RAG что это простыми словами и когда он действительно нужен

RAG что это: аббревиатура расшифровывается как Retrieval-Augmented Generation, «генерация, дополненная поиском». Идея проста: прежде чем задать вопрос модели, система находит в ваших документах несколько подходящих фрагментов и кладёт их в запрос вместе с вопросом. Модель отвечает, опираясь на этот текст, а не только на то, чему научилась при обучении. Ниже разбираем, как RAG работает, из чего состоит и в каких случаях он не нужен вовсе.

Какую проблему решает RAG

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

Есть три способа дать модели ваши данные:

1. Положить документы прямо в запрос (длинный контекст).
2. Найти нужные фрагменты и положить только их (RAG).
3. Дообучить модель на своих данных.

Третий способ дороже в подготовке и заслуживает отдельного разговора. Здесь сравниваем первые два.

RAG как работает: шаги

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

Подготовка.

1. Загрузка. Берёте документы (PDF, страницы wiki, выгрузку тикетов) и превращаете в текст.
2. Нарезка на фрагменты. Текст делится на куски по несколько сотен слов, иногда с небольшим перекрытием, чтобы мысль не обрывалась на границе.
3. Индекс. Для каждого фрагмента считается «отпечаток» для поиска. Чаще всего это эмбеддинг, то есть вектор чисел, по которому находятся близкие по смыслу тексты. Он хранится в векторной базе или даже в обычном файле.

На каждый вопрос.

1. Поиск. Вопрос превращается в такой же отпечаток, и из индекса берутся несколько самых близких фрагментов.
2. Сборка запроса. В промпт кладутся инструкция («отвечай только по тексту ниже»), найденные фрагменты и вопрос.
3. Генерация. Модель отвечает. Хорошая практика — просить её указать, из какого фрагмента взят ответ, и сказать «нет данных», если ответа в тексте нет.

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

RAG система: минимальный пример на Python

Ниже учебный пример без внешней векторной базы. Для поиска используется TF-IDF из scikit-learn: он считает похожесть по общим словам. Для русского языка без лемматизации это грубо (слова в разных формах считаются разными), так что в реальной системе поиск обычно заменяют на эмбеддинги. Но принцип виден целиком.

pip install scikit-learn openai

import os
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity
from openai import OpenAI

client = OpenAI(base_url="https://api.zukko.pro/v1",
                api_key=os.environ["ZUKKO_API_KEY"])

def split_text(text, size=120, overlap=20):
    words = text.split()
    step = size - overlap
    return [" ".join(words[i:i + size]) for i in range(0, len(words), step)]

doc = open("handbook.txt", encoding="utf-8").read()

Параметры запроса описаны в справочнике по chat completions↗. Более полный разбор с эмбеддингами — в статье RAG своими руками↗.

Где RAG ошибается

Это важно знать до внедрения:

• Плохой поиск. Если нужный фрагмент не попал в топ, модель ответит по другому или скажет «нет данных». Качество RAG зависит от поиска не меньше, чем от модели: проверяйте поиск отдельно, на наборе вопросов с известными ответами.
• Неудачная нарезка. Если ответ растянут на два фрагмента, а в запрос попал один, ответ будет неполным.
• Противоречия. Две версии одного регламента в индексе дадут два разных ответа. Удаляйте устаревшее.
• Права доступа. Если в индексе документы разных отделов, поиск должен учитывать, кто спрашивает.

RAG или длинный контекст: сколько стоит каждый подход

У современных моделей окно в 1M токенов (у GLM 5.3 — 128K, у Grok — 256K). Если ваша база помещается в окно, проще не делать RAG, а положить всё в запрос. Сравним по стоимости на примере.

Допущения: база знаний 250 тысяч токенов (это порядка 500 страниц), 1000 вопросов в месяц. Выход считаем одинаковым в обоих подходах и в сравнение не включаем. Для RAG вход одного запроса — 3000 токенов (4–5 фрагментов, инструкция и вопрос). Цены на 18 октября 2026, $ за 1M токенов (вход), формула: число токенов входа × цена.

При длинном контексте помогает кэш. Если префикс с документами одинаков во всех запросах, повторные запросы читают его из кэша по более низкой цене. Идеальный случай, когда кэш срабатывает на 999 запросах из 1000:

• gpt-6.1-sol (кэш виден в обоих форматах): 0.27 × 0.25 + 0.013 × 999 × 0.25 = 0.0675 + 3.247 = около $3.31.
• claude-sonnet-5-5 в Anthropic-формате (запись 0.5, чтение 0.05): 0.5 × 0.25 + 0.05 × 999 × 0.25 = 0.125 + 12.49 = около $12.61.

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

Когда RAG действительно нужен

• База больше окна модели или быстро растёт.
• Вопросов много, и платить за весь документ в каждом запросе накладно.
• Документы обновляются, и нужны ссылки на источник.
• Нужно разграничение доступа к частям базы.

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

• Документов немного, и они помещаются в окно с запасом.
• Вопросов мало.
• Нужны ответы по документу целиком: сводка, сравнение двух версий, поиск противоречий. Поиск по фрагментам такие вопросы теряет.

Общий принцип: сначала проверьте длинный контекст на 10 реальных вопросах. Если качество и цена устраивают, RAG откладывайте. Для готовых решений поиска по базе знаний есть статья поиск по базе знаний дёшево↗.

Частые вопросы

RAG и поиск в интернете — это одно и то же?

Нет. В RAG поиск идёт по вашим документам, заранее подготовленным. Поиск в интернете — другая функция, где источник внешний.

RAG убирает галлюцинации?

Снижает, но не убирает. Модель может неверно истолковать фрагмент или ответить вопреки инструкции. Требуйте цитату-источник в ответе и проверяйте её.

Нужна ли векторная база?

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

С какой модели начать?

С дешёвой, например deepseek-v4.1-flash: она получает готовый контекст, а задача сводится к ответу по найденному тексту. Если ответы слабые, сначала проверьте поиск, а потом меняйте модель. Ключ создаётся в кабинете↗.