Актуальность knowledge base в RAG: ingest, versioning и reindex

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

Freshness в RAG держится на пяти практиках:

1. Source-of-truth ownership
2. Versioned ingestion
3. Update / delete discipline
4. Freshness-aware metadata
5. Reindex и freshness monitoring

Что чаще всего портит retrieval

• новые документы добавляются, а старые не снимаются;
• chunks не связаны с document version;
• policy pages и product docs не имеют effective date;
• retriever не умеет учитывать freshness metadata;
• stale content остаётся в top-k из-за сильного lexical overlap.

Почему `добавить новый документ` недостаточно для quality RAG?

1. Source of truth важнее vector store

Первый вопрос не "какой vector DB лучше", а какой источник знания authoritative.

Типовые варианты:

• docs CMS;
• product handbook;
• policy repository;
• CRM / internal KB;
• database snapshots;
• support macros / SOP documents.

Проблема начинается, когда index становится теневой правдой сам по себе. Тогда команда перестаёт понимать:

• откуда пришёл chunk;
• какая у него версия;
• действителен ли он ещё;
• кто отвечает за его обновление.

2. Versioned ingestion лучше append-only ingestion

Append-only pipeline удобен в начале, но быстро создаёт stale debt.

Нормальный ingest обычно хранит хотя бы:

Это позволяет retrieval-системе понимать не просто "похожий текст", а "похожий и актуальный текст".

3. Update и delete - это часть retrieval quality

В production knowledge base почти никогда не живёт в режиме "один раз загрузили и забыли". Значит, ingest должен уметь:

• upsert changed documents;
• delete obsolete chunks;
• mark deprecated content;
• пересчитывать summaries и metadata;
• переиндексировать affected documents, а не always весь corpus.

Особенно важны deletion и supersession. Иначе stale policies продолжают жить в поиске бесконечно.

4. Freshness metadata должна участвовать в retrieval

Ошибка многих RAG-систем - freshness живёт в metadata, но retriever её не использует.

Полезные паттерны:

• фильтровать status=active;
• понижать score для deprecated и stale документов;
• использовать effective_from / effective_to в ranking;
• в answer path показывать дату источника;
• при конфликте версий предпочитать newest authoritative doc.

Это особенно важно для:

• pricing;
• policy;
• product capabilities;
• legal/compliance docs;
• frequently updated support instructions.

5. Reindex - не всегда full rebuild

Полный rebuild индекса иногда нужен, но чаще useful думать в терминах:

• delta ingest;
• selective re-embedding;
• chunk invalidation;
• background rebuild for large migrations.

Полный reindex дорогой не только по infra, но и по quality risk: пока он идёт, система может жить в mixed state.

Поэтому mature pipeline обычно умеет:

• быстро обновить affected docs;
• отдельно rebuild-ить changed collections;
• хранить old/new index versions для controlled cutover.

6. Как stale knowledge выглядит в product behavior

Признаки проблем со свежестью часто видны не в инфраструктуре, а в ответах:

• модель цитирует старую цену;
• agent советует deprecated workflow;
• support assistant путает старую и новую refund policy;
• retrieval приносит конфликтующие chunks из разных эпох;
• answer выглядит "вроде правдоподобно", но не совпадает с текущим продуктом.

Именно поэтому freshness - это не только ingest metric, но и user-facing quality issue.

7. Что полезно мерить

Практические freshness-метрики:

• ingest lag от source update до searchable state;
• доля retrieval hits по deprecated content;
• share of answers citing stale documents;
• average age of retrieved chunks по маршрутам;
• update failure rate;
• reindex backlog.

Отдельно полезно смотреть conflicting-version retrieval rate: как часто в один ответ попадают chunks из разных версий одного документа.

8. Freshness и answer policy

Даже хороший retrieval layer не всегда может однозначно выбрать одну версию. Поэтому answer policy тоже важна:

• если источники конфликтуют, модель должна уметь сказать об этом явно;
• high-risk domains должны предпочитать abstain over stale certainty;
• citations без даты мало помогают, если контент быстро меняется.

Это особенно полезно там, где "сегодняшняя правда" важнее общей энциклопедичности.

Пример metadata для versioned chunks

{
  "document_id": "refund-policy",
  "version_id": "v12",
  "status": "active",
  "updated_at": "2026-03-28T10:42:00Z",
  "effective_from": "2026-03-29",
  "source_uri": "kb://policies/refund-policy"
}

Минимальный ingest decision

def ingest_document(doc):
    current = load_active_version(doc.document_id)

    if current and current.hash == doc.hash:
        return "skip"

    if current:
        mark_deprecated(current.version_id)
        delete_old_chunks(current.version_id)

    new_version = write_new_version(doc)
    embed_and_upsert(new_version)
    return "updated"

Практический совет: отделяйте document changed от embeddings rebuilt. Это два разных operational события. Тогда проще видеть, где именно накапливается freshness lag: в source sync, chunking, embedding queue или index cutover.