# Knowledge Freshness Engineering CURRENT_STATUS: UNKNOWN OBSERVATION: SPEC_ONLY FRESHNESS: UNKNOWN PAGE_TYPE: reference CANONICAL_URL: /tools/ea-067-knowledge-freshness-engineering CLAIM_IDS: none EVIDENCE_IDS: EVD-EA-067-URL-E0E9622033AF, EVD-EA-067-URL-E8CFEB3458D9, EVD-EA-067-URL-D320C481D01C, EVD-EA-067-URL-7C7C7DBBC222, EVD-EA-067-URL-883737C6EFB0, EVD-EA-067-URL-7BBD2F9AC09C, EVD-EA-067-URL-5C9DF414C214, EA-067-R11-RESEARCH, EA-067-R11-WEB-READBACK UNKNOWN_IDS: EA-067-UNKNOWN-01, EA-067-UNKNOWN-CURRENTNESS OPS_IDS: none ## Summary 「RAGの鮮度は、データソースの更新時刻やインデックス同期成功だけでは判定できない。更新・削除が検出され、検索可能な表現へ反映され、キャッシュや検索結果を経て、最終回答が新しい状態へ追随するまでの各段階を測定する。incremental sync、TTL、CDC、再indexはそのための手段であり、それぞれの製品・connectorが同じ反映保証を持つとは限らない。」 ## Current judgment - 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を保持する。 ## Scope Enterprise AI Core / implementation / provider mapping / benchmark / operability / governance。EA-066 ACL-aware RAG、EA-064 Memory Lifecycleと隣接するが、本Packetはcontent/knowledgeのtemporal freshnessを対象とする。 ## Confirmed - 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を保持する。 ## UNKNOWN - EA-067-UNKNOWN-01: 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が更新時点で再確認できた時点。 --- - EA-067-UNKNOWN-CURRENTNESS: 外部根拠の再確認日がcanonical body/control-planeで確定していないため、currentnessはUNKNOWNとして保持する。日付を推測補完しない。 ## Evidence - EVD-EA-067-URL-E0E9622033AF (RESEARCH): 1) 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 - EVD-EA-067-URL-E8CFEB3458D9 (RESEARCH): 2) official product docs | Azure AI Search — Indexer overview / scheduling | Microsoft | — https://learn.microsoft.com/en-us/azure/search/search-indexer-overview - EVD-EA-067-URL-D320C481D01C (RESEARCH): 3) 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 - EVD-EA-067-URL-7C7C7DBBC222 (RESEARCH): 4) official product docs | Delete documents from a knowledge base | Amazon Web Services | — https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-delete.html - EVD-EA-067-URL-883737C6EFB0 (RESEARCH): 5) reproducible benchmark/preprint artifact | StaleBench: A Benchmark for Answer Freshness in Retrieval-Augmented Generation | Karan Singh | — https://zenodo.org/records/20710012 - EVD-EA-067-URL-7BBD2F9AC09C (RESEARCH): 6) primary preprint | LayerRAG-Bench: A Cross-Layer Reliability Benchmark for Agentic Retrieval-Augmented Generation | Musa Shams | — https://arxiv.org/abs/2607.27353 - EVD-EA-067-URL-5C9DF414C214 (RESEARCH): 7) 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 - EA-067-R11-RESEARCH (RESEARCH): EA-067 監査済みresearch / canonical revision binding - EA-067-R11-WEB-READBACK (IMPL): EA-067 Web body identity / canonical readback ## Failure / limits connectorが「incremental」を称しても全source type・全metadata・ACL・delete eventの完全CDCを意味しない。 ## Failure / limits full re-indexはfreshnessを改善し得るが、処理中のmixed-version window、費用、latency、availabilityを生む。 ## Failure / limits TTLは時間経過による再取得契機であり、source changeを即時検出するCDCではない。 ## Failure / limits cache invalidation成功はindex更新を証明せず、index更新成功はanswer freshnessを証明しない。 ## Failure / limits StaleBench/LayerRAG-Benchはfailure classの存在証拠であり、特定商用tenantのfailure probabilityではない。 ## Practice 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時に再確認する。 ## Practice 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。 ## Practice 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依存を避ける。 ## Practice 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になり得る。 ## Practice future update時にAzure/AWS/Google等のcurrent connector別sync/deletion semanticsとminimum intervalを再確認。 ## Practice EA-066の`revocation-to-enforcement latency`と本EAの`mutation-to-answer latency`を同一Freshness SLO章で並置するが混同しない。 ## Practice KNOWLEDGE FRESHNESS LEDGER採用可否をCoreで判断。 ## Practice high-risk corpusではupdate/delete canaryを定期実行し、job successではなくretrieval/answer layerまで検証する設計を候補化。 ## WHY_THIS_MATTERS_TO_UPDATE RAG/enterprise searchではsourceが更新されても、connector検出、indexer、embedding、vector/keyword index、cache、retrieval、context assemblyの各層が別々の時刻で更新される。したがって「同期成功」「index更新済み」だけでは利用者が最新回答を得ることを保証できない。EA-066のauthorization freshnessとは分離しつつ、同じfreshness SLO体系で扱う必要がある。 ## SCOPE_ROUTING Enterprise AI Core / implementation / provider mapping / benchmark / operability / governance。EA-066 ACL-aware RAG、EA-064 Memory Lifecycleと隣接するが、本Packetはcontent/knowledgeのtemporal freshnessを対象とする。 ## CLAIM_OR_RESEARCH_QUESTION 1. Knowledge freshnessはsource→detect→ingest→index→retrieve→answerのend-to-end propertyとして測定すべきか。 2. update/additionとdeletionは同一同期機構で保証されるか。 3. incremental sync、full sync、TTL/cache invalidation、CDCの各方式はどこまでfreshnessを保証するか。 4. indexが最新でもanswerが古いfailureをどう検出するか。 ## EVIDENCE TABLE 1) 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が必要で、削除反映を自動一般化できない。 2) 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に依存する。 3) 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即時反映とは同義でない。 4) 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に潰せない。 5) 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保証へ外挿しない。 6) 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としては扱わない。 7) 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を直接表現しない。 ## FINDINGS - 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を保持する。 ## LIMITS / COUNTEREVIDENCE / FAILURE ENVELOPE - 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ではない。 ## AVAILABILITY_GATES 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時に再確認する。 ## IMPLEMENTATION_STATE 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。 ## BENCHMARK_OR_EVAL 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依存を避ける。 ## SECURITY / PRIVACY / AUDIT / COST / OPERABILITY 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になり得る。 ## SAFE_WORDING_FOR_FUTURE_BOOK 「RAGの鮮度は、データソースの更新時刻やインデックス同期成功だけでは判定できない。更新・削除が検出され、検索可能な表現へ反映され、キャッシュや検索結果を経て、最終回答が新しい状態へ追随するまでの各段階を測定する。incremental sync、TTL、CDC、再indexはそのための手段であり、それぞれの製品・connectorが同じ反映保証を持つとは限らない。」 ## UPDATE_WORK_HANDOFF 1. future update時にAzure/AWS/Google等のcurrent connector別sync/deletion semanticsとminimum intervalを再確認。 2. EA-066の`revocation-to-enforcement latency`と本EAの`mutation-to-answer latency`を同一Freshness SLO章で並置するが混同しない。 3. KNOWLEDGE FRESHNESS LEDGER採用可否をCoreで判断。 4. high-risk corpusではupdate/delete canaryを定期実行し、job successではなくretrieval/answer layerまで検証する設計を候補化。 ## UNKNOWN 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が更新時点で再確認できた時点。 --- NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.