LLM 企业数据查询来了"新考官"：SemPlan 不考 SQL，考规划
企业数据是大模型商业化最值钱、也最容易翻车的场景。问题常常不在模型读不懂人话，而在它不知道该查哪张表、按什么顺序查。近日在 arXiv 亮相的 SemPlan，把这段"从人话到数据"的中间地带命名为语义规划——并把它变成一场考试。
测的不是一句话写 SQL
测的是规划完整查询路径
信号是企业 Agent 评估进入"过程时代"
企业数据是大模型商业化最值钱、也最容易翻车的场景。问题常常不在模型读不懂人话，而在它不知道该查哪张表、按什么顺序查。近日在 arXiv 亮相的 SemPlan，把这段"从人话到数据"的中间地带命名为语义规划——并把它变成一场考试。
一个业务人员问："帮我查一下华东区上季度复购率下降的原因。"这条查询背后远不止一句 SQL：要先定位客户表、订单表、区域维度表；再搞清楚"复购率"在本公司的计算口径；然后决定先筛选时间还是先做聚合；最后还要核一遍结果是否合理。这一连串决策，被 SemPlan 命名为语义规划。
模型能背出"复购率"的定义，不等于能把这单查询跑通。
SemPlan（Structured Semantic Planning Benchmark）近日在 arXiv 亮相，定位是企业数据场景下的 LLM 语义规划评测基准——不是给 Text-to-SQL 题库多加一道题，而是把"规划"这个过程本身端上考桌。
如何阅读：链路从左到右，是从用户意图到数据结果的全过程；SemPlan 评测的正是中间每一步的决策质量。
传统 Text-to-SQL 基准（如 Spider 系列）把任务定义为"自然语言 → SQL"的单次转译。题目干净、标答唯一、评测方便，但它隐含一个前提：查询路径已被预设——模型只需要完成最后一步翻译。
真实的企业环境，恰恰没有这个前提。
跨系统、口径不一、表结构陌生……模型得先决定查什么、按什么顺序查、怎么把零散结果拼成答案——这一整层决策，在旧基准里几乎是空白。
对比卡左边是旧基准的评测方式，右边是 SemPlan 的设计方向；两者并非替代关系，而是评估粒度的一次下潜。
一个现象很能说明问题：主流模型在 Spider 上的准确率早已越过 80%，但企业级 Text-to-SQL 的落地体验仍常常被诟病。差距不在"会不会写 SQL"，而在写 SQL 之前那段看不见的规划。
SemPlan 全称里的"Structured Semantic Planning"——结构化语义规划。把题目拆开看，它指向的是四种层层递进的能力：
识别表、字段、外键与层级关系，读懂数据的骨架。这是所有规划的地基。
"复购率"在 CRM 和财务报表里可能是两套口径。模型需要做实体与度量上的消歧。
把模糊需求拆成一串有依赖关系的子查询，并排定执行顺序——先聚合还是先过滤，结果截然不同。
调用工具、数据库或 API 完成查询后，对结果做合理性验证，发现异常能回头修正规划。
S-E-M-A 是编辑对论文标题的拆解，方便记忆；论文的具体任务维度与权重，请以全文为准。
从"单步转译"到"全程规划"，这不只是评测方式的升级，也折射出行业对 LLM 的期待变化：它不再只是会答题的模型，而是被要求成为能独立交付结果的数字员工。
语义规划听起来抽象，但落到企业现场，其实都是具体的"坑"。
语义规划评测比 SQL 评测难得多。传统基准可以自动化校验执行结果，而"规划质量"牵涉路径是否最优、口径是否合理这类开放判断。SemPlan 如何在自动校验与人工评审之间取得平衡，目前还看不出全貌。
覆盖不了"脏"的真实。企业数据里的缺失值、错误值、口径混乱，很难在基准任务中完全模拟。
归因仍是难题。一个低分，可能源于语义理解弱、工具调用差，也可能只是规划策略笨——基准难以拆开归因。
复现门槛不算低。跨库多步查询的评测环境搭建成本，远比单库基准高，可能影响社区参与热情。
这些短板无损 SemPlan 的价值，但它提醒我们：任何基准都只是切片，不是全貌。
企业级 LLM 的下半场，比的不再是"谁更会对话"，而是"谁更会找数据"。语义规划是这条通路上最隐蔽、也最值钱的一段。能够规模落地的企业 Agent，未必拥有最强大的模型，但一定拥有最清晰的查询路径。
论文已上传 arXiv，检索 SemPlan 即可找到论文全文与评测设计说明。
基准刚发布，任务细节与评测数据以论文最终版为准。