Не давай модели подбирать слова. Заметка для редакторов про метод Птачека
Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению.
Правило первое: ни одного слова, предложенного моделью
Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы.
И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно».
Правило второе: никакой похвалы
Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят.
Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус.
Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку.
Что модели разрешено
Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: перебор со страдательным залогом, отглагольные существительные вместо действия, повторяющиеся обороты; «очень», «к сожалению», «на самом деле», рассыпанные по черновику, как опилки по верстаку. И отдельно — два-три абзаца, которые надо просто переставить в другое место, отчего ясность мгновенно улучшается.
Цикл: попросить модель найти проблемы, самому переписать проблемные куски, потом дать оба варианта на сравнение. И здесь важная деталь, которую легко упустить: сравнивать надо давать другой модели, без контекста вашей правки. Иначе она знает, что вы только что переписали, и знает, какой ответ вы хотите услышать.
Себе он сделал под это инструмент — редактор с подсветкой и комментариями на полях, где по тексту прогоняются заготовленные промпты-проходы. Но в заметке есть оговорка, которая мне нравится больше самого инструмента: что бы вы ни собрали сами, оно будет лучше моего, потому что собранное самостоятельно всегда лучше подходит своему автору.
Он скормил эту заметку GPT-5 со словами «я не автор», и модель сказала, что текст на 20% длиннее нужного. Птачек пишет: вероятно, она права. Но править он не будет.
Что я об этом думаю
Конечно, я не могу все тексты писать сам. Не для этого я целую фабрику контента написал. Но для редакторов экспертных материалов на Хабр эти приёмы очень пригодятся. Особенно проверки разными моделями.
Однако, я заложил эту логику в фабрику. Например, чистый контекст — это как раз проверка моделью без истории создания и правок текста.
Оригинал тут: sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
#ai #контентменеджерское
Томас Птачек, человек из мира безопасности, написал заметку о том, как он пишет тексты с ИИ. Метод сводится к двум запретам и одному разрешению.
Правило первое: ни одного слова, предложенного моделью
Обоснование у него любопытное. Модели сверхъестественно хороши в подборе приятных оборотов — это, собственно, их главный навык. Проблема тонкая: модель как будто застряла в режиме, где всё, что она пишет, — заголовок для журнала. Заголовки хороши, но человек, написавший статью из нескольких десятков заголовков, вызывает вопросы.
И дальше он предлагает относиться к правилу как к средству индивидуальной защиты: любой конкретный оборот, предложенный моделью, — вне игры, даже если он вам нравится и даже если вы уверены, что он лучше вашего. Логика в том, что вы не сможете надёжно отлавливать все способы, которыми модель превращает текст в нейрослоп. Поэтому запрет тотальный, без исключений на «ну вот тут же правда удачно».
Правило второе: никакой похвалы
Это он называет более тонкой проблемой — влиянием, а не подстановкой слов. Отдаёте черновик, модель отвечает, что это золото. А в первом черновике большинство абзацев плохи, логика скачет и есть лишних слов семьсот пятьдесят.
Модель одобряет структуру, потом абзацы и переходы, потом выбор слов, метафоры, отсылки. В результате вы укрепляетесь во всех импульсах первого черновика, хотя обычно поступили бы иначе: переписали бы, передумали, заменили абзацы. Именно эти передумывания — основа для вашего голоса. Читатель не поймёт, что не так, но почувствует искусственный привкус.
Обходной приём у него был такой: пару лет он открывал каждый промпт враньём. Помогает, но модель обычно начинает подгонять свои выводы под «цели». Так что нынешний совет проще: запретить похвалу прямым текстом и оставаться начеку.
Что модели разрешено
Тут всё про усталость. Ошибки можно ловить и вручную, но это утомительная работа, а модель не устаёт. Отсюда список: перебор со страдательным залогом, отглагольные существительные вместо действия, повторяющиеся обороты; «очень», «к сожалению», «на самом деле», рассыпанные по черновику, как опилки по верстаку. И отдельно — два-три абзаца, которые надо просто переставить в другое место, отчего ясность мгновенно улучшается.
Цикл: попросить модель найти проблемы, самому переписать проблемные куски, потом дать оба варианта на сравнение. И здесь важная деталь, которую легко упустить: сравнивать надо давать другой модели, без контекста вашей правки. Иначе она знает, что вы только что переписали, и знает, какой ответ вы хотите услышать.
Себе он сделал под это инструмент — редактор с подсветкой и комментариями на полях, где по тексту прогоняются заготовленные промпты-проходы. Но в заметке есть оговорка, которая мне нравится больше самого инструмента: что бы вы ни собрали сами, оно будет лучше моего, потому что собранное самостоятельно всегда лучше подходит своему автору.
Он скормил эту заметку GPT-5 со словами «я не автор», и модель сказала, что текст на 20% длиннее нужного. Птачек пишет: вероятно, она права. Но править он не будет.
Что я об этом думаю
Конечно, я не могу все тексты писать сам. Не для этого я целую фабрику контента написал. Но для редакторов экспертных материалов на Хабр эти приёмы очень пригодятся. Особенно проверки разными моделями.
Однако, я заложил эту логику в фабрику. Например, чистый контекст — это как раз проверка моделью без истории создания и правок текста.
Оригинал тут: sockpuppet.org/blog/2026/09/17/how-to-write-with-an-llm/
#ai #контентменеджерское
👍4❤1
Сегодня хочется просто поддержать коллег из Yandex и Yandex Cloud. Тем, кто пытается восстановить инфраструктуру и тем, кто отвечает на сотни сообщений и поддерживает коммуникацию с клиентами, коллегами, конкурентами и СМИ. Держитесь. Вы в ответе за Тех.
У меня готовы материалы о том, как я строю свою работу с нейросетями. Такие живые хайлайты реальной работы контент-лида в 2026 году. Но давайте уже в понедельник.
У меня готовы материалы о том, как я строю свою работу с нейросетями. Такие живые хайлайты реальной работы контент-лида в 2026 году. Но давайте уже в понедельник.
❤5🔥1😁1😭1🗿1
Второй мозг контент-менеджера. Часть 1. Что стало с базой контента
Больше года назад я начал писать текст про базу контента в Obsidian. Он так и остался в черновиках, оборванный на фразе «прошло несколько месяцев, и я начинаю подводить итоги эксперимента». Итогов не было, потому что эксперимент не закончился. Он свернул туда, куда я не планировал.
С чего всё началось. Я разобрал свой рабочий день и увидел, что весь день пишу: минутки встреч, тексты задач, ответы в чатах, комментарии к чужим текстам. Написанное копится, но почти не переиспользуется. Через полгода найти старую заметку стоит столько же, сколько написать её заново. Я прошёл обычный путь: папки по проектам, потом по годам и месяцам, потом заметки в телефоне. Папки работают, пока ты редактор одного направления. Заметки хранят голый текст, который ни с чем не связан.
Тогда я написал, что в основе продуктивности контент-менеджера лежит база контента, и составил список, что она должна уметь: теги, Markdown с таблицами, шаблоны, папки, автоматизация, графы связей, визуализация. Семь пунктов. Я собирался выбрать под них инструмент — Obsidian — и рассказать, как всё устроил.
Инструмент я выбрал. Это оказался репозиторий на GitHub, и сейчас в нём лежит всё, что я делаю как контент-менеджер.
Пройдусь по старому списку, потому что он закрылся весь, только не так, как я ожидал.
Теги есть: у каждого файла в шапке домен, тип, продукт, география. Markdown с таблицами есть: кроме него, там вообще ничего нет. Шаблоны есть, но не заметок, а целых процессов: пресс-релиз, кейс, SEO-статья, дайджест, у каждого свои шаги и своя папка, куда он сохраняется. Папки есть, и они плоские: один уровень по типу материала, имя файла начинается с даты, никаких «черновиков» и «опубликованного». Автоматизация есть, и её больше, чем я мог себе представить год назад: конспект исследования сохраняется сам, ещё до того, как его кто-то прочитал. Графы есть: система показывает, какие статьи ни на кого не ссылаются и на кого стоило бы сослаться из новой. Визуализация тоже есть, хотя ей я пользуюсь реже всего.
Вот только главный читатель этой базы теперь не я.
Её читают ИИ-агенты. Перед тем как искать что-то в вебе, агент смотрит, есть ли по теме конспект в базе. Перед тем как написать цифру, сверяется с карточкой факта, у которой есть источник и срок годности. Перед тем как назвать продукт, открывает словарь канонических имён. Я год назад думал, что строю базу для себя, чтобы быстрее находить старое. А построил память для системы, которая без этой памяти врёт уверенно и красиво.
И тут список из семи пунктов оказался неполным. В нём не было трёх вещей, которые по-настоящему отличают базу контента от второго мозга. Память должна проверять то, что в неё кладут. Память должна стареть: цифра годовой давности должна сама проситься на перепроверку. И память должна учиться: ошибка, повторившаяся дважды, должна превращаться в правило, а не в ещё одну правку в тексте.
Про это и будет цикл. Не про то, как писать: на это есть Ильяхов и коллеги. Про то, как контент-менеджеру держать поток, когда часть потока теперь пишут не люди. Как и обещал год назад: только мой опыт, только мой идеальныйдушный мир, и каждый пост должен быть полезен сам по себе.
В следующем: четыре задачи моей недели и как выстраивается процесс работы.
P.S.: Сорри за второй мозг. Этим термином очень любят пользоваться инфоцыгане от ИИ, чем уже сильно бесят. Но на самом деле эта концепция очень даже рабочая, особенно если ты работает с огромным количеством информации.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Больше года назад я начал писать текст про базу контента в Obsidian. Он так и остался в черновиках, оборванный на фразе «прошло несколько месяцев, и я начинаю подводить итоги эксперимента». Итогов не было, потому что эксперимент не закончился. Он свернул туда, куда я не планировал.
С чего всё началось. Я разобрал свой рабочий день и увидел, что весь день пишу: минутки встреч, тексты задач, ответы в чатах, комментарии к чужим текстам. Написанное копится, но почти не переиспользуется. Через полгода найти старую заметку стоит столько же, сколько написать её заново. Я прошёл обычный путь: папки по проектам, потом по годам и месяцам, потом заметки в телефоне. Папки работают, пока ты редактор одного направления. Заметки хранят голый текст, который ни с чем не связан.
Тогда я написал, что в основе продуктивности контент-менеджера лежит база контента, и составил список, что она должна уметь: теги, Markdown с таблицами, шаблоны, папки, автоматизация, графы связей, визуализация. Семь пунктов. Я собирался выбрать под них инструмент — Obsidian — и рассказать, как всё устроил.
Инструмент я выбрал. Это оказался репозиторий на GitHub, и сейчас в нём лежит всё, что я делаю как контент-менеджер.
Пройдусь по старому списку, потому что он закрылся весь, только не так, как я ожидал.
Теги есть: у каждого файла в шапке домен, тип, продукт, география. Markdown с таблицами есть: кроме него, там вообще ничего нет. Шаблоны есть, но не заметок, а целых процессов: пресс-релиз, кейс, SEO-статья, дайджест, у каждого свои шаги и своя папка, куда он сохраняется. Папки есть, и они плоские: один уровень по типу материала, имя файла начинается с даты, никаких «черновиков» и «опубликованного». Автоматизация есть, и её больше, чем я мог себе представить год назад: конспект исследования сохраняется сам, ещё до того, как его кто-то прочитал. Графы есть: система показывает, какие статьи ни на кого не ссылаются и на кого стоило бы сослаться из новой. Визуализация тоже есть, хотя ей я пользуюсь реже всего.
Вот только главный читатель этой базы теперь не я.
Её читают ИИ-агенты. Перед тем как искать что-то в вебе, агент смотрит, есть ли по теме конспект в базе. Перед тем как написать цифру, сверяется с карточкой факта, у которой есть источник и срок годности. Перед тем как назвать продукт, открывает словарь канонических имён. Я год назад думал, что строю базу для себя, чтобы быстрее находить старое. А построил память для системы, которая без этой памяти врёт уверенно и красиво.
И тут список из семи пунктов оказался неполным. В нём не было трёх вещей, которые по-настоящему отличают базу контента от второго мозга. Память должна проверять то, что в неё кладут. Память должна стареть: цифра годовой давности должна сама проситься на перепроверку. И память должна учиться: ошибка, повторившаяся дважды, должна превращаться в правило, а не в ещё одну правку в тексте.
Про это и будет цикл. Не про то, как писать: на это есть Ильяхов и коллеги. Про то, как контент-менеджеру держать поток, когда часть потока теперь пишут не люди. Как и обещал год назад: только мой опыт, только мой идеальный
В следующем: четыре задачи моей недели и как выстраивается процесс работы.
P.S.: Сорри за второй мозг. Этим термином очень любят пользоваться инфоцыгане от ИИ, чем уже сильно бесят. Но на самом деле эта концепция очень даже рабочая, особенно если ты работает с огромным количеством информации.
#контентменеджерское #ai_agents #второймозгконтентменеджера
🔥4
Второй мозг контент-менеджера. Часть 2. Четыре задачи из моей недели
Не откладываем в долгий ящик — продолжаем цикл. Год назад я описал свой день списком задач. По сути он не изменился, но у каждого дела появилась одна общая точка старта. Это сессия Claude Code, открытая внутри моего репозитория. Не потому, что я полюбил терминал. Это единственное место, где одновременно лежат память, правила и агенты: чат без репозитория забывает всё после закрытия вкладки, а репозиторий помнит, что я туда положил за полгода.
Покажу на четырёх реальных задачах, как я работаю с нейросетями. Можно сказать, что тут полностью реализован подход ai-first.
Пресс-релиз про технологический анонс. На входе: тема, бриф и имя спикера для цитаты. Я пишу в сессии «напиши пресс-релиз про ...». Начинается мастер: шаг за шагом, по одному вопросу. Тип релиза, продукт, потом выбор из трёх заголовков, трёх лидов, набора блоков. Я выбираю, как выбирал бы из вариантов коллеги. Дальше конвейер уходит в фон: ресёрчер собрал семь источников и сохранил конспект отдельным коммитом ещё до того, как его увидел автор. Фактчекер проверил четырнадцать утверждений: семь подтвердил, четыре уточнил, три не нашёл в публичных источниках, выдуманных не нашёл ни одного. Например, одна цифра вела на SEO-агрегатор, первоисточника не было — и в текст она не вошла. На выходе три версии релиза: общая, техническая и упрощённая техническая, и рядом отчёт, где написано, что проверено, а что осталось на согласование. Моя работа — согласовать то, что осталось.
Интервью для СМИ. На входе документ, в котором уже есть комментарии от разных сторон: заход от лица вендора, рыночный блок на подтверждение спикеру, никаких оценок про чужие платформы, у заказчика стилевой контракт без длинных тире и конструкций «не X, а Y». Раньше это был вечер правок руками и три переписки. Теперь я даю ссылку на документ, он импортируется в библиотеку как Markdown, а дальше говорю: «переработай по комментариям, образец канвы — вот это интервью из базы». Система берёт старое интервью как референс структуры, проходит комментарии, прогоняет финальную траст-редактуру. Идём согласовывать.
SEO-статья для блога. На входе документ с ТЗ: тема, ключи, структура. Я говорю: «напиши статью по этому ТЗ, работай автономно». Система сначала проверяет базу: у меня уже есть конспекты по теме, их она дополняет, а не собирает заново. Потом ресёрч, автор, фактчекер. И вот тут самое интересное: фактчекер снял из текста цифру, которая пришла из нашей же продуктовой фактуры, но публичного первоисточника у неё нет, а та публичная, что нашлась, относится к другому направлению. Заодно он заметил, что условия скидки в фактуре и на сайте расходятся. В статью ни то ни другое не вошло, но в отчёте появилась строка для продуктовой команды: сверить фактуру с сайтом. Траст-редактор внёс 26 правок и статья сохранена со статусом «на ревью». Идём согласовывать.
Обновление лендинга по SEO-ТЗ. На входе документ с тремя вкладками (анализ, структура, SEO) и текущая страница. Я говорю: «обнови лендинг баз данных по этому ТЗ». Режим обновления отличается от создания: структура страницы жёстко сохраняется, число блоков и предложений плюс-минус одно, на выходе таблица «было — стало» по каждому блоку. Редактор оценил черновик на 8 из 10, повторный круг не потребовался. Цифры в новых блоках траст-редактор пометил на перепроверку, фактчекер прошёл по ним точечно. В CMS я несу таблицу, а не текст: так тот, кто вносит правки на сайте, видит, что именно изменилось.
Что общего у этих четырёх задач. Я ни разу не писал текст с нуля и ни разу не искал факты сам. Моя работа сдвинулась в две точки: решения на входе (какой заголовок, какой угол, что считать источником) и приёмка на выходе (что взять на согласование и что из открытых вопросов нести людям на проверку). Всё между ними делает система, и всё между ними остаётся в репозитории: конспект, черновик, отчёт с трассой проверок. Поэтому следующая такая задача начнётся не с чистого листа, а с того, что уже найдено.
В следующем посте: про то, как у меня всё хранится и три вида памяти.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Не откладываем в долгий ящик — продолжаем цикл. Год назад я описал свой день списком задач. По сути он не изменился, но у каждого дела появилась одна общая точка старта. Это сессия Claude Code, открытая внутри моего репозитория. Не потому, что я полюбил терминал. Это единственное место, где одновременно лежат память, правила и агенты: чат без репозитория забывает всё после закрытия вкладки, а репозиторий помнит, что я туда положил за полгода.
Покажу на четырёх реальных задачах, как я работаю с нейросетями. Можно сказать, что тут полностью реализован подход ai-first.
Пресс-релиз про технологический анонс. На входе: тема, бриф и имя спикера для цитаты. Я пишу в сессии «напиши пресс-релиз про ...». Начинается мастер: шаг за шагом, по одному вопросу. Тип релиза, продукт, потом выбор из трёх заголовков, трёх лидов, набора блоков. Я выбираю, как выбирал бы из вариантов коллеги. Дальше конвейер уходит в фон: ресёрчер собрал семь источников и сохранил конспект отдельным коммитом ещё до того, как его увидел автор. Фактчекер проверил четырнадцать утверждений: семь подтвердил, четыре уточнил, три не нашёл в публичных источниках, выдуманных не нашёл ни одного. Например, одна цифра вела на SEO-агрегатор, первоисточника не было — и в текст она не вошла. На выходе три версии релиза: общая, техническая и упрощённая техническая, и рядом отчёт, где написано, что проверено, а что осталось на согласование. Моя работа — согласовать то, что осталось.
Интервью для СМИ. На входе документ, в котором уже есть комментарии от разных сторон: заход от лица вендора, рыночный блок на подтверждение спикеру, никаких оценок про чужие платформы, у заказчика стилевой контракт без длинных тире и конструкций «не X, а Y». Раньше это был вечер правок руками и три переписки. Теперь я даю ссылку на документ, он импортируется в библиотеку как Markdown, а дальше говорю: «переработай по комментариям, образец канвы — вот это интервью из базы». Система берёт старое интервью как референс структуры, проходит комментарии, прогоняет финальную траст-редактуру. Идём согласовывать.
SEO-статья для блога. На входе документ с ТЗ: тема, ключи, структура. Я говорю: «напиши статью по этому ТЗ, работай автономно». Система сначала проверяет базу: у меня уже есть конспекты по теме, их она дополняет, а не собирает заново. Потом ресёрч, автор, фактчекер. И вот тут самое интересное: фактчекер снял из текста цифру, которая пришла из нашей же продуктовой фактуры, но публичного первоисточника у неё нет, а та публичная, что нашлась, относится к другому направлению. Заодно он заметил, что условия скидки в фактуре и на сайте расходятся. В статью ни то ни другое не вошло, но в отчёте появилась строка для продуктовой команды: сверить фактуру с сайтом. Траст-редактор внёс 26 правок и статья сохранена со статусом «на ревью». Идём согласовывать.
Обновление лендинга по SEO-ТЗ. На входе документ с тремя вкладками (анализ, структура, SEO) и текущая страница. Я говорю: «обнови лендинг баз данных по этому ТЗ». Режим обновления отличается от создания: структура страницы жёстко сохраняется, число блоков и предложений плюс-минус одно, на выходе таблица «было — стало» по каждому блоку. Редактор оценил черновик на 8 из 10, повторный круг не потребовался. Цифры в новых блоках траст-редактор пометил на перепроверку, фактчекер прошёл по ним точечно. В CMS я несу таблицу, а не текст: так тот, кто вносит правки на сайте, видит, что именно изменилось.
Что общего у этих четырёх задач. Я ни разу не писал текст с нуля и ни разу не искал факты сам. Моя работа сдвинулась в две точки: решения на входе (какой заголовок, какой угол, что считать источником) и приёмка на выходе (что взять на согласование и что из открытых вопросов нести людям на проверку). Всё между ними делает система, и всё между ними остаётся в репозитории: конспект, черновик, отчёт с трассой проверок. Поэтому следующая такая задача начнётся не с чистого листа, а с того, что уже найдено.
В следующем посте: про то, как у меня всё хранится и три вида памяти.
#контентменеджерское #ai_agents #второймозгконтентменеджера
🔥1
Второй мозг контент-менеджера. Часть 3. Три памяти и одно правило
Продолжаем сериал. Год назад я хотел от базы контента теги, папки и графы. Сейчас база устроена иначе, потому что её главный читатель сменился: агенты читают её чаще, чем я. Этот пост о том, как она разделена и почему.
Типовая ошибка, через которую я прошёл сам: одно хранилище на всё. Минутки, черновики, выписки из отчётов, скриншоты конкурентов лежат вместе, и поиск по ним работает ровно до тех пор, пока человек помнит, что ищет. У агента такой памяти нет. Ему нужно, чтобы у каждой записи были заданы три вещи: срок жизни, источник доверия и событие, после которого запись надо перепроверить. По этим трём признакам записи и расходятся в три разных хранилища. Я называю их памятями, потому что они различаются так же, как долговременная и рабочая память у человека.
Долговременная память. Проверенные синтезы по доменам и атомарные карточки: один факт, одна цифра, одно возражение клиента, один блок, пригодный для цитирования ИИ-поиском. Сейчас это двадцать разделов и 351 карточка фактов. У карточки фиксированная шапка: утверждение, домен, дата проверки, срок годности, уровень доверия, источник с издателем и ссылкой, список процессов, где карточку разрешено применять. Доверие трёх уровней: 218 карточек с высоким, 115 со средним, 18 с низким. Низкое доверие у карточки означает ограниченный допуск. Пример из базы: вендорский опрос про защиту 5G-сетей, процитированный через обзор на arXiv, доверие низкое, применять разрешено только в брифинге спикера. Автор пресс-релиза эту карточку не получит, даже если тема совпадёт. Теги, которых я хотел год назад, в итоге работают именно так: это фильтр допуска для агента, а поиск для человека у них вторичен.
Рабочая память. Конспект, который ресёрчер собирает под один материал: источники, цифры, цитаты по узкой теме. Таких конспектов сейчас около ста семидесяти, из них, например, сорок под статьи и одиннадцать под пресс-релизы. У конспекта есть срок годности, статус и ссылка на материал, в который он вошёл, поэтому по любой статье можно восстановить, откуда взялась каждая цифра. Ключевое правило рабочей памяти касается момента до поиска. Ресёрчер обязан сначала проверить, что по теме уже собрано, и зафиксировать один из трёх исходов: использовать как есть, дополнить, пересобрать. Это экономит деньги на поиске и защищает от расхождений между статьями одной серии.
Память о других. Профили чужих продуктов: что заявляют, какие цифры публикуют, как называют компоненты. Выделена отдельно по двум причинам. Доверие к чужим заявлениям другое, и триггер обновления другой: профиль конкурента устаревает не по календарю, а после релиза, ребрендинга или смены цен.
Правило распределения умещается в одну строку. Широкое и проверенное идёт в долговременную память. Узкое, собранное под задачу, в рабочую. Всё про чужой продукт в память о других. Запись, которая не проходит ни по одному критерию, в репозиторий не попадает. Минутки встреч там не живут.
Между рабочей и долговременной памятью нужен переход, который год назад я не спроектировал. Если ресёрчер под одну статью нашёл цифру, полезную ещё десяти материалам, она должна превратиться в карточку с источником, сроком годности и допуском. Иначе она останется в конспекте, который через три месяца истечёт. Сейчас этот переход полуручной: система предлагает кандидатов, я подтверждаю каждого. Это самое слабое место схемы, потому что я регулярно откладываю подтверждение.
Два ограничения, о которых нужно знать, прежде чем повторять схему. Просроченных карточек в долговременной памяти сегодня ноль, и это пока ничего не доказывает: базе меньше года, первые сроки годности истекут в 2027, и только тогда станет видно, работает ли механизм перепроверки. И память о других останется пустой, пока у неё нет отдельного процесса наполнения, одними ресёрчами под статьи она не заполняется.
В следующем посте: как агент получает из трёх памятей короткую подборку под задачу вместо дампа всей базы, и почему этот отбор важнее самого хранилища.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Продолжаем сериал. Год назад я хотел от базы контента теги, папки и графы. Сейчас база устроена иначе, потому что её главный читатель сменился: агенты читают её чаще, чем я. Этот пост о том, как она разделена и почему.
Типовая ошибка, через которую я прошёл сам: одно хранилище на всё. Минутки, черновики, выписки из отчётов, скриншоты конкурентов лежат вместе, и поиск по ним работает ровно до тех пор, пока человек помнит, что ищет. У агента такой памяти нет. Ему нужно, чтобы у каждой записи были заданы три вещи: срок жизни, источник доверия и событие, после которого запись надо перепроверить. По этим трём признакам записи и расходятся в три разных хранилища. Я называю их памятями, потому что они различаются так же, как долговременная и рабочая память у человека.
Долговременная память. Проверенные синтезы по доменам и атомарные карточки: один факт, одна цифра, одно возражение клиента, один блок, пригодный для цитирования ИИ-поиском. Сейчас это двадцать разделов и 351 карточка фактов. У карточки фиксированная шапка: утверждение, домен, дата проверки, срок годности, уровень доверия, источник с издателем и ссылкой, список процессов, где карточку разрешено применять. Доверие трёх уровней: 218 карточек с высоким, 115 со средним, 18 с низким. Низкое доверие у карточки означает ограниченный допуск. Пример из базы: вендорский опрос про защиту 5G-сетей, процитированный через обзор на arXiv, доверие низкое, применять разрешено только в брифинге спикера. Автор пресс-релиза эту карточку не получит, даже если тема совпадёт. Теги, которых я хотел год назад, в итоге работают именно так: это фильтр допуска для агента, а поиск для человека у них вторичен.
Рабочая память. Конспект, который ресёрчер собирает под один материал: источники, цифры, цитаты по узкой теме. Таких конспектов сейчас около ста семидесяти, из них, например, сорок под статьи и одиннадцать под пресс-релизы. У конспекта есть срок годности, статус и ссылка на материал, в который он вошёл, поэтому по любой статье можно восстановить, откуда взялась каждая цифра. Ключевое правило рабочей памяти касается момента до поиска. Ресёрчер обязан сначала проверить, что по теме уже собрано, и зафиксировать один из трёх исходов: использовать как есть, дополнить, пересобрать. Это экономит деньги на поиске и защищает от расхождений между статьями одной серии.
Память о других. Профили чужих продуктов: что заявляют, какие цифры публикуют, как называют компоненты. Выделена отдельно по двум причинам. Доверие к чужим заявлениям другое, и триггер обновления другой: профиль конкурента устаревает не по календарю, а после релиза, ребрендинга или смены цен.
Правило распределения умещается в одну строку. Широкое и проверенное идёт в долговременную память. Узкое, собранное под задачу, в рабочую. Всё про чужой продукт в память о других. Запись, которая не проходит ни по одному критерию, в репозиторий не попадает. Минутки встреч там не живут.
Между рабочей и долговременной памятью нужен переход, который год назад я не спроектировал. Если ресёрчер под одну статью нашёл цифру, полезную ещё десяти материалам, она должна превратиться в карточку с источником, сроком годности и допуском. Иначе она останется в конспекте, который через три месяца истечёт. Сейчас этот переход полуручной: система предлагает кандидатов, я подтверждаю каждого. Это самое слабое место схемы, потому что я регулярно откладываю подтверждение.
Два ограничения, о которых нужно знать, прежде чем повторять схему. Просроченных карточек в долговременной памяти сегодня ноль, и это пока ничего не доказывает: базе меньше года, первые сроки годности истекут в 2027, и только тогда станет видно, работает ли механизм перепроверки. И память о других останется пустой, пока у неё нет отдельного процесса наполнения, одними ресёрчами под статьи она не заполняется.
В следующем посте: как агент получает из трёх памятей короткую подборку под задачу вместо дампа всей базы, и почему этот отбор важнее самого хранилища.
#контентменеджерское #ai_agents #второймозгконтентменеджера
👍1🤯1
Неприятный Левашов сейчас будет. Перед продолжением серии ответ на частый вопрос: «получается, ты теперь всё пишешь нейронкой?». Задают с интонацией, будто поймали на списывании в школе. Зае...
Отвечаю: да, практически всё. И в конце 2026 года контентщик, который работает иначе, уже безнадёжно отстал, устарел.
Во-первых, время. Например, лонгрид для блога на 29 000 знаков — это неделя работы руками: два дня на ресёрч, два на текст, день на фактчек и редактуру, и это если автор уже в теме. Через конвейер: 19 минут работы агентов в пять стадий. Плюс час моего времени на ТЗ и приёмку. Человек, который продолжает тратить на такую статью неделю, тратит деньги компании, которая могла получить за них пять статей и не получить ни одной непроверенной цифры. Компания, которая держит большую редакцию под блог, просто бездарно расходует бюджет, которого и так сейчас у всех немного.
Во-вторых, про «личный подход» и «авторские тексты». Это самая дорогая ложь на рынке контента. Работодатель платит за точность, скорость и за то, что текст не придётся переписывать. Человек, который продаёт ему вместо этого «авторский стиль», продаёт собственную неспособность организовать проверку своей работы. Он берёт деньги за то, что в 2026 году делается с помощью ИИ в десять раз быстрее и чище, и называет свою медлительность ремеслом. Это не ремесло, это обман в красивой обёртке. «Но машина не заменит живого автора». Живой автор и нужен там, где принимаются решения: какой угол брать, что говорить, чего не говорить, кому верить при конфликте источников. За это компании будут платить много. За набор букв, даже очень красивый, сейчас платить уже довольно глупо. Набор букв делает машина, и в понедельник утром она делает это лучше любого из нас.
В третьих... хотя пожалуй хватит, меня уже сейчас возненавидит большинство авторов и редакторов.
Но, соррян, если единственный ваш аргумент за качество текста звучит как «я написал его сам без нейронки», то это аргумент против вас. Рынок уже понял, работодатели, если уже не разобрались, поймут в следующем бюджетном цикле. Если вы до сих пор думаете, что нейронкам можно доверить только низкокачественный контент, то вы застряли в 2025 году и вас уже обгоняют. Заходите, расскажу как сделать ИИ-редакцию. Дорого, эффективно. 😈
#контентменеджерское
Отвечаю: да, практически всё. И в конце 2026 года контентщик, который работает иначе, уже безнадёжно отстал, устарел.
Во-первых, время. Например, лонгрид для блога на 29 000 знаков — это неделя работы руками: два дня на ресёрч, два на текст, день на фактчек и редактуру, и это если автор уже в теме. Через конвейер: 19 минут работы агентов в пять стадий. Плюс час моего времени на ТЗ и приёмку. Человек, который продолжает тратить на такую статью неделю, тратит деньги компании, которая могла получить за них пять статей и не получить ни одной непроверенной цифры. Компания, которая держит большую редакцию под блог, просто бездарно расходует бюджет, которого и так сейчас у всех немного.
Во-вторых, про «личный подход» и «авторские тексты». Это самая дорогая ложь на рынке контента. Работодатель платит за точность, скорость и за то, что текст не придётся переписывать. Человек, который продаёт ему вместо этого «авторский стиль», продаёт собственную неспособность организовать проверку своей работы. Он берёт деньги за то, что в 2026 году делается с помощью ИИ в десять раз быстрее и чище, и называет свою медлительность ремеслом. Это не ремесло, это обман в красивой обёртке. «Но машина не заменит живого автора». Живой автор и нужен там, где принимаются решения: какой угол брать, что говорить, чего не говорить, кому верить при конфликте источников. За это компании будут платить много. За набор букв, даже очень красивый, сейчас платить уже довольно глупо. Набор букв делает машина, и в понедельник утром она делает это лучше любого из нас.
В третьих... хотя пожалуй хватит, меня уже сейчас возненавидит большинство авторов и редакторов.
Но, соррян, если единственный ваш аргумент за качество текста звучит как «я написал его сам без нейронки», то это аргумент против вас. Рынок уже понял, работодатели, если уже не разобрались, поймут в следующем бюджетном цикле. Если вы до сих пор думаете, что нейронкам можно доверить только низкокачественный контент, то вы застряли в 2025 году и вас уже обгоняют. Заходите, расскажу как сделать ИИ-редакцию. Дорого, эффективно. 😈
#контентменеджерское
1❤4👍2🔥2🤬2🆒1😡1
Второй мозг контент-менеджера. Часть 4. Библиотекарь важнее библиотеки
В прошлом посте я разложил базу на три памяти. Этого недостаточно. За год в репозитории накопились сотни файлов, и агент, который перед статьёй читает всё подряд, работает хуже агента, который не читает ничего: контекст забивается, старые цифры смешиваются с новыми, а автор берёт то, что попалось первым. Ценность базы определяется тем, что из неё попадёт автору в руки за пять минут до работы. Эту часть системы я называю библиотекарем.
Устроен он в четыре слоя:
6️⃣ Каталог. Из шапок всех файлов трёх памятей собирается один плоский индекс: тема, домен, теги, тип, срок годности, допуск. Это указатель, не доказательство. Доказательство лежит в самой карточке и её источнике, каталог лишь говорит, где искать.
2️⃣ Поиск с объяснением. Например, запрос под статью про платформы данных вернул десять записей. Первой с баллом 20,5 идёт синтез по инженерии данных и lakehouse из долговременной памяти. Второй — конспект ресёрча августа про переход на Lakehouse и TCO. Третьей — досье на Arenadata с пометкой «требует обновления». Дальше карточки фактов со своим уровнем доверия. У каждой записи написано, за что она попала в выдачу: совпадение в названии, в тегах, через синоним. Это важно для разбора: когда автор взял странный источник, я вижу, по какому признаку библиотекарь его подсунул.
3️⃣ Маршрутная карта. У каждого из 25 процессов свой плейбук: какие слои базы подавать в первую очередь, какие во вторую, что запрещено без отдельной проверки. Например, для SEO-статьи первыми идут карточки фактов, блоки для цитирования ИИ-поиском, позиционирование продукта и списки источников. Во вторую очередь досье конкурентов и рабочие конспекты. Без проверки запрещены просроченные карточки, непубличные кейсы и вендорские оценки с низким доверием. Там же контракт выдачи: пять записей в шорт-лист, три карточки фактов, список просроченного и список пробелов обязательны.
4️⃣ Коробка. На выходе агент получает компактный объект вместо дампа. Шорт-лист синтезов. Карточки фактов, отфильтрованные по допуску именно этого процесса. Публичные кейсы. Источники для мониторинга. Отдельно просроченное: оно видно, но использовать его как факт нельзя. И поле «пробелы». Пустой шорт-лист означает, что нужен ресёрч. Контракт требует карточки, а свежих нет: значит, цифры в этой теме фактчекер проверяет особенно внимательно. Пробелы и есть самая полезная часть коробки, потому что они превращают пустую выдачу из базы в задачу.
Поверх коробки стоят два предохранителя.
➡️ Первый: перед веб-поиском ресёрчер обязан зафиксировать, что он сделал с базой. Три исхода: взял как есть, дополнил, пересобрал. Исход попадает тегом в отчёт, и по отчётам видно, сколько раз за месяц система ходила в веб за тем, что уже лежало дома.
➡️ Второй: хук на самом веб-поиске. Перед тем как запрос уйдёт в сеть, он сверяется с кэшем прошлых поисков, и повторный запрос по той же формулировке в сеть не уходит.
Почему я считаю эту часть важнее хранилища. База без библиотекаря остаётся папкой с файлами, сколько бы карточек в ней ни лежало. Библиотекарь решает, что увидит автор, значит, что попадёт в текст. Он же решает, чего автор не увидит: просроченную цифру, оценку с низким доверием, кейс, который нельзя называть. Вторая функция важнее первой. Ошибку от незнания фактчекер поймает. Ошибку от уверенного использования устаревшего факта поймать сложнее, потому что цифра выглядит обоснованной и у неё есть источник.
Некоторые минусы моей системы. Ранжирование работает по тегам, названиям и словарю синонимов, семантического поиска нет, поэтому карточка с неточным тегом для библиотекаря невидима. Эвристика пробелов простая: пустой список или отсутствие свежих карточек. И маршрутные карты я писал сам под каждый процесс; когда появляется новый тип материала, первый месяц он живёт без карты и получает выдачу по общему правилу.
В следующем посте: что происходит с картой знаний, когда у фактов истекает срок годности, и почему я спроектировал старение до того, как оно началось.
P.S.: На схеме понятнее?
#второймозгконтентменеджера
В прошлом посте я разложил базу на три памяти. Этого недостаточно. За год в репозитории накопились сотни файлов, и агент, который перед статьёй читает всё подряд, работает хуже агента, который не читает ничего: контекст забивается, старые цифры смешиваются с новыми, а автор берёт то, что попалось первым. Ценность базы определяется тем, что из неё попадёт автору в руки за пять минут до работы. Эту часть системы я называю библиотекарем.
Устроен он в четыре слоя:
Поверх коробки стоят два предохранителя.
Почему я считаю эту часть важнее хранилища. База без библиотекаря остаётся папкой с файлами, сколько бы карточек в ней ни лежало. Библиотекарь решает, что увидит автор, значит, что попадёт в текст. Он же решает, чего автор не увидит: просроченную цифру, оценку с низким доверием, кейс, который нельзя называть. Вторая функция важнее первой. Ошибку от незнания фактчекер поймает. Ошибку от уверенного использования устаревшего факта поймать сложнее, потому что цифра выглядит обоснованной и у неё есть источник.
Некоторые минусы моей системы. Ранжирование работает по тегам, названиям и словарю синонимов, семантического поиска нет, поэтому карточка с неточным тегом для библиотекаря невидима. Эвристика пробелов простая: пустой список или отсутствие свежих карточек. И маршрутные карты я писал сам под каждый процесс; когда появляется новый тип материала, первый месяц он живёт без карты и получает выдачу по общему правилу.
В следующем посте: что происходит с картой знаний, когда у фактов истекает срок годности, и почему я спроектировал старение до того, как оно началось.
P.S.: На схеме понятнее?
#второймозгконтентменеджера
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥2🤔1🤯1
С процессом ремонта в квартире с серого ключа не справится ни одна нейросеть. Вариативность этого процесса кажется бесконечной.
🙏1
Второй мозг контент-менеджера. Часть 5. Память стареет
Последняя душная часть про память. А далее перейдём к более интересным механикам и лайфхакам.
Приведу следующий пример: цифра трёхлетней давности существует, находится в карточке базы и выглядит обоснованной. Фактчечек считает его корректной и не проверяет. И цифра попадает в текст, проходя все проверки.
Поэтому у меня появилось старение памяти. Ниже четыре механизма, которые это делают, в порядке срабатывания.
1. Срок задаётся при записи и зависит от типа данных. У каждой записи в базе три поля: дата проверки, срок годности, уровень доверия. Срок не единый. Правило свежести фиксирует допустимую давность по типу цифры.
2. Истёкший срок меняет маршрут записи, а не удаляет её. Три реакции на трёх этапах.
➡️ До ресёрча. Библиотекарь при сборке коробки для агента выносит просроченные записи в отдельный список. Они видны, их нельзя подать как факт, а отсутствие свежих записей по теме превращается в пункт «пробелы: цифры проверять фактчекеру».
➡️ После автора. Фактчекер делает повторную проверку по типу данных: запрос по теме с текущим годом, поиск первоисточника, замена цифры с новой датой или снятие. Формулировка «по данным такого-то года» допустима только когда новее данных не существует, и это должно быть видно в конспекте.
➡️ После публикации. Детектор корпуса проходит по опубликованным материалам и считает три признака: возраст старше 365 дней, устаревшие годы в фактах, незакрытые метки «нужен фактчек». Первые два дают кандидата на обновление, третий поднимает приоритет.
3. Волны истечения ловятся заранее. Пакетный импорт получает одну дату на всю полку, и через год вся полка истекает одним днём. Окно предупреждения в 30 дней такую волну не показывает: вчера ноль просроченных, завтра полсотни. Поэтому индекс свежести считает волны отдельно: двадцать и больше файлов с одной датой в ближайшие 60 дней дают строку в плане ревизии, и ревизию полки планируют за месяц, а не по факту.
4. Свежесть считается по всем трём памятям. Срок у досье обязателен, слой входит в индекс, в гейт и в расчёт волн, а ревизия досье проходит по правилу «было → стало»: старая цифра остаётся в тексте рядом с новой, с датой и источником.
И про проблему, которую я сейчас исправляю. План ревизии собирается скриптом в один список: просроченное, истекающее за 30 дней, волны. Он должен был приходить задачей в репозиторий раз в неделю. Но расписание было отключено: задачи приходили, я их не отрабатывал, невыполненные копились. Ревизии идут кампаниями раз в несколько недель вместо еженедельной рутины.
Поэтому срок годности работает ровно настолько, насколько есть процесс реакции на его истечение. И этот процесс нужно настроить.
В следующем посте про чистый контекст. Я уже много рассказывал, почему фактчекер не должен видеть, как думал автор и тд.. В новых материала постараюсь углубиться в тему. Например, рассказать, что может случиться, когда система заглядывает через плечо субагентами и подсказывает им. И как с этим бороться.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Последняя душная часть про память. А далее перейдём к более интересным механикам и лайфхакам.
Приведу следующий пример: цифра трёхлетней давности существует, находится в карточке базы и выглядит обоснованной. Фактчечек считает его корректной и не проверяет. И цифра попадает в текст, проходя все проверки.
Поэтому у меня появилось старение памяти. Ниже четыре механизма, которые это делают, в порядке срабатывания.
1. Срок задаётся при записи и зависит от типа данных. У каждой записи в базе три поля: дата проверки, срок годности, уровень доверия. Срок не единый. Правило свежести фиксирует допустимую давность по типу цифры.
2. Истёкший срок меняет маршрут записи, а не удаляет её. Три реакции на трёх этапах.
3. Волны истечения ловятся заранее. Пакетный импорт получает одну дату на всю полку, и через год вся полка истекает одним днём. Окно предупреждения в 30 дней такую волну не показывает: вчера ноль просроченных, завтра полсотни. Поэтому индекс свежести считает волны отдельно: двадцать и больше файлов с одной датой в ближайшие 60 дней дают строку в плане ревизии, и ревизию полки планируют за месяц, а не по факту.
4. Свежесть считается по всем трём памятям. Срок у досье обязателен, слой входит в индекс, в гейт и в расчёт волн, а ревизия досье проходит по правилу «было → стало»: старая цифра остаётся в тексте рядом с новой, с датой и источником.
И про проблему, которую я сейчас исправляю. План ревизии собирается скриптом в один список: просроченное, истекающее за 30 дней, волны. Он должен был приходить задачей в репозиторий раз в неделю. Но расписание было отключено: задачи приходили, я их не отрабатывал, невыполненные копились. Ревизии идут кампаниями раз в несколько недель вместо еженедельной рутины.
Поэтому срок годности работает ровно настолько, насколько есть процесс реакции на его истечение. И этот процесс нужно настроить.
В следующем посте про чистый контекст. Я уже много рассказывал, почему фактчекер не должен видеть, как думал автор и тд.. В новых материала постараюсь углубиться в тему. Например, рассказать, что может случиться, когда система заглядывает через плечо субагентами и подсказывает им. И как с этим бороться.
#контентменеджерское #ai_agents #второймозгконтентменеджера
Please open Telegram to view this post
VIEW IN TELEGRAM
🤯2
Давайте вторую часть Неприятного Левашова. Зачем городить такую сложную систему? Я про это уже не раз писал, но в контексте серии публикаций про второй мозг контент-менеджера не грех повторить. Заранее извиняюсь за мат.🙈
Какая была идея: дайте редакторам нейронку получше, залейте в проект контекст, быстро получайте тексты. Звучит, конечно, логично, но работает на очень коротких отрезках по очень несложным темам. То, что пишет модель, проверить может только тот, кто и сам бы написал не хуже. Потому что ошибки модели не выглядят ошибками, они выглядят как хороший текст.
Разберу, что стоит за каждым из этих трёх слов и почему вы, внедрив клод в редакции, не сделали ещё даже первого шага к нормальному процессу.
Отсюда арифметика, которую не любят считать. Схема «один сеньор и пять джунов с моделью» производит в пять раз больше гладких текстов с уверенными ошибками, которые сеньор физически не успевает читать. Ошибки уходят к читателю под именем компании. Экономия на фонде оплаты труда, счёт приходит репутацией, и приходит на другой отдел, поэтому в отчёте об экономии его нет.
ИИ-редакция — это три вещи, и доступ к модели из них самая дешёвая и самая быстрая. Источники правды с датой, доверием, допуском и сроком. Проверка, которая не доверяет ни автору, ни фактчекеру, ни собственному контексту и частично живёт вне модели. И человек на приёмке, который сам написал бы не хуже, просто за неделю вместо часа. Первые две без третьей не работают, третья без первых двух выгорает за квартал.
И, возвращаясь к началу, почему так сложно то? Потому что я честно не придумал, как это сделать легко. Последним моделям не нужно уже много правил, они замечательно пишут по верхнеуровневой редполитике. И вся так жепиздят . Поэтому до момента, когда нас всех заменит нейросеть, придётся ещё неплохо так над этим поработать.
А теперь дописываю про чистый контекст.
Какая была идея: дайте редакторам нейронку получше, залейте в проект контекст, быстро получайте тексты. Звучит, конечно, логично, но работает на очень коротких отрезках по очень несложным темам. То, что пишет модель, проверить может только тот, кто и сам бы написал не хуже. Потому что ошибки модели не выглядят ошибками, они выглядят как хороший текст.
То есть задача сделать ИИ-редакцию не сводиться только к раздаче доступов к ИИ и настройке необходимых скиллов. Необходимо дать источники правды, настроить системы проверки качества и достоверности.
Разберу, что стоит за каждым из этих трёх слов и почему вы, внедрив клод в редакции, не сделали ещё даже первого шага к нормальному процессу.
Источник правды. Контекст проекта — это свалка текста без даты, без первоисточника и без владельца. Через полгода в нём три версии одной цифры, и модель уверенно берёт ту, что лучше ложится в абзац. И этот пиздец выглядит очень правдоподобно. И даже гуглится. Источник правды здоровой ИИ-редакции отличается четырьмя полями: когда проверено, откуда взято со ссылкой, насколько доверяем и где можно использовать. Последнее поле важнее всех: вендорскую оценку можно сказать со сцены и нельзя писать в пресс-релиз, и модель эту разницу не знает, пока ей не запретили.
Проверка. Модель в том же окне проверяет свой текст, как автор вычитывает свою статью: находит опечатки и соглашается с каждым тезисом. Это не проверка, это самоуспокоение за токены. Проверка начинается, когда проверяющий получает голый текст без рассуждений автора, ищет первоисточник заново, а не подтверждает найденный, и не имеет права трогать цифры, ссылки и цитаты, только помечать. И даже такой проверяющий пропустит правдоподобное: цифра из вашей же презентации, устаревшая редакция стандарта с убедительным объяснением, дата с правильным форматом и неправильным годом. Эти вещи ловятся не моделью, а детекторами снаружи сессии: сверка с каноном продукта, сноска без первоисточника как блокирующий сигнал, проверка редакции на дату публикации. Детекторам похуй, что модель была уверена.
Оценка качества. Чтобы сказать «хорошо» или «хуйня», нужна шкала. У редактора с десятью годами она в голове: он знает, как выглядит первоисточник, чем отличается перепечатка, где в тексте дырка, которую автор залил общими словами, и почему абзац звучит как модель. У джуна шкалы нет. Он видит гладкий текст с правильно оформленными сносками, и для него это и есть качество. Галлюцинация и факт выглядят для него одинаково не потому, что он тупой, а потому что отличие лежит в знании предмета, которого у него ещё нет. Нейронка это знание не даёт, она его требует.
Отсюда арифметика, которую не любят считать. Схема «один сеньор и пять джунов с моделью» производит в пять раз больше гладких текстов с уверенными ошибками, которые сеньор физически не успевает читать. Ошибки уходят к читателю под именем компании. Экономия на фонде оплаты труда, счёт приходит репутацией, и приходит на другой отдел, поэтому в отчёте об экономии его нет.
ИИ-редакция — это три вещи, и доступ к модели из них самая дешёвая и самая быстрая. Источники правды с датой, доверием, допуском и сроком. Проверка, которая не доверяет ни автору, ни фактчекеру, ни собственному контексту и частично живёт вне модели. И человек на приёмке, который сам написал бы не хуже, просто за неделю вместо часа. Первые две без третьей не работают, третья без первых двух выгорает за квартал.
И, возвращаясь к началу, почему так сложно то? Потому что я честно не придумал, как это сделать легко. Последним моделям не нужно уже много правил, они замечательно пишут по верхнеуровневой редполитике. И вся так же
А теперь дописываю про чистый контекст.
🔥2
This media is not supported in your browser
VIEW IN TELEGRAM
Я как-нибудь в декабре сяду и напишу, что думаю о ремонте квартиры. И как это перекликается с работой в ИТ и контенте.
А пока там терминальная стадия уже. И поеду я после работы стеллаж покрашу.
А пока там терминальная стадия уже. И поеду я после работы стеллаж покрашу.
😁1
Пять способов не захламлять контекст. Разбор гайда LangChain
Подготавливая свои материалы, нашёл концептуальный гайд от LangChain про то, как агенты помнят, не держа всё в голове. Статья полезная, хотя и написана наполовину как витрина их собственного харнесса. Перескажу суть и скажу, что из этого реально работает у меня.
Проблема простая. Чем дольше работает агент, тем больше он в себе тащит: инструкции, выдачу инструментов, куски файлов, свои прошлые ответы. В какой-то момент он начинает тупеть — не ломаться, а именно тупеть, терять нить и путать детали. Метафора в статье хорошая: как подготовка к экзамену в ночь перед ним, чем больше учишь, тем сильнее вылетают первые главы.
Что предлагается: не пускать лишнее внутрь и разбираться с тем, что уже внутри.
Не пускать
Выгружать большое в файлы. Агент дёрнул инструмент, тот вернул простыню на тысячи строк. В контекст кладётся не простыня, а её начало, конец и путь к файлу. Понадобится деталь — дочитает. Ключевое отличие от обрезки: обрезка теряет данные навсегда, выгрузка оставляет их доступными. Разница кажется мелкой, пока агент не упирается в то, что нужная строка была в середине отрезанного.
Грузить инструкции по требованию. Вместо того чтобы держать все инструкции в системном промпте, агент видит только список названий с однострочным описанием, а полную инструкцию подтягивает, когда решил, что она нужна. У них точная формулировка: десять скиллов стоят примерно столько же контекста, сколько десять однострочников.
Это, кстати, второй раз за месяц, когда я вижу ровно эту архитектуру. В скилле для диаграмм, про который я писал, — то же самое: тонкий индекс плюс референсы по запросу. Похоже, паттерн устоялся.
Выносить шумную работу в субагента. Если вы заранее знаете, что задача грязная — обойти двадцать страниц, перелопатить выгрузку, — её отдают отдельному агенту с собственным контекстом. Назад приходит только результат. В их примере субагент читает полный отчёт у себя и возвращает три пункта; главный агент сырых данных вообще не видит. Бонус: такие задачи мелкие, их можно гнать параллельно и на модели подешевле.
Разбираться с тем, что уже внутри
Сжимать историю. Когда окно заполнено процентов на восемьдесят пять, старые сообщения схлопываются в сводку, свежие остаются как есть. Два важных условия: оригиналы при этом пишутся в файл, чтобы можно было вернуться, и процесс цикличный — следующая сводка включает предыдущую.
Полезная диагностика оттуда же. Выгрузка файлов срезает резкие скачки, сжатие истории гасит медленный подъём. Это разные болезни. Если у вас контекст распухает рывками — лечится первым. Если ползёт вверх ровно — вторым. Я до этого валил в одну кучу и чинил не тем.
Память между запусками. Отдельный markdown-файл, который читается в начале прогона и обновляется, когда агент узнал что-то, что стоит сохранить. Пример у них ровно редакторский: сказали «в саммари буллеты, а не абзацы» — без памяти будете повторять это каждую неделю.
Что в статье главное
Для меня — не пять техник, а тезис про владение памятью. Память агента у них лежит обычным файлом в вашем хранилище, а не внутри сервиса провайдера. Поэтому модель можно сменить, а всё накопленное останется.
Для контентных команд это не техническая деталь, а вопрос собственности. Ваш редстандарт, ваши правила, ваши накопленные исключения — где они физически лежат? Если markdown-файлом в репозитории, вы переживёте смену любого инструмента. Если внутри чужого продукта — нет.
И что меня смущает
В статье ноль цифр. Деградация объявлена, механизм описан, но насколько именно падает качество и насколько помогают эти пять приёмов — ни слова. Для компании, которая продаёт платформу для наблюдаемости и оценки агентов, отсутствие замеров странное.
Пороги — восемьдесят пять процентов, двадцать тысяч токенов — поданы как данность, откуда взялись, не объясняется. Там же сказано, что их надо настраивать под задачу, а как понять, что текущие не годятся, — нет.
И главное умолчание. Все пять приёмов — это обмен информации на место. Сводка решает, что считать важным. Превью решает, какие строки показать. Субагент решает, какие три пункта вернуть. Каждое из этих решений принимает модель, и каждое может выбросить не то. Сказано, что всё восстановимо, но восстановить можно, только если агент догадается, что ему чего-то не хватает. А он не догадается: он не знает, что выбросил.
Это ровно тот класс ошибок, который не ловится на демо и вылезает на третьем месяце работы. Держите в голове, когда будете это всё внедрять.
Почитать можно тут: langchain.com/blog/context-engineering-deep-agents-remember
#ai_agents
Подготавливая свои материалы, нашёл концептуальный гайд от LangChain про то, как агенты помнят, не держа всё в голове. Статья полезная, хотя и написана наполовину как витрина их собственного харнесса. Перескажу суть и скажу, что из этого реально работает у меня.
Проблема простая. Чем дольше работает агент, тем больше он в себе тащит: инструкции, выдачу инструментов, куски файлов, свои прошлые ответы. В какой-то момент он начинает тупеть — не ломаться, а именно тупеть, терять нить и путать детали. Метафора в статье хорошая: как подготовка к экзамену в ночь перед ним, чем больше учишь, тем сильнее вылетают первые главы.
Что предлагается: не пускать лишнее внутрь и разбираться с тем, что уже внутри.
Не пускать
Выгружать большое в файлы. Агент дёрнул инструмент, тот вернул простыню на тысячи строк. В контекст кладётся не простыня, а её начало, конец и путь к файлу. Понадобится деталь — дочитает. Ключевое отличие от обрезки: обрезка теряет данные навсегда, выгрузка оставляет их доступными. Разница кажется мелкой, пока агент не упирается в то, что нужная строка была в середине отрезанного.
Грузить инструкции по требованию. Вместо того чтобы держать все инструкции в системном промпте, агент видит только список названий с однострочным описанием, а полную инструкцию подтягивает, когда решил, что она нужна. У них точная формулировка: десять скиллов стоят примерно столько же контекста, сколько десять однострочников.
Это, кстати, второй раз за месяц, когда я вижу ровно эту архитектуру. В скилле для диаграмм, про который я писал, — то же самое: тонкий индекс плюс референсы по запросу. Похоже, паттерн устоялся.
Выносить шумную работу в субагента. Если вы заранее знаете, что задача грязная — обойти двадцать страниц, перелопатить выгрузку, — её отдают отдельному агенту с собственным контекстом. Назад приходит только результат. В их примере субагент читает полный отчёт у себя и возвращает три пункта; главный агент сырых данных вообще не видит. Бонус: такие задачи мелкие, их можно гнать параллельно и на модели подешевле.
Разбираться с тем, что уже внутри
Сжимать историю. Когда окно заполнено процентов на восемьдесят пять, старые сообщения схлопываются в сводку, свежие остаются как есть. Два важных условия: оригиналы при этом пишутся в файл, чтобы можно было вернуться, и процесс цикличный — следующая сводка включает предыдущую.
Полезная диагностика оттуда же. Выгрузка файлов срезает резкие скачки, сжатие истории гасит медленный подъём. Это разные болезни. Если у вас контекст распухает рывками — лечится первым. Если ползёт вверх ровно — вторым. Я до этого валил в одну кучу и чинил не тем.
Память между запусками. Отдельный markdown-файл, который читается в начале прогона и обновляется, когда агент узнал что-то, что стоит сохранить. Пример у них ровно редакторский: сказали «в саммари буллеты, а не абзацы» — без памяти будете повторять это каждую неделю.
Что в статье главное
Для меня — не пять техник, а тезис про владение памятью. Память агента у них лежит обычным файлом в вашем хранилище, а не внутри сервиса провайдера. Поэтому модель можно сменить, а всё накопленное останется.
Для контентных команд это не техническая деталь, а вопрос собственности. Ваш редстандарт, ваши правила, ваши накопленные исключения — где они физически лежат? Если markdown-файлом в репозитории, вы переживёте смену любого инструмента. Если внутри чужого продукта — нет.
И что меня смущает
В статье ноль цифр. Деградация объявлена, механизм описан, но насколько именно падает качество и насколько помогают эти пять приёмов — ни слова. Для компании, которая продаёт платформу для наблюдаемости и оценки агентов, отсутствие замеров странное.
Пороги — восемьдесят пять процентов, двадцать тысяч токенов — поданы как данность, откуда взялись, не объясняется. Там же сказано, что их надо настраивать под задачу, а как понять, что текущие не годятся, — нет.
И главное умолчание. Все пять приёмов — это обмен информации на место. Сводка решает, что считать важным. Превью решает, какие строки показать. Субагент решает, какие три пункта вернуть. Каждое из этих решений принимает модель, и каждое может выбросить не то. Сказано, что всё восстановимо, но восстановить можно, только если агент догадается, что ему чего-то не хватает. А он не догадается: он не знает, что выбросил.
Это ровно тот класс ошибок, который не ловится на демо и вылезает на третьем месяце работы. Держите в голове, когда будете это всё внедрять.
Почитать можно тут: langchain.com/blog/context-engineering-deep-agents-remember
#ai_agents
🔥2
Anti-Malware собрали карту российского рынка ИИ-агентов: семь корпоративных платформ, фреймворки, нормативная база, риски. Полезно хотя бы для того, чтобы увидеть масштаб.
#ai_agents
#ai_agents
👍1