Что такое RAG: предоставление большим языковым моделям доступа к внешним знаниям
Пошаговое руководство по RAG для начинающих: разбиение на части, эмбеддинги, векторный поиск, гибридные методы поиска и ситуации, когда RAG всё ещё создаёт ложные данные, с чёткими диаграммами архитектуры.
Большие языковые модели отвечают, опираясь на память, сформированную в процессе обучения. Эта память мощна, но неполная: она может не включать внутренние руководства, устаревшие правила и факты, которые никогда не появлялись в публичных текстах. Технология генерации с усилением через поиск (RAG) устраняет этот недостаток, сначала извлекая релевантные внешние материалы, а затем прося модель дать ответ на основе этих материалов.
Что такое RAG?
Без механизма поиска вопрос напрямую передается модели:
User Question
↓
LLM
↓
Answer
С использованием RAG система сначала находит релевантную информацию, прежде чем начать генерацию:
User Question
↓
Find Relevant Information
↓
Give Information to the LLM
↓
LLM
↓
Answer
Модель по-прежнему формирует окончательный текст; новым элементом становится контекст из хранилища знаний.
Зачем нам нужен RAG?
Лимиты на обучение, приватные корпуса данных и быстро меняющиеся правила нарушают принцип ответов, основанных исключительно на памяти. Руководство для сотрудников, обновленное на прошлой неделе, не будет входить в веса модели frontier. RAG позволяет ассистенту обращаться к этому руководству при запросе без необходимости повторного обучения.
Простой пример RAG
Сотрудник задаёт вопрос о переносе отпуска. Порядок действий выглядит следующим образом:
Employee asks a question
↓
Search the employee handbook
↓
Find the relevant section
↓
Give that section to the LLM
↓
LLM generates the answer
Ассистент должен цитировать руководство, а не выдумывать правило, которое «звучит разумно».
Как работает RAG?
Важны два этапа: подготовка знаний офлайн, а затем ответ на вопрос онлайн.
1. Подготовка знаний
Загружаются файлы, они делятся на части, эмбеддинги создаются для каждой части, а векторы сохраняются для поиска.
2. Ответ на вопрос
Эмбеддинг создаётся для вопроса, берутся наиболее релевантные части, они объединяются в запрос, после чего генерируется ответ.
Часть 1: Подготовка знаний
Типичные источники информации для ассистента по кадрам:
Employee Handbook
Vacation Policy
Benefits Guide
Leave Policy
Процесс подготовки:
Documents
↓
Extract Text
↓
Break into Smaller Pieces
↓
Create Embeddings
↓
Store for Search
Шаг 1: Получение информации
Извлекаем чистый текст из каждого источника:
Employee Handbook
↓
Extract text
↓
"Employees receive..."
"Vacation requests..."
"Leave policy..."
Заголовки, подзаголовки и навигационные элементы следует удалять на раннем этапе, чтобы они никогда не становились «фактами».
Шаг 2: Разделение документа на фрагменты
Длинные руководства превышают лимиты контекста и маскируют соответствующие абзацы. Разделение на фрагменты позволяет создавать единицы, подлежащие поиску:
Employee Handbook
↓
┌───────────────┐
│ Chunk 1 │
├───────────────┤
│ Chunk 2 │
├───────────────┤
│ Chunk 3 │
├───────────────┤
│ ... │
└───────────────┘
Почему важно разделение на фрагменты?
Слишком большие фрагменты снижают степень релевантности; слишком маленькие теряют связь с окружающими элементами (особенно отрицания и исключения). Наличие перекрытия между соседними фрагментами сохраняет контекст границ. Начните с простого формата — фиксированного размера с перекрытием, затем скорректируйте его при появлении ошибок в оценках.
Шаг 3: Создание эмбеддингов
Эмбеддинги преобразуют текст в векторы, благодаря чему фразы с похожим значением оказываются рядом друг с другом, даже если у них нет общих ключевых слов.
Текст вопроса:
"What is my vacation allowance?"
Перефразирование с той же целью:
"How many annual leave days do I get?"
После встраивания оба могут оказаться рядом с одним и тем же фрагментом, касающимся политики отпусков:
"What is my vacation allowance?"
↓
Embedding
↓
Numerical representation
Для индексации и поиска следует использовать один и тот же инструмент встраивания; смешивание моделей тайно нарушает алгоритм поиска по ближайшему соседу.
Шаг 4: Хранение информации для поиска
Каждый фрагмент вместе с его вектором помещается в векторный индекс (или гибридное хранилище):
Document Chunk
↓
Embedding
↓
Vector Database
Метаданные — название источника, страница, уровень доступа, дата вступления в силу — должны храниться вместе с фрагментом для последующего использования при фильтрации и цитировании.
Часть 2: Ответ на вопрос пользователя
Онлайн-путь:
User Question
↓
Understand the question
↓
Search the stored information
↓
Find relevant chunks
↓
Give those chunks to the LLM
↓
Generate an answer
Шаг 5: Получение релевантной информации
Встраивание вопроса позволяет выделить наиболее релевантные фрагменты, например:
Chunk 147 → Vacation carryover policy
Chunk 148 → Vacation request process
Chunk 62 → Employee benefits
Chunk 300 → Security policy
Здесь качество ранжирования определяет качество окончательного ответа. Плохое получение информации невозможно исправить с помощью более красиво сформулированного запроса.
Шаг 6: Передача информации в LLM
Загруженный текст становится контекстом запроса:
Context:Employees may carry over up to 5 unused
vacation days into the following year.
Question:How many vacation days can I carry over?
Инструкции должны требовать ответа на основе контекста и признания отсутствия информации, когда она не предоставлена.
Шаг 7: Генерация ответа
Retrieved Information
+
User Question
↓
LLM
↓
Answer
Модель формирует ответ, основываясь на полученных данных, а не на общепринятых стереотипах в сфере HR.
Полная архитектура RAG
Метка для офлайн-подготовки:
KNOWLEDGE PREPARATION
Диаграмма «конец-конец»:
Documents
↓
Extract Text
↓
Chunking
↓
Embeddings
↓
Vector Database
│
│
│
▼
USER QUESTION
↓
Query Embedding
↓
Retrieval
↓
Relevant Information
↓
Question + Context
↓
LLM
↓
Answer
До поступления вопроса
Documents
↓
Chunks
↓
Embeddings
↓
Vector Database
При поступлении вопроса
Question
↓
Retrieval
↓
Relevant Context
↓
LLM
↓
Answer
Использует ли RAG только векторный поиск?
Нет. В производственных системах часто сочетаются разные методы.
Поиск по ключевым словам
Лексические сопоставители (BM25 и подобные) отлично справляются с точным совпадением токенов: кодами политик, SKU, идентификаторами ошибок, собственными именами.
Семантический поиск
Векторный поиск находит парафразы и синонимы, которые ускользают от обычных ключевых слов.
Гибридный поиск
Сочетайте оба метода, затем объединяйте рейтинги:
Keyword Search
+
Semantic Search
↓
Hybrid Search
Гибридный подход является хорошим стандартным решением, когда трафик включает как точные идентификаторы, так и запросы на натуральном языке.
RAG не устраняет галлюцинации
Метод извлечения снижает количество необоснованных выдумок, но не устраняет их полностью. К возможным проблемам относятся:
Получен фрагмент неверный:
User Question
↓
Wrong information retrieved
↓
LLM
↓
Wrong answer
Ничего релевантного не найдено, но модель всё равно отвечает:
User Question
↓
No relevant information found
↓
LLM
↓
Unsupported answer
Способы смягчения проблем: более строгое извлечение информации, переранжирование результатов, инструкции о отказе в ответе, цитаты и оценка точности ответа, а не только его плавности.
RAG против тонкой настройки
RAG
Этот метод наилучше подходит, когда знания часто меняются, требуется указание источников или они остаются конфиденциальными вне данных обучения. Обновления подразумевают переиндексацию, а не повторное обучение.
Тонкая настройка
Оптимально, когда необходимо изменить поведение, стиль или формат задачи, либо когда знания достаточно стабильны и компактны, чтобы быть встроенными. Обновление таких решений стоит дорого при частых изменениях правил.
Многие продукты используют оба подхода: настройку для развития навыков и технологию RAG для получения фактов.
Где полезна технология RAG?
Поддержка клиентов
Ассистенты, основанные на документации продукта и шаблонах обработки заявок.
Здравоохранение
Поиск протоколов и рекомендаций с строгим контролем цитирования и доступа (применяются правила домена).
Финансы
Ответы на вопросы о правилах, раскрытии информации и характеристиках продуктов, требующие использования самой свежей утвержденной информации.
Управление персоналом
Руководства, информация о льготах, правила отпусков — именно те же сценарии вопросов от сотрудников, что и выше.
Разработка программного обеспечения
Внутренние рекомендации, пособия по эксплуатации и справки API наряду с публичной документацией.
Когда следует использовать технологию RAG?
Используйте RAG, когда ответы должны отражать конкретный корпус данных, превосходящий объем запроса, который изменяется быстрее, чем циклы настройки модели, или когда требуется указание источника информации. Не используйте RAG для простых фактов, известных базовой модели, для творческих задач или в ситуациях крайне низкой задержки, когда невозможно выполнить операцию поиска.
Что может затруднить использование RAG?
Границы фрагментов данных, смещение эмбеддингов, устаревшие индексы, утечки прав доступа и проблемы с оценкой качества. Пример ошибки:
Пользователь задает вопрос:
User asks:
"What is the vacation carryover policy?"
Система находит неверную группу правил:
↓System retrieves:
"Health insurance policy" ↓LLM receives wrong context ↓Poor answer
Затем модель уверенно объясняет принципы медицинской страховки, как будто речь идет о продлении отпуска. Сначала исправьте процесс поиска и фильтры метаданных, прежде чем винить генератор.
Чему нужно научиться, чтобы создать RAG?
Практическая иерархия навыков:
RAG Fundamentals
↓
Document Processing
↓
Chunking
↓
Embeddings
↓
Vector Databases
↓
Retrieval
↓
Prompt + Context
↓
LLM
↓
Evaluation
Обработка документов, стратегия разбиения на части, эмбеддинги, хранилища векторов, сбор промптов, оценка и операции (пересоздание, доступ, мониторинг) — всё это имеет значение.
Общая картина
Knowledge
↓
Find relevant
information
↓
Give it to LLM
↓
Generate
answer
Знания находятся вне модели; механизмы получения данных преодолевают этот разрыв; генерация остается заключительным этапом.
Варианты разбиения данных в чанки взаимодействуют с размерностью эмбеддингов и типом индекса: конфигурации HNSW с использованием только плотных эмбеддингов ведут себя иначе, чем гибридные хранилища BM25+векторов, когда запросы содержат как прозу, так и идентификаторы. Необходимо иметь писаное правило относительно ситуаций, при которых происходит пересоздание индекса — новые версии руководства, удаленные страницы, изменения прав доступа — и проверять, что удаляемые материалы действительно исчезают из индекса, а не остаются в виде «орфанских» векторов. Форматирование цитат также должно быть частью условий генерации: если интерфейс обещает информацию о происхождении данных на уровне страницы, то плейсхолдеры и постобработчик должны генерировать стабильные идентификаторы источников, а не декоративные сноски, не ведущие никуда.
Повторная оценка ранжирования заслуживает краткого упоминания даже на этапе обучения начинающих. Создание списка кандидатов с помощью двойного кодера стоит недорого; применение кросс-кодера к пятидесяти лучшим кандидатам часто устраняет ошибки вида «документ почти правильный, но раздел неверный», из-за которых демонстрации выглядят неисправными. Это можно сочетать с простыми правилами отклонения, когда показатели сходства опускаются ниже установленного порога. Команды, которые пропускают процедуру оценки, обычно обнаруживают эти проблемы перед заинтересованными сторонами, а не в своих записях.
Наконец, не забывайте о финансовой стороне использования технологии RAG: затраты на индексацию возрастают по мере увеличения объема корпусов данных, тогда как затраты на доработку оплачиваются пакетами. Для областей с высокими требованиями к регулированию непрерывные расходы на индексацию обычно дешевле, чем еженедельные процедуры доработки — к тому же это позволяет цитировать точный абзац, запрошенный аудитором. Именно такая возможность отслеживания часто является настоящей технической требованием, скрытым за формулировкой «создать чат-бота».
При интеграции RAG в существующую стек-архитектуру поддержки начните с одного корпуса данных и одной группы вопросов, вместо попыток охватить всё сразу. Оцените уровень отклонений, частоту эскалации и количество жалоб на неверные ответы в рамках этой части системы, прежде чем массово добавлять пространства Confluence. Узкие тесты помогают определить, какие размеры фрагментов данных и гибридные веса эффективны; широкомасштабные запуски, как правило, показывают, что дашборды без метрик точности скрывают ухудшения качества ответов. В первые недели сохраняйте очередь для ручной проверки спорных ответов, чтобы редакторы могли отмечать случаи «хорошего поиска/плохой генерации» и «плохого поиска» — это разные способы устранения проблем. Со временем такие метки становятся сигналами для алгоритмов переранжирования и помогают решать, следует ли тот или иной топик покинуть систему RAG и стать частью детерминистического рабочего процесса.
Итоговый вывод
Store external knowledge
↓
Find relevant information
↓
Give that information to an LLM
↓
Generate a grounded response
Храните внешние знания, находите соответствующую информацию для каждого вопроса и только затем генерируйте ответ. Этот цикл из трех этапов и есть RAG — простой в описании, но требующий точной реализации, и при этом самый практичный способ обеспечить честность помощников в отношении конфиденциальных и постоянно меняющихся фактов.
Дисциплина в работе отличает простые демо-версии от надежных помощников: замораживайте наборы вопросов, измеряйте коэффициенты успешного поиска наряду с точностью ответов, а также регулярно обновляйте индексы в соответствии с частотой изменений исходных материалов. При использовании гибридного поиска, переранжирования или фильтров на основе метаданных сохраняйте один и тот же набор показателей, чтобы улучшения были видимы, а не основаны лишь на случайных наблюдениях. С самого начала рассматривайте метки доступа как часть данных, передаваемых в составе запросов; добавление прав позже приводит к тому, что конфиденциальные записи HR попадают в общие чаты. Наконец, при слабых результатах поиска предпочитайте отказ с просьбой о цитировании источника вместо произвольных предположений — пользователи больше доверяют обоснованному молчанию, чем искусственно созданным ответам.
Храните руководства по восстановлению индексов, проверке доступа и известным способам сбоев рядом с диаграммами оптимальных сценариев работы, чтобы операторы получали не только презентации, но и практические инструкции.
Храните руководства по восстановлению индексов, проверкам доступа и известным способам сбоев рядом с диаграммами типичных сценариев работы, чтобы операторы получали нечто большее, чем просто набор слайдов.
Храните руководства по восстановлению индексов, проверкам доступа и известным способам сбоев рядом с диаграммами типичных сценариев работы, чтобы операторы получали нечто большее, чем просто набор слайдов.
Храните руководства по восстановлению индексов, проверкам доступа и известным способам сбоев рядом с диаграммами типичных сценариев работы, чтобы операторы получали нечто большее, чем просто набор слайдов.
Храните руководства по восстановлению индексов, проверкам доступа и известным способам сбоев рядом с диаграммами типичных сценариев работы, чтобы операторы получали нечто большее, чем просто набор слайдов.
Храните руководства по восстановлению индексов, проверкам доступа и известным способам сбоев рядом с диаграммами типичных сценариев работы, чтобы операторы получали нечто большее, чем просто набор слайдов.
Храните руководства по восстановлению индекса, проверке доступа и известным способам сбоев рядом с диаграммами оптимальных сценариев работы, чтобы операторы получали не только презентационные слайды.