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

Ты спрашиваешь чат-бот про правила возврата в твоём интернет-магазине — а он уверенно отвечает что-то не то, потому что придумал «среднестатистические» правила из интернета. Или загружаешь в чат триста страниц документации, а модель честно говорит: «столько текста мне не влезает». Знакомо? Обе проблемы решает одна и та же техника — RAG. Именно она стоит под капотом сервисов вроде ChatPDF и NotebookLM, которые умеют «читать» твои файлы и отвечать по ним. Ниже — что такое RAG простыми словами, как он устроен внутри, чем отличается от MCP и как собрать похожую механику в собственном приложении.

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

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

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

RAG — это не сервис и не программа, которую можно «скачать и поставить». Это концепция, схема работы. Как «клиент-сервер» или «авторизация» — не конкретный продукт, а способ устроить систему. Реализаций RAG бесконечно много, но скелет у всех одинаковый: поиск релевантных кусков текста → подстановка их в запрос к модели → ответ с опорой на найденное.

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

Три буквы расшифровываются так: retrieval — извлечение (поиск нужных фрагментов), augmented — дополненная (запрос к модели дополняется найденным), generation — генерация (модель пишет ответ). Если где-то встретишь полную формулировку «retrieval augmented generation» — теперь знаешь, что за ней стоит ровно эта трёхходовка, ничего сложнее.

Зачем вообще нужен RAG

Языковые модели вроде Claude или GPT обучались на огромных массивах текстов из открытого интернета. Отсюда два фундаментальных ограничения, которые никак не убрать «умным промптом».

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

Второе: модель галлюцинирует. Когда ответа нет, модель не всегда честно скажет «не знаю». Она устроена так, что продолжает текст максимально правдоподобно — и выдаёт уверенный, гладкий, грамотный ответ, который может быть полностью выдуманным. В быту это смешно, а в чат-боте поддержки — катастрофа: клиенту пообещали возврат, которого по правилам нет.

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

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

Чтобы окончательно расставить вещи по местам, сравним RAG с двумя альтернативами, о которых чаще всего спрашивают новички:

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

Чем RAG отличается от загрузки файла в чат

«Погоди, — скажешь ты, — я и так могу загрузить PDF в ChatPDF или NotebookLM и задавать вопросы по нему. Чем это не то же самое?»

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

Разница не в «RAG или загрузка файла», а в том, кто собирает механику и насколько она гибкая:

• Готовый сервис — RAG скрыт интерфейсом. Загрузил файл, получил ответы. Зато никакой настройки: как нарезаны документы, сколько фрагментов попадает в контекст, откуда именно взят ответ — решает сервис, а не ты. И данные живут у него: документы уходят на чужие серверы.
• Свой RAG — ты сам контролируешь весь конвейер: что кладёшь в базу (не один файл, а весь сайт, всю базу знаний, тысячи отзывов), как ищется релевантное, как модель должна использовать найденное и что делать, если ответа в документах нет. Данные остаются в твоей инфраструктуре — для коммерческих документов и переписки с клиентами это часто решающий аргумент.

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

Чем RAG отличается от MCP

Ещё одна путаница, которая встречается постоянно: RAG и MCP. Оба слова про «дать модели доступ к данным», но это вещи разного уровня.

MCP (Model Context Protocol) — это протокол, стандарт подключения. Он описывает, как агент или модель обращаются к внешним инструментам и источникам данных в реальном времени: к базе, к календарю, к файловой системе, к API. Про него есть отдельная статья — «Что такое MCP».

RAG — это не протокол, а конкретная техника: поиск релевантного текста перед генерацией ответа и подстановка найденного в запрос.

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

Коротко: MCP отвечает на вопрос «как подключить модель к данным», RAG — «как найти в данных нужное и скормить модели перед ответом». Ещё одно практическое отличие: RAG работает со статичным снимком данных — тем, что лежит в векторной базе на момент вопроса. А MCP-инструмент может дёрнуть живой API и получить значение прямо сейчас: текущий баланс, статус заказа, свободные окошки в календаре. Если задача — «отвечай по нашей документации», это территория RAG. Если «проверь в системе и скажи, что с моим заказом» — это территория инструментов и MCP. В больших ассистентах обе механики живут бок о бок.

