Инженер Контекста
Kanalga Telegram’da o‘tish
Евгений Левашов, контент-лид в VK Tech, отвечаю за VK Cloud, VK Data Platform, Tarantool и другой технохардкор. Редактирую ИТ-компании, консультирую, учу. Здесь всё про Ai в контенте, дату, облака и остальной ИТ. Писать — @levashove CC BY-NC-SA 4.0
Ko'proq ko'rsatish947
Obunachilar
Ma'lumot yo'q24 soatlar
+47 kun
+630 kun
Ma'lumotlar yuklanmoqda
O'xshash kanallar
Taglar buluti
Kirish va chiqish esdaliklari
---
---
---
---
---
---
Obunachilarni jalb qilish
Oktabr '26Okt '26
Oktabr '26
+7
0 kanalda
Sentabr '26
+17
0 kanalda
Get PRO
Avgust '26
+42
0 kanalda
Get PRO
Iyul '26
+23
1 kanalda
Get PRO
Iyun '26
+5
0 kanalda
Get PRO
May '26
+10
2 kanalda
Get PRO
Aprel '26
+12
1 kanalda
Get PRO
Mart '26
+29
3 kanalda
Get PRO
Fevral '26
+6
0 kanalda
Get PRO
Yanvar '26
+7
0 kanalda
Get PRO
Dekabr '25
+22
1 kanalda
Get PRO
Noyabr '25
+10
3 kanalda
Get PRO
Oktabr '25
+4
0 kanalda
Get PRO
Sentabr '25
+4
0 kanalda
Get PRO
Avgust '25
+6
0 kanalda
Get PRO
Iyul '25
+15
3 kanalda
Get PRO
Iyun '25
+11
3 kanalda
Get PRO
May '25
+5
1 kanalda
Get PRO
Aprel '25
+10
0 kanalda
Get PRO
Mart '25
+11
0 kanalda
Get PRO
Fevral '25
+16
0 kanalda
Get PRO
Yanvar '25
+12
0 kanalda
Get PRO
Dekabr '24
+23
0 kanalda
Get PRO
Noyabr '24
+15
0 kanalda
Get PRO
Oktabr '24
+17
0 kanalda
Get PRO
Sentabr '24
+25
0 kanalda
Get PRO
Avgust '24
+16
0 kanalda
Get PRO
Iyul '24
+8
3 kanalda
Get PRO
Iyun '24
+12
0 kanalda
Get PRO
May '24
+10
1 kanalda
Get PRO
Aprel '24
+22
0 kanalda
Get PRO
Mart '24
+33
0 kanalda
Get PRO
Fevral '24
+67
1 kanalda
Get PRO
Yanvar '24
+22
0 kanalda
Get PRO
Dekabr '23
+33
0 kanalda
Get PRO
Noyabr '23
+32
2 kanalda
Get PRO
Oktabr '23
+19
1 kanalda
Get PRO
Sentabr '23
+24
0 kanalda
Get PRO
Avgust '23
+23
0 kanalda
Get PRO
Iyul '23
+23
0 kanalda
Get PRO
Iyun '23
+19
0 kanalda
Get PRO
May '23
+21
0 kanalda
Get PRO
Aprel '23
+11
0 kanalda
Get PRO
Mart '23
+22
0 kanalda
Get PRO
Fevral '23
+16
0 kanalda
Get PRO
Yanvar '23
+36
0 kanalda
Get PRO
Dekabr '22
+33
0 kanalda
Get PRO
Noyabr '22
+34
0 kanalda
Get PRO
Oktabr '22
+39
0 kanalda
Get PRO
Sentabr '22
+30
0 kanalda
Get PRO
Avgust '22
+37
0 kanalda
Get PRO
Iyul '22
+39
0 kanalda
Get PRO
Iyun '22
+44
0 kanalda
Get PRO
May '22
+58
0 kanalda
Get PRO
Aprel '22
+81
0 kanalda
Get PRO
Mart '22
+188
0 kanalda
Get PRO
Fevral '22
+20
0 kanalda
Get PRO
Yanvar '22
+37
0 kanalda
Get PRO
Dekabr '21
+19
0 kanalda
Get PRO
Noyabr '21
+13
0 kanalda
Get PRO
Oktabr '21
+18
0 kanalda
Get PRO
Sentabr '21
+40
0 kanalda
Get PRO
Avgust '21
+20
0 kanalda
Get PRO
Iyul '21
+32
0 kanalda
Get PRO
Iyun '21
+43
0 kanalda
Get PRO
May '21
+69
0 kanalda
Get PRO
Aprel '21
+31
0 kanalda
Get PRO
Mart '21
+34
0 kanalda
Get PRO
Fevral '21
+27
0 kanalda
Get PRO
Yanvar '21
+39
0 kanalda
Get PRO
Dekabr '20
+1 314
0 kanalda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 13 Oktabr | 0 | |||
| 12 Oktabr | +1 | |||
| 11 Oktabr | +2 | |||
| 10 Oktabr | 0 | |||
| 09 Oktabr | +2 | |||
| 08 Oktabr | 0 | |||
| 07 Oktabr | +1 | |||
| 06 Oktabr | +1 | |||
| 05 Oktabr | 0 | |||
| 04 Oktabr | 0 | |||
| 03 Oktabr | 0 | |||
| 02 Oktabr | 0 | |||
| 01 Oktabr | 0 |
Kanal postlari
Второй мозг контент-менеджера. Часть 2. Четыре задачи из моей недели
Не откладываем в долгий ящик — продолжаем цикл. Год назад я описал свой день списком задач. По сути он не изменился, но у каждого дела появилась одна общая точка старта. Это сессия Claude Code, открытая внутри моего репозитория. Не потому, что я полюбил терминал. Это единственное место, где одновременно лежат память, правила и агенты: чат без репозитория забывает всё после закрытия вкладки, а репозиторий помнит, что я туда положил за полгода.
Покажу на четырёх реальных задачах, как я работаю с нейросетями. Можно сказать, что тут полностью реализован подход ai-first.
Пресс-релиз про технологический анонс. На входе: тема, бриф и имя спикера для цитаты. Я пишу в сессии «напиши пресс-релиз про ...». Начинается мастер: шаг за шагом, по одному вопросу. Тип релиза, продукт, потом выбор из трёх заголовков, трёх лидов, набора блоков. Я выбираю, как выбирал бы из вариантов коллеги. Дальше конвейер уходит в фон: ресёрчер собрал семь источников и сохранил конспект отдельным коммитом ещё до того, как его увидел автор. Фактчекер проверил четырнадцать утверждений: семь подтвердил, четыре уточнил, три не нашёл в публичных источниках, выдуманных не нашёл ни одного. Например, одна цифра вела на SEO-агрегатор, первоисточника не было — и в текст она не вошла. На выходе три версии релиза: общая, техническая и упрощённая техническая, и рядом отчёт, где написано, что проверено, а что осталось на согласование. Моя работа — согласовать то, что осталось.
Интервью для СМИ. На входе документ, в котором уже есть комментарии от разных сторон: заход от лица вендора, рыночный блок на подтверждение спикеру, никаких оценок про чужие платформы, у заказчика стилевой контракт без длинных тире и конструкций «не X, а Y». Раньше это был вечер правок руками и три переписки. Теперь я даю ссылку на документ, он импортируется в библиотеку как Markdown, а дальше говорю: «переработай по комментариям, образец канвы — вот это интервью из базы». Система берёт старое интервью как референс структуры, проходит комментарии, прогоняет финальную траст-редактуру. Идём согласовывать.
SEO-статья для блога. На входе документ с ТЗ: тема, ключи, структура. Я говорю: «напиши статью по этому ТЗ, работай автономно». Система сначала проверяет базу: у меня уже есть конспекты по теме, их она дополняет, а не собирает заново. Потом ресёрч, автор, фактчекер. И вот тут самое интересное: фактчекер снял из текста цифру, которая пришла из нашей же продуктовой фактуры, но публичного первоисточника у неё нет, а та публичная, что нашлась, относится к другому направлению. Заодно он заметил, что условия скидки в фактуре и на сайте расходятся. В статью ни то ни другое не вошло, но в отчёте появилась строка для продуктовой команды: сверить фактуру с сайтом. Траст-редактор внёс 26 правок и статья сохранена со статусом «на ревью». Идём согласовывать.
Обновление лендинга по SEO-ТЗ. На входе документ с тремя вкладками (анализ, структура, SEO) и текущая страница. Я говорю: «обнови лендинг баз данных по этому ТЗ». Режим обновления отличается от создания: структура страницы жёстко сохраняется, число блоков и предложений плюс-минус одно, на выходе таблица «было — стало» по каждому блоку. Редактор оценил черновик на 8 из 10, повторный круг не потребовался. Цифры в новых блоках траст-редактор пометил на перепроверку, фактчекер прошёл по ним точечно. В CMS я несу таблицу, а не текст: так тот, кто вносит правки на сайте, видит, что именно изменилось.
Что общего у этих четырёх задач. Я ни разу не писал текст с нуля и ни разу не искал факты сам. Моя работа сдвинулась в две точки: решения на входе (какой заголовок, какой угол, что считать источником) и приёмка на выходе (что взять на согласование и что из открытых вопросов нести людям на проверку). Всё между ними делает система, и всё между ними остаётся в репозитории: конспект, черновик, отчёт с трассой проверок. Поэтому следующая такая задача начнётся не с чистого листа, а с того, что уже найдено.
В следующем посте: про то, как у меня всё хранится и три вида памяти.
#контентменеджерское #ai_agents #второймозгконтентменеджера
| 2 | Второй мозг контент-менеджера. Часть 1. Что стало с базой контента
Больше года назад я начал писать текст про базу контента в Obsidian. Он так и остался в черновиках, оборванный на фразе «прошло несколько месяцев, и я начинаю подводить итоги эксперимента». Итогов не было, потому что эксперимент не закончился. Он свернул туда, куда я не планировал.
С чего всё началось. Я разобрал свой рабочий день и увидел, что весь день пишу: минутки встреч, тексты задач, ответы в чатах, комментарии к чужим текстам. Написанное копится, но почти не переиспользуется. Через полгода найти старую заметку стоит столько же, сколько написать её заново. Я прошёл обычный путь: папки по проектам, потом по годам и месяцам, потом заметки в телефоне. Папки работают, пока ты редактор одного направления. Заметки хранят голый текст, который ни с чем не связан.
Тогда я написал, что в основе продуктивности контент-менеджера лежит база контента, и составил список, что она должна уметь: теги, Markdown с таблицами, шаблоны, папки, автоматизация, графы связей, визуализация. Семь пунктов. Я собирался выбрать под них инструмент — Obsidian — и рассказать, как всё устроил.
Инструмент я выбрал. Это оказался репозиторий на GitHub, и сейчас в нём лежит всё, что я делаю как контент-менеджер.
Пройдусь по старому списку, потому что он закрылся весь, только не так, как я ожидал.
Теги есть: у каждого файла в шапке домен, тип, продукт, география. Markdown с таблицами есть: кроме него, там вообще ничего нет. Шаблоны есть, но не заметок, а целых процессов: пресс-релиз, кейс, SEO-статья, дайджест, у каждого свои шаги и своя папка, куда он сохраняется. Папки есть, и они плоские: один уровень по типу материала, имя файла начинается с даты, никаких «черновиков» и «опубликованного». Автоматизация есть, и её больше, чем я мог себе представить год назад: конспект исследования сохраняется сам, ещё до того, как его кто-то прочитал. Графы есть: система показывает, какие статьи ни на кого не ссылаются и на кого стоило бы сослаться из новой. Визуализация тоже есть, хотя ей я пользуюсь реже всего.
Вот только главный читатель этой базы теперь не я.
Её читают ИИ-агенты. Перед тем как искать что-то в вебе, агент смотрит, есть ли по теме конспект в базе. Перед тем как написать цифру, сверяется с карточкой факта, у которой есть источник и срок годности. Перед тем как назвать продукт, открывает словарь канонических имён. Я год назад думал, что строю базу для себя, чтобы быстрее находить старое. А построил память для системы, которая без этой памяти врёт уверенно и красиво.
И тут список из семи пунктов оказался неполным. В нём не было трёх вещей, которые по-настоящему отличают базу контента от второго мозга. Память должна проверять то, что в неё кладут. Память должна стареть: цифра годовой давности должна сама проситься на перепроверку. И память должна учиться: ошибка, повторившаяся дважды, должна превращаться в правило, а не в ещё одну правку в тексте.
Про это и будет цикл. Не про то, как писать: на это есть Ильяхов и коллеги. Про то, как контент-менеджеру держать поток, когда часть потока теперь пишут не люди. Как и обещал год назад: только мой опыт, только мой идеальный душный мир, и каждый пост должен быть полезен сам по себе.
В следующем: четыре задачи моей недели и как выстраивается процесс работы.
P.S.: Сорри за второй мозг. Этим термином очень любят пользоваться инфоцыгане от ИИ, чем уже сильно бесят. Но на самом деле эта концепция очень даже рабочая, особенно если ты работает с огромным количеством информации.
#контентменеджерское #ai_agents #второймозгконтентменеджера | 58 |
| 3 | Сегодня хочется просто поддержать коллег из Yandex и Yandex Cloud. Тем, кто пытается восстановить инфраструктуру и тем, кто отвечает на сотни сообщений и поддерживает коммуникацию с клиентами, коллегами, конкурентами и СМИ. Держитесь. Вы в ответе за Тех.
У меня готовы материалы о том, как я строю свою работу с нейросетями. Такие живые хайлайты реальной работы контент-лида в 2026 году. Но давайте уже в понедельник. | 110 |
| 4 | Matn yo'q... | 168 |
| 5 | Не давай модели подбирать слова. Заметка для редакторов про метод Птачека
Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению.
Правило первое: ни одного слова, предложенного моделью
Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы.
И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно».
Правило второе: никакой похвалы
Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят.
Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус.
Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку.
Что модели разрешено
Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: перебор со страдательным залогом, отглагольные существительные вместо действия, повторяющиеся обороты; «очень», «к сожалению», «на самом деле», рассыпанные по черновику, как опилки по верстаку. И отдельно — два-три абзаца, которые надо просто переставить в другое место, отчего ясность мгновенно улучшается.
Цикл: попросить модель найти проблемы, самому переписать проблемные куски, потом дать оба варианта на сравнение. И здесь важная деталь, которую легко упустить: сравнивать надо давать другой модели, без контекста вашей правки. Иначе она знает, что вы только что переписали, и знает, какой ответ вы хотите услышать.
Себе он сделал под это инструмент — редактор с подсветкой и комментариями на полях, где по тексту прогоняются заготовленные промпты-проходы. Но в заметке есть оговорка, которая мне нравится больше самого инструмента: что бы вы ни собрали сами, оно будет лучше моего, потому что собранное самостоятельно всегда лучше подходит своему автору.
Он скормил эту заметку GPT-5 со словами «я не автор», и модель сказала, что текст на 20% длиннее нужного. Птачек пишет: вероятно, она права. Но править он не будет.
Что я об этом думаю
Конечно, я не могу все тексты писать сам. Не для этого я целую фабрику контента написал. Но для редакторов экспертных материалов на Хабр эти приёмы очень пригодятся. Особенно проверки разными моделями.
Однако, я заложил эту логику в фабрику. Например, чистый контекст — это как раз проверка моделью без истории создания и правок текста.
Оригинал тут: sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
#ai #контентменеджерское | 177 |
| 6 | Не вайбкодь на выходных, не вайбкодь на выходных, не вайбкодь на выходных... | 173 |
| 7 | Обещал на 1000 подписчиков, но получилось раньше. Отдельный скилл clean-ai-patterns для проверки текстов на ИИ-паттерны. Показывает конкретные места и предлагает конкретные правки. | 167 |
| 8 | Обещанная история про косяки и разработку агентов, написанная во время перелёта в Москву
То, о чём я сейчас буду рассказывать, наверняка очень хорошо известно любому разработчику. И даже может вызвать у них улыбку. Итак, первую половину года я постоянно писал агенты для контента. Проектировал, вайбкодил, дописывал руками, что не нравилось, снова вайбкодил. Постоянно хотелось что-то улучшить, ускорить, оптимизировать, а затем опять усложнить. На каком то этапе там появился пайтон, экшены в гитхабе, синхронизация с другими репозиториями. И в какой-то момент для меня самого стало казаться, что этот процесс бесконечный.
Почему я вспомнил разработку в начале. Довольно часто знакомые программисты рассказывали, что долго не решались показать какой-то новый продукт, потому что опасались критики и провала. Процесс доработки становился бесконечным, а пока они стремились к идеалу, конкуренты выпускали сырую версию и уже начинали на ней зарабатывать.
Я свой mvp, конечно, раскатал на коллег практически в первые месяцы, но ситуация похожая. От той первой версии, которую забрали коллеги, до следующей анонсированной прошло три-четыре месяца. По своей внутренней нумерации я скакнул от v.1 до 4.55. Это приблизительно, в самолёте не посмотришь ченжлог, да и смысла в этом нет. То есть после первой раскатки я просто ушёл в лютые доработки и не смотрел по сторонам.
К чему это привело лично для меня:
Сложность и монструозность системы. Для всех кроме меня
Я то знаю, почему и зачем все эти проверки и экшены. И даже документацию написал, но кто её читает. Система, которую нельзя объяснить за десять минут, принадлежит одному человеку, даже если лежит в общем репозитории.
Я оптимизировал то, что видел сам
Да, видел много, но только по своим направлениям. Четыре месяца я честно доводил систему до идеала на выборке, которую сам же и составил. В ML для этого есть точное определение: переучился на тестовом наборе. Загуглите сами, что это.
Коллеги остались с v.1
Вот, кстати, это больнее всего. Пока я разгонялся, у них работала первая версия и они к ней приспособились. Придумали обходные пути, завели свои агенты и скиллы, привыкли к её странностям. Моя новая версия для них стала не улучшение, а ломкой того, что уже как-то жило. Чем дольше пауза, тем дороже обходится каждое обновление.
Точка остановки не наступила сама.
Я почему-то ждал, что в какой-то момент станет «готово» и я сам это почувствую. Не чувствуется. Список идей не заканчивается никогда, каждая следующая выглядит как последняя недостающая. Остановиться можно только решением, а не ощущением.
Следующие пару месяцев я не трогал ничего. Просто работал с системой как обычный пользователь, слушал коллег и смотрел по сторонам.
Первое, что выяснилось: половина того, что я написал, используется только мной. Не потому что плохо сделано, потому что не нужно. Я решал задачи, которые люди предпочитают решать другими способами. А то, что реально болит, казалось мне скучным, и я это четыре месяца обходил стороной. Теперь нагоняю.
Второе: пока не трогаешь, наконец видишь, что ломается. Когда каждую неделю выкатываешь новую версию, любой сбой списывается на свежие правки. Когда система стоит неподвижно, становится ясно, что она разваливается стабильно и в одном и том же месте.
Третье, и самое неприятное. За эти два месяца вышло столько всего нового, что какие-то мои проверки и промпты просто перестали иметь смысл. Я месяцами обходил ограничения, которое теперь снято на уровне инструмента. Смотреть по сторонам тоже работа, и я её не делал, потому что был занят.
Так что пауза оказалась не простоем. Она оказалась единственным способом узнать, что строить дальше. Разработка ослепляет: пока пишешь, видишь только следующий шаг.
Теперь стараюсь держать ритм: месяц строю, месяц живу с тем, что построил. Второй месяц даёт больше, чем первый, хотя это до сих пор кажется мне контринтуитивным.
#ai_agents | 134 |
| 9 | Раньше любил написать что-то про новые айфоны, сравнить. Сейчас лень, потому что по ощущениям весь Apple выглядит как-то так. | 102 |
| 10 | Вышел DeepSeek V4.1-Flash. Что там по применимости для контента?
Если лень всё читать, то вот сразу вывод: модели дешевеют быстрее, чем умнеют. Читать миллион токенов теперь почти ничего не стоит, а фактология осталась на прежнем уровне. Значит, на первый план выходит не выбор модели, а то, что мы кладём ей в контекст. Кто собирает хороший контекст, тот получает хороший текст. Кто надеется на модель, получит уверенную ошибку, просто дешевле. Контент-инженерия всё больше превращается в инженерию контекста.
Теперь подробности. В отчёте DeepSeek на 51 страницу нет ни одного теста на качество текста и ни слова о русском языке. Модель делали под агентов и код. Но часть выводов прямо переносится на контент-пайплайны.
1. Редстандарты в начало промпта
Главное в релизе — дешёвый контекст. Префилл стал почти вдвое дешевле, KV-кэш — вчетверо компактнее. Кэш префикса DeepSeek хранит не меньше 72 часов. В контент-пайплайне постоянная часть промпта большая: редстандарт, tone of voice, эталоны, описание продукта. Её выгодно ставить первой и не менять между запусками. Всё переменное: задание, исходник, дату — в конец. Если поставить дату в первую строку системного промпта, кэш будет сбрасываться каждый день.
2. Факты давать, а не спрашивать
Слабое место модели — фактология. На SimpleQA-Verified базовая модель набирает 42,3, а V4-Pro — 55,2. Длинные рассуждения не спасают: при переходе с уровня 25 на 100 результат меняется на пару пунктов. Если модель чего-то не знает, додумать это она не сможет.
Для контента вывод простой: имена, даты, цифры и названия продуктов берутся только из источников в контексте. Особенно это касается тех, кто работает на deepseek-v4-pro: с 14 сентября такие запросы молча уйдут на V4.1-Flash.
3. Миллион токенов не значит понимание миллиона токенов
На LongBench-V2 у модели 45,2, у V4-Pro — 51,5. Когда адаптируете длинный отчёт, отдавайте нужные разделы, а не весь PDF целиком.
4. Картинки на вход рабочий инструмент
Модель нативно мультимодальная, на DocVQA у неё 95,6. Слайды спикера, скриншоты интерфейса и таблицы из PDF можно отдавать как есть и просить черновик. При этом картинка сжимается примерно до 1344×1344, так что длинные скриншоты и плотную инфографику лучше резать на части. И цифры, снятые с графиков, стоит проверять: на Chartography у модели 78,9, у Opus 5 — 84.
5. Max не по умолчанию
В API три уровня: low, high и max, внутри это 50, 75 и 100. Переход с 25 на 100 даёт плюс 8–9 пунктов на тестах и примерно в 2,5 раза больше токенов. Большая часть прироста набирается уже к 60–80. Эти данные только по математике и коду, по текстам замеров нет. Моя гипотеза: для рерайта, адаптаций и анонсов хватит low, для аналитики стоит брать high.
Забрать DeepSeek V4.1-Flash, опубликовано под лицензией MIT
#ai | 112 |
| 11 | 🚀К 2030 году российский рынок софта для ИИ вырастет почти в 4 раза
Apple Hills Digital исследовали рынок AI/ML/GenAI за 2022–2025 годы и подготовили прогноз до 2030 года. Посмотрели на динамику разных сегментов, переход бизнеса от экспериментов к измеримому ROI, роль облачных решений и основные ограничения для дальнейшего роста.
Главные выводы собрали в карточках, а полное исследование можно найти здесь 👀
📬 Мы в МАХ | 103 |
| 12 | Почти написал. Но пока почитайте исследование.
Интересно. | 110 |
| 13 | Перелет до Москвы — прекрасная возможность написать про контент-заводы и все такое без нейронок. По старинке.
Главное — не уснуть. | 119 |
| 14 | Пятничное, отпускное, написанное с телефона.
Смотрите:
— 1 сентября Anthropic выпускает Claude Fable 5.1
— 2 сентября Google свою очередную Gemini 3.8 Flash, кстати, очень дешевую.
— 3 сентября вышла Muse Spark 1.3.
Ждем буквально на днях ещё релиз новой модели OpenAI ASTRA и новый Grok 4.7.
Конкуренция растет, токены дешевеют. Кажется выиграет сейчас тот, будет быстрее внедрять нужную модель на нужном шаге.
Ну и как анонс: сел писать, что я делал в своей системе агентов два месяца. Спойлер: ничего до двух последних дней. | 141 |
| 15 | Зашли с вопросом про стратегию или концепцию AI-first в контент. Но спросили с пониманием, что это когда в любом процессе буквально сначала ИИ. Сгенерили, потом посмотрели, что вышло.
Можно со мной тут поспорить, конечно, но «first» в таких терминах никогда не значило «сначала». Mobile-first — не про то, что мобильную версию рисуют раньше десктопной, а про то, что мобильный экран учитывается в каждом решении. Так же и здесь: AI-first — не порядок шагов, а то, что ИИ встроен во весь процесс, а не стоит отдельным этапом в начале или посередине.
Когда ИИ отдельный этап, вы, например, ускоряете написание черновика втрое, но материал упирается в проверку. Текстов стало больше, проверять чужое дороже, чем писать своё, редактор тонет. Локальное ускорение, глобальное замедление — знакомая история же?
Когда ИИ встроен, вы смотрите на весь маршрут материала: от идеи до разбора после публикации, и на каждом отрезке спрашиваете, что здесь меняется теперь, когда есть модель.
На планировании раньше спорили, какую тему взять: производство стоило дорого, ошибиться было больно. Теперь дешевле накидать три черновика и посмотреть, какой живой, чем неделю обсуждать один.
На брифе выясняется, что модель не читает мысли. Приходится проговаривать вслух: что на входе, что на выходе, что считается браком. Побочный эффект: люди тоже начинают понимать задачу с первого раза.
По той же причине из головы главреда наконец переезжает в файл редстандарт. Больно, зато у команды появляется общий критерий вместо «мне не нравится».
На проверке — главное. Сверить факт с источником, поймать разнобой в терминах, прогнать текст по стандарту: всё это машина делает лучше и дешевле, чем пишет. Но ставят её обычно на написание, потому что генерация эффектнее.
И на разборе после публикации: что зашло, что нет, почему. Раньше на это просто не хватало рук.
Проверить себя просто: спросите, что у вас изменилось, кроме того, что тексты теперь пишет модель. Если ничего — это не AI-first, а новый инструмент на одном этапе. Нормально, все с этого начинают, просто не надо называть это стратегией.
И то, что не меняется при любой встроенности: последний шаг человеческий, кто-то ставит подпись. В этом вся разница между «сначала ИИ» и «ИИ везде». В первом случае вы ищете, что бы ему отдать. Во втором понимаете, что оставляете себе и почему.
Брюзжание off. Пойду дальше работать. Постараюсь следующими публикациями дать что-то прикладное, а не только теорию, как нужно строить новые редакции.
#контентменеджерское #ai | 153 |
| 16 | «Что сейчас самое лучшее?» — неправильный вопрос
Давайте сегодня не про технину и агентов опять. Я начал со сложного и пропустил самое начало, а спрашивают как раз про него. С чего начать, что сейчас на острие, какая модель лучше, пора ли переезжать.
Отвечу сначала как спросили. Потом объясню, почему спросили не то.
По существу вопроса: берите то, что подходит вам, а не то, что вышло вчера.
Инструмент, в котором вы работаете каждый день, окупается не характеристиками, а наработанностью. Вы знаете, где он врёт. Знаете, какая формулировка даёт результат. У вас накопились заготовки, шаблоны, контекст. Это капитал, и переносится он плохо: на новом инструменте вы снова новичок, только теперь с завышенными ожиданиями. Три месяца притирки ради пятнадцати процентов на бенчмарке — плохая сделка.
А переезжают именно ради процентов на бенчмарке. Хотя бенчмарк меряет не вашу работу. Модель, которая решает олимпиадную математику, не обязательно держит ваш тон голоса. Победитель агентных задач не обязательно аккуратнее с фактами. Единственный честный тест — десять ваших типовых задач через оба варианта. Вечер работы.
А теперь забудьте всё, что я написал выше.
Не потому что неправда. Потому что не туда пошли изначально.
За вопросом «какую модель взять» почти всегда стоит надежда, что правильный выбор всё решит. Но я пока не видел ни одного случая, когда это срабатывает. Упираются не в модель.
Упираются в то, что стандарт не сформулирован: он живёт в голове главреда и достаётся оттуда в режиме «мне не нравится». В то, что источники не описаны и каждый берёт цифры откуда придётся. В то, что никто не знает, где текст проверяется и кем, потому что проверяет его тот, у кого сегодня есть время.
Более сильная модель не чинит ни одну из этих вещей. Она делает ровно одно: быстрее производит то, что вы всё равно не умеете принять. Вы получаете больше текста, который некому оценить по критерию, которого нет.
Поэтому мой ответ на «с чего начать» звучит скучно. Возьмите то, что уже под рукой. Найдите одну задачу, которая повторяется каждую неделю и от которой воет вся команда. Опишите её словами: что на входе, что на выходе, что считается браком. Не «пиши хорошо», а что именно делает текст непригодным. Пропишите процесс и доведите до состояния, когда он идёт без вашего участия в каждом шаге.
Вот тогда вопрос про модель станет осмысленным. Вы упрётесь и будет видно во что: в модель, в окружение или в собственное описание задачи. До этой точки ответить на него нечем.
И последнее, неприятное. Гонка за релизами — это способ не делать скучную часть. Читать про новое приятно, ощущается как работа, не требует ни одного решения и никого не злит. А сесть и выписать редполитику, договориться, кто отвечает за факты, и признать вслух, что ваш стандарт нигде не зафиксирован, — это конфликт, время и неудобные разговоры.
Поэтому все обсуждают модели. Модели обсуждать безопасно.
#контентменеджерское | 137 |
| 17 | Понедельничное | 127 |
| 18 | Дело не в гуманитариях, а в конфигурации задачи. Или размышления о том, как внедрять ИИ в редакциях.
Давайте не про агенты, а про процессы. На митапе для редакторов в IT от YADRO я очень коротко рассказывал про то, как улучшить качество материалов, которые мы получаем от ИИ. И сам в процессе понял, что тема интересна даже не механиками, а психологией. Ведь я долго объяснял сопротивление ИИ у редакторов складом ума. Технари любят новое, гуманитарии, коих среди коллег большинство, держатся за ремесло. Удобная рамка, все кивают.
Рамка неверная. Я видел, как в её тени принимаются решения: «наймём тех, кто помоложе», «проведём воркшоп, они привыкнут». Не привыкают. Потому что сопротивление растёт не из склада ума, а из конфигурации задачи. Условий три, и у редакторов совпадают все три сразу.
Первое. Задача выглядит субъективной
Текст — это вкусовщина. Так его видит редактор, и не без оснований: он не может объяснить, почему эта фраза плохая, он её слышит. Там, где нет проверяемого критерия, доверять алгоритму не за что. Нечем поверить его выход.
Тут ловушка в слове «выглядит». Внутри редактуры полно вполне объективных кусков: факт сходится с источником или нет, термин единообразен или нет, структура соблюдена или нет. Но они не отделены, поэтому весь процесс окрашивается субъективным. Мы сами склеили проверяемое с непроверяемым и потом удивляемся, что доверие не выдаётся частями.
Второе. У человека есть экспертиза именно здесь
Десять лет практики, свёрнутые в интуицию. Это капитал, и он работает: редактор правит быстро и точно, не проговаривая ни одного правила.
Он же главное препятствие. Эксперт вообще плохо принимает советы, любые, не только машинные. Попробуйте предложить сильному редактору правку от другого сильного редактора И увидите ту же реакцию, что и на нейросеть. Просто человеку мы такое прощаем, а модели нет.
Третье. Модель спорит с твоим суждением, а не с чужим
Вот это самое недооценённое. Разница между «вот вариант коллеги, сравни со своим» и «вот вариант вместо твоего» кажется формальной. Она не формальная.
Почти все внедрения устроены по второй схеме. Модель отдаёт готовый текст, человек ставит оценку. То есть каждый раз ставится вопрос «ты или она», и каждый раз человек защищает себя. Мы буквально спроектировали процесс так, чтобы включалась самозащита, а потом называем результат технофобией.
Проверка на технарях
Если бы дело было в гуманитарной природе, разработчики принимали бы ИИ гладко. Не принимают.
Сеньор, который десять лет живёт в своей кодовой базе, тормозит ровно так же. У него та же тройка: качество кода он оценивает по неписаному стандарту, экспертизы вагон, и ассистент предлагает вместо его решения. Разница только в том, что он реже говорит об этом вслух — не принято.
Это, кстати, лучший аргумент в разговоре с руководством. Как только «наши редакторы боятся нового» превращается в «у наших редакторов совпали три условия, и у наших сеньоров они тоже совпали» — разговор переезжает с людей на процесс. А чинить процесс можно.
Что делать по каждому пункту
Расщепить задачу. Вытащить из «редактуры» то, что проверяемо, и назвать это отдельно. Редполитика в файле: что считается фактом, откуда берутся цифры, какие конструкции запрещены, что делаем с вендорскими заявлениями. Это больно, так как впервые заставляет команду проговорить то, о чём она молчаливо договорилась. Зато появляется предмет спора: критерий, а не вкус. И спорить начинают редакторы между собой, а не редактор с нейросетью.
Дать право править. Разница между «принять или отклонить» и «вмешаться внутрь» больше, чем кажется. В первом случае человек оценивает чужой результат целиком и потому придирается к целому. Поэтому одна кривая фраза хоронит нормальный текст, отправляя его на перегенерацию. Во втором он эту фразу просто переписывает и идёт дальше. Причём объём вмешательства почти не важен: достаточно, чтобы возможность править существовала. И вот что из этого следует. Чем плотнее вы закрываете процесс — «модель сама всё сделает, вам останется утвердить», — тем больше сопротивления получите на входе. Не потому что качество хуже, а потому что человеку не оставили места. Пайплайн, где нельзя ничего подкрутить, будет отвергнут скорее, чем пайплайн, который иногда выдаёт ерунду, которую можно поправить.
Поставить рядом, а не вместо. Обычная схема: редактор жмёт кнопку, получает готовый текст и ставит «ок» или «переделать». Но это не помощь, а экзамен, где экзаменуют его самого: свой вариант у него уже есть в голове, и принять чужой значит признать, что его был хуже. Он защищает себя, а не оценивает текст. Переставьте два шага: сначала свой заголовок, потом ещё три от модели — и он уже не сдаёт экзамен, а выбирает из четырёх, один из которых его. Отсюда три правила, и все они про то, кто в процессе автор:
1. Модель работает в начале, а не в конце: даёт сырьё — конспекты и черновики, — а не финал на утверждение, потому что чужой финал тяжело судить и хочется зарубить целиком, а из сырья просто собирают.
2. Вариантов всегда несколько: один — это закрытый вопрос «да или нет», где отказ стоит дорого, а три — открытый «какой», и даже слабые варианты работают, на их фоне видно, чем хорош сильный.
3. И своя версия появляется первой. Стоит один раз прочитать вариант модели и мысль уже не своя: дальше вы либо соглашаетесь с ним, либо спорите, но в обоих случаях думаете про её текст, а не про свой. Собственная идея просто не успевает родиться. Поэтому сначала набросайте свой заголовок — хоть кривой, хоть за тридцать секунд, — и только потом смотрите, что предложила модель.
Что не чинится
Под материалом стоит фамилия человека. Не модели. Пока это так, редактор будет проверять, и правильно сделает. Задача не в том, чтобы он перестал проверять, а в том, чтобы проверка стоила дешевле, чем написать самому.
И тут уже можно возвращаться к тому, о чём я рассказывал на митапе и рассказываю в канале. Но начинать, конечно, лучше вот с вышеописанных решений и договорённостей.
#контентменеджерское | 136 |
| 19 | На Хабре вышла статья коллеги о том, как развернуть локальный ИИ-агент в своём контуре — Ollama плюс OpenClaw. Рабочая инструкция, пользуйтесь.
#ai_agents #habr | 137 |
| 20 | Пятничное | 249 |
