⁣Corpus drift в RAG-системах: как заметить деградацию retrieval без разметки, labels и явных ошибок

В RAG retrieval часто ломается тихо: модель та же, embedding model тот же, prompt тот же, latency в норме, а ответы стали хуже. Типичная ошибка - сразу крутить prompt или ругать LLM, хотя проблема ниже: изменился корпус.

1. Мониторьте drift самого корпуса

Мы не измеряем качество напрямую, но смотрим, как изменилось пространство, в котором работает retriever:

- распределение embedding-ов чанков;
- средняя длина чанка, overlap, число чанков на документ;
- доля новых, удалённых и изменённых чанков;
- дубликаты и near-duplicates;
- распределение доменов, типов документов, языков, дат;
- плотность embedding-пространства: не стало ли много «слипшихся» чанков.

Если корпус заметно сдвинулся, старые retrieval-пороги и ожидания по top-k могут стать мусором. Особенно если confidence logic завязана на score или gap между top-1 и top-2.

2. Anchor queries вместо labels

В production почти никогда нет labels вида «для этого query релевантны вот эти chunks». Но можно взять стабильный набор production-запросов: например, 500-5000 частых или бизнес-критичных query.

Это не разметка. Мы не знаем правильный chunk. Но знаем, что retrieval-поведение не должно хаотично меняться после каждого обновления корпуса.

Для каждого anchor query сохраняйте baseline:

- top-k doc/chunk ids;
- retrieval scores;
- rank positions;
- gap между top-1 и top-2;
- diversity top-k;
- source distribution.

После обновления корпуса сравнивайте новый retrieval с baseline.

Полезные proxy-метрики:

- Jaccard@k между старым и новым top-k;
- rank churn: сколько документов поменяло позиции;
- score distribution shift;
- падение top-1 score;
- уменьшение score gap;
- рост доли low-confidence retrieval;
- изменение источников в top-k;
- рост почти одинаковых чанков в top-k.

Минимальный набор, который уже даёт сигнал:

- mean_jaccard@10;
- p95_top1_score_drop;
- score_wasserstein между baseline и current scores.

3. Как интерпретировать сигналы

- mean_jaccard@10 резко упал: retriever стал приносить другой контекст;
- top-1 score системно падает: запросы хуже матчятся с корпусом;
- score distribution сильно сдвинулась: старые thresholds и confidence logic могли сломаться.

Практический совет: считайте эти метрики не только глобально, но и по сегментам - источникам, языкам, типам документов, продуктовым доменам. Глобальный average легко скрывает деградацию в критичном сегменте.

4. Retrieval confidence без ground truth

Даже без разметки можно смотреть на «уверенность» ретривера:

- высокий top-1 score;
- большой gap между top-1 и top-2;
- согласованность dense retrieval и BM25;
- стабильность top-k при query rewriting;
- низкая доля дубликатов в top-k;
- покрытие нужных источников.

Если dense и lexical retrieval внезапно начали расходиться, не стоит списывать это на шум. Часто это значит, что корпус или запросы изменились так, что одна из стратегий больше не работает как раньше.

Production minimum для RAG:

- хранить snapshot retrieval-результатов для anchor queries;
- считать overlap, score drift и rank churn после каждого обновления корпуса;
- отдельно мониторить дубликаты, новые чанки и распределения источников;
- заводить alerts не на один query, а на агрегаты по сегментам.

Corpus drift неприятен тем, что не выглядит как авария. Система отвечает, ошибок нет, latency нормальная. Просто контекст стал чуть менее релевантным. Потом ещё чуть менее. И качество RAG медленно проседает.

Вывод:
Без labels нельзя честно измерить relevance, но можно мониторить стабильность retrieval-поведения, уверенность ретривера и изменения корпуса, чтобы поймать деградацию раньше пользователей.