Что такое RAG (retrieval-augmented generation)

Представьте студента, сдающего экзамен с открытой книгой. Вместо того чтобы отвечать на каждый вопрос исключительно по памяти, студент листает учебник, находит наиболее релевантные страницы, читает их и затем пишет ответ, сочетающий запомненные знания со свежеподсмотренными фактами. Retrieval-Augmented Generation (RAG) работает точно так же для большой языковой модели. Модель полагается не только на то, что запомнила во время обучения — она сначала ищет во внешней базе знаний, извлекает наиболее релевантные документы и использует их как дополнительный контекст при генерации ответа.

Эта техника важна, потому что даже самые мощные LLM имеют дату отсечения знаний, могут «галлюцинировать» (выдавать правдоподобные, но неверные утверждения) и могут не обладать специализированными знаниями в конкретной области. RAG решает все три проблемы одновременно, давая модели доступ к актуальным, доменно-специфичным, верифицируемым источникам при каждом ответе на вопрос.

Коротко: RAG — это архитектурный паттерн, объединяющий систему поиска с LLM. Это не отдельный тип модели — это способ работы с внешними знаниями и контекстом.

Как это работает

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

Шаг 1 — Запрос пользователя

Процесс начинается, когда пользователь отправляет вопрос, команду или промпт. Этот запрос — отправная точка для всего последующего. Например, пользователь может спросить: «Какие крупные предложения по управлению Ethereum появились за последний месяц?» Система не пытается ответить исключительно из памяти LLM — вместо этого она обрабатывает запрос как инструкцию для поиска.

Шаг 2 — Эмбеддинг запроса

Текстовый запрос преобразуется в числовое представление, называемое эмбеддингом — вектор чисел, который фиксирует семантический смысл запроса. Для этого используется специализированная модель эмбеддингов (например, text-embedding-ada-002 от OpenAI или open-source альтернативы вроде E5 или BGE). Полученный вектор позволяет системе выполнять семантический поиск — находить документы по смыслу, а не по точному совпадению ключевых слов.

Шаг 3 — Поиск в базе знаний

Эмбеддинг запроса сравнивается с векторной базой данных (также называемой векторным хранилищем), которая содержит предвычисленные эмбеддинги документов, отрывков или фрагментов данных. База данных возвращает top-k наиболее семантически похожих элементов. Популярные векторные базы данных включают Pinecone, Weaviate, Qdrant, Milvus и Chroma.

Качество поиска зависит от нескольких факторов:

Стратегия чанкинга — как исходные документы были разбиты на более мелкие фрагменты. Слишком большие чанки размывают релевантность; слишком маленькие теряют контекст. Подбор правильного размера чанков — одно из наиболее значимых инженерных решений в конвейере RAG.
Модель эмбеддингов — насколько точно смысл фиксируется в векторах. Слабая модель эмбеддингов ведёт к слабому поиску независимо от базы данных.
Ранжирование по релевантности — возвращает ли поиск действительно релевантные результаты или лишь поверхностно похожие. Некоторые системы добавляют этап переранжирования, используя кросс-энкодер для пересчёта оценок начальных результатов.

Шаг 4 — Инъекция контекста

Найденные документы объединяются с исходным запросом пользователя в единый промпт (иногда называемый «дополненным промптом»), который отправляется в LLM. Промпт обычно инструктирует модель отвечать на вопрос, используя предоставленный контекст, и указывать, когда контекст не содержит достаточно информации.

Шаг 5 — Генерация ответа LLM

LLM читает дополненный промпт и генерирует ответ, опирающийся как на предобученные знания, так и на найденные доказательства. Хорошо спроектированная RAG-система может также включать слой цитирования, который связывает части ответа с конкретными исходными документами, давая пользователю возможность проверить утверждения.

Этап	Вход	Выход	Ключевой компонент
Запрос	Текст пользователя	Сырой запрос	Пользовательский интерфейс
Эмбеддинг	Сырой запрос	Вектор запроса	Модель эмбеддингов
Поиск	Вектор запроса	Релевантные документы	Векторная база данных
Инъекция контекста	Запрос + документы	Дополненный промпт	Шаблон промпта
Генерация	Дополненный промпт	Финальный ответ	LLM

Почему RAG важен

RAG решает три хорошо известных ограничения автономных LLM:

Галлюцинации. LLM могут выдавать уверенные, но неверные ответы. RAG снижает это, опирая ответы на реальные документы. Когда модель может сослаться на конкретный отрывок, риск выдумки значительно уменьшается.
Устаревшие знания. Предобученная модель имеет дату отсечения знаний. RAG даёт доступ к свежим, непрерывно обновляемым данным — внешняя база может обновляться ежедневно или даже в реальном времени.
Доменная специфичность. Файн-тюнинг LLM для узкой области стоит дорого и занимает много времени. RAG позволяет модели общего назначения работать со специализированными базами знаний без переобучения, что ускоряет и удешевляет развёртывание доменно-специфичных приложений.

RAG и файн-тюнинг

