Что такое RAG и почему без него AI-приложения остаются игрушкой

Когда люди впервые подключают LLM (large language model, большую языковую модель) к продукту, кажется, что самое сложное уже позади. Модель отвечает, умеет пересказывать текст, пишет черновики, поддерживает диалог. Но как только дело доходит до реального бизнеса, выясняется неприятная вещь: сама по себе модель почти ничего не знает о ваших договорах, внутренних регламентах, базе знаний, тикетах, коде, каталогах товаров и свежих документах.

Именно поэтому столько AI-приложений выглядят впечатляюще на демо и разочаровывают в проде. Они говорят уверенно, но не могут опереться на конкретные данные компании. RAG появился не как модный термин, а как практический ответ на этот разрыв: как дать модели доступ к нужным данным без переобучения и без постоянной ручной сборки промптов.

Почему LLM без ваших данных мало что стоит

У базовой LLM есть три системные проблемы.

Первая: у неё нет доступа к приватным данным организации. Модель может хорошо объяснять общие темы, но она не знает, что написано в вашем PDF с регламентом закупок, в Confluence, в Notion, в Zendesk или в папке с договорами.

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

Третья: знания модели быстро стареют. Для прикладных AI-систем это критично. Пользователь спрашивает не про абстрактную физику, а про текущий тариф, актуальную редакцию документа, статус заказа, внутреннюю политику или спецификацию API.

Именно здесь и рождается главная проблема прикладного AI: если модель не привязана к вашим данным, она не знает то, что бизнесу как раз важнее всего. NIST (Национальный институт стандартов и технологий США) в профиле по Generative AI отдельно описывает, что для таких систем вопрос не в «умности» модели самой по себе, а в управлении рисками, источниками истины и достоверностью вывода. (1)

Что такое RAG в одном абзаце

RAG расшифровывается как Retrieval-Augmented Generation, то есть «генерация, усиленная поиском». Сначала система находит релевантные фрагменты в ваших данных, потом подставляет их в контекст модели, и только после этого LLM формирует ответ. Иначе говоря, модель не отвечает «из памяти», а отвечает на основе найденных источников. (2)

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

Embeddings и векторные базы данных, без хайпа

Чтобы RAG работал, текст обычно переводят в embeddings — числовые векторы, которые отражают смысл фразы или абзаца. За счёт этого вопрос пользователя можно сравнивать не только по буквальному совпадению слов, но и по смысловой близости. OpenAI в документации Retrieval прямо показывает, что семантически релевантный фрагмент может вообще не содержать слов из исходного запроса. (2)

Векторная база данных хранит такие представления и умеет быстро находить близкие фрагменты. Это не «магическая память для AI», а специализированный индекс для семантического поиска. В hosted-варианте OpenAI vector store сам автоматически чанкует, эмбеддит и индексирует загруженные файлы. В Chroma эту же логику можно собрать локально или встроить в приложение, вплоть до собственной embedding-функции. (211)

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

Как реально устроено продакшен-RAG приложение

В проде RAG почти никогда не выглядит как «загрузили PDF, спросили, получили ответ». У нормальной системы есть как минимум пять слоёв: ingestion, parsing, chunking, retrieval и generation.

Сначала документы надо привести в пригодный для поиска вид. У Google Vertex AI RAG Engine это прямо описано как отдельный lifecycle: ingestion из локальных файлов, Cloud Storage или Google Drive, затем transformation, затем indexing в corpus. (7) И это важный сигнал: главная сложность начинается до модели.

Потом идёт chunking, то есть разбиение документа на небольшие фрагменты. Документ почти никогда не ищут целиком. Его разбивают на куски, чтобы retrieval работал точнее. И здесь живёт половина всех ошибок. Если chunk слишком маленький, он теряет контекст. Если слишком большой, вы получаете «тематический суп», где найден фрагмент вроде бы похожий, но на деле слишком размазанный. В OpenAI Retrieval дефолтный размер чанка для vector store — 800 токенов при overlap 400, то есть с частичным пересечением соседних кусков, но это всего лишь стартовая точка, а не универсальная истина. (2)

