Оценка качества Knowledge RAG

У Knowledge RAG три места, где можно промахнуться:

1. Retrieval failure — нужный чанк не попал в top-k.
2. Generation failure — чанк есть, но модель неверно его пересказала или добавила то, чего в чанке нет.
3. Coverage failure — ответ есть в ваших документах, но загрузили не те, либо документ распался на бесполезные чанки.

Оценка качества — это поймать все три. Эта страница — прагматичный workflow без PhD, под имеющиеся в AACSearch данные и инструменты.

Как выглядит «хорошо»

Сделайте маленький набор (10–30) репрезентативных вопросов на каждый Knowledge space. Для каждого:

• Ожидаемый ответ (короткий, фактический).
• Ожидаемый документ-источник — файл(ы), где ответ есть.
• Ожидаемое поведение при промахе — «не знаю» или партиальный ответ?

Это ваш eval-сет. Самый ценный артефакт в любом RAG-проекте и единственный честный способ ловить drift. Перепрогоняйте после каждой смены ingest-конфига.

Три метрики, которые можно гонять уже сегодня

1. Source recall

Для каждого вопроса прогон knowledge.ask, проверяем, есть ли ожидаемый документ в result.sources.

const result = await orpc.knowledge.ask.call({ spaceId, question: eval.question, topK: 5 });
const recallHit = result.sources.some((src) => src.id === eval.expectedDocumentId);

• Source recall @ 5 — доля eval-сета, где нужный документ в top-5.
• Цель: 0.85+. Ниже 0.7 → проблема в retrieval, не в генерации.

При низком recall не тюньте промпт ответа — он работает только с тем, что ему дали. Сначала чините retrieval.

2. Faithfulness

Вопрос: «использует ли ответ только информацию из цитированных чанков?»

Ручная проверка: скопируйте result.chunks в заметки, прочтите абзац ответа и подчеркните то, чего нет в чанках. Подчёркнутое — галлюцинация.

Полу-автомат: повторно прогоните LLM с чанками и ответом, попросите подсветить неподтверждённые предложения. Это автоматизируют фреймворки вроде RAGAS; принцип тот же.

3. Answer accuracy

Самая трудная и единственная, что отражает удовлетворённость пользователя. Каждый ответ:

Среднее по сету. Трекайте после каждого изменения (chunk size, top-k, модель).

Диагностика частых провалов

Что мониторить

Knowledge-модуль пишет события в SearchUsageEvent с eventType = "knowledge_ask". В Analytics dashboard:

• Volume — knowledge_ask/день, в разрезе spaces.
• Token spend — сумма tokensInput / tokensOutput за период.
• Refusal rate — доля ответов с шаблонами «не знаю» / «в документах нет». Скачок — обычно ingest упал.
• Latency — p50 / p95 / p99 по knowledge_ask.

Соедините это с ручными eval-баллами — drift ловится рано.

Как улучшать, по порядку

Когда eval говорит «плохо», работайте список по порядку — каждая следующая ступень в 10× дороже предыдущей:

1. Аудит eval-сета. Ответы реально есть в загруженных документах? Половина проблем — контент, не RAG.
2. Re-ingest с правильной стратегией чанкинга. Markdown для Markdown, semantic для прозы, code для кода.
3. Тюнинг chunk size и overlap. Старт: chunkSize: 400, overlap: 50; замерьте recall до/после.
4. topK 5 → 8/10. Дёшево; обычно улучшает recall.
5. Сменить embedding-модель. text-embedding-3-small → -large. 2× стоимость и dim, нужен re-ingest.
6. GraphRAG для многодокументных вопросов. См. GraphRAG use cases.
7. Метадата-фильтры (Beta) — сузить retrieval по тегам / источнику / дате.
8. Per-tenant fine-tuning (Roadmap, Enterprise).

Privacy и PII в eval-сетах

Eval-сеты часто содержат PII, потому что реальные пользовательские вопросы их содержат. Храните eval-стор отдельно от оцениваемого space; не ingest-те eval-вопросы — они не должны всплывать в ответах.

Если PII в eval неизбежен — редактируйте до коммита в VCS: любая DPA / SOC 2 evidence требует относить eval-стор к scope персональных данных.

Когда «достаточно»

30-вопросный eval с устойчивым source-recall ≥ 0.85 и accuracy ≥ 1.5 (из 2) — достаточно, чтобы катить в контролируемую аудиторию. Ниже — стоимость плохих ответов (зря потраченное время пользователей, эскалации в поддержку, потерянное доверие) обычно перевешивает ценность AI-слоя.

Если планка не берётся — самый чистый фоллбек — отрисовать passages как список (без LLM-выжимки) и дать прочитать. Это по сути semantic search; см. AI Search → Semantic search.

Связанные страницы

• Обзор Knowledge RAG
• Sources — фикс retrieval начинается с re-ingest
• GraphRAG use cases — когда граф бьёт вектор
• Обзор Analytics