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

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

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

Дальше — механизм по четырём шагам, разбор того, где именно ломается качество, с распределением причин ошибок; что обязано быть в каждом ответе; сколько стоит собрать такую систему в России на сентябрь 2026 и какие строки в смету обычно не кладут; три реалистичных пути реализации; методика замера качества на контрольном наборе вопросов; расчёт окупаемости и честный список случаев, когда RAG не нужен.

Механизм за четыре шага

Возьмём живой вопрос сотрудника розничной сети: «Клиент вернул кроссовки без коробки через 12 дней, чек есть, маркировка на самой паре. Принимать?». В нём три условия и одна отраслевая тонкость — обязательная маркировка. Посмотрим, что система делает с этим вопросом от нажатия «отправить» до ответа на экране.

1. 1
   Шаг 1. Вопрос превращается в поисковый запрос

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

2. 2
   Шаг 2. Поиск находит фрагменты в вашей базе

   Ищется не документ целиком, а куски по 300–800 слов, на которые база была заранее нарезана. Хороший поиск комбинирует два способа: по смыслу — через векторное представление текста, и по точному совпадению слов — чтобы не потерять артикул, номер приказа или название товарной группы. На выходе — 3–7 фрагментов, отсортированных по релевантности. Ровно здесь возникает большинство ошибок всей системы.

3. 3
   Шаг 3. Фрагменты подставляются в запрос к модели

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

4. 4
   Шаг 4. Ответ собирается и снабжается ссылкой

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

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

Почему это дешевле и честнее дообучения

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

Это не значит, что дообучение бесполезно. Оно решает свою задачу: научить модель говорить в вашем стиле, использовать вашу терминологию, выдавать ответ в жёстком формате. Но факты через него передавать нельзя — ни проверить, ни быстро обновить их не получится. Рабочая комбинация в тех редких случаях, когда нужны обе части: факты приходят через поиск, стиль и формат — через дообучение или через тщательно собранные примеры в запросе. Для 9 из 10 бизнес-задач достаточно первой половины.

Где ломается качество: в 8 случаях из 10 виноват поиск

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

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

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

Что должно быть в каждом ответе

Требование одно и оно жёсткое: ответ без указания источника не принимается. Не «согласно внутренним документам», а «Регламент возвратов, редакция от 14.03.2026, пункт 4.2» — с возможностью открыть этот пункт одним нажатием. Без этого система бесполезна ровно в тех случаях, ради которых её покупали: сотрудник не может опереться на ответ в разговоре с клиентом, руководитель не может разобрать спорную ситуацию, а вы не можете доказать, что персонал действовал по регламенту.

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

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

Подготовка базы: самая дорогая и самая полезная часть

База знаний из 380 документов и 2 100 страниц не превращается в поисковый индекс нажатием кнопки, и это не жадность подрядчика, а свойство ваших файлов. Регламент в виде скана без текстового слоя надо распознать — этим занимаются Content AI (российский преемник ABBYY: ContentReader вместо FineReader, ContentCapture вместо FlexiCapture), Smart Engines или 1С:Распознавание первичных документов. Три версии одного приказа надо свести к действующей. Таблицу с условиями акций надо превратить в текст, который поиск сможет найти. Пятнадцать инструкций, живущих в переписке, надо записать.

Отдельная и почти всегда недооценённая работа — таблицы. Условия акций, тарифная сетка, сроки поставки по регионам обычно живут в таблицах, а поиск по смыслу работает с текстом: строка «Москва — 2 дня — от 5 000 ₽ бесплатно» сама по себе не отвечает ни на один человеческий вопрос. Такие таблицы либо переводятся в текстовые формулировки при нарезке, либо выносятся в отдельный источник, к которому система обращается запросом, а не поиском. Если в вашей базе больше десятка значимых таблиц, спросите подрядчика прямо, что он с ними будет делать: ответ «мы их тоже проиндексируем» означает, что на вопросы про сроки и цены система будет отвечать неверно.

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

Сколько стоит: разбор бюджета на 175 000 ₽

Рыночный ориентир на сентябрь 2026 для базового агента с поиском по базе знаний — 150 000–200 000 ₽ и 3–8 недель. Разброс объясняется тремя вещами: объёмом и состоянием документов, числом каналов, где система должна отвечать, и наличием разграничения прав. Ниже — середина вилки в разборе по строкам для нашего примера: розничная сеть на 40 магазинов, база 380 документов, помощник отвечает сотрудникам в MAX и во внутреннем портале.

Что в эту сумму не входит и о чём стоит спросить заранее, чтобы не получить сюрприз на третьей неделе. Коннекторы к учётным системам — «посмотри статус заказа в 1С» или «покажи карточку клиента из CRM» — это ещё 60 000–120 000 ₽ и 1–2 недели: помощник по документам и агент с доступом к данным решают разные задачи. Разграничение прав по ролям, когда продавец видит одни разделы, а руководитель другие, — 40 000–90 000 ₽. Голосовой канал — 80 000–150 000 ₽ плюс расходы на телефонию. Массовое распознавание архива сканов — 50 000–120 000 ₽ в зависимости от объёма и качества.

Три пути реализации в России на сентябрь 2026

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

