Когда RAG на горе свистнет: архитектура, метрики оценки и практика тестирования в ПСБ

Одна из ключевых проблем ИИ — склонность к «галлюцинациям», то есть к генерации убедительно звучащих, но ложных ответов. Яркий пример на картинке :) Как это можно исправить или улучшить? Есть разные способы. Одно из самых простых решений, позволяющих значительно повысить точность и достоверность ответов, — RAG (Retrieval Augmented Generation). Это генерация с дополненной выборкой. 

Меня зовут Михаил Костецкий, я управляющий эксперт отдела обеспечения качества в ПСБ. Мы в коллегами сейчас тоже пробуем использовать технологию RAG в разных задачах — в своей статье я хочу поделиться этим опытом. Буду рад, если моя статья станет полезна тем, кому предстоит работать с методом. 

Зачем нужен RAG?

Как мы видим, на картинке выше ИИ пытается определить то, что ему даже пока не показали :) Выглядит забавно, и такие галлюцинации — как раз причина, по которой ИИ пока не подходит для повсеместного использования. Особенно в таких серьёзных сферах, как финтех. ​​Галлюцинации возникают, потому что ИИ-модели обучены на ограниченном наборе данных и иногда «додумывают» ответ, когда не знают точных фактов.

Чем здесь нам может помочь RAG? Он заставляет модель искать информацию в вашей собственной базе знаний (в документах, базах данных и так далее), а уже затем составлять ответ на основе этих проверенных источников. 

Как устроен RAG? По сути, он выполняет три действия:

• поиск — находит документы;

• дополнение — обогащает ответ фактами из базы знаний;

• генерация — формулирует ответ.

Как я уже говорил, источником информации для RAG становится ваш собственный массив данных — будь то база данных, хранилище документов или сайт, из которого вы можете выгрузить содержимое в файлы. Но чтобы быстро извлекать информацию из этого массива, данные нужно подвергнуть векторизации.

Архитектура RAG

Итак, у вас есть набор данных — они могут быть структурированные (например, база данных, для которой прописали «ключ-значение») или неструктурированные (массив из книги и тому подобное). 

Этот массив данных нужно разделить на чанки — сегменты текста, разбитого на токены в соответствии с определённым алгоритмом. Важный момент: под токеном мы понимаем не букву. Токен — единица разбиения, зависящая от токенизатора модели; в разных языках соотношение символов/слов к токенам различается, и для нелатинских скриптов часто требуется больше токенов.

Способ разбиения текста на фрагменты определяется его структурой. Для html-документов или художественных текстов подходит разделение по абзацам. Структурированные материалы с пунктами логично делить по знакам пунктуации (точка, точка с запятой). В случае сложноорганизованных документов рекомендуется использовать разбиение по количеству токенов.

Когда данные разделены на чанки, их передают в векторную базу данных с помощью эмбеддинг-модели. Система извлекает релевантные фрагменты (чанки) из векторного индекса и добавляет их в контекст генерации ответа. 

Как оценивать качество работы RAG?

По каким критериям судить о качестве RAG? Выделю три критерия.

1. Качество поиска — нашла ли модель нужные документы. Здесь важны две метрики:

• Hit Rate — показывает, извлекает ли система релевантные документы в принципе.

• Mean Reciprocal Rank (MRR) — оценивает, насколько высоко в результатах поиска находится самый подходящий документ. Чем он выше, тем больше вероятность получить точный ответ.

Вместе эти метрики показывают, как хорошо система находит информацию и насколько правильно её ранжирует.

Бывает, что LLM, которую вы используете, вас полностью устраивает, но вот при работе с RAG она чудит в плане понимания документов. Тогда стоит обратить внимание то, как разделили документы на чанки, а затем — на качество поиска.

Что касается расчётов, то мы применяем автоматический расчёт и сравнение с золотым стандартом. То есть здесь тоже, как это часто бывает, лучший референс — то, что написал человек.

2. Точность ответа — правильно ли модель поняла документы. 

Ключевые критерии:

Factual Accuracy — процент фактически верных утверждений в ответе.

Отсутствие галлюцинаций — проверка, не добавила ли модель вымышленной или несоответствующей информации.

