1. 引言在证券业务场景中自然语言交互式查询也就是让业务人员直接用普通话问合肥齐云山路营业部的存量有效户覆盖率在全公司排名第几这种问题一直是智能数据分析的圣杯命题。传统做法无非两条路一是写死几十个 SQL 模板然后做意图映射二是在通用大模型上狂塞 Prompt 规则。前者每新增一个指标口径就要改代码上线后者随着规则越来越多 Token 成本爆炸不说模型还容易上下文漂移。本文将深度拆解一个在生产环境运行超过数月的证券数据智能问答系统agent_ds_plus_v3.py。它不是简单的「大模型 数据库」调用而是一个精心设计的5-Agent 流水线 多级并行优化 私有知识库检索增强系统把「意图识别 → SQL 生成 → SQL 审查 → 回答生成 → 忠实度审计」这五个环节各自解耦为独立 Agent并引入了私有知识库混合规则召回和推测执行等优化手段。2. 整体架构五段式流水线先上图让读者快速建立全局认知OUT_OF_SCOPEDIRECT_QUERY / ANALYTICAL_QUERYHARD_FAILPASSFAIL 回到Agent4PASS用户问题阶段0并行前置处理Agent1意图结构化解析 ‖ RAG Schema召回 ‖ PrivateKB业务背景召回Agent1 意图判断拒绝回答并引导阶段1Agent2 Text-to-SQL生成DeepSeek reasoning 模式阶段2Agent3 SQL审查Fast Rule Guard (毫秒级) → LLM深审 (仅复杂题)阶段3Agent4 业务回答生成不喂SQL仅基于数据表格写自然语言Agent5 忠实度审计(仅排名/分位/中位数题触发)业务清洗兜底 → 最终输出注意亮点Agent2/3/4 之间存在两层并行机制——Eager Agent4在 SQL 执行成功后立即后台预跑与 Agent3 的 fast_rule 和深审完全并行对复杂题还有Speculative Agent4与 LLM 深审并肩作战。简单来说能并行的地方绝不串行。那么混合规则召回相比传统全量 Prompt 注入到底带来了多少实际收益下面这张表把差异量化出来对比维度传统全量 Prompt 注入方案本系统混合规则召回方案优化效果Token 消耗单次 Agent2 调用200 行 System Prompt约 2,500–3,500 Token按需召回System Prompt 缩减至约 1,000–1,800 Token单次调用 Token 节省30%–60%平均响应延迟90% 的 SQL 审查走 LLM 深审延迟集中在 2–5 秒约70% 的查询仅走 Fast Rule Guard毫秒级长尾复杂题才触发 LLM 深审简单查询延迟降至1 秒以内P50 延迟降低50%–70%规则维护成本每次新增/修改规则需改几百行 Prompt牵一发动全身规则越多维护越困难规则以独立.md文件存储新增一条规则只需新增一个文件索引启动时自动重建单条规则维护成本从「改几百行 Prompt」降至「新增一个文件」且规则可跨 Schema 复用这张表揭示了一个关键点随着业务规则从 5 条增长到 50 条甚至 100 条传统方案的 Token 消耗和维护成本会线性甚至超线性恶化而混合召回方案的成本几乎不随规则总量增长——因为每次只按需加载与当前问题相关的少数规则。如果再拉远一点看系统上线前后的整体效果下面这张对比图更直观P50 / P90 延迟对比传统全量 Prompt混合规则召回5000450040003500300025002000150010005000延迟 (ms)蓝色柱P50 延迟传统方案约 2,850 ms几乎每次调用都需 LLM 深审→ 本方案降至约 620 ms70% 查询经 Fast Rule Guard 毫秒级放行橙色柱P90 延迟传统方案约 5,100 ms → 本方案约 1,450 ms长尾复杂题才触发 LLM 深审并行推测执行进一步压缩长尾SQL 生成准确率 规则维护耗时对比传统全量 Prompt混合规则召回1009080706050403020100百分比 / 分钟蓝色柱SQL 生成准确率传统方案约 76%规则互相干扰造成上下文漂移→ 本方案约 93%按需召回强相关规则聚焦生成绿色折线单条规则维护耗时传统方案约 30 分钟/次翻阅数百行 Prompt 改一处→ 本方案约 2 分钟/次新增一个.md文件索引自动重建注以上数据来自该系统在证券问数场景下 1,200 条真实查询的离线回放评测传统方案和混合召回方案使用相同的测试集与业务规则集。这就是「让规则回归检索」所带来的可扩展性红利。3. 核心设计理念不只是写 SQL而是管规则领域 Text-to-SQL 的真正难点从来不是 SQL 语法——现在的大模型写SELECT ... FROM ... WHERE ...已经炉火纯青。真正的难点是那些藏在业务人员脑子里、文档里、Excel 公式里的隐性知识「覆盖率」到底取哪个表的哪个字段是BASE_EFFECTIVE_KH_RATE还是KH_ACTIVE_1_GX_RATE「前 10%」对正向指标和负向指标的解释方向是反的——正向指标是「前 10% 是最优秀的那批」负向指标反而是「前 10% 是最差的那批」。SQLite 里没有原生MEDIAN函数中位数怎么算多指标问题是否应该同表优先来避免跨表 JOIN传统做法是把这些规则全塞进一个超长 System Prompt——这有几个致命问题Token 成本爆炸15 条规则动辄 200 行 Prompt每次调用都传一遍。上下文漂移规则太多模型注意力分散反而容易在简单问题上犯错。维护灾难改一条规则要翻几百行 Prompt牵一发动全身。跨 Schema 迁移时规则没法复用。这个系统的解法很优雅把隐性知识组织成可检索、可演化、可验证的私有知识库——叫 PrivateKB。它不是死板的全文检索而是设计了一套「混合规则召回」机制召回层机制作用Layer 1Always-Onalways_includetrue的元规则无条件注入兜底核心规则比如「禁止对百分比字段直接 SUM」Layer 2硬路由按 Agent1 判定的sql_pattern匹配pattern_to_rules倒排索引精准注入与当前 SQL 模式强相关的规则Layer 3Hybrid RAGFAISS 语义向量 BM25 关键词 → RRF 融合排序 → 余弦阈值过滤召回可能相关的扩展规则Layer 4LLM 压缩当召回规则段超 2500 字符时用轻量模型精炼默认关闭极端情况下控制 Token以下是其核心实现逻辑的简化版伪代码defrecall_sql_rules(struct_json:dict,query:str)-list[Rule]:混合规则召回四层漏斗从精准走向泛化rules[]# ── Layer 1Always-On 元规则 ──forruleinprivate_kb.rules:ifrule.meta.get(always_include):rules.append(rule)# ── Layer 2硬路由sql_pattern → 规则倒排索引──patternstruct_json.get(sql_pattern)# 来自 Agent1ifpatternandpatterninprivate_kb.pattern_index:rules.extend(private_kb.pattern_index[pattern])# ── Layer 3Hybrid RAG 语义关键词融合 ──dense_hitsfaiss_index.search(query,top_k10)# BGE 向量sparse_hitsbm25_index.search(query,top_k10)# BM25 关键词# RRFReciprocal Rank Fusion融合两路排序mergedreciprocal_rank_fusion(dense_hits,sparse_hits,k60)# 余弦阈值过滤去噪forhitinmerged:ifcosine_similarity(query_embed,hit.embedding)THRESHOLD:rules.append(hit.rule)# ── Layer 4LLM 压缩可选──rulesdeduplicate_and_sort(rules,keylambdar:r.priority)total_charssum(len(r.content)forrinrules)iftotal_chars2500:rulesllm_compress(rules,query)# 轻量模型精炼returnrules这四层不是简单的「全跑一遍取并集」而是层级递进的漏斗设计Always-On 保证底线规则不失配硬路由按问题类型精准命中Hybrid RAG 在语义和关键词两个维度补充召回LLM 压缩作为最后一层兜底 —— 前两层已经命中时后两层可能只补充零到一条规则。而且整个 PrivateKB 的召回在阶段 0 与 Agent1 并行执行几乎不增加用户感知延迟。相比全量规则注入的 Fallback 模式RAG 路径可将 Agent2 的 System Prompt 缩减 20%–60%在长对话场景下 Token 节省非常可观。4. 五 Agent 深度协作的精妙之处4.1 Agent 1意图识别 结构化解析一石二鸟Agent1 不只给意图标签还输出一份包含 8 个字段的结构化 JSON——sql_pattern、indicator_direction正/负向、metrics指标中文名、target_branches等。这份 JSON 在后续被多个 Agent 消费Agent 2根据sql_pattern构建「规则聚焦指引」告诉模型「这道题是分位排名类型请严格按照对应规则生成 SQL」根据indicator_direction决定PERCENT_RANK OVER (ORDER BY ... DESC/ASC)的方向。Agent 4根据indicator_direction选择正向/负向的排名解读指南。PrivateKB根据sql_pattern做硬路由精准召回对应规则。为什么特别提这一点因为很多同类系统只让 Agent1 输出一个简单标签后续 Agent 完全靠自己再推理一遍结构——不仅多了一次推理开销还容易出现 Agent1 说 A、Agent2 按 B 处理的不一致。4.2 Agent 3两级审计——让 70% 的查询毫秒级放行SQL 审查如果每次都走 LLM延迟暴涨不说成本也翻倍。Agent3 分两级Fast Rule Guard纯规则引擎毫秒级8 条硬规则覆盖常见的 SQL 生成陷阱——# 规则 4相对指标覆盖率/百分位禁止在 SQL 中直接乘 100# 规则 5分位问题禁止用 ROW_NUMBER应该用 PERCENT_RANK# 规则 6结果集聚合缺失检测——同一营业部名重复率 30% 就是忘了 GROUP BY# 规则 7SQL 文本静态分析——无 CTE 无 GROUP BY 无聚合函数 → 大概率遗漏# 规则 8PERCENT_RANK 必须配套「分位区间」列前10%/前25%/前50%等其中规则 6 的设计最值得学——它不看 SQL 文本SQL 是图灵完备的永远无法穷举所有遗漏 GROUP BY 的模式而是直接检查 SQL 执行结果集的营业部名重复率。看结果比分析意图可靠得多。LLM 深审仅复杂题触发只在 SQL 含PERCENT_RANK()或问题含「中位数」时才走 LLM 审计。审计 Prompt 里有一条重要指令「你的任务不是追求完美答案而是只拦截会导致最终回答明显错误的高风险 SQL。如果只是措辞、字段命名的轻微问题请输出 SOFT_WARN 而不是 HARD_FAIL。」这是刻意降低 Agent3 的攻击性——太严苛会把大量正确答案打回重写延迟雪崩。4.3 Agent 4不喂 SQL 给模型这是整个链路里看似简单但极有智慧的设计——Agent4 的 Prompt 里没有 SQL只有数据表格的 Markdown。喂 SQL 会诱导模型写出「根据 SQL 中的 PERCENT_RANK排名分位为 0.14…」这种技术话术而最终用户需要的回答是「您的营业部处于全公司前 25% 梯队优于约 86% 的营业部」。Agent4 还根据数据是否已有「分位区间」列走两条路有分位区间直接告诉模型「分位区间已经算好了你直接读『前25%』这个词就行不要再自己换算」无分位区间告诉模型排名分位的数学含义让它自己翻译4.4 Agent 5忠实度审计——卡住最后一关Agent5 不审计 SQL那是 Agent3 的职责。它只审计 Agent4 的最终回答回答中的每个数字都能在数据结果里找到对应吗允许四舍五入/小数百分数转换有没有把 A 营业部的数据张冠李戴到 B 营业部结论和趋势有没有和实际数据反过来PERCENT_RANK的换算对不对0.14 说成「优于 86%」是正确的说成「优于 14%」就是反了。Agent5 不通过 → 回到 Agent4 重写回答不是回到 Agent2 重写 SQL。这个反馈回路很克制——只在 Agent4 层面修避免引发 Agent2→3→4 的全链路重跑。5. 混合规则召回与自演化闭环这是整个系统最值得凝练的价值点可演化性。传统方案每次发现新问题都得靠人工改 Prompt但这个系统的 PrivateKB 把规则做成了可以自行产生、存储、召回的知识单元——每条规则就是一个.md文件通过 front-matter 标记categorysql_rule区分。当线上出现一次答错时只要把新规则写进 PrivateKB下次同类问题就能自动召回。而且因为规则存在本地、索引在启动时重建不需要重新训练模型。这本质上是一个「检测失败 → 定位根因 → 规则化沉淀 → 自动召回」的自修复闭环。6. 总结这个系统的核心哲学可以用一句话概括让推理回归模型让规则回归检索。模型擅长理解自然语言和生成 SQL 结构但不擅长记住几十条业务口径——那是检索系统的事。通过「知识库化管理业务规则 多层混合召回 多 Agent 流水线并行 强兜底机制」这个系统在证券数据问数场景下同时做到了高准确率、可维护和可迁移。更关键的是这套设计范式可以低成本迁移到任何「有复杂业务口径、需要 Text-to-SQL」的垂直领域——只要替换 PrivateKB 中的规则和数据 Schema其他引擎逻辑几乎不用改。这是一套领域 Text-to-SQL 系统的可复用骨架。