RAG

Литература¶

Что такое RAG¶

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

📌 RAG vs Fine-Tuning (Дообучение модели)¶

Критерий	RAG	Fine-Tuning
Гибкость	Можно обновлять базу знаний	Требует переобучения модели
Актуальность	Использует свежие данные	Зависит от даты обучения модели
Сложность	Проще внедрить	Требует вычислительных ресурсов

RAG особенно полезен, когда важно сочетание генерации текста с точными данными, например, в чат-ботах для поддержки клиентов или в системах анализа документов. 🚀

1. RAG (Retrieval-Augmented Generation)¶

Как работает?

Сначала ищет информацию в базе знаний (например, в векторной БД).
Затем передаёт найденные документы в LLM для генерации ответа.

Плюсы:
✔ Актуальные данные (можно обновлять базу).
✔ Меньше "галлюцинаций", так как ответы основаны на документах.

Минусы:
❌ Требует хорошей поисковой системы.
❌ Медленнее, чем чистый Fine-Tuning.

Пример: Чат-бот техподдержки, который ищет ответы в FAQ перед генерацией.

2. Fine-Tuning (Дообучение модели)¶

Как работает?

Берётся готовая LLM (например, GPT-3, LLaMA) и дообучается на специфичных данных.

Плюсы:
✔ Может решать узкоспециализированные задачи (медицина, юриспруденция).
✔ Быстрее в работе (не требует поиска).

Минусы:
❌ Требует много данных и вычислительных ресурсов.
❌ Не может использовать свежие данные без переобучения.

Пример: Модель, дообученная на медицинских статьях для диагностики.

## RAG парадигмы

1.  наивный RAG,
2.  продвинутый RAG,
3.  модульный RAG. виды

А. Наивный RAG¶

Наивный RAG представляет собой ранний подход который включает три этапа: индексирование, поиск и генерацию, образуя так называемую архитектуру "Retrieve-Read" («поиск-чтение»).
Индексирование начинается с очистки и извлечения сырых данных из PDF, HTML, Word и Markdown, которые конвертируются в единый текстовый формат. Для преодоления ограничений контекста языковых моделей текст разбивается на чанки. Чанки преобразуются в векторные представления (embedding) с помощью модели эмбеддингов (embedding model) и сохраняются в векторной базе данных (vector database).

Основной алгоритм наивного RAG работы следующий:¶

Вся база знаний «нарезается» на небольшие куски текста, так называемые chunks (чанки по‑русски). Размер этих chunks может варьироваться от нескольких строк, до нескольких абзацев, т. е. примерно 100 до 1000 слов.
Далее эти чанки оцифровываются с помощью «эмбеддера» и превращаются в эмбеддинги или другимими словами в вектора, некоторые наборы чисел. Считается, что в этих числах зашит скрытый смысл всего чанка, и именно по этому смыслу и можно производить поиск.
Далее все эти полученные вектора складываются в специальную базу данных, где лежат и ждут пока над ними и начнут производить ту самую операцию поиска (наиболее релевантных, т. е. близких по смыслу чанков поисковому запросу).
Когда пользователь отправляет свой вопрос в LLM, то текст его запроса точно по такому же алгоритму (как правило тем же самым эмбеддером), кодируется также в еще один эмбеддинг и далее над базой данных содержащей наши эмбеддинги чанков производится поиск наиболее близких «по смыслу» эмбеддингов (векторов). В реальности, как правило, считается косинусная близость вектора запроса и вектора каждого чанка и далее выбираются топ N векторов наиболее близких к запросу.
Далее текст чанков, соответствующий этим найденным векторам, вместе с запросом пользователя объединяется в единый контекст и подается на вход языковой модели. т. е. модель «думает», что пользователь написал ей не только вопрос, но еще и предоставил данные на основе которых нужно ответить на поставленный вопрос.

Технологии для RAG¶

Основные технологии и инструменты для реализации RAG (Retrieval-Augmented Generation) поверх LLM, разбитые по ключевым компонентам системы:

1. Векторные базы данных (Vector Databases)¶

Хранят векторные представления (эмбеддинги) документов и обеспечивают быстрый семантический поиск.
Популярные решения:
- Pinecone: Управляемая облачная БД, оптимизирована для RAG.
- Chroma: Легковесная, open-source, идеальна для прототипирования.
- FAISS (Facebook AI Similarity Search): Библиотека от Meta для эффективного поиска похожих векторов.
- Qdrant: Open-source с поддержкой Rust/Python, облачная версия.
- Milvus / Zilliz: Высокомасштабируемые, для enterprise-решений.
- Weaviate: Open-source с GraphQL-API, поддерживает гибридный поиск (векторы + ключевые слова).
- Elasticsearch / OpenSearch: С плагинами k-NN для векторного поиска.
- Redis: Модуль RediSearch поддерживает векторный поиск.
- PostgreSQL: Расширение pgvector добавляет векторные операции.

2. Фреймворки для оркестрации RAG¶

