语义解析（Semantic Parsing）是把自然语言句子翻译成机器可执行的形式化表示（logical form）的任务。比如“找出上个月北京地区退货率超过 5% 的订单”，输出不是一段解释，而是一组可执行条件：对象=订单，时间=上个月，地区=北京，筛选=退货率>5%。
可以把它想成“口译员+填表员”：先听懂人话，再把话填进机器能读的格子。难点在于语言有嵌套、指代、比较和省略。“退货率最高的那款产品的供应商是谁”需要先找产品、再排序、再关联供应商。语义解析输出的形式化表示可以是 SQL、图查询语言（如 SPARQL）、API 调用参数、过滤器 DSL，甚至对话系统里的意图和槽位。
它和 Text-to-SQL 的关系常被混淆。Text-to-SQL 是语义解析的子集：目标语言固定为 SQL，主要面对关系数据库的表结构，核心难点之一是 schema linking（把话里的词对应到表名、列名）。语义解析的目标语言不一定是 SQL；只要最终产物是“可执行结构”，无论是内部查询 DSL、函数调用 JSON 还是检索过滤表达式，都算。因此 Text-to-SQL 可视为语义解析在关系数据库上的特例，反过来不成立。
| 维度 | 语义解析 | Text-to-SQL | 语义搜索 |
|---|---|---|---|
| 输出 | 任意可执行形式化表示 | SQL 查询 | 相关文档/向量 |
| 评价 | 执行结果是否正确 | 执行准确率 | 召回与相关性 |
| 典型难点 | 组合性、歧义、目标语言设计 | 表列对齐、复杂 join | 语义相似但不精确 |
对从业者，语义解析的数据通常是“句子—逻辑形式”配对，评测要看执行结果（execution accuracy），不能只看字面相似；系统遇到“最近”“比较好”这类模糊词，应主动澄清而不是硬猜。对普通人，自然语言查报表、语音助手设提醒、客服工单自动分流，背后都可能是它。把条件说具体，系统才更容易给出可执行、可验证的答案。