Making the Knowledge Layer a Graph You Actually Traverse

让知识层成为你真正能够遍历的图谱

LLM Applications Making the Knowledge Layer a Graph You Actually Traverse. Why retrieval quality should be a property of the system, not of the question’s wording? Rebuilding knowledge layer with graph traversal on every query, bitemporal edges, and two-threshold entity resolution. 大模型应用：让知识层成为你真正能够遍历的图谱。为什么检索质量应该是系统的一种属性，而不是取决于问题的措辞？通过每次查询时的图遍历、双时态边以及双阈值实体解析来重构知识层。

In the first article of this series (Designing a Persistent Knowledge Layer That Refuses to Guess), I built a persistent knowledge layer next to a RAG pipeline: an evidence layer for grounding, a structured knowledge layer for accumulated understanding, and an orchestrator that decided which of the two a question needed. 在本系列的第一篇文章（《设计一个拒绝猜测的持久化知识层》）中，我在 RAG（检索增强生成）流水线旁构建了一个持久化知识层：一个用于基础支撑的证据层、一个用于积累理解的结构化知识层，以及一个决定问题需要两者中哪一个的协调器。

I deployed it on Azure, seeded it with a synthetic insurance corpus engineered to break retrieval systems in six specific ways, and measured what happened. The architecture held up. The contradiction register refused to answer a question the firm itself had not settled. The effective-date scoping kept a rule that took effect on 1 March from being applied to a loss dated 20 February. The live model walked a four-hop reasoning chain with citations at every step. 我将其部署在 Azure 上，并注入了一套合成的保险语料库，该语料库旨在从六个特定方面破坏检索系统，随后我测量了运行结果。该架构经受住了考验。矛盾登记册拒绝回答公司尚未定论的问题；生效日期范围限制确保了 3 月 1 日生效的规则不会被应用于 2 月 20 日的损失；实时模型执行了四跳推理链，并在每一步都提供了引用。

But I ended that article with a list of things I would build next, and two of the entries on that list have not left me alone since. The first was a number. When I ran all twenty-one documents through live extraction on the deployed stack, the model proposed concepts that my alias-based entity resolution could only partially merge. The result was 149 concept objects where the curated graph has 19 – a roughly 7x fragmentation factor. 但在那篇文章的结尾，我列出了一系列接下来要构建的内容，其中两项一直萦绕在我的心头。第一项是一个数字。当我将所有 21 份文档通过部署的堆栈进行实时提取时，模型提出的概念超出了我基于别名的实体解析所能合并的范围。结果产生了 149 个概念对象，而人工整理的图谱中只有 19 个——碎片化程度约为 7 倍。

I wrote at the time that this was “the concrete argument for embedding similarity and LLM adjudication in the resolution chain.” It is. But sitting with the number longer, I realized it argues for something bigger. The knowledge layer I built stores relationships, but nothing in the system actually traverses them at retrieval time. The graph is consulted like a filing cabinet, not walked like a graph. 当时我写道，这是“在解析链中嵌入相似度计算和大模型裁决的具体论据”。确实如此。但随着对这个数字的深入思考，我意识到它指向了更宏大的问题。我构建的知识层存储了关系，但在检索时，系统中没有任何东西真正去遍历这些关系。这个图谱被当作文件柜来查阅，而不是像图谱那样被遍历。

The second was an incident, not a number. During live validation I asked the deployed system an unscripted question — why a particular claim had been triaged the way it was, and my first phrasing got intercepted by the contradiction gate, because the claim’s evidence brushed against a contested concept. The gate did its job. But the routing in front of the gate had made a judgment call about how to retrieve, based on keyword markers in my question, and it occurred to me that I had built a system whose retrieval quality depended on how a question happened to be worded. 第二项是一个事件，而不是数字。在实时验证期间，我问了部署系统一个未预设的问题——为什么某项索赔会被那样处理。我的第一种措辞被“矛盾门”拦截了，因为该索赔的证据触及了一个有争议的概念。拦截门发挥了作用，但门前的路由机制根据我问题中的关键词标记，对如何检索做出了判断。我意识到，我构建的系统，其检索质量竟然取决于问题的措辞方式。

