Чем вредят дубликаты

Одинаковый текст занимает top-k несколькими chunks, вытесняет diversity, раздувает индекс и создаёт ложную уверенность: пять результатов могут быть одной копией.

Exact duplicates

Сначала нормализуйте безопасные различия и считайте cryptographic checksum. Хешируйте также исходник: агрессивная canonicalization может ошибочно склеить разные документы.

Near duplicates

Шаблоны, экспорты и версии требуют shingling/MinHash или similarity. Порог калибруется на размеченных парах; embedding similarity сама по себе не доказывает дубликат.

Canonical document

Группа копий получает canonical ID, но хранит все source locations, ACL и версии. Права объединять нельзя: доступ к одной копии не открывает другую.

Chunk-level diversity

После retrieval группируйте соседние chunks и копии, затем расширяйте candidate pool. Дедупликация перед reranker экономит latency.

Метрики

Считайте duplicate rate, unique documents@k, context redundancy, recall и ошибочные merges. После изменения алгоритма пересобирайте clusters версионированно.

Какой первый шаг?
Зафиксировать корпус, реальные запросы и baseline; без версий сравнение невоспроизводимо.
Что измерять?
Retrieval relevance, grounded correctness, p95 latency, стоимость и ошибки по сегментам.
Можно ли доверить оценку одной LLM?
Нет. LLM judge полезен как сигнал, но критические выборки требуют детерминированных проверок и экспертной разметки.
Как обновлять систему?
Через новую версию, offline eval, shadow, canary и заранее подготовленный rollback.
Что делать с чувствительными данными?
Минимизировать, ограничивать доступ, применять ACL до retrieval и задавать retention для traces и eval-наборов.
Как избежать каннибализации экспериментов?
Менять один слой за раз и хранить control, candidate, corpus version и сегментированные результаты.
← Все статьи блога