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

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

Что такое RAG и каков его пайплайн

Если упрощенно, то RAG состоит из двух ключевых компонентов:

Модуль поиска (retrieval) — это процесс извлечение релевантных документов из базы знаний. Но просто поиском эту часть назвать было бы нечестно, так как саму качественную базу знаний надо сначала создать (и в ней могут быть самые разные по своему типу документы), потом проиндексировать, и только поверх уже идет поиск. И каждая из описанных задач — может быть сложной, но о них всех мы поговорим чуть позже.

И, собственно, генеративная модель (generation) — генерация ответа на основе анализа найденных данных.

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

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

Зачем нужна оценка RAG-пайплайнов

В целом, первично RAG можно попробовать оценить end-to-end, а именно: собрать логи пар запросов и ответов и попробовать людьми это оценить. Оценка тоже простая (но у всех варьируется): получен ли финальный ответ на вопрос, нет ли ошибок и нравится ли стиль. Если это заработает хорошо (что вряд ли, но бывает), то можно открывать шампанское, но, скорее всего, нам захочется что-то сильно улучшить, а значит нужно будет закатать рукава и обвесить процесс датчиками и снимать с них показания, итеративно улучшая затем все вокруг.

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

Давайте пройдемся по каждой из групп отдельно.

1. Качество данных

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

Дальше встает вопрос разбиения (чанкинг, chunking) — процесса разрезания всех наших данных на некие частички, по которым затем и производится поиск. Здесь нет готового рецепта для всех сразу, слишком длинные чанки замедляются поиск, слишком короткие теряют смысловые связи, поэтому экспериментировать на своих данных здесь придется.

После разбиения необходимо по каждому чанку построить эмбединг (embedding) — векторное представление этого кусочка документа и положить их в подходящую БД. Качество полученных эмбедингов напрямую влияет на точность поиска.

Для оценки самой базы знаний нужен пайплайн из скриптов с автоматическими проверками: например, на анализ дубликатов через Cosine Similarity эмбеддингов, оценка читаемости текста (Flesch Reading Ease), поиск устаревшей информации и противоречий через сравнение семантически близких фрагментов.

2. Производительность модели

Эта группа включает в себя параметры, которые отделяют просто хорошую работающую технологию от прода и реальной жизни. Сюда можно отнести скорость ответа системы, мониторинг и аптайм, расчет потребления ресурсов (CPU/GPU/RAM/диск) и вопросы масштабируемости. Уложимся ли мы в нужную latency, если база знаний вырастет в два раза? А в чем именно будет просадка — индексация, поиск, генерация? Получится ли не упасть после одновременно прилетевшего множества запросов от 10 человек? 100? 1000?

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

Это всегда некий компромисс (trade-off — если на модном) между качеством и скоростью. И именно неумение нащупать подходящий для себя инженерно-бизнесовый баланс сгубило множество внедрений и проектов: делать хайлод и жечь ресурсы там, где оно в принципе не планировалось или, наоборот, сделав хороший прототип и не сумев ему обеспечить нужную производительность.

3. Релевантность ответов

Это ключевая группа эффективности всей RAG-системы, которая напрямую влияет на пользовательский опыт и доверие.

Для оценки релевантности важны как автоматические метрики (например, BLEU, ROUGE, BERTScore), так и подключение к оценке человеков-экспертов, которые либо создают готовые бенчмарки качества, либо вручную проверяют ответы. А лучше и то и то.

Ответы должны быть точными, полными, актуальными, безопасными и стилистически адаптированными к аудитории. Стилистическая адаптируемость важна, так как база знаний может включать документы самых разных типов — от ГОСТов и служебных записок до писем и неформальных чатиков с распоряжениями. А вот на выходе мы должны получить не смесь надерганных знаний, а единый правильный ответ, с чем LLM и справляются особенно хорошо.

Не менее важно оценивать стабильность и повторяемость ответов. Чем стабильнее будут ответы системы, тем проще оценивать ее качество и улучшаться.

4. Безопасность

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

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

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

Разбор типичного RAG-пайплайна

С метриками более-менее понятно, давайте разберем конкретный пайплайн построения RAG на пальцах.

Предобработка документов

Собираем данные, парсим интернет, если это требуется. Затем очистка, нормализация текста, разбиение данных на чанки (chunking).

Пример софта: Apache Tika для извлечения текста, Textract, PDFMiner, spaCy или NLTK для лингвистической обработки

