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 в архитектурах приложений и что на самом деле понимается под агентами