Упрощают разработку пайплайнов: загрузка данных, чанкинг, эмбеддинг, поиск, интеграция с LLM.
Ключевые фреймворки:
- LangChain: Самый популярный, поддерживает множество БД, LLM, чанкеров. Гибкий, но требует глубокого погружения.
- LlamaIndex: Специализирован на RAG, оптимизирован для эффективного индексирования и запросов к данным.
- Haystack (deepset): Фокус на поисковых системах и QA, интерфейс на Python.

3. Модели для создания эмбеддингов (Embedding Models)¶

Преобразуют текст в векторы. Критичны для качества поиска.
Примеры моделей:
- OpenAI: text-embedding-ada-002 (SOTA для общего использования).
- Hugging Face:
- BAAI/bge-large-en (State-of-the-art для поиска).
- intfloat/multilingual-e5-large (мультиязычные).
- sentence-transformers/all-MiniLM-L6-v2 (легкая модель).
- Cohere: embed-english-v3.0 (с поддержкой инструкций).
- Google: textembedding-gecko (через Vertex AI).

4. LLM (Large Language Models)¶

Генерация ответов на основе найденных контекстов.
Варианты:
- Проприетарные:
- OpenAI GPT-4, GPT-3.5-turbo
- Anthropic Claude 2/3
- Google Gemini
- Cohere Command
- Open-source (для локального/приватного использования):
- Llama 2/3 (Meta)
- Mistral 7B/Mixtral
- Gemma (Google)
- Falcon (TII)

5. Инструменты для чанкинга (Chunking)¶

Разбивка документов на фрагменты для индексации.
Подходы:
- Фиксированный размер (например, 512 токенов).
- Семантический чанкинг (сохлопывание/разделение по смыслу).
- Расширенные методы:
- LangChain: RecursiveCharacterTextSplitter, MarkdownHeaderTextSplitter.
- LlamaIndex: интеллектуальное разбиение с учетом иерархии.
- unstructured.io: Предобработка PDF, Word, HTML и др.

6. Оптимизации и продвинутые техники¶

Query Rewriting / Expansion: Переформулировка запроса для улучшения поиска (e.g., HyDE).
Re-Ranking: Фильтрация результатов поиска (модели типа Cohere Rerank, bge-reranker).
Hybrid Search: Комбинация семантического (векторного) и лексического (ключевые слова) поиска.
Fine-tuning эмбеддинг-моделей: Подстройка под домен данных.
Agents: Динамическое управление пайплайном RAG (например, через LangChain Agents).

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

Данные: PDF/веб-страницы → парсинг с помощью unstructured или PyPDF.
Чанкинг: LangChain (разбивка по заголовкам + рекурсивное разделение).
Эмбеддинги: text-embedding-ada-002 или bge-large-en-v1.5.
Векторная БД: Pinecone (production) / Chroma (prototyping).
Оркестрация: LangChain для интеграции поиска и вызова GPT-4.
Оптимизация: Cohere Rerank для улучшения релевантности чанков.

Мой личный набор¶

langchain - сам фреймворк для построения RAG
openai - библиотечка для работы с API OpenAI
chromadb - для хранения embeddings
tiktoken - библиотека для генерации embeddings, используется другими библиотеками.

Допиливание RAG¶

Размер чанков и их количество.
Чем меньше чанк по размеру, тем точнее будет буквальный поиск, чем больше размер чанка тем больше поиск приближается к смысловому.
Разные запросы пользователя могут содержать разное количество чанков, которое необходимо добавлять в контекст. Необходимо опытным путем подобрать тот самый коэффициент, ниже которого чанк смысла не имеет и будет лишь замусоривать ваш контекст.
Чанки должны перекрывать друг друга, чтобы у вас был шанс подать на вход последовательность чанков, которые следуют друг за другом вместе, а не просто вырванные из контекста куски.
Начало и конец чанка должны быть осмысленными, в идеале должны совпадать с началом и концом предложения, а лучше абзаца, чтобы вся мысль была в чанке целиком.
Добавление других методов поиска. Очень часто поиск «по смыслу» через эмбеддинги не дает нужного результата. Особенно если речь идет о каких‑то специфических терминах или определениях. Как правило к поиску через эмбеддинги подключают также TF‑IDF поиск и объединяют результаты поиска в пропорции, подобранной экспериментальным путем. Также очень часто помогает ранжирование найденных результатов например алгоритмом BM25.
Мультиплицирование запроса. Как правило, запрос от пользователя имеет смысл несколько раз перефразировать (с помощью LLM) и осуществлять поиск чанков по всем вариантам запроса. На практике сделают от 3-х до 5-ти вариаций запросов и потом результаты поиска объединяют в один.
Суммаризация чанков. Если по запросу пользователя найдено очень много информации и вся эта информация не помещается в контекст, то ее можно точно также «упростить» с помощью LLM и подать на вход в виде контекста (в добавление к вопросу пользователя) нечто вроде заархивированного знания, чтобы LLM могла использовать суть (выжимку из базы знаний) при формировании ответа.