# FDE W5D5 评测题 · Text2SQL 最小 Demo
> 配套《FDE-W5D5-Text2SQL最小Demo-学习手册.html》。场景统一为「特药理赔 Agent」。
> 每个题目含：**考察点**（考什么）、**评分维度**（按 1~5 分档，总分 5 分）、**参考答案**（折叠，点击展开）。
> 评分维度通用说明：① 正确性（概念/结论对不对）② 完整性（关键要点是否齐全）③ 工程与风险意识（是否想到安全/兜底/成本）。
---
## L1 基础（概念识别，能说清"是什么"）
### Q1. 什么是 Text2SQL？它适合特药理赔 Agent 里的哪类问题？
- **考察点**：Text2SQL 的定义与适用边界。
- **评分维度**：
- 正确性（2 分）：能定义"自然语言转 SQL"。
- 完整性（2 分）：能区分适合/不适合的场景。
- 工程意识（1 分）：提到"前提是安全"。
参考答案（点击展开）
Text2SQL（NL2SQL）是把自然语言问题转换成可在数据库执行的 SQL 的任务。
在特药理赔 Agent 里，它适合**结构化、可聚合**的问题，例如："3 月我报的奥希替尼花了多少""哪些保单的特药额度还没用完""上个月理赔金额 Top10 的药品"。
不适合：知识条款类（"特药目录怎么规定"→应走 RAG）、实时写操作（"帮我提交一笔理赔"→应走业务 API）。核心是：数据在结构化库、需要筛选/聚合/关联时优先 SQL。
参考答案（点击展开）
用户问题 → 数据路由判断（确认走 SQL）→ Schema Linking（话术映射表/字段）→ 生成只读 SQL（低 T + schema 上下文）→ SQL 安全校验（只读/白名单/参数化/行数/EXPLAIN）→ 执行计划 & 超时 → 执行（受限连接）→ 结果解释（SQL→自然语言）→ 自然语言回答。
关键：安全校验是独立于"生成"的一道关卡，不能合并。
参考答案（点击展开）
Schema Linking 是把用户话术里的实体/概念，对齐到数据库真实的表名、字段名、枚举值。例如"报销金额"→`claim.clm_amt`，"奥希替尼"→`drug.name='奥希替尼'`，"上个月"→`clm_date BETWEEN 上月首日 AND 上月末`。
它是 Text2SQL 的**准确率命门**：Linking 错，后面 SQL 再语法正确也是错答案（形对义错）。
参考答案（点击展开）
"只读"指解析 SQL 的 AST，只允许 SELECT（含 WITH...SELECT 形式的只读查询），拒绝一切 INSERT/UPDATE/DELETE/DROP/ALTER 等写操作与 DDL。
工程上：① 用 SQL 解析器（JSqlParser/Apache Calcite）做 AST 校验，别只靠正则（可被注释/换行绕过）；② 数据库账号本身也要 GRANT SELECT only，应用层+数据库层纵深防御。
参考答案（点击展开）
**后果**：Linking 错 → SQL 查错表/错字段/错值 → 形对义错，给用户错误理赔数据。
**怎么做准**：
1. 建数据字典 + 中文注释（建表 comment，让 `clm_amt=理赔金额`）。
2. 用问题召回 Top-K 相关表（向量/关键词），避免全库 schema 噪声。
3. 让模型先输出 (表,字段) 映射，再生成 SQL。
4. 枚举值归一化（"奥希替尼"→精确匹配 drug_name）。
5. 时间表达式归一化（"上个月"→具体日期区间）。
本质是检索增强：多数失败在 Linking 而非生成。
参考答案（点击展开）
正则匹配字符串极易被绕过：攻击者/模型可在语句中插入注释（`SEL/* */ECT`）、换行、大小写混合（`sElEcT`）、特殊编码来绕过关键词黑名单；而 AST 解析把 SQL 变成语法树，只判断"根节点是不是 SELECT 语句"，结构层面的判断无法被文本变形绕过。所以生产用 JSqlParser/Calcite 等解析器做 AST 校验。
参考答案（点击展开）
越权访问不一定在主查询的 FROM 里，也可能藏在 `JOIN`、`子查询`、`CTE`、甚至 `IN (SELECT ...)` 里。若只校验顶层表，会漏掉这些隐式引用的敏感表（如 `user_credential`、`payment_account`）。
正确做法：从 AST 提取**所有**被引用的表名（含 JOIN/子查询/CTE），逐一校验是否在允许集内；同时数据库账号只 GRANT SELECT 给白名单表，双重保险。
参考答案（点击展开）
- **参数化（防注入）**：用户输入走绑定变量 `?`，防 `' OR '1'='1` 注入和语法错（Java 的 PreparedStatement 同理）。
- **行数 LIMIT（防拖库）**：自动追加 LIMIT 或校验用户 LIMIT 不超阈值，防 `SELECT *` 返回百万行拖垮连接。
- **EXPLAIN（防慢查询）**：执行前看是否全表扫/笛卡尔积/超成本，超标则拒绝或改写，避免占满连接池。
注意：LIMIT 太低会"静默截断"导致统计错，结果解释要提示"已截断"；EXPLAIN 本身有成本，高并发可对简单查询免检或缓存计划。
参考答案（点击展开）
生成由 LLM 完成，**不可信**：它可能产出错误 SQL，也可能被越狱/上下文注入诱导吐出 `DROP`/`UPDATE`。若把"安全"寄托在 prompt 的"请只输出 SELECT"上，等于把守门员和不可信来源合并，必然失守。
因此安全校验必须是**独立的确定性规则层**。纵深防御层次：
1. prompt 软防线（先声明只读，挡掉大部分明显违规）；
2. AST 校验（应用层，只允许 SELECT）；
3. 白名单表（含 JOIN/子查询）；
4. 数据库账号本身 GRANT SELECT only（即使应用层漏了，库层也挡住写/越权）。
这是整个 Agent Harness"不可信生成 + 可信守门"思想的缩影。
参考答案（点击展开）
**数字准确**：结果解释把行集转自然语言，但金额/计数必须直接来自真实 SQL 结果，不能让模型"重新算"或编造。分工是"SQL 负责准，语言模型负责顺"。若结果被 LIMIT 截断，解释里必须明示"仅统计前 N 条"。
**空结果**：SQL 正常但 0 行（如查不存在的保单），要如实说"未查到相关记录"，**不能编"您报销 0 元"**——0 元和没有是两回事，保险场景会误导用户引发投诉。
**异常**：超时/权限/语法漏网时，别把原始报错（含表名/SQL）抛给用户（信息泄露），给友好提示并记日志，可降级（返回近 30 天概览）或转人工。
参考答案（点击展开）
1. **执行层**：受限独立连接池 + 语句级超时（如 3s），超时即 `KILL QUERY`，保证一个烂查询拖不垮整个理赔服务（连接池隔离）。
2. **用户层**：返回友好提示"查询过慢，请缩小时间范围或指定具体保单"，不暴露 SQL/表名。
3. **降级**：可返回近 30 天概览等轻量结果，或转人工。
4. **可观测**：把超时、原 SQL、耗时记到 Trace，便于后续优化索引或改写查询。
即便 EXPLAIN 放行，线上数据分布变化也可能让查询变慢，超时是最后兜底。
参考答案（点击展开）
1. **路由判断**：问题含"多少钱/上个月"，属聚合统计 → 走 SQL（非 RAG/API）。
2. **Schema Linking**：召回理赔相关表（`claim`/`policy`/`drug`），把"特药报销金额"→`claim.clm_amt`，"上个月"→`claim.clm_date BETWEEN 上月首日 AND 上月末`，"我"→按当前用户 member_id 过滤。
3. **生成**：低 T=0，prompt 含 schema 与"仅 SELECT"，生成如 `SELECT SUM(clm_amt) FROM claim WHERE member_id=? AND clm_date BETWEEN ? AND ? AND drug_type='特药'`。
4. **安全校验五关**：
- 只读：AST 确认是 SELECT；
- 白名单：引用的 `claim` 在允许集；
- 参数化：`member_id`/`日期` 走绑定变量；
- 行数：聚合查询自动 LIMIT（或无需）；
- EXPLAIN：无全表扫则放行。
5. **执行**：受限连接 + 超时。
6. **结果解释**：把 SUM 值组织成"您上个月特药报销合计 ¥X"，数字来自真实结果；若为空则说"未查到相关记录"，不编 0 元。
参考答案（点击展开）
这是安全红线场景，绝不能执行：
1. **路由层**：虽像 SQL 查询，但目标是敏感表（`user_credential`/`payment_account`），且超出该 Agent 职责——应在路由阶段就识别为"越权/敏感"并拦截，不进入生成。
2. **安全校验层**：即使生成了 SQL，白名单表校验会拒绝引用敏感表；即便绕过，数据库账号对这些表无 SELECT 权限，库层再挡一道。
3. **拒答**：返回友好提示"抱歉，我无法导出客户身份证号与银行卡号等敏感信息"，**不执行、不暴露**内部表结构或报错细节。
4. **审计**：把该次越权请求记审计日志（谁、何时、问了什么），便于安全复盘。
体现原则：最小权限 + 纵深防御 + 该拒答时拒答（而非硬编或硬查）。