Контекст, агенты, эвалы

Промпт кончился, начался контекст

Первая волна работы с моделями была про промпт: как сформулировать инструкцию, чтобы разовая задача - классификация, генерация текста - решалась лучше. Задача одноходовая, формулировка одна, ее шлифуют и забывают.

С агентами так не получается. Агент - это, по определению Anthropic, модель, которая в цикле сама пользуется инструментами. На каждом витке цикла появляются новые результаты вызовов, новые куски файлов, новые сообщения. Вселенная возможной информации растет сама, и вопрос смещается: не «как написать инструкцию», а «какой набор токенов должен лежать перед моделью именно сейчас».

Anthropic называет это контекст-инжинирингом и определяет как набор приемов курирования и поддержания оптимального множества токенов во время работы модели. В контекст входит все: системная инструкция, описания инструментов, данные из MCP, подтянутые документы, история переписки.

Разница практическая. Промпт-инжиниринг - разовое действие. Контекст-инжиниринг - цикл: отбор происходит заново перед каждым обращением к модели. И отвечает за этот отбор не модель, а тот, кто собирает систему.

Почему длинное окно не спасает

Есть соблазн считать, что окно на миллион токенов снимает вопрос: клади все, модель разберется. Данные говорят иначе. По мере роста числа токенов способность модели точно вспомнить информацию из контекста падает. Эффект есть у всех моделей, отличается только крутизна спада.

Причина архитектурная. Трансформер строит связи «каждый токен с каждым»: для n токенов это n² пар. Чем длиннее контекст, тем тоньше размазано внимание по этим парам. Добавьте то, что обучающие тексты в массе короче: у модели просто меньше опыта и меньше специализированных параметров под зависимости длиной во весь контекст.

Важная оговорка, которую часто теряют в пересказах: это градиент, а не обрыв. Модель на длинном контексте остается сильной, но точность извлечения фактов и рассуждений на большую дистанцию снижается против той же работы на коротком.

Отсюда рабочая метафора - бюджет внимания. Как оперативная память у человека: каждый новый токен тратит долю из конечного запаса. Значит, к токенам надо относиться как к деньгам, а не как к складу.

Правильная высота системного промпта

Главный принцип сформулирован у Anthropic одной фразой: хороший контекст - это минимально возможный набор токенов с высоким сигналом, который максимизирует вероятность нужного исхода. Все дальнейшее - следствия.

У системного промпта две крайности, и обе плохи. Первая - слишком низкая высота: жесткая хрупкая логика, зашитая прямо в текст, ветвление на каждый случай. Такое ломается при первом изменении и требует вечной поддержки. Вторая - слишком высокая: расплывчатые напутствия, которые не дают конкретного сигнала и молча предполагают, что у модели есть общий с вами контекст. Его нет.

Правильная высота - между: достаточно конкретно, чтобы направлять поведение, достаточно гибко, чтобы дать модели сильные эвристики.

Техника простая: разбить промпт на явные разделы - фон, инструкции, правила по инструментам - тегами вроде <background_information> или заголовками Markdown. И начинать с минимального промпта на самой сильной модели, а инструкции и примеры добавлять потом, по следам реальных отказов, найденных в тестах. Не наоборот.

Инструменты: мало, без перекрытий, экономно

Инструменты - это контракт между моделью и внешним миром. Требования Anthropic к ним: самодостаточные, устойчивые к ошибкам, предельно ясные по назначению. Параметры - описательные, однозначные, ложащиеся на сильные стороны модели.

Типовая болезнь - раздутый набор: инструменты покрывают слишком многое и пересекаются, и в какой-то момент выбор между ними становится неоднозначным. Критерий проверки прямой и жесткий: если человек-инженер не может определенно сказать, какой инструмент применить в данной ситуации, ожидать от агента лучшего нельзя.

Второе требование - экономность по токенам. Инструмент должен возвращать то, что помещается в бюджет внимания, и поощрять эффективное поведение агента. Инструмент, вываливающий в контекст двести строк служебного вывода на каждый вызов, вредит, даже когда работает правильно.

