Полное руководство по RAG: архитектура, типичные ошибки и open-source реализация

Ваша LLM врет? Это лечится. Но не так, как вы думаете

Вы загрузили тонну документации в ChatGPT, а он все равно генерирует ответы из своей старой тренировочной выборки. Или выдает факты, которые были актуальны два года назад. Классические галлюцинации. В теории, RAG (Retrieval-Augmented Generation) должен был стать панацеей. На практике, 80% внедрений спотыкаются об одни и те же грабли. Сегодня разберем, почему ваша RAG-система, скорее всего, работает плохо, и как заставить ее отвечать точно по вашим документам.

Сердце и мозг: из чего на самом деле состоит RAG

Забудьте про красивые диаграммы с тремя блоками. Реальная архитектура RAG - это цепь из пяти взаимозависимых компонентов, где сбой в любом звене убивает всю точность.

• Загрузчик и парсер: Тот, кто превращает ваш PDF, DOCX или HTML в сырой текст. Если он теряет таблицы или иерархию заголовков - все, вы уже проиграли.
• Чанкер (Chunker): Самый недооцененный убийца качества. Нарезка текста на равные куски по 500 символов - гарантия того, что контекст разорвется.
• Модель эмбеддингов (Embedding Model): Превращает текст в вектор чисел. В 2026 году text-embedding-3-large-3072d от OpenAI и BGE-M3 от BAAI задают тон. Ключевой параметр - размерность. 1536 - старый стандарт, 3072 дает прирост в recall на сложных запросах.
• Векторная база + гибридный поиск: Pure векторный поиск уже не катит. Нужен гибрид: семантический поиск (по векторам) + лексический (по ключевым словам, типа BM25). Почему это критично, мы разбирали в roadmap на 2026 год.
• LLM с расширенным контекстом: Модель, которая получает найденные чанки и вопрос, и генерирует ответ. GPT-4 Turbo с контекстом 128к токенов - стандарт. Но локальные модели вроде Llama 3.2 90B или Command R+ дышат в спину.

7 ошибок, которые сведут на нет все ваши усилия

Вот что я вижу в 9 из 10 проектов, которые приходят на code review.

1. Наивный чанкинг (разрыв контекста)

Берете текст, делите его по символам. Результат? Вопрос про "настройки безопасности на странице 5" не найдет нужный чанк, потому что "страница 5" была в одном куске, а "настройки безопасности" - в другом.

2. Игнорирование метаданных

Вы сохраняете в векторную базу только текст чанка. А источник, номер страницы, заголовок раздела - теряете. Потом LLM не может сказать "смотрите документ X, страница Y", и вы не можете проверить ответ.

3. Слабая модель эмбеддингов

Использование устаревшей модели вроде text-embedding-ada-002 (уже релиз 2022 года) для поиска по узкоспециальным текстам. Она плохо понимает нюансы доменного языка.

4. Отсутствие реранкинга (re-ranking)

Векторный поиск возвращает топ-5 похожих чанков. Но "похожий" не всегда значит "релевантный". Отправлять все 5 в LLM - дорого и может зашумлять контекст. Нужен отдельный маленький и быстрый модель-ранкер (например, BGE-reranker-v2-m3), который переупорядочит результаты по истинной релевантности запросу.

5. Прямой поиск по пользовательскому запросу

Пользователь спрашивает: "Как мне починить эту штуку?". Векторная база ищет по слову "штука" и возвращает мусор. Нужно сначала с помощью LLM переформулировать запрос в поисковый: "Инструкция по устранению неполадок устройства X, раздел 'Ремонт'". Это называется Query Transformation или Query Expansion.

6. Скудный системный промпт

"Ответь на вопрос на основе контекста." - этого катастрофически мало. Нужны четкие инструкции: что делать, если ответа нет в контексте, как ссылаться на источники, в каком формате выводить ответ. Готовые шаблоны промптов, которые реально работают, мы собрали здесь.

7. Нет мониторинга и eval-пакетов

Вы запустили систему и забыли. А она тихо деградирует: новые документы плохо индексируются, пользователи задают другие вопросы. Без метрик вроде Hit Rate (попал ли релевантный документ в топ-k) и Faithfulness (не придумала ли LLM того, чего нет в контексте) вы летите вслепую.

Собираем production-ready RAG за час: open-source стек 2026

Забудьте про монолитные облачные сервисы. Сейчас все собирается из Lego-конструктора. Вот стек, который не подведет.

1 Подготовка и чанкинг документов

Используем LlamaIndex (v0.11.0+) или Unstructured.io - они умеют парсить сотни форматов, включая презентации и сканы с OCR.

