Ch31: Wiki 自维护——库健康、矛盾检测与 eval 闭环
Part 8 收束 · 前置：Ch30 向量库 · 后续：Ch32 大师通关 延伸：Ch42 图谱与增量 · Ch47 评估
结论先行：WeKnora 不只「问得到」，还试图 库健康——过期、矛盾、覆盖缺口。Wiki/inspector 与 Ch20 Benchmark 形成 数据驱动改进环：低分 query → 聚类 → 补文档 → re-embed → eval 复跑。
一、日常类比
RAG 像城市图书馆：检索是「帮读者找书」，Wiki 自维护是 馆藏编目员——标记过期地图、发现两本书对同一事实说法矛盾、统计「很多人问但库里没有」的主题。
二、三种巡检
| 类型 | 输入 | 输出 | 关联挑战 |
|---|---|---|---|
| 过期 | 文档时间、版本元数据 | 待更新列表 | #13 实时更新 |
| 矛盾 | 实体/事实冲突 | 冲突对，需人工确认 | #10 Memory vs RAG |
| 覆盖缺口 | 低 Rerank 分 query 日志 | 建议补文档主题 | #1 最后一公里 |
Memory 冲突（#10）：用户口头说已迁 PostgreSQL，库内仍写 MySQL——Wiki 可 标记 但不自动裁决，见 Ch46。
三、与 EventManager 增量链
文档更新理想路径：
DocumentUpdated → 删旧 chunk/向量 → 重 parse/chunk/embed
→ 增量 PMI 重算（Ch42）
→ Wiki 矛盾 re-scan
当前实现：图谱增量相对领先，chunk/向量级联需加强（竞赛贡献点）。
rg -n "Wiki|Inspector|contradict|stale" internal/ -g '*.go'
rg -n "DocumentUpdated|document.*update" internal/ -g '*.go'
四、eval + Wiki 闭环（大师工作流）
1. 跑 benchmark/smoke-10.jsonl 得 baseline
2. 改检索/解析/chunk 代码
3. 复跑 smoke-10，PR 附四指标表
4. 把仍失败的 query 类型写入 Wiki 缺口 backlog
5. 补 corpus（lab/corpus/）→ ingest → 再 eval
#1248 点踩数据（若产品化）可 feed 缺口检测——与 case-1774 三层 API 模式同构。
五、动手
- 上传 faq-version-conflict.md 两版「向量库个数」
- 问「支持几个向量库」— 观察是否两版都召回
- 设计 metadata：
source_credibility/doc_version如何进 Rerank（Ch38）
章末自检
- 区分「检索质量差」与「库内容不健康」
- 画出 eval → 缺口 → 补文档 → re-index 环
- 说 Wiki 对 #10 Memory 冲突能做什么、不能做什么