Are We Asking the Right Questions? On Ambiguity in Natural Language Queries for Tabular Data Analysis

该论文提出将自然语言查询中的歧义重构为用户与系统共同承担责任的协作特征，通过建立区分可协作解析与不可解析查询的框架，揭示了现有评估中查询类型混杂的问题，并为表数据分析自然语言接口的设计与评估指明了未来方向。

要点

这篇论文探讨了一个非常有趣的问题：当我们用自然语言（比如说话或打字）向电脑询问表格数据时，我们到底是在问对问题了吗？

作者认为，目前的电脑系统（AI）往往把用户提问中的“模糊不清”当作一种错误，拼命想猜出用户心里唯一的那个“正确答案”。但作者提出，这种模糊其实是一种合作，是用户和系统之间的一种默契分工。

为了让你更容易理解，我们可以用"点菜"和"寻宝"这两个比喻来解释这篇论文的核心思想。

1. 核心比喻：点菜 vs. 寻宝

想象一下，你走进一家餐厅（这就是表格数据系统），你想吃点什么（这就是你的分析需求）。

• 传统的做法（把模糊当错误）：
  如果你说：“我想吃点好吃的。”
  现在的系统会崩溃，因为它不知道你是想吃辣的还是甜的，是吃面还是吃鱼。它觉得你“没把话说清楚”，是个坏顾客。它试图强行猜一个菜给你，或者报错。

• 作者的新观点（模糊是合作）：
  作者认为，你说“我想吃点好吃的”，其实是在和厨师（系统）合作。

  • 你（用户）的责任：告诉厨师大概的方向（比如“想吃点好吃的”）。
  • 厨师（系统）的责任：根据常识（比如“好吃的通常指招牌菜”）或者主动问你（“您想吃辣的吗？”）来补全细节。
  • 结论：只要双方配合，哪怕你没说全，也能做出一道好菜。这种“没说完”不是你的错，而是你信任厨师能懂你。

2. 三种“点菜”方式

论文把用户的问题分成了三类，就像三种不同的点菜风格：

A. 完美无缺的“明确指令” (Unambiguous Queries)

• 例子：“请给我一份2023 年 6 月到 8 月，哥本哈根的平均气温。”
• 比喻：你不仅说了想吃鱼，还说了要“清蒸”、“去骨”、“只要 200 克”。
• 作用：这种问题最适合用来测试厨师的手艺（系统的执行能力）。因为答案只有一个，如果厨师做错了，那就是厨师不行。

B. 懂得合作的“模糊指令” (Cooperative Queries)

• 例子：“请告诉我哥本哈根夏天的平均气温。”
• 比喻：你说“夏天”，没说是哪一年，也没说具体哪几个月。但你信任厨师知道“夏天”通常指 6-8 月，而且默认是最近几年的数据。
• 作用：这种问题适合测试厨师的悟性（系统的推理能力）。系统需要运用常识（比如“夏天=6-8 月”）来补全信息。如果系统能猜对，说明它很聪明，懂人情世故。

C. 无法合作的“乱点” (Uncooperative Queries)

• 例子：“请告诉我平均气温。”
• 比喻：你只说了“气温”，没说地点，也没说时间。这就像在餐厅里只说“我要吃热的”，厨师完全不知道是该给你上火锅还是热汤，甚至不知道你在哪个城市。
• 作用：这种问题没法用来测试系统。因为它本身就是个死胡同。但它可以用来测试系统的抗干扰能力——看它会不会胡乱猜，或者能不能礼貌地告诉你“您没说清楚，我没法做”。

3. 现在的“考试”出了什么问题？

作者检查了目前流行的 15 个“考试卷”（数据集），发现了一个大麻烦：

1. 题目太“作弊”了（数据特权）：
   很多题目里藏着只有出题人知道的“暗号”。

   • 比喻：就像考试题目里直接写着“请查看表格第 3 列第 5 行的数据”。
   • 问题：在现实生活中，用户不知道表格长什么样，根本不会这么问。这种题目测不出系统真正的本事，只能测它会不会背答案。

