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

这个 Demo 验证什么

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

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

• naive summary：只保留第一行或短摘要，模拟过早摘要化。
• structured ingestion：保留 raw_source_id、source_hash、source_uri、权限字段、review 状态、全文 body 和 chunks。

运行命令：

bash python scripts/ingestion_quality_demo.py --write-report

输出文件：

text vault/50-outputs/ingestion-quality-documents.json vault/50-outputs/ingestion-quality-analysis.md

当前样例结果

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

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

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

暴露出的风险

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

对架构的影响

第一版 context_document 至少需要保留：

text document_id raw_source_id source_type source_uri source_hash title summary body chunks permission_scope review_status source_excerpt

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

下一步

1. 定义正式 context_document schema，把 JSON / 表格字段映射成可查询结构。
2. 增加 field_mask、PII 检测、客户名/合同号/财务字段识别。
3. 把本实验输出接入 retrieval_platform_benchmark，验证清洗后的文档在 OpenSearch/ES 与 Postgres+pgvector/FTS 中是否真的能被搜到。
4. 接入 permission_leak_test，验证 restricted / task_only 材料不会泄露内容、owner、路径或存在性。
5. 增加人工 review 和过期策略，避免 pending 或 task-only 卡片长期污染知识库。

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