Объяснение RAG: как системы ИИ получают свежие знания по запросу
Узнайте, как работает технология Retrieval-Augmented Generation — от разбиения текста на чанки и использования эмбеддингов до векторного поиска, что позволяет моделям ИИ отвечать на вопросы без переобучения.
Представьте себе ИИ-ассистента, который давно завершил свою обучающую процедуру.
Вы задаете ему вопрос:
«Что находится в этом документе, который я только что загрузил?»
Во время обучения модель никогда не сталкивалась с этим файлом.
Как же она может ответить?
Одним из решений является техника под названием Retrieval-Augmented Generation, обычно сокращаемая до RAG.
Bлагодаря RAG ИИ-система может извлекать релевантные материалы из внешних источников и включать их в ответ, который она генерирует.
Вот что интересно:
Модель не обязана переобучаться каждый раз, когда появляется новая информация.
Давайте рассмотрим, как это работает.
Проблема: ИИ не может знать всё
Большие языковые модели обучаются на тех данных, с которых они проходили тренировку.
Упрощенное представление этого процесса выглядит следующим образом:
Training Data
↓
Model Training
↓
Model Parameters
↓
AI Model
↓
Generate Answers
После завершения тренировки у модели нет автоматического способа обрабатывать новые документы, веб-сайты, корпоративные отчеты или личные файлы, появляющиеся позже.
Предположим, вы сегодня завершили тренировку модели.
А завтра кто-то создаст:
new_report.pdf
Этого PDF просто не существовало во время тренировки модели.
Как же тогда модель сможет ответить на вопрос:
"Каковы три основных вывода в этом отчете?"
Именно этот пробел и предназначен для устранения механизм RAG.
Что такое RAG?
RAG = Retrieval-Augmented Generation
Само название объясняет принцип работы:
- Retrieval → поиск соответствующей информации
Вместо простого следования такому порядку:
Question
↓
LLM
↓
Answer
можно создать конвейер вида:
Question
↓
Retrieve relevant information
↓
Add information to context
↓
LLM
↓
Answer
Такое изменение архитектуры может иметь значительное влияние.
RAG против традиционного ИИ
Без RAG процесс происходит напрямую:
┌──────────────┐
Question ───→│ LLM │
└──────┬───────┘
↓
Answer
При использовании RAG:
┌─────────────────┐
│ External Data │
│ PDFs / Docs │
│ Database / Web │
└────────┬────────┘
↓
Question → Retrieval → Relevant Context
↓
LLM
↓
Answer
Модели больше не нужно запоминать всё заранее.
Вместо этого она может запрашивать необходимые факты по мере необходимости.
Как на самом деле работает RAG?
Стандартная конфигурация RAG включает несколько отдельных этапов:
Documents
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Database
↓
← User Question
↓
Query Embedding
↓
Similarity Search
↓
Relevant Chunks
↓
LLM
↓
Final Answer
Рассмотрим каждый из них.
Сбор ваших данных
Начальной точкой является сбор исходных материалов. Это может включать:
- Файлы в формате PDF
- Документы, созданные в Word
- Страницы, взятые с веб-сайтов
- Научные или исследовательские статьи
- Внутренние корпоративные записи
- Инструкции, описывающие продукт
- Файлы простого текста
- Записи, хранящиеся в базе данных
- Записи из базы знаний
В качестве примера представьте папку, содержащую:
company_policy.pdf
research_paper.pdf
employee_handbook.pdf
product_manual.pdf
Пайплайн RAG способен принимать и обрабатывать все эти элементы.
Разделение документов на части
Подача всего документа целиком в модель обычно нецелесообразна из-за ограничений по размеру.
Поэтому документы разделяются на более мелкие единицы, называемые частями.
Вот простая иллюстрация:
Document
│
├── Chunk 1
├── Chunk 2
├── Chunk 3
├── Chunk 4
├── Chunk 5
└── ...
Представьте документ из 100 страниц, содержащий несколько тысяч предложений.
Вместо того чтобы сканировать всё при каждом запросе, вы можете разделить его на более управляемые части:
Chunk 1 → Introduction
Chunk 2 → Architecture
Chunk 3 → Security
Chunk 4 → Performance
Chunk 5 → Limitations
Способ разбиения контента зависит от его характеристик и цели создания.
Преобразование текста в эмбеддинги
Именно здесь всё становится по-настоящему интересным.
Компьютеры не могут понимать текстовый смысл так же, как люди, по крайней мере, не изначально.
Чтобы преодолеть это, текст преобразуется в числовые векторы, называемые эмбеддингами.
Рассмотрим пример:
"Machine learning is a branch of AI"
↓
Embedding Model
↓
[0.21, -0.14, 0.73, ...]
И второе предложение:
"Artificial intelligence includes machine learning"
↓
[0.19, -0.11, 0.70, ...]
Поскольку эти два предложения имеют схожий смысл, их векторы обычно находятся рядом друг относительно в пространстве эмбеддингов.
В приблизительном визуализированном виде:
AI
●
/ \
/ \
ML ● ● Robotics
\
\
Cooking ●
Цель не в поиске буквального совпадения слов.
Вместо этого цель заключается в определении семантической схожести — близости в значении.
Что такое семантический поиск?
Традиционный поисковик на основе ключевых слов воспринимает запрос вроде:
"автомобиль"
и ищет документы, в которых буквально присутствует слово автомобиль.
Семантический поиск, напротив, пытается понять истинное значение запроса.
Например, запрос вроде:
"Как электромобили хранят энергию?"
может выдать отрывок, объясняющий, что электромобили используют литиево-ионные аккумуляторы для сохранения заряда.
Формулировки запросов практически не совпадают, но соответствие тем не менее имеет смысл.
Это возможно благодаря тому, что эмбеддинги кодируют отношения в значении, а не только орфографию.
Хранение эмбеддингов в векторной базе данных
Как только появляются эмбеддинги, им нужно место для хранения.
Именно для этого и существует база данных векторов, которая хранит:
Chunk
+
Embedding
+
Metadata
Структура примерно такова:
Vector Database
ID Vector Text
-------------------------------------
1 [0.21,...] Chunk A
2 [0.78,...] Chunk B
3 [0.34,...] Chunk C
4 [0.91,...] Chunk D
Когда кто-то задаёт вопрос, система сканирует эти сохранённые векторы в поисках соответствующего контекста.
Среди популярных инструментов для такого поиска векторов можно выделить:
- FAISS
- pgvector
- Pinecone
- Weaviate
- Milvus
- Chroma
Выбор конкретной базы данных не является ключевым фактором.
Важно следующее:
Храните информацию в формате, позволяющем быстро выполнять поиск на основе смысла.
Пользователь задаёт вопрос
Допустим, пользователь вводит:
«Какие механизмы безопасности использует система?»
Этот вопрос затем преобразуется в свой собственный эмбеддинг.
User Question
↓
Embedding Model
↓
Query Vector
На этом этапе система хранит числовой «отпечаток» вопроса.
Поиск релевантной информации
Этот вектор запроса затем сравнивается со всеми векторами, уже находящимися в базе данных.
Говоря кратко:
Query
●
/ \
/ \
● ●
Relevant Relevant
Chunk Chunk
●
Unrelated
Выбираются наиболее близкие по совпадению фрагменты.
Например, при наличии:
Question:
"What security mechanisms does the system use?"
Система может вернуть:
Retrieved:Chunk 17 → Authentication
Chunk 42 → Encryption
Chunk 51 → Access control
Теперь у модели есть значимый, релевантный контекст для работы.
Добавление полученной информации в промпт
После нахождения релевантных фрагментов они передаются в LLM в качестве контекста вместе с первоначальным вопросом.
Концептуально структура промпта выглядит так:
System Instructions
+
User Question
+
Retrieved Context
↓
LLM
↓
Answer
Например:
Context:
"The system uses AES-GCM encryption
for protecting stored data..."Question:"What encryption method does the
system use?"
При такой настройке модель может ответить чем-то вроде:
«Система использует шифрование AES-GCM для защиты хранимых данных».
Этот ответ основан на полученных данных, а не исключительно на том, что модель усвоила во время первоначальной обучения.
И в этом суть
Сама модель не обязательно узнала что-то постоянное в результате этого обмена.
Её внутренние параметры остаются неизменными.
Вместо этого процесс выглядит следующим образом:
New Information
↓
External Knowledge Store
↓
Retrieve When Needed
↓
LLM Uses Context
↓
Answer
Именно разделение между фиксированными знаниями модели и заменяемым внешним источником знаний является основой преимуществ RAG.
RAG не означает, что ИИ усвоил информацию
Это различие имеет огромное значение, и его легко неправильно понять.
Предположим, вы загружаете файл вроде этого:
Project_Report.pdf
и ассистент начинает отвечать на вопросы на его основе.
Это не означает, что модель навсегда включила содержимое этого отчета в свои веса.
Вместо этого документ является:
Stored externally
↓
Retrieved when relevant
↓
Provided as context
↓
Used to generate response
Полезной аналогией может служить студент, который во время экзамена обращается к учебнику.
Студент не запоминает заранее каждую страницу.
Вместо этого процесс происходит следующим образом:
Вопрос, затем поиск соответствующей страницы, ее прочтение и ответ
RAG ведет себя примерно так же.
RAG против тонкой настройки
Это сравнение возникает постоянно, поэтому стоит четко его изложить.
Тонкая настройка
При тонкой настройке параметры модели фактически корректируются путем продолжения ее обучения на специально выбранном наборе примеров.
Концептуально:
Base Model
↓
Training Data
↓
Fine-Tuning
↓
Modified Model
RAG
RAG практически не изменяет модель, а вместо этого предоставляет внешнюю информацию при поступлении запроса.
Base Model
+
External Knowledge
↓
Retrieval
↓
Context
↓
Answer
Вот упрощенное сравнение:
| Особенность | RAG | Тонкая настройка |
|---|---|---|
| Изменение параметров модели | Как правило, нет | Да |
| Внешние знания | Отличное соответствие | Менее прямое|
| Обновление знаний | Обновление документов или индекса | Возможна необходимость переобучения |
| Частные документы | Полезно | Возможно, но с другими компромиссами |
| Стиль или поведение | ОграниченоБолее эффективное применение | |
| Обоснование из источника | Сильный потенциал | Не гарантируется по своей природе |
Эти два метода не исключают друг друга; команды могут их сочетать.
Может ли RAG использовать Интернет?
Да, может.
Источник внешних знаний не обязательно должен находиться в частном хранилище документов.
Вместо этого система может заимствовать информацию из таких источников, как:
Internet
↓
Search Engine
↓
Relevant Pages
↓
LLM
↓
Answer
Это становится ценным, когда ответ на вопрос зависит от актуальных фактов.
Например:
«Что изменилось в последней версии этого программного обеспечения?»
В таком случае система может сначала загрузить текущую документацию и использовать её для формирования ответа.
Тем не менее одного только поиска недостаточно для гарантии точности.
Источник, из которого берутся данные, всё равно должен быть надежным и действительно релевантным для вопроса.
RAG для собственных документов
Одним из наиболее практичных применений этого подхода является возможность напрямую взаимодействовать со своими собственными файлами.
Представьте папку, содержащую что-то вроде:
Research/
│
├── paper1.pdf
├── paper2.pdf
├── dataset_notes.pdf
├── experiment_results.pdf
└── thesis.pdf
Система на основе RAG позволит задавать такие вопросы:
"Каковы были основные ограничения, выявленные в экспериментах?"
Тогда структура обработки будет выглядеть так:
Your Documents
↓
Extract Text
↓
Chunk Documents
↓
Create Embeddings
↓
Vector Database
↓
Question
↓
Semantic Search
↓
Relevant Sections
↓
LLM
↓
Answer
Именно по этой причине RAG стал настолько ценным инструментом для исследовательских рабочих процессов и систем знаний крупных предприятий.
RAG в реальных приложениях
Этот подход используется в самых разных системах.
Поддержка клиентов
Customer Question
↓
Product Documentation
↓
Retrieve Relevant Section
↓
AI
↓
Response
Образование
Student Question
↓
Course Materials
↓
Relevant Concepts
↓
AI Tutor
↓
Explanation
Исследования
Research Question
↓
Research Papers
↓
Relevant Sections
↓
AI
↓
Summary
Корпоративные знания
Employee Question
↓
Internal Documents
↓
Retrieve Policy
↓
AI
↓
Answer
RAG не полностью устраняет галлюцинации
Этот момент заслуживает особого внимания.
Вы можете предположить:
«Если я использую RAG, ИИ никогда не будет выдумывать».
Это не совсем верно.
RAG может уменьшить количество определённых видов ответов, не подкреплённых данными, но он не устраняет проблему полностью.
Например:
Bad Retrieval
↓
Wrong Context
↓
LLM
↓
Wrong Answer
Существует ещё несколько способов, когда могут возникнуть ошибки:
- Фрагменты текста, разделённые таким образом, что теряется их смысл
- Релевантные факты, которых просто нет в исходном материале
- Взятые фрагменты, которые на самом деле не связаны с вопросом
- Документы, устаревшие или больше не точные
- Исходные файлы, которые с самого начала были неверными или несоответствовали друг другу
- Слишком большой объём контекста, заложенный сразу в запрос
- Сама модель, принимающая неверные решения, несмотря на качественный входной материал
По этой причине надежной системе RAG требуется нечто большее, чем просто векторная база данных.
Оценка системы RAG
Можно оценивать работу конвейера RAG на нескольких уровнях.
Качество поиска
Система смогла получить правильную информацию?
Question
↓
Retrieved chunks
↓
Are they relevant?
Качество генерации
Смогла ли модель эффективно использовать полученные данные?
Retrieved Context
↓
Generated Answer
↓
Is the answer supported?
Качество от начала до конца
Отвечает ли весь конвейер в совокупности правильно на вопрос пользователя?
Question
↓
Retrieval
↓
Context
↓
Generation
↓
Final Answer
Система может дать неверный результат даже при отличной основной модели LLM.
Например:
Если при поиске находится неверный документ, даже очень сильная модель может дать неправильный ответ.
Математика, лежащая в основе эмбеддингов
Эмбеддинги позволяют сравнивать фрагменты информации с помощью математики.
Одним из широко используемых показателей сходства является косинусное сходство.
Для двух векторов A и B косинусное сходство рассчитывается как скалярный произведение A и B, деленное на произведение их модулей.
Результат показывает, насколько тесно совпадают направления этих двух векторов.
Проще говоря:
High similarity
↓
Vectors point in similar directions
↓
Likely related meaning
Это предоставляет RAG конкретный математический способ нахождения информации, семантически связанной с запросом.
RAG — это как библиотека для ИИ
Возможно, это самый ясный способ представить себе эту концепцию.
Представьте ИИ в виде очень способного студента.
Без RAG:
Student
↓
Uses what they already remember
↓
Answer
С RAG:
Student
↓
Goes to library
↓
Finds relevant book
↓
Reads relevant pages
↓
Answers question
Основные знания и способность к логическому мышлению студента не изменились.
Изменилась только информация, доступная этому студенту в данный момент.
В сущности, именно в этом заключается суть RAG.
Куда движется RAG
Системы RAG постепенно становятся всё более сложными.
В будущем они могут объединять в себе:
User Question
↓
Query Understanding
↓
Multiple Retrieval Sources
↓
Document Ranking
↓
Reasoning
↓
Tool Use
↓
Verification
↓
Answer + Evidence
Вместо поиска в одном документе система может искать среди:
PDFs
+
Database
+
Website
+
API
+
Company Knowledge Base
Затем соответствующие фрагменты объединяются вместе.
Это способствует тому, что RAG превращается в более широкую архитектуру знаний и рассуждений для ИИ-агентов, а не просто в метод поиска информации.
Более широкая перспектива
RAG ознаменовывает значимое изменение в подходе к пониманию знаний у ИИ.
Старая модель была такова:
Train AI
↓
Put knowledge into model
↓
Ask questions
Новый подход выглядит более так:
Train AI
↓
Keep knowledge externally
↓
Retrieve relevant information
↓
Reason over it
↓
Generate answer
Такой способ разделения интеллекта модели и внешних знаний оказывается чрезвычайно мощным.
Модели больше не нужно хранить все факты внутри себя.
Вместо этого ей достаточно уметь эффективно использовать информацию, когда она к ней имеет доступ.
Возможно, будущее ИИ заключается не в создании модели, запомнившей всё, что только можно знать.
Возможно, речь идёт о создании модели, способной определить, что ей нужно найти, отыскать подходящий источник, эффективно использовать полученные данные и проверить достоверность ответа.
Именно поэтому технология RAG заслуживает внимания.
AI Model
+
External Knowledge
+
Retrieval
+
Reasoning
+
Verification
↓
More Useful AI
Это указывает на более общую идею: самый умный ИИ — это не тот, кто знает всё, а тот, кто умеет находить то, что ему нужно.