2. 题目类型太混乱（混合了）：
   现在的考试把“明确指令”、“合作指令”和“乱点”混在一起考。

   • 比喻：就像一场考试，有的题考“背诵课文”（执行能力），有的题考“即兴创作”（推理能力），结果混在一起打分。
   • 后果：如果一个系统“背诵”很好但“创作”很烂，或者反过来，我们根本分不清它到底哪里强、哪里弱。这就像让一个只会背菜谱的厨师去评“创意奖”，或者让一个很有创意的厨师去评“背诵奖”，都不公平。

4. 作者的建议：我们要怎么改进？

作者提出了三个简单的改进方向：

1. 分门别类地考试：
   如果要测系统“算得准不准”，就用明确指令（A 类）；如果要测系统“懂不懂人话”，就用合作指令（B 类）。别把它们混在一起。

2. 设计新的“寻宝图”：
   未来的数据集应该包含那种“没说完”的问题，并且要允许系统有多种合理的回答方式。

   • 比喻：不要只给标准答案，要告诉系统：“只要你的解释合乎逻辑，就算对。”

3. 从“一问一答”变成“聊天”：
   当系统发现用户没说清楚时（比如 C 类问题），不要直接报错或瞎猜，而是应该像真人一样问：“您是指哪个城市的气温呢？”

   • 比喻：好的服务员会问您“您想吃辣的吗？”，而不是直接端上一盘辣椒。

总结

这篇论文的核心思想是：别再逼用户把话说得像机器代码一样精确了。

用户说话模糊是正常的，也是聪明的（因为人类习惯把细节留给对方去补全）。未来的智能系统不应该只追求“猜对唯一答案”，而应该学会理解用户的意图，并在用户没说清楚时，通过常识推理或礼貌提问来共同完成任务。

这就好比，我们不需要一个只会死记硬背菜谱的机器人厨师，我们需要的是一个能听懂“我想吃顿好的”这种模糊指令，并主动问一句“那您喜欢清淡还是重口？”的贴心大厨。

技术摘要

1. 研究背景与问题 (Problem)

核心问题：
在表格数据分析（Tabular Data Analysis）中，自然语言查询（NLQ）普遍存在歧义性。现有的研究通常将这种歧义视为一种技术缺陷，试图通过事后检测、分类和消除歧义来挖掘用户唯一的“潜在意图”。

现有方法的局限性：

• 视角偏差： 这种“消除歧义”的视角忽略了用户与系统之间的协作本质。用户往往基于不完整的心智模型（Mental Models）提出查询，故意或无意地省略细节，期望系统能进行合理的推断。
• 评估失效： 现有的基准测试（Benchmarks）混合了不同类型的查询（无歧义、协作性歧义、不可解决歧义），且大量使用“数据特权查询”（Data-Privileged Queries，即查询中包含了用户在实际开放域环境中无法获知的数据库结构或特定值信息）。这导致评估结果无法准确区分系统的执行准确性（Execution Accuracy）和解释/推断能力（Interpretation Capabilities）。
• 开放域挑战： 与固定数据库的 Text-to-SQL 不同，开放域表格分析缺乏上下文脚手架，用户必须指定分析程序和适用数据，但现有数据集往往未能反映这一现实。

2. 方法论 (Methodology)

作者提出了一种基于**协作交互（Cooperative Interaction）**的新框架，重新定义了对查询歧义的理解和评估方式。

A. 理论框架：协作查询 (Cooperative Queries)

基于格赖斯（Grice）的合作原则（Cooperative Principle），特别是“量的准则”（提供足够但不过量的信息），将查询分为三类：

1. 无歧义查询 (Unambiguous Queries)： 用户提供了所有必要信息（显式或通过通用惯例），系统无需进行任何选择性推断即可得出唯一的可执行解释。这类查询适合评估执行准确性。
2. 协作性查询 (Cooperative Queries)： 用户故意省略部分细节（如“夏季”、“平均”），期望系统通过合理推断（Reasonable Inference）来补全。这包括：
   • 常规推断 (Conventional Grounding)： 基于常识（如“最高峰”默认为“世界最高峰”）。
   • 选择性推断 (Selective Grounding)： 用户在合理范围内授权系统选择（如“关系”可以是皮尔逊或斯皮尔曼相关系数）。
   • 这类查询适合评估系统的解释能力和人机对齐能力。
