Querying Databases with Function Calling
Connor Shorten, Charles Pierse, Thomas Benjamin Smith, Karel D'Oosterlinck, Tuana Celik, Erika Cardenas, Leonie Monigatti, Mohd Shukri Hasan, Edward Schmuhl, Daniel Williams, Aravind Kesiraju, Bob van Luijt
cs.DB, cs.AI, cs.IR
2025-01-24
Weaviate把搜索、过滤、聚合和分组拆成Function Calling参数，用315条合成查询测8个模型。Claude 3.5 Sonnet精确匹配74.3%最高；布尔过滤约87.5%，文本过滤只有46.25%。
把数据库交给 LLM 当工具，业界默认两条路：一条是 RAG 式搜索，一条是 text-to-SQL。前者擅长非结构化文本，后者擅长结构化过滤和聚合，两边长期分开评测。SQL 还有另一层麻烦：不同库的方言差很远，Function Calling 目前又几乎约束不了「请生成一段合法 SQL」这种自由字符串。
Weaviate 团队换了接口：不让模型写 SQL，把查询拆成一组可选的 JSON 参数，搜索、过滤、聚合、分组和跨 collection 路由放进同一个 querydatabase 工具。问题变成现成的 Function Calling 模型，能不能把自然语言填对这组参数。
评测叫 DBGorilla，改编自 Berkeley Function Calling Leaderboard 和 Gorilla 的 Self-Instruct 流程。先用 GPT-4o 生成 5 套合成业务库，每套 3 个相关 collection，每个 collection 固定 4 个字段：两个文本（其中一个可搜索）、一个数值、一个布尔。五个域是餐厅、诊所、课程、旅行规划、视觉艺术。库与库之间没有外键。
然后穷举合法的算子组合，每种组合用结构化输出生成一条必须用上全部指定算子的自然语言，再加一轮 Reflexion 校对。最终 5×63=315 条查询。评测只跑 Function Calling 的第一步：模型要么给出工具参数，要么直接回答；不调用工具记 0 分。工具描述压在 1024 token 以内，因为多家厂商的 Function Calling SDK 有这个上限。collectionname 是唯一必填参数，取值限制在当前 schema 的枚举里。
主指标是精确匹配，预测 API 与标注完全一致才得分。AST 分数把 collection 选对记 40%，搜、滤、聚、分组各 15%；搜只看用没用，不看文本像不像，过滤、聚合、分组必须值完全相同。另外还有 collection 路由准确率、不调用工具的比例，以及用 LLM 当裁判的偏好排序。测了 8 个模型、5 个家族：Claude 3.5 Sonnet、GPT-4o、GPT-4o mini、Gemini 1.5 Pro、Gemini 2.0 Flash（实验版）、Command R+、Command R7B、Llama 3.1 8B Instruct。
精确匹配的第一档挤在 70% 出头：
| 模型 | Exact Match | 备注 |
| Claude 3.5 Sonnet | 74.3% | AST 0.973，复杂查询 72.1% |
| GPT-4o mini | 73.7% | 全量评测只要 0.12 美元 |
| GPT-4o | 71.8% | 简单查询 87.5% |
| Gemini 1.5 Pro | 70.2% | 偏好排序加权第一 |
| Command R+ | 59.4% | 路由仍有 94.3% |
| Gemini 2.0 Flash (exp) | 37.1% | 53.97% 的题直接不调工具 |
| Llama 3.1 8B Instruct | 32.1% | 不调工具 21.90% |
头部分模型 collection 路由在 96%–98%。简单查询只要 1 个参数，GPT-4o 到 87.5%，Claude 到 77.5%；Claude 的复杂查询（3 个及以上参数）仍有 72.1%，掉点不大。
按算子拆开，布尔过滤是最稳的一块：GPT-4o 和 Claude 都是 87.5%。同一对模型的布尔聚合掉到 62.5% 和 66.25%。文本过滤是明显短板：Claude 46.25%、GPT-4o mini 42.50%、GPT-4o 37.50%，常见错误是把字段上的精确匹配写成语义搜索。GPT-4o 跨 5 个 schema 的波幅只有 5.64 个百分点（餐厅 73.44% 到视觉艺术 67.8%）；Gemini 2.0 Flash 从 57.81% 掉到 23.44%。
GPT-4o 上的消融几乎不动：加 rationale 到 73.2%，打开并行工具 71.2%（平均 1.21 次调用），一库一工具 72.3%，改用 structured generation 72.8%。裁判偏好和精确匹配对不齐：GPT-4o mini 拿下 29.0% 的第一名，Claude 精确匹配最高，第一名比例只有 4.5%。315 条里只有 5 条让 8 个模型给出完全相同的预测。
对要接数据库的 agent，这篇给的是一份可复用的工具 schema，不是又一个 SQL 方言。搜索和结构化算子可以写进同一个 Function Calling 定义，映射到具体库的查询语言是工程问题。GPT-4o mini 用 0.12 美元跑完全部 315 条，分数几乎贴着 Claude，更接近能天天回归的评测成本。
文本过滤和语义搜索分不清，是现在就能踩到的坑：用户说「名字等于某串字符」，模型容易改写成向量搜索。schema 如果能多用布尔和数值字段，这篇的数字显示会好做很多。并行调用、一库一工具、structured output 在 GPT-4o 上几乎没有额外分数，优先把工具参数本身设计清楚，比换调用姿势更值。
这是合成基准上的渐进结果。没有执行正确率，没有多轮改写，没有真实业务库。
作者自己把下一步写得很清楚：每套只有 3 个 collection、4 个字段，没有外键，每种算子组合只生成一条自然语言。真实仓库的表数量、命名混乱、空值和 schema 漂移都不在当前分布里。评测停在单步 Function Calling，AST 对 search 文本不做相似度判断，工具描述被 1024 token 卡住。LLM 裁判和精确匹配打架，说明「结构对」和「看起来好用」不是一回事。实验代码开源在 weaviate/gorilla。