В соседней статье про агентов Anthropic добавляет: интерфейс «агент - компьютер» надо проектировать с тем же тщанием, что интерфейс «человек - компьютер». Про это будет отдельная лекция.

Примеры вместо перечисления исключений

Примеры в промпте - признанно сильный прием, и именно поэтому его портят: в инструкцию сваливают все известные исключения, надеясь закрыть каждую дырку. Получается длинный список, который съедает внимание и при этом не описывает основное поведение.

Рекомендация обратная: подобрать разнообразные канонические примеры, которые показывают ожидаемое поведение, и на этом остановиться. Формулировка авторов: для модели примеры - это «картинки, стоящие тысячи слов».

Общее правило раздела - держать контекст информативным, но плотным. Каждый блок должен зарабатывать свое место.

Контекст «точно в срок»

Классический подход - заранее проиндексировать все данные и подкладывать найденное перед запуском. Anthropic описывает сдвиг к другому подходу: агент держит легкие идентификаторы - пути к файлам, сохраненные запросы, ссылки - и подгружает данные в контекст во время работы, своими инструментами.

Так устроен Claude Code при анализе больших баз: он пишет точечные запросы, сохраняет результаты, пользуется head и tail - и разбирает объемы, которые целиком в контекст не влезли бы никогда.

Обоснование прямое: это повторяет человеческое мышление. Мы не заучиваем корпус документов наизусть, мы заводим папки, почту и закладки и достаем нужное по требованию.

Отдельная ценность - метаданные как сигнал. Файл test_utils.py в каталоге tests и он же в src/core_logic значат разное, и это понятно до чтения содержимого. Иерархия папок, соглашения об именах, даты изменения - все это информация. Размер файла намекает на сложность, дата - на актуальность. Агент разворачивает контекст постепенно, и каждый шаг подсказывает следующий.

Цена известна: исследование на ходу медленнее, чем взять заранее посчитанное, и требует продуманной инженерии - иначе агент уходит в тупики или не находит главного. Поэтому лучшие системы гибридные: часть данных кладется сразу ради скорости, остальное агент добирает сам. Claude Code так и сделан - CLAUDE.md просто кладется в контекст на старте, а glob и grep дают добирать файлы по мере надобности, минуя протухающие индексы.

Долгая задача: компакция, заметки, субагенты

Задачи на десятки минут и часы - миграция большой кодовой базы, исследование - неизбежно выходят за окно контекста. Ставка на то, что окна вырастут и проблема исчезнет, авторами прямо отклоняется: окна любого размера остаются подвержены засорению и вопросу релевантности.

Компакция. Разговор, подошедший к пределу, суммируется, и работа продолжается в новом окне с этой выжимкой. Claude Code при этом сохраняет архитектурные решения, нерешенные баги и детали реализации, а выбрасывает повторяющиеся выводы инструментов; в новое окно идет сжатая история плюс пять последних открытых файлов. Тонкое место - что оставить, а что выкинуть: слишком агрессивное сжатие теряет мелкую, но критичную деталь. Совет по настройке: сначала добиться полноты - чтобы промпт сжатия ловил все существенное, - и только потом убирать лишнее. Самая безопасная и дешевая форма - чистка старых результатов вызовов инструментов.

Заметки. Агент регулярно пишет заметки в файл за пределами контекста и подтягивает их обратно позже. Это дает постоянную память почти даром: списки задач, NOTES.md, рабочие журналы. В опытах с игрой в покемонов агент без всякой подсказки про структуру памяти сам завел счетчики вида «последние 1234 шага тренирую покемонов на маршруте 1, Пикачу набрал 8 уровней из 10», карты исследованных мест и заметки по тактике боя - и после сброса контекста читал собственные записи и продолжал многочасовую линию.

Субагенты. Главный агент держит план, специализированные субагенты делают узкую работу в своем контексте. Субагент может потратить десятки тысяч токенов на разведку, а вернуть сжатую выжимку в 1000-2000 токенов. Разделение чистое: подробности поиска остаются внутри субагента, ведущий агент занят синтезом.

