## Before 一次知识召回治理通常靠临时分析串起来：先从某个商品域 session 表里取 Top123 知识 ID，再去旧 Base 或本地 FAQ 文件反查标签和标准问；遇到没有命中的知识，再用 `query_recall_multitable.csv` 的答案文本兜底。最后人工判断哪些记录更新、哪些新增，再手写批量导入 Base 的 JSON，并用 1 行 dry-run 验证。 风险是每次口径都要重建：Top1/Top2/Top3 是否合并去重、纯数字知识 ID 属于哪个桶、标准问为空时怎么补、Base 已有记录如何 upsert，都可能在临时脚本里漂移。 ## After ```bash python data-analysis-workspace/tools/knowledge_recall_governance.py \ --sessions data/一级分类打标/domain_label_2026_04_product_sessions_v2.csv \ --recall-detail data/query_recall_multitable.csv \ --base-export data/base/knowledge_master_export.csv \ --sources-config data-analysis-workspace/config/knowledge_recall_sources.yaml \ --topn 123 \ --out data-analysis-workspace/adhoc/knowledge_governance_2026-05-28 ``` 流水线输出： | 产物 | 用途 | |---|---| | `top_knowledge_ids.csv` | TopN 知识 ID、调用次数、session 去重口径 | | `coverage_curve.csv/png` | Top10/20/50/100/500/1000 覆盖率 | | `source_match_report.csv` | 每个知识 ID 命中的历史源、字段完整度、兜底原因 | | `upsert_plan.csv` | 已有更新、新增缺失、未匹配历史库明细 | | `base_payload_dryrun.json` | 1 行 dry-run 请求体 | | `blocking_issues.csv` | 标准问为空、schema 不匹配、重复 ID 等阻断项 | 验收信号： - `validate` 显示唯一知识数、当前母表已有数、本次更新数、本次新增数，与 upsert 明细一致。 - TopN 覆盖率表可复现，例如 Top100/Top500/Top1000 覆盖率稳定生成。 - 标准问为空的记录有明确 reason：历史库未命中、召回明细无标准问、需人工补齐。 - Base dry-run 返回成功后才允许 `--apply` 分批写入。