Продолжаем. Теперь мы переходим к очень важному разделу первой главы. Здесь мы разрушим еще одну распространенную иллюзию: RAG — это не просто «добавить документы в prompt». Современный RAG — это полноценная информационная система, где качество ответа определяется не только LLM, а всей цепочкой обработки данных.
На предыдущем этапе мы получили минимальную схему:
Вопрос пользователя
│
▼
Поиск
│
▼
Найденные документы
│
▼
LLM
│
▼
Ответ
Эта схема правильная.
Но она слишком сильно упрощена.
Она похожа на описание автомобиля:
«Автомобиль состоит из двигателя, четырех колес и руля.»
Формально это правда.
Но если мы захотим построить настоящий автомобиль, нам придется разобраться в:
- типе двигателя;
- трансмиссии;
- топливной системе;
- электронике;
- тормозах;
- безопасности;
- управлении.
С RAG происходит то же самое.
Сама идея проста.
Реализация сложна.
Полная архитектура современной RAG-системы
Рассмотрим более реалистичную схему.
Пользователь
│
▼
┌──────────────────┐
│ Query Processing │
└──────────────────┘
│
▼
┌──────────────────┐
│ Query Rewrite │
└──────────────────┘
│
▼
┌──────────────────┐
│ Query Embedding │
└──────────────────┘
│
▼
┌─────────────────────────────────┐
│ Retrieval │
└─────────────────────────────────┘
│ │
▼ ▼
Dense Search Sparse Search
(Embeddings) (BM25)
│ │
└─────────┬──────────┘
│
▼
┌──────────────────┐
│ Result Fusion │
└──────────────────┘
│
▼
┌──────────────────┐
│ Reranking │
└──────────────────┘
│
▼
┌──────────────────┐
│ Context Filtering│
└──────────────────┘
│
▼
┌──────────────────┐
│ Prompt Building │
└──────────────────┘
│
▼
LLM
│
▼
Ответ
Каждый блок здесь решает отдельную проблему.
Разберем их.
1.5. Query Processing — подготовка запроса
Первое, что делает пользователь, — формулирует вопрос.
Например:
Как настроить резервное копирование PostgreSQL?
Для человека этот вопрос понятен.
Но для поисковой системы он может быть недостаточно оптимальным.
Почему?
Потому что пользователь формулирует вопрос с точки зрения своей задачи.
А система поиска должна найти документы.
Это не всегда одно и то же.
Проблема естественного языка
Рассмотрим несколько вариантов:
Как сделать backup базы?
Как настроить резервирование PostgreSQL?
Процедура создания резервной копии БД
Postgres backup configuration
Человек понимает, что речь идет об одном и том же.
Но разные системы поиска могут воспринимать эти запросы совершенно по-разному.
Особенно это заметно в больших корпоративных базах.
Документ может называться:
Database Recovery Procedure v3.5
Хотя пользователь никогда не использует слово «Recovery».
Query Rewrite
Поэтому современные RAG-системы часто используют дополнительный этап:
переписывание запроса.
Система сначала анализирует вопрос пользователя и создает более подходящую поисковую форму.
Например:
Пользователь:
Как вернуть базу после сбоя?
Система преобразует:
Database recovery procedure
PostgreSQL restore
Backup recovery steps
Disaster recovery documentation
После этого поиск становится эффективнее.
Multi Query Retrieval
Еще более мощный вариант — создание нескольких поисковых запросов.
Например:
Исходный вопрос:
Почему сервер медленно работает?
Модель может создать:
CPU performance troubleshooting
Memory pressure analysis
Linux system monitoring
Server bottleneck investigation
Затем каждый запрос используется отдельно.
Результаты объединяются.
Такой подход называется:
Multi Query Retrieval
1.6. Query Embedding
После подготовки запроса следующий этап — преобразование текста в числовое представление.
Например:
"Как настроить PostgreSQL backup?"
становится:
[
0.023,
-0.451,
0.782,
...
]
Тысячи чисел.
Этот набор чисел называется:
embedding vector
Почему это необходимо
Компьютер плохо понимает смысл текста напрямую.
Для него:
backup
и
резервная копия
это разные последовательности символов.
Но человек понимает, что смысл близкий.
Embedding-модель пытается сделать так, чтобы похожие по смыслу тексты находились рядом в математическом пространстве.
Например:
Векторное пространство
PostgreSQL backup
●
Database restore
●
●
Cooking recipe
Первые два объекта находятся близко.
Последний далеко.
Важное замечание
На этом этапе мы впервые встречаем фундаментальную идею всей современной системы поиска:
Поиск происходит не по словам, а по смыслу.
Это главное отличие RAG от классических поисковых систем.
1.7. Retrieval — поиск информации
Теперь система должна найти документы, которые помогут ответить на вопрос.
Но возникает проблема.
Представим:
- 10 документов — легко;
- 10 тысяч — нормально;
- 10 миллионов — сложно;
- 10 миллиардов — практически невозможно полным перебором.
Если каждый раз сравнивать запрос с каждым документом, время поиска станет огромным.
Поэтому используются специальные структуры данных и алгоритмы.
Например:
- FAISS;
- HNSW;
- IVF;
- ScaNN;
- DiskANN.
Мы подробно разберем их позже.
1.8. Почему одного поиска недостаточно
Здесь возникает один из важнейших моментов современной архитектуры.
Долгое время считалось:
Если embedding хороший, достаточно векторного поиска.
Практика показала, что это не всегда так.
Рассмотрим запрос:
Как исправить ошибку ORA-12514 Oracle?
Пользователь ищет конкретный код ошибки.
Здесь ключевые слова имеют огромное значение.
Векторный поиск может понять общий смысл:
Oracle connection problem
Database error
Network issue
Но может не найти именно:
ORA-12514
потому что это редкая комбинация символов.
Поэтому современные системы используют два типа поиска.
Dense Retrieval
По смыслу.
Использует embeddings.
Хорошо работает для:
- вопросов;
- объяснений;
- похожих концепций.
Sparse Retrieval
По словам.
Например:
- TF-IDF;
- BM25.
Хорошо работает для:
- кодов ошибок;
- имен файлов;
- номеров документов;
- технических терминов.
Hybrid Search
Лучшие современные системы часто объединяют оба подхода.
Запрос
│
┌────────┴────────┐
▼ ▼
Vector Search Keyword Search
│ │
└────────┬────────┘
▼
Объединение
▼
Результат
1.9. Главный вывод этого раздела
Теперь можно сформулировать важный принцип:
Качество RAG определяется не только качеством языковой модели. В большинстве практических систем основное ограничение находится раньше — на этапе поиска и подготовки контекста.
Можно использовать самую мощную LLM в мире, но если ей передали неправильные документы, она не сможет дать хороший ответ.
И наоборот.
Даже относительно небольшая локальная модель может показывать отличные результаты, если получает правильный контекст.
В следующей части первой главы мы разберем:
1.10. Почему RAG иногда дает неправильные ответы
Это будет один из самых важных разделов всей книги.
Мы подробно разберем:
- почему модель «галлюцинирует»;
- почему найденный документ может не помочь;
- почему больше документов иногда хуже;
- почему RAG не является гарантией истины;
- где именно ломается цепочка:
Документ
↓
Индекс
↓
Поиск
↓
Контекст
↓
Prompt
↓
LLM
↓
Ответ
И начнем формировать инженерный подход к диагностике RAG-систем.