Эвалы для продакта на практике

Что такое эвалы

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

Если к твоему продукту недавно прикрутили «AI-ассистента» просто потому, что так модно, попробуй выключить его в A/B-тесте. Велик шанс, что бизнес-метрики останутся теми же или даже подрастут (только CEO показывай это аккуратно). Чаще всего старый добрый веб-интерфейс справляется лучше всех, а ассистенты, расставленные тут и там, только мешают. Мне рассказывали про интернет-банк, где долго и упорно пытались встроить чат-помощников в разные вертикали. В итоге всё свернули: пользователям оно так и не пригодилось.

Но бывает, что AI и правда создаёт ценность. В поддержке AI-агенты могут работать эффективнее и стабильнее людей. А иногда пользователю проще описать, что нужно, своими словами, чем ковыряться в фильтрах (например, в ИИ-ассистенте Яндекс Маркета).

Если на тебе AI-агент, от которого сильно зависит решение проблемы клиента, про эвалы (evals) ты наверняка уже слышишь. По сути, эвалы это тест-кейсы для твоего ML-решения, с парой важных оговорок. Да-да, те самые тесты, которые разработчики пишут десятилетиями, только в новой обёртке (скажи это хайпующему по эвалам коллеге и понаблюдай за реакцией).

Детерминированные эвалы

Берём запрос, прогоняем через агента и сравниваем ответ с заранее известным правильным. Тут всё просто: ответ либо верный, либо нет.

Допустим, AI-чат поддержки в доставке еды вроде Яндекс Еды сначала классифицирует каждое сообщение клиента, чтобы отправить его в нужный флоу. Output это метка, которую поставил AI, а ground truth (она же разметка) это метка, которую задаёшь ты, продакт. Скролль дальше, и эвал пройдёт по строкам одну за другой.

На выходе простая метрика, accuracy, то есть доля верных ответов: в этой таблице 3 из 5, или 60%. Её можно отслеживать во времени и проверять на этом наборе эвалов каждый новый релиз.

И кстати, поздравляю с первым эвалом. Пока никакой магии, правда?

LLM as a judge

К сожалению, такой подход работает только для агентов с фиксированным результатом: принять решение, отроутить запрос, дёрнуть API со структурированными параметрами. А у большей части того, что агент пишет клиентам, единственного правильного ответа просто нет. Часть проверок свободного текста тоже можно делать кодом (валидный JSON, запрещённые слова, длина), но на вопрос «хороший ли это ответ?» код не ответит.

Представь, что наш чат теперь ещё и отвечает клиентам сам. Измерять качество всё равно хочется (я надеюсь!). Скажем, агент пишет «Извините, вернём деньги за картошку» или «Это наш косяк, сумма за картошку уже возвращена на карту». Нормальные ответы? На мой взгляд, вполне. Но как проверить такое на масштабе, когда чатов с клиентами 10 тысяч в день?

Для открытых ответов берём другую, обычно более мощную модель и назначаем её судьёй: это и есть LLM as a judge. Вместо точного ожидаемого ответа ground truth теперь становится общим описанием того, что должно получиться. А пишет его... правильно, продакт! Попробуй побыть судьёй: зачёт или незачёт?

Вот что про судей пришлось выучить на своих граблях:

• Критерий должен быть бинарным, да или нет. «Ответ не содержит утверждений об аллергенах, которых нет в данных меню? Да/Нет.» Когда такой эвал падает, сразу понятно, что чинить.
• Один судья, один критерий. Судья, который разом проверяет тон, факты и соответствие политикам, про все три напишет что-то туманное. Распили его на трёх. В таблице выше несколько проверок собраны в одном описании, чтобы пример был короче, а в реальной работе их лучше разделять.
• Проси судью объяснять вердикт. Когда дебажишь упавший трейс, объяснение часто полезнее самого вердикта. А ещё его можно использовать в циклах, где агент улучшает сам себя.
• Проверяй самого судью. Не смейся и не паникуй, но судья тоже LLM-приложение, и если он стал важным и сложным, ему тоже нужны эвалы. Да, иногда нам нужны эвалы для эвалов. Тут хватит вручную разметить 50-100 примеров и прогнать обычный детерминированный эвал.

Как вести наборы эвалов

• Синтетические кейсы. Если сценарий совсем новый, первый набор эвалов почти наверняка придётся написать с нуля. Этот период я не люблю: фантазии редко совпадают с тем, что клиенты пишут на самом деле.

  Придумано за рабочим столом

  Две "Маргариты" из Luigi's

  Написал живой пользователь

  как в прошлый раз только без лука и побыстрее плз

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

• Каждый серьёзный баг становится эвалом. Агент на проде потерял пометку про аллергию? Сначала добавь этот кейс в набор, потом чини промпт. Так тот же баг больше не проскочит незаметно, по крайней мере в той же форме. (Да, разработчики и тут делают так же уже десятилетиями.)
• Раскладывай эвалы по темам. Если фича приносит пользу и ты её масштабируешь (кстати, поздравляю!), набор начнёт быстро пухнуть. Разбей его по темам: мало данных, небезопасные темы, промпт-инъекции.

• Версионируй эвалы вместе с промптами. Оценка эвала имеет смысл только рядом с версией промпта, модели и набора, на которых её получили. Чтооо? Давай на пальцах.

  Твой классификатор поддержки выбивает 80% на 50 тест-кейсах. Через неделю прогоняешь снова и видишь 70%, а команда уже ищет, что сломалось в промпте. Ничего не сломалось, и git blame показывать некому.

  Прогоны эвала

  40 из 5080%

  промпт v4 × модель X × набор v1 → 80%

  Добавить 20 кейсов из логов за неделю

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

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

Эвалы на проде

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

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

Но в любом случае бизнес-сигналы намного важнее эвалов.

Такой сценарий всё равно плохой. Судьи иногда помогают понять, почему клиенты не в восторге, но это инструмент, и цель у продукта другая.

Итоги

• Эвалы это тест-кейсы для твоего AI-агента.
• Детерминированные эвалы сравнивают ответ с заранее известным правильным. Просто и дёшево, но работает только для структурированных ответов: классификации, роутинга и так далее.
• LLM as a judge критически оценивает открытые ответы по описанию того, что должно получиться.
• Начинай с синтетики, но как можно скорее переходи на реальные кейсы с прода. Группируй эвалы по темам и версионируй вместе с промптами.
• На проде ground truth нет, но на выборке диалогов можно гонять эвалы, которым он не нужен.
• Бизнес-метрики всегда важнее оценок эвалов.