В предыдущих статьях серии (Часть 1, Часть 2) мы обсудили концепцию корпоративной GenAI-платформы и подходы к ее разработке. Теперь перейдем к одному из ключевых компонентов такой платформы — интеграции знаний с помощью Retrieval-Augmented Generation (RAG). 

Что такое RAG и зачем он нужен

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

Зачем RAG корпоративной платформе? Без RAG любая LLM ограничена знаниями из своего тренинга (часто актуальность информации ограничена датой обучения) и объемом контекста. В бизнес-сценариях модель должна отвечать на вопросы, опираясь на внутренние документы компании, свежие данные и специфические доменные знания. Перенастраивать или дообучать LLM под каждую порцию новых данных дорого и сложно, а просто скормить модели всю базу знаний в промпте нельзя из-за ограничений контекстного окна. RAG решает эту проблему элегантно: мы соединяем LLM с поиском по базе знаний. 

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

Архитектура retrieval-уровня: эмбеддинги, top‐K и векторная БД

Основу RAG составляет специальный слой поиска знаний — retrieval-уровень. Он отвечает за то, чтобы быстро найти в корпоративном хранилище нужные данные под запрос. Рассмотрим, как он устроен:

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

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

2. Поиск (Retrieval). Когда пользователь задает вопрос, платформа выполняет поиск по векторной базе. Запрос пользователя тоже превращается в вектор (той же эмбеддинг-моделью, что и документы). Затем система вычисляет степень близости запроса к каждому векторизованному фрагменту (например, косинусное сходство). Из всей базы выбирается несколько наиболее близких фрагментов — обычно берут top K результатов, где K — заданное число документов, например, 5 или 10. Эти топ-K фрагментов считаются самым релевантным контекстом для ответа. В простейшем случае на этом retrieval заканчивается, так как мы получили нужные кусочки знаний.

3. Генерация ответа. На последнем этапе конвейера в ход снова идет LLM. Модели передается расширенный промпт, состоящий из исходного вопроса и текстов найденных фрагментов знаний. Теперь LLM имеет под рукой и формулировку задачи, и справочный материал. Используя оба источника (контекст и свои внутренние знания) модель генерирует ответ пользователю. Как правило, мы дополнительно направляем модель через подсказку: просим ее опираться только на предоставленный контекст и цитировать источники. Это важно для достоверности: хороший ответ на основе RAG обычно содержит ссылки на документы или цитаты, чтобы пользователь мог проверить факты.

На практике описанная схема может усложняться. Например, в Advanced RAG добавляют дополнительные шаги до и после поиска для улучшения. Можно сначала выполнить черновой поиск по широкой базе, затем сгенерировать на базе топ-K фрагментов гипотетический ответ с помощью LLM, и уже его использовать как уточненный запрос для второго прохода поиска (подход HyDE, Hypothetical Document Embedding). 

Также применяют многоступенчатый отбор: сперва выбирают топ-50 фрагментов быстрым методом, затем более точным алгоритмом ранжируют их и оставляют, скажем, топ-5. Цель этих ухищрений — повысить релевантность финального контекста, чтобы в нем точно нашлась нужная информация для ответа. Тем не менее, базовые компоненты retrieval-уровня остаются теми же: эмбеддинги, векторное хранилище, поиск ближайших соседей и формирование контекста из top-K результатов.

Пример: генерация юридической справки с помощью RAG

Чтобы увидеть пользу RAG в реальном сценарии, возьмем юридический кейс. Представьте, что в большой компании сотруднику юридического отдела нужно подготовить справку по конкретному вопросу, например: «Какие ограничения накладывает закон о персональных данных на хранение клиентских сведений?» Без GenAI-платформы такой запрос потребовал бы ручной работы: юрист ищет нужные статьи закона, перечитывает их, составляет резюме. Это может занять часы. С внедрением RAG-подхода процесс упрощается до одного запроса в корпоративный чат-бот.

Как это работает. Внутренняя база знаний компании уже содержит необходимые документы: тексты законов, нормативные акты, внутренние политики. Когда юрист задает вопрос системе, та автоматически находит релевантные фрагменты, например, вытаскивает из Федерального закона о персональных данных конкретные статьи, относящиеся к вопросу, и пару пунктов из внутренних инструкций компании. Эти выдержки мгновенно передаются модели. LLM на основе полученного контекста формирует ответ — сгенерированную справку. В ответе будет пояснение, какие ограничения предусмотрены законом, и ссылки на соответствующие статьи (например, «...согласно статье 5 ФЗ-152, персональные данные должны храниться не дольше... »). Юрист получает четкий черновик справки буквально за несколько секунд. Ему остается только проверить ссылки и слегка отредактировать текст под официальный стиль. В итоге RAG позволяет существенно сэкономить время на поиск и обобщение юридической информации, а итоговый документ получается обоснованным ссылками на первоисточники, что повышает доверие к результату.

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