Системы векторного поиска

Когда данные подготовили, их нужно куда-то заскладировать, а именно — построить по ним вектора и положить в подходящую БД с поиском по векторным индексам.

Пример софта: FAISS, Milvus, Pinecone, Weaviate, Qdrant и Chroma

Выбор LLM

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

Сейчас есть множество открытых моделей для локального развертывания с отличным качеством, например: Qwen, Mistral, LLaMA. Перед тем как выбирать конкретную, возможно сначала стоит прогнать на людях, чтобы оценить какая наиболее подходит под ваш домен — так будет проще в дальнейшем.

Промпт-инжиниринг для RAG

Промптинг — мощнейшая штука, очень сильно влияющая на качество генерации. Поиграться можно как вручную или с прогоном пачки результатов на экспертах, так и при помощи спецсофта: LangChain, Guidance, PromptPerfect. Ну и в целом, в интернете полно качественных гайдов о том, как писать промпты (рекомендую те, что выпускают ведущие лаборатории мира, например, моя любимая Anthropic), их как минимум стоит разок посмотреть.

Постобработка результатов

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

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

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

Пример софта: RAGAS, EvalHarness, LLaMAEval, TruLens.

Если требуется оценка людьми, создание разного рода бенчей или оценка голой LLM, то стоит присмотреться к Label Studio и ABC Elementary. И то и то — софт для быстрого создания интерфейсов и оценки любой сложности пайплайнов. Первые заграничный опенсурс, вторые российский корпоративный онпрем и сервис полного цикла.

Вывод в прод — тесты и оценка

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

Пример софта: Apache JMeter, Grafana/Prometheus для мониторинга

Так как моя статья все еще про оценку RAG-пайплайнов и в более широком смысле выбор LLM, то распишу немного детальнее их.

Инструменты оценки RAG-систем и LLM

В целом, и LLM и RAG итогово можно оценивать одинаково — по набору метрик. Это может быть бинарный ответ (да/нет), либо оценка (от 1 до 5). Вот примеры метрик: актуальность ответа, полнота информации, достоверность, краткость/детальность, структурированность, понятность, практическая применимость, безопасность контента, нейтральность тона и многие-многие другие, подбираемые под конкретную задачу.

Можно оценивать конкретно сам конечный ответ, можно оценивать промежуточные звенья, можно делать e2e SBS (side-by-side) — сравнение ответов разных версий RAG'а. Какая больше понравилась, та и пошла дальше в прод.

Поэтому при разработке системы оценки RAG и LLM важно обеспечить следующие ключевые компоненты:

• Гибкий интерфейс для разметки и оценки данных, позволяющий быстро адаптироваться под различные метрики и сценарии использования

• Инструменты для координации работы экспертов-оценщиков, включая распределение заданий и контроль качества, сбор обратной связи

• Система сбора и анализа метрик с возможностью генерации детальных отчётов

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

Кажется, все.

И вот просто списком так называемые лучшие практики, которые мне показались уместно добавить в статью и на которые стоит обратить ваше внимание в процессе.

Просто по три совета в каждой части

Индексация:

• Пробовать гибридные подходы к чанкингу (по размеру + семантический)

• Внедрить систему версионирования документов в базе знаний

• Сохранять метаданные и связи между чанками

Поиск:

• Комбинировать векторный и keyword поиск

• Использовать reranking для улучшения результатов

• Внедрять повсеместный кеш, где он уместен

Генерация:

• Разработать систему промптов с четкими инструкциями

• Внедрить валидацию ответов — как другими промптами, так и npl-хардкором

• Ввести метрики и работать над их улучшением

Эксплуатация:

• Вести мониторинг всех компонентов

• Собирать обратную связь от пользователей — привычные всем лайк/дизлайк после получения ответа (или более сложную оценку)

• Регулярно актуализировать базу знаний, проводить бенчи на просадку

Финал и заключение

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

Спасибо.

С наступающим Новым годом!

Если вам понравилось, то вот другие мои статьи на смежные темы:

Нам нужен RAG, вам нужен RAG: как встроить LLM туда, где она не нужна — статья о том, когда RAG не нужен

Как LLM меняют архитектуру систем: от простых дата-пайплайнов к интеллектуальным автономным агентам — дополненная мной статья от Anthropic о применении LLM в архитектурах приложений и что на самом деле понимается под агентами