RAG простыми словами: как AI отвечает по вашим документам, а не угадывает

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

Проблема, которую решает RAG

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

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

Как это устроено технически

Под капотом RAG-система обычно состоит из двух связанных процессов: подготовки данных заранее и обработки запроса пользователя в реальном времени.

• Индексация (заранее). Документы разбиваются на небольшие фрагменты (chunks), каждый фрагмент превращается в числовой вектор — эмбеддинг, отражающий его смысл, — и складывается в векторную базу данных вместе со ссылкой на исходный текст.
• Retrieval (в момент запроса). Вопрос пользователя тоже превращается в эмбеддинг, и система ищет в векторной базе наиболее близкие по смыслу фрагменты — обычно не один, а несколько, с запасом.
• Generation (в момент запроса). Найденные фрагменты вместе с исходным вопросом отправляются модели с инструкцией отвечать, опираясь именно на них, а не на общие знания.

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

Чем RAG отличается от «длинного промпта» и от дообучения

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

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

RAG не делает модель умнее — он делает так, чтобы у неё под рукой были правильные факты именно тогда, когда они нужны.

Где RAG-системы чаще всего ломаются на практике

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

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

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

Что это значит на практике для разработчика

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