RAG и извлечение знаний

RAG (Retrieval-Augmented Generation) в настоящее время является одной из наиболее распространённых архитектур развёртывания LLM.

Основная идея RAG такова:при ответе на вопросы позволить LLM сначала извлечь релевантный контент из внешней базы знаний, а затем сгенерировать ответ на основе результатов поиска, вместо того чтобы полагаться только на знания, запомненные во время обучения модели.

Это решает две ключевые болевые точки LLM: отсечение знаний (модель не знает о событиях, произошедших после обучения) и галлюцинации (модель выдумывает ответы, когда не уверена).

Основные принципы RAG

Полноценная система RAG состоит из двух конвейеров:офлайн-конвейер индексации(предварительно обрабатывает документы и сохраняет их в векторной базе данных) ионлайн-конвейер запросов(принимает вопросы пользователя, выполняет поиск и генерирует ответ).

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

На онлайн-этапе вопрос пользователя также преобразуется в вектор, из базы данных находятся наиболее похожие фрагменты документов, объединяются в контекст и передаются в LLM для генерации ответа.

На рисунке ниже показан полный поток запроса RAG:

Basic RAG Flowchart RAG complete request flow: user questions are converted into query vectors via the Embedding model, similar document chunks are retrieved in the vector database, the question and retrieval results are concatenated into a Prompt, and input to the LLM to generate the final answer. User question Embedding Convert to query vector Vector database Similarity retrieval Top-K Prompt concatenation Question + document chunks LLM generation Answer based on retrieval results Offline indexing (one-time preprocessing) Original documents Chunking / cleaning Embedding Convert to document vectors Write Vector database Online query flow (every request goes through)

Предварительная обработка данных и разбиение документов на фрагменты

Предварительная проблема: сложный парсинг документов

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

Сейчас основной отраслевой подход заключается во внедрениидвижков парсинга документов(таких как LlamaParse, Unstructured) или мультимодальных больших моделей, преобразующих сложные изображения и текст в структурированный Markdown и закладывающих основу для последующего высококачественного разбиения на фрагменты.

Стратегии разбиения документов на фрагменты

Разбиение документов на фрагменты — основа эффективности RAG; гранулярность фрагментов напрямую влияет на качество поиска. Слишком большие фрагменты вносят шум, а слишком маленькие теряют контекст. Типичные стратегии приведены ниже:

Стратегия разбиения на фрагменты Применимые сценарии Преимущества Недостатки
Чанкинг фиксированного размера Общий текст Простой в реализации, быстрый Может разрезать семантически завершённые предложения
Рекурсивный чанкинг по символам Структурированный текст (Markdown, код) Предпочитает разбиение по семантическим границам, таким как абзацы и предложения Немного сложнее в реализации; требует настройки разумного списка разделителей
Семантический чанкинг Длинные документы, книги Использует Embedding для вычисления схожести между соседними предложениями и автоматически находит семантические точки поворота для чанкинга Высокие вычислительные затраты, медленная предобработка
Извлечение родительских и дочерних документов
(от малого к большому)		 Сценарии всестороннего охвата Использует «малые фрагменты» для высокоточного векторного поиска, а при попадании возвращает LLM соответствующий «крупный фрагмент» (родительский документ), балансируя точность поиска и полноту контекста. Затраты на проектирование и поддержку базы данных удваиваются

На практике при разбиении на фрагменты обычно добавляютперекрытие, то есть соседние фрагменты имеют несколько общих символов, чтобы важная информация не обрезалась на границах. Типичная конфигурация: размер фрагмента 512 токенов, перекрытие 50~100 токенов.

Пример: рекурсивное разбиение на фрагменты с LangChain

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,        # Максимальное количество токенов на фрагмент
    chunk_overlap=50,      # Количество токенов перекрытия между соседними фрагментами для предотвращения потери информации на границах
    separators=["\n\n", "\n", "。", ".", " ", ""]  # Приоритетно разделять по абзацам и предложениям
)

chunks = splitter.split_text(document_text)
print(f"Разбито на {len(chunks)} фрагментов документа")

Векторный поиск

Модели эмбеддингов

Модели эмбеддингов преобразуют текст в плотные векторы (обычно 768- или 1536-мерные массивы чисел с плавающей запятой). Семантически похожие тексты находятся ближе в векторном пространстве, что является математической основой поиска по сходству.

Сравнение распространённых моделей эмбеддингов:

Модель Размерность Поддерживаемые языки Особенности
text-embedding-3-small（OpenAI） 1536 Многоязычный Высокая экономическая эффективность, подходит для крупномасштабного индексирования
text-embedding-3-large（OpenAI） 3072 Многоязычный Наивысшая точность, более высокая стоимость
BAAI/bge-m3 1024 Китайский и английский Открытый исходный код, отличная производительность на китайском, поддерживает несколько языков
sentence-transformers/all-MiniLM-L6-v2 384 Английский Малый размер, высокая скорость, подходит для предельно лёгкого локального развёртывания

Вычисление сходства и алгоритмы ANN

В основе поиска лежит измерение расстояния. Наиболее часто используетсякосинусное сходство, которое вычисляет косинус угла между двумя векторами, диапазон — [-1, 1]; чем ближе к 1, тем более похожи векторы. Кроме того, существуют скалярное произведение и евклидово расстояние (L2-расстояние).

Чтобы достичь поиска на уровне миллисекунд среди миллионов векторов, базы данных обычно используюталгоритмы приближённого поиска ближайших соседей (ANN)(такие какHNSW, IVF). HNSW в настоящее время — самый распространённый алгоритм. Он строит многослойную сеть skip graph, жертвуя очень малой точностью в обмен на улучшение скорости поиска на порядок.

Продвинутый RAG (усовершенствованная архитектура)

Базовая архитектура (Naive RAG) часто сталкивается с такими проблемами, как неточный поиск и «переполнение контекста», вызванное избыточной информацией. Продвинутый RAG решает их с помощьюпредпоисковой оптимизации → слияния результатов поиска → постпоисковой оптимизациис помощью трёхэтапной архитектуры для их решения.

1. Предпоисковый этап: оптимизация запроса

Исходные вопросы пользователей часто бывают неточными:

  • Переписывание запроса: используйте LLM, чтобы переписать разговорные запросы в стандартизированные термины поиска.
  • HyDE（эмбеддинг гипотетического документа）: Пусть LLM сначала «вслепую угадает» гипотетический ответ. Поскольку сгенерированный ответ обычно содержит больше отраслевой терминологии, чем исходный вопрос, использование вектора этого гипотетического ответа для поиска часто позволяет найти документы более высокого качества.

2. Гибридный поиск

будетВекторный поиск(понимает семантику, высокая отказоустойчивость) ипоиск по ключевым словамРезультаты объединяются по весам. Это особенно важно при встрече с именами собственными, моделями продуктов и фрагментами кода, потому что традиционный векторный поиск склонен к «сбоям» на конкретных именах собственных.

3. Оптимизация после поиска: переранжирование

Этогрубое ранжирование → точное ранжированиедвухэтапная схема. Хотя векторный поиск быстр, его оценка недостаточно точна. Переранжирование вводитмодель Cross-Encoder(например, `bge-reranker`), которая подаёт пары «вопрос» и «документ» в модель для совместного вывода и оценки. Оно вычислительно затратно и отвечает только за отбор из Top-20 до Top-5.

Пример: псевдокод конвейера переранжирования

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("BAAI/bge-reranker-v2-m3")

# 1. Грубое ранжирование: векторный поиск быстро извлекает Top-50
candidates = vector_store.similarity_search(query, k=50)

# 2. Точное ранжирование: построить пары [вопрос, документ] для точной оценки
pairs = [[query, doc.page_content] for doc in candidates]
scores = reranker.predict(pairs)

