本文在 RAG-to-SQL 的基础上，介绍了：
• 什么是 函数RAG
• 函数RAG的特点
• 工具和智能体的结合
• 如何使用函数RAG
• 函数RAG的使用场景分析和启发
函数RAG(Function RAG) 是什么
上一篇讲训练的文章提到，VannaAI 经典训练方法 Question-SQL 的方式，而 Function RAG 就是这种方式的升级， 讲训练转换为可调用的模板，这个可调用模板称之为函数。
在使用函数RAG的时候，LLM仅决定使用哪个函数（模板）、以及函数（模板）的参数是什么，这样就保证了输出的一致性， 同时能显著加快SQL生成的过程。
下面简单画了个架构图， 能清楚的看到函数RAG的执行过程：
函数RAG的特点
函数RAG的特点和优点也是我们前面讲到他解决的问题：
• 基于模板生成SQL：大模型保证SQL和用户查询相关，模板保证SQL的准确性，和执行的速度。
• 增强安全性：函数RAG不仅能防止提示注入等安全问题，还可以预设模板嵌入权限等逻辑保障数据安全。
• 用户特定的查询：可以在查询中嵌入用户信息，而不必担心数据泄露，执行个性化问题：比如查询：
• 我最近的订单有哪些？
• 我这个月的考勤？
• 我部门的业绩？
• 集成图表代码的生成：前面提到 Vanna.AI 生成的图表太单一，使用 函数RAG 嵌入SQL对应的可视化代码，能够达到可定制的图表展示。
• 多语言支持：函数RAG 的架构设计为被各种语言（JS,Java等）集成提供了可能性
智能体和工具集成
我看了下源码，Vanna.AI 正在很好的抽取和模块化核心逻辑，配合 函数RAG的功能，我们能很方便的吧 VannaAI 集成响应的工具调用，实现数据应用的智能体。
详细解释一点，就比如我们去年文章展示的 BI 增加工具调用一样：
基于《AIGC时代的用户体验和接口设计》的交互规范，我们可以稍微改造一下就让其初步具备 Agent 的能力：
这个的优点就是基于 「函数」 来定制不同的可能的行为动作。因为除了单纯的看数据，大部分的查询我们都是有使用数据的意图的。
比如：当你查询你本周的工作日报时，可能的动作就是**「发送工作周报」**。
函数RAG使用过程
下面展示下 「函数RAG」的使用过程。
VannaAI 界面山点击 Functions 菜单，可以看到当前已经创建的 Functions，如果没有的话可以点击 New 来新建：
新建的过程也很简单，直接输入你的问题，等待 Vanna.AI 的执行，比如我们「有多少个艺术家」：
点击 「Yes, create function」，就可以创建一个函数。下图展示函数创建的结果，包含：
• 唯一的函数名称
• 函数的问题模板
• 函数的参数（这个例子没有）
下面我们创建另外一个函数，提问： 销量最高的五个国家，可以看到创建的函数里面多了一个 limit 的参数：
再次提问：销量最高的10个国家，可以看到 Vanna 执行了刚刚创建的函数，并且把参数设置为 10，直接执行了 SQL， 而且我们可以明显感到执行的速比BI之前快了很多。
UI 的局限
当我提问 最近20年开票最多的三个客户 来创建函数时，
创建的函数只有一个 years 参数，并没有 limit 这个参数。
重新执行查询 最近10年开票最多的五个客户，发现匹配到了函数，参数也修改了，但是只修改了一个。
查看 SQL 也发现并没有把 五个客户 的条件给放进去。
遇到这种情况，我们的解决方案也很简单，使用代码创建函数即可，你可以不依赖LLM，更灵活和准确的控制函数的构成：
vn.create_function(question=..., sql=..., plotly_code=...)
何时使用
类似问题查询
最终用户经常会询问类似问题，那么函数 RAG 可以很好提升效率和准确率。
限制用户查询
如果产品期望限制用户的查询，只允许用户查询经过批准和确认的特定查询及分析。此时 Function RAG 是能够确保运行特定查询的好方法。
限制用户查询数据范围
传统 Text 2 SQL 无法应用到企业生产最重要的问题就是「大模型的不确定性」和**「无法限制数据范围」**。
而 FunctionRAG 就能很好的解决这两个问题，他可以保证用户最终能看到正确的数据。
提高速度
如果你的场景查询范围有限，复核上述特点，那么强烈建议你使用 FunctionRAG，因为他可以极大提升运行速度。
总结
RAG-to-SQL 为基于大模型的 SQL 生成（或者说是 Text-to-SQL）开辟了新的领域，那 Function RAG 就像是 是这个新领域的一条新道路。
而且 LLM -> RAG -> Function 的产品功能路线和设计思路也给了我们极大的启发， 让普通的东西经过优雅的设计绽放不一样的色彩。
--- END ---
