如何使用Python、Neo4j和ServiceNow构建GraphRAG系统
内容提要
本书介绍将ServiceNow CMDB数据导入Neo4j以构建GraphRAG系统，要点包括：批量API原子提交使错误信息仅反映整批而非单行，需统计消息类型定位问题；加载前须决定如何处理已退役配置项；加载器需可安全重启，用correlation_id和实例戳记防止重复与静默错误；读取时注意字段双值、时区、分页和权限过滤等陷阱；建模应从问题出发，警惕关系方向反转、超级节点和依赖环，并区分哪些关系传递影响。
延伸解读
GraphRAG 的适用边界
文章明确指出，GraphRAG 并非万能。对于结构化的依赖查询，ServiceNow 自带的 Dependency Views、CI Impact Explorer 等工具已经足够，且维护更好。GraphRAG 的价值在于处理非结构化文本（如工单描述、工作笔记）和跨领域关联查询，以及提供可测量的检索效果对比。如果只需回答“什么依赖这个配置项”，应优先使用内置工具。
检索策略的实测结果
作者在 39 个预先冻结的问题上测试了八种检索方法，发现没有一种能回答开篇的 02:10 问题。关键词搜索在“查找已知记录”上得分为 1.00，但在“按含义查找”“计数排序”“时间比较”上均为 0.00。图遍历在链式依赖查询上表现更好，但整体结果并不支持“图总是更优”的结论。这提醒读者，检索策略的选择需基于具体问题类型。
数据命名对评估的影响
数据集中的配置项使用 lnx2419、pg0711 这类无结构名称，而非 payments-db 这种包含服务信息的命名。这种设计避免了关键词搜索通过名称拼写“作弊”，迫使图遍历必须依靠关系而非文本相似性来找到答案。如果使用真实世界中常见的关联命名，关键词搜索在链式查询上的表现会显著提升，因此评估结果高度依赖命名方案。
成本与隐私的权衡
全书除 Part 8 租用 GPU 约 5 美元外，其余部分均使用免费资源。作者选择在自有 GPU 上运行模型，而非调用托管 API，是因为工单文本包含主机名、内部服务名等敏感信息，发送到外部服务会引发安全审查问题。如果使用托管模型，Part 10 的测量结果不变，因为检索发生在模型之前。这为读者提供了成本与隐私的实用参考。
Q&A
GraphRAG系统是什么？它如何结合ServiceNow、Neo4j和Python？
GraphRAG是检索增强生成（RAG）的一种，其中图数据库决定哪些记录与问题相关。系统从ServiceNow CMDB中提取配置项、事件、变更等数据，用Python加载到Neo4j图数据库中，然后通过图遍历选择相关记录，最后交给语言模型生成答案。
为什么在ServiceNow中回答“如果这个坏了，还有什么会坏”需要20分钟？
因为CMDB将每个事实存储为单独的行，依赖关系需要多跳查询。要回答这个问题，需要手动打开一条记录，读取其依赖，再打开每个依赖的记录，如此反复。在包含11,891个配置项和28,694条依赖边的环境中，三跳查询需要打开四条记录，且无法保证完整性。
在Neo4j中如何查询一个配置项的所有上游依赖？
使用Cypher查询：MATCH (a)<-[:SUPPORTS*]-(b) WHERE a.key = $item RETURN b。其中*表示沿SUPPORTS关系无限深度遍历，无需指定跳数，因此无论依赖链多长，查询语句不变。
将ServiceNow数据加载到Neo4j时，如何避免重复加载和静默错误？
加载器需要可安全重启，使用correlation_id和实例戳记来防止重复和静默错误。此外，批量API原子提交使错误信息仅反映整批而非单行，需统计消息类型定位问题；加载前须决定如何处理已退役配置项。
从ServiceNow读取数据到Python时有哪些常见陷阱？
常见陷阱包括：每个字段有两个值（显示值和实际值）、时间戳时区问题、分页遗漏导致数据不全、权限过滤导致看到的数据比预期少且无警告。此外，工作笔记不是列，需要特殊处理。
在将ServiceNow建模为图时，有哪些常见的建模错误？
常见错误包括：关系方向反转（如Hosted on::Hosts方向弄反）、超级节点（如存储阵列连接大量数据库）、依赖环、以及将边键值设为文本而非sys_id。建模应从问题出发，区分哪些关系传递影响。
GraphRAG系统在回答“如果这个坏了，还有什么会坏”时表现如何？
在本书的测量中，八种检索方法（包括纯相似度、关键词、混合、图遍历等）均未能正确回答该问题。Part 10报告了零召回率，表明当前系统在将自然语言问题转化为图查询方面仍有局限。
