ナレッジ・フレッシュネス・エンジニアリング

RAG/enterprise searchではsourceが更新されても、connector検出、indexer、embedding、vector/keyword index、cache、retrieval、context assemblyの各層が別々の時刻で更新される。したがって「同期成功」「index更新済み」だけでは利用者が最新回答を得ることを保証できない。EA-066のauthorization freshnessとは分離しつつ、同じfreshness SLO体系で扱う必要がある。

Enterprise AI Core / implementation / provider mapping / benchmark / operability / governance。EA-066 ACL-aware RAG、EA-064 Memory Lifecycleと隣接するが、本Packetはcontent/knowledgeのtemporal freshnessを対象とする。

• Knowledge freshnessはsource→detect→ingest→index→retrieve→answerのend-to-end propertyとして測定すべきか。
• update/additionとdeletionは同一同期機構で保証されるか。
• incremental sync、full sync、TTL/cache invalidation、CDCの各方式はどこまでfreshnessを保証するか。
• indexが最新でもanswerが古いfailureをどう検出するか。

• official product docs | Azure AI Search — Indexers: change and deletion detection | Microsoft | https://learn.microsoft.com/en-us/azure/search/search-how-to-index-changed-deleted-blobs | accessed 2026-09-15 | current web docs | locator: change detection / soft delete policy / deletion detection limitations | VERIFIED_SPEC + PRODUCT_VOLATILE | support/limit. Indexerはchanged/new contentを追跡できるが、削除検出にはdata-source-specific policy/configurationが必要で、削除反映を自動一般化できない。
• official product docs | Azure AI Search — Indexer overview / scheduling | Microsoft | https://learn.microsoft.com/en-us/azure/search/search-indexer-overview | accessed 2026-09-15 | current web docs | locator: scheduled indexer execution; incremental indexing | VERIFIED_SPEC + PRODUCT_VOLATILE | support/context. scheduled/incremental indexingが存在する一方、freshnessはschedule、change detection、processing timeに依存する。
• official product docs | Sync your data with your Amazon Bedrock knowledge base | Amazon Web Services | https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-ingest.html | accessed 2026-09-15 | current Bedrock docs | locator: StartIngestionJob; sync adds/modifies/deletes; incremental sync for supported sources | VERIFIED_SPEC + PRODUCT_VOLATILE | support/limit. Knowledge Baseのsyncは追加・変更・削除を取り込むが、同期実行と完了を経るためsource mutation即時反映とは同義でない。
• official product docs | Delete documents from a knowledge base | Amazon Web Services | https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-delete.html | accessed 2026-09-15 | current Bedrock docs | locator: direct ingestion DeleteKnowledgeBaseDocuments; sync caveats | VERIFIED_SPEC + PRODUCT_VOLATILE | support/context. deletionは独立operation/ingestion経路としても扱われ、更新と削除を同一claimに潰せない。
• reproducible benchmark/preprint artifact | StaleBench: A Benchmark for Answer Freshness in Retrieval-Augmented Generation | Karan Singh | https://zenodo.org/records/20710012 | 2026-06; accessed 2026-09-15 | current record | locator: catch-up latency/recovery rate; immediate re-indexing experiment across 10 open models | RESEARCH | counter/limit. 即時re-indexでも古い回答が残る例を報告し、index freshness≠answer freshnessを示す。ただしopen-model controlled benchmarkでありenterprise provider保証へ外挿しない。
• primary preprint | LayerRAG-Bench: A Cross-Layer Reliability Benchmark for Agentic Retrieval-Augmented Generation | Musa Shams | https://arxiv.org/abs/2607.27353 | 2026-07-29; accessed 2026-09-15 | arXiv 2607.27353 | locator: stale evidence scenario; groundedness false positives | RESEARCH | counter/context. stale evidenceはgroundedness-only評価で見逃され得る。特定providerのfailure rateとしては扱わない。
• primary preprint | Risk-Constrained Freshness-Aware Semantic Caching for Open-Web Retrieval-Augmented LLMs | Muhammad Mansoor, Tahir Ahmad, Yeo-Chan Yoon | https://arxiv.org/abs/2607.04281 | 2026-07-05; accessed 2026-09-15 | arXiv 2607.04281 | locator: FreshCache-Bench; time-varying staleness; cache error budgets | RESEARCH | support/context. semantic cacheはfreshnessを別リスクとして扱う必要があり、固定TTLだけではanswer-affecting changeを直接表現しない。

