TAG：SQL 查数之后，还要会解释
TAG：SQL 查数之后，还要会解释
这篇论文的核心观点很简单：真实用户问数据库，不只是想要 SQL 执行结果。他们还会问“为什么销售下降”“哪些评论是正面的”“Bay Area 学校有哪些”。这些问题需要数据库的精确计算，也需要 LLM 的语义理解和世界知识。
TAG 做的事：把数据库查询和 LLM 生成统一成一个问答范式。
Text2SQL 关注“自然语言能不能翻译成 SQL”。TAG 关注更大的问题：“用户对数据库提出任意自然语言问题，系统如何结合数据库执行能力和 LLM 推理能力，给出最终自然语言答案？”
数据库负责精确计算
过滤、排序、聚合、join、大规模扫描，这些是 DBMS 擅长的。
LLM 负责语义和知识
情感判断、文本摘要、世界知识、业务概念解释，这些是 LLM 擅长的。
答案不是只有表格
很多用户要的是解释、总结、原因和洞察，而不是一张原始查询结果表。
Text2SQL 和 RAG 都只覆盖了真实问询的一小块。
| 方法 | 适合什么 | 短板 |
|---|---|---|
| Text2SQL | 能完全表达为关系代数/SQL 的问题。 | 无法处理“评论是否正面”“这家公司是否属于零售行业”这类语义和世界知识问题。 |
| RAG | 从少量相关记录中查找答案。 | 通常只是 point lookup，不擅长大规模过滤、聚合、排序、join，也容易把精确计算交给 LLM。 |
| TAG | 既需要数据库计算，又需要 LLM 语义推理/世界知识/答案生成的问题。 | 自动合成高质量 TAG pipeline 仍是开放问题。 |
TAG 的三步：syn、exec、gen。
论文把 TAG 定义成一个简单但很有表达力的三阶段模型：先把用户请求转成可执行查询，再由数据库执行得到相关数据表，最后由 LLM 基于原问题和数据表生成自然语言答案。
Query Synthesis
\(syn(R) \rightarrow Q\)：把用户请求 \(R\) 转成数据库可执行查询 \(Q\)，可能是 SQL，也可能包含 semantic operators。
Query Execution
\(exec(Q) \rightarrow T\)：数据库执行查询，得到相关数据表 \(T\)。这里可以利用 DBMS 的计算能力。
Answer Generation
\(gen(R,T) \rightarrow A\)：LLM 读取原问题和结果表，生成最终自然语言答案 \(A\)。
TAG 的创新点是把很多 AI + DB 交互放到同一个框架里。
查询类型更广
既包括 point query，也包括需要跨多行推理的 aggregation、ranking、summarization。
数据模型更广
论文实验用关系数据库，但 TAG 可以扩展到半结构化、非结构化、多模态数据。
执行引擎更广
数据库 API 不一定只是 SQL，也可以包含 LM UDF、semantic filter、semantic rank、semantic aggregation。
example TAG-style query idea: SELECT movie_title, review, revenue FROM movies WHERE genre = 'Romance' AND sem_filter(movie_title, 'is considered a classic') ORDER BY revenue DESC LIMIT 1 Then ask LLM: Summarize the reviews for the selected movie.
论文构造了一个 TAG benchmark，专门考两类难题。
作者基于 BIRD 选了 5 个领域数据库，改写出 80 个问题：40 个需要世界知识，40 个需要语义推理。问题覆盖 match-based、comparison、ranking、aggregation 等类型。
需要世界知识
比如“Bay Area 的学校有哪些”。Bay Area 这个概念不一定在表里，需要模型知道地理/现实世界知识。
需要语义推理
比如“最讽刺的评论 Top 3”。讽刺不是普通 SQL 条件，需要 LLM 对文本做语义判断。
| Baseline | 做法 |
|---|---|
| Text2SQL | 直接生成 SQL，SQL 执行结果就是答案。 |
| RAG | 把行序列化后做向量检索，取 10 行给 LLM。 |
| Retrieval + LM Rank | RAG 检索后，再让 LLM 给行打分重排。 |
| Text2SQL + LM | 先用 SQL 找相关行，再把行给 LLM 生成答案。 |
| Hand-written TAG | 专家手写 TAG pipeline，用 LOTUS 的 semantic operators 执行。 |
结果很直接：普通 Text2SQL/RAG 都很弱，手写 TAG 明显更强。
整体 exact match 55%，显著高于其他 baseline。
Text2SQL、RAG、Text2SQL+LM 等标准方法都没有超过 20%。
准确率更高的同时，平均执行时间也相对低。
对 DataEngine 来说，TAG 是“智能问询最终形态”的参考。
前面的 AutoLink 和 Schema Linking 论文帮助我们找字段，CHASE-SQL 帮我们多候选生成和选择 SQL。TAG 提醒我们：很多时候 SQL 结果不是终点，系统还要基于结果表做解释、摘要、分类和原因分析。
recommended DataEngine TAG pipeline: 1. understand_question(question) 2. schema_link(question) # 找表和字段 3. synthesize_query_or_plan(question, schema) # 生成 SQL / semantic query 4. execute_query_with_mcp(plan) # DB 精确计算 5. semantic_ops_if_needed(rows) # 情感、分类、排序、摘要等 6. generate_answer(question, computed_table) # 给用户自然语言答案 7. cite_rows_and_confidence(answer)
适合 MCP 做的
执行 SQL、过滤/聚合、取样、分页、权限控制、结果缓存、调用数据库内置 ML/UDF。
适合 skill/agent 做的
判断问题是否需要世界知识、是否需要语义操作、如何把结果表转成解释性答案。
一句话评价：这篇论文把智能问询的边界从“查数”推到了“解释数据”。
强项
问题定义很准：真实业务问询常常需要 SQL + LLM，而不是二选一。TAG 三步模型简洁但覆盖面广。
创新点
把 Text2SQL 和 RAG 都看作 TAG 的特例，并提出更贴近真实用户问题的 TAG benchmark。
局限
最强结果来自 hand-written TAG pipelines，说明自动合成 TAG pipeline 仍然很难，这正是后续系统研究空间。
和前面几篇的关系
AutoLink 找 schema，CHASE-SQL 生成和选择 SQL，TAG 负责把查询结果变成有语义的答案。组合起来才是完整智能问询。