RAG

RAG (от англ. retrieval-augmented generation, генерация с дополненной выборкой) это способ заставить языковую модель отвечать по документам конкретной компании: перед ответом система ищет в базе знаний подходящие фрагменты и передаёт их модели вместе с вопросом. Модель при этом ничему не учится. Она получает нужный кусок текста ровно в тот момент, когда его спросили.

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

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

Модель эмбеддингов на схеме одна, а моделей за ней две, и перепутать их легко

Чем отличается от дообучения, длинного контекста и поиска по сайту

Четыре способа дать модели доступ к корпоративным данным путают постоянно. Стоят они разного и ломаются по-разному.

Способ	Где живёт знание	Как обновляется	Чем плох
RAG	во внешнем поисковом индексе	правкой документа, минуты	ответ зависит от качества поиска
Дообучение модели	в весах модели	новым циклом обучения, дни и деньги	знание нельзя удалить точечно, источник ответа не виден
Длинный контекст	нигде, весь корпус кладут в сам вопрос	никак, кладёте свежую версию	цена растёт вместе с объёмом, есть потолок окна
Поиск по сайту	в поисковом индексе	переобходом	выдаёт список страниц, а не ответ

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

Откуда взялось

Название и сама схема появились в работе Патрика Льюиса и одиннадцати соавторов, опубликованной 22 мая 2020 года и принятой на конференцию NeurIPS 2020. Контекстные окна тогда были короткими, и подкладывание найденных документов выглядело способом обойти это ограничение. Массовым приёмом RAG стал после ноября 2022 года. Место среди прочих технологий искусственного интеллекта с тех пор не менялось: это способ доставки знания, а не способ думать.

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

Как это устроено

Контур загрузки: чанкинг и векторы

Документы нельзя положить в индекс целиком. Их режут на фрагменты, которые здесь принято называть чанками. От размера фрагмента дальше зависит почти всё: и попадание в выдачу поиска, и объём лишнего текста, за который платят на каждом вопросе. У Яндекса в сервисе AI Search максимальная длина одного чанка составляет 8000 символов, и там же есть режим, где вы режете документы сами и загружаете готовые фрагменты файлом JSONL.

Дальше каждый фрагмент отдельная модель эмбеддингов превращает в вектор, то есть в набор чисел, отражающий смысл текста. У GigaChat модель EmbeddingsGigaR выдаёт вектор из 2560 координат и принимает на вход до 4096 токенов, у Яндекса вторая версия векторизатора умеет отдавать 128, 256, 512 или 768 координат на выбор. Векторы складывают в индекс. С этого момента база знаний готова отвечать.

Размер чанка решает. Это не настройка для красоты. В бенчмарке LaRA измерили обе крайности: и слишком крупные, и слишком мелкие фрагменты роняют точность ответа, а рабочий диапазон лежит посередине. Там же нашлось различие между моделями. У Qwen-2.5 на 72 миллиарда параметров качество росло по мере добавления найденных фрагментов, а у версии на 7 миллиардов сначала росло, потом падало: лишние фрагменты приносили больше шума, чем пользы.

Контур ответа: поиск, переранжирование, генерация

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

Тонкость, которую в описаниях обычно пропускают: вопрос и документ это разные по природе тексты. Короткий вопрос и абзац регламента плохо сравниваются напрямую. Поэтому у Яндекса для векторизации заведены две отдельные модели, `text-search-doc` для документов и `text-search-query` для запросов. Перепутать их местами легко. Видно это будет только по проваленному поиску, то есть уже на живых вопросах пользователей.

Эмбеддинги для русского языка

Советы «выберите модель эмбеддингов» встречаются почти во всех разборах RAG, но чисел за ними обычно нет. Для русского языка числа есть. Модель эмбеддингов это обычная модель машинного обучения, и сравнивают их так же, общим бенчмарком. Бенчмарк ruMTEB, собранный командой SberDevices, содержит 23 набора данных в семи категориях задач, из них 17 наборов опубликованы авторами впервые. Результаты ниже сняты авторами бенчмарка по состоянию на 9 октября 2024 года.

