作为程序员，咱平时跟 SQL 打交道不少，但你有没有发现，现在大模型虽说能生成代码，可一到真实业务场景就拉胯？比如老板问 “下个月销量咋预测”“咋提升复购率”，普通 Text-to-SQL 基准根本覆盖不到 —— 那些数据集要么只让查历史数据，要么场景太脱离商业实际。最近看到 Cornell 和 Gena AI 团队搞的 CORGI 基准，算是把这个痛点给戳中了，今天咱就用程序员的话唠唠这玩意儿到底牛在哪。

先说说为啥要搞 CORGI。现在企业里数据驱动决策是刚需，SQL 又是数据分析师的吃饭家伙，连麦肯锡这种咨询公司都把 SQL 当核心技能。但问题是，现有基准比如 BIRD、WikiSQL，大多只考 “查上个月卖了多少货” 这种纯检索活，可老板要的远不止这些 —— 得分析销量下滑的原因，得预测下个季度的趋势，还得给能落地的建议。就像你写接口，不光要返回数据，还得处理异常、给前端提示，不然业务根本用不起来。CORGI 就是奔着解决这个来的，它模拟了 Doordash、Airbnb、Lululemon 这些真实企业的数据库，还把问题分成了四类，从简单到复杂层层递进，咱后面细说。

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

先看 CORGI 的数据库是咋建的，这部分特别体现 “真实感”。团队没瞎编数据，而是走了三步流程：第一步先设计 schema，参考了真实企业的业务流程，比如外卖平台得有用户、商家、订单、配送员这些表，还得考虑表之间的关联，就像咱设计数据库时得画 ER 图，避免字段冗余或关联缺失。第二步是定数据模拟规则，这是最有意思的地方，分了三类规则：业务操作规则是硬约束，比如个性化营养订阅平台 Persona Nutrition，新用户必须做健康评估，评分低于 3.0 就得自动发咨询邀请，这就像代码里的 if-else 逻辑；潜在特征分布是概率性的，比如这个平台的用户里，35% 是试用用户（0-3 个月，对价格敏感），44% 是常规订阅用户，这就像咱做用户画像时统计的分布规律；还有潜在季节趋势，比如新年目标季订阅量涨 45%，暑假跌 31%，这跟电商大促时流量波动一个道理。第三步才是用 Gemini-2.5-flash-lite 生成数据，还手动审核过，确保数据符合规则，不会出现 “冬天卖比夏天多三倍冰淇淋” 这种离谱情况。

图 1 CORGI 数据库构建和多智能体评估框架

这张图上边是数据库构建流程，下边是评估框架，后面咱会说评估部分，先记住这个图里的多智能体逻辑，很关键。

再看数据模拟规则的具体例子，用 Persona Nutrition 来说明更直观。下图（a）是用户特征分布，能清楚看到不同用户群体的占比，（b）是月度订阅量的季节趋势，新年和黑五的峰值特别明显，这跟咱平时看业务监控面板里的流量曲线一模一样，不是那种平得像直线的假数据。

图 2 Persona Nutrition 数据模拟规则示例

这种带趋势和分布的数据，才能真正考验大模型的分析能力 —— 要是给个纯随机数据，就算分析出花来也没意义，就像你测接口用假数据，测不出边界情况。

接下来是问题分类，这四类问题简直是为业务场景量身定做的。第一类是描述性问题，就是纯检索，比如 “2025 年 9 月 1 日 Labubu 的总销量是多少”，对应 SQL 就是 sum 销量、where 条件过滤日期和产品名，这是大模型最擅长的，相当于写个简单的 CRUD 接口。第二类是解释性问题，得找原因，比如 “纽约 Pop Mart 线下店近 90 天收入为啥下滑”，这就不能只查数据了，得分析是竞争导致的（比如对面开了家 Jellycat 新店），还是内部问题（供应链断了、库存不够），就像咱排查线上 bug，不能只看报错日志，还得结合业务场景找根因。第三类是预测性问题，要算未来的数，比如 “北美线上旗舰店下个月 Labubu 能卖多少”，这得用时间序列、线性回归甚至 LSTM 模型，还得考虑黑五促销这种因素，就像你做容量规划，得结合历史流量和未来活动来预测服务器负载。第四类是推荐性问题，要给落地建议，比如 “明年咋拓展 Labubu 在欧洲的市场”，得综合多方面信息，比如搞本地化营销、跟当地零售商合作，这就像给业务提技术方案，不光要可行，还得对齐业务目标。

图 3 CORGI 四类问题分类

这四类问题一层比一层难，就像游戏升级，从 “打小怪” 到 “打 BOSS”，能真正看出大模型的业务能力。而且 CORGI 的数据库规模也不小，平均每个数据库有 26 张表，比 BIRD 的 7.3 张表复杂多了，更接近真实企业的数据库复杂度，你想想，真实业务里哪有只有几张表的数据库？光电商平台就有商品、订单、用户、库存、支付等几十张表，CORGI 这一点做得很实在。