This article is about fixing both. It is the result of the design work I did after previous work was shipped, and it changes my own architecture in a way I want to be upfront about: the query router from Part 1, the wiki-first, evidence-first, hybrid decision I drew as a flowchart and defended in prose is actually the component I am retiring. 本文旨在解决这两个问题。这是我在前作发布后进行设计工作的成果，它改变了我的架构，我希望开诚布公地说明：第一部分中的查询路由——即我画成流程图并以文字论证的“维基优先、证据优先”的混合决策机制——实际上正是我要淘汰的组件。

Not because it was wrong for what Part 1 was doing, but because I now think there is a better answer to the question it was trying to answer, and the better answer also unlocks three capabilities the router never could: real multi-hop traversal, time-aware relationships, and contradictions that are discovered instead of curated. 这并不是因为它在第一部分中表现不佳，而是因为我认为现在有了更好的方案来回答它试图解决的问题，而且这个更好的方案解锁了路由机制永远无法实现的三个能力：真正的多跳遍历、时间感知关系，以及被发现而非人工整理的矛盾。

I will keep the previous approach, and present it in three parts, the same way as before. Part I is the design revision. Vendor-neutral, like last time. It covers the principle that replaces the router (retriever versus filter), the always-fused retrieval pipeline, bitemporal edges, ingest-time contradiction detection, and the entity-resolution subsystem that everything else stands on. 我将沿用之前的方法，并像以前一样分三部分呈现。第一部分是设计修订。和上次一样，保持供应商中立。它涵盖了取代路由器的原则（检索器与过滤器）、始终融合的检索流水线、双时态边、摄入时的矛盾检测，以及其他一切功能所依赖的实体解析子系统。

Part II grows the Azure stack. The resource group from Part 1 is still running, and it turns out to contain most of what this design needs — including a change feed I provisioned and never used. One new engine joins it. 第二部分扩展 Azure 堆栈。第一部分的资源组仍在运行，事实证明它包含了此设计所需的大部分内容——包括我预置但从未使用的变更馈送（change feed）。一个新的引擎将加入其中。

Part III walks the insurance corpus through the new design — live. The same Ostermere Mutual documents, the same contradiction, the same claims — and the questions the new architecture can answer that the old one could not. The implementation is deployed on a fresh Azure resource group, and every request and response quoted in Part III was actually sent to and returned by that system, the same standard Part 1 held itself to. 第三部分通过新设计实时遍历保险语料库。同样的 Ostermere Mutual 文档、同样的矛盾、同样的索赔——以及新架构能回答而旧架构无法回答的问题。该实现部署在一个全新的 Azure 资源组上，第三部分中引用的每一个请求和响应实际上都是由该系统发送和返回的，这与第一部分所坚持的标准一致。

What this article deliberately defers: the reflection loop that derives higher-level insights, the full write-path architecture in production depth, the agent-tool layer, and the governance backlog. Each of those deserves its own treatment, and stacking them here would produce a survey instead of an argument. 本文特意推迟讨论的内容：推导更高层次见解的反射循环、生产深度的完整写入路径架构、智能体工具层以及治理积压工作。每一项都值得单独探讨，将它们堆砌在这里只会写成一份综述，而不是论证。

Everything in the dataset is synthetic. Ostermere Mutual does not exist. Neither does the regulator, the policy, the claims, the people, the wind zones or the figures. Nothing here is insurance, legal, underwriting or claims advice. 数据集中的一切都是合成的。Ostermere Mutual 公司并不存在。监管机构、保单、索赔、人员、风区或数据也都不存在。此处内容不构成任何保险、法律、承保或索赔建议。

Naming note: current Microsoft documentation uses Microsoft Foundry for the platform previously called Azure AI Foundry. As in Part 1, I use Foundry throughout. 命名说明：当前的微软文档使用 Microsoft Foundry 来指代之前称为 Azure AI Foundry 的平台。与第一部分一样，我在全文中使用 Foundry。

The complete Part 1 project (application, infrastructure, dataset and the generated Obsidian vault) is available at github.com/mcekikj/persistent-knowledge-layer, under the MIT license — that repository stays frozen as the artifact Part 1 describes. The Part 2 implementation lives in its own repository at github.com/mcekikj/knowledge-graph-fusion. 第一部分的完整项目（应用程序、基础设施、数据集和生成的 Obsidian 库）可在 github.com/mcekikj/persistent-knowledge-layer 获取，采用 MIT 许可证——该存储库将保持冻结状态，作为第一部分所述的产物。第二部分的实现位于其独立的存储库 github.com/mcekikj/knowledge-graph-fusion 中。