Практические проблемы: скорость, кеширование, актуальность данных

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

• Latency (задержка ответа). Добавление этапа поиска усложняет цепочку и может замедлить ответ. Если без RAG модель отвечала сразу, то теперь перед генерацией нужно выполнить векторный поиск, возможно, несколько. Время отклика растет на десятки-сотни миллисекунд, а то и секунды — в зависимости от размеров базы и скорости БД. 

  Для конечных пользователей корпоративного чат-бота лишние задержки нежелательны. Как минимизировать задержку? Во-первых, оптимизировать сам поиск: использовать быстрые approximate nearest neighbor алгоритмы, шардировать базу, держать часто используемые данные в памяти. Во-вторых, уменьшать объем контекста: лишние или слишком большие чанки замедляют обработку на этапе генерации, поэтому стоит хранить тексты в сжатом виде (например, заранее удалять стоп-слова, HTML-разметку) и ограничивать K разумными пределами. В-третьих, можно делать часть работы заранее: например, если запросы предсказуемы, формировать индекс под них заблаговременно (pre-caching результатов поиска). Наконец, правильная архитектура (параллелизация операций, асинхронные вызовы) поможет использовать время эффективно: пока LLM обрабатывает один запрос, уже можно начинать извлечение для следующего.

• Кеширование результатов. Один из самых простых и действенных способов ускорить систему — кеширoвать повторяющиеся запросы и ответы. В корпоративной среде часто разные пользователи задают похожие вопросы. Вместо того чтобы каждый раз проходить весь цикл (поиск и генерация), платформа может запоминать уже полученные ответы. Например, если вчера спрашивали: «Как предоставить отпуск за свой счет?» и система нашла и ответила, то сегодня на такой же вопрос можно мгновенно вернуть сохраненный ответ, минуя LLM. Правильно настроенный кеш резко снижает нагрузку и расходы: меньше обращений к дорогим моделям (особенно если это GPT-4 по API) и быстрее отдача для популярных запросов. Кешировать можно на разных уровнях: и финальные ответы, и промежуточные результаты (например, топ-кандидатов из поиска). Наш опыт показывает, что кеш вопросов-ответов отлично работает для FAQ-подобных сценариев, так как скорость возрастает, пользователи довольны. Нужно лишь не забывать заменять устаревшие элементы кеша, если информация изменилась.

• Актуальность знаний. RAG позволяет LLM быть в курсе свежих данных, но только при условии, что сама база знаний актуальна. Это еще один челлендж: поддерживать корпоративное хранилище векторных эмбеддингов синхронизированным с реальностью. Документы устаревают, появляются новые, и если их не добавить в индекс, модель про них не узнает. Классический пример — справочная информация: меняются законы, внутренние регламенты обновляются, появляются новые цены, продукты и т. д. Здесь важно выстроить процесс обновления индекса. Решение — автоматизация: интеграция с системами, откуда приходят данные (DMS, CRM и др.), и периодическая переиндексация. 

Некоторые платформы делают почти real-time обновление: как только документ изменен или добавлен, сразу пересчитывают его эмбеддинг и кладут в векторную БД. Если же такая мгновенность не нужна, достаточно запускать регулярное обновление (например, каждую ночь). Другой аспект актуальности — фильтрация по дате или версии. 

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

Кроме перечисленного, есть и другие технические нюансы: контроль максимального размера контекста (чтобы не переполнить вход модели), безопасность доступа (убедиться, что через RAG не утекут чувствительные данные пользователю, который не должен их видеть), мониторинг качества (LLM все равно может ошибаться, даже опираясь на данные). Эти вопросы тесно связаны с темой следующей статьи — guardrails.

Заключение: RAG как фундамент и взгляд вперед на guardrails

Мы рассмотрели, как Retrieval-Augmented Generation вписывается в корпоративную GenAI-платформу и решает проблему привлечения актуальных знаний для LLM. RAG-функциональность фактически становится фундаментом корпоративного AI-ассистента: без нее модель была бы отрезана от свежих данных и специфичных знаний компании. Настроив retrieval-уровень, мы получаем гибридную систему, которая умеет и красиво сформулировать ответ, и подкрепить его фактической информацией.

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

Впереди — обсуждение того, какие бывают guardrails, как они интегрируются в GenAI-платформу и как позволяют довести решение до требуемого уровня надежности и стабильности. RAG дал нашему корпоративному боту знания, а guardrails дадут ему разум и ответственность. 

Автор: Денис Прилепский — специалист по архитектуре ИТ-систем и трансформации ИТ-ландшафта, приглашенный эксперт онлайн-магистратур Центра «Пуск» МФТИ.