После этого нужна не просто векторная выдача, а нормальный retrieval-конвейер. В 2026 году хорошей практикой стал не dense-only поиск, а сочетание семантического поиска и keyword-поиска. OpenAI даёт semantic search, query rewriting, attribute filtering и ranking options. Weaviate прямо строит hybrid search как параллельный запуск vector search и BM25 (Best Matching 25, классический алгоритм ранжирования для keyword-поиска) с последующим fusion. (210)

Дальше обычно добавляют reranking, то есть дополнительную пересортировку найденных фрагментов по релевантности. Это особенно важно, когда первый этап retrieval возвращает широкий пул кандидатов. Anthropic в исследовании Contextual Retrieval показывает тот же продакшен-паттерн: embeddings + BM25 + reranker дают заметно меньше провалов поиска, чем embeddings в одиночку. (5)

И только после этого retrieved-контекст попадает в LLM. Если продукт серьёзный, на выходе должны быть как минимум цитаты, ссылки на источники, page-level привязка или понятный след того, откуда взялся ответ. Без этого пользователь получает красиво сформулированный текст, но не получает проверяемость.

Чат с PDF и корпоративная база знаний: что меняется на практике

Chat with PDF часто выглядит как самый простой пример RAG. И действительно, для демо этого достаточно: загрузили файл, разбили на чанки, построили embeddings, нашли похожие куски, отдали их модели. Но в реальном продукте сложности начинаются мгновенно.

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

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

Поэтому рабочий RAG для базы знаний почти всегда включает:

фильтрацию по источнику, tenant, отделу или типу документа;
переиндексацию при обновлении данных;
логи retrieved-чанков;
offline evals на типовых вопросах;
явную стратегию fallback, если релевантных кусков не найдено.

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

Инструменты в 2026: Pinecone, Weaviate, Chroma, Qdrant, pgvector

Выбор инструмента зависит не от моды, а от того, какой именно retrieval-слой вы строите.

Pinecone остаётся сильным managed-вариантом для команд, которые не хотят поднимать и эксплуатировать отдельную поисковую инфраструктуру. В документации Pinecone акцент на serverless-архитектуре, разделении control plane и data plane, независимом масштабировании read/write путей и работе через namespaces. Это хороший вариант, когда нужен предсказуемый managed-сервис и минимум ops-нагрузки. (9)

Weaviate силён там, где нужен гибридный поиск из коробки. В его документации hybrid search — это не дополнительный хак, а базовый паттерн: vector search и BM25 идут параллельно, а затем сливаются через relativeScoreFusion или rankedFusion. Дополнительно можно регулировать alpha, то есть баланс между semantic и keyword-сигналом. Для knowledge-heavy систем это очень практичный компромисс между recall и precision. (10)

Chroma удобен как локальный и лёгкий старт, особенно для прототипов, evaluation-пайплайнов и небольших приложений. Он позволяет использовать встроенную embedding-функцию на базе all-MiniLM-L6-v2, а при необходимости быстро подключить OpenAI, Google, Mistral, Ollama, Jina и другие провайдеры. Это хороший способ быстро собрать retrieval-слой без тяжёлой инфраструктуры. Но для жёстко нагруженного multi-tenant production его обычно оценивают уже гораздо строже. (11)

Qdrant часто выбирают, когда на первый план выходят metadata filtering, hybrid search и отдельная эволюция retrieval-слоя. Показательно, что даже в собственном материале о сравнении с pgvector команда Qdrant строит аргумент не вокруг «магической скорости», а вокруг фильтруемого HNSW (Hierarchical Navigable Small World, популярная структура индекса для быстрого поиска ближайших соседей), hybrid search и сценариев, где векторы становятся самостоятельным слоем, а не просто полем в Postgres. (12)

pgvector по-прежнему остаётся разумным стартом, если у вас уже есть Postgres, корпус сравнительно небольшой, а search-логика тесно связана с реляционными данными. Но практическое правило простое: если вы ожидаете сложную фильтрацию, BM25/hybrid, рост объёма embeddings и отдельное развитие retrieval-пайплайна, стоит заранее проектировать систему так, чтобы миграция в dedicated vector store не стала болезненной. (12)

Managed RAG от вендоров моделей: OpenAI File Search и Vertex AI RAG Engine

Отдельный тренд последних лет — hosted RAG прямо у поставщиков моделей. Это важный сдвиг: вендоры больше не ограничиваются «вот вам LLM, остальное стройте сами», а постепенно забирают на себя и retrieval-слой.

