家人们谁懂啊！现在用大模型做 NL2SQL（把自然语言转成 SQL 查询），看着方便，背地里烧钱烧得心疼。尤其是企业里数据库多到爆炸的时候，要把所有数据库的元信息都塞给大模型当提示词， tokens 直接飙上天，成本跟着翻跟头。但今天要聊的这个「Datalake Agent（数据湖特工）」，直接把这个坑填上了 —— 最多能少用 87% 的 tokens，花钱少了，处理复杂查询还更给力，这波操作我直接吹爆！

先跟大家掰扯下为啥之前的 NL2SQL 这么费钱。咱们用大模型处理表格数据的时候，要让它懂怎么写 SQL，就得告诉它数据库的结构、表名、字段类型这些「元信息」。要是只有一两个小数据库还好，可企业里动辄几十上百个数据库，表加起来几百张，所有元信息堆进提示词里，那 tokens 数量能从几千涨到几万，OpenAI 的 API 费用可不是按字算，是按 token 算啊！之前有研究就说，提示词超过 1000 个 tokens，GPT 处理表格数据就跟瞎猜差不多，既费钱又不准，这不纯纯大冤种吗？

而这个 Datalake Agent 的思路就特别清奇：它不一次性把所有元信息都喂给大模型，而是搞了个「互动循环」，让大模型像侦探查案一样，只拿自己需要的信息。具体咋操作呢？分三步走，每一步都透着聪明劲儿。

《ChatBI核心技术》是刚上市的新书，本书旨在为读者提供一个全面的ChatBI学习框架。从基础概念到核心技术，再到实际应用场景，书中详细介绍了ChatBI的定义、特点、与传统BI的区别，以及其在企业决策支持、数据分析民主化、即时数据洞察等多场景中的应用。书中还深入探讨了提示工程、AI智能体、检索增强生成、大模型微调等关键技术，并通过实战案例展示了如何构建AI智能体和业务知识库，以及实现数据智能查询与可视化等功能。此外，书中还讨论了对话理解、智能分析、用户交互等重要环节，帮助读者全面掌握ChatBI的技术实现和应用思路。

第一步是「信息获取」，就像侦探先摸清楚整个案发现场的布局。Datalake Agent 给大模型准备了三个「专属指令」：想知道有哪些数据库，就用 GetDBDescription 调数据库的概要；确定好要查哪个库了，用 GetTables 列出库里的所有表；知道表之后，再用 GetColumns 看表里的字段名和类型。比如你想查「2015 年有多少场 F1 比赛」，它不会先把体育、医疗、电商所有数据库的信息都调出来，而是先定位到「F1 相关数据库」，再找「比赛记录表」，最后看表里有没有「比赛年份」「比赛场次」这些字段，多余的信息一点不碰。

第二步是「迭代优化」，这步特别关键，像侦探查案时不断调整方向。大模型先从宏观的数据库概要入手，慢慢聚焦到具体的表和字段，要是发现找错表了，还能退回去重新选，不用从头再来。比如你问「H&M 里 40 岁以下的顾客有多少」，它先找「H&M 用户数据库」，再看「用户信息表」，要是发现这张表没有「年龄」字段，不会死磕这张表，而是退回去看看有没有「用户 demographics（人口统计）表」，直到找到有用的信息为止。这种灵活的循环，能确保每一步拿的都是有用的信息，不浪费 tokens。

第三步就是「生成查询」，信息找全了，就用 DBQueryFinalSQL 指令让大模型写 SQL，然后通过专门的接口执行。整个过程就像给大模型配了个「信息筛选助手」，只给它递有用的「线索」，没用的一概不拿，tokens 自然就省下来了。

当然，光说不练假把式，咱们得看实际测试结果。研究团队用了 OpenAI 的 GPT-4-mini 做实验，选了 23 个数据库，其中 5 个是真实的 RelBench 数据库，18 个是模拟企业场景的数据库（涵盖体育、政治、商业这些领域），还专门做了 100 个「表格问答任务」，既有简单的单表查询（比如「H&M 有哪些会员等级」），也有复杂的多表查询（比如「Stack Exchange 上评论最多的帖子有多少条评论」），分了三种场景测试：42 张表、159 张表、319 张表，就想看看数据量变大时，这俩方法的表现到底差多少。

先看性能，一开始的时候，传统的「直接提示法」（就是把所有元信息一次性塞给大模型）表现还不错，42 张表的时候，正确率比 Datalake Agent 高一点。但数据量一上来，差距立马就拉开了 ——159 张表的时候，直接提示法的正确率掉得厉害，尤其是复杂任务，正确率只有 32%，而 Datalake Agent 还能保持在 55.3%；到 319 张表的时候，直接提示法的复杂任务正确率只剩 29.3%，Datalake Agent 还稳在 56.3%。这说明数据越多、查询越复杂，Datalake Agent 的优势越明显，再也不用怕大模型「看太多信息反而变笨」了。

