如何利用 Function Calling 将 LLM 接入企业私有数据库实现实时查询

大模型在面对企业私有数据时，最尴尬的不是它不聪明，而是它在“一本正经地胡说八道”。传统的 RAG（检索增强生成）虽然解决了知识库问题，但在处理“上个月销售额是多少”这种需要精确计算和实时聚合的结构化查询时，检索片段根本没用，因为 LLM 无法通过阅读几段文本得出统计结果。

Function Calling（函数调用）本质上是给 LLM 递了一把“钥匙”，让它从一个单纯的聊天机器人变成一个能够调度 API 的控制器。在这种架构下，LLM 不再尝试直接回答问题，而是将用户的自然语言翻译成数据库能听懂的参数。

一个典型的链路是：用户提问 → LLM 识别意图 → 触发特定的 query_database 函数 → 后端执行 SQL → 将查询结果回传给 LLM → LLM 组织成自然语言回答。

对于开发者来说，核心挑战在于如何定义 Function 的描述（Description）。如果描述模糊，LLM 很容易传错参数。一个高效的定义应该是强类型的，并且包含明确的枚举值。例如，定义查询订单状态的函数时，不要只写 status，而要写 status: 订单状态，可选值为 ['pending', 'shipped', 'delivered']。

实现这个流程的代码逻辑大致如下（以 Python 为例）：

# 定义函数描述，告知 LLM 如何调用
tools = [
    {
        "type": "function",
        "function": {
            "name": "get_customer_revenue",
            "description": "查询特定客户在指定时间段内的总营收",
            "parameters": {
                "type": "object",
                "properties": {
                    "customer_id": {"type": "string", "description": "客户唯一识别码"},
                    "start_date": {"type": "string", "description": "开始日期，格式 YYYY-MM-DD"},
                    "end_date": {"type": "string", "description": "结束日期，格式 YYYY-MM-DD"}
                },
                "required": ["customer_id", "start_date", "end_date"]
            }
        }
    }
]

这种方案对行业的实际影响在于，它打破了 LLM 的“静态知识”诅咒。企业不再需要为了让 AI 了解实时数据而去频繁地训练微调模型，而是通过构建一套标准的 API 接口层，将数据权限控制在后端。

这意味着 AI 应用的重心正在从“Prompt 工程”转向“API 工程”。未来的竞争力不在于谁会写提示词，而在于谁能构建更细粒度、更鲁棒的工具集（Toolsets），让模型能够精准地在成百上千个函数中选择正确的那一个。同时，这也对数据库的安全性提出了更高要求，因为 LLM 生成的参数如果未经校验直接进入 SQL 语句，很容易造成注入风险，必须在函数执行层增加严格的参数校验和权限过滤。