Аудит и оптимизация RAG-систем
Ваша RAG-система работает, но ответы неточные, документы не находятся, качество падает со временем? Проводим аудит существующей RAG-системы: диагностика retrieval, чанкование, reranking, метрики RAGAS — и собираем план оптимизации под ваши данные. Всё в закрытом контуре.
- Диагностика retrieval quality и recall
- Аудит чанкования, эмбеддингов, векторного хранилища
- RAGAS-метрики: faithfulness, context precision
- План оптимизации с приоритетами и сроками
Что входит в аудит
Проверяем каждый слой RAG-конвейера и находим узкие места
Диагностика retrieval
Анализируем recall и precision поиска: какие документы находятся, какие пропущены. Тестируем retrieval на вашем наборе вопросов, сравниваем dense vs BM25 vs гибридный поиск. Измеряем влияние топ-K и fusion-стратегии.
Аудит чанкования
Фиксированный чанк — причина 60% провалов RAG. Проверяем текущую стратегию, тестируем семантическое и рекурсивное чанкование, подбираем оптимальный размер и overlap для ваших типов документов: PDF, DOCX, таблицы, регламенты.
Проверка reranking
Топ-K векторов без переранжирования снижает точность ответа на 25–35%. Проверяем, используется ли cross-encoder (bge-reranker-v2, jina-reranker-v3), оцениваем прирост качества после внедрения reranking.
RAGAS-оценка качества
Запускаем RAGAS-метрики на вашем наборе тестовых вопросов: faithfulness (нет ли вымысла), answer relevancy (ответ на вопрос), context precision (релевантность найденных документов), context recall (найдены ли все нужные документы). Целевые значения: faithfulness ≥ 0.85, context recall ≥ 0.75.
Анализ эмбеддингов
Проверяем модель эмбеддингов, совместимость query/document моделей, version drift. Сравниваем text-embedding-3-large, BGE-M3, jina-embeddings-v3. Проверяем, нет ли смешения векторов от разных моделей в одном collection.
Безопасность RAG
Проверяем RAG-систему на prompt-инъекции, RAG-poisoning (отравление векторного индекса), утечку данных через LLM. Проверяем guardrails на вход и выход. Интеграция с OWASP LLM Top 10 и Agentic Top 10.
Как проходит аудит
-
01
Сбор информации и доступов
Получаем доступ к вашей RAG-системе: векторное хранилище, инференс-сервер, источники документов, текущие настройки. Собираем бизнес-требования: какие вопросы задают пользователи, какие ответы считаются корректными.
-
02
Диагностика retrieval
Запускаем тестовый набор вопросов, измеряем recall@K, precision@K, MRR. Сравниваем текущую стратегию поиска с гибридным (dense + BM25 + RRF). Фиксируем, какие документы находятся, какие пропущены, почему.
-
03
RAGAS-оценка и бенчмарк
Создаём eval-набор из 50–200 вопросов (или используем ваш). Запускаем RAGAS: faithfulness, answer relevancy, context precision, context recall. Сравниваем с целевыми значениями для production. Формируем baseline.
-
04
План оптимизации
На основе диагностики составляем план: что менять в первую очередь (чанкование, гибридный поиск, reranking), что во вторую, что можно оставить. Для каждого пункта — ожидаемый прирост метрик, оценка трудозатрат, приоритет.
-
05
Пилот доработки
Внедряем ключевые оптимизации в ваш контур: меняем чанкование, настраиваем гибридный поиск, подключаем reranker. Перезапускаем RAGAS — видим прирост в цифрах. Передаём документацию и настройки.
Что мы измеряем
Ключевые метрики RAG-системы и целевые значения для production
| Метрика | Что показывает | Цель для production |
|---|---|---|
| Faithfulness | Насколько ответ основан на retrieved context, нет ли галлюцинаций | ≥ 0.85 |
| Answer Relevancy | Насколько ответ отвечает на исходный вопрос | ≥ 0.80 |
| Context Precision | Насколько релевантны найденные документы среди всех retrieved | ≥ 0.80 |
| Context Recall | Найдены ли все нужные документы из ground truth | ≥ 0.75 |
| Retrieval Recall@K | Доля релевантных документов среди топ-K найденных | ≥ 0.70 при K=10 |
| Latency P95 | Время от запроса до ответа (95-й перцентиль) | < 3 сек |
Почему RAG-система деградирует
RAG-система, запущенная в пилоте, не остаётся статичной. Документы обновляются и устаревают, новые типы документов не индексируются, модель эмбеддингов может быть заменена без редубликации индекса, данные растут без пересборки векторного индекса. Без мониторинга и регулярной RAGAS-оценки качество падает незаметно — пользователи перестают доверять системе. Аудит — не разовое событие, а регулярная процедура.
Типовые проблемы, которые мы находим
80% RAG-пилотов не выходят в продакшен из-за этих ошибок
Фиксированный чанк без семантики
Разбиение по 512 символам рвёт таблицы, ссылки и логические разделы. Семантическое чанкование с overlap 10–20% и размером 256–512 токенов — стандарт для production.
Только dense-поиск без BM25
Векторный поиск пропускает точные термины и редкие названия. Гибридный поиск (dense + BM25 + RRF) улучшает recall на 10–30%. Без BM25 вы теряете документы с точными совпадениями.
Нет reranking после retrieval
Топ-K векторов без cross-encoder переранжирования снижает точность ответа на 25–35%. bge-reranker-v2 или jina-reranker-v3 — обязательный слой перед генерацией ответа.
Нет eval-набора и метрик
Без RAGAS и тестовых вопросов нельзя оценить, работает ли система. Вы не знаете, отвечает ли система бизнес-требованиям. Закладываем метрики с первого дня.
Vector drift и stale embeddings
Документы обновляются, но векторы не пересчитываются. Старые эмбеддинги не отражают актуальное содержание. Нужна инкрементальная индексация и регулярная пересборка индекса.
Смешение моделей эмбеддингов
Разные документы эмбеддированы разными моделями или разными версиями одной модели. Векторы из разных моделей несовместимы — поиск даёт шум. Всегда храним metadata с версией модели.
Техническая глубина аудита
Как устроен наш аудит
Мы не просто запускаем метрики — мы декомпозируем RAG-систему на слои и проверяем каждый:
Слой 1: Индексация и чанкование. Проверяем, как документы попадают в векторное хранилище. Фиксированный чанк (512 символов) — самая частая причина провалов. Переходим к семантическому чанкованию: RecursiveCharacterTextSplitter с separators ["\n\n", "\n", "## ", "### ", ". "] и overlap 200 токенов. Для таблиц и форматов с жёсткой структурой — отдельная стратегия: парсинг через tabular-экстракторы, а не текстовый чанк.
Слой 2: Эмбеддинги. Проверяем модель и её версию. text-embedding-3-large, BGE-M3, jina-embeddings-v3 — каждая модель по-разному понимает русский язык и технические термины. Важно: query и document модели должны быть совместимы, и все векторы в collection — одной версии. Храним metadata: embedding_model, embedding_version, source, created_at.
Слой 3: Retrieval. Тестируем три стратегии: dense-only (векторный), BM25-only (keyword), hybrid (dense + BM25 + RRF). RRF (Reciprocal Rank Fusion) — стандартный метод фузии результатов. Измеряем recall@K, precision@K, MRR (Mean Reciprocal Rank) для каждой стратегии. Для сложных документов применяем HyDE (Hypothetical Document Embedding) — генерируем гипотетический ответ, эмбеддируем его и ищем по нему.
Слой 4: Reranking. После первоначального retrieval (top-20) применяем cross-encoder reranker: bge-reranker-v2 или jina-reranker-v3. Cross-encoder сравнивает query и document совместно, а не по отдельности — это даёт значительно более точную сортировку. Финальный top-5 подаётся в LLM.
Слой 5: Guardrails и безопасность. Проверяем RAG-систему на prompt-инъекции: можно ли через пользовательский запрос заставить модель выдать скрытые документы. Проверяем RAG-poisoning: что будет, если в векторный индекс попадёт вредоносный контент. Проверяем PII-фильтры на вход и выход.
Слой 6: Мониторинг и observability. Настраиваем RAGAS-оценку в CI/CD: каждый релиз чанкования или модели эмбеддингов проходит через eval-набор. Prometheus + Grafana для latency, throughput. Langfuse для трейсинга каждого запроса: что было retrieved, что сгенерировано, сколько стоило.
Инструменты и стек
- RAGAS — основной фреймворк оценки. 4 метрики: faithfulness, answer relevancy, context precision, context recall.
- DeepEval — альтернатива для CI/CD gates и автоматических тестов.
- Phoenix (Arize AI) — визуализация и мониторинг retrieval в реальном времени.
- Langfuse — трейсинг каждого шага RAG-пайплайна.
- Qdrant client — диагностика коллекций, анализ payload, проверка метаданных.
- Cross-encoders — bge-reranker-v2, jina-reranker-v3 для финального переранжирования.
Когда RAG не нужно оптимизировать
Если ваша система ещё не запущена — лучше сразу настроить правильно. Если задача решается классическим поиском (Elasticsearch по полнотекстовому индексу) — RAG избыточен. Если в базе 10 документов и 5 вопросов в день — хватит простого поиска. Мы честно скажем, если RAG-оптимизация не нужна.
Нужен аудит вашей RAG-системы?
Опишите текущую архитектуру, типы документов и проблемы с ответами — предложим план аудита и оценки.