本文记录我们自研 RAG 系统multi-agent-service的完整设计过程从存储选型、混合召回、父子块模型到多跳检索与 Agentic 工具循环对比知识图谱方案GraphRAG与开源项目 LightRAG、A-RAG 的取舍最后给出在单一问题与多跳问题两套基准上的实测数据与解读。所有数字均来自可复现的自动化评测。项目地址基于 FastAPI LangGraph 的多智能体推理服务一、我们要解决什么问题企业知识库问答的真实需求往往长这样文档类型杂PDF / Word / Excel / Markdown中文英文混排问题类型杂既有这个产品的保修期多久式的单跳事实题也有A 的导演的出生地式的多跳跨文档推理题工程要求高答案必须可溯源章节/页码权限必须收口配置必须能热更新模型必须能随时替换。通用的向量 RAG 能覆盖第一类问题但第二类多跳问题——答案分散在多个文档、需要先查 A、再顺着 A 查 B——是所有 RAG 方案的共同难题。本文就是这个问题的求解记录。二、总体架构一套混合存储 Agentic 检索的分层设计2.1 双库分工PostgreSQL 管事实Qdrant 管向量存储职责PostgreSQLragschema知识库 / 文件夹 / 文档 / 父子块 / 会话与消息的全量事实源向量命中后回查完整上下文、章节与页码Qdrant每知识库一个混合集合kb_{id}_v1存 dense 语义向量 jieba BM25 稀疏向量服务端 RRF 融合为什么不把向量塞进 PGpgvector检索吞吐与稀疏向量支持是主要考量为什么不只用 Qdrant答案溯源、父子块回查、权限过滤都需要关系型事实源。双库各干各的强项是这个系统一切设计的起点。2.2 父子块模型Small-to-Big两级切分父块 2000 字符 → 叶块 400 字符80 重叠只有叶块进向量库point id chunk id命中后回溯父块/文档给模型更完整的上下文切块策略可选auto有结构走章节/char/structurePDF 回填页码、markdown/docx 回填章节标题。2.3 检索与问答管线Agentic RAG提问 → condense 问题改写rewrite 模型无历史直通 → [检索子图] 混合召回dense 语义 jieba BM25 词法服务端 RRF 融合 → 反思LLM 判定上下文是否充分不足则改写重检索 → rerank 精排 → top-k → respond 生成答案 结构化 sources章节/页码/相似度问答父图用 LangGraph 编排checkpointerPostgres 池持久化多轮状态对话模型在 respond 节点通过工具循环自主决定是否再检索、用什么查询检索——这就是Agentic的含义检索策略交给模型而不是写死在代码里。三、多跳检索我们踩过的坑与最终形态多跳问题的难点在于答案文档往往不包含问题的原词问A 的导演的出生地桥接文档只讲A。我们先后实验并诚实证伪了三代方案关系词表匹配v1→ 通用领域不可取彻底删除实体共现桥接 候选塞终排→ 机制全部达标但对 top-10 贡献为 0/781——桥接段落被重排器按原问题打分淘汰检索层不应替推理层做消费决策受控 LLM 查询分解→ 分解成功率 96.7% 但质量贡献为零——子查询召回与既有通道高度重叠。最终保留的形态是检索层内生的多跳能力原问题检索hop 0安全底座 → 从首跳候选中提取实体锚点确定性规则无词表 → 逐跳独立检索每跳用自己的查询 → wiki 主题页门控导航通用页按统计判据过滤绝不注入检索输入 → 各跳候选文档级去重汇入合并池 → 对【原问题】做一次统一重排 → top-10核心原则只有一条各跳的职责是把单路召不回的文档送进决赛圈排序权全部交给对原问题的统一重排。跨跳比分不可比两把尺子任何跨跳比分数的花活都会引入碰运气的副作用——这是实验证伪换来的教训。四、相对知识图谱GraphRAG方案的优势与缺点通用领域我们没有选择知识图谱作为主存储这是权衡后的主动决策。优势维度说明零图构建成本通用领域对象类型多样、关系定义复杂实体建模与边属性设计难以提前稳定完成向量 BM25 对任意语料开箱即用链路简单、延迟可控检索是查表 重排无图遍历的不确定性延迟多跳由模型多轮检索完成强模型时代的多跳新解法实测表明强对话模型通过多轮自主检索隐式查询分解补齐了确定性多跳管线的缺口图遍历的边际价值显著降低增量更新友好文档增删只影响自身向量与块图谱方案需要同步维护实体/关系/社区摘要的一致性缺点维度说明显式关系表达弱A 与 B 是什么关系这类问题没有结构化的边可查依赖模型从原文归纳我们补建了离线实体关系索引实体锚定事实句 块指针作为可选增强全局主题归纳偏弱GraphRAG 的社区层次摘要擅长这个语料总体在讲什么的全局问题我们用 wiki 主题地图部分弥补但覆盖与更新成本更高多跳桥接收制于块级对齐实测多跳子集的文档级 Recall10 仅 0.10~0.21——桥接事实分散在未命中块内这是无图结构的结构性短板五、与 LightRAG、A-RAG 的对比5.1 vsLightRAGHKUDS图增强双层检索LightRAG 的核心是双层检索低层实体/关系知识图谱 高层主题社区摘要图与向量混合召回支持增量更新。维度本实现LightRAG多跳/关系问题依赖模型多轮检索实体关系索引为可选旁路KG 显式表达关系类问题天然更强全局主题问题wiki 主题地图LLM 离线生成覆盖有限社区摘要层次化全局归纳更强上下文完整性父子块回查给模型的上下文更完整原子块较碎上下文完整性弱一档工程复杂度无 KG 构建/维护链路简单需要构建并持续维护实体图谱产品化完成度权限收口、配置热更新、会话持久化、可溯源引用偏库/框架产品层需自建一句话LightRAG 用图换来了关系与主题问题的上限我们用父子块 完整产品层换来了工程下限的稳健。若语料关系密集、全局分析需求重LightRAG 值得借鉴若以企业文档问答为主、要求权限与溯源本实现的形态更合适。5.2 vsA-RAG分层检索接口的 Agentic RAGA-RAG 是与我们同源同构的方案——同样遵循“自主策略 迭代执行 交错工具调用ReAct”三原则同样把检索决策交给模型、同样提供chunk_read读块工具、同样无训练环节。真正的差异在于工具的分层方式维度本实现A-RAG检索工具粒度混合召回一体词法BM25 语义dense在单次knowledge_base_search内经 RRF 融合模型只决定“要不要再检索”不选粒度三粒度分离keyword词法 semantic语义 chunk_read模型自主选择粒度多跳导航确定性逐跳多跳hop 查询 wiki 门控 合并池作为检索层内生能力无专门机制纯靠模型迭代重排双塔重排定序后再给模型无工具返回即候选上下文管理父子块回查 工具结果预算裁剪Context Tracker 防重复读块 token 预算定位生产系统权限 / 配置热更新 / 可溯源引用研究框架batch runner / eval论文基座glm-5.3-flash可替换任意兼容模型gpt-5-mini强调 test-time scaling设计哲学差异一句话A-RAG 把“选什么粒度检索”也交给模型三工具分离更灵活但调用次数多我们把“词法语义”在一次检索里融合模型只决定检索轮次更收敛并把多跳与重排做成确定性工程层。参考数据与口径说明A-RAG 在 MuSiQue 上的 74.1% 是LLM-AccLLM 判定语义等价也算对其与我们同口径的Contain-Match 为 65.3%我们在 glm-5.3-flash 上 MuSiQue/HotpotQA/2Wiki 为 60.6/75.0/68.0。两者不可直接用单轮检索的 Hit10我们 musique 单轮仅 24%去对比端到端成绩——端到端口径下我们与 A-RAG 的 Contain-Match 仅差约 5pt。剩余差距主要来自test-time 预算A-RAG 跑 15 轮迭代 128k token 预算论文主打 test-time scaling靠堆算力换分数而我们采用 3 轮上限的收敛设计用可运维的延迟与成本换取了这部分边际分数。六、模型选型与本地部署角色模型 / 实现部署嵌入模型Qwen3-Embedding-4B本地 vLLM pooling 服务单卡RTX 4070 Ti Super实测吞吐约8000 tokens/s——百万字符级知识库全量向量化在小时级完成重排模型Qwen3-Embedding 双塔余弦相似度打分与嵌入同池化服务实测优于 0.6B cross-encoderQwen3-Reranker-0.6B 判别力不足分数压缩严重稀疏通道jieba 中英双语分词 BM25纯本地实现零模型下载中文词法召回的主力对话模型glm-5.3-flash云端 OpenAI 兼容 API数据库配置热更新可随时替换任意兼容模型两个选型心得嵌入与重排同源双塔是性价比之王一次部署两个角色且实测双塔打分胜过小参数量 cross-encoder——判别力并不随参数量线性增长嵌入吞吐决定工程效率单卡 8000 tokens/s 意味着换 embedding 参数或重建索引的迭代成本可控这是嵌入模型钉死在部署级、对话模型热更新策略能成立的前提。七、实测结果单一问题 vs 多跳问题7.1 检索层指标文档级LongBench 五子集 ×200 条测试集类型Recall10Hit10NDCG10MRRdureader中文多文档单一事实型0.9901.0000.5670.437multifieldqa_zh中文单文档单一事实型0.6740.7230.5220.497hotpotqa英文多跳多跳0.1750.5660.1820.3082wikimqa英文多跳多跳0.2130.4330.1370.170musique英文多跳最难多跳0.0970.2420.0860.124如何读这张表——两个口径回答两个不同的问题Recall10文档级全召回top-10 是否捞齐了该题的全部金标文档。多跳题平均 2~4 个金标文档桥接文档又不含问题原词单轮检索在数学上很难全中——数值低是口径严格不是检索器失效Hit10至少命中一个金标文档的题占比答对问题只需要一个含答案线索的文档。这才是与用户体验对应的口径——中文多文档场景 100% 命中单文档场景 72%即便最难的 musique 也有 24% 的单轮直接命中。7.2 Agent 级端到端问答完整对话图contain-match 判定配置多跳三子集准确率平均延迟强对话模型纯检索路径68.3%600 题 0 失败 0 超时78s强对话模型 分层确定性工具65.7%92s弱对话模型历史锚点纯检索路径34.5%38s三个数字连成一条完整的能力链检索单轮命中率 58%五子集加权 Hit10 模型多轮自主改写检索第一轮没中就换查询再搜 阅读理解 答案级判定答案文本出现即算对 端到端 68.3%解释检索指标低多跳 Recall10 仅 0.10~0.21与 QA 准确率高68.3%并不矛盾——前者量的是检索器捞全 gold 文档的能力工程诊断的严格尺子后者量的是用户拿到的答案对不对体验尺子。强模型用多轮检索和阅读理解补上了检索缺口而同模型下再加确定性检索工具的净贡献为零65.7% vs 68.3%统计不显著且延迟 18~60%——因此分层工具在生产配置中默认关闭仅在弱模型/小上下文场景按需开启。7.3 单一问题 vs 多跳问题的结构性差异单一事实型问题多跳跨文档问题检索 Hit1072% ~100%24% ~ 57%端到端准确率预期显著高于 68.3%60.6% ~ 75.0%瓶颈几乎无瓶颈检索即答桥接文档词汇弱重叠 需多步推理工程启示混合召回 重排已足够受益于强模型多轮检索检索侧增量优化收益趋零7.4 与外部方案的端到端对比Contain-Match 口径用与本文一致的Contain-Match判定把我们的多跳成绩与几个代表性方案放在同一张表里数据取自 A-RAG 论文/README基座为 gpt-5-mini方案基座模型MuSiQueHotpotQA2WikiNaive RAG单轮检索gpt-5-mini48.779.566.5GraphRAGgpt-5-mini39.174.970.7HippoRAG2gpt-5-mini52.575.079.7LinearRAGgpt-5-mini51.877.684.8A-RAG (Full)gpt-5-mini65.388.088.9本实现glm-5.3-flash60.675.068.0如何读这张表我们的位置多跳三子集上本实现显著超过 Naive RAG 与 GraphRAG与 HippoRAG2 相当距离 SOTAA-RAG还有一段差距差距归因与 A-RAG 的差距主要来自test-time 预算——A-RAG 跑 15 轮迭代 128k token 预算靠堆算力换分数我们采用 3 轮上限的收敛设计口径提醒上表是端到端 Contain-Match勿与 7.1 的单轮检索 Hit10 直接混比基座模型不同glm vs gpt-5-mini数字仅作量级参考。八、结语三条被证伪的路线与一个收敛的架构这个系统迭代过程中我们用带归因的自动化评测先后证伪了三条看起来合理的路线关系词表匹配、实体共现候选塞终排、LLM 查询分解——每次证伪都伴随代码的物理删除而不是留一个用户不会去关的开关。最终收敛的架构出乎意料地简单混合召回 确定性多跳门控 统一重排 强模型多轮推理。它证明了一件事在强对话模型时代RAG 的竞争力正在从检索管线的精巧转移到存储模型的合理父子块/双库 模型能力的充分释放多轮工具循环。检索层该做的是把证据找得到、读得到理解与推理请放心交给模型。技术细节与复现方式见 RAG.md评测脚本与全部原始数据位于test/dataset01/。