3. 不协作查询 (Uncooperative Queries)： 查询过于模糊，导致歧义无法解决（如“平均温度是多少？”未指明地点），缺乏有效推断的基础。这类查询不适合评估执行能力，但可用于测试系统的鲁棒性。

B. 评估指标与数据集分析

• 数据独立性 (Data-Independence)： 识别“数据特权查询”，即查询中直接引用了列名（如 first_name）、特定内部 ID 或数据容器（如“该表格”），这些在开放域中是不合理的。
• 协作性分类： 开发基于大语言模型（LLM）的分类器，对查询在过程规范（意图、方法论）和数据规范（实体、时间、领域）五个维度上进行标注。
• 实验设置： 分析了 15 个 主流表格数据集（涵盖 Text-to-SQL、表格问答、数据分析任务，如 Spider, BIRD, DA-Eval, KramaBench 等），使用 LLM 分类器（经专家验证，Kappa 系数 > 0.7）对查询特性进行量化分析。

3. 主要贡献 (Key Contributions)

1. 概念重构： 提出将查询歧义视为协作特征而非缺陷。建立了“用户显式提供”与“系统推断”之间的责任分工模型，强调“欠规范（Underspecification）”是赋予系统代理权（Agency）的有意为之。
2. 评估框架： 定义了针对不同评估目标的查询分类标准：
   • 评估执行准确性 $\rightarrow$ 使用无歧义查询。
   • 评估解释/推断能力 $\rightarrow$ 使用协作性查询。
   • 评估鲁棒性 $\rightarrow$ 使用不协作查询。
3. 基准测试诊断： 揭示了现有 15 个数据集存在的系统性偏差：
   • 大量复杂分析任务的数据集充斥着数据特权查询（泄露了数据库结构信息）。
   • 无歧义查询占比极低，导致难以纯粹评估执行能力。
   • 现有评估混淆了执行错误和解释错误，无法准确反映系统在开放域中的真实表现。
4. 未来方向指引： 提出了构建迭代式查询细化数据集、设计支持混合主动（Mixed-Initiative）对话的系统、以及开发更灵活的评估协议（接受多种合理的推断结果）的具体建议。

4. 实验结果 (Results)

通过对 15 个数据集的分析（如图 2 所示），得出以下关键发现：

• 数据特权普遍存在： 许多数据集（特别是复杂分析类如 DA-Eval, DA-Code）中，大量查询包含结构引用（Structural References）或值引用（Value References）。这意味着这些查询在真实的开放域场景下，用户是无法提出的，因为它们依赖于对底层表结构的先验知识。
• 无歧义查询稀缺： 在所有数据集中，能够映射到单一可验证解释的“无歧义查询”占比非常小。
  • 在简单的表格问答（如 WikiTableQuestions）中，无歧义查询比例稍高。
  • 在复杂的诊断分析、预测建模任务中，无歧义查询极少，大部分查询属于“过程指定但数据范围模糊”的协作性查询。
• 评估错位： 由于现有基准测试混合了上述不同类型的查询，且缺乏对“数据特权”的过滤，导致当前的系统评估既不能准确衡量执行精度，也不能有效衡量系统的推断对齐能力。

5. 意义与影响 (Significance)

• 范式转变： 该论文挑战了当前 NLP 社区处理歧义的主流范式（即“消除歧义”），转而倡导“利用歧义”进行协作。这要求系统设计者从“猜测用户意图”转向“与用户共同构建查询”。
• 指导系统设计：
  • 系统应能够识别何时需要选择性推断（Selective Grounding），并主动披露其推断逻辑（如“我假设您指的是 2023 年的数据”），以便用户干预。
  • 对于无法解决的歧义，系统应启动混合主动对话（Mixed-Initiative Dialogue）向用户澄清，而不是盲目猜测或报错。
• 推动基准测试改革： 呼吁构建新的数据集，明确标注查询的协作层级和推断需求，并采用灵活的评估协议（允许一组合理的答案，而非单一标准答案），以推动开放域表格数据分析系统的实质性进步。

总结：
这篇论文不仅指出了当前表格数据分析评估体系的根本缺陷，还提供了一个基于人机协作理论的坚实框架。它强调，真正的智能系统不应仅仅是执行精确指令的工具，而应是能够理解用户意图、合理推断隐含信息并与用户共同解决模糊问题的合作伙伴。