Measuring context quality

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

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

Эвалы делятся на офлайн и онлайн. Офлайн — golden set с разметкой, быстрые и дешёвые, гоняются в CI. Онлайн — метрики продакшена: доля эскалаций к человеку, thumbs up/down, доля ответов «не знаю», повторные обращения по тому же вопросу. Офлайн ловит регрессии до релиза, онлайн — то, чего нет в наборе. Работают только вместе: офлайн без онлайна слепнет к реальному распределению запросов, онлайн без офлайна замечает поломку через неделю по жалобам.

Retrieval измеряется отдельно от генерации, и это принципиально: если нужного фрагмента нет в выдаче, никакая модель не спасёт ответ — она либо откажется, либо сгаллюцинирует. Разделение слоёв позволяет чинить то, что сломано, а не крутить всё сразу.

Основа — golden set: 50–200 реальных запросов, для каждого размечено, какие фрагменты корпуса релевантны. Собирается из логов продакшена (реальные формулировки лучше выдуманных) с ручной разметкой; это скучный день работы, который окупается месяцами. По набору считаются классические метрики: recall@k — доля запросов, где нужный фрагмент попал в топ-k (главная метрика: потерянное на этом этапе не восстановить); precision@k — сколько в топ-k релевантного (низкая точность — это дистракторы в контексте, привет context rot); MRR и nDCG — насколько высоко стоят релевантные результаты, что критично, если в контекст идут только первые позиции.

Практический ориентир: recall@10 ниже 0,8 означает, что каждый пятый ответ строится без нужного источника — начинать надо отсюда, а не с промптов. Инструменты типа Ragas дают готовые реализации context precision и context recall, включая вариант с LLM-разметкой вместо ручной — полезно для быстрого старта, но выборочно сверяйте авторазметку с человеческой.

Хороший retrieval не гарантирует честный ответ: модель может проигнорировать контекст и ответить «из головы». Для этого измеряют faithfulness (groundedness) — долю утверждений ответа, подтверждённых переданным контекстом. Схема оценки LLM-судьёй в два шага: первый вызов разбивает ответ на атомарные утверждения; второй для каждого утверждения проверяет, следует ли оно из контекста, с вердиктом «подтверждено / не подтверждено / противоречит». Метрика — доля подтверждённых; противоречия весят хуже, чем просто неподтверждённые.

Судью нельзя принимать на веру — его калибруют. Возьмите 50 случаев, разметьте людьми, посчитайте согласие судьи с человеком. Согласие ниже 80% — чините промпт судьи (типовые причины: судья засчитывает парафраз как противоречие или прощает «общеизвестные» вставки). Правила гигиены: судья работает на другой модели или минимум на другом промпте, чем оцениваемая система; критерии в промпте судьи конкретны («утверждение подтверждено, если следует из контекста без внешних знаний»); шкала — бинарная или трёхуровневая, дробные баллы вроде «7 из 10» нестабильны.

Парная метрика — answer relevancy: отвечает ли ответ на заданный вопрос. Вместе faithfulness и relevancy ловят два главных провала генерации: «красиво, но не по контексту» и «по контексту, но не про то».

Метрики слоёв необходимы, но недостаточны: пользователь видит только конечный результат. End-to-end эвал прогоняет всю систему на реалистичных сценариях, включая multi-turn: «спроси про X, уточни Y, попроси сравнить с Z» — именно на длинных сценариях всплывают проблемы компакции и памяти, невидимые в одиночных вопросах. Синтетические тесты вроде «иголки в стоге» для этого непригодны: как показал отчёт о context rot, модели проходят их почти идеально, продолжая проваливать реальные длинные задачи. Для длинного контекста есть специализированные наборы вроде LongBench, но свои сценарии на своих данных всегда информативнее.

Когда эвал нашёл провалы, начинается главное — анализ ошибок с классификацией по слоям: нужный фрагмент не был извлечён (чинить retrieval); извлечён, но проигнорирован (раскладка окна, дистракторы); инструкция потерялась в длинном диалоге (компакция, позиция инвариантов); память протухла (политика обновления); ответ не обоснован контекстом (промпт генерации). Пара десятков размеченных так провалов почти всегда показывает: 70% ошибок сидят в одном-двух слоях — туда и направляются усилия, вместо интуитивного кручения всего подряд.

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