Проблема больших языковых моделей — знания замкнуты в параметрах.
Модель обучена на данных 2023 года. Пользователь спрашивает про событие 2024 года. Модель "не знает" — выдумывает ответ.
RAG решает проблему: вместо упаковки знаний в параметры модель запрашивает факты из внешней базы.
Архитектура RAG
RAG (Retrieval-Augmented Generation) — это не отдельный алгоритм, а архитектурный паттерн.
Три этапа работы RAG
- Индексация данных (offline, заранее)
- Поиск релевантной информации (online, при запросе)
- Генерация ответа с учётом найденного
Каждый этап критичен — сбой на любом приводит к плохим ответам.
Этап 1: Индексация данных
Подготовка базы знаний для быстрого поиска.
Процесс индексации Документы (PDF, Wiki, базы данных) ↓ Разбиение на чанки (200-1000 токенов) ↓ Преобразование в эмбеддинги (векторы) ↓ Сохранение в векторную БД ↓ Индекс знаний готов
Этап выполняется оффлайн, периодически обновляется.
Разбиение на чанки
Chunk — фрагмент текста оптимального размера для поиска.
| Параметр | Типичное значение | Зачем |
|---|---|---|
| Размер чанка | 200-1000 токенов | помещается в контекст LLM |
| Overlap (перекрытие) | 10-20% | контекст не обрывается на границе |
| Стратегия | по абзацам / предложениям | сохраняет смысловую целостность |
Слишком маленькие чанки (50-100 токенов):
- • Теряют контекст
- • Буквальный поиск по словам
Слишком большие чанки (2000+ токенов):
- • Не помещаются в контекст модели
- • Снижают точность поиска
Эмбеддинги — векторное представление
Эмбеддинг преобразует текст в список чисел.
Модель эмбеддингов (например, BERT-подобная) переводит чанк в вектор 384-1536 чисел.
Пример (упрощённо):
- "Оформление отпуска" → [0.23, -0.15, 0.87, ..., 0.42]
- "Как взять отпуск?" → [0.21, -0.14, 0.89, ..., 0.40] (близкий)
- "Настройка сервера" → [-0.45, 0.72, -0.33, ..., 0.11] (далёкий)
Близость векторов = семантическая похожесть.
Векторная база данных
Специализированное хранилище для векторов с быстрым поиском похожих.
Возможности векторных БД:
- • Индексация миллионов/миллиардов векторов
- • Поиск k ближайших соседей за миллисекунды
- • Фильтрация по метаданным (дата, источник, тег)
Алгоритмы индексирования: • Flat — точный, но медленный (перебор) • HNSW — быстрый приближённый поиск (графы) • IVF — кластеризация с инвертированными индексами
Этап 2: Поиск (Retrieval)
Нахождение релевантных фрагментов при запросе пользователя.
Процесс поиска Вопрос пользователя ↓ Преобразование в эмбеддинг (той же моделью) ↓ k-NN search в векторной БД ↓ Топ-K релевантных чанков (обычно 3-5)
k-NN search (k Nearest Neighbors) — поиск k ближайших векторов.
Метрики близости:
- • Cosine similarity (косинусное расстояние)
- • Euclidean distance (евклидово)
- • Dot product
Наиболее популярна cosine similarity — устойчива к длине векторов.
Улучшение поиска
| Метод | Суть |
|---|---|
| Двухступенчатый поиск | сначала топ-20 векторным, потом rerank |
| MMR (Maximum Marginal Relevance) | баланс релевантности и разнообразия |
| Гибридный поиск | векторный + полнотекстовый (BM25) |
MMR избегает дублей: если первый фрагмент про X, второй будет релевантен, но про другой аспект.
Этап 3: Генерация ответа
Формулирование ответа языковой моделью на основе найденного контекста.
Процесс генерации Найденные чанки + вопрос ↓ Формирование промпта: "Контекст: [чанк1, чанк2, чанк3] Вопрос: ... Ответь ТОЛЬКО на основе контекста" ↓ Языковая модель генерирует ответ ↓ Ответ + ссылки на источники
Модель работает как с предоставленным контекстом, так и со своими знаниями из обучения.
Ограничения контекста LLM
Проблема: окно контекста модели ограничено (4k-32k токенов). Если найдено 5 документов по 2000 токенов каждый — не поместятся.
Решения:
- • Summarization (краткие конспекты документов)
- • Извлечение только релевантных абзацев
- • Рекурсивная генерация (ответ по частям)
- • Модели с длинным контекстом (100k+ токенов)
RAG vs Fine-tuning
Два подхода к адаптации LLM под специфичные знания.
| Параметр | RAG | Fine-tuning |
|---|---|---|
| Обогащение знаний | внешние данные при запросе | встраивание в параметры |
| Актуальность | высокая (обновление базы) | ограничена датасетом обучения |
| Галлюцинации | минимизированы (привязка к фактам) | снижены, но не устранены |
| Прозрачность | высокая (ссылки на источники) | низкая ("чёрный ящик") |
| Сложность | инженерная (пайплайн) | ML-экспертиза (обучение) |
| Скорость ответа | +задержка поиска | только генерация |
| Стоимость | ниже (не нужно обучение) | высокая (GPU, датасет) |
| Обновление знаний | добавление документов | переобучение модели |
Когда выбирать RAG:
- • Знания часто обновляются
- • Важна проверяемость ответов
- • Нет ресурсов на обучение моделей
- • База знаний большая и несвязанная
Когда fine-tuning:
- • Специфический стиль ответов
- • Статичные, структурированные данные
- • Нужна автономность (без внешних баз)
Технические вызовы RAG
| Вызов | Проблема | Решение |
|---|---|---|
| Релевантность поиска | нерелевантные чанки | качественные эмбеддинги, rerank |
| Размер контекста | не помещается всё | summarization, длинные LLM |
| Задержки (latency) | поиск + генерация | оптимизация индекса, кэширование |
| Противоречия в источниках | разные документы — разные факты | алгоритмы разрешения конфликтов |
| Галлюцинации | модель додумывает | явная инструкция "только контекст" |
Главная ошибка внедрения RAG
Типичный сценарий: «Поднимем векторную базу, подключим LLM — RAG готов.»
Проблема: качество RAG зависит от качества каждого компонента.
Что критично:
- • Правильное разбиение документов на чанки
- • Качественная модель эмбеддингов (под ваш домен)
- • Настройка поиска (k, метрики, фильтры)
- • Промптирование для ограничения галлюцинаций
- • Регулярное обновление индекса
Без внимания к деталям RAG даёт плохие результаты, даже с хорошими компонентами.
Правильный подход:
- Подготовить качественные данные
- Выбрать эмбеддинг-модель под домен
- Настроить чанкинг и поиск
- Протестировать на типовых вопросах
- Итеративно улучшать
Перспективы RAG
| Направление | Суть |
|---|---|
| Agentic RAG | множество агентов координируют поиск |
| Multimodal RAG | поиск по изображениям, видео, аудио |
| Hybrid RAG | комбинация с базами данных (SQL-запросы) |
| GraphRAG | поиск по графам знаний |
RAG эволюционирует от простого поиска по тексту к сложным системам с множеством источников и модальностей.
RAG — архитектурный паттерн, комбинирующий поиск и генерацию.
Ключевые компоненты:
- • Векторная БД для хранения эмбеддингов
- • Модель эмбеддингов для семантического поиска
- • Языковая модель для генерации ответов
- • Оркестратор для связывания компонентов
Преимущества:
- • Актуальность (обновление базы знаний)
- • Проверяемость (ссылки на источники)
- • Масштабируемость (рост без переобучения)
Ограничения:
- • Зависимость от качества поиска
- • Задержки при больших базах
- • Сложность инженерной реализации
Правильная стратегия: фокус на качество каждого этапа — индексация, поиск, генерация.
Частые вопросы
Какой размер чанков оптимален для RAG?
200-1000 токенов с перекрытием 10-20%. Конкретное значение зависит от структуры документов. Технические тексты — меньшие чанки (200-400), повествовательные — большие (800-1000). Тестируйте на своих данных, измеряя качество поиска.
Что важнее — качество поиска или качество генерации?
Поиск. Даже лучшая языковая модель не даст правильный ответ, если retriever вернул нерелевантные фрагменты. Сначала оптимизируйте retrieval (эмбеддинги, чанкинг, метрики), потом генерацию. Плохой поиск = плохой RAG.
Можно ли комбинировать RAG и fine-tuning?
Да, это оптимальный подход для многих задач. Fine-tuning адаптирует стиль и формат ответов модели, RAG обеспечивает актуальные факты. Например, модель обучена на терминологии компании, но данные берёт из текущей документации через RAG.