Как RAG работает по шагам

Теперь самое интересное — что именно происходит внутри. Весь RAG состоит из двух фаз: подготовка (делается один раз, заранее) и ответ на вопрос (делается при каждом запросе пользователя). Это разделение важно понять с самого начала: тяжёлая работа — нарезка документов и подсчёт векторов — происходит не в момент вопроса, а задолго до него. Поэтому RAG-система отвечает быстро: ей не нужно «перечитывать» всю базу на каждый запрос, только найти в ней несколько подходящих кусков.

Фаза 1. Подготовка базы знаний

Шаг 1. Документы разбивают на куски — чанки. Модель не может проглотить документ в триста страниц целиком, да и искать удобнее по небольшим фрагментам. Поэтому каждый документ режут на чанки — куски текста размером обычно в несколько абзацев. Нарезка — целая наука: слишком мелкие чанки теряют контекст («возврат возможен» — а на что возврат? оборвалось), слишком крупные размывают поиск — в одном куске оказывается три разные темы, и вектор получается «усреднённым», ни на одну толком не похожим. Часто чанки делают с небольшим перекрытием, чтобы смысл на стыках не рвался: конец предыдущего куска дублируется в начале следующего. Ещё лучше резать не механически по числу символов, а по границам смысла — по заголовкам и абзацам.

Шаг 2. Каждый чанк превращают в вектор. Специальная модель (её называют моделью эмбеддингов) переводит текст в вектор — длинный ряд чисел, числовое представление смысла. Аналогия: это как координаты на карте, только карта не двумерная, а многомерная, и «города» на ней — это смыслы. Магия в том, что у текстов с близким смыслом векторы получаются близкими: «как вернуть товар» и «правила возврата покупки» будут рядом в этом числовом пространстве, даже если в них нет ни одного общего слова. Именно поэтому такой поиск называют семантическим — по смыслу, а не по совпадению слов. Важный нюанс: эмбеддинг считается один раз, при загрузке документа в базу, а не при каждом вопросе.

Шаг 3. Векторы сохраняют в векторную базу. Все векторы чанков складывают в специальное хранилище — векторную базу данных, которая умеет быстро отвечать на вопрос «какие векторы ближе всего к этому». Рядом с каждым вектором лежит и сам текст чанка, и служебная информация (её называют метаданными): из какого документа кусок, какая это страница или раздел, когда документ обновлялся. Метаданные пригодятся позже — чтобы показать пользователю источник ответа или искать только по свежим документам.

Фаза 2. Ответ на вопрос пользователя

Шаг 4. Вопрос тоже превращают в вектор. Пользователь спрашивает: «Можно ли вернуть курс, если я уже прошёл половину?» Вопрос прогоняется через ту же модель эмбеддингов и становится вектором.

Шаг 5. Ищут ближайшие по смыслу чанки. Векторная база сравнивает вектор вопроса со всеми векторами чанков и возвращает несколько самых близких — например, пять кусков, где говорится про условия возврата. Это и есть retrieval — извлечение релевантного. Здесь кроется тонкая настройка: сколько чанков брать. Мало — модель может не получить нужный кусок. Много — в контекст попадёт шум, запрос подорожает, а модель начнёт путаться в лишнем. На практике обычно берут от трёх до десяти фрагментов и подбирают число на контрольных вопросах.

Шаг 6. Найденное добавляют в промпт, и модель отвечает. Система собирает запрос примерно так: «Вот фрагменты из нашей базы знаний: [куски текста]. Опираясь только на них, ответь на вопрос пользователя: [вопрос]». Модель читает реальные правила возврата и формулирует ответ по ним — с опорой на контекст, а не по памяти. Это generation. Сама модель при этом ничего не знает про векторы и базу: для неё это обычный запрос, в котором вежливо приложили выдержки из документов. Вся «магия» RAG происходит снаружи модели — в коде, который готовит этот запрос.