Модель	Поиск	Переранжирование	Смысловая близость	Среднее по 23 задачам
rubert-tiny2	8,89	30,95	61,60	42,22
sbert_large_nlu_ru	8,51	32,81	57,21	45,35
sbert_large_mt_nlu_ru	19,13	40,56	64,40	48,72
multilingual-e5-small	65,85	65,28	69,48	57,29
multilingual-e5-base	67,14	66,24	70,16	58,34
multilingual-e5-large	74,04	69,65	71,62	61,41
BGE-M3	74,79	69,71	73,68	61,58
ru-en-RoSBERTa	66,52	63,89	73,97	61,77
multilingual-e5-large-instruct	74,41	69,17	74,85	66,03
E5-mistral-7b-instruct	74,19	69,96	73,71	67,18

Из таблицы вытекают два правила. Оба неочевидны.

• • Смотреть надо в колонку поиска, а не в среднюю.** Модель `rubert-tiny2` набирает пристойные 61,60 на смысловой близости и 8,89 на поиске. Разрыв в семь раз. На вопрос «похожи ли эти два текста» она отвечает сносно, в задаче «найди нужный абзац среди тысячи» бесполезна, и по средней колонке это не видно.

• • Лидер по среднему баллу и лидер по поиску это разные модели.** Среди моделей без инструкций среднее выигрывает `ru-en-RoSBERTa` с 61,77, но на поиске она отдаёт 66,52 против 74,79 у BGE-M3. Для RAG это значит, что выбор по сводному рейтингу уводит в сторону примерно на восемь пунктов поиска.

Две верхние строки занимают модели с инструкцией: им вместе с текстом подают пояснение задачи. Такой режим есть и у российских векторизаторов.

Что делать на практике

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

Чем измеряют

Качество RAG меряют в двух точках. Путать их нельзя. Поиск оценивают долей вопросов, где нужный фрагмент попал в выдачу (hit rate), средним обратным рангом правильного фрагмента (MRR) и метрикой nDCG, учитывающей порядок найденного. Ответ оценивают иначе. Опорность на источник (faithfulness) показывает, следует ли текст ответа из поданных фрагментов, а релевантность отвечает на вопрос, ответили ли на то, что спрашивали. Три метрики такого рода описаны в работе про фреймворк Ragas.

Порядок починки один: сначала поиск, потом всё остальное. Пока hit rate низкий, ни переписанный промпт, ни модель вдвое дороже не изменят ничего.

Из чего складывается цена

Счёт за корпоративный RAG растёт из трёх статей. Ниже тарифы Yandex AI Studio с НДС.

Разовая подготовка: перевод текста в векторы стоит 0,0101 ₽ за 1000 токенов, то есть корпус в десять миллионов токенов обойдётся в 101 ₽. Экономить тут не на чем.

Постоянное хранение: поисковый индекс тарифицируется как 10,6 ₽ за гигабайт в сутки, то есть 318 ₽ за месяц и около 3869 ₽ за год с каждого гигабайта.

Ответы: входящие токены YandexGPT Pro 5 стоят 1,2 ₽ за тысячу. Отсюда вся экономика приёма. Вопрос с пятью найденными фрагментами на две тысячи токенов стоит 2,4 ₽ по входу. Тот же вопрос со ста тысячами токенов документов в теле запроса стоит 120 ₽. Разница в пятьдесят раз, и умножается она на число вопросов в день.

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

Частые ошибки

• • Только векторный поиск.** Смысловая близость не найдёт «договор № 114-АЗ от 3 марта», поэтому там, где в документах есть коды и номера, гибрид обязателен.

• • Слишком крупные чанки.** Фрагмент на две страницы попадает в выдачу почти всегда и тащит лишнее, которое модель примет за контекст.

• • База знаний без владельца.** Документы устаревают. Через полгода ассистент уверенно цитирует отменённый регламент, поэтому корпусу нужен процесс сопровождения, а не разовая загрузка.

• • Нет набора контрольных вопросов.** Тогда любая правка системы это ремонт вслепую, а отчёт о качестве держится на паре удачных демонстраций.

• • Вера в то, что RAG убирает выдумывание.** Он сокращает выдумывание, а не отменяет: модель по-прежнему может сшить два фрагмента в утверждение, которого нет ни в одном из них. Механика этого разобрана в статье Большая языковая модель.

Ограничения и спорные места