Выбор техники зависит от задачи: компакция хороша там, где важен непрерывный диалог; заметки - там, где работа идет вехами; субагенты - там, где окупается параллельная разведка.

Workflow или агент

Anthropic проводит границу прямо. Workflow - система, где модели и инструменты оркестрируются заранее заданными путями в коде. Агент - система, где модель сама направляет свой процесс и решает, чем воспользоваться.

Разница не в сложности кода, а в том, кто принимает решение о следующем шаге. Workflow предсказуем и потому хорош для задач с понятной структурой. Агент гибок и нужен там, где решение должно приниматься по ходу и в масштабе.

Главная рекомендация статьи - сопротивляться соблазну. Начинать с простого промпта, мерить результат и добавлять многошаговые конструкции только тогда, когда простое решение доказуемо не справляется. Не «кажется, тут нужен агент», а «замерили, простое не тянет».

Завершается статья тремя принципами: простота конструкции, прозрачность - явно показывать шаги планирования, и документированный и протестированный интерфейс между агентом и его инструментами. И итог: успех не в том, чтобы построить самую изощренную систему, а в том, чтобы построить правильную для своей задачи.

Пять шаблонов workflow

1. Цепочка промптов. Задача разбивается на последовательные шаги, каждый вызов работает с результатом предыдущего. Годится там, где задача честно делится на фиксированные подзадачи и не жалко потерять скорость ради точности. Пример: написать текст, затем перевести; сделать план, проверить его, затем развернуть в документ.

2. Маршрутизация. Входящее классифицируется и уходит в специализированную ветку. Годится, когда категории заметно разные и их лучше обрабатывать врозь: возвраты и техподдержка - разными сценариями. Сюда же экономика: простые вопросы - на модель поменьше, сложные - на сильную.

3. Параллелизация. Два варианта. Секционирование - независимые подзадачи выполняются одновременно. Голосование - одна и та же задача решается несколько раз для уверенности. Примеры: проверять запрос на недопустимое содержимое параллельно с его обработкой; искать уязвимости несколькими разными промптами.

4. Оркестратор и работники. Центральная модель на ходу дробит задачу, раздает исполнителям и собирает результат. Отличие от параллелизации принципиальное: подзадачи заранее не известны - их определяет оркестратор. Пример: правка, расходящаяся по многим файлам.

5. Оценщик и оптимизатор. Одна модель генерирует, вторая оценивает и дает замечания, круг повторяется. Работает там, где есть внятные критерии оценки и где итерация действительно улучшает результат - художественный перевод, сложный поиск.

Когда действительно нужен автономный агент

Автономный агент - это модель, которая пользуется инструментами в цикле, опираясь на обратную связь от среды. Начинает с задачи человека, дальше планирует сама, может вернуться за уточнением, и у цикла обязаны быть условия остановки.

Область применения описана узко: открытые задачи, где нельзя предсказать количество шагов и невозможно захардкодить путь. Примеры - правки в коде, расходящиеся по множеству файлов, и работа с компьютером.

Требования к такому решению названы прямо: доверие к решениям модели, изолированная среда для испытаний и ограждения. Агент, работающий без песочницы на боевых данных, - не смелость, а незакрытый риск.

Отсюда и связка с первым блоком: чем длиннее автономная работа, тем важнее и компакция, и заметки, и независимая проверка результата.

ACI: интерфейс между агентом и машиной

Anthropic вводит понятие ACI - agent-computer interface - и настаивает, что вкладываться в него надо так же, как в интерфейс для людей. Практические правила короткие и проверяемые.

• Дайте модели достаточно токенов на размышление, прежде чем она загонит себя в угол необратимым действием.
• Держите форматы близкими к тому, что модель видела в обычных текстах. Чем экзотичнее формат, тем больше ошибок.
• Убирайте накладные расходы формата: подсчет строк, многослойное экранирование - все это цена, которую платит качество.
• Пишите описания инструментов как для нового джуниора: с примерами использования, краевыми случаями и явными границами.
• Тестируйте инструмент на живых примерах и смотрите, где модель ошибается. Потом меняйте конструкцию так, чтобы ошибиться было сложно - принцип пока-ёкэ.

