Сотрудник поддержки спрашивает ИИ-агента: «В какой срок передать заявку на возврат в отдел качества?» Ему нужен срок из внутреннего регламента компании и текст, который этот срок подтверждает.
RAG (Retrieval-Augmented Generation или «генерация с дополненной выборкой») — способ подготовить ответ ИИ с предварительным поиском сведений в документах или других внешних источниках. Сначала система находит подходящий материал, затем передаёт его вместе с вопросом языковой модели. Это та часть ИИ, которая составляет ответ. Название Retrieval-Augmented Generation описывает эту связь. В этом названии retrieval означает поиск, augmentation означает дополнение вопроса найденными сведениями, а generation означает создание ответа. При этом найденный текст и составленный по нему ответ остаются двумя разными результатами.
Для примера возьмём вымышленный регламент компании. В нём указано, сколько времени есть у сотрудника на передачу заявки в отдел качества после регистрации запроса. Разберём, как система находит это правило, какие сведения передаёт ИИ и как мог бы выглядеть ответ сотруднику. Здесь нас интересует порядок работы с заявкой внутри компании, а не срок возврата товара покупателем. В регламенте описаны несколько этапов работы с заявкой: её регистрация, передача и рассмотрение. Все они связаны с возвратом, но сотрудник спрашивает только о сроке передачи. Поэтому системе нужно найти пункт, в котором указан именно этот срок.
Коротко
RAG помогает ИИ отвечать на вопросы по документам компании. Система сначала находит отрывок, в котором есть нужные сведения, затем передаёт его модели вместе с вопросом. Модель использует этот текст, чтобы составить ответ. Например, на вопрос о передаче заявки она получает пункт регламента с указанием срока и условий, от которых он зависит. Но ответ всё равно нужно проверить: выбран ли подходящий документ и сохранила ли модель все важные условия.
Поиск нужен, когда заранее неизвестно, где находится ответ: в каком документе или в какой части большого текста. Если подходящий небольшой документ уже известен, его можно передать модели целиком. Поэтому выбирать RAG стоит исходя из задачи: нужно ли сначала найти сведения или они уже под рукой.
Как система находит нужный фрагмент регламента
Чтобы ответить на вопрос сотрудника, системе нужно найти в регламенте пункт о передаче заявки. Для этого документы обычно готовят заранее: извлекают из файлов текст, а длинные документы делят на небольшие отрывки. Их называют фрагментами, так система может искать нужный пункт внутри документа и выбирать его для ответа, не передавая модели весь регламент. Подготовленный текст организуют в удобном для поиска виде. Получается поисковый индекс, который помогает системе находить совпадения с вопросом. Создавать его заново требуется не всегда: если подходящая система поиска уже есть, можно обращаться к ней.
Посмотрим, как происходит выбор в нашем примере. Системе доступны три документа: «Учебный внутренний регламент возврата» в редакции от 1 октября 2026 года, его прежняя редакция от 1 мая 2025 года и учебный регламент адаптации новых сотрудников. В сведениях о каждом документе заранее указаны подразделение и статус. Система оставляет только действующие документы службы поддержки. Поэтому прежняя редакция отсеивается по статусу, а регламент адаптации не подходит по подразделению. Система использует готовые отметки, а не определяет по тексту, какой документ устарел.
После этого остаётся один регламент. Но подходящий документ ещё не означает, что нужный пункт найден: внутри есть сведения о регистрации заявки, её передаче и рассмотрении отделом качества. Сотрудник спрашивает о передаче, поэтому системе предстоит выбрать из этих трёх фрагментов тот, который отвечает на его вопрос.
Для наглядности используем простое правило: сравним фрагменты по совпадениям с вопросом. Вручную зададим пять частей слов: «переда», «заявк», «возврат», «отдел», «качества». Части слов нужны, чтобы разница в окончаниях не мешала сравнению: например, «переда» встречается и в слове «передать», и в слове «передаёт». Поиск проверяет каждый фрагмент и считает, сколько из пяти частей в нём встретилось.
| Действие | Текст | Совпадения с вопросом | Число совпадений |
|---|---|---|---|
| Регистрация заявки | Сотрудник поддержки регистрирует заявку на возврат и присваивает номер обращения. | «заявк», «возврат» | 2 |
| Передача заявки | После регистрации запроса сотрудник поддержки передаёт заявку на возврат в отдел качества в течение двух рабочих дней. | «переда», «заявк», «возврат», «отдел», «качества» | 5 |
| Рассмотрение заявки | Отдел качества рассматривает заявку на возврат и сообщает сотруднику поддержки результаты проверки. | «заявк», «возврат», «отдел», «качества» | 4 |
Больше всего совпадений у пункта о передаче заявки: в нём есть все пять частей слов. У пункта о рассмотрении их четыре, у пункта о регистрации два. По заданному правилу система выбирает фрагмент о передаче. Он действительно отвечает на вопрос сотрудника, потому что называет нужное действие и его срок. Два других фрагмента тоже говорят о заявке на возврат, но срок передачи в них не указан.
Такой подсчёт помогает понять выбор в нашем примере. В реальных документах совпадения слов могут привести и к неподходящему отрывку, поэтому числа 2, 5 и 4 не показывают качество поиска в целом.
Найденный фрагмент из документа «Учебный внутренний регламент возврата», редакция от 1 октября 2026 года:
После регистрации запроса сотрудник поддержки передаёт заявку на возврат в отдел качества в течение двух рабочих дней.
Мы нашли правило по совпадениям частей слов, но поиск может учитывать и близость смысла. Для этого текст часто преобразуют в наборы чисел, которые называют эмбеддингами, или embeddings. Система сравнивает такие наборы, чтобы находить близкие по смыслу фразы. Их можно хранить в векторном хранилище, или vector store. Это распространённый способ организовать поиск, но для RAG он не обязателен: в нашем примере достаточно простого сравнения частей слов.
Результат поиска теперь есть: пункт регламента указывает два рабочих дня и момент, с которого считают срок. Следующий шаг состоит в том, чтобы передать этот текст модели вместе с вопросом сотрудника. Тогда у неё будут сведения, на которых можно построить ответ.
Что получает модель и как из источника получается ответ
Поиск нашёл нужный пункт регламента. Но модель ещё должна получить этот текст: само подключение документов к системе поиска не означает, что она читает их целиком. В нашей схеме найденный отрывок передаёт программа, которая управляет работой ИИ-помощника.
Программа собирает всё необходимое для ответа в одном обращении: вопрос сотрудника, пункт регламента, название документа с датой редакции и инструкцию. Вопрос теперь сопровождается сведениями, на которые модель может опереться. Такое дополнение вопроса найденным материалом называют augmentation. В нашем примере обращение выглядит так:
Пример входа модели:
- Вопрос: «В какой срок передать заявку на возврат в отдел качества?»
- Текст для ответа: «После регистрации запроса сотрудник поддержки передаёт заявку на возврат в отдел качества в течение двух рабочих дней».
- Источник: «Учебный внутренний регламент возврата», редакция от 1 октября 2026 года.
- Инструкция: «Ответь на вопрос, используя только сведения из приведённого текста. Сохрани условия срока и укажи источник».
Каждая часть здесь выполняет свою задачу. Вопрос указывает, что нужно узнать; текст регламента содержит срок и условия его отсчёта; название и дата помогают найти источник для проверки. Инструкция задаёт требования к тому, как составить ответ: использовать приведённые сведения, сохранить условия и назвать источник. По одному названию документа модель не смогла бы определить срок, поэтому ей передают и сам пункт регламента. Подробнее о том, какие сведения получает модель, можно прочитать в статье о контексте.
В нашей схеме программа сначала ищет текст, затем передаёт его модели. В других системах модель может сама запросить поиск через доступную ей функцию; такие варианты называют агентными. Порядок работы может различаться, но для составления ответа модель всё равно должна получить найденные сведения.
Когда вопрос и пункт регламента собраны вместе, модель может изложить правило в виде ответа сотруднику. Этот этап называют generation, или генерацией. В нашем учебном примере ответ мог бы выглядеть так:
Заявку на возврат сотрудник поддержки передаёт в отдел качества в течение двух рабочих дней после регистрации запроса. Основание — «Учебный внутренний регламент возврата», редакция от 1 октября 2026 года.
Поиск выбрал пункт регламента, а ответ передаёт его содержание сотруднику. Между этими шагами программа подготовила обращение к модели с вопросом, найденным текстом и инструкцией. Теперь важно проверить, не изменился ли смысл при составлении ответа: осталось ли указание на рабочие дни, сохранён ли момент начала отсчёта и говорится ли именно о передаче заявки.
Как проверить ответ по найденному регламенту
Ответ называет срок и документ, из которого он взят. Чтобы понять, можно ли на него опереться, нужно проверить две вещи: подходит ли найденный пункт к вопросу сотрудника и точно ли модель передала его содержание.
Сначала посмотрим на документ. В нашем примере действует «Учебный внутренний регламент возврата» в редакции от 1 октября 2026 года. Найденный пункт описывает передачу заявки в отдел качества и указывает срок этого действия. Пункты о регистрации или рассмотрении заявки не подошли бы: они говорят о том же возврате, но не отвечают на вопрос о сроке передачи.
Теперь сравним ответ с нужным пунктом. В нём важно сохранить не только число дней, но и всё правило: кто передаёт заявку, куда её передают и с какого момента считают срок. В учебном ответе все эти сведения есть: сотрудник поддержки передаёт заявку на возврат в отдел качества в течение двух рабочих дней после регистрации запроса.
Для сравнения сократим формулировку срока до «В течение двух дней» и посмотрим, что исчезло.
| Формулировка | Какие условия сохранены |
|---|---|
| «В течение двух рабочих дней после регистрации запроса» | Указаны вид дней и событие, от которого отсчитывается срок. |
| «В течение двух дней» | Потеряны слово «рабочих» и условие «после регистрации запроса». |
Число осталось прежним, но правило стало неполным. Из короткой фразы нельзя понять, нужно ли считать рабочие дни и с какого события начинается отсчёт. Название документа и дата редакции помогают найти регламент для проверки, однако не возвращают пропущенные условия в сам ответ. Поэтому ответ нужно сверять с текстом, а не доверять ему только потому, что он указывает источник.
Условия могут потеряться не только при составлении ответа. Иногда из документа выбирают слишком короткий отрывок, в котором уже нет важной части правила. Сам документ тоже может устареть, а модель может добавить сведения, которых в нём не было. Поэтому проверка охватывает весь путь: какой документ использовали, что из него передали модели и что она сообщила сотруднику. Подробнее об этих ошибках можно прочитать в статьях о том, почему RAG не устраняет галлюцинации, и о том, как проверять утверждения в ответе нейросети.
Чтобы поиск опирался на подходящие материалы, компания должна отдельно следить за обновлением документов и определять, кому разрешено их читать. Совпадение текста с вопросом не доказывает, что документ действует или что сотруднику открыт доступ к нему.
Если найденный пункт вообще не содержит срока, подтвердить ответ по нему нельзя. В такой ситуации ИИ-помощнику следует сообщить: «В найденном тексте недостаточно сведений, чтобы назвать срок передачи заявки». Подставлять число по догадке нельзя. Такой ответ при нехватке сведений нужно предусмотреть и проверить при создании системы.
В нашем примере поиск помог выбрать пункт, по которому можно ответить сотруднику. Но если подходящий документ уже известен, можно ли сразу передать его модели и обойтись без отдельного поиска?
Когда нужен поиск, а когда достаточно передать документ
Если сотрудник заранее знает, в каком регламенте есть ответ, небольшой документ можно передать модели целиком вместе с вопросом. Тогда ей сразу будут доступны нужные сведения, и отдельный поиск может не понадобиться. Наличие документов само по себе ещё не означает, что для работы с ними нужен RAG.
Но передать весь текст удаётся не всегда. Модель может принять лишь ограниченный объём сведений за одно обращение. Эту вместимость называют контекстным окном; подробнее об этом в статье о том, что помещается в контекстное окно. Если документ слишком большой, приходится выбирать из него подходящие отрывки. Поиск помогает сделать такой выбор, а также найти сведения среди нескольких документов, когда заранее неизвестно, где находится ответ.
Поэтому решение зависит от задачи: нужный материал уже найден и его можно передать напрямую или сначала требуется отобрать подходящие фрагменты? Единого размера базы документов, после которого обязательно нужен RAG, нет.
И передача целого документа, и RAG предоставляют модели текст для конкретного ответа. Обучение меняет саму модель. Разницу между этими способами показывает таблица:
| Способ | Что происходит |
|---|---|
| Передать подходящий документ целиком | Текст сразу включают в обращение к модели вместе с вопросом. |
| Использовать RAG | Сначала выбирают материал для вопроса, затем включают найденный текст в обращение к модели. |
| Обучить модель | Изменяют внутренние параметры модели, от которых зависит её работа с входными сведениями. |
Когда мы передаём регламент вместе с вопросом, модель получает сведения для этого обращения. Её внутренние параметры, от которых зависит обработка текста и составление ответа, при этом не меняются. При дополнительном обучении, которое называют fine-tuning, меняют именно параметры. Это не мешает использовать поиск вместе с обучением: в исходной работе о RAG 2020 года эти способы сочетались.
Память тоже может работать вместе с поиском, но у них разные задачи. Память сохраняет сведения для дальнейшего использования, а поиск выбирает материал для текущего вопроса. Подробнее о сохранении и возвращении сведений можно прочитать в статье «Как устроена память LLM и ИИ-агентов».
Чтобы выбрать подход для своей задачи, возьмите рабочий документ и сформулируйте вопрос к нему. Найдите пункт, который подтверждает ответ, и отметьте условия, без которых его смысл изменится. Если подходящий документ уже известен и его можно передать целиком, начните с этого. Если же нужные сведения приходится искать внутри большого текста или среди разных документов, у поиска есть конкретная задача: выбрать материал, по которому модель сможет ответить.
Частые вопросы о RAG
Чем RAG отличается от обычного ответа ИИ?
При использовании RAG система сначала ищет сведения для вашего вопроса и передаёт их модели. Поэтому ответ можно сверить с конкретным документом. Без такого поиска нельзя считать, что ИИ использовал нужный регламент компании.
Можно ли использовать RAG с одним документом?
Да. Если документ большой, поиск может выбирать нужные отрывки внутри него. Если небольшой подходящий документ уже известен, его можно передать модели целиком.
Нужна ли для RAG векторная база?
Не обязательно. Векторное хранилище помогает искать близкие по смыслу тексты, но RAG может работать и с поиском по словам. В нашем примере фрагмент выбирается по совпадениям частей слов.
Гарантирует ли RAG правильный ответ?
Нет. Поиск может выбрать неподходящий или устаревший текст, а модель может потерять условие или добавить сведения от себя. Нужно проверить документ и сравнить ответ с найденным пунктом.
Нужно ли обучать модель на документах компании?
Не обязательно: найденный текст можно передать вместе с вопросом без изменения параметров модели. При этом RAG и дополнительное обучение могут работать вместе.
Чем поиск отличается от памяти ИИ?
Поиск выбирает сведения для текущего вопроса. Память сохраняет сведения, к которым можно вернуться позже. Эти задачи различаются, но могут сочетаться в одной системе.