И RAG, и файн-тюнинг направлены на улучшение работы LLM на конкретных задачах, но работают принципиально по-разному.

Аспект	RAG	Файн-тюнинг
Когда добавляются знания	Во время инференса (при каждом запросе)	Во время обучения (однократно, затем статично)
Стоимость обновления	Низкая — обновить базу знаний	Высокая — переобучить или повторно дообучить модель
Свежесть знаний	Может быть почти в реальном времени	Заморожена на дату отсечения обучения
Требуется инфраструктура обучения	Нет	Да (GPU, датасеты, конвейер обучения)
Лучше всего подходит для	Фактический поиск, Q&A по документации	Стиль, тон, формат, оптимизация для узких задач
Аудитируемость	Высокая — найденные источники можно логировать	Низкая — знания встроены в веса

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

Продвинутые паттерны RAG

Базовый пятиэтапный конвейер, описанный выше, иногда называют наивным RAG. По мере развития техники инженеры разработали более сложные варианты:

Многошаговый (итеративный) RAG. Вместо однократного поиска система ищет, генерирует промежуточный ответ, выявляет пробелы в знаниях, делает повторный поиск с уточнённым запросом и повторяет, пока ответ не станет достаточно полным. Этот подход справляется со сложными вопросами, на которые нельзя ответить за один проход поиска.
Агентный RAG. Этап поиска обёрнут во фреймворк ИИ-агента. Агент решает, когда искать, в какой базе знаний, нужно ли переформулировать запрос и достаточно ли контекста для генерации финального ответа. Этот паттерн размывает границу между RAG и автономными агентами.
Гибридный поиск. Комбинация семантического поиска на основе векторов с традиционным поиском по ключевым словам (BM25) на одном этапе. Гибридный поиск улавливает и смысловые, и терминологические совпадения, улучшая полноту для запросов с конкретными техническими терминами или именами собственными.
Graph RAG. Вместо плоских фрагментов документов база знаний структурирована как граф знаний — сущности и связи. Поиск следует по рёбрам графа, а не (или в дополнение к) векторному сходству, что позволяет многошаговые рассуждения по структурированным данным.

Эти паттерны важны для оценки: проект, который описывает конвейер graph-RAG с итеративным поиском, делает более конкретное (и сложнее подделываемое) заявление, чем тот, который просто говорит «мы используем RAG».

Реальные примеры RAG

RAG — не теоретическая концепция: он лежит в основе некоторых из наиболее популярных ИИ-продуктов сегодня.

Bing Chat (Microsoft Copilot). Когда вы задаёте Bing Chat вопрос, он ищет в вебе, находит релевантные страницы и использует их как контекст для ответа LLM. Встроенные цитаты, которые вы видите в ответе, — прямой результат этапа поиска.
Perplexity. Perplexity построен вокруг архитектуры RAG: каждый запрос пользователя запускает поиск в вебе, результаты подаются в LLM, и ответ включает пронумерованные ссылки на источники. Пользователь может перейти по ним для проверки каждого утверждения.
Корпоративные ассистенты по базе знаний. Компании используют внутренние RAG-системы, чтобы сотрудники могли запрашивать HR-политики, инженерную документацию или юридические договоры на естественном языке. Слой поиска обращается к внутреннему хранилищу документов, а не к открытому вебу.

Эти примеры демонстрируют, что RAG — это мейнстрим-технология. Когда крипто-ИИ-проект заявляет «мы используем RAG», вопрос не в том, является ли RAG реальной технологией, а в том, насколько качественна конкретная реализация проекта: какие данные извлекаются, как они проиндексированы и измерялось ли качество поиска.

Почему RAG встречается в крипто-ИИ-проектах

Многие крипто-ИИ-проекты используют RAG или заявляют об этом в своих архитектурах. Типичные сценарии использования:

Ассистенты по документации — поиск по документации протоколов, whitepaper-ам или предложениям по управлению (governance) для ответов на вопросы пользователей о правилах или параметрах протокола.
Инструменты крипто-аналитики — извлечение рыночных данных в реальном времени, ончейн-событий или новостных статей для генерации аналитических сводок или оповещений.
Базы знаний для агентов — создание структурированных репозиториев, к которым ИИ-агенты могут обращаться перед действиями, обеспечивая принятие решений на основе актуальных данных.
Привязка к ончейн-данным — подключение слоя поиска к блокчейн-индексаторам, чтобы LLM мог отвечать на вопросы о балансах кошельков, истории транзакций или состоянии смарт-контрактов с актуальной информацией, а не со снимков времени обучения.

Типичные значения AI component в карточках проектов DecAIHub, включающие паттерны RAG: «3D AI agents (RAG/memory/LLM catalog)», «AI summaries + crypto intelligence terminal», «AgentData (real-time data streams for AI agents)».

RAG — это не модель

Распространённое заблуждение — считать RAG типом модели ИИ. Это не так. RAG — это архитектурный паттерн: способ объединения системы поиска / слоя знаний с LLM. Моделью внутри конвейера RAG может быть GPT, DeepSeek, Mistral или любая другая LLM. Компонентом поиска может быть векторная база данных, поисковый API или структурированный граф знаний.