再说说评估框架，这部分是 CORGI 的亮点，比传统只看 SQL 对不对的评估要全面得多。团队参考了管理咨询的评价标准，搞了七个维度的评估：结构（逻辑是不是清晰，有没有遗漏或重复）、SQL 执行成功率（生成的 SQL 能不能跑通）、数据敏感度（用的数据够不够、有没有考虑趋势）、洞察力（有没有跳出常规分析，找到深层原因）、可执行性（建议能不能落地）、目标对齐（是不是符合业务目标）、合规性（有没有考虑风险和伦理）。这就像咱做项目评审，不光看代码能不能跑，还得看架构合不合理、性能达不达标、有没有安全隐患、能不能支撑未来扩展。

更牛的是它的 “原子化多智能体评估机制”，不是用一个大模型评到底，而是用一个判别智能体先判断问题类型，再调用七个专业评分智能体分别打分，最后算平均分。比如评估推荐性问题时，会调用合规性智能体，而评估描述性问题就不用，因为描述性问题不用考虑风险。这就像咱做代码审查，前端问题找前端同学，后端问题找后端同学，数据库问题找 DBA，各司其职，评得更准。下图对比了这种多智能体评估和单模型评估的结果，能明显看到多智能体在各个维度的评分更合理，统计测试也证明两者差异显著，不是瞎评的。

图 4 多智能体评估 vs 单模型评估

而且 CORGI 还搞了个在线平台，用 Bradley-Terry 框架收集人类反馈，通过 pairwise 比较来校准评分，避免机器评估的偏见。就像咱做用户调研，让用户在两个方案里选更喜欢的，比直接让用户打分更准确，因为用户有时候也说不清楚 “4 分和 5 分的区别”，但能分清 “哪个更好”。

最后看实验结果，这部分最扎心，也最真实。测试了 Gemini-2.0、Gemini-2.5 和 GPT-4o 三个模型，结果发现大模型在高难度问题上表现明显下滑。首先是 SQL 执行成功率，CORGI 上平均只有 67.8%（解释性）、57.4%（预测性）、74.5%（推荐性），而在 BIRD 上能到 88%，差了 21 个百分点，说明 CORGI 的 SQL 更难写，更贴近真实业务里复杂的多表关联、子查询场景。比如预测销量的 SQL，可能要关联历史销量表、促销活动表、用户表，还得用窗口函数算趋势，大模型很容易漏关联表或写错函数。

再看评分结果，模型之间还存在 “评分偏见”，GPT-4o 给所有答案的平均分比 Gemini-2.5 高 0.56 分，而且统计显著，说明不同模型的评价标准不一样，就像有的代码评审员严一点，有的松一点，这也提醒咱，以后看模型评测结果时，得注意用的是哪个评估器。更关键的是，随着问题难度从描述性升到推荐性，模型的评分稳步下降，GPT-4o 在推荐性问题上的评分比解释性问题低了 0.32 分，Gemini-2.5 低了 0.09 分，而且统计显著。尤其是推荐性问题的 “可执行性” 维度，平均分只有 2.23（满分 5 分），说明大模型虽然能把答案组织得很有条理（结构分 3.76），但给的建议大多是 “正确的废话”，比如 “要搞营销”“要提升用户体验”，没有具体说 “搞什么类型的营销”“提升体验的哪方面”，这跟咱平时看有些技术方案一样，框架写得很漂亮，但落地细节全是坑，根本没法执行。

图 5 不同模型在各类问题上的 SQL 执行成功率

下面这张表是详细的评分对比，能看到每个模型在各个维度的表现。比如 GPT-4o 在 “数据敏感度” 上比 Gemini-2.5 高，说明它用数据更充分，但在 “洞察力” 上两者差距不大，都偏低，说明大模型还没达到 “能提出独到见解” 的程度。而且推荐性问题的 “合规性” 评分虽然不低，但主要是因为模型会套话 “要考虑风险”，但具体是什么风险、怎么规避，大多没说清楚，就像咱写安全文档，只写 “要防 SQL 注入”，但没写 “用参数化查询”“做输入过滤” 一样，没实际意义。

表 3 不同模型在各评估维度的详细得分，S：结构，D：数据敏感度，I：洞察力，O：可执行性，P：目标对齐，C：合规性

总的来说，CORGI 这个基准算是把大模型在商业 Text-to-SQL 上的 “短板” 给暴露出来了 —— 能处理简单的检索，但搞不定复杂的分析、预测和建议。对咱程序员来说，这既是挑战也是机会：挑战在于以后做业务型 AI 应用时，不能光依赖大模型的 “开箱即用” 能力，还得做二次开发，比如给模型加领域知识、优化提示词、加人工审核环节；

机会在于这方面还有很多可做的工作，比如优化多智能体评估、提升模型的业务理解能力、构建更真实的业务数据集，这些都是能落地且有实际价值的方向。

最后提一句，CORGI 的数据集、评估框架和在线平台都开源了，地址在论文里有，感兴趣的同学可以去试试，把自己的模型放上去测测，看看在真实业务场景下到底能得多少分 —— 毕竟，只有在真实场景下经得住考验的模型，才是真有用的模型，就像只有在生产环境跑通的代码，才是好代码。