Два уточнения, которые чаще всего всплывают поздно. Первое: если среди ваших заказчиков есть государственные организации или компании с госучастием, проверяйте не только физическое расположение серверов, но и наличие конкретного продукта в реестре отечественного ПО — это разные вещи, и данные в российском облаке сами по себе включения в реестр не означают. Проверка занимает десять минут и делается по названию продукта до начала проекта, а не на согласовании закупки. Второе: в третьем варианте расходы выглядят обманчиво низкими, пока не посчитан администратор. Аренда сервера с подходящей видеокартой в российских дата-центрах стоит примерно 60 000–200 000 ₽ в месяц, собственное железо начинается от полутора миллионов, и к этому добавляется человек, который будет всё это обновлять.

Отдельно про зарубежные модели, потому что их продолжают закладывать в проекты. Прямая оплата OpenAI и Anthropic из России невозможна, страна не входит в список поддерживаемых для их API, доступ идёт через рублёвых посредников. Для системы, на которую опирается работа сорока магазинов, это не инструмент, а точка отказа: посредник может исчезнуть, тариф — измениться, а вопрос о том, где физически обрабатываются данные, останется открытым. В новых внедрениях мы исходим из российских моделей или из открытых на своём сервере, а зарубежную допускаем максимум как запасной вариант для редких запросов на обезличенных данных. Требование к архитектуре одно: вызовы модели идут через собственный слой абстракции, чтобы смена поставщика стоила дней, а не переписывания системы.

Как проверить качество: замер на 100 вопросах

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

1. 1
   Соберите 100 реальных вопросов

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

2. 2
   Замерьте попадание нужного документа в найденное

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

3. 3
   Проверьте ссылки и отказы

   Доля ответов со ссылкой на конкретный документ и пункт должна быть 100 % — это не метрика качества, а условие приёмки. Доля корректных отказов на вопросах, которых нет в базе, — не ниже 90 %: система обязана говорить «не знаю», а не строить правдоподобную версию.

4. 4
   Прочитайте 50 ответов глазами

   Возьмите 50 ответов из числа тех, где документ нашёлся, и оцените по трём пунктам: соответствует ли ответ найденному фрагменту, не добавлено ли лишнего, годится ли формулировка для показа клиенту. Ошибок этого типа должно быть не больше 5 %. Тот же чек-лист потом становится основой еженедельного выборочного контроля.

5. 5
   Зафиксируйте порог в договоре

   Числа из пунктов 2–4 записываются как условия сдачи с конкретными значениями, а не как «система должна работать корректно». Тогда спор о качестве превращается в сверку протокола, а не в обмен мнениями. Формулировки для этого раздела мы разбирали в материале о договоре на разработку.

Считаем окупаемость на 2 000 вопросов в месяц

Вводные модельного примера: розничная сеть, 40 магазинов, 260 человек в торговых залах. В месяц сотрудники задают около 2 000 вопросов по регламентам — возвраты, маркировка, условия акций, кассовая дисциплина. Сейчас на них отвечают два методиста в офисе: около 7 минут на вопрос с учётом поиска нужного документа, ставка с налогами примерно 700 ₽/час. Система закрывает без человека 65 % вопросов — консервативная оценка для базы такого размера.

Две оговорки, без которых расчёт нечестен. Первая: экономия здесь не в сокращении методистов, а в возвращённом времени — они перестают отвечать на повторяющиеся вопросы и занимаются обучением и разбором сложных случаев. Если такой работы в компании нет, экономия останется на бумаге. Вторая: расчёт держится на доле 65 %. Она проверяется на пилоте за 2–3 недели, и если по журналу выходит 40 %, честный вывод — вернуться к подготовке базы, а не расширять функциональность.

Есть и вторая, менее очевидная статья выгоды, которую в этом расчёте мы не учитывали. С 2026 года обязательная маркировка охватывает 27 товарных групп, а ЦПТ 2.0 автоматически блокирует продажу при ошибке — контроль стал сплошным вместо выборочного. Каждый случай, когда продавец действует по устаревшей инструкции, теперь оборачивается не замечанием, а остановленной продажей на кассе. Стоимость такой ошибки считать сложнее, чем минуты методиста, но в рознице она часто оказывается больше.

Карта раздела: где разбирается каждый шаг

Эта статья — вход в раздел про технологии языковых моделей, и каждый шаг схемы в нём развёрнут отдельно.

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

Когда RAG не нужен

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

• База маленькая и стабильная — до 20–30 страниц. Тогда весь текст помещается в запрос целиком, поиск не нужен вовсе, а ответы получаются точнее: система физически не может не найти нужное место.
• Ответ лежит в одном поле учётной системы. «Где мой заказ» — это запрос в 1С, а не поиск по документам. Здесь нужен коннектор за 60 000–120 000 ₽, и никакая база знаний его не заменит.
• Вопросов много, но они одинаковые. Двадцать типовых вопросов закрываются кнопочным меню за 30 000–120 000 ₽: ответ воспроизводим, проверять нечего, счёта за вызовы модели нет.
• Правило формулируется в три строки. «Возврат обуви без коробки принимаем, если чек есть и маркировка читается» — это строка в памятке на кассе, а не повод для внедрения.
• Документы противоречат друг другу, и никто не знает, какая версия действует. Пока это так, система будет уверенно цитировать отменённый приказ. Сначала ревизия документов, потом автоматизация.
• Меньше 300–400 вопросов в месяц и все от одного отдела. Постоянные расходы контура — около 33 000 ₽ в месяц независимо от нагрузки — съедят всю экономию. Дешевле собрать памятку и назначить дежурного.

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