RAG-система: что это и как работает простыми словами

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

Так ведёт себя языковая модель (LLM) без доступа к вашим данным. В документации AWS её сравнивают со «слишком уверенным новичком, который отказывается следить за новостями, но на всё отвечает с абсолютной уверенностью». Отсюда две хронические боли. Первая — устаревшие знания: модель помнит мир на момент обучения (knowledge cutoff) и про вчерашний прайс ничего не знает. Вторая — галлюцинации, то есть складные, но выдуманные ответы. RAG как раз даёт такому сотруднику справочник: перед ответом система идёт в вашу базу знаний, находит нужные куски и кладёт их модели на стол вместе с вопросом.

Что такое RAG?

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

Чтобы дальше было легче, держите под рукой короткий словарь. Эти пять слов встречаются в любом разговоре про RAG-систему.

Термин	Что значит простыми словами
Чанкинг (chunking)	Нарезка документов на куски, чтобы каждый был цельным по смыслу
Эмбеддинг (embedding)	Перевод текста в числовой вектор, который кодирует его смысл
Векторная база (vector store)	База, которая хранит векторы и быстро ищет похожие по смыслу
Retrieval (поиск)	Поиск релевантных кусков под конкретный вопрос пользователя
Reranking (переранжирование)	Пересортировка найденного, чтобы наверх попали лучшие куски

Как работает RAG?

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

Фаза индексации (готовим базу заранее, офлайн)

Загрузка документов. Собираем источники: PDF, базы, вики, сайты, записи из CRM. Уже здесь стоит чистить мусор, иначе он осядет во всей базе.
Чанкинг. Режем документы на куски так, чтобы каждый был цельной единицей смысла. Способы разные: по фиксированному размеру, рекурсивно, с перекрытием и по смысловым границам (семантический чанкинг).
Эмбеддинги. Отдельная модель превращает каждый чанк в вектор — числовой массив, кодирующий смысл текста.
Векторная база. Векторы складывают в базу (pgvector, Pinecone, Qdrant, Weaviate, Chroma), которая быстро находит близкие по смыслу через приближённый поиск ближайших соседей.

Фаза запроса (происходит на каждый вопрос, онлайн)

Вопрос в вектор. Запрос пользователя тоже переводят в эмбеддинг.
Retrieval. По векторной близости достаём top-K самых релевантных чанков.
Reranking. Шаг необязательный, но в 2026 это уже стандарт продакшена. Более «умная» модель пересортировывает кандидатов: берёт, скажем, top-50 и оставляет top-5 лучших.
Подстановка в контекст. Найденные куски вставляют в промпт вместе с вопросом.
Генерация. Модель пишет ответ с опорой на эти куски и в идеале даёт ссылки на источники.

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

Запомните главное про RAG: качество ответа почти полностью упирается в качество поиска, а не в саму модель. Достал retrieval не тот кусок — ответ будет неверным, какой бы умной ни была модель.

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

Гибридный поиск (hybrid search) — это когда векторный поиск дополняют классическим поиском по ключевым словам (алгоритм BM25). В продакшене 2026 это считают стандартом, а по оценке инженеров — улучшением с самым высоким ROI: если делать в пайплайне только одно улучшение, делать стоит именно его.

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

Запрос уходит параллельно в два поиска — ключевой (BM25) и векторный.
Кандидатов объединяют, например в общий top-50.
Reranker пересортировывает их и оставляет top-5 действительно релевантных.
Эти пять кусков уходят модели, и она пишет ответ с цитатами.

Зачем RAG бизнесу?

Коротко: RAG нужен там, где ассистент должен работать с вашим контекстом, а не болтать в вакууме. Написать пост или пересказать статью — хватит обычного чата. А когда нужно ответить по реальным данным компании и сослаться на источник, в дело идёт RAG.

Внутренняя база знаний. Сотрудник спрашивает «сколько у меня осталось отпуска», и система достаёт политику отпусков плюс его личную запись (пример из документации AWS).
Поддержка клиентов. Бот отвечает по актуальной документации продукта, а не по общим данным из обучения.
Поиск по внутренней документации: мануалы, FAQ, отчёты, HR. Вместо сорока минут поисков «того самого файла» сотрудник получает ответ со ссылкой.
Регулируемые домены — юридический, медицинский, финансовый, где критична ссылка на источник и доступ по правам. RAG умеет ограничивать выдачу прямо на уровне поиска.
ИИ-агенты с памятью. Агент подтягивает релевантный контекст из базы на каждом шаге задачи.

Если хотите сперва разобраться, чем агент отличается от чат-бота, начните со статьи что такое ИИ-агент. А собрать рабочего агента поверх своей базы знаний сегодня можно и без глубокого кода: про это есть отдельный разбор — как создать ИИ-агента без программирования.

@yourself_realize

Разборы ИИ без воды — в Telegram

Как собирать ИИ-агентов, автоматизацию и работу с нейросетями на практике. Коротко и по делу.

Перейти в канал

RAG, дообучение или длинный контекст — что выбрать?

Вопрос «или-или» поставлен неверно: в продакшене это почти всегда гибрид. Проще держать в голове разделение ролей. RAG отвечает за то, ЧТО модель знает (факты из ваших документов). Дообучение (fine-tune) — за то, КАК она говорит (тон, формат, правила). Длинный контекст хорош, когда нужно скормить модели целый документ целиком.

