文档图谱
文档图谱是从营销政策、客服文档、活动方案、培训材料等非结构化文档中抽取业务规则，并把这些规则挂回产品、客户、地域、渠道、有效期等业务对象的知识图谱形态。
简介
文档图谱解决的是企业知识中最难治理的一类问题：大量价值很高但格式不统一、颗粒度不一致、跨系统分散的业务文档。与产品主数据不同，文档类知识往往没有天然字段骨架。一篇营销活动文档可能同时包含多个产品、多个地域、多段时间、不同客群、办理渠道、权益内容、互斥限制和例外条件；一份客服口径可能只在某个地市、某个套餐档位、某个有效期内成立。如果这些内容只被切成文本片段放进向量库，问答时可能偶尔能找到相关段落，但很难稳定做资格判断、冲突检查和规则复用。
文档图谱的关键不是“给每篇文档单独画一张图”，而是把文档中隐藏的规则、条件和限制抽出来，挂回企业已有的业务对象。也就是说，文档只是规则的来源，真正进入系统的应该是“某活动在某时间对某地域某客群适用、与某合约互斥、依附于某产品、证据来自某文档切片”这类可计算、可审核、可追溯的结构化知识。
它与 企业级知识图谱 是局部与整体的关系。企业级知识图谱通常同时包含产品主数据图谱和文档图谱：前者补齐产品、套餐、权益等结构化骨架，后者把业务规则、营销政策和客服口径挂到骨架上。没有文档图谱，企业图谱容易只剩“产品名—套餐—权益”的静态结构；有了文档图谱，图谱才具备处理真实业务限制、时效、互斥和证据链的能力。
关键信息
- 类型：概念 / 知识治理方法
- 领域：企业 AI、知识图谱、RAG、智能客服、运营商知识治理、业务规则治理
- 官方网站/地址：不适用
- 定价/开源状态：不适用，通常作为企业知识图谱项目中的子模块
- 相关概念：企业级知识图谱、RAG 知识库、证据链验证、知识准入治理、规则挂接、文档切片
核心特性
定义
文档图谱是将非结构化或半结构化文档中的实体、关系、条件、规则、限制、时效和证据来源抽取出来，并绑定到业务对象上的图谱系统。它的目标不是保存文档摘要，而是让文档中的业务规则可以被查询、校验、推理和调用。
核心组成
- 文档准入判断：不是所有文档都按同一种方式入库。营销政策、客服文档、采访纪要、活动方案、培训材料的治理方式不同，必须先判断文档类型、业务对象和字段要求。
- 类型化抽取字段：活动类文档至少抽活动时间、适用地域、适用客群、适用产品、办理渠道、活动规则、权益内容、互斥规则；权益包类文档则重点抽权益内容、资费、有效期、领取方式、生效规则、变更规则、退订规则。
- 规则挂接：把“哪些用户能参加活动”“哪些套餐档位对应哪些合约”“活动何时开始结束”“哪些合约互斥”“奖品有效期多久”等规则挂回具体产品、客户、地域和有效期。
- 人工审核闸门：由于文档常常存在重叠、覆盖、冲突和口径差异，AI 抽取结果不能直接入库，需要业务侧确认。
- 证据链追溯：每条规则都应保留证据文档与文档切片，问答或校验时可以追溯“这个判断依据是什么”。
- 持续演化机制：当问答发现某个节点不够用或某类规则缺失，系统可以回到知识库搜索候选节点，再进入审核流程，而不是让 AI 静默修改图谱。
典型应用
- 营销活动治理：将多个活动文档中的时间、地域、产品、客群、互斥规则和奖品有效期挂回产品/活动对象，支持资格判断和冲突检查。
- 客服口径统一：把不同地市、不同产品线的客服说明关联到对应地域、产品和有效期，避免客服系统误用过期或异地口径。
- 规则冲突检查：发现多个营销文档时间重叠、办理限制不一致、活动规则互相覆盖等问题。
- Agent 工具调用：为智能 Agent 提供可查询、可验证的规则服务，而不是让 Agent 每次从文档切片中临时猜规则。
常见误区
- 误区一：文档切片就是文档图谱。切片只保留文本片段，无法保证规则挂回正确对象，也难以处理互斥、有效期和冲突。
- 误区二：抽一个“活动名称”就够了。活动类文档真正可治理的是时间、地域、客群、产品、渠道、规则、权益、互斥和有效期等字段。
- 误区三：文档图谱是给文档看的。文档图谱不是为文档本身画图，而是把文档规则挂回产品、客户、地域、渠道和有效期等业务对象。
- 误区四：AI 抽取后可自动入库。AI 可以发现线索，但规则入库是业务治理动作，尤其在冲突、覆盖和口径差异场景中必须有人类审核。
不同素材中的观点
- 2026-07-05-woshipm-enterprise-knowledge-graph-6-lessons：这篇素材把文档图谱定义为企业级知识图谱中“更难、也更有价值”的部分。产品主数据通常已有结构化骨架，而大量业务规则藏在营销政策、客服口径、活动方案里。素材强调，文档图谱的目标不是给文档单独画图，而是把活动、规则、限制、权益、渠道、时间等信息挂回具体产品、具体客户、具体地域和具体有效期。否则这些信息只停留在文档切片里，问答时偶尔能答，却无法稳定支持冲突检查、重复识别和规则治理。
- 2026-07-07-woshipm-enterprise-kg-hybrid-architecture：这篇素材解释了为什么办理条件、限制规则和 FAQ 在早期不一定已经进入图数据库。系统能回答“怎么办理”“有什么限制”“能不能退订”，很可能是规则仍保存在 MongoDB 的文档切片或抽取字段里，通过 Milvus 和 Elasticsearch 召回后由大模型总结。这个阶段的 NebulaGraph 主要存产销品和别名关系。对文档图谱来说，这是一条务实路径：先保留原文上下文和审核状态，避免错误关系直接入图污染全局；等规则达到高频、高风险、可结构化、可复用，再逐步把产品—活动、活动—客群/地域/渠道、互斥规则、退订变更规则等结构化入图。
实用信息
建设文档图谱的最小流程
- 收集并分类文档：按营销活动、客服口径、权益包、培训材料、政策说明等类型分类。
- 定义每类文档的必抽字段：例如活动类必须有时间、地域、客群、产品、渠道、规则、权益、互斥、有效期。
- 让 AI 抽候选信息：从非结构化文本中识别实体、关系、条件、规则和证据切片。
- 业务审核字段与关系：确认抽取字段是否完整、关系是否挂对对象、规则是否有遗漏。
- 挂接到业务对象：把规则绑定到产品、客户、地域、渠道、有效期，而不是停留在文档节点下。
- 运行问答与冲突测试：用真实问题验证答案、关联节点、证据切片和关键条件是否正确。
- 建立迭代机制：当发现缺失字段、冲突规则或过期活动时，进入审核与更新流程。
判断文档图谱是否有效
- 能否回答“某地区某客群在某时间能否参加某活动”，并给出判断链路。
- 能否识别同一产品在不同文档中的办理限制差异。
- 能否发现活动时间重叠、互斥规则覆盖或过期规则误用。
- 能否让客服、Agent、RAG 和运营工具调用同一套规则，而不是各自检索文档。