Основной подход для оценки точности — LLM-арбитр. Для этого другая языковая модель проверяет и оценивает сгенерированный ответ. Хотя этот подход тоже неидеален (арбитр тоже может ошибаться), он хорошо работает в сочетании с автоматическим подсчётом метрик и последующей ручной верификацией.

3. Качество изложения — насколько понятен и адекватен ответ.

Важные критерии:

• ясность и структура — ответ должен быть читаемым и логично подложенным;

• релевантность — ответ должен соответствовать вопросу без отклонений;

• полезность — тут мы оцениваем, решил ли ответ проблему пользователя.

В части оценки качества изложения конечной информации мы в ПСБ пока тоже прибегаем к ручной оценке. Но можно ли здесь что-то автоматизировать? Да — например, создать набор «вопрос-ответ» с разметкой, из какой области документа извлекать нужную информацию, и по этому шаблону прогонять.

Оцениваем RAG: метрики для компонентов архитектуры

Для каждого компонента RAG есть свои методы оценки. Например, посмотрим на метрики для чанков:

• Размер чанка — оптимизация между контекстом и шумом.

• Смысловая цельность — зависит от способа разделения на чанки. Здесь нет идеального подхода, алгоритмы могут быть разными.

Один из самых дорогих и ресурсоёмких подходов — семантическое разделение, когда кусочки текста делит по смыслу LLM, установленная в контур. Другой подход — «скользящее окно». Здесь чанки создаются с перекрытием: например, первый содержит токены с 1-го по 200-й, следующий — с 150-го по 250-й. За счёт этого пересечения система захватывает больше контекста, что повышает точность поиска. Можно применить и структурное разделение текста (по знакам препинания) или вовсе поделить тексты на фрагменты фиксированного размера.

• Перекрытие контекста — анализ границ между чанками.

Для работы с чанками есть разные инструменты — например, LlamaIndex и LangChain.

Метрики для эмбеддингов:

• семантическое сходство — косинусная близость векторов;

• разрешающая способность — различение моделью тонких смысловых оттенков;

• качество кластеризации.

Есть алгоритмы, такие как TF-IDF или BM25, которые дают лексическую релевантность (по терминам) и в гибридном поиске хорошо дополняют векторный поиск.

Уверенность системы 

Итак, у вас есть LLM. Вы хотите понять, где и как она сама, без RAG, галлюцинирует. А также — как её настроить, выбрать оптимальную температуру и так далее. Можно использовать Logprobs как один из сигналов (например, для выбора из фиксированного набора ответов или как эвристику), но это не гарантия истинности. Для фраз корректно сравнивать суммарный/средний logprobs по токенам при фиксированных кандидатах.

Покажу, как это работает, на простом примере. Вы задаёте вопрос: «Небо какое?» И далее вы видите в логах — это очень удобно с точки зрения тестирования — ту вероятность, с какой модель может предсказать тот или иной ответ. Так, вероятность ответа «Небо чистое» — –1,6 , а «Небо голубое» — –0,96. То есть наиболее вероятный ответ — «Небо голубое».

Ещё полезны такие проверки: вы задаёте LLM вопрос о данных, на которых она не была обучена. Узнать, что модель даёт ответы по данным, на которых её не обучали, не так сложно: в описании на HuggingFace обычно указаны все датасеты. Если модель выдумывает, то её нужно настроить. Например, снижение температуры уменьшит вариативность. Ещё лучше бороться с галлюцинациями через улучшение retrieval (recall/precision), grounded prompting, цитирование и проверку источников, а также правила отказа (abstain) при недостаточном контексте.

Инструменты для оценки RAG

Я уже упоминал некоторые, но здесь коротко повторюсь и расскажу, для чего они нужны:

• RAGAS — позволяет проводить автоматическую оценку без эталонов;

• TruLens — обеспечивает мониторинг и трассировку LLM-приложений;

• LangSmith — отлаживает и оценивает цепочки LangChain;

• собственные решения — различные Python-скрипты, дашборды, CI/CD интеграции.

