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

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

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

Работа RAG состоит из трёх этапов:

• поиск — извлечение релевантных документов;
• дополнение — добавление найденных фактов в контекст;
• генерация — создание итогового ответа.

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

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

Чанки — это сегменты текста, разбитые на токены. Токен — это не символ и не слово, а единица разбиения, зависящая от токенизатора модели. Для разных языков и алфавитов количество токенов на слово может сильно различаться.

Способ разбиения зависит от структуры данных:

• для художественных или HTML-текстов — по абзацам;
• для структурированных текстов — по знакам препинания;
• для сложных документов — по фиксированному количеству токенов.

После векторизации чанки загружаются в векторную базу данных. При запросе система находит наиболее релевантные фрагменты и передаёт их в LLM для генерации ответа.

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

Оценка RAG строится по трём основным направлениям: качество поиска, точность ответа и качество изложения.

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

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

Эти метрики помогают понять, насколько эффективно работает retrieval-часть RAG. Если LLM работает хорошо, но RAG даёт сбои, стоит пересмотреть способ разбиения на чанки и качество поиска.

Для расчётов используется сравнение с золотым стандартом — ответами, подготовленными экспертами.

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

• Factual Accuracy — доля фактически верных утверждений в ответе.
• Отсутствие галлюцинаций — проверка, не добавляет ли модель вымышленную информацию.

Для оценки часто используется LLM-арбитр — отдельная модель, которая анализирует сгенерированный ответ. Этот подход не идеален, но хорошо работает в сочетании с автоматическими метриками и ручной проверкой.

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

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

В ПСБ качество изложения пока оценивается вручную. Однако можно частично автоматизировать процесс, создав размеченные наборы «вопрос-ответ» с указанием источников.

Метрики для компонентов RAG

Каждый элемент архитектуры можно оценивать отдельно.

Метрики для чанков:

• размер чанка — баланс между достаточным контекстом и избыточным шумом;
• смысловая цельность — зависит от метода разбиения;
• перекрытие контекста — важно при использовании «скользящего окна», чтобы не терялись связи между фрагментами.

Для разбиения можно использовать LlamaIndex, LangChain или LLM, разделяющую текст по смыслу. «Скользящее окно» (например, 200 токенов с перекрытием 50) помогает сохранить контекст на границах чанков.

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

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

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

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

Чтобы понять, где LLM может галлюцинировать, можно использовать logprobs — вероятности предсказания токенов. Например, на вопрос «Небо какое?» модель может выдать:

• «Небо чистое» — logprob: –1,6;
• «Небо голубое» — logprob: –0,96.

Более высокая вероятность указывает на предпочтительный ответ. Однако logprobs — не гарантия правдивости, а лишь эвристика.

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

• уменьшением температуры;
• улучшением retrieval (повышением recall и precision);
• использованием grounded prompting;
• требованием цитирования источников;
• внедрением правил отказа при недостатке данных.

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

Основные инструменты:

• RAGAS — автоматическая оценка без эталонов;
• TruLens — мониторинг и трассировка LLM-приложений;
• LangSmith — отладка цепочек LangChain;
• собственные решения — скрипты, дашборды, CI/CD.

В ПСБ используется RAGAS из-за удобного интерфейса, поддержки LangChain и набора метрик. В перспективе планируется разработка внутреннего инструмента, так как существующие решения не всегда соответствуют требованиям безопасности.

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

Тестирование RAG следует строить по пирамиде:

• Компонентное тестирование — проверка отдельных частей: LLM, векторная БД, retrieval-настройки.
• API-тесты — нагрузка, количество возвращаемых чанков и токенов.
• E2E-тесты — проверка пользовательских сценариев.
• Ручное тестирование — неизбежно на этапах оценки качества и безопасности.

Цикл оценки качества

Оценка RAG — это непрерывный процесс:

• подготовка тестового датасета (генерация 100–1000 вопросов с помощью LLM);
• запуск RAG и сбор ответов с найденными документами;
• расчёт автоматических и ручных метрик;
• анализ результатов и выявление узких мест;
• улучшение системы.

Цикл нужно повторять регулярно.

Автоматические vs ручные метрики

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

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

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

Для контроля качества полезно использовать:

• дашборды с ключевыми метриками;
• графики трендов качества во времени;
• A/B тестирование разных версий системы;
• heat maps проблемных зон.

Бизнес-ценность оценки RAG

Оценка качества RAG важна не только технически, но и с точки зрения бизнеса:

• Доверие — RAG повышает уверенность в точности ответов.
• Эффективность — сотрудники быстрее находят нужную информацию.
• Безопасность — снижается риск ошибок за счёт использования проверенных источников.
• Масштабируемость — систему легко внедрять в новые подразделения.

В отличие от файнтюнинга, RAG не требует больших затрат и позволяет быстро улучшить, например, чат-бот контактного центра.

Итоги

• 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 ещё только начинают внедрять, это новая земля для айтишников. Если вам есть что рассказать о своём опыте работы с методом — пишите в комментариях. Думаю, другим читателям это тоже будет интересно.