跳转至

Ingestion Quality Demo：入库清洗质量分析

这个 Demo 验证什么

本 Demo 验证私域上下文库最早的一道风险：原始材料进入 D3 检索投影、embedding 或 MCP 上下文工具之前，清洗、摘要、chunk 和 metadata 是否会丢掉关键事实。

它不调用模型 API，也不依赖真实 D3 检索投影引擎。当前用 8 条 synthetic 混合样例模拟企业微信群聊、会议纪要、Markdown、JSON 和表格材料，对比两条入库路径：

  • naive summary：只保留第一行或短摘要，模拟过早摘要化。
  • structured ingestion：先写 Evidence source snapshot 和 sha256，再产出正式 ContextDocumentRecord，保留 raw_source_id、source_hash、source_uri、权限字段、review 状态、全文 body、PII/mask 元数据和 chunks。

本轮新增的 Evidence Registry 位于本 Demo 之前：它负责保存 source snapshot、hash、临时外链状态、PII/field mask 和下游制品引用；本 Demo 负责验证这些 source 进入 ContextDocumentRecord 时不会丢事实。

运行命令：

python scripts/ingestion_quality_demo.py --write-report

输出文件：

workspaces/variai/outputs/ingestion-quality-documents.json
workspaces/variai/outputs/ingestion-quality-analysis.md
workspaces/variai/outputs/ingestion-quality-evidence-registry.json
workspaces/variai/outputs/ingestion-quality-evidence-snapshots/

当前样例结果

基于 8 条 synthetic 本地样例、43 个预期事实：

指标 naive summary structured ingestion
样例数 8 8
预期事实数 43 43
事实召回率 19% 100%
额外保留事实数 - 35
原文追溯通过率 - 100%
权限字段保留通过率 - 100%
review 状态通过率 - 100%

结论很直接：后续不能只把群聊、会议和业务系统记录摘要进检索投影。摘要可以作为展示字段，但不能替代原文、结构化字段、chunk、权限元数据和审计追溯。

暴露出的风险

  • 只做摘要会系统性丢失付款期限、负责人、权限提示、状态字段和表格关系。
  • JSON 和表格现在仍主要被保留成文本 chunk；字段类型、父子关系、行列关系还需要进一步结构化。
  • 当前 schema 已保留 pii_flags 和 field_mask 字段，但还没有做 PII、客户名、合同号、财务字段等敏感信息自动识别。
  • 当前 review 状态是规则推断，真实系统需要人工确认、来源可信度、有效期和过期处理。
  • 当前事实匹配是确定性字符串匹配，还没有验证 paraphrase、别名、错别字和跨 chunk 事实组合。

对架构的影响

当前已新增正式 context_document schema：framework/context/document_schema.py，并提供样例 fixture workspaces/variai/knowledge/system/context-document-schema-samples.json 和 lint：

python scripts/context_document_schema_lint.py

当前也新增 Evidence source registry：workspaces/variai/evidence/registry/evidence-registry.json 和 lint；本 Demo 自身也会生成一份可校验的 Evidence registry：

python scripts/evidence_registry_lint.py
python scripts/evidence_registry_lint.py --registry workspaces/variai/outputs/ingestion-quality-evidence-registry.json

ingestion_quality_demo 的输出已经迁移到 Evidence source -> ContextDocumentRecord 链路，并在 workspaces/variai/outputs/ingestion-quality-documents.json 中保留 search_projection，用于后续接入 SearchConnector。第一版 context_document 至少需要保留：

document_id
raw_source_id
source_type
source_uri
source_hash
title
summary
body
chunks
permission_scope
review_status
source_system
object_type
lifecycle
created_at
updated_at
owner
pii_flags
field_mask

其中 summary 只能作为辅助字段，不能作为唯一入库内容。OpenSearch/ES、Postgres FTS/pgvector 或 MCP evidence 都需要能从 chunk 回到 raw source，并在进入 prompt 前完成权限过滤。

下一步

  1. 把 Connector Callback Ledger 的有效回调按同一 contract 写成 Evidence source，再投影到 ContextDocument 或 Ontology artifact。
  2. 给 JSON 和表格增加结构化字段映射，不只保留文本。
  3. 增加 PII 检测、客户名/合同号/财务字段识别和自动 field_mask 建议。
  4. 把本实验输出接入 retrieval_platform_benchmark 和 context_layer_benchmark，验证清洗后的文档在 OpenSearch/ES 与 Postgres+pgvector/FTS 中是否真的能被搜到，并能被正确分层使用。
  5. 接入 permission_leak_test，验证 restricted / task_only 材料不会泄露内容、owner、路径或存在性。
  6. 增加人工 review、pending/task-only 过期策略和 schema lint 治理规则，避免临时材料长期污染知识库。

详细风险序列见：风险驱动验证计划。