Частный, но показательный пример из статьи: относительные пути к файлам становятся источником ошибок, требование абсолютных путей поднимает качество работы.

Дайте проверку, которую он прогонит сам

Это главная практика всего руководства. Агент останавливается, когда работа выглядит сделанной. Если проверки нет, то «выглядит» - единственный критерий, и каждая ошибка ждет, пока ее заметит человек. Дайте то, что возвращает «прошло» или «не прошло», - и цикл замыкается сам: сделал, прогнал, прочитал результат, исправил, прогнал снова.

Проверкой годится все, что возвращает читаемый сигнал: набор тестов, код возврата сборки, линтер, скрипт, сравнивающий вывод с эталоном, скриншот против макета.

Разница видна на формулировках. «Сделай функцию проверки адреса почты» против «сделай validateEmail, вот примеры: такой-то адрес - истина, такой-то - ложь, и прогони тесты после реализации». «Сделай дашборд красивее» против «вот скриншот, сделай так же, потом сними свой скриншот, сравни и перечисли отличия». «Сборка падает» против «сборка падает с такой ошибкой, почини и убедись, что собирается; лечи причину, а не симптом».

Дальше решается, насколько жестко проверка держит остановку: попросить прогнать в том же сообщении; поставить условием на всю сессию; повесить хук, который не дает завершить ход, пока скрипт не пройдет; или дать вторую пару глаз - отдельного проверяющего, который пытается опровергнуть результат, чтобы работу оценивал не тот, кто ее сделал.

И последнее: требуйте доказательство вместо утверждения. Вывод тестов, команда и что она вернула, скриншот. Прочитать доказательство быстрее, чем перепроверять самому, - и это работает для сессий, за которыми вы не следили.

Разведка, план, код, коммит

Если пустить агента сразу писать код, он часто решает не ту задачу - красиво и мимо. Рекомендованный порядок из четырех фаз.

• Разведка. В режиме плана агент читает файлы и отвечает на вопросы, ничего не меняя: «прочитай src/auth и разберись, как устроены сессии и вход».
• План. «Хочу добавить вход через Google. Какие файлы меняются? Как идет поток сессии? Составь план». План можно открыть в редакторе и поправить руками до начала работы.
• Реализация. Выходим из режима плана и просим сделать по плану, с тестами и прогоном.
• Коммит. Просим коммит с внятным сообщением и пул-реквест.

Оговорка, которую стоит запомнить: режим плана - это накладные расходы. Для опечатки, лишней строки в логе или переименования переменной он не нужен. Планирование окупается, когда вы не уверены в подходе, когда правка идет по нескольким файлам или когда код вам незнаком. Если правка описывается одной фразой - плана не надо.

Для крупной затеи есть отдельный прием: попросить агента проинтервьюировать вас - про реализацию, интерфейс, краевые случаи и компромиссы - и записать спецификацию в файл. Потом начать чистую сессию и выполнять ее. Хорошая спецификация самодостаточна: называет файлы и интерфейсы, говорит, что вне рамок, и заканчивается сквозной проверкой.

Конкретика вместо телепатии

Модель умеет достраивать намерение, но не читает мысли. Четыре приема, каждый показан парой «было - стало».

• Сузить задачу. «Добавь тесты для foo.py» → «напиши тест для foo.py на случай, когда пользователь разлогинен; без моков».
• Указать источник. «Почему у этого класса такой странный интерфейс?» → «посмотри историю git по этому классу и расскажи, как его интерфейс таким стал».
• Показать образец. «Добавь виджет календаря» → «посмотри, как сделаны виджеты на главной, хороший пример - вот этот; сделай по тому же образцу, без новых библиотек».
• Описать симптом. «Почини баг входа» → «пользователи жалуются, что вход не проходит после истечения сессии; посмотри обновление токена в src/auth, напиши падающий тест, который это воспроизводит, потом почини».

