Что такое RAG простыми словами: как нейросеть отвечает по вашим документам

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

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

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

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

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

Три буквы расшифровываются как retrieval-augmented generation, по-русски «генерация, дополненная поиском». Порядок слов в названии и есть описание работы: сначала поиск, потом генерация ответа. Механизм не новый и не маркетинговый: его описали в статье «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», принятой на конференцию NeurIPS в 2020 году.

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

1. Хранилище. Ваши документы, порезанные на куски и разложенные так, чтобы по ним можно было искать по смыслу. Это не папка на диске и не база данных в привычном виде.
2. Поиск. Часть, которая по вопросу человека достаёт из хранилища несколько относящихся к делу кусков. Именно здесь чаще всего и ломается качество.
3. Генерация. Нейросеть, которая получает вопрос вместе с найденными кусками и пишет связный ответ.

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

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

Почему нейросеть без RAG уверенно врёт

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

Вторая причина тоньше и важнее. Казалось бы, на незнакомый вопрос модель должна ответить «не знаю». На практике она отвечает уверенно и неправильно. В сентябре 2025 года OpenAI выпустила исследование «Why language models hallucinate», где объясняет причину прямо: и обучение, и принятые способы проверки моделей поощряют угадывание, а не признание неуверенности. Модель ведёт себя как студент на экзамене, которому за пустой ответ ставят ноль, а за наугад написанный есть шанс получить балл.

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

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

Как выглядит поиск по документам: путь одного вопроса

Разберу по шагам, что происходит внутри RAG, на живом вопросе: «Вы возите в Калининград и сколько это займёт?»

1. Вопрос превращается в набор чисел. Тот же механизм, которым заранее обработали ваши документы. Дальше объясню, что это за числа и почему они отражают смысл.
2. Поиск находит ближайшие куски. Ищет по близости смысла: буквальное совпадение слов тут необязательно. Система возвращает заданное количество самых подходящих фрагментов - обычно от трёх до десяти, это настройка.
3. К каждому куску прилагается оценка. Поиск не просто отдаёт текст, он говорит, насколько уверен. Важная деталь: по этой оценке можно отсекать слабые совпадения и заставлять систему честно говорить «не нашёл».
4. Куски и вопрос уходят в модель одним пакетом. Технически модель получает примерно такое: «вот вопрос клиента, вот три абзаца из документов компании, ответь только по ним, если ответа нет - так и скажи».
5. Модель пишет ответ, система прикладывает источники. Откуда какой абзац взят, обычно известно с точностью до файла и раздела.

Два вывода, которые стоит унести из механики RAG.

Модель никогда не видит всю вашу базу целиком. Она видит несколько кусков, которые ей принёс поиск. Значит, качество ответа определяется качеством поиска в первую очередь и качеством модели во вторую. Компании обычно покупают дорогую модель и экономят на подготовке документов, а результат зависит ровно наоборот.

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

Что такое чанки и эмбеддинги простыми словами

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

Здесь же первая встроенная проблема. Резать текст умно дорого, поэтому по умолчанию его режут механически, по объёму. В документации Yandex AI Studio это сказано открытым текстом: при разбиении на фрагменты смысл не учитывается, и текст может быть разделён, например, в середине предложения, а контекст окажется неполным. Лечат перекрытием: соседние куски делают внахлёст, чтобы важное на стыке не обрывалось.

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

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

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

Обратная сторона тоже есть. Смысловой поиск плохо ловит то, у чего смысла нет: артикулы, серийные номера, фамилии, аббревиатуры. Запрос «ТР-4412» векторному поиску ничего не говорит. Поэтому в нормальных системах поиск делают гибридным: параллельно работают смысловой поиск и обычный поиск по точным словам, а результаты объединяются. Если подрядчик про гибридный поиск молчит, а в вашей номенклатуре тысячи артикулов - это повод для вопроса.

Почему ответ приходит со ссылкой на источник

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

Что меняется в работе, лучше всего видно на трёх ситуациях.

Спор с клиентом. Менеджер вместо «мне так бот сказал» открывает документ, на который бот сослался. Разговор из «кто прав» превращается в «вот пункт 4.2».

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

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

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

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

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

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

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

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

Почему «загрузить все файлы в чат» - это не RAG

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

Первое: объём всё равно кончается. Пока у вас пять файлов, приём работает. Когда их триста, включая архив договоров, не влезет ни в какое окно. Для сравнения: в поисковом индексе Yandex AI Studio можно держать до десяти тысяч файлов размером до 128 МБ каждый. Модель при этом получает только те куски, которые относятся к вопросу.

Второе: длинный текст читается неровно. Эффект измерен. В работе «Lost in the Middle», опубликованной в журнале TACL в 2024 году, авторы показали такое: точность модели заметно падает, когда нужная информация лежит в середине длинного контекста. Выше всего она держится, когда нужное стоит в начале или в конце. Причём верно и для моделей, специально рассчитанных на длинный вход. То есть загрузить в чат триста страниц и надеяться, что модель одинаково внимательно прочитает все, нельзя.

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

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

