Ваш AI-чат-бот для клиентов начал галлюцинировать, и вы узнаёте об этом только по жалобам? Или внутренний ассистент для менеджеров выдаёт не те сроки, и вы теряете заказы? Без системной оценки качества AI-продукта вы работаете вслепую. Хорошие новости: первые тесты можно написать за вечер, и они сразу начнут ловить проблемы. Разберём на примере стройфирмы, но подход подойдёт для любой ниши.
Eval (от evaluation - оценка) - это проверка качества модели на наборе тестовых задач. Как приёмочные испытания на заводе: прежде чем выпустить изменение в продукт, вы проверяете, действительно ли оно улучшило качество или только кажется, что улучшило. Для предпринимателя это переводится просто: перестаёте гадать и начинаете измерять.
Без этого инструмента компании работают вслепую. Разработчик меняет промпт - «кажется, стало лучше». Переходят на другую модель - «наверное, дешевле и не хуже». Добавляют новый документ в базу знаний - «должно помочь». Каждое решение на ощущениях. Eval заменяет ощущения числами.
Типы показателей оценки: эталон, суждение и гибрид
Бизнесу важно понимать три класса инструментов оценки, прежде чем выбирать конкретный.
Показатели на основе эталона сравнивают ответ модели с заранее проверенным правильным ответом. ROUGE-L измеряет совпадение ключевых слов и фраз - хорош для проверки кратких изложений, но не распознаёт синонимы: «автомобиль» и «машина» дадут низкий балл. BERTScore сравнивает смысл через языковую модель: улавливает синонимы лучше. Точное совпадение (Exact Match) - бинарный тест для структурированных ответов: либо JSON правильный, либо нет.
Проблема: нужен эталонный набор правильных ответов. Для живых документов компании это дорого собирать.
Показатели на основе суждения AI (LLM-as-judge) оценивают ответ без эталона. Другая языковая модель выступает судьёй и отвечает на вопросы: «Содержит ли ответ только факты из документа?» или «Есть ли в ответе придуманные факты?» Результат - число от 0.0 до 1.0. Это основной подход для большинства бизнес-систем, где эталонный набор сложно поддерживать в актуальном состоянии.
Гибридные показатели комбинируют оба подхода. G-Eval в DeepEval - пример: AI-судья оценивает по нескольким критериям с весами, которые вы задаёте сами.
Ragas: оценка систем поиска с генерацией
RAG-система (Retrieval-Augmented Generation, поиск с генерацией) - это когда AI сначала ищет нужные документы в вашей базе знаний, а потом формирует ответ на их основе. Разберём на примере стройфирмы: у вас есть чат-бот для менеджеров по прайсам и типовым договорам подряда. Качество такой системы нужно измерять с двух сторон: насколько хорошо нашли документы и насколько честно их пересказали.
Ragas специализируется именно на этом. Четыре ключевых показателя:
faithfulness (верность) - доля утверждений в ответе, которые реально подтверждаются найденными документами. Если бот говорит то, чего нет в документе - это галлюцинация. Цель: выше 0.85.
answer_relevancy (релевантность ответа) - насколько ответ относится к вопросу. Цель: выше 0.80.
context_precision (точность поиска) - доля полезных документов среди всех найденных. Много лишних документов - много шума в ответе.
context_recall (полнота поиска) - доля нужных фактов, которые система вообще нашла. Низкий показатель значит: важная информация не извлекается.
Следующий код запускает оценку RAG-системы по всем четырём показателям сразу. На входе - список вопросов, ответы системы, найденные документы и (если есть) эталонные ответы:
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_precision, context_recall
from datasets import Dataset
data_samples = {
"question": ["Какой срок оплаты по договору 123?", "Кто несёт ответственность за просрочку?"],
"answer": ["Срок оплаты - 30 дней с момента подписания акта.", "Ответственность за просрочку несёт поставщик."],
"contexts": [
["Оплата производится в течение 30 рабочих дней после подписания акта приёма-передачи..."],
["В случае нарушения сроков поставки поставщик уплачивает неустойку в размере 0.1%..."]
],
"ground_truth": ["30 дней с момента подписания акта.", "Поставщик."]
}
dataset = Dataset.from_dict(data_samples)
result = evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_precision, context_recall])
print(result)
Целевые значения для рабочей системы: faithfulness выше 0.85, answer_relevancy выше 0.80, context_precision выше 0.75.
DeepEval: оценка за пределами поиска с генерацией
DeepEval охватывает более широкий круг задач, чем Ragas. Он подходит для оценки AI-агентов, диалоговых ботов и любых сценариев, где нужны гибкие критерии.
G-Eval - универсальный судья с произвольными критериями. Вы описываете словами, что значит «хороший ответ», и DeepEval оценивает по этим критериям. Это особенно ценно для задач, где не существует единственно правильного ответа - например, оценка тона, вежливости или структуры объяснения.
Следующий код создаёт метрику, которая проверяет фактическую точность ответов по шкале от 0 до 10:
from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams
correctness_metric = GEval(
name="Correctness",
criteria="Determine whether the actual output is factually correct based on the expected output.",
evaluation_params=[LLMTestCaseParams.INPUT, LLMTestCaseParams.ACTUAL_OUTPUT, LLMTestCaseParams.EXPECTED_OUTPUT],
)
test_case = LLMTestCase(
input="Каков срок действия договора?",
actual_output="Договор действует 1 год.",
expected_output="Срок действия - 12 месяцев с даты подписания."
)
correctness_metric.measure(test_case)
print(correctness_metric.score) # 0.0-1.0
print(correctness_metric.reason) # объяснение оценки
HallucinationMetric находит придуманные факты и объясняет, какой именно факт выдуман. Это важно для принятия решений: вы видите не просто «плохой балл», а конкретную проблему.
ToolCallCorrectnessMetric - для AI-агентов. Проверяет, правильный ли инструмент вызвал агент с правильными аргументами. Незаменим при тестировании сложных автоматизированных процессов.
ConversationalTestCase оценивает многоходовые диалоги: связность разговора и помнит ли модель факты из предыдущих сообщений.
DeepEval также измеряет время ответа и стоимость прямо в тест-кейсе. Можно поставить пороги: «ответ не дороже $0.01».
Построение золотого набора данных
Золотой набор данных (golden dataset) - это ваши «правильные ответы»: набор проверенных пар вопрос-ответ-контекст. Это главный актив системы оценки. Минимум для старта: 50-100 примеров.
Для стройфирмы это могут быть вопросы по типовым договорам, прайсам и регламентам. Чем качественнее золотой набор, тем надёжнее оценка. Раз в месяц стоит проверять его актуальность - если документальная база обновилась, старые эталоны устаревают.
Ragas умеет автоматически генерировать тестовые вопросы из ваших документов. Следующий код создаёт 100 тестовых примеров трёх типов: простые вопросы, требующие рассуждения и требующие синтеза нескольких источников:
from ragas.testset import TestsetGenerator
from langchain_openai import ChatOpenAI, OpenAIEmbeddings
generator = TestsetGenerator.from_langchain(
generator_llm=ChatOpenAI(model="gpt-4o"),
critic_llm=ChatOpenAI(model="gpt-4o"),
embeddings=OpenAIEmbeddings()
)
testset = generator.generate_with_langchain_docs(
documents,
test_size=100,
distributions={"simple": 0.5, "reasoning": 0.25, "multi_context": 0.25}
)
После генерации - обязательная ручная проверка. AI создаёт хорошие вопросы, но иногда ошибается в ответах. 10-20 минут проверки специалистом экономят часы разбора ложных тревог позже.
Для задач со специфической терминологией используют Argilla - платформу ручной разметки. Аннотаторы оценивают ответы модели по шкале 1-5.
AI-судья: настройка и калибровка
AI-судья работает хорошо только при правильной настройке. Три параметра определяют качество.
Выбор модели-судьи. GPT-4o и Claude Sonnet показывают 85-90% согласия с людьми на типичных задачах. Более дешёвые модели - 70-75%. Экономия на судье обходится дорого: ненадёжная оценка хуже, чем отсутствие оценки.
Промпт судьи. Должен содержать: чёткие критерии (что значит оценка 1, 3, 5 по шкале), примеры для каждого уровня, инструкцию «думай вслух» перед вынесением оценки.
Температура. Для оценки - 0.0. Предсказуемый результат важнее разнообразия.
Калибровка против человеческих оценок обязательна. Возьмите 100 примеров, соберите оценки живых людей и оценки AI-судьи, сравните совпадение. Коэффициент согласия выше 0.6 считается приемлемым для автоматической оценки.
Важная ловушка: AI-судья склонен давать более высокую оценку тому ответу, который идёт первым при сравнении двух вариантов. Как исправить: запускайте сравнение дважды с переставленными вариантами и берите среднее.
Интеграция в процесс разработки
Качество AI не должно проверяться вручную перед каждым релизом. Правильный подход - автоматическая проверка при каждом изменении кода, так же как тесты для обычного программного обеспечения.
DeepEval встраивается в стандартный инструмент тестирования pytest. Следующий код проверяет, что RAG-система не выдаёт ответы, противоречащие исходным документам:
import pytest
from deepeval import assert_test
from deepeval.metrics import HallucinationMetric
@pytest.mark.parametrize("test_case", test_cases)
def test_no_hallucinations(test_case):
metric = HallucinationMetric(threshold=0.5)
assert_test(test_case, [metric])
Следующая команда запускает тесты и создаёт отчёт в стандартном формате JUnit. Если тест не прошёл - слияние кода в основную ветку блокируется автоматически:
deepeval test run test_rag.py --junit-xml report.xml
Это работает с GitHub Actions, GitLab CI и Jenkins без дополнительной настройки.
Стратегия: как не разориться на оценке
Запускать AI-судью на 100% запросов дорого. Рабочая стратегия - трёхуровневая.
Первый уровень: 100% запросов проходят быстрые проверки без AI. Длина ответа, запрещённые слова, правильность структуры JSON, время ответа. Стоимость около нуля, задержка меньше 1 мс.
Второй уровень: 10-20% запросов случайно выбирается для полноценной оценки AI-судьёй. При 10 000 запросов в день и стоимости $0.002 за оценку - это $20 в день.
Третий уровень: еженедельный просмотр 20-30 случайных диалогов живым человеком из команды. Этот шаг ловит то, что пропускают автоматические показатели.
Дополнительно: при аномалиях (низкие отклики пользователей, жалобы) автоматически добавляйте эти случаи в очередь полноценной оценки.
Реальный пример: как оценка поймала проблему до релиза
Представьте внутренний чат-бот для HR-службы компании в 150 человек. Бот отвечает на вопросы сотрудников по политикам, льготам и регламентам. После обновления промпта разработчик субъективно посчитал, что ответы стали лучше. Без eval это ушло бы в продакшн.
После запуска оценки на 80 примерах из золотого набора: faithfulness упал с 0.91 до 0.74. Конкретная причина - бот начал добавлять детали о льготах, которых не было в документах. Это галлюцинация на HR-данных, которая могла привести к юридическим вопросам и недовольству сотрудников.
Разработчик увидел это в отчёте DeepEval через 20 минут после запуска тестов, откатил изменение и исправил промпт. Без eval это обнаружили бы через несколько дней по жалобам сотрудников - с уже испорченным доверием к инструменту.
Именно этот сценарий повторяется в большинстве компаний, которые внедряют AI без оценочной инфраструктуры: проблема обнаруживается поздно и дорого.
Типичные ошибки
Оптимизация под судью вместо реальной пользы. Если промпт настраивается для получения высокого балла от AI-судьи, система научится «обманывать» метрику. Симптом: оценки растут, пользователи жалуются. Защита: периодически меняйте судью и критерии.
Путаница между метрикой и целью. Faithfulness 0.95 не означает, что пользователь решил свою задачу. Автоматические показатели - приближение к цели, а не сама цель.
Устаревший золотой набор. Если документальная база обновляется, старые правильные ответы устаревают. Нужна политика обновления: ежемесячная проверка актуальности эталонов.
Экономия на модели-судье. GPT-4o-mini с плохо настроенным промптом даёт ненадёжные результаты. Лучше уменьшить долю проверяемых запросов, но не ухудшать качество оценки.
Частые вопросы
Ragas или DeepEval - что выбрать?
Они дополняют друг друга. Ragas - специалист по оценке систем поиска с генерацией. DeepEval - более широкий инструмент с оценкой агентов, встроенной интеграцией в процессы разработки и гибкими критериями. Типичный выбор: Ragas для показателей качества RAG, DeepEval для автоматических тестов и проверки агентов.
Как оценивать систему, если документы постоянно меняются?
Используйте показатели без эталона: faithfulness и answer_relevancy. Они не зависят от фиксированных правильных ответов - только от текущего состояния документов и ответа. При смене базы достаточно перегенерировать тестовый набор.
Сколько примеров достаточно на старте?
50 примеров дают статистически значимый сигнал и ловят грубые регрессии. 200 примеров ловят тонкие изменения в 5-10% качества. Начинайте с 50 и наращивайте.
Как снизить стоимость AI-судьи?
Три способа: более дешёвая модель с тщательно настроенным промптом (экономия в 10 раз при потере около 15% точности); кеширование результатов для одинаковых тест-кейсов; запуск оценки только для изменившихся тест-кейсов, а не всего набора.
Как поймать деградацию при обновлении промпта в продакте?
Привязывайте оценки к конкретным версиям промпта. При выходе новой версии автоматически запускайте оценку на 200 запросах из продакта за последние сутки. Если средний показатель верности упал на 0.05 и больше - алерт и автоматический откат.
Что дальше
Начать проще, чем кажется. Первый шаг: запустить Ragas на 50 реальных запросах из вашего чат-бота или RAG-системы. Это покажет базовый уровень верности и релевантности. Если faithfulness ниже 0.75 - есть явная проблема с галлюцинациями. Выше 0.90 - система работает надёжно, можно заниматься тонкой настройкой.
После построения оценочного процесса следующий шаг - наблюдение за продактом в реальном времени: Observability и логирование LLM: Langfuse, LangSmith, Helicone, Arize Phoenix.
Основы RAG, качество которого нужно измерять: Сверхпро: RAG для начинающих.
Разбор подходов к улучшению качества: Fine-tuning vs RAG vs Prompt Engineering.
AI Компас (t.me/kosmoslab_ai) - канал для предпринимателей в РФ и СНГ, которые применяют AI в своём бизнесе без программиста. Разбираем инструменты и схемы - без курсов и теории.