当你以为 GraphRAG 最难的是建图实际上最难的是给实体定类型——哪怕你已经预定义了严格的类型 schema。一、先看一组真实数据我们拿 3GPP TS 23.5025G 核心网信令流程规范跑了一次 GraphRAG 的实体抽取。这份文档大约 700 多页是电信领域最核心的标准之一。结果让人头疼总共抽出8873 个不同的实体按 title 去重后其中1123 个实体被分配了 2 种以上的 type——占比 12.7%最夸张的实体PMIC被分成了7 种不同的 typeARCHITECTURE_CONCEPT、DATA_TYPE、INFORMATION_ELEMENT、MANAGEMENT_ENTITY、NETWORK_ELEMENT、PROCEDURE、PROTOCOL注意这次实验已经预定义了严格的实体类型 schema在 prompt 中明确约束 LLM 只能使用指定的类型集合。也就是说这不是没给约束导致的混乱而是给了约束之后依然控制不住的混乱。更要命的是这些类型冲突不是发生在不同文档之间而是在同一个文档里甚至在同一个片段里。LLM 在读最小切分的一段文字时即便有明确的类型约束对同一个实体仍然给出了不同的类型判断。我们发现了63 条 text_unit 级别的重叠冲突——同一个实体在同一个文本块中被标注为两种不同的 type。比如实体被标为也被标为AFORGANIZATIONNETWORK_FUNCTIONNRFINTERFACENETWORK_FUNCTION5G SECURITY CONTEXTSECURITY_ELEMENTARCHITECTURE_CONCEPTHPLMNNETWORK_FUNCTIONORGANIZATIONSERVICE REQUESTINFORMATION_ELEMENTPROCEDURE这不是 LLM 犯了低级错误也不是 schema 设计得不好。你仔细想想AFApplication Function确实既是一个网络功能也是一个组织角色NRF既是一个网络功能也暴露了接口。这些类型都在我们预定义的 schema 里LLM 每次选的都是合法的类型——只是对同一个实体选了不同的合法类型。问题不在于 LLM 判断错了也不在于 schema 不够严格而在于现实世界的实体本来就不是单一类型的。二、为什么这个问题这么难2.1 实体天然具有多面性在 3GPP 规范里AMFAccess and Mobility Management Function这个词在架构图里它是一个NETWORK_FUNCTION在信令流程里它是一个PROCEDURE的参与者在部署描述里它是一个NETWORK_ELEMENT在接口定义里它是一个INTERFACE的端点同一个实体在不同上下文中扮演不同角色这不是 bug这是现实。2.2 LLM 的类型判断依赖上下文窗口GraphRAG 的实体抽取是逐 chunk 进行的。每个 text_unit 大约几百个 tokenLLM 只能看到这一小段文字。同一个实体PDU SESSION ESTABLISHMENT - 在描述信令流程的 chunk 里LLM 判断它是PROCEDURE- 在描述消息格式的 chunk 里LLM 判断它是INFORMATION_ELEMENT两个判断都对但合并到知识图谱时就冲突了。2.3 哪怕 schema 设计得再好类型边界本身就是模糊的我们已经预定义了类型 schema但谁来定义ARCHITECTURE_CONCEPT和NETWORK_FUNCTION的边界在 3GPP 的语境里很多概念天然横跨多个类别。POLICY CONTROL既是一个过程PROCEDURE也是一个架构概念ARCHITECTURE_CONCEPT——这两个类型都在我们的 schema 里LLM 选哪个都不算错。这不是 prompt 写得不好的问题也不是 schema 定义不够精确的问题而是类型体系的粒度和现实世界的复杂度之间存在根本性的张力。你可以把 schema 定义得更细但更细的 schema 只会让边界问题更多不会更少。2.4 规模放大了问题我们的数据显示拥有多个 type 的实体中Top 20 的实体平均有 4-7 种 type平均关联 10-200 条 description。像AF这样的核心实体有 209 条 description、192 个 text_unit 引用、4 种 type。当知识图谱里有上千个这样的多面实体时下游的社区检测、关系推理、摘要生成都会受到影响——因为图的结构被类型噪声污染了。三、业界目前怎么解决方案一预定义严格的类型体系Schema-First⚠️ 我们已经试过了做法在抽取之前人工定义一套严格的实体类型 schema并在 prompt 中明确约束 LLM 只能使用这些类型。代表微软 GraphRAG 的默认配置、大多数企业级知识图谱项目。我们的实际结果本文开头的所有数据就是在 Schema-First 模式下跑出来的。我们已经预定义了类型集合prompt 里也明确约束了——但 1123 个实体仍然出现了多类型冲突63 条 text_unit 级别的重叠冲突照样存在。为什么不够 - Schema 能约束 LLM 只能从这些类型里选但没法约束它对同一个实体只选一个- 领域概念天然具有多面性AF在 3GPP 的语境里确实既是 NETWORK_FUNCTION 又是 ORGANIZATION你定义再严格的 schema 也改变不了这个事实 - 需要领域专家参与设计 schema成本高换一个领域就要重新设计 - 过于严格会丢失信息——强制把AF归为NETWORK_FUNCTION就丢掉了它作为ORGANIZATION的语义结论Schema-First 是必要条件但不是充分条件。它能减少乱起名的问题但解决不了一个实体多种身份的根本矛盾。方案二允许多类型后处理合并Multi-Label Post-Processing做法抽取时不限制类型数量允许一个实体有多个 type然后在后处理阶段通过规则或模型来合并、去重、选主类型。代表LlamaIndex 的 PropertyGraphIndex、一些学术研究。优点 - 保留了实体的多面性信息 - 抽取阶段不丢信息缺点 - 后处理逻辑复杂规则难以穷举 - 选主类型本身就是一个需要领域知识的判断 - 图的复杂度增加查询性能下降适用场景探索性分析、不确定领域边界的早期阶段。方案三类型层次化Hierarchical Typing做法建立层次化的类型体系比如NETWORK_FUNCTION是ARCHITECTURE_CONCEPT的子类型。抽取时标注最细粒度的类型查询时可以按层次聚合。代表Wikidata 的类型体系、YAGO 知识库。优点 - 兼顾了精确性和灵活性 - 支持不同粒度的查询缺点 - 层次体系的设计本身就是一个大工程 - LLM 很难在抽取时准确判断层次关系 - 跨领域的层次体系很难统一适用场景大规模、长期维护的知识图谱项目。方案四放弃显式类型用 Embedding 表示Type-Free Embedding做法不给实体分配离散的类型标签而是用向量 embedding 来表示实体的语义特征。相似的实体在向量空间中自然聚在一起。代表一些最新的研究工作如基于 GNN 的实体表示学习。优点 - 彻底避免了类型冲突问题 - 能捕捉实体之间的细微语义差异缺点 - 失去了可解释性——你没法告诉用户这是一个网络功能 - 下游的社区检测和摘要生成需要重新设计 - 调试困难适用场景研究性项目、对可解释性要求不高的场景。方案五上下文感知的动态类型Context-Aware Dynamic Typing做法不在抽取阶段固定类型而是在查询阶段根据问题的上下文动态决定实体的类型。比如用户问架构问题时AF被视为NETWORK_FUNCTION问组织问题时被视为ORGANIZATION。代表目前主要停留在学术探索阶段。优点 - 最符合现实——实体的身份确实取决于上下文 - 不需要在抽取阶段做艰难的类型决策缺点 - 工程复杂度极高 - 离线建图阶段无法确定图结构社区检测等算法难以应用 - 查询延迟增加适用场景下一代 GraphRAG 系统的研究方向。四、我的建议Schema-First 打底 分层类型 主类型投票 上下文保留我们的实验已经证明Schema-First 是必要的起点——没有它类型会更加混乱。但光靠它不够。基于我们在 3GPP 文档上的实战经验我建议在 Schema-First 的基础上叠加一套务实的后处理方案第零层保持 Schema-First已有继续使用预定义的类型 schema 约束 LLM。这一步已经在做了它的价值在于把类型控制在一个有限集合内避免 LLM 自由发挥出THINGY、STUFF这种无意义类型。第一层抽取时保留所有类型在 Schema-First 的基础上不要在抽取阶段强制单一类型。LLM 从预定义类型集合中选了多个都保留。保留每个 (entity, type, text_unit) 三元组。这是原始信号丢了就回不来了。第二层统计投票选主类型对每个实体统计它在所有 text_unit 中被标注为各类型的频次选频次最高的作为主类型primary type。以AF为例 - NETWORK_FUNCTION: 出现 150 次 →主类型- ORGANIZATION: 出现 30 次 - ARCHITECTURE_CONCEPT: 出现 20 次 - NETWORK_ELEMENT: 出现 9 次主类型用于知识图谱的主结构、社区检测和默认查询。第三层保留副类型作为属性其他类型不丢弃作为实体的alternative_types属性存储。查询时可以按需使用。{ title: AF, primary_type: NETWORK_FUNCTION, alternative_types: [ORGANIZATION, ARCHITECTURE_CONCEPT, NETWORK_ELEMENT], type_distribution: { NETWORK_FUNCTION: 150, ORGANIZATION: 30, ARCHITECTURE_CONCEPT: 20, NETWORK_ELEMENT: 9 } }第四层类型冲突检测与人工审核对于 text_unit 级别的重叠冲突同一个 chunk 里同一个实体被标为不同类型标记为需要审核的候选项。这 63 条冲突就是最值得人工检查的——它们往往揭示了类型体系设计的盲区。代价是什么存储成本增加每个实体要存多个类型和分布信息图的数据量大约增加 20-30%。抽取阶段不变不需要修改 prompt 或抽取流程成本不增加。后处理需要开发投票、合并、冲突检测的 pipeline 需要额外开发大约 2-3 天的工程量。查询逻辑稍复杂需要在查询层面决定是用主类型还是全部类型但这个逻辑可以封装。不能完全自动化text_unit 级别的冲突仍然需要人工判断但数量可控我们的案例中只有 63 条。五、写在最后GraphRAG 的论文和博客总是把重点放在社区检测和全局查询这些亮眼的能力上但真正落地时实体类型的混乱才是第一个拦路虎。一份 23.502 文档8873 个实体1123 个有多类型冲突——而且这还是已经用了 Schema-First 约束之后的结果。这不是个例这是所有复杂领域文档的常态。预定义类型 schema 是必要的但远远不够。解决这个问题没有银弹。但至少我们可以做到在 Schema-First 的基础上不在后处理阶段丢信息用统计方法选主类型保留多面性供下游使用把真正需要人工判断的冲突控制在可管理的范围内。这才是 GraphRAG 从能跑通 demo到能上生产之间最需要填的一个坑。本文基于对 3GPP TS 23.502 文档的 GraphRAG 实体抽取实验数据。写于 2026 年 4 月 24 日。