Фраза «мы используем RAG» рассказывает, как организована система. Она не говорит, какая модель используется, является ли она проприетарной и насколько хорош поиск. Два проекта могут заявлять об использовании RAG, имея при этом совершенно разный уровень сложности — один с тщательно подготовленной базой знаний и кастомными эмбеддингами, другой с наспех собранным прототипом, который редко возвращает релевантные документы.

Что RAG не доказывает

Использование RAG не доказывает, что базовая LLM является проприетарной или дообученной. Проект может вызывать сторонний API.
Построение конвейера RAG не доказывает высокое качество поиска. Качество зависит от базы знаний, стратегии чанкинга, модели эмбеддингов и релевантности поиска.
Наличие архитектуры RAG не доказывает точность ответов. Плохой поиск может подавать нерелевантный контекст, и LLM всё равно может галлюцинировать.
Упоминание RAG на лендинге не доказывает, что система действительно выполняет поиск. Без Tier-1 доказательств — кода, архитектурных диаграмм, логов демо — заявление остаётся неверифицированным.

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

Где RAG отображается в карточках проектов DecAIHub

RAG обычно упоминается в поле AI component — напрямую или через описания, подразумевающие конвейер «поиск + генерация». Флаг AI_1 проверяет, описан ли AI component с достаточной детализацией. Просто написать «RAG» недостаточно; карточка должна объяснять, что извлекается, откуда и для какой цели.

Не путайте с

LLM — движок генерации внутри конвейера RAG. RAG добавляет поиск поверх.
Обучение — RAG — это паттерн времени инференса. Он не переобучает модель; он дополняет промпт найденным контекстом.
ИИ-агент — агент может использовать RAG как один из инструментов, но RAG сам по себе не делает систему агентом.
Файн-тюнинг — файн-тюнинг изменяет веса модели во время обучения. RAG вводит внешние знания во время инференса, не изменяя модель.
Поиск / слой знаний — компонент поиска — одна половина RAG. RAG добавляет этап генерации поверх чистого поиска.

Часто задаваемые вопросы

В чём разница между RAG и файн-тюнингом?

Файн-тюнинг необратимо изменяет веса модели, обучая её на специализированном датасете. Новые знания становятся частью самой модели. RAG оставляет модель нетронутой и вместо этого подаёт релевантные документы во время запроса. Файн-тюнинг лучше подходит для обучения модели новому стилю или формату задачи; RAG — для поддержания ответов, основанных на свежих, верифицируемых фактах. Многие продакшен-системы используют оба подхода: дообученная модель задаёт тон и формат, а RAG обеспечивает актуальную фактическую основу.

Делает ли RAG LLM более точными?

RAG может значительно снизить галлюцинации, опирая ответы модели на найденные доказательства. Однако точность зависит от качества поиска. Если система поиска возвращает нерелевантные или устаревшие документы, LLM может выдать уверенно неверный ответ — теперь ещё и подкреплённый неверными доказательствами. RAG поднимает потолок точности, но не гарантирует её. Измерение precision и recall поиска необходимо для любого серьёзного развёртывания RAG.

Что такое векторная база данных?

Векторная база данных — это специализированное хранилище, предназначенное для хранения и поиска многомерных числовых векторов (эмбеддингов). При подаче эмбеддинга запроса база данных выполняет поиск по сходству — обычно с помощью алгоритмов HNSW или IVF — для нахождения ближайших совпадающих векторов. Это обеспечивает семантический поиск: нахождение документов по смыслу, а не по точному совпадению ключевых слов. Популярные векторные базы данных: Pinecone, Weaviate, Qdrant, Milvus и Chroma.

Как RAG используется в крипто-ИИ-проектах?

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

Может ли RAG работать с ончейн-данными?

Да. Слой поиска в конвейере RAG может подключаться к блокчейн-индексаторам, субграфам или API ончейн-аналитики. Когда пользователь спрашивает о балансе кошелька, истории транзакций или состоянии смарт-контракта, система поиска извлекает соответствующие ончейн-данные, а LLM генерирует ответ в человекочитаемой форме. Основные проблемы: задержка (запросы к блокчейну могут быть медленными), форматирование данных (сырые ончейн-данные нужно распарсить и разбить на чанки для эмбеддинга) и актуальность (индекс должен обновляться достаточно часто, чтобы отражать текущее состояние сети).

Смотрите также

Внешние источники

Lewis, P. et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." arXiv, 2020. https://arxiv.org/abs/2005.11401
Gao, Y. et al. "Retrieval-Augmented Generation for Large Language Models: A Survey." arXiv, 2024. https://arxiv.org/abs/2312.10997
AWS. "What is RAG?" https://aws.amazon.com/what-is/retrieval-augmented-generation/
Pinecone. "Retrieval-Augmented Generation (RAG)." https://www.pinecone.io/learn/retrieval-augmented-generation/
Microsoft. "Retrieval-Augmented Generation (RAG) in Azure AI Search." https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview