RAG для тех, кто разочаровался: почему retrieval ломается и как это починить

Страницы:  1

Ответить
 

Professor Seleznov


Вы собрали RAG-пайплайн: загрузили документы, нарезали на чанки, сгенерировали эмбеддинги, подключили векторную базу. Задаёте вопрос — модель отвечает уверенно и подробно. Показываете заказчику, тот в восторге. Потом начинается тестирование на реальных вопросах, и оказывается, что на половину из них система отвечает мимо: то находит не тот документ, то находит правильный, но не тот кусок, то вообще ничего релевантного не достаёт и модель уверенно галлюцинирует.
Каждый раз проблема не в модели (GPT-4 и Claude отвечают хорошо, если им дать правильный контекст), а в retrieval — в том, как мы ищем релевантные куски документов. Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули.
Рассмотрим три основные причины.
Проблема 1: чанки нарезаны бездумно
Стандартный подход — нарезать документ на куски по 500-1000 символов с перекрытием.
Представьте договор на 30 страниц. Пункт 7.3 про ответственность начинается на одной странице и заканчивается на другой. При нарезке по 500 символов пункт разрезается пополам: первая половина в одном чанке, вторая в другом. Пользователь спрашивает «какая ответственность по договору», retrieval находит первую половину (там есть слово «ответственность»), но не находит вторую (там уже про суммы и сроки). Модель отвечает неполно, а пользователь думает, что система не работает.
Другой пример: таблица с тарифами. При нарезке по символам заголовок таблицы попадает в один чанк, а данные в другой. Чанк с данными без заголовка бессмысленен: числа без контекста.
Первое, что стоит сделать — перейти от «нарезки по символам» к «нарезке по смыслу»:
from langchain.text_splitter import RecursiveCharacterTextSplitter
# Стандартный подход — работает, но грубо
basic_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
)
# Лучше: разделители по приоритету
# Сначала пробуем разрезать по двойному переносу строки (между параграфами),
# потом по одинарному, потом по предложению, потом по символам
smart_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000,
chunk_overlap=200,
separators=["\n\n", "\n", ". ", " ", ""],
)
RecursiveCharacterTextSplitter пробует разделители по порядку: сначала ищет двойной перенос (граница параграфа), если чанк получается слишком большой — ищет одинарный перенос, потом точку с пробелом (конец предложения). Идея в том, чтобы разрезать в естественных точках текста, а не посередине слова.
Но для структурированных документов (договоры, регламенты, технические спецификации) этого мало. Лучше нарезать по структуре документа: каждый раздел или пункт — отдельный чанк.
import re
def split_by_sections(text: str, max_chunk_size: int = 2000) -> list[dict]:
"""Нарезка по заголовкам разделов (markdown-стиль)."""
sections = re.split(r'\n(#{1,3}\s+.+)\n', text)
chunks = []
current_header = ""
for i, section in enumerate(sections):
if re.match(r'^#{1,3}\s+', section):
current_header = section.strip()
continue
content = section.strip()
if not content:
continue
# Если секция слишком большая — разбиваем дальше
if len(content) > max_chunk_size:
sub_chunks = smart_splitter.split_text(content)
for j, sub in enumerate(sub_chunks):
chunks.append({
"text": f"{current_header}\n\n{sub}",
"metadata": {
"section": current_header,
"part": j + 1,
}
})
else:
chunks.append({
"text": f"{current_header}\n\n{content}",
"metadata": {"section": current_header}
})
return chunks
Каждый чанк содержит заголовок раздела + текст. Даже если чанк найден по содержанию, модель видит заголовок и понимает контекст. Для таблиц аналогично: заголовок таблицы добавляется к каждому чанку с данными из неё.
Проблема 2: семантический поиск не находит то, что нужно
Cosine similarity между эмбеддингами запроса и чанка — стандартный способ поиска в RAG. Но он ломается в нескольких конкретных случаях.
Пользователь спрашивает «штрафы за просрочку», а в документе написано «неустойка за нарушение сроков». Семантически это одно и то же, но эмбеддинги могут быть далеко друг от друга, потому что слова разные. Особенно если эмбеддинг-модель не обучена на юридических текстах.
Другой случай: пользователь спрашивает «что нужно для оформления возврата», а модель находит чанк про «политику возврата товаров», который описывает общие принципы, а не конкретные шаги. Семантически похоже, но ответ бесполезен.
Первое улучшение видится в гибридном поиске. Кроме семантического (по эмбеддингам), добавляем keyword-поиск (BM25):
from rank_bm25 import BM25Okapi
import numpy as np
class HybridRetriever:
def __init__(self, chunks: list[dict], embeddings_model):
self.chunks = chunks
self.texts = [c["text"] for c in chunks]
# BM25 для keyword search
tokenized = [text.lower().split() for text in self.texts]
self.bm25 = BM25Okapi(tokenized)
# Эмбеддинги для semantic search
self.embeddings = embeddings_model.encode(self.texts)
self.model = embeddings_model
def search(self, query: str, top_k: int = 5, alpha: float = 0.5) -> list[dict]:
# BM25 scores
bm25_scores = self.bm25.get_scores(query.lower().split())
bm25_norm = bm25_scores / (bm25_scores.max() + 1e-6)
# Semantic scores
query_emb = self.model.encode(query)
cos_scores = np.dot(self.embeddings, query_emb) / (
np.linalg.norm(self.embeddings, axis=1) * np.linalg.norm(query_emb) + 1e-6
)
cos_norm = (cos_scores - cos_scores.min()) / (cos_scores.max() - cos_scores.min() + 1e-6)
# Комбинируем: alpha * semantic + (1-alpha) * keyword
combined = alpha * cos_norm + (1 - alpha) * bm25_norm
top_indices = np.argsort(combined)[::-1][:top_k]
return [self.chunks for i in top_indices]
alpha регулирует баланс между семантическим и keyword-поиском. При alpha=1.0 это чистый semantic, при alpha=0.0 — чистый BM25. На практике alpha=0.5-0.7 работает лучше обоих по отдельности, потому что BM25 ловит точные совпадения терминов (штраф -> штраф), а semantic ловит синонимы (штраф -> неустойка).
Второе улучшение — reranking. Первый этап (retrieval) быстрый, но грубый: находит 20 кандидатов. Второй этап (reranking) медленный, но точный: пропускает 20 кандидатов через cross-encoder и переранжирует:
from sentence_transformers import CrossEncoder
reranker = CrossEncoder("cross-encoder/ms-marco-MiniLM-L-6-v2")
def search_with_rerank(query: str, retriever: HybridRetriever, top_k: int = 5):
# Грубый поиск: 20 кандидатов
candidates = retriever.search(query, top_k=20)
# Reranking: cross-encoder оценивает пару (query, candidate)
pairs = [(query, c["text"]) for c in candidates]
scores = reranker.predict(pairs)
# Сортируем по score от reranker
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [c for c, s in ranked[:top_k]]
Cross-encoder работает иначе, чем bi-encoder (обычные эмбеддинги). Bi-encoder кодирует запрос и документ отдельно и сравнивает векторы. Cross-encoder получает пару (запрос, документ) целиком и оценивает релевантность напрямую. Это точнее, но медленнее, поэтому cross-encoder используют для reranking 20 кандидатов, а не для поиска по миллиону документов.
Гибридный поиск + reranking сильно бустит качество retrieval.
Проблема 3: вы не измеряете качество retrieval
Большинство RAG-проектов оценивают качество так: разработчик задаёт 5 вопросов, смотрит на ответы и говорит «вроде нормально». Потом приходят реальные пользователи с реальными вопросами, и оказывается, что на половину система отвечает мимо.
Нужен evaluation dataset: набор вопросов с ожидаемыми чанками (или ожидаемыми ответами). 50-100 вопросов достаточно для начала.
eval_dataset = [
{
"question": "Какая неустойка за просрочку поставки?",
"expected_chunk_id": "contract_7_3", # ID чанка с пунктом 7.3
},
{
"question": "Какой срок оплаты по договору?",
"expected_chunk_id": "contract_4_1",
},
# ... ещё 48–98 вопросов
]
def evaluate_retrieval(retriever, eval_dataset, top_k=5):
hits = 0
for item in eval_dataset:
results = retriever.search(item["question"], top_k=top_k)
result_ids = [r["metadata"].get("chunk_id") for r in results]
if item["expected_chunk_id"] in result_ids:
hits += 1
recall = hits / len(eval_dataset)
return recall
# Базовый retrieval
recall_basic = evaluate_retrieval(basic_retriever, eval_dataset)
print(f"Basic retrieval recall@5: {recall_basic:.2%}")
# После улучшений (гибридный + reranking)
recall_improved = evaluate_retrieval(improved_retriever, eval_dataset)
print(f"Improved retrieval recall@5: {recall_improved:.2%}")
Без eval dataset вы не знаете, стало лучше или хуже после изменений. Поменяли размер чанка с 500 на 1000 — recall вырос или упал? Добавили reranking — помогло или нет? Без чисел это гадание.
Создание eval dataset-а — ручная работа. Берёте реальные вопросы от пользователей (или придумываете), находите правильный чанк для каждого, записываете. 50 вопросов — час работы. Зато потом каждое изменение в пайплайне можно оценить за минуту.
Что ещё влияет на качество
Размер чанка. Маленькие чанки (200-500 символов) дают точный retrieval, но модель получает мало контекста. Большие чанки (2000-3000) дают больше контекста, но retrieval менее точный (в большом чанке много шума). Золотой середины нет: для FAQ 300-500 нормально, для юридических документов 1000-2000, для технической документации 500-1000. Подбирайте под свои данные и измеряйте через eval dataset.
Эмбеддинг-модель. По умолчанию все берут OpenAI text-embedding-3-small или sentence-transformers all-MiniLM-L6-v2. Для русскоязычных документов multilingual-e5-large или BGE-M3 обычно работают лучше, потому что обучены на русском тексте. Замена модели эмбеддингов может дать +10-20% recall без изменения остального пайплайна.
Промпт для модели. Даже с идеальным retrieval модель может отвечать плохо, если промпт не объясняет, что делать с контекстом. «Ответь на вопрос на основе контекста» — слабо. «Ответь на вопрос на основе предоставленного контекста. Если в контексте нет информации для ответа, скажи об этом. Не додумывай. Ссылайся на конкретные пункты документа» — сильнее. Инструкция «не додумывай» снижает галлюцинации, а «ссылайся на пункты» делает ответ проверяемым.
Когда RAG не подходит
RAG хорош для вопросов по существующим документам: «что написано в договоре», «как настроить сервис по инструкции», «какая процедура возврата». RAG плох для задач, требующих рассуждения поверх данных: «сравни два договора и скажи, какой выгоднее», «проанализируй тренд в данных за квартал». Для таких задач нужны агенты с инструментами, а не retrieval.
RAG также плох, когда документов мало (меньше 10 страниц). Если весь контекст влезает в окно модели целиком, retrieval не нужен: загружайте документ полностью и спрашивайте. RAG окупается, когда данных сотни и тысячи страниц, и загрузить всё в контекст невозможно.
Retrieval — самое слабое звено в RAG-пайплайне. Модель отвечает ровно настолько хорошо, насколько хороший контекст ей подали. Нарезка по смыслу, гибридный поиск, reranking и eval dataset — четыре вещи, которые превращают демо-RAG в рабочий. Каждую из них можно внедрить за день, и каждая даёт измеримое улучшение.
Если у вас есть свои подходы к RAG, пишите в комментариях. Спасибо, что дочитали.-Если хочется чуть шире посмотреть на тему LLM, RAG и ИИ-агентов, приходите на открытые уроки OTUS. Там без обещаний «собрать идеального агента за вечер», но с разбором, что сейчас реально работает, где начинаются ограничения и как всё это применять в разработке.
  • 27 мая, 20:00. «Мифы про ИИ-агентов: что реально работает в 2026 году». Записаться
  • 15 июня, 20:00. «Интеграция ИИ-агентов в рабочую разработку: обвязка агента навыками и MCP». Записаться
Подписывайтесь на канал OTUS в Max, чтобы оставаться в курсе всех бесплатных мероприятий.-Источник
 
Loading...
Error