При этом расплывчатый запрос - не всегда ошибка. «Что бы ты здесь улучшил?» иногда поднимает то, о чем вы не догадались бы спросить. Важно понимать, в каком режиме вы сейчас: исследуете или заказываете.

Отдельно про богатый ввод: ссылаться на файлы через @, вставлять скриншоты прямо в запрос, давать адреса документации, передавать данные через конвейер - или просто разрешить агенту самому добрать то, что нужно.

CLAUDE.md: короткий файл, который читают всегда

CLAUDE.md читается в начале каждого разговора. Туда кладут то, чего нельзя вывести из кода: команды запуска, правила стиля, отличные от общепринятых, порядок тестирования, соглашения репозитория, архитектурные решения, особенности среды, известные грабли.

Туда не кладут то, что агент поймет, прочитав код; стандартные соглашения языка; подробную документацию API - на нее лучше ссылку; часто меняющиеся сведения; описания файлов по одному; самоочевидные наставления вроде «пиши чистый код».

Критерий прополки один: если убрать эту строку, начнет ли он ошибаться? Если нет - убрать. Раздутый файл приводит к тому, что агент игнорирует половину написанного, и важное тонет в шуме.

Диагностика по симптомам. Агент упорно делает то, что запрещено правилом, - файл, скорее всего, слишком длинный и правило потерялось. Агент спрашивает то, что в файле уже написано, - формулировка двусмысленная. Если одну инструкцию все время пропускают, можно выделить ее словом «ВАЖНО» - но только ее одну: когда выделено многое, не выделено ничего.

И отношение к файлу как к коду: пересматривать, когда что-то пошло не так, регулярно подрезать, проверять правки по тому, изменилось ли поведение. То, что нужно не всегда, а иногда, лучше выносить в навыки - они подгружаются по требованию и не висят в каждом разговоре.

Права, хуки, навыки, субагенты

Права. Когда на каждое действие спрашивают разрешение, после десятого подтверждения вы уже не читаете, а кликаете. Лечится двумя способами: белый список заведомо безопасных команд и песочница с ограничениями файловой системы и сети, внутри которой агент работает свободно.

Инструменты командной строки. Самый экономный по контексту способ общаться с внешними сервисами. Агент хорошо осваивает и незнакомые утилиты: «разберись через --help и реши такую-то задачу».

Хуки. Скрипты, запускаемые в определенных точках работы. Ключевое отличие: инструкции в CLAUDE.md носят рекомендательный характер, а хук срабатывает детерминированно. Все, что обязано происходить всегда и без исключений, должно быть хуком, а не строкой в инструкции.

Навыки. Файл SKILL.md с описанием - знание предметной области или повторяемый порядок действий. Подтягивается по релевантности или вызывается явно, и не раздувает каждый разговор. Для действий с побочными эффектами лучше отключать автоматический вызов и оставлять только ручной.

Субагенты. Работают в своем контексте со своим набором инструментов. Нужны там, где надо прочитать много файлов или сосредоточиться на узком вопросе, не засоряя основную переписку.

Сессия: правка на ходу и пять типовых провалов

Лучшие результаты дают короткие петли обратной связи. Останавливать, как только видно, что пошло не туда: контекст сохраняется, направление меняется. Есть откат по контрольным точкам - можно восстановить и переписку, и состояние файлов, - и есть сброс контекста между несвязанными задачами.

Правило, которое стоит запомнить дословно: если вы поправили агента больше двух раз по одному и тому же поводу, контекст уже забит неудачными подходами. Чистая сессия с хорошим запросом, вобравшим то, что вы поняли, почти всегда бьет длинную сессию с накопленными поправками.

Пять типовых провалов, названных в руководстве:

