📖 Теория: RAG, поиск и генерация по контексту

← К оглавлению урока

⚡ Суть

  • RAG = retrieval + generation: сначала ищем релевантные данные, затем генерируем ответ по ним.
  • Он помогает с актуальностью, корпоративными знаниями и снижением галлюцинаций.
  • Классический pipeline: документы → чанки → эмбеддинги → векторная БД → поиск → промпт → LLM.
  • RAG не гарантирует правду: качество ответа зависит от источников, индекса, retrieval и промпта.

Зачем нужен RAG

Большая языковая модель умеет писать, объяснять и рассуждать, но её знания ограничены тем, что было в обучении. Она не знает ваши внутренние документы, свежие новости, текущую базу знаний компании или содержимое файлов пользователя, если вы явно не передали это в запрос.

Retrieval-Augmented Generation решает эту проблему так: перед ответом система ищет релевантную информацию во внешнем источнике и добавляет найденный контекст в промпт.

Аналогия из лекции. LLM — умный студент. RAG — библиотекарь, который быстро находит нужные страницы и передаёт студенту, чтобы ответ был актуальным и проверяемым.

Преимущества RAG

ПреимуществоЧто это даёт
АктуальностьМожно отвечать по свежим данным, которые не были в обучении модели.
Доступ к доменным знаниямМодель работает с документацией, FAQ, регламентами, базой знаний компании.
Снижение галлюцинацийОтвет строится по найденным фрагментам, а не только по внутренним вероятностям модели.
ОбоснованностьМожно показать источники: документ, страницу, раздел, таймкод, URL.
Дешевле, чем переобучениеНовые документы можно переиндексировать без fine-tuning всей модели.

Архитектура RAG

  1. Источники данных: PDF, Markdown, HTML, база знаний, тикеты, транскрипты, таблицы.
  2. Загрузка: Document Loader превращает файл или страницу в документы с текстом и метаданными.
  3. Разбиение на чанки: длинные документы режутся на небольшие смысловые фрагменты.
  4. Эмбеддинги: каждый чанк превращается в числовой вектор.
  5. Vector store: векторы и метаданные сохраняются в FAISS, Chroma, Pinecone, Qdrant, pgvector или managed-сервис.
  6. Retrieval: вопрос пользователя тоже превращается в вектор, затем находятся ближайшие чанки.
  7. Generation: LLM получает вопрос + найденный контекст и формирует ответ.

Векторная база данных

Обычный поиск по ключевым словам ищет совпадения текста. Векторный поиск ищет близость по смыслу: запрос «питание кошек» может найти фрагменты про «рацион котёнка», даже если слово «питание» там не встречается.

КомпонентРоль в RAG
Embedding modelКодирует текст в вектор. Важно использовать одну и ту же модель для документов и запросов.
Vector storeХранит векторы, текст чанков и метаданные, быстро ищет ближайшие элементы.
RetrieverОборачивает поиск: выбирает k, фильтры, стратегию ранжирования, иногда reranking.
PromptГоворит модели отвечать только по контексту и явно признавать отсутствие данных.

RAG или fine-tuning

RAG и fine-tuning решают разные задачи. RAG подключает знания, которые часто меняются или принадлежат конкретной компании. Fine-tuning меняет поведение модели: стиль, формат ответа, классификацию, устойчивый способ решать типовую задачу.

⚠️ Практическое правило: если нужно добавить документы или свежие знания — начинайте с RAG. Если нужно изменить формат, тон, политику ответа или специализированное поведение — рассматривайте fine-tuning после базовой оценки.

Ограничения и риски

  • Плохой retrieval: если найден не тот контекст, LLM ответит плохо.
  • Плохие чанки: слишком большие фрагменты размывают смысл, слишком маленькие теряют контекст.
  • Нет источников: пользователь не может проверить, откуда взят ответ.
  • Устаревший индекс: документы обновились, а векторная база нет.
  • Indirect prompt injection: найденный документ может содержать инструкции вроде «игнорируй системный промпт».