Вы собрали 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[i] 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, чтобы оставаться в курсе всех бесплатных мероприятий.