项目背景与架构
业务人员取数依赖数据团队写 SQL，排队等待长且沟通成本高。直接对外提供自然语言查询接口面临两大挑战：准确率难保障，易出现选错表、混淆字段或聚合逻辑错误；存在安全隐患，如越权查询、写操作或慢查询拖垮数据库。为此项目设计了分层架构。
底层为语义层，建立表与字段的元数据及包含指标定义、维度的业务描述文档。提前构建大宽表或完善语义层是保障准确率的第一杠杆。中层为生成链路，涵盖问题澄清、schema linking、生成 SQL、安全校验、沙箱执行与错误自修复。时间或维度缺失时系统主动反问；按相关性筛选表字段避免将庞大库信息全量输入；生成的 SQL 需经过只读、白名单、超时与行数限制校验，沙箱执行报错时将信息回喂模型进行限次重试。
顶层为交付层，向用户展示结果表格、可供审计的 SQL 及图表建议，并将高频验证过的查询沉淀为模板供复用。
面试官会挖的难点
- 「准确率上不去先改什么」 优先完善语义层与 schema 描述解决数据输入问题。其次调整生成策略，引入 few-shot 示例或相似问题检索增强。最后才考虑对模型进行微调。
- 「库有几百张表怎么办」 采用 schema linking 分层检索，先召回相关的表名，再展开对应表的相关字段。或者按业务域将库拆分，路由给多个不同的 Agent 或语义模型处理。
- 「生成的 SQL 执行错了怎么办」 把报错信息作为新的输入交给模型修正，重试次数封顶，超限自动转人工。危险操作的 SQL 用静态规则拦截，不交给模型判断。
指标怎么讲
评测集由真实的业务取数问题、标准 SQL 以及标准执行结果组成，按问题类型分为单表聚合、多表 join、时间窗计算与对比类查询。评测时不比对 SQL 字符串的绝对一致性，而是以执行结果的准确率作为核心主指标。
过程指标重点关注 SQL 语法通过率、自修复成功率、平均耗时以及转人工率。通过对比引入该架构前后的取数耗时，以及统计高频模板的命中情况，证明系统在执行准确率与响应速度上实现了方向性的改善。
简历怎么写
- 设计 Text2SQL 查询机制，整合语义层、schema linking、受约束生成与沙箱执行链路，支持业务人员自助完成数据查询。
- 建立执行准确率评测集与只读安全校验层，涵盖权限过滤、超时限制与审计日志，通过错误自修复机制减少人工介入频次。
- 沉淀高频问题为查询模板，优化取数流程，将业务获取数据的耗时从排期等待降低至分钟级。
常见 badcase 与治理
- 字段选错或口径错误。归因为模型缺乏足够的业务背景上下文。治理动作是在语义层补充详细的字段描述与指标口径，当发生口径冲突时，严格以语义层定义的描述为准。
- 时间条件理解偏差。现象如对上月的边界划分错误，归因为自然语言中的时间表达具有模糊性。治理动作是增加时间表达标准化预处理模块，并在生成 SQL 前向用户显式确认时间范围。
- 慢查询拖垮数据库。归因为生成的 SQL 缺乏性能约束。治理动作是限制在只读副本执行，强制加入超时限制与 LIMIT 注入，并设置危险函数黑名单。
面试讲法收束
一分钟介绍项目可按四个层次展开。首先说明业务排队取数等待时间长的背景。接着阐述三个关键设计，即建立语义层保障数据输入、采用受约束生成与校验拦截风险、引入沙箱执行与自修复机制。随后说明执行准确率与取数耗时得到方向性改善的结果。最后明确系统的边界，指出复杂的表连接与口径冲突场景仍需转交人工处理。
怎么扩展
项目可进一步向数据分析方向扩展。查询完成后自动对接分析模型，生成数据洞察叙述。支持多轮追问能力，允许用户在上一轮查询结果的基础上叠加过滤条件。在交付层，将输出结果结构化，直接对接现有的 BI 工具进行可视化渲染。在权限合规方面，细化用户数据域的行级与表级过滤控制，完善查询审计日志体系。