Есть и пятое, денежное. Каждый вопрос в переписке с приложенными файлами оплачивается по всему объёму - вы платите за триста страниц снова и снова. Поиск отдаёт модели несколько абзацев. На сотне вопросов в день разница перестаёт быть теоретической.

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

Что меняется в работе компании, когда появляется RAG

Опишу по местам, где это заметно.

Первая линия поддержки. Типовые вопросы про условия, сроки и совместимость закрываются ответом из вашего же документа, без пересказа менеджера по памяти. Человеку остаются спорные и дорогие случаи. Как такая связка выглядит целиком, разобрано в статье про чат-бот поддержки.

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

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

Документы и тендеры. Вопросы по многостраничным договорам и техническим заданиям закрываются с указанием на конкретный пункт. Здесь механизм окупается быстрее всего, потому что цена невнимательности измерима.

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

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

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

Где RAG не помогает

Случай первый: ответа нет. Механизм достаёт то, что есть, и не создаёт того, чего нет. Если правило живёт только в голове коммерческого директора, поиск его не найдёт. Признак: система честно отвечает «не нашёл» на вопросы, которые сотрудники считают очевидными. Не поломка - перепись пробелов.

Случай второй: документы врут или спорят. Система отдаст обе версии или ту, что окажется ближе по смыслу. Признак: два одинаковых вопроса дают разные ответы в разные дни. Лечится это решением, какая версия главная; настройка поиска тут ни при чём.

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

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

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

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

Сколько стоит держать RAG живым

Про деньги в цифрах здесь говорить бессмысленно: разброс огромный и зависит от объёма базы, числа вопросов и выбранной модели. А вот структура расходов одинаковая, и её стоит знать до разговора с подрядчиком.

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

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

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

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

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

С чего начать: что готовит сам заказчик

1. Соберите тридцать-пятьдесят реальных вопросов дословно. Не те, которые вы придумали, а те, что лежат в переписках, с опечатками и просторечием. Рядом с каждым - правильный ответ в одну-две фразы. Этот список одновременно техническое задание, набор для проверки и материал для обучения новых сотрудников.
2. Составьте список документов с двумя колонками: кто отвечает и когда обновлялся в последний раз. Половина проблем внедрения видна уже на этом шаге: у трети файлов ответственного не найдётся вовсе, у четверти дата окажется двухлетней давности.
3. Сформулируйте правило отказа своими словами. Что система говорит, когда ответа нет: кого зовёт, за какое время этот человек отвечает, что видит клиент в эти минуты. «Передал менеджеру, ответит до 11 утра» работает, «ваш вопрос обрабатывается» нет.
4. Снимите три числа до запуска. Сколько вопросов приходит в неделю, сколько времени занимает ответ сейчас, какая доля вопросов остаётся без ответа. Через месяц те же три числа снимаются повторно, и спор о пользе превращается в арифметику.
5. Решите вопрос прав заранее. Какие документы видят все, какие только руководители, какие не уходят во внешний сервис вообще. Решение здесь за владельцем, и принимать его после запуска дороже.

Отдельно про формулировки вопросов к системе: они влияют на ответ сильнее, чем кажется, и навык тут такой же, как в работе с любой моделью. Базовые правила собраны в разборе про то, как писать промпты.

Где вы сейчас

• Слышите слово впервые, нейросетью пользуетесь через обычный чат. Ваш следующий шаг - пункт 1 из списка выше: выписать реальные вопросы. Половина пользы придёт от одного этого упражнения, ещё до всякой техники.
• Бот или ассистент уже стоит и периодически выдумывает. Проверьте две вещи: есть ли у него вообще доступ к вашим документам через RAG и написано ли правило отказа. В девяти случаях из десяти проблема здесь, а не в модели.
• Документов много, порядка нет, ответственных нет. Начинать надо с пункта 2: список файлов, ответственный, дата, и только потом техника. Иначе вы автоматизируете беспорядок и увидите его в ответах клиентам.
• Система работает, хочется большего. Ваша тема - следующая ступень, где модель не только ищет по документам, но и ходит за данными в ваши системы. Подступ к ней - разбор про базу знаний для ИИ и дальше связка с учётными программами.

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

• Собрано тридцать и больше реальных вопросов дословно, у каждого есть письменный правильный ответ, и на них проверены ответы системы.
• У каждого документа в базе есть ответственный человек и дата последнего обновления, устаревшие версии убраны из хранилища.
• Написано, что система отвечает при отсутствии ответа, кого зовёт и за какое время этот человек отвечает.
• Проверено, что файлы читаемы: в базе нет сканов без распознанного текста и таблиц, вставленных картинками.
• В ответах видно источник: файл и раздел, откуда взят каждый факт; проверено это на десяти разных вопросах.
• Записаны три числа до запуска: вопросов в неделю, время ответа сейчас, доля вопросов без ответа.
• Решено, какие документы не уходят во внешний сервис, и это решение записано в документе.

Если после списка всё ещё непонятно, что именно нужно вам - поиск по документам, бот или связка с учётной системой, - ответьте на четыре вопроса квиза на главной. Он показывает, где у вас теряется время, и с чего разумно начинать.