from llama_index.core import SimpleDirectoryReader
from llama_index.core.node_parser import SemanticSplitterNodeParser
from llama_index.embeddings.openai import OpenAIEmbedding

# Используем семантический сплиттер на основе эмбеддингов
embed_model = OpenAIEmbedding(model="text-embedding-3-large", dimensions=3072)
splitter = SemanticSplitterNodeParser(
    buffer_size=1,
    breakpoint_percentile_threshold=95,
    embed_model=embed_model
)

documents = SimpleDirectoryReader("./data").load_data()
nodes = splitter.get_nodes_from_documents(documents)
# Каждый node содержит текст и метаданные (источник, позиция в документе)

2 Векторная база с гибридным поиском

Qdrant 1.9.x или Weaviate 1.25+ поддерживают гибридный поиск из коробки. Мы выберем Qdrant за его простоту и производительность на CPU.

# Запускаем Qdrant через Docker (актуальный образ на 2026)
docker run -p 6333:6333 qdrant/qdrant:latest

from qdrant_client import QdrantClient
from qdrant_client.models import Distance, VectorParams, PointStruct
import numpy as np

client = QdrantClient(host="localhost", port=6333)
client.recreate_collection(
    collection_name="docs_2026",
    vectors_config=VectorParams(size=3072, distance=Distance.COSINE),
    # Включаем sparse-вектора для лексического поиска (BM25)
    sparse_vectors_config={
        "lexical": models.SparseVectorParams()
    }
)

# Сохраняем ноды. Предполагаем, что у нас уже есть эмбеддинги vectors и тексты texts
points = []
for i, (vector, text, metadata) in enumerate(zip(vectors, texts, metadatas)):
    # Создаем sparse-вектор (термы и их веса) для лексического поиска
    # На практике используйте библиотеку для преобразования текста в термы (tf-idf)
    points.append(
        PointStruct(
            id=i,
            vector=vector,
            payload={"text": text, "metadata": metadata}
        )
    )
client.upsert(collection_name="docs_2026", points=points)

3 Поиск с реранкингом и агентской логикой

Здесь мы выходим за рамки naive RAG. Добавляем агента, который решает, нужно ли искать, уточнять запрос или использовать цепочку рассуждений. Пример такого агента для объяснения настолок мы разбирали ранее.

from llama_index.core import VectorStoreIndex, ServiceContext
from llama_index.llms.openai import OpenAI
from llama_index.postprocessor.flag_embedding_reranker import FlagEmbeddingReranker

# Используем актуальную модель GPT (на 26.01.2026)
llm = OpenAI(model="gpt-4-turbo-2026-01-26", temperature=0)
service_context = ServiceContext.from_defaults(llm=llm, embed_model=embed_model)

# Создаем индекс поверх Qdrant
index = VectorStoreIndex.from_vector_store(vector_store, service_context=service_context)

# Добавляем реранкер (легкая модель, которая пересортирует результаты)
reranker = FlagEmbeddingReranker(model="BAAI/bge-reranker-v2-m3", top_n=3)

query_engine = index.as_query_engine(
    similarity_top_k=10,  # Сначала берем 10 кандидатов
    node_postprocessors=[reranker],  # Реранжируем и оставляем топ-3
    # Включаем гибридный поиск в Qdrant
    vector_store_query_mode="hybrid",
    alpha=0.7  # Вес для семантического поиска (0.7) vs лексического (0.3)
)

response = query_engine.query("Какие требования к безопасности в последнем обновлении?")
print(response)
print(response.source_nodes)  # Показывает источники

Что дальше? Эволюция RAG в 2026 и позже

Базовый RAG - это только начало. Тренды, которые уже стали must-know:

• Agentic RAG: Система сама решает, какие базы данных опросить, когда выполнить поиск, а когда использовать цепочку рассуждений (Chain-of-Thought). Полное руководство по сборке такой системы локально.
• Мультимодальный RAG: Поиск не только по тексту, но и по изображениям, аудио, видео. Запрос "найди схему из презентации, где показан процесс X" требует совместного эмбеддинга текста и изображений. Новые подходы к мультимодальному RAG.
• RAG для structured data: Работа с SQL-базами, Excel, API. Это уже не просто поиск, а генерация запросов и интерпретация результатов. И да, 90% точности Text-to-SQL - это ни о чем, когда цена ошибки - финансовый отчет. Почему 90% точности в Text-to-SQL недостаточно.
• Безопасность и атаки на RAG: Инъекция вредоносного контекста, подмена чанков, data poisoning. В 2026 году хакеры уже вовсю атакуют RAG-системы. Подробнее об угрозах и защите.

Частые вопросы (FAQ)

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