Retrieval Debugging Workflows в 2026: как разбирать плохой RAG не на ощущениях, а по слоям

Короткая версия

Хороший retrieval debugging в 2026 обычно идёт по слоям:

1. Document presence
2. Chunk quality
3. Filter correctness
4. Ranking / reranking
5. Answer grounding

Что особенно важно

• сначала нужно понять, был ли в candidate set правильный материал;
• query rewrite может как помочь, так и скрыть исходную проблему;
• citation failure и retrieval failure не всегда одно и то же;
• debugging полезнее строить как standard workflow, а не heroic investigation.

С чего лучше начинать расследование плохого RAG-ответа: с prompt или с retrieval trace?

1. Первый вопрос: был ли нужный документ вообще достижим

Полезно проверить:

• документ существует в corpus;
• индексирован ли он;
• попадает ли в tenant/domain scope;
• не устарел ли snapshot;
• не удалён ли metadata cleanup.

Если ответ "нет", дальше ranker и prompt уже не виноваты.

2. Второй вопрос: правильный ли chunk видел retriever

Частые проблемы:

• chunk слишком большой и noisy;
• chunk слишком маленький и теряет смысл;
• critical sentence split across chunks;
• heading-only chunk outranks useful content;
• duplicate chunks размывают ranking.

3. Третий вопрос: filters и scoping не убили retrieval

Особенно важно проверить:

• tenant filters;
• locale filters;
• product/version filters;
• time-based constraints;
• policy or access scopes.

Слишком агрессивный filter легко делает retrieval "чистым", но бесполезным.

4. Четвёртый вопрос: ranking и reranking дали правильный порядок

Даже если candidate set нормальный, может ломаться:

• BM25 vs dense recall mix;
• reranker bias toward generic text;
• over-weighting recent but vague docs;
• under-weighting exact snippet;
• query rewrite introducing drift.

Именно здесь top-k looks plausible, but evidence priority wrong.

5. Пятый вопрос: answer layer действительно использовал evidence?

Даже при хорошем retrieval answer может:

• опираться на нерелевантный chunk;
• over-summarize;
• сделать unsupported synthesis;
• потерять citation mapping;
• prefer language prior over retrieved evidence.

То есть debugging должен доходить до claim-to-source use, а не останавливаться на "документы вроде были".

6. Что особенно часто ломают команды

Prompt-first debugging

Сразу крутят synthesis, не проверив retrieval.

No saved retrieval traces

Нельзя воспроизвести конкретный failure.

Mixing retrieval and answer metrics

Команда не знает, где реально живёт баг.

No representative failing queries

Debug строится на случайных примерах.

No standard workflow

Каждое расследование начинается с нуля.

7. Какие метрики полезны

Минимальный retrieval-debug dashboard обычно включает:

• document presence failures;
• chunk-level miss rate;
• filter-related drop rate;
• reranking mismatch rate;
• claim-to-source grounding failure rate;
• mean time to diagnosis by layer.

Пример debug record

{
  "query_id": "q_1921",
  "document_present": true,
  "relevant_chunk_present": false,
  "filter_drop": false,
  "reranking_issue": false,
  "answer_grounding_issue": null,
  "diagnosis": "chunking_problem"
}

Практический checklist

1. Check corpus and document presence first
2. Inspect chunk quality before tweaking prompts
3. Verify filters and scoping explicitly
4. Compare recall and reranking behavior separately
5. Confirm that final answer used the retrieved evidence

Практический совет: хороший retrieval debugging workflow не ищет "почему модель ошиблась". Он ищет, на каком именно слое evidence pipeline перестал быть полезным.