Зачем нужны эвалы для LLM-фич
Автор объясняет, что такое эвалы для LLM-фич, где их запускать и какие проблемы возникают без них. Без эвалов невозможно объективно оценить, стало ли лучше после смены промпта или модели.
Бэкенд-разработчик Тарас Малиновский, работающий на Go, опубликовал на Хабре цикл статей об оценке качества (эвалах) LLM-фич. Поводом стал хакатон Podlodka AI Club, где его команда строила систему памяти для агентов. Реализовать память удалось быстро, но доказать, что она действительно работает, оказалось сложнее — именно на это ушла основная часть времени.
По словам автора, замена промпта или модели занимает вечер, но без чётких критериев оценки невозможно понять, стало ли лучше. Эвал — это набор метрик, показывающих, насколько успешно выполнена задача. В первой части цикла Малиновский разбирает, зачем нужны такие системы и что происходит с LLM-функциональностью, когда их нет.
В качестве примера он приводит проект Job Radar — сервис, который собирает IT-вакансии из Telegram-каналов и классифицирует их по направлениям (бэкенд, HR, QA и т.д.). Если модель ошибается, вакансия попадает не в ту категорию и остаётся незамеченной подписчиками. Ошибки при этом не вызывают исключений и не логируются, поэтому без эвалов их легко пропустить.
Автор описывает четыре основных вида проверок: детерминированные (по схемам, регуляркам, спискам), сравнение с эталоном (когда есть единственная правильная метка), ручная оценка (для сложных случаев) и LLM-судья (для масштабируемости). Главное правило — выбирать самую дешёвую и эффективную проверку, которой достаточно для выявления ошибки. Например, для классификатора вакансий достаточно сравнения с эталонной меткой.
Малиновский подчёркивает разницу между эвалом и бенчмарком. Бенчмарк сравнивает модели на стандартных наборах данных и подходит для публичных рейтингов, но может давать неточные выводы для узких задач. Эвал же проверяет качество фичи на ваших данных и сценариях, помогая находить ошибки, характерные именно для вашего продукта.
На хакатоне команда столкнулась с неочевидной проблемой: агент учитывал факт из прошлого разговора, но не проговаривал его вслух. Тест, проверявший наличие точного упоминания, отклонял такой ответ. Решение нашли, переформулировав критерий: стали сравнивать ответы агента с включённой и выключенной памятью. Это позволило измерить именно то, что было нужно.
Автор отмечает, что для LLM-фич классический подход с юнит-тестами не работает: правильных ответов может быть несколько, а сами ответы «плавают» даже без изменений в коде. Поэтому эвалы становятся ключевым инструментом для объективной оценки и итеративного улучшения AI-продуктов.
Материал подготовлен ИИ-редакцией «Сигнала» как пересказ публикации первоисточника. Фактическую точность и подробности проверяйте по оригиналу.