Содержание
- Что такое RAG в ИИ простыми словами
- Чем RAG отличается от обычного генеративного ИИ
- Архитектура RAG: что происходит до вопроса и что после
- Что в RAG называют базой: база знаний, векторная база, обычная СУБД
- Зачем в RAG нужна векторная база данных
- Эмбеддинг в RAG: почему запрос и документ кодируют разными моделями
- RAG-агент, RAG-ассистент и RAG-бот: чем они отличаются
- RAG-анализ: чем меряют качество и что показал наш замер
- Где схема RAG ломается и что с этим делать
- Чек-лист перед сборкой RAG
RAG в ИИ: что это и где схема ломается
Черновик готовит редакция с помощью ИИ. За стандарт издания отвечает главный редактор — Валерий Курземнек.
Материал редакции Зерокодера. Обновлено 14 сентября 2026 года.
RAG (retrieval-augmented generation, по-русски «генерация с дополненной выборкой») — это схема, в которой языковая модель перед ответом достаёт подходящие куски текста из вашей базы и отвечает по ним. Что это меняет: ответ опирается на ваши документы и на них же ссылается, а обновление знаний сводится к замене файла в базе. Термин ввела статья Patrick Lewis и одиннадцати соавторов «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», поданная на arXiv 22 мая 2020 года.
Мы сняли выдачу Яндекса по десяти запросам кластера, прочитали 47 страниц топа из 55 снятых, собрали из них базу знаний на 1738 фрагментов и задали ей 20 вопросов. Коротко, что показал прогон:
- словарный поиск BM25 нашёл нужный фрагмент в первой пятёрке 8 раз из 20, векторный поиск на русских эмбеддингах — 6 раз из 20;
- поиски ошибаются в разных местах: только BM25 нашёл ответ на 6 вопросов, только вектор — на 4, оба вместе покрыли бы 12 из 20;
- семь вопросов из двадцати не закрыл ни один из четырёх ретриверов;
- у Yandex Cloud эмбеддинги разделены на две модели, и косинус между векторами одного и того же текста равен 0,7217 при нулевом числе совпавших координат из 256;
- собственного замера качества поиска не приводит ни одна из 47 прочитанных страниц топа.
Что такое RAG в ИИ простыми словами
RAG в ИИ — это связка из четырёх частей: хранилище с вашими текстами, поисковик по нему (ретривер), языковая модель (генератор) и код, который склеивает найденное с вопросом в один промпт. Аббревиатура расшифровывается как retrieval-augmented generation: retrieval — поиск, augmented — дополнение вопроса найденным, generation — генерация ответа с учётом этого дополнения. В русской выдаче ту же родословную приводит cloud.ru: «В 2020 году команда исследователей во главе с Патриком Льюисом (Patrick Lewis) представила архитектуру RAG».
Важная оговорка, которую в выдаче формулирует serverspace.kz: «RAG — это не отдельная модель в привычном смысле». Скачать RAG нельзя, обучить RAG нельзя. Это архитектурный приём поверх обычной большой языковой модели: та же GPT, тот же GigaChat, тот же YandexGPT, только с подложенными в контекст фрагментами документов.
Отсюда и главная выгода. Дообучение модели под базу знаний стоит денег и устаревает в день, когда регламент поменяли. В RAG регламент лежит файлом: заменили файл — на следующем же вопросе ответ другой.
Чем RAG отличается от обычного генеративного ИИ
Обычный генеративный ИИ отвечает из параметров: всё, что модель знает, зашито в веса на момент обучения. Отсюда две беды — устаревание и выдумывание. RAG и генеративный ИИ соединяются так: модель остаётся прежней, но к вопросу пользователя перед отправкой подклеивается текст, найденный в базе, и модель получает инструкцию отвечать по нему.
Цена этой подклейки видна в цифрах Википедии: по сводке в статье «Генерация с дополненной выборкой» RAG улучшает ответы даже при шуме в подборке, и «ChatGPT сохраняет 96,33 % точности при умеренном шуме», однако выше 80 % шума точность падает до 76 %. Читается это просто: RAG вытягивает ответ настолько, насколько чистую подборку ему дал поиск. Мусор на входе остаётся мусором на выходе.
Архитектура RAG: что происходит до вопроса и что после
RAG-архитектура распадается на два независимых конвейера, и путают их чаще всего.
Индексация (заранее, без пользователя). Документы загружают, чистят от разметки, режут на фрагменты-чанки, каждый чанк прогоняют через модель эмбеддингов и кладут вектор вместе с метаданными в хранилище. Практический ориентир даёт интегратор itfresh.ru: «Целевой размер фрагмента — около 800 токенов с перекрытием (chunk overlap) около 100 токенов между соседними чанками».
Ответ (в момент вопроса). Вопрос кодируют в вектор, ищут ближайшие чанки, при желании переупорядочивают их отдельной моделью-реранкером, складывают в промпт и отдают генератору. Бюджет времени у того же itfresh.ru: «Гибридный retrieval укладывается в 150–300 мс, reranking 100 кандидатов — ещё 200–400 мс».
| Узел RAG-архитектуры | Что делает | Чем ломается |
|---|---|---|
| Загрузчик и чанкер | режет документы на фрагменты | режет посреди пункта регламента |
| Модель эмбеддингов | превращает текст в вектор | разные модели дают несовместимые пространства |
| Хранилище векторов | ищет ближайших соседей | не умеет точных совпадений по номеру и коду |
| Реранкер | переупорядочивает найденное | добавляет сотни миллисекунд |
| Генератор (LLM) | пишет ответ по фрагментам | отвечает красиво по нерелевантной подборке |
Мини-вывод: качество RAG определяется первым конвейером, а видят пользователи второй.
Что в RAG называют базой: база знаний, векторная база, обычная СУБД
Слово «база» в запросах про RAG означает три разные вещи, и это источник путаницы.
База знаний — содержимое: регламенты, инструкции, статьи, переписка поддержки. Это то, что вы собираете руками и поддерживаете в актуальности.
Векторная база данных — техническое хранилище, которое умеет искать ближайшие векторы: Qdrant, Milvus, Chroma, расширение pgvector поверх обычного PostgreSQL.
Обычная СУБД — там живут точные данные: остатки, цены, статусы заказов. Она отвечает на вопрос про остаток на складе, тогда как порядок оформления возврата живёт в тексте регламента.
RAG-база знаний обычно живёт сразу в трёх местах: тексты в файлах, их векторы в векторном хранилище, метаданные и права доступа в реляционной таблице рядом.
Зачем в RAG нужна векторная база данных
Векторная база нужна затем, чтобы искать по смыслу, когда слова вопроса и слова документа не совпадают. Сотрудник спрашивает, сколько у него осталось отпускных дней; в регламенте написано про ежегодный оплачиваемый отпуск — словарный поиск промахивается, векторный находит. Как получается сам вектор, разобрано в отдельном материале про эмбеддинги.
Обратная сторона в выдаче почти не проговаривается, хотя цифры есть. VK Cloud приводит замер, где «BM25 обошёл плотный поиск на эмбеддингах OpenAI text-embedding-3-large по всем метрикам, кроме Recall@20»: в финансовых и юридических документах много номеров, кодов и точных терминов, по которым словарный матч работает лучше. Оттуда же практический порог: «корпус меньше 10 млн векторов, отдельная векторная база данных чаще всего избыточна» — хватает pgvector на уже работающем PostgreSQL.
Мы решили проверить обещание «поиска по смыслу» руками. Скрипт rag_run.py собрал базу знаний из 47 прочитанных страниц топа — 1738 чанков по 700 знаков с перекрытием 120 — и прогнал по ней 20 вопросов в четырёх конфигурациях. Эталон у каждого вопроса задан якорем: буквальной строкой, которая обязана встречаться в корпусе, а её вхождения прибор проверяет машинно и выводит с контекстом в gt_contexts.txt.
| Конфигурация поиска | Попал в топ-1 | Попал в топ-5 |
|---|---|---|
| BM25, словарный поиск | 5 из 20 | 8 из 20 |
| Вектор: text-search-doc + text-search-query | 4 из 20 | 6 из 20 |
| Вектор: обе стороны через text-search-doc | 5 из 20 | 5 из 20 |
| Гибрид RRF (BM25 + вектор) | 4 из 20 | 8 из 20 |
Числа маленькие, и разница в два попадания на двадцати вопросах статистически незначима — переносить её на ваш корпус нельзя. Значима другая картинка: только BM25 нашёл ответ на 6 вопросов, только вектор — на 4, и оба вместе закрыли бы 12 из 20. Гибрид на простом сложении рангов дал 8 — то есть механическое суммирование этот потенциал не забрало, и разрыв между 8 и 12 остаётся той работой, которую в проде отдают реранкеру. У kt-team.ru тот же эффект описан числом со ссылкой на Databricks: после реранкинга «recall@10 растёт с 74% до 89%».
Эмбеддинг в RAG: почему запрос и документ кодируют разными моделями
Эмбеддинг — это массив чисел, которым модель записывает смысл текста. VK Cloud перечисляет типовые длины: «1536 у OpenAI text-embedding-3-small, 3072 у text-embedding-3-large, 1024 у BGE-M3, 4096 у Qwen3-Embedding-8B».
Дальше начинается место, которое не описывает ни одна из 47 прочитанных страниц топа. Классическое объяснение на Хабре звучит так: «при поиске запрос пользователя тоже превращается в вектор» — одной моделью, той же, что кодировала документы. У российского облака это устроено иначе. Прогон emb_probe.py 14.09.2026 показал: адрес emb://<folder>/text-search-doc/latest и адрес emb://<folder>/text-search-query/latest — две разные модели. Обе отдали вектор длиной 256 и поле modelVersion со значением 06.12.2023, а выдуманная третья модель вернула HTTP 400 с текстом «unknown model ’emb://text-search-fake/latest’».
Главное число прогона: один и тот же текст «Зачем в RAG нужна векторная база данных» эти две модели кодируют по-разному — косинус между полученными векторами 0,7217, совпавших координат ноль из 256. Имена моделей говорят о назначении прямо: doc кодирует абзацы базы, query — короткие вопросы пользователя.
Проверка последствий ошибки вошла в тот же прогон: конфигурация, где вопрос закодирован документной моделью, дала 5 попаданий в пятёрку против 6 у правильной пары. На двадцати вопросах это разница в один вопрос, и честный вывод — на такой выборке эффект неразличим. Про смешение разных семейств VK Cloud предупреждает отдельно: «индексировать корпус одной моделью, а запросы кодировать другой нельзя».
RAG-агент, RAG-ассистент и RAG-бот: чем они отличаются
Три слова из запросов означают почти одно и то же, разница в объёме полномочий.
RAG-бот и RAG-чат-бот — интерфейс: окно в мессенджере или на сайте, за которым стоит одна и та же связка: поиск по базе плюс генерация. Слово «бот» описывает канал общения.
RAG-ассистент — тот же бот, встроенный в рабочее место сотрудника: он отвечает по внутренним регламентам и обязан ссылаться на документ и его редакцию.
RAG-агент — надстройка, которая сама решает, сколько раз и куда ходить: переформулировать вопрос, сходить в поиск повторно, дёрнуть внешний инструмент, сверить ответ. Подробнее про такую автономию — в материале про ИИ-агентов, а сборка маршрутов обсуждается в разборах LangGraph и Dify.
Мини-вывод: RAG-агенты нужны там, где одного прохода по базе не хватает, а цена ошибки выше цены лишней секунды.
RAG-анализ: чем меряют качество и что показал наш замер
Качество RAG меряют по слоям. Поиск: hit@k — доля вопросов, где нужный фрагмент попал в первые k результатов; recall@k — какая часть нужных фрагментов вообще найдена; MRR — насколько высоко стоит первый правильный. Генерация: соответствие ответа найденному и релевантность вопросу.
Порог осмысленности «КОРУС Консалтинг» формулирует жёстко: если поиск «не дает точных ответов в 50% случаев, то использование технологии будет бессмысленным».
Отдельно мы проверили сам прибор — иначе числа выше ничего не стоили бы. Скрипт sanity2.py берёт 20 случайных чанков корпуса, вырезает из каждого дословный кусок в 230 знаков и подаёт его как запрос. Задача вырожденная: найти фрагмент по его же тексту. BM25 справился 20 раз из 20, векторный поиск — 15 раз из 20 (попадание засчитывалось и соседнему чанку той же страницы, потому что фрагменты перекрываются).
Семь вопросов из двадцати не закрыл ни один из четырёх ретриверов. Показательный пример — вопрос «какой длины бывает один вектор у разных векторизаторов»: векторный поиск поднял наверх абзац о том, что такое векторы вообще, тогда как ответ с числами 1536, 3072, 1024 и 4096 лежал в другом чанке. Похожесть тем и наличие ответа — разные вещи, и векторный поиск оптимизирует первое.
Где схема RAG ломается и что с этим делать
Пересказ схемы стоит дёшево. Дорого стоит знание, где она рвётся.
Чанкинг. Фрагмент, разрезанный посреди пункта, теряет ответ в обеих половинах. Держите границы по структуре документа и перекрытие в сотню токенов.
Разрыв «похоже» против «отвечает». Векторный поиск ранжирует по близости темы. Спасают гибрид со словарным поиском и реранкер поверх расширенной выдачи.
Шум. Чем больше нерелевантных кусков в промпте, тем хуже ответ — это и есть падение с 96,33 % до 76 % в замерах из Википедии.
Отсутствие замера. Собственного замера качества поиска не приводит ни одна из 47 прочитанных нами страниц топа. Двадцать вопросов с проверяемым эталоном снимают месяцы споров о том, виновата ли модель.
Чек-лист перед сборкой RAG
| Шаг | Что сделать | Чем проверить |
|---|---|---|
| 1 | Собрать 20 реальных вопросов сотрудников и эталонные фрагменты к ним | вопрос без эталона в чек-лист не идёт |
| 2 | Нарезать документы по структуре, 500–800 токенов, перекрытие ~100 | открыть 10 случайных чанков глазами |
| 3 | Выбрать модель эмбеддингов до заливки корпуса | смена модели требует полной переиндексации |
| 4 | Проверить пару моделей эмбеддингов: документную и запросную | один текст через обе модели, сравнить косинус |
| 5 | Замерить hit@5 словарного, векторного и гибридного поиска | три числа на одной таблице вопросов |
| 6 | Добавить реранкер, если объединение поисков даёт заметно больше | повторный замер hit@5 |
| 7 | Зафиксировать порог, ниже которого система не запускается | сравнение с порогом в половину точных ответов |
Охват и границы этого материала: выдача снята 14.09.2026 по десяти запросам кластера через Яндекс Search API, регион 225. Из 55 уникальных адресов прочитаны 47; восемь не отдались — yandex.cloud, youtube.com, dzen.ru, reg.cloud и gitverse.ru вернули заглушку вместо текста, datacamp.com ответил HTTP 403, companies.rbc.ru — HTTP 401, infostart.ru не открыл соединение. Утверждения об отсутствии чего-либо в топе ограничены этими 47 прочитанными страницами. Прогоны выполнены с европейского адреса выхода (130.17.14.168, Falkenberg, SE), поэтому о доступности сервисов из России они не говорят ничего.