Ситуация	Что выбрать
База меньше ~200K токенов, спрашивают примерно одно и то же	Длинный контекст с кэшированием промпта: дёшево и просто
Гигабайты-терабайты данных, сотни тысяч документов	RAG: в контекст столько не влезет
Знания меняются каждый день (новости, цены, остатки)	RAG: дообучение мгновенно устареет
Нужен стабильный тон, формат и соблюдение правил	Дообучение: учим «как», а не «что»
100K+ однотипных запросов в день	Дообучение маленькой модели: по оценке практиков, в 10–50 раз дешевле
Продакшен-уровень	Чаще всего гибрид всех трёх подходов

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

И честно про споры. Тезис «RAG умер из-за длинных контекстов» в 2026 реален, но консенсус практиков такой: длинный контекст помогает, но не заменяет хороший поиск. Мешают стоимость, задержка в десятки секунд на запрос и эффект «потерянного в середине», когда модель хуже видит факты в центре очень длинного текста. По оценке источников, гибрид даёт около 96% точности против 89–91% у одного метода — это ориентир, не закон.

Подводные камни RAG

Развернули RAG, а ответы всё равно так себе — частая история. Почти всегда дело не в «глупой модели», а в одном из этих мест.

Плохой чанкинг. Наивная резка по N символов рвёт мысль пополам, и потеря расползается по всей базе. Лечится семантическим или рекурсивным чанкингом с перекрытием.
Мусор на входе. Грязные скрейпы и сырые PDF-дампы дают принцип garbage in, garbage out. Подготовка данных — полноценный этап, а не разминка.
Нет reranker'а. Полагаться на одно косинусное сходство — значит брать ближайшего соседа и надеяться на удачу. На больших базах это даёт нерелевантные куски и галлюцинации.
Embedding rot, «гниение эмбеддингов». Тихий убийца: данные и модель эмбеддингов устаревают, а команда боится болезненной миграции базы. Переэмбеддить стоит, когда вышла модель получше, сменился домен или обновилось 10–15% корпуса.
Ноль eval'ов. Оценка «по ощущениям» не показывает, где RAG ломается. Минимум — маленький размеченный датасет и проверка сначала качества поиска, потом ответа.
GraphRAG на грязных данных. Граф поверх мусора даёт шумные узлы и бессмысленные связи. Он оправдан, только когда в домене реально есть сущности и связи между ними.

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

На чём собирают RAG: инструменты экосистемы

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

Фреймворки-оркестраторы. LangChain — самый известный каркас для сборки RAG-пайплайнов и агентов. LlamaIndex заточен под индексацию и подключение данных к модели.

Векторные базы данных, с практическими оговорками из обзоров 2026:

pgvector — расширение для PostgreSQL. Бесплатно, ничего нового поднимать не нужно. Разумный дефолт для старта: начинайте с него, а на выделенную базу переходите, когда назовёте конкретное узкое место.
Pinecone — полностью управляемый облачный сервис. Простая эксплуатация, но дороже на масштабе и без self-host, что критично для регулируемых отраслей.
Weaviate — open-source, сильный гибридный поиск из коробки. Минус — больше «ручек» и сложнее в эксплуатации.
Qdrant — open-source, хорош на фильтрации по метаданным, приличный бесплатный тариф.
Chroma — лёгкий вариант для локального прототипа.

Есть и готовые managed-решения, например AWS Bedrock Knowledge Bases — RAG как сервис. А подключать модели к внешним инструментам и данным агенту помогает отдельный слой, про который мы писали в статье про MCP-сервер.

Куда движется RAG в 2026

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

Agentic RAG. Вместо фиксированного пайплайна агент сам анализирует вопрос, выбирает стратегию, делает несколько раундов поиска и вызывает инструменты. Для сложных многошаговых задач, но такого агента сложнее отлаживать.
GraphRAG. Поверх векторного индекса строят граф сущностей и связей, и поиск рассуждает по рёбрам, находя отношения, а не только похожие слова. Для кросс-документных вопросов: юридический поиск, финансовая отчётность, комплаенс.
Hybrid search с reranker'ом. Тот самый стандарт продакшена с самым высоким ROI.
HyDE. Для размытых запросов модель сначала придумывает гипотетический идеальный ответ и ищет реальные документы по его эмбеддингу. Цена — лишний вызов модели.
Self-RAG. Модель сама решает, нужен ли поиск, релевантен ли документ и подтверждён ли её ответ, и при провале самопроверки переспрашивает базу.

Что такое RAG простыми словами?

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

RAG убирает галлюцинации?

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

RAG или дообучение — что выбрать?

Они решают разные задачи и в продакшене часто работают вместе. RAG отвечает за факты (что модель знает) и хорош, когда данные часто меняются. Дообучение отвечает за поведение (как модель говорит): тон, формат, правила. Новым фактам дообучение не учит — для этого нужен RAG.

Нужна ли для RAG векторная база данных?

В большинстве случаев да: именно она хранит эмбеддинги и быстро ищет похожие по смыслу куски. Для старта необязательно поднимать что-то отдельное — часто хватает расширения pgvector поверх обычного PostgreSQL, а на выделенную базу переходят, когда упёрлись в конкретное ограничение.

Сколько стоит RAG?

Универсальной цифры нет, всё зависит от объёма данных и числа запросов. По оценке практиков, RAG среднего масштаба (порядка 500K документов и 10K запросов в день) обходится примерно в 5–8 тысяч долларов в месяц с учётом векторной базы, эмбеддингов и вызовов модели. Это ориентир из расчётов авторов, а не прайс-лист.