RAG与SQL智能体协同架构在金融知识管理中的实践

1. 项目概述：当RAG遇到SQL的化学反应

去年在金融行业做知识管理系统时，我遇到个典型场景：业务人员既要查产品文档（非结构化数据），又要实时获取客户账户余额（结构化数据）。传统做法是分别开发两个系统，直到发现用LangGraph框架可以将RAG和SQL智能体结合——这就像给分析师配了个既懂文档又懂数据库的超级助手。RAG（检索增强生成）负责处理PDF/PPT等文件，SQL智能体则实时查询数据库，两者协同工作的效果让业务响应速度提升了3倍。

2. 核心架构设计

2.1 双智能体协作模式

我们采用"路由-执行"架构：

1. 输入问题首先进入路由智能体（使用BERT分类器）
2. 判断问题类型后分发到：
   • RAG智能体：处理"产品条款包含哪些免责内容？"类问题
   • SQL智能体：处理"用户A当前账户余额是多少？"类问题
3. 结果经LangGraph编排后统一返回

实测中，关键是要在路由阶段设置超时熔断（建议300ms），避免复杂问题卡死流程。曾因未设置熔断导致线上事故——有个模糊查询同时触发了两个智能体，引发循环调用。

2.2 技术栈选型要点

经过对比测试，我们的技术组合：

• RAG部分：LlamaIndex + ChromaDB（比FAISS节省30%内存）
• SQL部分：SQLAlchemy + 自定义校验层（防止SQL注入）
• 编排层：LangGraph（比LangChain更轻量）

特别提醒：不要直接用LangChain的SQLDatabaseChain！它生成的SQL缺少校验，我们曾在测试环境误删过整张表。正确做法是像这样封装执行器：

python复制def safe_sql_execute(query):
    if "drop" in query.lower() or "delete" in query.lower():
        raise PermissionError("高危操作被拦截")
    # 其他校验逻辑...
    return engine.execute(query)

3. RAG模块深度优化

3.1 知识库构建的坑

初期直接用的PDF文本提取，结果发现：

• 表格内容错乱（解决方案：用Camelot库专门提取表格）
• 页