Pro版：知识图谱与结构树
在普通检索中，有两类问题几乎都会发生翻车的：
- 关系类问题：比如"发布控制和变更评审、运维值班是什么关系"。向量检索只能召回分别提到这几个词的段落，但它们之间的关系是散落在全文各处的，靠相似度根本拼不起来。
- 全局总结类问题：比如"这份运维手册整体讲了哪几块内容"。答案不在任何单一片段里，而是要对全文做归纳。向量检索召回的永远是局部片段。
Nexus Agent Pro 用两个检索通道来解决这两个难点问题：知识图谱： 负责管理关系，结构树： 负责管理全局。
这两个能力都是业界比较前沿的检索增强方向，也是这个项目相比普通 Agent 项目最能拉开差距的地方。
知识图谱 把文档里的实体、关系、社区抽出来建成一张图。
结构树 把文档一层层聚类、逐层摘要，建成一棵从细节到全局的树。
到了用户提问时，它俩各自作为一个检索通道参与召回，和向量、关键词一起进加权融合。
知识图谱：把文档变成一张关系网
它解决什么问题
传统向量检索是"以块为单位"的，每个小块各自向量化、各自召回。这种方式丢掉了一个关键信息：块和块之间、实体和实体之间的关系。
知识图谱的思路是：在文档入库时，把里面的实体（人、部门、系统、概念）和关系（谁负责谁、谁依赖谁、谁触发谁）抽取出来，织成一张关系网。这样关系类问题就能顺着网上的连线直接找到答案，而不是靠相似度碰运气。
构建流程
分两步看：
第一步，候选抽取。 Python 工具服务从每个文本块里抽出实体（带别名、可信度）、关系（带关系描述、出自哪个块、原话引用），并做社区发现（把联系紧密的一组实体聚成一个"社区"）。注意 Python 给的都是候选，不是最终结果。
第二步，主链路校验并入库。 Java 负责把 Python 给的候选做同义实体合并（把"发布控制""发布管控"归一成同一个实体）、关系去重、核对引用原话和来源块是否真实存在、按可信度过滤，然后分门别类存起来：
| 存什么 | 内容 |
|---|---|
| 实体 | 归一后的名字、别名、类型 |
| 关系 | 头实体、尾实体、关系描述、出处 |
| 关系证据 | 支撑这条关系的原话、来源块、证据强度 |
| 社区 | 一组强关联实体的聚合，含社区标题和总结报告 |
主链路还会给图谱里的实体算一个"重要性分"（类似网页排名的思路），越是被很多关系指向的核心实体，分越高。
管理端的知识图谱视图可以把这些产物直接浏览出来：画布上方展示实体、关系、关联实体和孤立实体的统计，节点按实体类型区分颜色；选中实体后，底部关系明细会列出来源实体、关系、目标实体及权重。图谱因此不仅用于检索，也保留了可检查、可定位、可回溯的关系证据。
图：知识图谱的实体关系浏览视图，节点和关系明细共同构成可追溯的关系证据。
图谱怎么参与检索：复用同一套检索底座
这是一个很聪明的工程设计。图谱建好了，但检索时怎么让它和向量、关键词通道一起参与融合？
答案是：把图谱产物翻译成三类特殊的"检索单元"——实体单元、关系单元、社区单元，然后和普通文本块一样，写进同一套向量库和关键词索引里。
这样一来，知识图谱通道就不需要另搭一套检索设施，直接复用现有的向量库和关键词索引，检索出来的图谱单元天然就能进加权融合。图谱的价值（实体关系、社区总结）被"翻译"成了普通检索底座能理解的东西。
检索时怎么用
当系统判断这是一个图谱关系类问题，就会把知识图谱通道的融合权重拉高。它支持这几种查法：
- 关系类问题直接命中：直接找到实体之间的关系单元，拿到关系和支撑它的原话
- 别名也能命中：用户用的是实体的别名，靠前面的同义实体合并照样能找到
- 社区总结检索：偏全局的关系问题，命中对应的社区总结报告
- 跨文档关联：关联跨越多份文档时，跨文档的社区证据会被优先保留（融合阶段有专门的保底逻辑）
- 多跳查询：受控的查询计划能规划"A → B → C"这样跨多步的关系路径
实体/关系/社区抽取、把图谱翻译成检索单元、跨文档同义实体合并、多跳路径查询、受控查询计划——这些能力让关系类问题不再依赖向量相似度碰运气，而是顺着图谱上的实体和连线精准找到答案。
结构树：给长文档建一棵摘要树
它解决什么问题
结构树解决的是"全局总结"问题。
想象一份 80 页的运维手册。用户问"这份手册整体的应急响应思路是什么"。向量检索会给你召回几个提到"应急""响应"的段落，但这些局部片段拼不出一个全局答案。
结构树的思路是：先对文档一层层聚类、逐层摘要，建成一棵树。 树的叶子是原文小块，往上每一层是对下层若干节点的摘要，越往上越概括，树根就是对全文的高度概括。检索时先命中合适层级的摘要节点，再往下钻到原文。
构建流程
构建同样是 主链路编排 + 工具执行：
- 工具执行：把内容向量化后做层次聚类，把相近的块聚到一起；每个摘要簇最多包含 6 个下层节点，整棵树最多 3 层。如果开启了大模型摘要，Python 会调大模型给每个簇生成一段摘要，并给出质量分
- 主链路编排：负责按质量分过滤、保存树节点、把摘要写进向量库和关键词索引
管理端的分层摘要树视图展示了这套产物如何被组织和浏览：顶部是原始文档、解析块、父级块、检索子块、图谱证据和分层摘要等产物类型；下方按 L1、L2、L3 展开摘要节点，能够从高层概括逐层下钻到更具体的章节。检索时先命中摘要节点，再通过节点来源回到原文块，正是“先建立全局视角、再补齐可引用证据”的两段式路径。
图：分层摘要树的管理端视图，摘要节点按层级展开，并保留回到原文的来源关系。
质量把关：宁可没有也不要错误的
结构树有一个很关键的质量控制：摘要质量分低于阈值的摘要节点，主链路直接不保存，也不写进索引。
这背后的逻辑是：一个低质量的摘要（比如大模型摘偏了、或者聚类聚得不好）如果进了检索面，反而会污染召回、把用户带偏。宁可这个节点缺失，也不要一个误导性的摘要。
检索时怎么用
当系统判断这是全局总结类问题，就会把结构树通道的权重拉高。它的检索是两段式的：
- 先召回合适的摘要节点，拿到全局或中层视角
- 再顺着摘要节点记录的来源，下钻到背后的原文小块
和知识图谱一样，结构树命中后的最终引用不能只指向摘要节点（那是"只有概括、没有出处"）。必须下钻到摘要背后的原文块，让引用能回到真实原文。摘要只是帮你"找到该看哪一块"，真正作为证据的还是原文。
两者的定位对比
| 维度 | 知识图谱 | 结构树 |
|---|---|---|
| 解决的问题 | 实体关系、跨文档关联 | 长文档全局总结、跨章节概括 |
| 构建产物 | 实体/关系/社区关系网 | 逐层摘要的树 |
| 适合的问题 | "A 和 B 是什么关系" | "这份文档整体讲了什么" |
| 通道基础权重 | 1.1 | 1.05 |
| 检索方式 | 命中实体/关系/社区单元 | 先召回摘要，再下钻原文 |
| Python 负责 | 抽候选 + 社区发现 | 聚类 + 大模型摘要 |
| Java 负责 | 校验/合并/入库/翻译成检索单元/打分 | 质量过滤/入库/写索引 |
面试怎么聊这块
Q：向量检索搞不定的问题，你们怎么处理？
A：我们加了两个高级检索通道。关系类问题（"A 和 B 什么关系"）走知识图谱——文档入库时抽取实体、关系、社区织成一张关系网，再翻译成检索单元进统一检索底座。全局总结类问题（"这份文档整体讲了什么"）走结构树——对文档一层层聚类、逐层摘要建成一棵树，检索时先命中摘要节点，再下钻到原文。
Q：知识图谱的实体关系是模型抽的，怎么保证不出错？
A：我们让 Python 只做候选抽取，Java 来把关。Python 抽出实体、关系、证据候选，Java 负责同义实体合并、关系去重、核对引用原话和来源块是否真实存在、按可信度过滤，才正式入库。模型负责理解和抽取，Java 负责校验和入库，幻觉进不了主链路。
Q：结构树的摘要质量怎么控制？
A：每个摘要节点都有质量分，低于阈值（0.42）的直接不保存、不进检索面。宁可缺这个节点，也不要一个误导性的摘要污染召回。而且最终引用不能只指向摘要，必须下钻到摘要背后的原文块。
Nexus Agent Pro 项目的申请
Nexus Agent Pro 项目是本人根据大厂的真实开发思路，花费了很多的精力和时间认真打磨出来的，也为了更好的保护已经加入星球的小伙伴的权益。所以决定 Nexus Agent Pro 不再进行开源，而是将项目放到了私有库中。
普通版本的 Nexus Agent 项目依然还是正常开源，本人也依然会继续进行优化。开源地址为： 👉 点击这里跳转到 Nexus Agent
已经加入星球的小伙伴，可以按照以下指示来申请和学习 Nexus Agent Pro：👉 点击这里学习 Nexus Agent Pro