• Сессия-помойка. Начали одно, спросили постороннее, вернулись к первому. Лечение: сброс между несвязанными задачами.
• Поправки по кругу. Лечение: после двух неудачных - сброс и новый, более точный запрос.
• Перегруженный CLAUDE.md. Половина правил теряется в шуме. Лечение: безжалостно резать, а обязательное превращать в хук.
• Разрыв «доверяй, но проверяй». Правдоподобная реализация, не закрывающая краевые случаи. Лечение: всегда давать способ проверки. Если не можете проверить - не выкатывайте.
• Бесконечное исследование. «Разберись с этим» без границ - и прочитаны сотни файлов. Лечение: сужать рамку или отдавать разведку субагенту.

И отдельная мысль в конце руководства: все это - отправные точки, а не догма. Иногда контексту полезно накапливаться, иногда план только мешает, иногда расплывчатый запрос - именно то, что нужно. Смотрите, что сработало, и замечайте, что вы при этом сделали.

Масштаб: без интерфейса, параллельно, веером

Неинтерактивный запуск. Одна команда с промптом - и агент работает без диалога, выдавая обычный текст, JSON или поток JSON по строке на событие. Так он встраивается в конвейеры сборки, хуки перед коммитом и любые скрипты.

Параллельные сессии. Отдельные рабочие копии репозитория, чтобы правки не сталкивались; обмен находками между сессиями; запуск в облаке. Но главное тут не скорость, а качество: свежий контекст улучшает ревью, потому что сессия не привязана к коду, который сама только что написала.

Отсюда схема «писатель и рецензент». Сессия А реализует ограничитель частоты запросов. Сессия Б получает задание: посмотри реализацию, поищи краевые случаи, гонки и несоответствие принятым в проекте образцам. Замечания возвращаются в сессию А. Та же схема работает с тестами: один пишет тесты, другой - код, который их проходит.

Веер по файлам. Для больших миграций: сначала попросить составить список файлов, потом прогнать по нему цикл, вызывая агента на каждый файл с ограниченным набором разрешенных инструментов. Обкатать на двух-трех, поправить промпт, потом пускать на весь список.

Важная оговорка про рецензента: тот, кого попросили найти недостатки, найдет их и в хорошей работе - его об этом попросили. Гнаться за каждым замечанием значит получить лишние слои абстракций, оборонительный код и тесты на невозможное. Просите отмечать только то, что влияет на корректность или на заявленные требования.

Почему эвал занимает место теста

В обычной программе спецификация выражается тестом: вход такой - выход обязан быть таким. В системе с моделью на одном и том же входе выход меняется, а «правильно» - это суждение, а не равенство. Спецификацией становится эвал.

Hamel описывает три уровня. Первый - быстрые и дешевые проверки-утверждения, которые гоняют на каждое изменение: регулярка ловит утекший внутренний идентификатор, счетчик проверяет, что вернулось ровно столько объектов, сколько обещано. Их организуют так, чтобы использовать не только в тестах, но и в чистке данных, и в автоматических повторах.

Второй - оценка человеком и моделью: журналы трасс, собственный просмотрщик данных, модель-судья. Третий - A/B на живых пользователях, и он имеет смысл только для зрелого продукта.

Дальше Hamel описывает маховик из трех занятий: оценивать качество, отлаживать и менять поведение - промптом, кодом, дообучением. Делать все три хорошо - и есть то, что отличает сильный продукт от посредственного.

У Shreya та же мысль с другой стороны: проекты рушатся не от слабых моделей, а от того, что ожидания выставлены «по ощущениям», а инфраструктуры, чтобы постоянно смотреть на данные, добавлять проверки и улучшать систему, никто не построил.

Анализ ошибок - самое доходное занятие

Типовая ошибка команд - вкладываться в инструменты и архитектуру вместо измерения, а потом получать ложное чувство измеренности от общих метрик, которые ни с чем не коррелируют.

Правильный порядок обратный: взять настоящие переписки, прочитать их, описать отказы своими словами, сгруппировать и увидеть, какие категории образовались. Это подход снизу вверх - в отличие от подхода сверху, где берут готовые метрики вроде «галлюцинаций» и не видят того, что специфично именно для вашей области.