flowchart TB
    A["Документы нарезают на чанки"] --> B["Чанки превращают в эмбеддинги"]
    B --> C["Векторная база данных"]
    D["Вопрос пользователя"] --> E["Поиск похожих чанков"]
    C --> E
    E --> F["Ответ модели по найденному"]

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

Где хранить векторы: векторные базы данных

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

Самый простой путь для небольшого проекта — pgvector, расширение для привычного Postgres. Векторы живут прямо в той же базе, где лежит всё остальное: пользователи, заказы, таблица рекордов твоей «Змейки». Не нужно поднимать и содержать отдельный сервис, не нужно синхронизировать два хранилища. Для базы знаний в десятки тысяч чанков этого обычно хватает с головой.

Когда данных много или нужны продвинутые возможности поиска, смотрят на отдельные векторные базы — например, Pinecone (облачный сервис) или Qdrant (можно поднять у себя). Они заточены именно под векторный поиск: быстрее на больших объёмах, умеют фильтры по метаданным и тонкую настройку.

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

Простое правило выбора: начинай с того, что у тебя уже есть. Если в проекте крутится Postgres (а на курсе мы работаем именно с ним через Supabase) — подключи pgvector и не плоди лишние сервисы. Отдельную векторную базу имеет смысл добавлять, только когда упёрся в её возможности: миллионы чанков, сложные фильтры, высокая нагрузка на поиск.

Зачем RAG вайбкодеру

Переведём всё это на практику курса. Вот типичные задачи, которые рано или поздно встают перед твоим приложением:

• Чат-бот поддержки по документации твоего продукта. Пользователь спрашивает «как сбросить пароль» — бот отвечает по твоей инструкции, а не выдумывает. Без RAG модель либо честно скажет «не знаю», либо придумает шаги, которых в твоём приложении нет.
• Поиск по большой базе контента. У тебя тысячи отзывов, статей или товарных карточек. Пользователь формулирует запрос своими словами («что-то для подарка папе, он любит рыбалку») — семантический поиск находит подходящее по смыслу, хотя слов «подарок папе» в карточках нет.
• Ассистент по внутренним материалам. Правила, регламенты, переписки, заметки — всё это становится «спрашиваемым»: не листать папки, а задать вопрос и получить ответ со ссылкой на источник.

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

Хорошая новость: собирать RAG вайбкодеру не нужно голыми руками. Ты ставишь задачу ИИ-ассистенту обычными словами — «добавь в моё приложение чат, который отвечает на вопросы по файлам из папки docs, используй pgvector» — и код пишет ассистент. Но чтобы ставить такую задачу осмысленно, проверять результат и понимать, почему бот отвечает криво, нужно понимать механику. Именно для этого ты сейчас читаешь эту статью.

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

Из чего собрать RAG: готовые кирпичики

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

Сбор данных. Откуда возьмутся документы для базы? Если источник — твой сайт или чужой справочный портал, страницы нужно выкачать и очистить от меню, рекламы и прочего мусора. Это делает Firecrawl — сервис, который превращает сайты в чистый текст, готовый к нарезке на чанки. Мы уже разбирали его в отдельной статье.

Нарезка и эмбеддинги. Чанкинг — обычный код, который напишет ИИ-ассистент по твоему ТЗ. Эмбеддинги делаются вызовом API: отправляешь текст — получаешь вектор чисел. У обоих крупных провайдеров, Claude и OpenAI, есть свои модели для этого, так что эмбеддинги и генерацию можно делать в одной экосистеме.

Хранение и поиск. Как выбрать векторную базу, разобрали выше: для старта — pgvector в твоём Postgres, для больших объёмов — Qdrant или Pinecone.

Генерация ответа. Найденные чанки и вопрос пользователя уходят в языковую модель через API. Здесь работают те же инструменты, что и в остальном приложении: Claude API или OpenAI API (статья про него тоже есть на курсе). Модель получает контекст и вопрос и возвращает готовый ответ пользователю. Промпт при этом примерно такой: «Отвечай на вопрос, опираясь только на приведённые фрагменты. Если ответа в них нет — честно скажи об этом. В конце укажи, из какого документа взята информация».

