Knowledge Graph Builder 是一个专家级知识图谱创建系统，用于将彼此孤立、分散的支持内容转化为由概念、关系和解决方案构成的互联网络。该技能提供结构化的工作流，用于映射知识领域、定义关系，并驱动智能化的支持体验。
知识图谱使支持系统能够理解上下文，而不仅仅是关键词。当客户询问“账单问题”时，知识图谱知道这与发票、支付方式、订阅计划以及潜在的流失风险相关。该技能帮助你构建这种连接性的智能。它建立在语义网原则和知识工程最佳实践之上，结合领域建模、关系映射和实际实现，创建能够驱动更智能支持的知识图谱。
核心工作流
工作流 1：领域建模 定义知识领域中的概念和实体。实体识别包括：核心实体（产品、功能、概念）、客户实体（账户、用户、细分群体）、支持实体（问题、解决方案、文章）、流程实体（工作流、过程、步骤）、上下文实体（用例、角色、场景）。支持场景的实体类型包括：Product（应用、功能、模块，表示客户使用什么）、Issue（缺陷、错误、问题，表示客户面临什么）、Solution（修复、变通方法、指南，表示如何解决）、Article（FAQ、操作指南、参考，表示内容资源）、Concept（术语、流程、能力，表示理解）、Persona（管理员、用户、开发者，表示谁需要帮助）。实体属性示例（Feature）：id（唯一标识符）、name（显示名称）、description（功能说明）、status（active/deprecated/beta）、complexity（basic/intermediate/advanced）、related_persona（使用者）、documentation_url（帮助文章链接）。实体提取来源包括：产品文档、支持工单分类、FAQ 分类、帮助中心结构、功能规格说明、用户研究发现。
工作流 2：关系映射 定义实体之间如何连接。核心关系类型包括：SOLVES（Solution → Issue，如“密码重置 SOLVES 登录失败”）、PART_OF（Feature → Product，如“仪表盘 PART_OF 分析”）、REQUIRES（Feature → Feature，如“导出 REQUIRES 专业版计划”）、CAUSES（Issue → Issue，如“API 限制 CAUSES 同步失败”）、DOCUMENTED_IN（Concept → Article，如“账单 DOCUMENTED_IN 定价指南”）、APPLIES_TO（Solution → Persona，如“变通方法 APPLIES_TO 管理员用户”）。关系属性示例（SOLVES）：confidence（可靠程度 0-1）、conditions（适用条件）、effectiveness（成功率）、last_verified（核验日期）。关系发现方式包括：分析支持工单解决路径、映射帮助文章交叉引用、识别共现问题、研究用户旅程模式、审查专家知识。关系强度分为：强（始终成立、有据可查）、中（通常成立、常见模式）、弱（有时成立、依赖上下文）、建议（可能成立、待验证）。
工作流 3：图谱构建 构建实际的知识图谱结构。图架构包括节点（实体：唯一标识符、实体类型、属性、元数据如创建/更新/来源）和边（关系：起始节点、目标节点、关系类型、属性、元数据）。实现选项包括：图数据库（适合复杂查询与规模，工具如 Neo4j、Amazon Neptune）、RDF 三元组存储（适合语义网与标准，工具如 Apache Jena、Stardog）、属性图（适合灵活建模，工具如 Neo4j、TigerGraph）、嵌入式（适合简单用例，工具如 NetworkX、GraphQL）。模式设计包括：定义节点标签/类型、定义关系类型、设置必需属性、定义约束（唯一性、存在性）、为查询性能创建索引。数据填充方式包括：从现有来源批量导入、从实时系统 API 摄取、人工专家策展、自动化提取（NLP）、从支持活动持续更新。
工作流 4：查询与推理 从知识图谱中提取价值。查询模式包括：遍历（查找相关内容，如“与 X 相关的文章”）、路径查找（解决方案发现，如“从问题到解决的步骤”）、模式匹配（相似问题，如“类似 X 的问题”）、聚合（分析，如“每个功能最常见的问题”）、推荐（建议，如“其他用户还查看了”）。推理规则示例：若 A CAUSES B 且 B CAUSES C，则建议 A 可能与 C 相关；若 Solution S SOLVES Issue I，则为相似问题建议相似解决方案；若 Article A DOCUMENTED_IN B 且 B REQUIRES C，则将 C 显示为先决条件；若许多用户按 A → B → C 导航，则建议快捷方式。语义搜索增强包括：用相关概念扩展搜索、按图中心性排序、呈现相关文章、建议替代术语、从关系理解上下文。对话式 AI 集成包括：将用户意图映射到图实体、沿关系查找答案、从连接内容生成回复、通过图路径解释推理。
工作流 5：维护与演进 保持知识图谱准确并持续增长。质量监控包括：跟踪使用模式、识别死胡同路径、查找孤立节点、监控关系准确性、衡量搜索成功率。更新触发因素包括：新产品发布、文档变更、支持工单模式、用户反馈、专家策展会议。验证流程包括：专家审查新关系、A/B 测试图驱动功能、监控准确性指标、收集用户反馈、定期审计。增长策略包括：从工单自动提取实体、基于 ML 的关系建议、用户贡献机制、专家知识捕获会议、与外部来源交叉引用。
快速参考 创建实体：“Add entity [type] for [name]”；定义关系：“Create relationship [type] from [A] to [B]”；查询图谱：“Find [entity] related to [entity]”；查找路径：“Show path from [issue] to [solution]”；图谱统计：“Show knowledge graph metrics”；验证关系：“Audit relationships for [entity]”；从工单提取：“Extract entities from recent tickets”；生成文档：“Export graph as documentation”；查找缺口：“Identify missing relationships”；可视化图谱：“Visualize graph around [entity]”。
最佳实践 领域建模：从核心产品概念开始；从客户视角建模；保持实体类型聚焦；清晰记录实体定义；对模式进行版本管理。关系设计：使用基于动词的关系名称；使关系具有方向性；添加置信度/强度属性；避免冗余关系；记录关系语义。图谱构建：从小处着手、迭代增长；与领域专家验证；为频繁查询的属性建立索引；从一开始就规划规模；维护数据血缘。查询优化：分析查询性能；创建适当索引；缓存常见遍历；对大型结果分页；监控查询模式。维护：安排定期审计；跟踪内容新鲜度；移除过时节点/边；验证自动化添加内容；记录变更。
知识图谱模式 核心实体包括 Product、Feature、Issue、Solution、Article、Concept，各自定义了必需属性与可选属性（如 Product 的 id、name 为必需，description、version、status、tier 为可选；Issue 的 severity、frequency、symptoms；Solution 的 steps、type、effectiveness、applies_to；Article 的 url 为必需，type、audience、last_updated；Concept 的 term、definition 为必需，aliases、domain）。核心关系包括 PART_OF、SOLVES、CAUSES、DOCUMENTED_IN、REQUIRES、RELATED_TO、APPLIES_TO，各自定义了起点、终点与属性（如 SOLVES 的 confidence、conditions、verified_date；CAUSES 的 probability、mechanism；REQUIRES 的 type 为 prerequisite/dependency/permission；RELATED_TO 的 strength、type 为 similar/alternative/complementary）。
实施指南 阶段 1：基础（第 1-2 周）——定义核心实体类型、记录属性模式、映射主要关系、选择技术栈、搭建开发环境。阶段 2：核心图谱（第 3-4 周）——从文档提取实体、创建初始关系、导入图数据库、构建基本查询界面、与领域专家验证。阶段 3：集成（第 5-6 周）——连接支持系统、实现搜索增强、添加内容推荐、创建管理界面、设置监控。阶段 4：智能（第 7-8 周）——添加推理规则、实现相似度评分、启用自动化提取、构建反馈循环、部署到生产环境。
风险提示 孤立节点（没有关系的实体）、关系汤（过多弱关系）、过时数据（未更新的信息）、模式漂移（实体建模不一致）、查询复杂（简单问题需要复杂查询）、无验证（自动化添加内容未经验证）、缺少上下文（关系没有属性）、覆盖不足（关键概念未体现）。
成功指标 图谱覆盖率（概念捕获百分比，目标 90%+）、搜索改进（相关性对比关键词，目标 2 倍+）、解决速度（找到答案的时间，目标减少 50%）、关系准确性（专家验证率，目标 95%+）、查询延迟（响应时间，目标 < 100ms）、用户满意度（图功能 CSAT，目标 4.0/5.0+）、自动化率（由图自动解决，目标 30%+）、图谱增长（每月新增实体，目标健康增长）。