Пример из практики. В сервисе для управляющих компаний эксперты предметной области разметили переписки и обнаружили, что три проблемы дают больше 60 % отказов: разрывы в ходе разговора, сбои при передаче человеку и работа с датами. У дат доля отказов была 66 %. Занялись именно датами - и подняли успешность с 33 % до 95 %.

Второе по важности вложение - не красивые дашборды, а собственный просмотрщик данных под свою задачу. Требования простые: весь контекст виден в одном месте, оценка ставится в один клик, есть поле для свободного комментария, есть фильтры по типам ошибок и горячие клавиши. Разница в скорости работы - на порядок.

И третья мысль: не заставляйте эксперта предметной области объяснять свои знания инженеру, чтобы тот перевел их в промпт. Дайте эксперту править промпт самому - внутри интерфейса, где система работает целиком. И говорите с ним без жаргона: не «подход RAG», а «даем модели нужный контекст»; не «галлюцинации», а «иногда выдумывает».

Бинарно - и с объяснением

Шкалы кажутся богаче, а на деле размывают: никто не может внятно объяснить, чем тройка отличается от четверки, и разные люди ставят их по-разному. Бинарное решение заставляет договориться, что именно считается приемлемым.

Но одного вердикта мало. К нему прилагается критика - объяснение, почему так. Критерий подробности у Hamel бытовой и точный: текст должен быть таким, чтобы новый сотрудник понял. Односложные пометки бесполезны.

Ценность критики двойная. Во-первых, из нее потом собирается промпт для модели-судьи. Во-вторых, чтение критик само по себе подсказывает, что чинить в продукте, - часто больше, чем итоговые цифры.

Сюда же - предупреждение о разрастании метрик. Не заводите десять измерений качества сразу: многомерные оценки дают ощущение строгости и отнимают ясность. Одна бинарная метрика, выровненная с человеком, полезнее пяти невыровненных.

Модель-судья: метод целиком

Метод Hamel называется critique shadowing и состоит из семи шагов.

• 1. Найти главного эксперта. Один человек, в крайнем случае двое, с глубоким знанием предмета - психолог для продукта про психику, юрист для разбора договоров, руководитель поддержки для чат-бота. Именно он задает планку. Много оценщиков с разным пониманием разрушают процесс.
• 2. Собрать разнообразный набор данных по трем осям: функции (что продукт умеет), сценарии (совпадений много, ни одного, запрос двусмысленный, сбой системы) и типы пользователей. Синтетику генерировать только на входах, а ответы получать из настоящей системы - иначе вы унаследуете вкусы генерирующей модели.
• 3. Собрать оценки с критиками. Бинарно плюс объяснение. Начинать примерно с тридцати примеров и идти, пока перестанут появляться новые типы отказов; для проверки - около сотни примеров на каждый тип отказа.
• 4. Починить очевидное. Если разметка вскрыла сквозную проблему - сначала исправить ее, потом продолжать. Иначе судья будет калиброваться на систему, которой скоро не будет.
• 5. Собрать судью итеративно. В промпт кладут правила предметной области, три-пять примеров из разметки эксперта с его критиками - и удачных, и неудачных, - тот же контекст, который видел человек, и требование к формату ответа.
• 6. Измерить согласие. Судья - это бинарный классификатор, и мерить его надо как классификатор: долю верно распознанных «прошло» и долю верно распознанных «не прошло» по отдельности. Сырое согласие обманывает: если отказов 5 %, судья, который всем ставит «прошло», покажет 95 % точности и не поймает ни одной ошибки. Данные делят на три части: небольшая обучающая - примеры в промпт, и две примерно равные - для настройки и для финальной проверки, которую запускают один раз и замораживают. Для хорошо очерченной задачи обычно хватает двух-трех кругов.
• 7. Прогнать судью по всем данным и разобрать ошибки по осям функция × сценарий × тип пользователя. Корневые причины классифицируются руками - этот шаг не автоматизируется.

Отдельные судьи под конкретные типы отказов - только после того, как анализ покажет, что они нужны. Не раньше.

Criteria drift: критерии рождаются при разметке