• VERIFIED_SPEC/INFERENCE: freshnessは少なくとも source mutation time、change-detection time、ingestion start/end、index-visible time、retrieval-visible time、answer-correct time に分解する。単一last_sync timestampでは不足する。
• VERIFIED_SPEC: incremental indexing/syncは主要providerで実装されるが、方式・対象source・delete semantics・scheduleはprovider/data sourceごとに異なる。存在claimと利用可能条件を分離する。
• VERIFIED_SPEC/INFERENCE: deletion freshnessはupdate freshnessとは別SLOにする。soft-delete marker、hard delete、tombstone、connector deletion detection、vector-store direct deletionのどれを採るかで残存windowが変わる。
• RESEARCH: indexが最新でもgenerator/context ordering/cache等によりstale answerが残る可能性がある。よってend-to-end answer freshnessを別測定する。
• PROPOSAL: KNOWLEDGE FRESHNESS LEDGERをCore候補とする。source_object_id, source_version/etag, source_modified_at, mutation_type(add/update/delete), detected_at, ingest_job_id/start/end, indexed_at, retrievable_at, cache_invalidated_at, first_correct_answer_at, stale_window, delete_window, evidence_locatorを保持する。

• connectorが「incremental」を称しても全source type・全metadata・ACL・delete eventの完全CDCを意味しない。
• full re-indexはfreshnessを改善し得るが、処理中のmixed-version window、費用、latency、availabilityを生む。
• TTLは時間経過による再取得契機であり、source changeを即時検出するCDCではない。
• cache invalidation成功はindex更新を証明せず、index更新成功はanswer freshnessを証明しない。
• StaleBench/LayerRAG-Benchはfailure classの存在証拠であり、特定商用tenantのfailure probabilityではない。

provider / connector type / source API capability / change token・timestamp・soft-delete fieldの有無 / scheduler minimum interval / direct-ingestion API / vector store / region / plan / permissions。PRODUCT_VOLATILEとしてfuture update時に再確認する。

Azure AI Search: scheduled indexers、change detection、data-source-specific deletion detectionを実装。AWS Bedrock Knowledge Bases: ingestion/syncおよびdirect document deletion経路を実装。provider横断で同一freshness contractが存在することはUNKNOWN。

TEST_PROFILE（未実施）: synthetic corpusにK=v1を投入しbaseline確認→sourceをv2へ更新→t0からsource/index/retrieval/answerをpoll→同documentをdelete→同様に残存をpoll。T_detect, T_ingest, T_index_visible, T_retrieval_fresh, T_answer_fresh, T_delete_retrieval, T_delete_answerを個別記録。cache ON/OFF、incremental/full、conflicting v1/v2 coexistenceを分ける。正解判定は可能な限りexact controlled factを使いLLM judge依存を避ける。

AUDIT: mutation→sync job→index version→query evidenceを相関可能にする。OPERABILITY: freshness SLO違反をjob successとは別alertにする。COST: refresh頻度を上げるほどconnector/API/embedding/indexing/cache miss costが増えるため、data class別SLOが必要。SECURITY: EA-066のACL revocation freshnessとcontent freshnessを別metricで測る。削除済み機密情報のstale retrievalはsecurity/privacy incidentになり得る。

「RAGの鮮度は、データソースの更新時刻やインデックス同期成功だけでは判定できない。更新・削除が検出され、検索可能な表現へ反映され、キャッシュや検索結果を経て、最終回答が新しい状態へ追随するまでの各段階を測定する。incremental sync、TTL、CDC、再indexはそのための手段であり、それぞれの製品・connectorが同じ反映保証を持つとは限らない。」

• future update時にAzure/AWS/Google等のcurrent connector別sync/deletion semanticsとminimum intervalを再確認。
• EA-066のrevocation-to-enforcement latencyと本EAのmutation-to-answer latencyを同一Freshness SLO章で並置するが混同しない。
• KNOWLEDGE FRESHNESS LEDGER採用可否をCoreで判断。
• high-risk corpusではupdate/delete canaryを定期実行し、job successではなくretrieval/answer layerまで検証する設計を候補化。

provider横断で標準化されたend-to-end freshness metadata/schema、各managed connectorの実tenantでのp95/p99 propagation latency、hard-delete後の全cache/derived artifact残存window。STOP_CONDITION: update/add/delete各mutationについてsource→answerまでのdocumented semanticsとsafe synthetic measurementが揃い、provider/connector別availability gateが更新時点で再確認できた時点。

---