# 3. Отфильтровать итоговый Top-5 для передачи в LLM
ranked_docs = sorted(zip(scores, candidates), reverse=True)
final_docs = [doc for _, doc in ranked_docs[:5]]

4. Self-RAG и CRAG (Corrective RAG)

Добавляется механизм саморефлексии. Например, CRAG (Corrective RAG) после получения результатов поиска сначала заставляет LLM выступить в роли «судьи», чтобы оценить их. Если в локальной базе знаний нет подходящего документа или качество крайне низкое, система автоматически запускает Web Search (например, Google API) в качестве дополнения, что значительно снижает галлюцинации.

GraphRAG: интеграция графа знаний + поиска

Традиционный RAG рассматривает базу знаний как независимые текстовые фрагменты и не может отвечать на вопросы вроде «найти все компании, основанные нынешним CEO и с рыночной стоимостью, превышающей 100 миллиардов», которые требуютмеждокументного, многошагового рассуждениясложных проблем.GraphRAGВведение графа знаний для явного моделирования сущностей и связей.

GraphRAG architecture diagram GraphRAG fuses vector retrieval with the knowledge graph: the user question triggers both vector retrieval and graph retrieval, and the results of the two paths are fused and fed into the LLM to generate an answer. User question Vector retrieval Relevant document chunks Graph retrieval Entity-relationship subgraph Context fusion Document chunks + graph paths Entity A → Relationship → Entity B Entity B → Relationship → Entity C

Основные шаги GraphRAG

  1. Построение знаний: На офлайн-этапе используйте LLM для извлечения триплетов (субъект, отношение, объект) из документов и записи их в графовые базы данных, такие как Neo4j.
  2. Двухпутевой поиск: Для сущностей в запросе выполняется не только традиционный векторный поиск, но также запускается обход графа в графе знаний для извлечения многошаговых цепочек отношений.
  3. Генерация с объединением графа и текста: Соберите «чанки», полученные при векторном поиске, и «структуры путей», полученные при графовом поиске, в промпт, давая LLM как глобальное представление, так и конкретные детали.

Ссылка на материалы GraphRAG:https://www.example.com/ai-agent/graphrag-usage.html

Рекомендации по выбору технологий и баз данных

Выбор базы данных/инструмента Type Рекомендуемые сценарии реализации
Pinecone / Zilliz Cloud Полностью управляемый облачный сервис Готовое к использованию решение, не требует обслуживания инфраструктуры. В сочетании с Cohere Rerank + GPT-4o это самое быстрое коммерческое решение.
Qdrant Открытый исходный код + управляемый сервис Написан на Rust, отличное управление памятью, чрезвычайно высокая производительность. Подходит для приватного развёртывания корпоративного уровня.
Weaviate / Elasticsearch Открытый исходный код + управляемый сервис Обладает чрезвычайно зрелым гибридным поиском (BM25 + векторный поиск, Hybrid Search) и является лучшим выбором для сценариев с большим количеством имён собственных.
Milvus Распределённое решение с открытым исходным кодом Подходит для поисковых платформ предприятий сверхбольшого масштаба на уровне от миллиарда до десяти миллиардов.
Chroma / FAISS Локальная библиотека/встроенное решение Чрезвычайно лёгкий, не требует развёртывания отдельного сервиса. Отлично подходит для локальной разработки и проверки проектов личной базы знаний.

Метрики оценки RAG (фреймворк RAGAS)

Оценка RAG-системы не может основываться только на интуиции; в основном она используетRAGAS— фреймворк для автоматизированного количественного тестирования по двум измерениям: "поиск" и "генерация":

  • Полнота контекста: Какая доля информации в эталонном ответе может быть извлечена.
  • Точность контекста: Какая доля извлечённых документов действительно релевантна.
  • Достоверность (метрика достоверности/галлюцинаций): Все ли сгенерированные ответы подтверждаются извлечёнными документами.
  • Релевантность ответа: Действительно ли сгенерированный ответ отвечает на вопрос пользователя, избегая нерелевантных ответов.
Другие расширения