用 DeepMetier 搭建企业知识库：从文档到可问答的图谱
知识库不是把文件堆进一个目录，而是把文件里的实体与关系抽出来，编成一张可以被查询的图。本文给出从解析、建模、对齐到问答与溯源的完整路径，并说明它和普通向量检索的区别。
核心结论
- 一句话结论：知识库的价值不在于把文件集中存放，而在于把文件里的实体、属性与关系抽出来，变成一张可查询、可推理的图。
- 四步路径：解析（结构化切块并保留坐标）→ 建模（定义本体）→ 对齐（同物异名归一）→ 问答（图谱查询 + 原文引用）。
- 关键差别：向量检索找「哪段文字和问题最像」，图谱推理找「哪些实体和问题有关」；需要跨文档拼接的问题，只有后者能答对。
- 抗幻觉靠溯源：每条结论都要带来源文档、页码与字段路径；证据不足时必须明确说「不知道」，而不是给一个像样的答案。
- 验收标准：用 100 条真实问题做基线，长期跟踪覆盖率、答对率、可溯源率，并对答错的题逐条归因。
一、为什么「文件夹式知识库」一定会失败
多数企业第一次做知识库，做法都差不多：把共享盘与邮件里的文件收拢进一个目录，按部门建文件夹，再套一个对话入口。上线两周，使用率通常断崖式下跌。
原因不在模型，而在组织方式。文件夹是给人用的记忆索引，不是给机器用的语义索引。人靠「我记得它放在哪」找文件，机器靠「涉及哪些实体、它们什么关系」答题。
「文件夹式知识库」必然出现三个症状：
- 同物异名：同一客户在合同里是全称、发票里是简称、CRM 里是编码，检索只命中一份。
- 答案要拼接：「供应商近三年有无逾期交付」要看合同、验收单与邮件，片段检索只返回三段无关文字。
- 错无法定位：没有可追溯的数据链路，没人说得清错在哪一步。
所以文件只是原料：把实体与关系编成可查询的图，才是知识库的产品本体。
二、四步建设路径：解析、建模、对齐、问答
四步顺序不建议颠倒，每一步的产物就是下一步的输入。
第一步：解析
把 PDF、Word、Excel 与扫描件拆成结构化块。要点是保留上下文坐标：这段来自哪份文件第几页、属哪个章节、在表格第几行——没有坐标的切块，后面无法溯源。
第二步：建模
定义本体：有哪些实体类型、每种实体有哪些属性、实体之间允许哪些关系。它决定了知识库能回答哪类问题，属于设计决策。
第三步：对齐
把不同来源里指同一对象的记录归一到同一节点。别名表、编码映射与规则匹配一起用，对齐质量直接决定跨系统问题能不能答。
第四步：问答
问题先被翻译成图查询，再回原文取证据片段。图给事实骨架，原文给可核对的措辞，这条双通道是抗幻觉的基础。
三、本体设计示例：五个实体就够起步
以「供应商与合同管理」为例，一个最小本体包含 5 个实体类型。别一上来画全公司的大图，先覆盖一个高频问题域，跑通再扩。
| 实体 | 主要属性 | 关系 |
|---|---|---|
| 供应商 | 名称、统一社会信用代码、行业、评级、状态 | 签署合同；拥有联系人 |
| 合同 | 编号、金额、币种、签署日期、到期日、付款条款 | 归属供应商；涉及产品；产生验收单 |
| 验收单 | 编号、验收日期、验收结论、数量 | 关联合同；关联项目 |
| 联系人 | 姓名、角色、电话、邮箱 | 隶属于供应商 |
| 项目 | 名称、负责人、预算、周期 | 使用合同；归属部门 |
三列分别是实体、属性与关系。两个约束常被忽略：属性用可计算类型（日期、金额、枚举），别都存成自由文本；关系只留一个方向，两个方向都建会让聚合查询重复计数。
四、检索增强与图谱推理的差别
一句话概括：向量检索找「哪段文字和问题最像」，图谱推理找「哪些实体和问题有关」。
| 对比维度 | 向量检索 | 图谱推理 |
|---|---|---|
| 索引单位 | 文本块 | 实体与关系边 |
| 擅长问题 | 定义、条款、段落大意 | 多跳关系、聚合统计、条件筛选 |
| 典型失败 | 需跨三份文档拼接的问题 | 没有结构化字段的自由描述 |
| 可解释性 | 相关性靠猜 | 查询路径每步可核对 |
更稳的组合是「图谱优先、向量兜底」：能直接答的走图谱，开放式描述走向量，两条结果交叉校验；冲突时以结构化事实为准并显式标注。业务问题的落点通常是数字、时间与条件，这恰好是向量最不擅长精确保留的部分。
五、数据溯源如何压制幻觉
幻觉不是模型故意编，而是缺少约束时它用最可能的词填了空白。压制它的手段是给每一步加约束。
- 答案挂证据：每个结论附来源文档、页码与字段路径，点开能看原文。
- 无证据则弃答：查询为空或相似度低于阈值时，直接说「现有资料不足以判断」并列出该补什么。
- 数字只认字段：金额、日期、数量必须来自实体属性，不许模型复述。
- 冲突显式化：同一属性多来源取值不一致时并列展示，标注来源与时间。
最容易被跳过的是第二条。一个肯说「不知道」的知识库，比永远有答案的可信得多——否则省下的时间会被核验成本吃回去。
六、落地节奏与验收标准
建议 6 周一个周期：第 1–2 周选一个高频问题域，把 200–500 份核心文档解析入库；第 3–4 周做本体与实体对齐，人工抽检 100 个实体；第 5–6 周接入问答并做基线评测。
验收别用「感觉挺好用」这种口径。固定一批真实问题做基线，跟踪三个指标：
- 覆盖率：这类问题有多少能在库内找到依据，目标 85% 以上。
- 答对率：按人工标注判定，首期 70%，三个月后 85%。
- 可溯源率：答案带有效证据链接的比例，应接近 100%。
再把答错的题逐条归因：没解析出来、没建模、没对齐，还是没命中。归因表比总分有用，它告诉你下周该改哪一步。
常见问题
支持哪些文档格式？
常见办公格式都可以直接解析：PDF（含扫描件 OCR）、Word（docx）、Excel（xlsx）、PowerPoint（pptx）、纯文本与 Markdown，以及网页片段。版式复杂的表格会保留行列结构与表头，扫描件则保留页码与图块坐标，便于后续溯源。老旧格式（doc、xls）建议先批量转成新格式，解析质量会稳定很多。
需要先把数据整理干净吗？
不需要把全公司数据一次性洗干净，但需要先圈定一个高频问题域。做法是选 200 至 500 份核心文档入库，先把这一块的对齐质量做到可用，再逐域扩展。有两个前置动作值得先做：确定实体命名的主口径，以及标注哪些字段必须以结构化方式入库（金额、日期、编号）。
它和向量数据库是什么关系？
两者解决不同问题，通常是互补关系。向量库索引的是文本块，擅长找语义相近的段落；图谱索引的是实体与关系，擅长多跳查询、聚合统计和条件筛选。DeepMetier 的做法是图谱优先、向量兜底：能用实体关系直接回答的走图谱，开放式描述再走向量检索，最后合并结果并交叉校验。
文档更新后要重建整个库吗？
不需要。解析后的每个内容块都带文件指纹与坐标，更新时只重新解析发生变化的文件，并只重算受影响实体的属性与关系边。配套建议做三个动作：增量解析、实体级更新、定期一致性巡检，用巡检报告找出属性冲突与孤立节点。
能回答跨系统的问题吗？
可以，前提是先完成实体对齐。跨系统问题的典型形态，是把 ERP 的订单、CRM 的客户、OA 的审批记录关联到同一个主体上。对齐之后，一次图谱查询就能取到多系统的字段；对尚未接入的系统，还可以通过 MCP 工具在查询时实时取数，再并入答案。