Это результат исследовательской работы Shreya Shankar с соавторами, представленной на UIST 2024, - той самой «Who validates the validators?». Формулировка авторов: пользователям нужны критерии, чтобы оценивать выводы, но само оценивание помогает эти критерии определить.

Из этого следует вещь, ломающая привычную методологию: часть критериев зависит от увиденных выходов и не может быть задана заранее как независимая мера. Представление о том, что «правильно» - фиксированная планка, которую достаточно один раз записать в документ, в работе с моделями просто неверно.

Практический вывод: критерии - живой документ. Их пересматривают по мере того, как смотрят на данные, а не утверждают один раз на старте. И ровно поэтому Hamel настаивает на регулярной перепроверке согласия судьи с человеком: без нее критерии уползают, а смещение копится молча. В одном описанном случае потребовалось три круга, чтобы довести согласие судьи с экспертом выше 90 %.

И вывод общий, который авторы делают прямо: замысел полностью автоматизировать работу над промптами и приложениями поверх моделей - ошибочен. Человеческое суждение из контура не убирается, его можно только сократить и упорядочить.

Маховик данных

Shreya описывает работу с продуктом на моделях как три стадии, идущие по кругу.

Оценка. Метрики должны появляться из разглядывания настоящих выходов, а не из умозрительного перечня того, что может сломаться. Часть проверок - обычный код (длина, формат), часть - модель-судья (тон, эмпатия). Бинарные проверки выравнивать и размечать проще, чем шкалы. В графе вызовов разные узлы требуют разной проверки: классификаторы меряются точностью и полнотой, генераторы текста - качеством и соблюдением ограничений, генераторы кода - линтером, тестами и фактическим запуском.

Отдельно - проверка входа, о которой забывают чаще всего. Принцип сформулирован как «будь строг к тому, что отправляешь модели, и терпим к тому, что принимаешь»: относится ли запрос к делу, не выходит ли за рамки сложности, тот ли это пользователь, нет ли чувствительных данных, нет ли признаков атаки.

Наблюдение. Набор метрик, зафиксированный однажды, разъезжается с реальностью: меняются модели, меняются пользователи, появляются новые отказы. Лечится регулярной разметкой свежих production-примеров с отметками времени, хранением их с индексом по смыслу и обновлением примеров в промпте судьи - с приоритетом тех случаев, где человек и судья разошлись, и с весом на свежесть.

Улучшение. Смотреть распределение оценок, искать закономерности, сравнивать варианты промптов. Более интересный механизм - база исправлений: трассы с низкой оценкой правятся руками и складываются, а во время работы к похожему запросу подтягиваются исправленные случаи как примеры.

Честная оговорка автора: непрерывная разметка людьми остается трудоемкой и никуда не девается. Маховик ее не отменяет - он делает ее выборочной и адресной.

Свод: двенадцать правил

• 1. Ищите наименьший набор токенов с наибольшим сигналом. Это единственный принцип, из которого выводится остальное.
• 2. Длинное окно не отменяет деградации: точность падает плавно, но падает.
• 3. Системная инструкция - между жесткой логикой и общими словами. Начинать с минимальной на сильной модели.
• 4. Не можете сами уверенно выбрать инструмент - агент тем более не сможет.
• 5. Держите ссылки, подтягивайте содержимое в момент надобности. Имена и структура каталогов - бесплатный контекст.
• 6. На длинной дистанции: сжимать историю, писать заметки на диск, отдавать разведку субагентам.
• 7. Сначала простое. Агент - только когда измерено, что workflow не тянет.
• 8. Описание инструмента пишется как для нового джуниора, а аргументы - чтобы ошибиться было трудно.
• 9. Дайте проверку, которую агент прогонит сам, и требуйте доказательство, а не утверждение.
• 10. Две неудачных поправки подряд - чистить контекст и переписывать запрос.
• 11. Бинарная оценка плюс развернутая критика. Судью мерить как классификатор, двумя долями по отдельности.
• 12. Критерии не выписываются заранее - они рождаются при разметке. Возвращайтесь к данным регулярно.