AI Evals: 9 принципов которые реально работают

Как говорил мой дед: "Доверяй но verify"! Не буду тут повторяться про то как важны Evals в AI разработке, перейду к сути - вот принципы, к которым я пришел на практике.

1. Сначала реальные проблемы, потом метрики

Не придумывай evals из головы (и уж тем более не проси AI их придумать). Выпусти первую версию, отдай эксперту на разметку, и пусть проверки (а главное их категории!) вырастут из реальных косяков. Исключение: если уже есть verified ground truth (пары вопрос-ответ от экспертов) - можно начать с evals сразу. Тем более размечать готовые трейсы (например из LangFuse) куда удобнее - там есть много важных деталей о ходе работы AI системы.

2. PASS/FAIL лучше чем грейды (1-5, 0..100%)

Бинарные чеки проще согласовать между людьми и между LLM и человеком. Люди и сами нестабильно используют шкалы, а с бинарными оценками дрифт минимальный. Согласование между людьми на бинарных оценках всегда выше. Хочется нюансов? Бинарный вердикт + текстовая критика. Судья пишет pass/fail И развернуто объясняет почему. Нужна гранулярность? Разбей на несколько бинарных чеков.

3. Эксперт - ключевая фигура. Сделай чтобы ему удобно

Доменный эксперт - человек, от которого зависит качество eval-ов. Надо сделать все чтобы ему было удобно и все шло быстро. Например, мы у себя нередко вайбкодим кастомные eval-аппы чтобы экспертам было удобно размечать: cлева исходный документ (например PDF), справа ответ системы и там же поле для аннотации. Или даже тиндер-стайл (мне за эту разработку такую премию дадут!): свайп вправо pass, влево fail, и надиктовать коммент голосом - почему бы и нет? Главное вытащить суть из эксперта и делать это регулярно.

4. Простой кастомный eval лучше готового фреймворка

Generic метрики (coherence, fluency, faithfulness) создают иллюзию контроля. Eval который ты понимаешь и можешь объяснить коллеге за 30 секунд - всегда лучше черного ящика. Привет, RAGAS)

5. Детерминированные проверки в приоритете

Код (regex, assertions, другие code-checks включая простые NLP чеки) - всегда первый выбор. LLM-as-a-judge - только там, где код не справляется. Это надежнее, дешевле, быстрее. LLM-judge оправдан для субъективных вещей: качество передачи контекста, тон, полнота ответа - то что кодом не проверишь.

6. LLM-judge калибруй по эксперту, а не наоборот

Порядок такой: сначала берешь несколько десятков пар, которые размечает эксперт, потом бьешь это на категории (AI в помощь), потом строишь разные скореры - часть кодом, часть LLM-as-a-judge (каждый отвечает четко PASS/FAIL и есть поле с обоснованием/критикой), потом надо снова согласовать выход LLM-as-a-judge с экспертом и править промпт пока согласованность не будет высокой.

7. Разделяй evals по блокам системы

Не один eval на всю систему (хотя и один лучше чем ничего).
Пример с RAG:
- Retrieval: recall, precision, MRR - находит ли система правильные документы?
- Generation ответа: правильно ли модель использует найденный контекст (кастомные скореры)?
Разделение дает четкий сигнал где ломается.
С агентами принцип тот же: eval-ишь отдельные tools изолированно + session-level pass/fail на итог. Но не проверяй конкретные шаги - агент часто находит путь, который ты не предвидел.

8. Синхронизируй версии промптов и evals

Промпт, код и evals легко рассинхронизируются - промпт поменялся, а evals проверяют старое поведение. Неважно как именно ты версионируешь (Git, платформа типа promtfoo или Langfuse, хоть excel) - главное чтобы была сквозная версия. А еще метрики дрифтуют, это нормально, не пытайся сохранить непрерывную линию метрик любой ценой.

9. Процесс важнее инструмента

Даже Google Sheets которыми реально пользуются эксперты лучше чем Promptfoo которым не пользуется никто. Ручной eval на 50 парах лучше чем крутой Eval Pipeline в CI. Не прокрастинируй выбором тулинга. Лучший eval-инструмент - тот, который используется. Тем более потом превратить эту табличку в автоматические проверки будет очень просто.

🔥 ➕ 🔁 @nobilix