Что такое RAG: поиск по своим документам

Как расшифровывается RAG и зачем он нужен?

RAG — это Retrieval-Augmented Generation, по-русски «генерация с дополненной выборкой». Retrieval здесь означает извлечение: технология достаёт куски текста из ваших данных и подкладывает их модели. Схема такая: поисковый модуль находит релевантные фрагменты в вашей базе знаний, кладёт их в промпт, и уже потом языковая модель формирует ответ. Модель видит нужный кусок текста прямо перед собой и пересказывает его, а не вспоминает что-то похожее из весов.

Термин пришёл из научной работы. Статью «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» команда из двенадцати авторов во главе с Патриком Льюисом выложила на arXiv 22 мая 2020 года. Авторы соединили параметрическую память модели с непараметрическим индексом по Википедии и показали: вторую половину можно менять, не переучивая первую. Отсюда весь интерес бизнеса — база знаний обновляется за минуты вместо недель дообучения.

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

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

Из чего состоит конвейер RAG?

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

1. Разбор. Из PDF, DOCX и HTML достают чистый текст. Здесь же выбрасывают колонтитулы, оглавления и служебные страницы, иначе они полезут в ответы.
2. Нарезка. Текст режут на чанки в несколько сотен слов с небольшим перекрытием. Мелкий чанк теряет контекст, крупный размывает поиск.
3. Эмбеддинги. Каждый чанк прогоняют через модель-энкодер и получают вектор — длинный набор чисел, кодирующий смысл фрагмента.
4. Индекс. Векторы складывают в базу, которая умеет быстро находить ближайших соседей.
5. Сборка ответа. Вопрос пользователя тоже превращают в вектор, достают несколько ближайших чанков, склеивают их с вопросом в один промпт и отдают языковой модели.

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

Чем RAG отличается от обычного поиска по документам?

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

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

Третье отличие практическое. Поисковый движок живёт сам по себе и стоит копейки. RAG на каждый вопрос тратит вызов языковой модели, а значит — токены и деньги. Если вопросов тысячи в день, эта строчка в смете становится заметной.

Что взять на GitHub: открытые части конвейера

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

Шаг конвейера	Инструмент	Лицензия	Последний релиз
Нарезка и сборка промпта	LangChain	MIT	langchain-core 1.5.3, 30 июля 2026
Индексация документов	LlamaIndex	MIT	v0.14.23, 24 июня 2026
Эмбеддинги	sentence-transformers	Apache 2.0	v5.7.0, 6 августа 2026
Поиск по векторам	FAISS	MIT	v1.15.0, 3 августа 2026
Векторная база	Qdrant	Apache 2.0	v1.19.0, 5 августа 2026
Векторы внутри PostgreSQL	pgvector	PostgreSQL License	v0.8.6

Лицензии тут важнее звёзд. FAISS от исследовательского подразделения Meta лежит под MIT, Qdrant — под Apache 2.0, sentence-transformers тоже под Apache 2.0. Все три разрешают коммерческое использование без выплат. Это и есть ответ на вопрос «сколько стоит своя RAG-система»: инфраструктура даром, счёт приходит за генерацию.

Выбор между библиотекой и сервером зависит от масштаба. FAISS — это библиотека, она живёт внутри вашего процесса и не умеет реплики. Qdrant — отдельный сервер с API, репликацией и фильтрами по метаданным.

Сколько документов потянет база и что нужно из железа?

Для первых сотен тысяч чанков отдельная векторная база не нужна: хватает расширения к PostgreSQL, который у вас, скорее всего, уже стоит.

Судя по документации расширения pgvector на август 2026 года, один вектор хранит до 16 000 измерений, а индексы HNSW и IVFFlat работают с векторами до 2 000 измерений. Половинная точность поднимает потолок индекса до 4 000, бинарное квантование — до 64 000. Требование к серверу ровно одно: PostgreSQL версии 13 или новее. Лицензия у расширения та же, что у самой СУБД.

Типичные эмбеддинги укладываются в 384–1536 измерений, так что лимит индекса в 2 000 упирается в потолок редко. Отдельный сервер вроде Qdrant начинает окупаться, когда чанков миллионы, требуются фильтры по правам доступа или база должна переживать перезапуск приложения.

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

Где RAG применяют на практике?

Чаще всего RAG стоит там, где сотрудники задают один и тот же вопрос по внутренним документам.

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

Отдельная ветка — поиск по кодовой базе и по тикетам. Там RAG обычно становится инструментом внутри ИИ-агента: агент сам решает, когда полезть в индекс, а когда обойтись без него.

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

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

Когда RAG не нужен?

В обзорах RAG хвалят со всех сторон, но границу применимости почти никто не рисует. А она есть, и довольно чёткая.

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

Второй случай — агрегирующие вопросы. «Сколько всего договоров с отсрочкой платежа» векторный поиск не осилит: он приносит несколько похожих кусков, а не пересчитывает базу. Такие вопросы закрывает SQL, а не RAG.

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

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

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

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

Ошибки RAG почти всегда рождаются на этапе поиска, а не генерации.

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

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

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

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

Как попробовать RAG без своего сервера

Самая дорогая часть конвейера — генерация, и её можно взять готовой.

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

Когда прототип подтвердил пользу, генерацию подключают через API к своему индексу: ретривер остаётся у вас, наружу уходит только собранный промпт. Формат запросов совместим с OpenAI, так что LangChain и LlamaIndex подключаются штатным клиентом без переписывания кода. Дальше остаётся то, ради чего всё затевалось: следить за качеством поиска и держать документы в порядке.

Источники

• arXiv, «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», препринт 2005.11401 — arxiv.org (проверено 7 августа 2026)
• pgvector, README расширения: лимиты измерений и требование PostgreSQL 13+ — github.com/pgvector/pgvector (проверено 7 августа 2026)
• FAISS, карточка репозитория: лицензия MIT, релиз v1.15.0 — github.com/facebookresearch/faiss (проверено 7 августа 2026)
• Qdrant, карточка репозитория: лицензия Apache 2.0, релиз v1.19.0 — github.com/qdrant/qdrant (проверено 7 августа 2026)
• sentence-transformers, карточка репозитория: лицензия Apache 2.0, релиз v5.7.0 — github.com/huggingface/sentence-transformers (проверено 7 августа 2026)