У OpenAI для этого есть file_search и vector stores. Файлы можно загружать в knowledge base, после чего сервис сам их chunk'ит, embedding'ит и индексирует. Дальше можно включить file search как tool в Responses API, ограничивать число результатов, добавлять metadata filtering, query rewriting и ranking options, а также возвращать в ответ citations. Для многих внутренних помощников это даёт очень быстрый time-to-market. (24)

У Google похожую роль играет Vertex AI RAG Engine. Он описан именно как data framework для context-augmented LLM-приложений: ingestion, transformation, indexing, retrieval, generation. Плюс Google отдельно выделяет grounding, то есть привязку ответа к проверяемым источникам, и Check grounding API, чтобы проверять, действительно ли ответ опирается на найденные факты. (7)

Плата за такой комфорт очевидна: меньше контроля над retrieval-конвейером, больше зависимости от платформы и меньше свободы в тонкой настройке parsing, indexing и reranking. Но для части команд это абсолютно рациональный обмен, особенно если задача — не исследовательский стек, а быстрое прикладное решение.

Что советуют сами OpenAI, Anthropic и Google

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

OpenAI фактически говорит: retrieval надо настраивать как поисковую систему, а не как «магическое приложение к LLM». В их документации есть и query rewriting, и attribute filtering, и настройка ranker/score threshold, и ограничение числа результатов, и пакетная загрузка файлов для более высокой пропускной способности ingestion. Это очень инженерный, а не романтический взгляд на RAG. (2)

Anthropic идёт ещё дальше и прямо показывает, где ломается классический RAG. Их тезис простой: chunk без контекста часто теряет связь с исходным документом. Поэтому они предлагают Contextual Retrieval: добавлять к chunk короткий объясняющий контекст перед embedding и перед построением BM25-индекса. По их данным, contextual embeddings снижают долю неудачных retrieval'ов на 35%, сочетание contextual embeddings и contextual BM25 — на 49%, а вместе с reranking — на 67%. (5)

Google, в свою очередь, очень последовательно продвигает идею grounding. На практике это означает, что retrieval нужен не просто для «улучшения ответа», а для связывания генерации с проверяемыми источниками. И это, пожалуй, самый здоровый взгляд на весь RAG-слой: retrieval полезен не потому, что делает текст умнее, а потому, что делает вывод проверяемее. (7)

Когда RAG избыточен: long context vs retrieval

В 2026 году разговор о RAG уже невозможно вести без long context, то есть очень большого контекстного окна модели. Anthropic официально вывел 1M токенов контекста для Claude Sonnet 4, а в исследовании Contextual Retrieval отдельно пишет: если ваша база знаний меньше 200 000 токенов, то есть порядка 500 страниц, иногда проще вообще не строить RAG, а положить весь корпус в prompt. С prompt caching, то есть повторным использованием уже подготовленного большого контекста, это может дать снижение latency больше чем в два раза и уменьшение затрат до 90%. (5)

Это важная коррекция для всей индустрии. Не каждый набор документов требует embeddings, vector DB и отдельный retrieval-пайплайн. Если корпус маленький, стабильный и редко меняется, длинный контекст может быть проще, надёжнее и дешевле в сопровождении.

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

Практическое правило здесь такое:

маленький и стабильный корпус — сначала проверяйте long context;
большой или часто меняющийся корпус — почти наверняка нужен RAG;
сложное reasoning поверх большого корпуса — чаще всего работает гибрид: retrieval сначала, длинный контекст потом.

RAG — это дисциплина, а не библиотека

Главное заблуждение вокруг RAG звучит так: «добавим Pinecone, Weaviate или Chroma, и AI начнёт говорить по нашим данным». На практике всё почти наоборот. Векторная база данных — важная, но вторичная часть системы. Качество ответа чаще ломается на плохом parsing, неудачном chunking, отсутствии hybrid search, слабом reranker, грязных источниках и полном отсутствии evals, то есть проверочных наборов вопросов и тестов на качество retrieval и ответов.

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

Именно в этом смысле RAG остаётся центральной технологией прикладного AI. Не потому, что без него LLM вообще не умеет отвечать. А потому, что без retrieval, grounding и проверки источников большинство AI-приложений так и остаются красивой демкой, а не рабочим инструментом.