再看大家最关心的 tokens 用量，这直接关系到钱包厚度。从图 2 能清楚看到，Datalake Agent 的 tokens 用量特别稳：42 张表的时候平均用 3670 个 tokens，319 张表的时候也就涨到 4264 个，几乎没怎么变；但直接提示法呢？42 张表用 7407 个 tokens，319 张表直接飙到 34602 个，翻了快 5 倍！这意味着数据量越大，Datalake Agent 能省的 tokens 越多，成本自然就降下来了。

咱们再算笔明白账，按 1000 个任务来算，用 OpenAI o1 模型的话，319 张表的场景下，直接提示法要花 519.03 美元，而 Datalake Agent 只要花 2.02 美元，差了 250 多倍！就算用其他模型，比如 GPT-4-mini，直接提示法的成本也是 Datalake Agent 的 8 倍。对于每天要处理成千上万查询的企业来说，这省下来的钱可不是小数目，买奶茶能喝到明年！

不过话说回来，这个 Datalake Agent 也不是完美的，它有个小 bug：偶尔会陷入「无限推理循环」。比如大模型找不到正确的表，就会反复请求同一张表的元信息，一直卡着不动。研究团队的解决办法是：如果连续请求 10 次都没进展，就强制让大模型输出 SQL，虽然不能完全避免出错，但至少不会一直耗着。另外，目前只测试了 GPT-4-mini，还不知道在其他大模型上表现怎么样，未来肯定要多测几个模型，再把数据库规模搞大一点，看看它的极限在哪里。

但不管怎么说，这个 Datalake Agent 的思路真的打开了新世界的大门。以前咱们用大模型处理多数据库 NL2SQL，要么当冤种多花钱，要么忍受低正确率，现在终于有了「又好又省」的选择。尤其是企业里处理复杂表格查询的时候，用它不仅能少花钱，还能让大模型更专注于核心信息，处理多表查询更顺手。我已经开始期待它后续的升级了，要是能把「无限循环」的问题彻底解决，再支持更多大模型，那绝对是 NL2SQL 领域的「性价比之王」！

下面把实验里的关键图表放出来，大家直观感受下差距：

首先是两种方法的性能趋势图，能明显看到数据量越大，Datalake Agent 越能打：

图 1：Direct Solver 和 Datalake Agent 的性能趋势

然后是 tokens 用量对比图，Datalake Agent 的平稳曲线和直接提示法的飙升曲线形成鲜明对比：

图 2：解决单个任务所需的平均 tokens 数量趋势

最后是成本对比，这张图看完，谁用直接提示法谁心疼：

图 3：不同方法和 LLM 处理 1000 个任务的成本对比

除了这三张核心图，还有不同表数量下的 tokens 细节图，比如 42 张表时，Datalake Agent 的 tokens 用量稳定在 3000-4000 左右，而直接提示法经常冲到 30000 以上：

图 6：42 张表时，Datalake Agent 和 Direct Solver 的测试 tokens 用量对比

159 张表时，直接提示法的 tokens 用量更是肉眼可见地比 Datalake Agent 高一大截：

图 7：159 张表时，Datalake Agent 和 Direct Solver 的测试 tokens 用量对比

319 张表时，直接提示法的 tokens 已经快到 40000，而 Datalake Agent 还在 4000 左右徘徊：

图 8：319 张表时，Datalake Agent 和 Direct Solver 的测试 tokens 用量对比

性能细节图也得放出来，42 张表时两者差距还不大：

图 9：42 张表时，简单任务和复杂任务的正确率对比

159 张表时，直接提示法的复杂任务正确率已经掉得很明显：

图 10：159 张表时，简单任务和复杂任务的正确率对比

319 张表时，Datalake Agent 的复杂任务正确率直接领先近 30 个百分点：

图 11：319 张表时，简单任务和复杂任务的正确率对比

还有 Datalake Agent 处理任务的完整流程，从信息收集到生成 SQL，一步不差：

图 4：使用 Datalake Agent 处理表格问答任务的流程

以及它和大模型之间的通信循环，怎么一步步获取信息的，看得明明白白：

图 5：模型和 Datalake Agent 在处理任务前的通信循环

最后再给大家看看测试用的 100 个任务里有哪些例子，比如「哪个 F1 车手赢的比赛最多」「Avito 在 2015 年 4 月 28 日有多少次搜索」，都是企业里可能真的会用到的查询：