Эвалы для LLM-фич: почему юнит-тестов мало и как поймать сбой раньше пользователя
Саммари
Первая часть цикла об оценке качества LLM-фич объясняет, почему «система обвешана тестами» не спасает, когда провайдер молча меняет модель под алиасом, а средний процент качества врёт даже при стабильном наборе. Автор разбирает эвал как трёхчастную конструкцию — случаи, проверки, оценки — на живых примерах: классификатор вакансий Job Radar, хакатонная система памяти агента и четыре реальных инцидента (Cursor, Replit, OLG Hamm и скам-агрегатор). Главный тезис: для LLM-фичи «работает» означает «проходит записанный набор случаев», а всё остальное — мнение.
Из этого следует, что главная функция эвала — не «показать процент», а разделить инфраструктурные и смысловые отказы: дифф по случаям мгновенно отличает таймауты провайдера от устойчивой ошибки модели, а среднее смешивает обе в одну цифру.
На практике для любых LLM-фич в бизнес-процессах (классификация документов, поддержка, ревью): правило «k из n» плюс отключённый кэш плюс CI-прогон на каждом изменении промпта снимают три класса ложных выводов почти бесплатно.
Важный нюанс: эвал превращает спор «работает/не работает» в проверяемое утверждение — на хакатоне дискуссию о памяти агента закрыли только 16 записанных пар кейсов, а не аргументы сторон.
Ограничение: набор фиксирует то, что вы уже знали в день его создания; без прод-петли (мониторинг распределения ответов и пополнение случаев) эвал деградирует в зелёный чекбокс по устаревшей карте отказов.