• • Спор о длинном контексте не решён, и одной цифры в ответе нет.** Контекстные окна выросли, и естественный вопрос звучит так: зачем поиск, если весь корпус помещается в запрос. Исследователи Google DeepMind и Мичиганского университета в 2024 году померили оба подхода на наборах LongBench и InfiniteBench тремя моделями и получили, что длинный контекст выигрывает по среднему качеству, а RAG выигрывает по цене. Их же наблюдение: на 63% вопросов оба подхода дают одинаковый ответ, поэтому маршрутизация вопросов между двумя путями сократила стоимость на 65% у Gemini 1.5 Pro и на 39% у GPT-4o почти без потери качества.

Через полгода бенчмарк LaRA от исследователей Alibaba, 2326 тестовых случаев на четырёх типах задач и трёх типах длинных текстов, одиннадцать моделей, дал более осторожный вывод. Результат зависит от размера модели, её способности работать с длинным текстом, длины контекста, типа задачи и характера найденных фрагментов. Два измеренных перелома: на контексте в 32 тысячи токенов длинный контекст обгонял RAG в среднем на 2,4%, а на 128 тысячах тенденция переворачивалась и RAG выигрывал 3,68%. Чем слабее модель, тем больше даёт RAG: у Mistral-Nemo-12B разрыв в его пользу достигал 38,12%.

Практический ориентир отсюда такой. Маленький корпус поиска не требует: пара десятков страниц помещается в окно сильной модели целиком, и индекс вокруг них ничего не решает. Корпус, заметно превышающий окно, требует RAG независимо от споров. Порог проходит между, и одним числом его не назвать: у GigaChat 2 Max окно составляет 128 000 токенов, ровно ту длину, на которой измеренное преимущество длинного контекста уже исчезает.

• • Положение фрагмента в контексте влияет на ответ.** Работа «Lost in the Middle» показала, что модели хуже используют информацию из середины длинного контекста, чем из начала и конца. Авторы LaRA эффект воспроизвели и отдельно отметили: у RAG связи между позицией ответа и точностью они не нашли.

• • Документ в базе знаний это канал атаки.** Каталог OWASP для приложений с языковыми моделями в редакции 2025 года описывает сценарий прямо: злоумышленник правит документ в хранилище, и вложенная в текст инструкция меняет поведение модели при ответе. Права на запись в базу знаний по цене ошибки равны правам администратора.

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

• • Цифры бенчмарков это не ваши цифры.** Числа ruMTEB получены на новостях, научных аннотациях, отзывах и вопросах к Википедии. Ваш корпус может состоять из таблиц, сканов и внутреннего жаргона, где порядок моделей окажется другим. Бенчмарк сужает список кандидатов до трёх, выбор делает замер на своих данных.

• • Что не измерено вовсе.** Публичных замеров того, как качество RAG влияет на деньги заказчика, в открытых источниках нет. Точность поиска померена многократно, экономический эффект внедрения берётся из обещаний поставщиков.

Что здесь быстро устаревает

- **Таблица ruMTEB.** Приведённые значения сняты авторами на 9 октября 2024 года, и модели с тех пор выходят каждый квартал. Признак протухания: в публичном рейтинге MTEB появились русские модели, которых в таблице нет. - **Тарифы.** Цены Yandex AI Studio и GigaChat пересматриваются, линейки моделей переименовываются. Пропорция между статьями расходов живёт дольше абсолютных чисел. - **Границы контекстных окон.** Окно в 128 000 токенов через год может оказаться базовым уровнем, и тогда порог из спора выше сдвинется. - **Названия интерфейсов.** Яндекс уже перевёл сборку ассистентов с AI Assistant API на Responses API и держит для перехода отдельную инструкцию. Такие переименования ломают чужие руководства по внедрению быстрее, чем устаревает механика. - **Роль приёма в поиске.** Поисковые системы собирают ответы тем же способом, а правила попадания в эти ответы меняются отдельно: их разбирает статья GEO и AEO: продвижение в ответах нейросетей. - **Формулировка «RAG против длинного контекста».** Спор может закрыться в любую сторону или раствориться в гибридных схемах с маршрутизацией вопросов.

См. также

• ИИ-ассистент
• Большая языковая модель
• Нейросети для бизнеса
• ИИ в маркетинге

