Объяснение базового процесса RAG: от сырых документов до обоснованных ответов

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

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

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

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

В следующих разделах эта концепция рассматривается с нуля.

Как на практике работает RAG

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

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

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

Выбор источника знаний

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

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

Перед индексацией чего-либо полезно задать несколько практических вопросов:

• Является ли информация точной и актуальной?
• Кто является владельцем этих данных?
• Может ли каждый пользователь их просматривать?
• Есть ли дублирующиеся или противоречивые версии?
• Требуют ли таблицы, изображения, сноски или юридические положения особого обращения?

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

Очистка и подготовка документов

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

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

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

Разделение документов на фрагменты

Модели языка и системы поиска обычно не обрабатывают целые книги, руководства или библиотеки документов целиком. Они лучше справляются с более мелкими фрагментами текста, называемыми чанками.

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

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

При разбиении текста на фрагменты по возможности следует учитывать структуру документа. Разделение по разделам, заголовкам, абзацам или парам вопросов и ответов обычно эффективнее, чем разделение по фиксированному количеству символов, причем разные типы документов — такие как правила возврата средств, руководства по устранению неполадок и научные статьи — могут требовать собственных подходов.

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

Создание эмбеддингов

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

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

Такое семантическое совпадение объясняет, почему метод глубокого поиска стал важным в задачах ответов на вопросы в открытых доменах. Исследование Dense Passage Retrieval 2020 года показало, что обученные глубокие представления могут превзойти сильную базовую модель BM25 в нескольких тестах поиска для задач ответов на вопросы в открытых доменах.

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

Хранение эмбеддингов в векторной базе данных

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

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

Рассматривайте его как часть механизма поиска, а не просто контейнер для хранения. Эффективная фильтрация метаданных может существенно повлиять на качество результатов. Вопрос о политике возврата средств в Европе не должен приводить к загрузке информации из другого региона. Если пользователь имеет право просматривать только документы отдела кадров своего подразделения, механизм поиска должен обеспечить это до того, как информация попадёт к модели.

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

Извлечение соответствующих фрагментов

Процесс ответа начинается с того момента, когда пользователь задаёт вопрос. Система встраивает вопрос, ищет его в векторном хранилище и возвращает наиболее соответствующие фрагменты. Специалисты называют это методом поиска top-k, где k обозначает количество возвращаемых фрагментов; top-5 означает пять наиболее близких по совпадению фрагментов.

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

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

Именно по этой причине популярен гибридный поиск. Он сочетает в себе поиск по векторам и поиск по ключевым словам в полном тексте, а затем объединяет результаты. Например, Azure AI Search описывает гибридный поиск как один запрос, в котором выполняются оба типа поиска одновременно, а ранжированные результаты объединяются с использованием метода Reciprocal Rank Fusion. Проще говоря, система имеет два способа найти ответ: по значению и по точному формулированию.

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

Создание промпта

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

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

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

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

Генерация ответа

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

Хороший пример: «Переустановленные ноутбуки необходимо возвращать в течение 14 дней с момента доставки. В правилах не указано никаких исключений для возврата через 20 дней, поэтому согласно предоставленным правилам запрос на возврат после 20 дней не будет принят». Этот ответ хорош тем, что излагает правило, применяет его к ситуации пользователя и не делает вид, что существует исключение, когда в источнике его нет.

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

Оценка процесса

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

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

После этого изучите сгенерированный ответ. Остается ли он верным контексту? В нем присутствуют утверждения, которые никем не подтверждаются? Отвечает ли он на реальный вопрос и ссылается ли на правильный источник? Если документы оказались недостаточными, признает ли это ответ?

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

Основной цикл оценки может отслеживать:

• Точность извлечения — наличие правильного фрагмента текста.
• Адекватность — наличие подтверждения ответа в извлеченном контексте.
• Полнота — наличие важных деталей.
• Качество цитирования — релевантность используемых источников.
• Задержка — время, затрачиваемое на получение ответа.
• Затраты — количество токенов и количество запросов на извлечение информации.
• Удовлетворенность пользователя — решение поставленной проблемы.

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

Где возникают проблемы в базовых цепочках обработки

Первая версия цепочки обработки обычно работает достаточно хорошо, чтобы вызвать восторг, но в то же время настолько плохо, что заставляет признать свои ограничения. Типичные проблемные моменты:

• Плохое разбиение на фрагменты. Возвращается релевантный фрагмент, но в нем отсутствует полный ответ.
• Шум в процессе поиска. Возвращаются отрывки, которые кажутся связанными, но не отвечают на вопрос, особенно когда запрос слишком общий, двусмысленный или содержит термины, встречающиеся во многих документах.
• Устаревшая информация. Обновления проще, чем переобучение, но только при условии постоянного обновления базы знаний. Старые документы, оставшиеся в индексе, всё ещё могут быть найдены.

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

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

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

Простая архитектура

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

Кратко говоря: документы превращаются в фрагменты, затем — в эмбеддинги, и хранятся в векторном хранилище; вопрос превращается в эмбеддинг запроса, проходит через механизм поиска для получения контекста, и языковая модель преобразует его в ответ.

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

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

Что отличает хороший поток обработки

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

Поэтому качественная система RAG — это не просто функция искусственного интеллекта. Она сочетает в себе управление знаниями, поиск, дизайн продукта и меры безопасности.

Куда двигаться дальше

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

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

Разбивка на части по структуре документа, а не по фиксированной длине.

Переписывание нечетких запросов в более ясные.

Уточнение цитат путем записи названий источников, разделов и ссылок.

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

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

Почему стоит этому научиться

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

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