引言
近年来，大模型能力不断增强，已经进入了企业应用场景。其中Text2Sql虽能让非专业人员通过自然语言查询复杂数据库，但在一些对精确性、透明度和安全性有着极高要求的关键领域，例如金融、医疗、核电等应用领域，任何数据误差都可能带来巨大的安全隐患。
此类领域经过几十年的累积与修改，结构复杂、表关系混乱，完全依赖大模型NL-to-SQL能力将难以适应，极易生成错误或低效SQL语句。为此，「本文作者并没有完全依赖大模型text2sql能力，而是针对核电数据库检索应用场景下构建了一个比较实用Text2Sql方案，此方案可同样适用于金融、医疗等对准确要求极高的应用场景」。其核心理念是：不再让LLM直接生成复杂的SQL查询，而是将其能力聚焦于调用一套预先定义、经过专家验证和优化过的“功能函数”
https://www.arxiv.org/pdf/2506.08757
背景介绍
长期以来，自然语言到SQL（NL-to-SQL）的方法被认为是实现核电站数据便捷检索的有效途径。这种方法允许用户通过日常语言提问，系统自动将其转换为数据库可执行的SQL查询，从而简化了数据访问的流程。然而，在实际应用中，尤其是在核电站这样拥有庞大且历史悠久的数据库环境中，NL-to-SQL展现出了其固有的局限性。
首先，
「准确性与透明度」核电站的运营数据关系到巨大的安全风险和决策准确性，任何微小的查询错误都可能导致严重后果。然而，NL-to-SQL生成SQL查询的过程对于非专业的用户而言往往是一个“黑箱”操作。用户无法理解和确认模型生成的SQL语句，隐藏错误难以发现。在关键决策场景下，人工复核成为不可或缺但又耗时耗力的步骤。
其次，「数据库结构复杂、表关系混乱」核电站的数据库通常经过数十年的迭代和修改，积累了大量的历史数据和复杂的表结构。这些数据库可能存在不一致的命名约定、冗余的数据字段以及复杂的多表关联，模型需要理解这些复杂的语义和结构，并将其映射到正确的SQL语句。即使是目前最先进的LLM，也难以保证100%的准确性。
此外，「可维护性」也是一个问题。随着业务需求的变化和数据库结构的演进，NL-to-SQL模型需要不断地进行调整和优化。每一次数据库模式的修改，都可能意味着对模型训练数据的重新收集、模型的重新训练以及性能的重新评估。
正是在这样的背景下，本文提出了一种基于函数调用LLM的新方法，旨在为核电站数据检索提供一个更安全、更可靠、更高效的解决方案。
基于函数调用LLM的新范式
基于函数调用LLM的新范式核心理念是：不再让LLM直接生成复杂的SQL查询，而是将其能力聚焦于调用一套预先定义、经过专家验证和优化过的“功能函数”。其主要工作流如下：
「1.预定义与封装SQL逻辑」：首先，识别核电站数据检索中常见的用例和查询模式，并为每一个模式定义一个特定的功能函数。这些函数内部封装了优化后的SQL查询逻辑，从而从根本上保证了其准确性和安全性。例如，查询“所有工单”或“特定设备的历史维护记录”等，都将对应一个预设的功能函数。这类似于为LLM提供了一套“安全操作手册”，确保它只能执行那些已被证明是安全和有效的操作。
「2.LLM的角色转变」：当用户提交语言请求时，LLM不再试图从头开始生成SQL语句。相反，它会分析用户的意图，并根据其理解，决定调用哪一个或哪一组预定义的功能函数。这种转变极大地降低了LLM生成错误SQL的风险，因为它不再需要掌握复杂的数据库模式和SQL语法细节，只需理解用户意图并将其映射到对应的功能函数上。
「3.参数化与安全执行」：用户查询中的具体信息（如设备ID、日期范围、报告类型等）会被LLM提取出来，作为参数传递给被调用的功能函数。这些参数在传递之前，通常会经过严格的验证，以防止SQL注入等恶意攻击。功能函数在接收到参数后，会执行其内部封装的SQL逻辑，并返回结构化的数据结果。整个过程都在一个受控的环境中进行，极大地增强了系统的安全性。
「4.辅助函数库的构建」：尽管这种方法引入了开发和维护功能库的初始成本，但本文也指出，现有的NL-to-SQL工具可以在函数代码的初始生成阶段提供帮助。这意味着可以利用这些工具快速生成初步的SQL查询，然后在此基础上进行人工审查、优化和封装成功能函数，从而将专家的工作重点从从头开始编写SQL转移到更重要的验证和优化上，提高了开发效率。
「5.多代理（Multi-Agent）系统架构」：为了实现这一复杂而健壮的系统，本文采用了一种多代理、函数调用的架构。整个系统由一个“主代理”（Main Agent）和多个“子代理”（Sub Agent）组成，每个子代理负责特定领域（如工单、维护计划等）的查询处理。
- 「主代理（Main Agent）」：作为查询路由器，它接收用户的自然语言查询，并根据查询意图将其路由到相应的子代理，或者直接进行回答（如果不需要数据检索）。
- 「子代理（Sub Agent）」：每个子代理都拥有一套针对其特定领域的功能函数，并负责调用和执行这些函数以运行SQL查询。子代理会维护交互历史，并在出错时进行重试，或者当主代理接收到不合适的响应时，主代理也可以尝试不同的子代理。此外，只有子代理才能实际调用和执行SQL查询的功能函数，这进一步增强了系统的安全性和可控性。
「6.迭代对话与重试逻辑」：为了提高系统的鲁棒性，主代理和子代理都会保留每次交互的历史记录，包括系统提示、用户查询、工具调用及结果、以及自身的回答。这种机制允许子代理在出现错误时（例如，调用了不合适的函数）进行重试。
如果主代理从子代理那里得到一个不合适的响应，它也可以尝试将查询路由给另一个子代理。这种内置的重试逻辑显著提高了系统在面对复杂或模糊查询时的成功率。
「7.日志记录与错误处理」：系统对每一步操作都进行详细的日志记录，包括用户初始查询、工具调用/结果以及最终响应。这不仅有助于故障排除，还能为系统优化提供宝贵的数据。LLM代理本身能够处理大部分错误（例如，判断何时需要重试），而那些LLM无法处理的错误则会被捕获并记录到数据库中，以方便人工排查和解决。
「8.结构化输出与类型强制」：为了确保数据交换的严谨性，系统选择JSON作为数据格式，并利用Pydantic模型来强制执行精确的数据类型（dtypes）和参数验证。任何不符合预定义模式的输出都会触发系统自动重试操作，OpenAI的结构化输出模式通过“约束解码”技术进一步增强了可靠性，确保输出严格遵守预定义模式。这极大地减少了因数据格式或类型不匹配而导致的系统崩溃或不可预测行为的风险。
通过这种方法，LLM的强大语言理解能力与专家验证的SQL逻辑相结合，有效弥补了传统NL-to-SQL的不足。「它将SQL查询的生成过程从动态、不可控的LLM推理，转变为对预定义、受控功能的调用」，从而在确保用户友好的自然语言交互的同时，大大提升了核电数据检索的准确性、透明度和系统可维护性。
实验结果
为了全面评估所提出的函数调用方法的性能，将其与传统的非函数调用（NL-to-SQL）方法进行了对比，并「采用了两种不同类型的评估指标」：LLM计算指标和人类专家评估的正确性指标。
LLM计算指标包括：
「答案相关性」：衡量响应直接且清晰地回答用户查询的程度，是否包含所有请求的方面，并使用精确的语言和结构。
「相关性」：在考虑用户查询和伴随的上下文（SQL查询结果）的情况下，评估答案是否有效地整合和利用了提供的SQL数据来丰富响应，并避免了查询与上下文证据之间的脱节。
「忠实性」：衡量响应在不引入外部假设的情况下，准确反映给定上下文的程度。确保答案中的所有主张或结论都直接由SQL查询结果支持，并严格遵守SQL输出中呈现的事实和数据，从而建立对答案完整性的信任。
在LLM计算指标方面，两种方法表现相似，函数调用方法略微优于非函数调用方法。
然而，「人类评估的正确性指标」则揭示了函数调用方法的显著优势。结果显示，函数调用方法在人类评估的正确性得分上明显优于非函数调用方法，获得了更高的平均得分。
结论
本文提出的函数调用方法，通过将大型语言模型（LLM）的能力聚焦于调用一套预先定义、经过专家验证的功能函数，而非直接生成SQL查询，为核电站数据检索带来了显著的准确性和可维护性提升。这种框架通过约束SQL生成过程和构建结构化的代理工作流，最大程度地降低了传统NL-to-SQL方法带来的风险，并增强了操作安全性。「此类方法同样适用于金融、政府、财务等对准确性要求极高的业务场景。」
AI-Agent文章推荐
[1]Gartner预测，2028年Agent应用将融入1/3的企业软件」
[2]大模型Agent | 构建AI-Agent的 5大挑战，及解决方案！
[3]盘点一下！大模型Agent“花式玩法”
[4]大模型Agent的USB接口--MCP
[5]2025年的风口！| 万字长文纵观大模型Agent！
[6]万字长文！从AI Agent到Agent工作流，一文详细了解代理工作流(Agentic Workflows)
欢迎投稿或寻求报道，联系：ainlperbot
