rag в ии

RAG (Retrieval-Augmented Generation) — это архитектурный подход в области ИИ, при котором языковая модель перед генерацией ответа автоматически извлекает релевантные фрагменты из внешней базы знаний и использует их как контекст. Метод появился как ответ на ключевое ограничение больших языковых моделей: знания модели заморожены на момент обучения и не отражают актуальную информацию.

Как устроен RAG изнутри

Система RAG состоит из двух крупных блоков: retriever (извлекатель) и generator (генератор). Когда пользователь задаёт вопрос, retriever преобразует его в векторное представление и ищет ближайшие по смыслу фрагменты в векторной базе данных. Найденные фрагменты добавляются в промпт вместе с исходным вопросом. Языковая модель получает расширенный контекст и формирует итоговый ответ.

1. Запрос пользователя → embedding-вектор
2. Поиск по векторной БД (Pinecone, Chroma, Weaviate, pgvector)
3. Top-K фрагментов добавляются к промпту
4. LLM генерирует ответ на основе реальных данных

Почему RAG, а не просто fine-tuning

Fine-tuning «запекает» знания в веса модели — это дорого, медленно и не подходит для часто меняющихся данных. RAG, напротив, хранит знания отдельно и обновляет базу знаний без переобучения модели. Кроме того, RAG даёт прозрачность: можно показать пользователю источники, на основе которых сформирован ответ.

На практике оба подхода нередко комбинируют: модель дообучают под стиль и тональность домена, а RAG обеспечивает актуальный фактический контекст.

Типы RAG-архитектур

• Naive RAG — базовый pipeline: индексирование → поиск → генерация без дополнительной логики.
• Advanced RAG — добавляет query rewriting, reranking найденных фрагментов, компрессию контекста.
• Modular RAG — каждый компонент заменяем: можно подключить разные retriever-ы, LLM, стратегии chunking.
• Graph RAG — использует граф знаний для многошагового рассуждения через связанные концепции.

Ключевые технологии стека

Для построения RAG-системы понадобятся: embedding-модель (text-embedding-ada-002, sentence-transformers, E5), векторная база данных, LLM-генератор и оркестрирующий фреймворк. LangChain и LlamaIndex предоставляют готовые компоненты: загрузчики документов, splitter-ы для chunking, интеграции с десятками векторных хранилищ и LLM-провайдеров.

Chunking — разбивка документов на фрагменты — критически важный шаг. Слишком короткие чанки теряют контекст, слишком длинные засоряют промпт нерелевантной информацией. Оптимальный размер зависит от домена, обычно 256–512 токенов с перекрытием.

Типичные проблемы и способы их решения

Качество RAG-системы напрямую зависит от точности retriever-а. Если он возвращает нерелевантные фрагменты, генератор выдаст плохой ответ — принцип «мусор на входе, мусор на выходе». Для улучшения precision применяют гибридный поиск (dense + sparse BM25), cross-encoder reranking и query expansion.

Ещё одна проблема — ограниченное контекстное окно LLM: нельзя передать слишком много фрагментов. Решение — aggressive reranking и компрессия контекста с помощью отдельных моделей.

Практические применения RAG

RAG используют корпоративные чат-боты с доступом к внутренней документации, правовые системы анализа контрактов, медицинские ассистенты с привязкой к клиническим руководствам, образовательные репетиторы на основе учебных материалов. В разработке RAG лежит в основе AI-ассистентов для работы с кодовой базой — GitHub Copilot, Cursor, Cody.

Метрики оценки RAG-систем: faithfulness (насколько ответ соответствует найденным фрагментам), answer relevancy (насколько ответ отвечает на вопрос), context recall (насколько полно retriever нашёл нужное). Фреймворки RAGAS и TruLens автоматизируют эту оценку.

Оценка и мониторинг RAG-системы

Построить RAG — половина дела; важно измерять его качество в production. Метрики faithfulness (верность источникам), answer relevancy (соответствие вопросу) и context recall (полнота извлечения) образуют стандартный набор оценки. Фреймворки RAGAS и TruLens автоматизируют расчёт этих метрик на тестовой выборке. Для обнаружения деградации качества в production применяют онлайн-мониторинг: логируют пары вопрос—ответ и периодически запускают LLM-as-a-judge оценку. Важно также отслеживать latency retriever-а и генератора отдельно, чтобы локализовать узкие места при масштабировании системы.