То есть RAG-система — это не монолит, а конвейер из знакомых деталей: парсер → нарезка → эмбеддинги → векторная база → поиск → модель. Каждую деталь можно заменить, не трогая остальные. Поменял модель генерации — конвейер не заметил. Переехал с pgvector на Qdrant — остальное работает как работало. Такая модульность — одна из главных причин, почему RAG стал стандартным паттерном: он не привязывает тебя к одному поставщику.

Ограничения RAG: честно о слабых местах

RAG — не волшебная таблетка, и лучше знать его слабые места заранее.

Качество ответа зависит от качества нарезки. Если документы порезаны криво — чанки рвут мысль пополам или, наоборот, содержат три разные темы сразу, — поиск будет находить не то, и модель честно ответит по неправильному куску. Проблема «мусор на входе — мусор на выходе» никуда не делась.

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

Галлюцинации уменьшаются, но не исчезают. Если в найденных чанках ответа нет, модель может всё равно попытаться что-то сочинить. Борются с этим инструкциями в промпте («отвечай только по приведённым фрагментам, если ответа нет — скажи об этом»), но стопроцентной гарантии не даёт никто.

Это не готовое решение «из коробки». Собрать рабочий RAG с нуля требует технических навыков: поднять базу, написать конвейер обработки документов, подключить API, отладить поиск. Вайбкодеру в этом помогает ИИ-ассистент, но всё равно это проект на несколько итераций, а не кнопка «сделать хорошо». Если задача — просто позадавать вопросы к паре PDF, готовый NotebookLM или ChatPDF справится быстрее и проще.

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

Как проверить, что твой RAG работает

Собрал систему — не спеши отдавать её пользователям. Простая проверка занимает вечер и экономит недели разбора жалоб.

Составь список контрольных вопросов. Возьми 20–30 реальных вопросов, которые будут задавать пользователи: часть — с прямыми ответами в документах, часть — с формулировками «другими словами», часть — на темы, которых в документах вообще нет. Прогони все через систему и разбери ответы.

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

Проверь поведение на вопросах без ответа. Спроси о том, чего в базе нет. Правильное поведение — честное «в моих материалах этого нет». Если бот уверенно выдумывает — усиливай инструкцию в промпте.

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

Частые вопросы

Что такое RAG простыми словами — одной фразой?

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

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

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

Нужно ли уметь программировать, чтобы использовать RAG?

Чтобы пользоваться готовыми сервисами, где RAG уже встроен (NotebookLM, ChatPDF), — нет. Чтобы собрать собственную RAG-систему в своём приложении — нужен код, но в подходе вайбкодинга его пишет ИИ-ассистент по твоим задачам. От тебя требуется понимать механику и уметь проверять результат.

RAG — это то же самое, что поиск по ключевым словам?

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

Всякую ли задачу стоит решать через RAG?

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

Сколько стоит собрать свой RAG?

Точной цифры нет — зависит от объёма данных и числа запросов. Платить придётся за вызовы API эмбеддингов и языковой модели (по факту использования), плюс за хостинг базы, если она облачная. Для небольшого проекта расходы обычно скромные; актуальные тарифы смотри на сайтах сервисов.

Заключение

RAG — это концепция и механика, а не отдельный сервис, который можно купить. Схема простая: документы нарезаются на чанки, чанки превращаются в векторы и складываются в векторную базу, а при каждом вопросе система находит ближайшие по смыслу куски и отдаёт их модели как контекст для ответа. Именно так под капотом работают NotebookLM, ChatPDF и большинство «умных» чат-ботов поддержки.

Для тебя как для вайбкодера польза двойная. Во-первых, теперь понятно, что происходит внутри готовых инструментов — и где у них потолок. Во-вторых, ты знаешь, куда смотреть, когда готовые сервисы перестают подходить под задачу: чат-бот по своей документации, поиск по тысячам отзывов, ассистент по базе знаний — всё это собирается из знакомых кирпичиков: Firecrawl для сбора текстов, pgvector или отдельная векторная база для хранения, Claude API или OpenAI API для генерации ответов. Поставить такую задачу ИИ-ассистенту — вполне посильный следующий шаг после первых проектов курса.