Pro版：多通道检索与治理
前两篇讲的是 开源版 Nexus Agent，它已经把一个企业级 AI 智能体的主干打通了。从这一篇起，后面都是 Nexus Agent Pro （升级后的 Pro 版本）的内容——Pro 版在开源版这套主干之上，把检索、文档解析、知识治理几块推到了生产级深度。先看一眼两版的差异，你就知道 Pro 到底强在哪、后面几篇要讲什么。
开源版和 Pro 版差在哪
| 能力维度 | 开源版 Nexus Agent | Nexus Agent Pro |
|---|---|---|
| 检索通道 | 向量 + 关键词 双通道 | 向量 + 关键词 + 知识图谱 + 层级摘要树 多通道 |
| 融合排序 | RRF 融合 | 加权融合（RRF 骨架 + 原始分归一化 + 元数据推进 + 意图权重） |
| 精排 | 可选外部 Rerank | Python 工具 + 交叉编码器精排（BGE 多种重排） |
| 文档解析 | Apache Tika 识别 | 多种格式 OCR 智能识别 结构化解析（边界 / 表格 / bbox 坐标） |
| 切块 | 四种策略组合 | 基于结构化块 的父和子切块 |
| 关系类问题 | — | 知识图谱检索（实体 / 关系 / 社区 / 跨文档） |
| 全局总结问题 | — | 递归层级摘要树（聚类 + 摘要，召回后下钻原文） |
| 表格问答 | 表格当普通文本 | 结构化表格问答（行列单元格 + 受控查询计划 + 单元格级高亮） |
| 引用可靠性 | 引用来源标注 | 额外做 交叉编码器引用修复，引用回溯真实来源 |
| 知识库隔离 | 知识路由 | 知识路由 + 业务库边界 |
| 架构 | 纯 Java | Java 主链路 + Python 工具服务 混合架构 |
开源版帮你把 AI 应用工程化的主干跑通，Pro 版把每个环节都做到了大厂的生产级深度。 后面几篇会一块块展开，本篇先从最核心的「多通道混合检索」讲起。
多通道混合检索总览
Nexus Agent Pro 的检索链路是多通道并行召回 + 加权融合 + 交叉编码器精排。这一篇专门把这条链路拆开讲清楚：到底有几个通道、它们怎么并行、分数量纲不同怎么融合、融合完怎么精排、证据太多或太少又怎么治理。
这块是整个系统里技术细节很高的部分，也是面试中容易聊出深度的地方。
用户的一个问题，会被拆成若干子问题，每个子问题在最多五个检索通道里并行召回候选，然后通过加权融合统一排序、交叉编码器精排优选、父子块聚合补全上下文，最后经过证据预算裁剪注入 Prompt。整条链路里没有证据就直接拒绝，绝不有幻觉问题。
为什么要搞这么多通道
先说说单通道的天花板在哪。
纯向量检索的问题是：它擅长语义匹配，但对精确匹配天然弱势。用户问一个订单号 20260708-XY、一个配置项 app.admin-auth.token，向量检索很可能给你返回一堆"看起来相关"但根本不含这个词的段落。
纯关键词检索反过来：精确匹配很强，但完全不懂语义。用户问"打印机墨盒怎么换"，文档里写的是"墨盒更换步骤"，关键词就是匹配不上。
而且还有一类问题，这两个通道都搞不定：
- "这份文档整体讲了什么" —— 需要全局视角，不是某几个片段能回答的
- "A 部门和 B 部门是什么关系" —— 需要沿着实体关系走，不是相似度能算出来的
- "2025 年 Q3 华东区销量是多少" —— 答案在表格的某个单元格里，切成文本就丢了结构
所以 Nexus Agent Pro 把检索通道扩展到了五路，各自补齐一块短板。
五个检索通道
系统里一共定义了这些检索通道，实际参与召回的是前五个：
| 通道 | 标识 | 擅长什么 | 底层引擎 |
|---|---|---|---|
| 向量检索 | vector | 语义相似、模糊匹配 | PGVector |
| 关键词检索 | keyword | 精确匹配、专有名词、编号 | Elasticsearch / BM25 |
| 表格检索 | table | 表格统计、行列单元格定位 | 结构化表格数据 + 受控查询计划 |
| 知识图谱 | graph-rag | 实体关系、跨文档关联、社区总结 | 知识图谱（实体/关系/社区检索单元） |
| 结构树 | raptor | 长文档全局总结、跨章节概括 | 层级摘要树 |
除了这五个，还有 rerank（重排序，不是召回通道而是融合后的精排环节）和 structure（文档结构图检索，作为结构导航的软辅助）。
不是每次提问都把五个通道全跑一遍。系统会先理解问题意图，再决定重点走哪些通道、给哪些通道更高权重。比如判断是表格题，就会加大 表格检索 通道的权重；判断是全局总结题，就加大 结构树 权重。向量和关键词作为基础通道基本常驻，其余通道按开关和意图动态参与。
检索意图：先理解，再检索
多通道并行的前提，是系统得先搞清楚"这个问题该重点走哪个通道"。
它的做法是：先用一个确定性兜底（只从章节号、引号锚点这类明确结构语法里提取信号），再调用 LLM 做一次受控的查询理解，输出一个结构化的结果。这个结果里包含：
- 查询类型：问题类型，八选一：普通文档问答、追问、结构导航、表格查询、图谱关系、全局总结、开放闲聊、能力查询
- 多个通道：建议参与的检索通道列表
- 实体关系：涉及的实体（知识图谱会用到）
- 章节关系：章节锚点（结构导航会用到）
- 表格边界：表格操作意图（表格查询会用到）
- 置信度：打出不同信任分
这里有个很重要的工程约束：项目只输出受控建议，不生成 SQL、不决定最终答案。而且 LLM 给的建议还要过系统的白名单校验：置信度不够时，只保留确定性的保守计划；识别出的通道、结构操作枚举不在白名单里的直接丢弃。这样既借助了大模型的理解能力，又不会让它的幻觉直接影响主链路。模型负责理解，程序负责把关，这是整个系统反复出现的设计原则。
查询类型到检索意图的映射效率很高：结构导航，表格查询，图谱关系，全局总结，普通结构。这些加一起最终会影响融合阶段各通道的权重倍率。
加权融合：把五路结果排到一起
五个通道各返回一批候选，可它们的分数根本没法直接比——向量检索给的是相似度（0~1 之间），关键词检索给的是词频分（可能大到几十），知识图谱给的又是另一套质量分。硬比大小没有意义。
加权融合要解决的就是这件事：把口径不一的几批分数，公平地排到同一个榜单上。做法是给每个候选算一个统一的"融合分"。
融合分是怎么算出来的
融合分主要看三样东西：
- 排第几名：候选在每个通道里排的名次，越靠前加分越多。这一项只看名次、不看原始分数，所以天生能跨通道比较——它是整个融合的"骨架"。
- 原始分数高不高：作为微调。在名次相近时，原始分数更高的候选稍微占一点优势。
- 自带的加分项：比如这条证据属于高质量文档、命中了用户问的知识领域，会有一点额外加分（有上限，不会喧宾夺主）。
在这三样之上，每个通道还有一个信任权重：表格、知识图谱这类结构化程度高、噪声小的通道，天生给更高的权重；如果系统判断这次问题就是冲着某个通道来的（比如一看就是表格题），还会临时给这个通道再加点码。
一个候选要是同时被好几个通道命中，各通道给它的分会累加到一起——多路都认可的证据，本来就该排得更靠前。
你可能会问：既然要综合打分，为什么还留着"排第几名"，直接按原始分数加权不行吗？不行。不同通道的原始分数分布差别很大，哪怕都是 0~1，某个通道偶尔冒出一个虚高的分，也会把整个排序带偏。而"排第几名"只看名次、不看具体分值，天生不怕这种极端值。所以最终是用名次打底保稳定，用原始分数和加分项做微调，用通道权重做倾向引导，三者配合，既稳又准。
别让高价值证据被丢弃
融合排完序，系统默认取前 40 条进入后续环节。但只按分数取前几名有个风险：一些"分数不算最高、却特别关键"的证据会被挤出去，比如知识图谱里的实体关系证据、跨文档的社区总结、从多份文档找答案时其他文档的正文。
所以在挑候选时留了个"保底"机制：如果前几名里一条合格的知识图谱关系证据都没有，就从后面补一条进来（替换掉其中最弱的一条普通证据）；如果这次是自动从多份文档里找答案，也会给每份文档都留出一定的正文名额。这些"保底"靠的是证据本身的特征——有没有真实出处、来自哪个通道、质量分高不高、够不够多样，不靠猜业务关键词。
交叉编码器精排
融合给出的是一个"还不错"的粗排，但它本质上还是靠名次、分数、加分项这些统计信号排出来的，并没有真正"读懂"问题和候选到底搭不搭。所以融合之后，再接一道 交叉编码器精排。
交叉编码器和向量检索的思路不一样。向量检索是把问题和文档分别编码成向量，再算它俩的距离，快但粗。交叉编码器是把"问题 + 这条候选"拼在一起整个塞进模型，让模型直接判断这条候选到底有多相关。因为模型能同时看到问题和候选、做更细的比对，所以判断更准，但也更慢——正因为慢，只在融合后筛出来的那批干净候选（默认 24 条）上跑，不在全量上跑。
精排这一步由专门的交叉编码器重排模型负责，默认使用 BGE 重排模型。
系统不会用简单的关键词排序冒充交叉编码器精排。模型、依赖、网络或返回结果出现问题时，会明确记录失败原因，也不会写入虚假的精排分和精排名次，而是按照精排前的融合榜继续挑选最终证据。精排成功时使用模型给出的新排序，失败时使用原来的融合排序，整个过程都可以在观测面板中看到。
下图从功能视角串起了完整链路：五通道同时查找、合并重复证据、计算统一融合分、补全上下文、选出前 24 条进行交叉编码器精排、在精排失败时保留融合排序，以及最终挑选回答证据。观测面板会记录各通道命中数、候选数量变化、融合分、精排分和排名前后的变化。
父子块聚合：小块检索、大块回答
这是整条链路里最精巧的一个设计。
前面切块篇讲过，文档会切成大块（父块）和小块（子块）。检索时用的是 小块——小块语义集中、话题单一，更容易被向量检索精准命中。但如果直接把命中的小块拿去当证据，上下文往往不完整，模型可能"只见树木不见森林"。
所以命中小块后，系统会自动往上找到它所属的大块，用大块作为最终喂给模型的证据。
检索用小块保命中精度，回答用大块保上下文完整性。 一句话说清了这个设计的价值。
下面这张管理端的知识产物关系图，把这条链路落到了实际产物上：原始文档先生成解析块，再向下关联父级块、检索子块、图谱证据和分层摘要。检索命中子块后，系统可以沿着这条关系链回到父块和原文；其他检索通道也复用同一套来源关系完成证据追溯。
图：从原始文档到解析块、父子检索块及下游知识产物的可追溯链路。
结构化表格问答：表格通道怎么工作
前面把表格列成了五个通道之一，这里单独展开，因为它和其他通道的思路完全不同——走的是"结构化查询"而不是"文本检索"。
先看一个普通 RAG 一定翻车的场景：文档里有张销量表，用户问"2025 年 Q3 华东区的销量是多少"。如果把表格拍平成一段文本丢进向量库，行和列的对应关系就全丢了，模型看到一堆数字根本分不清哪个对应"华东 + Q3"。
表格通道的做法是完整保留表格的行、列、单元格结构以及每个格子在原文里的位置：
- 结构化入库：文档解析时产出的表格会保留原始的行列、单元格和它们在页面上的位置坐标，单独存成结构化表格数据，而不是拍平成一段文字
- 受控查询计划：用户的自然语言问题不靠关键词硬猜，而是由一个"查询计划建议器"给出方案——先由固定规则给候选，再让大模型补充受控建议，两者都要过一道白名单校验（用哪张表、哪些字段、做什么运算——计数/求和/最大值/最小值/分组，加什么过滤条件——等于/包含/大于/小于等，全都得在允许范围内），校验通过了才真正去查表
- 精确到单元格：表格证据带着完整的定位信息（命中的行号、列名、具体单元格和位置坐标），管理端可以从回答里的引用直接跳转到那张表，并高亮命中的单元格
证据治理：够不够、多不多、准不准
召回和精排解决的是"找得到、排得对"，接下来还有三个问题要治理。
没有证据？直接短路
如果所有通道跑完，最终一条有效证据都没召回到，系统不会硬着头皮让模型回答，而是直接短路返回一句预设话术：
当前没有从已接入文档中检索到足够证据，暂时不能给出可靠结论。
这是防幻觉最直接、最有效的手段。宁可告诉用户"没查到"，也绝不让模型凭空编。
证据太多？预算裁剪
反过来，如果证据召回得太多，会把模型能读的上下文塞满，既费钱又稀释重点。所以有一套按字数来的预算控制：
| 限制项 | 默认值 | 作用 |
|---|---|---|
| 单个子问题的证据上限 | 2,200 字 | 防止单个子问题证据过多 |
| 全部证据总量上限 | 5,200 字 | 控制喂给模型的总证据量 |
| 单个大块最大字数 | 2,200 字 | 防止某个大块占用太多预算 |
| 最终证据条数 | 6 条 | 最终喂给模型的证据数量 |
超出预算时，按相关性和证据的作用动态裁剪，优先保留高价值证据（同章节的正文、知识图谱里的关系原话、结构树对应的原文等）。
引用准不准？引用修复
模型生成回答时会标注引用编号 [1][2]，但模型标的引用不一定准——可能引错了，也可能该引的没引。所以答案生成完之后，还有一道 引用修复。
它的做法是用交叉编码器，把回答里的每一句话和候选证据逐一比对，找出真正支撑这句话的那条证据，记下这句话对应哪段引用原文、出自哪个分块、第几页、在页面的什么位置。至于什么时候触发修复、怎么过滤、怎么发给前端展示和归档，都由主链路来决定。
有一条硬原则：知识图谱、结构树、表格这些通道给出的最终引用，都必须能追溯到一段真实、可引用的原文——知识图谱要追到关系证据的原话，结构树要追到摘要背后的原文，表格要追到具体的行和单元格。绝不能让引用指向一个"只有概括、没有出处"的东西。上下文可以往外扩，但引用最终一定要落在真实原文上。
面试怎么聊这块
Q：你们的混合检索是怎么融合多路结果的？
A：我们有五个检索通道，各自打的分根本没法直接比。融合用的是加权融合：先用"排第几名"打底（跨通道能比、又抗极端值），再叠加原始分数和构建期算好的加分项做微调，最后乘以每个通道的信任权重和检索意图倍率。这样高质量通道、以及正好命中这次问题类型的通道，能拿到更高权重。融合完还会接一道交叉编码器精排。
Q：为什么要接一道交叉编码器精排，直接按检索分排序不行吗？
A：向量检索是把问题和文档分别编码成向量再算距离，快但是太粗糙。交叉编码器是把问题和候选拼在一起整个塞进模型，让模型直接判断这条候选相不相关，更准但更慢。所以我们只在融合后筛出来的那批干净候选（24 条）上跑精排，不在全量上跑，兼顾效果和性能。
Q：怎么防止模型幻觉？
A：从架构层面做了三道防线。第一，没有有效证据时直接拒答，不让模型编。第二，证据按字数预算裁剪，避免上下文被无关内容稀释。第三，答案生成后做引用修复，用交叉编码器校验每句话到底有没有证据支撑，引用必须能回溯到真实来源。
Nexus Agent Pro 项目的申请
Nexus Agent Pro 项目是本人根据大厂的真实开发思路，花费了很多的精力和时间认真打磨出来的，也为了更好的保护已经加入星球的小伙伴的权益。所以决定 Nexus Agent Pro 不再进行开源，而是将项目放到了私有库中。
普通版本的 Nexus Agent 项目依然还是正常开源，本人也依然会继续进行优化。开源地址为： 👉 点击这里跳转到 Nexus Agent
已经加入星球的小伙伴，可以按照以下指示来申请和学习 Nexus Agent Pro：👉 点击这里学习 Nexus Agent Pro