Источники

1. Lewis P., Perez E., Piktus A. и др. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: работа, давшая название приёму. arXiv:2005.11401, 22 мая 2020 года; принята на NeurIPS 2020. https://arxiv.org/abs/2005.11401
2. Snegirev A., Tikhonova M., Maksimova A., Fenogenova A., Abramov A. The Russian-focused embedders' exploration: ruMTEB benchmark and Russian embedding model design: состав бенчмарка (23 набора данных в семи категориях, 17 из них новые) и таблица результатов десяти моделей по категориям задач, снятая на 9 октября 2024 года. arXiv:2408.12503, 22 августа 2024 года; NAACL 2025. https://arxiv.org/abs/2408.12503
3. Li Z., Li C., Zhang M., Mei Q., Bendersky M. Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach: длинный контекст выигрывает по качеству, RAG по цене; совпадение ответов на 63% вопросов; экономия токенов 65% у Gemini 1.5 Pro и 39% у GPT-4o. Google DeepMind и Мичиганский университет, arXiv:2407.16833, версия от 17 октября 2024 года. https://arxiv.org/abs/2407.16833
4. Li K., Zhang L., Jiang Y. и др. LaRA: Benchmarking Retrieval-Augmented Generation and Long-Context LLMs, No Silver Bullet for LC or RAG Routing: 2326 тестовых случаев, четыре типа задач, три типа длинных текстов, одиннадцать моделей; перелом между 32 и 128 тысячами токенов, влияние размера и числа фрагментов. arXiv:2502.09977, версия от 5 марта 2025 года. https://arxiv.org/abs/2502.09977
5. Liu N. F., Lin K., Hewitt J. и др. Lost in the Middle: How Language Models Use Long Contexts: качество падает, когда нужная информация стоит в середине контекста. Transactions of the ACL, 2024, т. 12, с. 157-173. https://aclanthology.org/2024.tacl-1.9/
6. Es S., James J., Espinosa-Anke L., Schockaert S. Ragas: Automated Evaluation of Retrieval Augmented Generation: метрики опорности на источник, релевантности ответа и релевантности контекста. arXiv:2309.15217, 26 сентября 2023 года. https://arxiv.org/abs/2309.15217
7. LLM01:2025 Prompt Injection: сценарий подмены документа в хранилище RAG, косвенная инъекция через внешние источники. OWASP Top 10 for LLM Applications, редакция 2025 года. https://genai.owasp.org/llmrisk/llm01-prompt-injection/
8. «Обзор технологий поиска AI Search»: разбиение данных на чанки, максимальная длина чанка 8000 символов, режим загрузки готовых фрагментов в JSONL. Документация Yandex AI Studio, Яндекс. https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/search/
9. «Модели векторизации текста»: модели `text-search-doc` и `text-search-query`, вторая версия с размерностью вектора 128, 256, 512 или 768. Документация Yandex AI Studio, Яндекс. https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/embeddings
10. «Правила тарификации Yandex AI Studio»: 0,0101 ₽ за 1000 токенов векторизации, 10,6 ₽ за гигабайт поискового индекса в сутки, 1,2 ₽ за 1000 входящих токенов YandexGPT Pro 5, 0,2 ₽ у YandexGPT Lite. Цены с НДС. Документация Yandex AI Studio, Яндекс. https://aistudio.yandex.ru/docs/ru/ai-studio/pricing
11. «Переход с AI Assistant API на Responses API»: инструкция по переносу сборки ассистента на новый интерфейс. Документация Yandex AI Studio, Яндекс. https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/agents/assistant-responses-migration
12. «EmbeddingsGigaR»: размер вектора 2560 координат, размер контекстного окна 4096 токенов. Документация GigaChat, Сбер. https://developers.sber.ru/docs/ru/gigachat/models/embeddings-giga-r
13. «GigaChat 2 Max»: размер контекстного окна 128 000 токенов. Документация GigaChat, Сбер. https://developers.sber.ru/docs/ru/gigachat/models/gigachat-2-max
14. «Векторное представление текста»: модели Embeddings, Embeddings-2 и EmbeddingsGigaR, метод POST /embeddings. Документация GigaChat, Сбер. https://developers.sber.ru/docs/ru/gigachat/guides/embeddings