Что такое RAG-платформа

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

И в какой-то момент хочется совсем простого: загрузить эти документы в одно место и спросить человеческим языком, что именно нужно найти или сравнить. Например, “покажи, где отличаются условия оплаты”, “найди все сроки поставки” или “сравни обязанности сторон”. А система сама пробежится по файлам, найдёт подходящие места и соберёт ответ без бесконечного пролистывания документов туда и обратно.

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

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

Для таких задач и используют RAG. Расшифровывается это как Retrieval-Augmented Generation, то есть генерация ответа с предварительным поиском по источникам. Проще говоря, нейросеть сначала ищет нужные места в ваших документах, а уже потом формулирует ответ по найденным фрагментам, а не просто “из головы”.

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

Это не так просто, как “загрузить PDF”. Здесь начинается обычная текстовая инженерия, которую в индустрии часто называют IDP (Intelligent Document Processing, интеллектуальная обработка документов). Нужно аккуратно извлечь текст, распознать таблицы и сохранить структуру документа: заголовки, разделы и номера пунктов.

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

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

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

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

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

Эту работу делает embedding-модель. У неё только одна задача: перевести текст в вектор. На этапе индексации она строит векторы для чанков документов, а позже, когда пользователь задаёт вопрос, строит вектор уже для самого вопроса. После этого их можно сравнивать математически.

В настоящих системах такой вектор обычно состоит из сотен или тысяч координат, а это заметно больше, чем пять или десять чисел из простого примера. Поэтому ниже мы не рисуем “похожесть” вручную, а строим векторы через embedding-модель: показываем первые координаты, общий размер вектора и контекстную близость через cosine similarity, то есть косинусную близость.

Чтобы понять cosine similarity, полезно вспомнить обычную аналитическую геометрию. Вектор можно представить как стрелку, у которой есть длина и направление. В школе или на первом курсе такие стрелки рисуют на плоскости с двумя координатами: $x$ и $y$. Или в пространстве с тремя координатами: $x$, $y$ и $z$. В эмбеддингах принцип тот же, только координат гораздо больше, от сотен до тысяч. У вопроса есть свой вектор, и у каждого фрагмента документа тоже есть свой.

Если две стрелки направлены почти одинаково, угол между ними маленький. Косинус маленького угла близок к 1, а значит, векторы для модели близки по контексту. Если стрелки почти перпендикулярны, косинус около 0. Если смотрят в разные стороны, косинус может быть близок к -1.

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

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

Этап 1. Поиск кандидатов

Пользователь задаёт вопрос обычным языком, например, “где в договоре описаны условия оплаты?”. Платформа может использовать BM25, чтобы найти точные совпадения и важные слова. Рядом с ним работает векторный поиск. Вопрос тоже превращается в вектор и сравнивается с векторами чанков, которые заранее получились при индексации документов.

На практике это похоже на таблицу с оценками. У вопроса уже есть вектор, и платформа сравнивает его с вектором каждого чанка через cosine similarity. Чем выше число, тем ближе фрагмент по контексту. Потом эти фрагменты можно отсортировать, объединить с результатами BM25 и взять несколько лучших кандидатов для ответа.

Этап 2. Реранжирование

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

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

Этап 3. Отбор полезных фрагментов

Дальше платформа выбирает несколько самых подходящих мест. Это могут быть фрагменты, где прямо написано “условия оплаты”, а могут быть похожие по смыслу пункты, такие как счёт, аванс, срок платежа или порядок расчётов. То есть система ищет не одну волшебную фразу, а набор мест, которые могут помочь ответить на вопрос.

Этап 4. Ответ по источникам

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

Поэтому хороший ответ в RAG-платформе устроен не как “модель что-то вспомнила”, а как небольшая выжимка из найденных источников. Такая опора ответа на реальные источники называется grounding, то есть заземление. И если всё сделано правильно, рядом с ответом можно открыть документ, страницу или конкретный кусок текста, откуда это было взято. Такие кликабельные ссылки на источник называются citations, то есть цитирования.

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

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

Бывает и так, что вопрос сформулирован слишком широко: “что тут важного?” или “найди риски”. Для человека это понятный запрос, но системе нужно решить, какие именно риски считать важными и какие документы смотреть в первую очередь. В таких случаях хороший интерфейс должен помогать уточнять вопрос, а не делать вид, что неопределённости нет.

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

Главная польза RAG-платформы не в замене человека. Она снимает самую утомительную часть работы. Открыть десятки файлов, найти нужные места, сравнить формулировки и не потерять источник теперь занимает не часы, а минуты. Человек всё равно принимает решение, но тратит меньше времени на механический поиск.

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

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