解读

在大模型落地到真实业务场景时，生成式 SQL 是最常见也最危险的输出之一。国内监管对“数据安全”与“个人信息保护”要求极高，一旦模型在对话中直接拼出带注入风险的 SQL，不仅会导致数据泄露，还可能触发《数据安全法》第五十四条的高额罚款。因此，面试官希望听到一套可落地、可量化、可复现的对抗测试集构建方案，而不仅仅是“用 SQLMap 跑一遍”这种初级回答。核心考察点有三：

1. 能否覆盖中文业务场景下的多样 SQL 方言（MySQL、OceanBase、TDSQL、PolarDB）。
2. 能否把大模型当成“黑盒生成器”，用变异+语义保持的方式低成本扩增用例。
3. 能否把测试集无缝接入LLMOps 持续交付流水线，实现每日自动回归。

知识点

1. SQL 注入分类：经典 Union、布尔盲注、时间盲注、报错注入、二次注入、堆叠注入、NoSQL 注入。
2. 对抗样本生成策略：基于语法变异的AST 重写、基于提示工程的Prompt 变异、基于语义的同义改写。
3. 中文业务关键字库：订单号、身份证、手机号、统一社会信用代码、车牌号、中文拼音缩写。
4. 风险判定规则：正则+语法树双重判定；出现“sleep”“benchmark”“extractvalue”等关键字即高危；出现“union select”且列数匹配即中危。
5. 评估指标：误报率、漏报率、攻击成功率 ASR、平均检测延迟 P99。
6. 合规基线：GB/T 35273-2020《个人信息安全规范》、TC260-PG-20233A《生成式人工智能服务安全基本要求》。
7. LLMOps 接入：测试集以 JSONL 形式存入华为云 OBS或阿里云 OSS，通过KubeFlow Pipeline每日触发，结果写回Prometheus+Grafana看板。

答案

整套方案分五步，全部在离线沙箱完成，零线上流量污染。

第一步，种子用例收集。
从内部工单系统拉取最近 6 个月真实用户提问，筛选出含“查询”“统计”“导出”关键词的 1.2 万条对话，人工标注出 312 条含 SQL 的样本，作为种子池 S0。

第二步，对抗变异引擎。
采用自研的ZhSQLFuzz，核心是两阶段变异：

1. 语法层：用ANTLR4 解析 MySQL 方言，生成 AST，随机插入“/**/”“0x0a”等绕过符号，或替换比较运算符“=”为“like”。
2. 语义层：调用大模型本身做Prompt 改写，指令为“请用 3 种不同方式表达同一查询需求，要求保留中文表名和字段名”。
   每轮变异产出 10 倍扩增，经过去重后得到 S1（3.1 万条）。

第三步，风险标注自动化。
把 S1 输入到RASP 探针（基于 OpenRASP 二次开发），在腾讯云 TDSQL 沙箱执行，捕获异常回显。只要触发“ERROR 1064”“ERROR 1058”或执行时间超过 2 s，即标为“注入成功”。人工复核 5% 样本，一致性 96.4%，满足工业要求。

第四步，测试集分级。
按 OWASP Top10 威胁等级，把样本拆成高、中、低三档，再按中文业务维度打上标签：订单、金融、政务、医疗。最终交付 1.8 万条可回归用例，并以Git LFS形式托管在内部 GitLab，CI 流水线每日拉取。

第五步，持续对抗验证。
在 LLMOps 的Stage-Gate流程中增加“SQL 注入检测”门控：

1. 每次模型热更新后，KubeFlow 组件自动拉起 50 并发 Pod，把测试集喂给模型；
2. 模型输出 SQL 先过正则过滤器，再过预训练分类器（基于 CodeBERT-CN 微调）；
3. 只要高危样本漏检率 >0.5%，即回滚版本，并触发企业微信告警给安全红线值班组。
   上线三个月，累计拦截 27 次带风险 SQL，线上 0 注入事件。

拓展思考

1. 生成侧与执行侧联动：未来可把 RASP 探针的异常栈直接反馈给大模型，用强化学习微调，让模型学会“自我纠错”，形成对抗闭环。
2. 多模态注入：语音输入转文字后也可能携带注入 payload，需要把对抗测试集扩展到ASR 输出层，实现端到端防护。
3. 国产化合规：信创环境普遍使用达梦、人大金仓，其 SQL 方言与 MySQL 差异大，需要重新训练方言解析器，并对接国密算法的加密字段，防止“加密列+注入”组合绕过。