Как мы сделали универсального ИИ-аудитора для RAG-ботов и избавили аналитиков от часов ручной работы

Бота, который выбирает из заготовленных реплик, тестировать легко, но как только бот начинает генерировать ответ сам – с помощью RAG-поиска по базе знаний, – ответ каждый раз новый, и тестирование превращается в проблему.

Раньше это делали вручную: аналитик читает вопрос, читает ответ бота, сверяет его с документами и с эталоном (если он есть) и решает – верно, неверно, наполовину верно. Но представьте, что у вас датасет в несколько сотен вопросов, который нужно прогонять заново после каждого изменения промпта, модели или базы знаний...

Я разработала требования к функционалу, который должен снять эту проблему. В результате в нашем инструменте для обучения моделей появился ИИ-аудитор. Расскажу, почему мы решили доверить эту работу самой LLM, и как все в итоге устроено.

Сравнивать ответ бота с эталоном с помощью простого совпадения слов нельзя: два ответа могут быть написаны по-разному и оба быть верными, а могут звучать почти дословно похоже – и один из них при этом с фактической ошибкой. Оценка такого ответа – по сути, экспертная задача: нужно понять смысл, сверить его с контекстом, найти противоречия.

Идея поручить эту работу ИИ (LLM-as-a-judge) – не наше изобретение, о ней в последние пару лет написано уже немало, а некоторые метрики пришли в наш инструмент из открытых RAG-фреймворков – например, метрики Faithfulness и Context Relevancy (подробнее о них ниже).

Прогнать тестовый скрипт через LLM-судью для одного проекта – это одно, а интегрировать его как настраиваемый инструмент в платформу, где сосуществуют десятки ИИ-проектов с разными данными, разными требованиями к точности и разными эталонами (а где-то и вовсе без) – совсем другое.

В итоге в инструмент вошло пять сценариев, ниже расскажу, зачем нужен каждый из них.

Самый простой для тестирования кейс: для каждого вопроса в тестовом датасете есть подготовленный правильный ответ – эталон. LLM-аудитор сравнивает ответ бота с эталоном по заданному набору категорий качества.

На практике эталон есть далеко не всегда – особенно когда оцениваются ответы из живых диалогов с пользователями, а не из подготовленного датасета. Поэтому мы заложили возможность оценить ответ без эталона: в таком случае аудитор анализирует адекватность, полноту и отсутствие противоречий по косвенным признакам.

Этот сценарий мы добавили из конкретного запроса клиентов: часто нужно понять не «хорошо или плохо», а «какая из двух моделей, промптов или конфигураций лучше» – например, после смены LLM или доработки промпта. Тот же LLM-аудитор в этом случае просто выбирает более удачный из двух ответов, и по датасету собирается таблица побед, поражений и дельты.

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

Отдельно от корректности ответа бывает, что ответ по теме и частично верен, но содержит факт, которого нет в предоставленных документах, – модель «досочинила». Для банковских, медицинских и подобных сценариев такая ошибка даже критичнее, чем просто неполный ответ.

В разделе «Метрики» можно создать свой набор критериев оценки – вручную, клонированием готового шаблона или загрузкой из JSON. Предусмотрено три типа метрик:

● рубрики – набор критериев с весами (например, достоверность, полнота, естественность), где сумма весов дает итоговую оценку в виде балла или текстового обозначения (например, «высокая/низкая»)

● категории – модель относит ответ к одной из заранее описанных категорий (например, «ответ верный и полный», «ответ вводит в заблуждение»)

● сравнительная таблица – модель выбирает, какой из двух ответов лучше, и на выходе получается таблица побед, поражений и дельты между конфигурациями.

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

Сам процесс укладывается в четыре шага:

Результат – таблица для рубрик и категорий со статистикой по всему датасету, а по клику – детали по каждому примеру.

Отдельно можно задать порог по нужному критерию – тогда все строки, которые ему удовлетворяют, подсвечиваются зелёным, а остальные красным, и на десятках проверок сразу видно, что стоит перечитать внимательно, а что можно пропустить.

Команда внедрения уже применяет функционал на реальных ИИ-проектах – там, где RAG-бота нужно быстро протестировать после смены модели, промпта или базы знаний, и где раньше на это уходили часы ручной сверки. Аналитик по-прежнему нужен – но не для того, чтобы читать каждый ответ, а чтобы разобраться в тех немногих случаях, которые LLM-аудитор пометил как сомнительные.

Если вы хотите внедрить или повысить точность внедренных ИИ-ботов с RAG-поиском, можем показать, как все работает на бесплатном демо.