RAG (Retrieval-Augmented Generation, генерация с дополнением найденным) — подход, в котором поиск дополняет генерацию: прежде чем большая языковая модель (LLM) ответит, приложение находит подходящие фрагменты во внешней базе знаний и добавляет их в запрос. На практике RAG включает документы, поиск, сборку контекста и саму LLM, которая пишет ответ по принесенным фрагментам.
Содержание
RAG-агент (агентный RAG) — вариант, в котором модель сама решает, когда искать, какой запрос задать и какой инструмент вызвать. Дальше разберем конвейер на одном примере, причины ошибок RAG и случаи, когда к поиску добавляют инструменты. Статья опирается на разборы преподавателей с открытых уроков Otus, ближайшие уроки по LLM и RAG — в расписании открытых уроков.
Зачем LLM внешняя база знаний
LLM обучают на общих корпусах текстов. Поэтому модель не видела внутренних регламентов компании, не знает того, что появилось после сбора обучающих данных, а когда факта не хватает, может уверенно сочинить правдоподобный ответ — галлюцинацию.
Положить в запрос все документы целиком обычно не выходит: руководство на 100-200 страниц может не поместиться в контекстное окно, а длинный разнородный контекст зашумляет ответ — модели хуже находят в нем один нужный факт (проблема «иголки в стоге сена»).
RAG дает модели не всю библиотеку, а несколько фрагментов по вопросу. Подход описан в 2020 году в статье исследователей Facebook AI Research «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» — еще до появления ChatGPT.
Как устроен RAG: три шага на одном примере
Название совпадает с шагами: retrieval — поиск фрагментов, augmented — дополнение запроса найденным, generation — генерация ответа. Пройдем их на вопросе сотрудника во внутреннюю службу поддержки: «Как оформить замену ноутбука и сколько ждать решения по заявке?». Термины, которые понадобятся дальше:
| Термин | Что это |
|---|---|
| Чанк | Фрагмент документа, по которому ищут |
| Эмбеддинг | Вектор чисел, отражающий смысл текста |
| Векторная база | Хранилище эмбеддингов с поиском ближайших |
| Ретривер | Компонент, который находит фрагменты под вопрос |
| Реранкер | Вторая модель, которая переставляет найденное по релевантности |
Подготовка: документы режут на чанки
Заранее документы разбивают на чанки: короткий фрагмент на одну тему проще найти, чем документ, где смешаны установка, обслуживание и гарантия.
Резать можно по структуре (главы, пункты, статьи закона, функции в коде) или по длине с перекрытием — например, по 512 токенов, где каждый кусок захватывает около 100 токенов конца предыдущего, чтобы мысль на стыке не потерялась. Встречается ориентир около 256 слов на чанк, но это эвристика: размер подбирают под данные и под максимальную длину входа модели эмбеддингов.
Регламент сервисных заявок из примера лучше резать по пунктам: иначе условие окажется в одном чанке, а исключение из него — в другом. Еще две детали: таблицы не рвут без шапки (делят, повторяя заголовок в каждом куске), а в метаданные чанка пишут документ, страницу и дату — по ним ассистент покажет источник ответа.
Эмбеддинги и векторный поиск
Каждый чанк прогоняют через модель эмбеддингов, и она превращает текст в вектор. Тексты, близкие по смыслу, например «как подключиться к корпоративному VPN» и «настройка VPN для удаленного доступа», получают векторы, направленные почти в одну сторону. Близость обычно считают как косинус угла между векторами: чем он ближе к 1, тем сильнее тексты совпадают по смыслу.
Векторы хранят в векторной базе (Qdrant, Milvus, Chroma, расширение pgvector для PostgreSQL). Вопрос превращают в вектор той же моделью и достают top-k ближайших чанков. Так работает семантический поиск: он сравнивает векторы и найдет пункт о замене оборудования, даже если в вопросе написано «поменять ноутбук». Полнотекстовый поиск опирается на термины и их обработку: анализаторы приводят слова к основе и подключают словари синонимов, а точные коды и артикулы он находит надежнее векторного. Поэтому на практике их часто сочетают — об этом ниже.
Модели эмбеддингов берут с Hugging Face через библиотеку sentence-transformers (например, multilingual-e5, BGE-M3, для русского — также FRIDA) или по API; англоязычная all-MiniLM-L6-v2 для русских текстов слабая. Рейтинги быстро меняются, поэтому модель проверяют на своих вопросах.
Сборка промпта и генерация
Найденные фрагменты вставляют в промпт вместе с вопросом и инструкцией. Сама LLM в документы не ходит: поиск и вставку делает код приложения. Обычно берут три-пять фрагментов и отсекают слабые совпадения порогом по оценке близости; порог подбирают на своих данных.
Ниже минимальный полный пример шагов retrieval и augmented на Python: три фрагмента, вопрос, два ближайших к нему и готовый промпт (вызов LLM опущен). Код проверен 22.10.2026 на Python 3.9, sentence-transformers 5.1.2 и модели intfloat/multilingual-e5-small:
# pip install sentence-transformers
from sentence_transformers import SentenceTransformer
chunks = [
"Регламент сервисных заявок, п. 3.1: заявку на замену рабочего ноутбука подает руководитель отдела через портал поддержки.",
"Регламент сервисных заявок, п. 3.4: заявку на замену оборудования рассматривают в течение пяти рабочих дней.",
"Инструкция по VPN: для удаленного доступа установите клиент и получите токен у администратора.",
]
model = SentenceTransformer("intfloat/multilingual-e5-small")
# моделям e5 нужны префиксы: "passage: " для фрагментов, "query: " для вопроса
chunk_vecs = model.encode(["passage: " + c for c in chunks], normalize_embeddings=True)
question = "Как оформить замену ноутбука и сколько ждать решения по заявке?"
q_vec = model.encode("query: " + question, normalize_embeddings=True)
scores = chunk_vecs @ q_vec # для векторов длины 1 это косинусная близость
top = scores.argsort()[::-1][:2] # индексы двух самых близких фрагментов
context = "\n".join(f"[{n}] {chunks[i]}" for n, i in enumerate(top, start=1))
prompt = (
"Ответь только по фрагментам ниже и укажи номер фрагмента. "
"Если ответа в них нет, так и скажи.\n\n"
f"Фрагменты:\n{context}\n\nВопрос: {question}"
)
print(prompt)В промпт попадут оба пункта регламента сервисных заявок, а фрагмент про VPN — нет. В нашем прогоне оценки близости составили около 0,85 и 0,83 у пунктов регламента и около 0,79 у постороннего фрагмента. Числа зависят от версии модели и окружения и при повторе могут сдвинуться, поэтому ориентируйтесь на порядок результатов. Разрыв при этом невелик — у моделей e5 значения сжаты у верхней границы, так что порог отсечения подбирают на своих вопросах, а не задают на глаз. В реальной системе вместо списка chunks будет векторная база, а вместо print — запрос к LLM. Как собрать такой конвейер целиком, с хранилищем, реранкером и оценкой качества, разбирают на курсе «LLM-инженер».
Почему RAG ошибается
RAG снижает вероятность выдуманных ответов, но не до нуля: ретривер может не найти нужный документ или принести похожий, но не тот, и модель добросовестно ответит по нему. Поэтому ошибки чаще ищут в данных и поиске. Типичные симптомы, их причины и способы исправления:
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Ответ по постороннему документу | Много однотипных разделов («Побочные действия» у разных лекарств), а в чанке нет названия объекта | Добавить в чанк название документа (или переписать чанк с помощью LLM), фильтровать по метаданным |
| Не находится код ошибки или артикул | Для вектора такой токен почти не несет смысла | Гибридный поиск: полнотекстовый плюс векторный |
| Перепутаны значения таблицы | Таблица разорвана без шапки | Переразбить с повтором заголовка |
| Уточнение «а когда нельзя?» уходит мимо | Короткий вопрос без контекста диалога | Перед поиском переписать запрос с учетом переписки |
Если ответа в найденном нет, модель часто все равно пытается его составить, поэтому в инструкцию добавляют право на отказ, а в поддержке — передачу вопроса оператору.
Как улучшать качество RAG
Порядок ниже — практический ориентир от дешевых шагов к дорогим, а не закон:
- Измерить: на реальных вопросах с известными ответами отдельно проверять, попал ли нужный фрагмент в top-k и верен ли ответ по нему.
- Навести порядок в документах: дубли, распознавание сканов, таблицы, даты. Это дорого, но по опыту внедрений сильнее всего влияет на точность.
- Гибридный поиск и словарь терминов: полнотекстовый поиск (например, BM25 в OpenSearch или Elasticsearch) вместе с векторным, синонимы, расшифровка внутренних кодов в контексте.
- Реранкинг: взять 20-30 кандидатов, переставить их моделью-реранкером и отдать в промпт три-пять лучших.
- Сужение контекста: найти большой фрагмент и программно выделить нужный пункт.
- Дообучение и более крупная модель — в последнюю очередь.
Если поиск приносит правильные фрагменты, а ответ неверный, начинать стоит с инструкции и модели. Для документов со схемами и графиками есть мультимодальный RAG, для баз с множеством похожих объектов — графовый.
RAG, обычный поиск или дообучение: что выбрать
Первый вопрос — нужна ли генерация вообще: если пользователю нужен сам документ, а не пересказ, хватит хорошего поиска. Остальные варианты сведены в таблицу:
| Задача | Что взять | Когда иначе |
|---|---|---|
| Найти документ, читатель прочтет сам | Поиск | Нужен сжатый ответ из нескольких источников — RAG |
| Отвечать по актуальным фактам своих документов со ссылкой на источник | RAG | Документов мало и они целиком влезают в контекст — промпт без поиска |
| Освоить лексику, стиль и формат ответов домена | Дообучение, например LoRA | Для точных фактов к нему добавляют RAG |
| Посчитать, сходить во внешнюю систему, сделать несколько шагов | Агентный RAG | Шаги всегда одни и те же — фиксированный конвейер в коде |
Затраты на RAG зависят от индексации, модели эмбеддингов, поиска, LLM и нагрузки. Начните с небольшого прототипа из готовых компонентов и сравните стоимость поиска, индексации и генерации на своих запросах, а MVP стройте только после проверки на реальных вопросах.
Агентный RAG: когда к поиску добавляют инструменты
В классическом RAG путь фиксирован: вопрос — поиск — промпт — ответ. В агентном поиск становится одним из инструментов, которыми модель распоряжается сама: решает, хватает ли данных, искать ли еще и где, нужен ли калькулятор, API трекера задач или веб-поиск. Сама модель ничего не вызывает — она выдает запрос на вызов в заданном формате, а код приложения его выполняет и возвращает результат в контекст.
Распространенный шаблон такого цикла — ReAct (Reasoning and Acting, 2022): рассуждение — действие — наблюдение — снова рассуждение, пока ответ не готов. Пример, где простого RAG мало: нужно найти нормы в справочнике и посчитать по ним. LLM часто ошибается в точной арифметике, поэтому агент найдет нормы, извлечет числа из найденного и из вопроса и вызовет калькулятор. Чем различаются два варианта:
| Признак | Классический RAG | Агентный RAG |
|---|---|---|
| Кто решает, искать ли | Код, поиск всегда | Модель |
| Сколько поисков | Обычно один | Сколько понадобится |
| Инструменты | Только поиск | Поиск, калькулятор, API систем |
| Стоимость и задержка | Ниже | Выше: больше вызовов модели |
Типичная поломка агента — петля: он раз за разом вызывает один инструмент с теми же параметрами. Поэтому ограничивают число шагов, при срыве передают запрос оператору, а для действий с последствиями оставляют подтверждение человеком (human-in-the-loop). Как это выглядит в проекте, можно посмотреть в кейсе выпускника Otus «RAG-агент для автоматизации инцидент-менеджмента».
Выводы
Коротко о главном:
- RAG дополняет генерацию найденным: ретривер достает фрагменты из базы знаний, код вставляет их в промпт, LLM отвечает по ним.
- Качество определяется в основном данными и поиском: нарезкой чанков, таблицами и метаданными, моделью эмбеддингов, гибридным поиском.
- RAG снижает вероятность галлюцинаций, но не исключает их, поэтому нужны измерения, право на отказ и реранкинг.
- Агентный RAG нужен, когда к ответу добавляются расчеты, внешние системы или несколько шагов поиска; за это платят задержкой, стоимостью и риском петель.
Где применяется RAG и как освоить его на практике
RAG используют в ассистентах поддержки, в поиске по внутренней документации и коду, в справочных системах для инженеров и юристов — везде, где ответ должен опираться на конкретный документ.
Собирать RAG-конвейер, подбирать эмбеддинги и реранкер, добавлять агентную часть и доводить систему до продакшена учат на курсе «LLM-инженер». Познакомиться с темой и преподавателями до записи можно на открытых уроках Otus.
Смежные темы: Векторы: операции, длина и применение в ML и графике, Нейросети: как работают, достоинства и недостатки, популярные программы, RAG-агент для автоматизации инцидент-менеджмента.
FAQ
Нужна ли для RAG видеокарта?
Не обязательно. Легкие модели эмбеддингов и векторная база работают на сервере с CPU, а генерацию можно получать по API. Небольшую или квантованную LLM реально запустить локально и на CPU, а GPU нужен, чтобы крупные модели отвечали с приемлемой скоростью.
Можно ли обновлять знания RAG без переобучения модели?
Да. Новые документы нарезают и индексируют, устаревшие удаляют из векторной базы — модель не меняется, а на следующий вопрос уже получит свежие фрагменты.
Нужно ли знать машинное обучение, чтобы строить RAG?
Для первого прототипа хватает бэкенд-навыков: модели берут готовыми. Понимание эмбеддингов, реранкеров и оценки качества нужно, когда систему доводят до стабильной работы на реальных данных.