Мы в ПСБ сейчас работаем с RAGAS. Выбрали его, потому что нам понравился набор предустановленных метрик, удобный интерфейс и работа с LаngChain. В будущем планируем использовать и собственное решение, потому что ряд библиотек не отвечает нашим стандартам. 

Тестирование RAG

Возьмите любую архитектуру, информационную систему — всё это можно переложить на пирамиду тестирования.

Внизу пирамиды — unit-тесты. При этом для RAG в unit-тестах в качестве unit выступают не кусочки кода: здесь речь идёт о компонентном тестировании. Всю архитектуру мы делим на компоненты и можем их протестировать: отдельно посмотреть LLM или векторную базу данных и настройки её извлечения.
Выше — API-тесты, можно проверить нагрузку, посмотреть ответы и количества чанков и токенов, которые возвращаются в ответе.
Далее — E2E тесты — можно и нужно проверять пользовательские сценарии.

И, конечно же, без ручного тестирования тоже не обойтись.

Оценка качества RAG

Цикл оценки RAG можно разделить на такие этапы:

• Подготовка тестового датасета — с помощью LLM вы генерите от сотни до тысячи различных вопросов.

• Запуск RAG на тестовых вопросах и сбор ответов и найденных документов.

• Сбор и расчёт метрик — можно применять автоматические и ручные метрики.

• Анализ результатов — выявление проблем и узких мест.

• Улучшение системы.

Этот цикл нужно постоянно повторять.

Метрики: автоматические или ручные?

Нет единственно верного ответа.

Автоматические метрики — быстрые и масштабируемые, а также объективные. Ручные — медленные, но зато более точные и позволяют учитывать контекст. Ручные метрики лучше оценивают качество изложения в ответах. Идеально — использовать гибридный подход, где автоматика позволяет масштабироваться, а эксперты помогают с оценкой в сложных случаях.

Однако добавлю, что автоматика подходит не для каждой отрасли. В финтехе её можно использовать с ограничениями. У нас повышенные требования к защите персональных данных — их нужно вычищать из базы знаний, чтобы они никуда не утекли из контура. А автоматика, увы, не всегда понимает, какие данные перед ней — персональные или нет. Да, есть некоторые инструменты, которые умеют распознавать персональные данные, но 100%-ную точность в их работе гарантировать невозможно. Так что ручная проверка в подобных случаях даёт лучший результат.

Визуализация результатов

Когда у вас есть результаты тестирования и оценки качества RAG, вы можете их визуализировать. Что здесь можно использовать?

• Вести дашборды с ключевыми метриками — обеспечивают трекинг качества в реальном времени.

• Отслеживать тренды качества over time — помогают выявлять улучшения и регрессии.

• Сравнивать разные версии системы — A/B тесты улучшений.

• Составлять Heat Maps проблемных зон.

Можем оценивать, но зачем?

Ещё расскажу главное — в чём бизнес-ценность оценки качества RAG.

Тут есть несколько аспектов:

• Доверие. Да, RAG повышает доверие бизнеса к информации, которую представляет модель из коробки.

• Эффективность. Поиск с применением RAG экономит время сотрудников.

• Безопасность. RAG позволяет снизить риск ошибки за счёт использования собственных данных при поиске.

• Масштабируемость. Систему поиска с RAG легко внедрять в новые отделы.

Добавлю, что сегодня немногие компании могут себе позволить дообучение моделей. Файнтюнинг — это дорого и затратно по времени, для него нужно собрать много датасетов. В то же время RAG позволяет бизнесу что-то улучшить здесь и сейчас. Допустим, прокачать чат-бот контактного центра, чтобы пользователи быстрее получали ответы, и эти ответы были точны и корректны. 

Напоследок покажу, как может выглядеть результат оценки на конкретном примере вопроса и полученного ответа:

Как видно, по двум параметрам система справилась, но по части точности есть ошибка.

Подытожим

Краткий пересказ всего, что я написал выше:

• RAG — технология, а не магия. Её качество можно и нужно систематически оценивать.

• При оценке важно учитывать поиск, точность и качество изложения.

• Автоматические и ручные метрики дополняют друг друга.

• Оценка RAG — не разовое событие, а непрерывный процесс с циклом улучшений.

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