RAG без магии

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

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

Технически это верно. Но за этой короткой схемой скрывается большая часть работы.

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

И только после этого в работу вступает LLM.

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

Документ ещё не знает, что он станет знанием

Допустим, company хочет сделать внутреннего ИИ-помощника. У него должны быть инструкции отдела продаж, регламенты, техническая документация, договорные шаблоны, инструкции сотрудников и десятки других документов.

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

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

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

Но сначала эти документы нужно подготовить.

Первый шаг — разобрать документ

Представим инструкцию на 80 страниц. Для человека это один документ. Для поисковой системы это неудобный объект.

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

И вот здесь уже начинается инженерия.

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

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

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

А теперь — вектор

Вот здесь начинается самая часто неправильно понимаемая часть RAG. Компьютеру нужно каким-то образом сравнить вопрос пользователя с тысячами фрагментов текста. Можно искать по словам. А можно искать по смыслу.

И для этого текст переводят в числовое представление — embedding.

Это не перевод предложения в «язык чисел», который можно прочитать глазами.

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

И здесь полезно разобраться в одном старом и одном современном подходе.

Вектор можно понимать по-разному

До появления современных embedding-моделей существовали более простые способы представить текст численно. Представим словарь:

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

Числа здесь отвечают не за «смысл слова», а за его наличие или вес в конкретном тексте. Получается огромный словарь и длинные разреженные векторы: большая часть координат обычно равна нулю. Это классический подход, близкий к bag-of-words и другим лексическим моделям представления текста.

Он до сих пор полезен.

Если сотрудник ищет «SKU 4817-A», ему не обязательно нужен глубокий семантический поиск. Ему нужно найти именно эту последовательность символов. То же самое касается артикулов, кодов оборудования, номеров договоров, названий моделей и внутренних сокращений.

Поэтому утверждение «векторный поиск заменяет обычный поиск» слишком упрощённое. На практике эти подходы могут дополнять друг друга.

Embedding — уже про другой уровень сравнения

Теперь возьмём два предложения: «Как вернуть товар поставщику?» и «Какие действия выполнить для оформления возврата?» Словарный поиск увидит разные слова. Embedding-модель может представить их как близкие по смыслу.

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

Но здесь важно понимать ограничение.

Embedding не хранит документ в исходном виде. Это математическое представление содержания. При таком сжатии часть информации неизбежно теряется. Поэтому один только вектор не является заменой исходному тексту.

В реальной системе рядом с вектором хранят сам фрагмент или ссылку на него, идентификатор документа, раздел, дату, права доступа и другие метаданные.

Это уже гораздо ближе к реальной корпоративной системе, чем абстрактная схема «текст → вектор».

Почему нужна векторная база

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

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

Но даже здесь система ещё ничего не ответила. Она только нашла кандидатов.

Найти похожее — не значит найти нужное.

Найти похожее — не значит найти нужное

Это один из самых важных моментов во всём RAG. Допустим, пользователь спрашивает: «Можно ли вернуть оборудование после 30 дней?» Поиск может найти пять фрагментов, в которых встречаются слова: возврат, оборудование, срок, 30 дней.

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

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

Это уже существенно отличается от простого: PDF → VECTOR DB → CHATGPT.

И только теперь появляется LLM

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

Именно поэтому RAG правильнее воспринимать не как «обучение нейросети на документах». Документы не обязательно становятся частью параметров самой модели. Они извлекаются из внешнего источника в момент запроса и передаются модели как дополнительный контекст.

Это даёт важное практическое преимущество: базу знаний можно обновлять независимо от самой языковой модели.

• Изменили регламент — обновили индекс;
• Добавили новый документ — обработали его;
• Удалили устаревший документ — убрали соответствующие записи.

Но это преимущество работает только при нормально построенном процессе обновления данных.

Почему RAG может уверенно ошибаться

Представим, что сотрудник спрашивает: «Какой срок гарантии действует на оборудование серии X?» В базе действительно есть нужная информация. Но retrieval не нашёл её. Вместо этого он вернул похожий фрагмент про оборудование серии Y.

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

Именно здесь возникает важное различие: качество ответа RAG зависит не только от качества LLM.

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

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

Ещё одна проблема — свежесть

Корпоративная информация меняется. Сегодня инструкция говорит одно, через месяц её заменяет новая редакция. Если старая версия осталась в индексе, поиск может вернуть её вместе с новой. Для человека это очевидная проблема. Для алгоритма — просто два похожих фрагмента.

Поэтому при построении корпоративного RAG важны не только embeddings, но и обычные инженерные вещи:

• Версии документов и даты актуальности;
• Идентификаторы источников и права доступа;
• Удаление устаревших записей из индекса;
• Контроль повторной индексации и мониторинг качества поиска.

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

RAG — это не одна технология

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

А в крупной корпоративной системе могут добавляться права доступа, несколько источников данных, базы SQL, поиск по каталогам, внешние API, графовые связи и отдельные механизмы проверки ответа. Поэтому вопрос «есть ли у нас RAG?» сам по себе мало что говорит.

Гораздо полезнее задать другие вопросы к проектированию системы:

• Какие именно данные система использует на входе?
• Как именно она их индексирует и раскладывает на фрагменты?
• По каким критериям выбирается нужный фрагмент из векторной базы?
• Как отсекается неактуальная или устаревшая информация?
• Как учитываются права доступа пользователей разных отделов?
• Что делает ИИ, если релевантного ответа в базе физически нет?

И главное:

«Как мы проверяем, что найден именно тот контекст, который нужен для ответа?»

Где заканчивается магия

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

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

И именно поэтому хороший корпоративный RAG начинается не с выбора модной нейросети. Он начинается с данных.

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

А если retrieval построен правильно, LLM становится тем, чем ей и стоит быть в такой системе: не хранилищем корпоративных знаний, а инструментом, который умеет работать с найденной информацией и превращать её в понятный для человека ответ.

Коротко

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

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

Именно поэтому RAG — это прежде всего инженерная задача, а уже потом задача выбора нейросети.

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

Сайт носит исключительно информационный характер и не является публичной офертой в соответствии со статьёй 437 Гражданского кодекса РФ. Цены, состав и условия предоставления услуг уточняются при проектировании решения и фиксируются в договоре. Условия технического сопровождения и уровень сервиса могут дополнительно определяться отдельным соглашением (SLA).