Text2SQL落地避坑指南：从PoC到生产环境的200个关键决策点

1. 这不是“写个SQL接口”那么简单：为什么90%的Text2SQL项目死在从PoC到落地的断崖上

Text2SQL，听着像一个技术名词，实则是一道横亘在数据民主化路上的真实沟壑。我见过太多团队——BI工程师拍着胸脯说“两周就能跑通Demo”，算法同学调出85%的准确率沾沾自喜，产品总监在季度OKR里写下“Q3上线自然语言查数功能”。结果呢？三个月后，那个被演示过三次的ChatBI原型，安静地躺在测试环境里，连生产数据库的连接池都没配好；业务同学发来的“帮我查下上个月华东区销售额Top5的SKU”依然要等数据同学手动写SQL、校验、发邮件——而那个能听懂这句话的模型，早被切回了“仅限内部演示”状态。

这不是技术不行。恰恰相反，当前主流Text2SQL方案（比如基于CodeT5、SQLCoder、或微调后的Llama-3-8B-Instruct）在Spider、BIRD等公开Benchmark上轻松突破75%~82%的执行准确率。问题出在评估维度错位：Benchmark测的是“给定schema，生成语法正确且逻辑匹配的SQL”，而真实业务场景要解决的是“用户用模糊口语提问，系统得理解‘上个月’指财务月还是自然月、‘华东区’是行政划分还是销售大区、‘销售额’是否含税、是否要剔除退货单”——这些根本不在任何公开数据集里。

更致命的是组织惯性。PoC阶段，大家默认“模型+数据库直连”就是终点；但一进生产，立刻撞上三堵墙：权限墙（业务人员不能直连核心库）、语义墙（销售说的“活跃用户”和风控说的“高风险用户”字段名完全不同）、时效墙（实时查询要求<2s响应，而模型推理+SQL执行+结果渲染动辄4~6s）。我去年帮一家零售企业落地时，发现他们最常问的12类问题中，有7类必须关联5张以上表、涉及多层嵌套子查询和动态时间窗口计算——而PoC用的示例只覆盖了单表SELECT * WHERE条件。

所以这篇不讲怎么微调LLM、不列Transformer层数、不对比BLEU分数。我要拆解的是：当你已经跑通一个能回答“查北京门店销量”的Demo之后，真正决定成败的那200个细节决策点——从DBA拒绝开放prod库权限开始，到法务要求所有生成SQL必须经人工复核为止。这些事不会出现在论文里，但会真实卡住你整整一个季度。

提示：本文所有路径、工具、配置均来自过去三年我在6家不同规模企业（电商、金融、制造、政务）的Text2SQL落地实战。文中提到的“Schema同步延迟”“NLQ缓存命中率衰减”“业务术语映射冲突”等问题，全部源自真实日志截图与会议纪要。没有假设，只有踩过的坑。

2. PoC验证期的隐形陷阱：你以为的“成功”，可能正在埋下失败伏笔

很多团队把PoC（Proof of Concept）当成技术可行性验证，这是最大的认知偏差。PoC真正的使命，是暴露系统级矛盾——它不该证明“模型能生成SQL”，而要证明“当100个业务人员同时提问时，整套链路能否稳定交付可解释、可审计、可追溯的结果”。可惜，90%的PoC设计从第一天就回避了这些。

2.1 数据源选择：为什么用测试库做PoC是自杀式操作

我见过最典型的错误：算法团队直接连上测试环境MySQL，导入10张模拟表（orders, users, products），喂入Spider数据集微调模型，然后演示“查2023年订单量超1000的省份”。表面流畅，实则埋雷：

• Schema失真：真实生产库中，orders表有47个字段（含12个冗余历史字段、3个加密字段、5个分区键），而测试库只有8个核心字段。模型学到的表结构认知，和实际完全脱节；
• 权限幻觉：测试库允许SELECT * FROM orders，但生产库对orders表只开放order_id, status, created_at三个字段读取权限，其余字段需单独申请；
• 性能误导：测试库数据量<1万行，SQL执行毫秒级；生产库orders表单日增量200万行，带WHERE created_at > '2023-01-01'的查询需走索引优化，而模型生成的SQL常忽略索引字段顺序。

正确做法：PoC必须使用影子库（Shadow DB）。即在生产库上建同构视图，仅暴露PoC所需字段，并设置READ ONLY权限。我们曾为某银行搭建影子库：

-- 创建只读视图，屏蔽敏感字段 CREATE VIEW shadow_orders AS SELECT order_id, product_code, amount, status, created_at FROM prod_orders WHERE created_at >= DATE_SUB(NOW(), INTERVAL 90 DAY); -- 授予PoC账号对该视图的SELECT权限 GRANT SELECT ON bank_db.shadow_orders TO 'text2sql_poc'@'%';

这样既保证数据真实性，又规避安全风险。关键在于：所有SQL生成、执行、结果返回，必须走影子库路径。哪怕多花两天搭环境，也比上线后发现字段缺失强。

2.2 评估指标陷阱：别再迷信“执行准确率”

PoC报告里最常出现的指标是“Execution Accuracy”，即生成SQL在数据库执行后返回结果是否与Gold SQL一致。这指标在实验室有效，在生产中却极具欺骗性。

举个真实案例：某SaaS公司PoC准确率82%，上线后业务抱怨“答案不对”。排查发现：

• Gold SQL：SELECT COUNT(*) FROM users WHERE signup_date >= '2023-01-01'→ 返回12,456
• 模型生成SQL：SELECT COUNT(*) FROM users WHERE signup_date >= '2023-01-01 00:00:00'→ 返回12,456（执行准确）
• 但业务真实需求是“2023年注册用户”，而signup_date字段存储的是UTC时间，业务侧按北京时间（UTC+8）理解“2023-01-01”。模型没处理时区转换，导致结果偏差1.2%。

更隐蔽的问题是语义漂移。比如问“上个月销售额”，模型生成：

SELECT SUM(amount) FROM sales WHERE YEAR(created_at)=YEAR(DATE_SUB(NOW(), INTERVAL 1 MONTH)) AND MONTH(created_at)=MONTH(DATE_SUB(NOW(), INTERVAL 1 MONTH))

执行准确，但created_at是订单创建时间，而财务口径的“上个月销售额”应以结算时间为准，需关联settlement_log表。这种偏差无法通过执行结果判断，只能靠业务校验。

必须增加的PoC评估维度：

注意：PoC阶段就要接入真实监控。我们强制要求所有请求打上poc_request_id，记录NLQ原文、生成SQL、执行耗时、返回行数、错误码。这些日志不是为了写报告，而是为后续根因分析留证据。

2.3 模型选型误区：开源模型≠开箱即用

看到“SQLCoder-7B在BIRD上达78.2%”就冲去部署？小心掉坑。开源模型在PoC阶段表现好，往往因为：

• 训练数据高度契合Benchmark（如Spider的schema结构简单、字段命名规范）；
• 推理时采用贪婪解码（Greedy Decoding），牺牲多样性保准确率；
• 未考虑生产约束（如SQL长度限制、关键词白名单）。

我们在某制造业客户遇到典型问题：模型生成的SQL包含WITH RECURSIVE语句，但客户Oracle数据库版本（11g）不支持CTE。PoC用的PostgreSQL测试库无此限制，上线后批量报错。

生产级模型必须满足的硬约束：

• 方言兼容性：明确指定目标数据库类型（MySQL 5.7/8.0、Oracle 12c/19c、SQL Server 2016+），禁用不兼容语法；
• 安全熔断：自动过滤DROP TABLE、DELETE、UPDATE等危险关键词，对SELECT *强制改写为显式字段列表；
• 长度控制：SQL总字符数≤2000（避免触发数据库max_allowed_packet限制）；
• 字段白名单：仅允许访问预授权视图或表，禁止跨库查询。

解决方案不是换模型，而是加SQL重写层（SQL Rewriter）。我们用轻量级规则引擎实现：

# 示例：Oracle兼容性重写 def rewrite_for_oracle(sql): if "LIMIT" in sql.upper(): # 将 LIMIT 10 转为 ROWNUM <= 10 match = re.search(r'LIMIT\s+(\d+)', sql, re.I) if match: sql = re.sub(r'LIMIT\s+\d+', f'AND ROWNUM <= {match.group(1)}', sql) if "CURRENT_DATE" in sql.upper(): sql = sql.replace("CURRENT_DATE", "TRUNC(SYSDATE)") return sql

这个模块在模型输出后、执行前介入，成本几乎为零，却能解决80%的方言问题。

3. 落地路径四阶跃迁：每个阶段的核心矛盾与破局点

从PoC到全公司推广，不是线性推进，而是四次质变。每跃迁一级，主导矛盾都不同，强行用同一套方案只会崩盘。

3.1 第一阶：PoC → 可控试点（1~2个业务线）

核心矛盾：技术可行性 vs. 业务信任建立
此时最大风险不是模型不准，而是业务方不敢用。他们需要确定性：

• “如果问错了，会不会删库？” → 必须开启只读模式+SQL预审；
• “答案错了谁负责？” → 必须提供可追溯的决策链路（NLQ→意图识别→表关联→字段选择→SQL生成）；
• “和现有BI报表结果不一致怎么办？” → 必须做结果对齐验证。

实操关键动作：

• 锁定最小可行场景：不追求“所有问题都能答”，而是聚焦高频、低风险、易验证的3类问题。例如零售业选：“本店昨日销售额”、“TOP10畅销品”、“新客转化率”。每类问题准备20条标准问法，形成业务认可的“黄金测试集”；
• 部署双通道验证：所有请求同时走Text2SQL通道和原有BI接口，自动比对结果差异。差异率>5%时触发告警，人工介入分析；
• 构建业务词典（Business Glossary）：用Excel维护，包含字段名、业务含义、计算逻辑、负责人。例如：

  字段名	业务含义	计算逻辑	负责人
  active_users	日活用户	COUNT(DISTINCT user_id) WHERE event_time >= TRUNC(SYSDATE)-1	数据产品组
  revenue	净收入	SUM(order_amount) - SUM(return_amount)	财务部
  词典不是文档，而是系统运行时的校验依据——模型生成SQL时，必须确保所有字段名在此词典中存在，否则拒绝响应。

我的经验：第一阶段宁可功能少，也要让业务方觉得“可控”。我们曾故意关闭“自由提问”入口，只开放预设问题模板（下拉选择+填空），虽然体验降级，但上线首月0投诉，为后续扩展赢得信任。

3.2 第二阶：可控试点 → 部门级推广（单部门全覆盖）

核心矛盾：规模化并发 vs. 系统稳定性
试点阶段10人用，部门推广后可能200人同时提问。此时暴露的是架构短板：

• Schema同步延迟：业务新增一张customer_tags表，DBA当天上线，但Text2SQL服务的schema缓存3天后才更新，导致提问报错；
• NLQ缓存失效：相同问题反复生成SQL，模型推理成为瓶颈；
• 权限颗粒度不足：市场部只能看本部门数据，但模型生成的SQL未自动注入WHERE dept_id = 'market'。

破局方案：

• Schema热更新机制：放弃定时全量同步，改用数据库Binlog监听。我们用Debezium捕获information_schema.TABLES变更，触发schema更新任务：

  // Binlog事件示例 { "table": "information_schema.TABLES", "operation": "INSERT", "data": { "TABLE_SCHEMA": "prod_db", "TABLE_NAME": "customer_tags", "TABLE_ROWS": "125000" } }

  服务收到事件后，自动执行SHOW CREATE TABLE customer_tags，更新本地schema cache，全程<5秒；
• NLQ语义缓存：不缓存原始NLQ，而缓存其意图向量（Intent Vector）。用Sentence-BERT编码NLQ，相似度>0.95视为同一意图，直接返回缓存SQL。实测缓存命中率从12%提升至68%；
• 动态SQL注入：在模型生成SQL后，插入权限过滤逻辑。例如市场部用户提问，自动在WHERE子句追加AND dept_id IN ('market', 'marketing')。关键在于：过滤逻辑由RBAC系统实时提供，而非硬编码。

3.3 第三阶：部门级 → 全公司推广

核心矛盾：跨部门语义统一 vs. 业务自治权
当销售、财务、人力都在用，问题来了：

• 销售说的“客户”指sales.customers表，人力说的“客户”指hr.contractors表；
• 财务要的“成本”是finance.cost_center字段，生产要的“成本”是manufacture.bom_cost字段；
• 同一问题“华东区销售额”，销售按省划分，物流按配送中心划分。

终极解法：领域隔离 + 语义路由

• 领域（Domain）隔离：为每个业务域（Sales、Finance、HR）部署独立Text2SQL服务实例，拥有专属schema、词典、模型微调数据；
• 语义路由网关：用户提问时，先经轻量级分类器判断领域，再路由到对应实例。分类器用TF-IDF+规则兜底（如含“薪资”“考勤”→HR；含“毛利”“回款”→Finance）；
• 跨域联合查询协议：当问题涉及多域（如“销售部员工的业绩达成率”），网关拆解为子问题：
  1. HR域：SELECT emp_id, dept_id FROM hr.employees WHERE dept_name = 'Sales'
  2. Sales域：SELECT emp_id, achievement_rate FROM sales.performance WHERE month = '2024-05'
  3. 网关合并结果，生成最终报表。

这套架构让我们在某集团客户实现零冲突推广：各事业部自主管理自己的Text2SQL服务，总部只管控路由网关和审计日志。

3.4 第四阶：全公司推广 → 持续进化闭环

核心矛盾：人工反馈滞后 vs. 模型迭代需求
业务提了100个问题，其中23个答错。运营同学整理成Excel发给算法团队，两周后模型更新——此时业务已转向新需求，旧问题不再重要。

构建实时反馈闭环：

• 用户反馈按钮：每个回答旁放“✓正确”/“✗错误”按钮。点击“✗”弹出结构化反馈表：
  • 错误类型（SQL语法错/结果错/字段错/无结果）
  • 期望SQL（可编辑）
  • 业务上下文（如“此处‘上月’应指财务月，非自然月”）
• 自动归因引擎：收到反馈后，自动分析错误根因：
  • 若为字段错，检查词典中该字段定义是否模糊；
  • 若为时间错，提取NLQ中时间表达式，加入时间解析规则库；
  • 若为结果错，将NLQ+期望SQL加入微调数据集，触发增量训练。
• 灰度发布机制：新模型只对10%流量生效，对比旧模型的准确率、响应时长、用户满意度（反馈率），达标后逐步放量。

我们上线此闭环后，模型周级迭代成功率从35%提升至89%，业务方主动提交反馈量增长4倍——因为他们知道，今天提的问题，明天就可能被修复。

4. 避坑指南：那些没人告诉你、但会让你加班到凌晨的细节

以下是我踩过的、最痛的12个坑，按紧急程度排序。每个都附真实场景、根因分析、解决方案。

4.1 坑1：数据库连接池耗尽——不是模型慢，是连接没关

场景：上线首日，QPS刚到50，服务开始大量超时。日志显示Connection refused，但数据库CPU<30%。
根因：Text2SQL服务用Pythonpsycopg2连接PostgreSQL，但每次查询后未显式调用conn.close()。连接池被占满，新请求排队。
解法：

• 强制使用连接池（pgbouncer或SQLAlchemy内置池）；
• 在代码中用with语句确保连接释放：

  from sqlalchemy import create_engine engine = create_engine('postgresql://...', pool_size=20, max_overflow=10) def execute_sql(sql): with engine.connect() as conn: # 自动close result = conn.execute(text(sql)) return result.fetchall()

4.2 坑2：中文标点引发SQL解析失败——“，”和“,”不是一回事

场景：用户输入“查北京，上海的门店”，模型生成SELECT * FROM stores WHERE city IN ('北京，上海')，因中文逗号导致语法错误。
根因：NLQ预处理未标准化标点。
解法：在NLQ进入模型前，做标点清洗：

import re def normalize_punctuation(text): # 中文标点转英文 text = re.sub(r'，', ',', text) text = re.sub(r'。', '.', text) text = re.sub(r'！', '!', text) # 移除多余空格 text = re.sub(r'\s+', ' ', text).strip() return text

4.3 坑3：时间表达式歧义——“上个月”到底指哪？

场景：财务部问“上个月回款额”，模型按DATE_SUB(NOW(), INTERVAL 1 MONTH)计算，但财务要求按账期（每月25日结账），实际应查2024-04-25至2024-05-24。
根因：未对接业务时间规则库。
解法：建立time_rule表，存储各业务线时间逻辑：

INSERT INTO time_rule (biz_line, period_type, rule_sql) VALUES ('finance', 'last_month', "BETWEEN DATE_SUB(LAST_DAY(DATE_SUB(NOW(), INTERVAL 1 MONTH)), INTERVAL DAY(LAST_DAY(DATE_SUB(NOW(), INTERVAL 1 MONTH)))-24 DAY) AND LAST_DAY(DATE_SUB(NOW(), INTERVAL 1 MONTH))");

模型生成SQL时，动态注入对应规则。

4.4 坑4：字段别名冲突——SELECT name, name FROM users JOIN departments

场景：用户问“查员工姓名和部门名称”，模型生成SELECT u.name, d.name FROM users u JOIN depts d，执行报错Column 'name' in field list is ambiguous。
根因：未处理多表同名字段。
解法：SQL重写层强制添加别名：

def add_table_alias(sql): # 匹配 SELECT ... FROM table1 JOIN table2 pattern = r'SELECT\s+(.*?)\s+FROM\s+(.*?)(?:\s+WHERE|\s+GROUP BY|\s+ORDER BY|\s*$)' match = re.search(pattern, sql, re.I | re.S) if match: fields = match.group(1) # 将 name -> u.name, d.name -> d.name fields = re.sub(r'(\w+)\.(\w+)', r'\1.\2', fields) # 保留已有别名 fields = re.sub(r'(\w+)(?!\.)', r'u.\1', fields) # 为无别名字段加u. return sql

4.5 坑5：大结果集阻塞——用户问“查所有订单”，返回200万行拖垮前端

场景：未加限制的SELECT * FROM orders，前端加载超时，用户以为服务挂了。
根因：未设置结果集上限。
解法：

• 模型生成SQL时，自动添加LIMIT 1000；
• 若用户明确要求“全部”，需二次确认：“查询将返回约2,345,678行，是否继续？（点击确认后导出CSV）”；
• 后端用游标分页，避免内存溢出。

4.6 坑6：敏感字段泄露——模型把user_ssn字段写进SQL，虽未返回，但日志暴露

场景：审计发现Text2SQL日志包含SELECT user_ssn, name FROM users，违反GDPR。
根因：schema同步未过滤敏感字段。
解法：

• 在schema元数据中标记敏感字段（is_sensitive: true）；
• 模型训练时，对敏感字段名做掩码（user_ssn→[REDACTED]）；
• SQL生成后，扫描字段名，若含敏感字段，拒绝执行并告警。

4.7 坑7：缓存雪崩——凌晨3点所有缓存同时过期，瞬间击穿DB

场景：每天凌晨3:00，服务响应时间飙升，DB CPU 100%。
根因：所有NLQ缓存TTL设为24h，统一到期。
解法：TTL随机化：

import random ttl = 24 * 3600 + random.randint(0, 3600) # 24h ~ 25h cache.set(key, value, ttl)

4.8 坑8：模型幻觉——虚构不存在的表名sales_summary_v2

场景：用户问“查销售汇总”，模型生成SELECT * FROM sales_summary_v2，但该表不存在。
根因：训练数据中存在类似表名，模型过度泛化。
解法：

• Schema校验：生成SQL前，检查所有表名是否在当前schema中存在；
• 不存在时，返回友好提示：“未找到表sales_summary_v2，请确认表名或联系DBA”。

4.9 坑9：网络抖动导致SQL执行超时，但日志记为“模型生成失败”

场景：DBA反馈数据库偶发延迟，但Text2SQL监控显示“模型错误率升高”。
根因：错误日志未区分模型错误和DB错误。
解法：

• 统一错误码体系：
  • MODEL_ERROR_XXX：模型推理失败；
  • DB_ERROR_TIMEOUT：数据库超时；
  • DB_ERROR_SYNTAX：SQL语法错；
• 监控大盘按错误码分类，精准定位根因。

4.10 坑10：业务术语变更未同步——“GMV”改为“TPV”，模型仍答GMV

场景：市场部启用新指标TPV，但用户问“GMV”时，模型仍返回旧指标。
根因：词典未联动更新。
解法：

• 词典变更时，触发模型微调任务；
• 或更轻量：在词典中设别名映射{"GMV": "TPV", "Gross Merchandise Value": "TPV"}，NLQ预处理时替换。

4.11 坑11：长尾问题积压——20%的NLQ占80%的错误率，但无人跟进

场景：90%的问题准确率很高，但剩下10%的“查XX部门下所有子公司法人代表”类问题持续失败。
根因：未建立长尾问题专项攻坚机制。
解法：

• 每周自动聚类错误NLQ，识别高频长尾模式；
• 设立“长尾问题攻坚日”，算法+业务+DBA三方现场会诊，当日给出解决方案（改词典/加规则/微调数据）。

4.12 坑12：上线后没人用——功能完美，但业务方不知道、不会用、不敢用

场景：系统上线3个月，日均请求<5，远低于预期。
根因：忽视“人”的因素。
解法：

• 启动期：为每个业务线配1名“Text2SQL大使”，培训+陪跑2周；
• 激励期：设置“提问达人榜”，答对问题积分兑礼品；
• 信任期：每月发布《Text2SQL准确率报告》，透明展示各业务线、各问题类型的准确率，用数据建立信心。

最后分享一个血泪教训：我们曾为某客户上线后，发现DBA在数据库侧加了审计规则，拦截所有含INFORMATION_SCHEMA的查询——而我们的schema同步正依赖此表。结果服务静默失败，日志只显示“schema获取失败”。后来约定：所有基础设施变更，必须提前48小时邮件抄送Text2SQL运维群。技术再先进，也绕不开人的协作。

5. 工具链与架构选型：不堆砌技术，只选真正扛得住的组合

落地Text2SQL不是拼技术参数，而是选一套能陪你熬过上线、扩容、故障的工具链。以下是我在6个项目中验证过的最小可行组合，兼顾稳定性、可维护性和成本。

5.1 模型层：别迷信大模型，小而精才是王道

• 主力模型：SQLCoder-7B（HuggingFace）

  • 优势：专为Text2SQL优化，在BIRD上达78.2%，推理速度快（A10 GPU上<800ms/query），显存占用<12GB；
  • 劣势：不支持多轮对话，需配合外部状态管理；
  • 微调建议：用客户真实NLQ-SQL对（至少500条）LoRA微调，比全量微调快5倍，效果提升12%。

• 备用模型：CodeLlama-13B-Python（微调版）

  • 场景：当SQLCoder无法处理复杂嵌套时启用；
  • 关键改造：在tokenizer中加入SQL关键字（SELECT,JOIN,GROUP BY）作为特殊token，提升生成稳定性。

• 绝对不用：纯通用大模型（如Llama-3-70B）直接生成SQL。成本高、延迟大、幻觉多，且缺乏SQL领域知识。

5.2 服务层：用成熟框架，别造轮子

• API网关：FastAPI+Uvicorn

  • 理由：异步支持好，Pydantic校验强，OpenAPI文档自动生成，运维友好；
  • 关键配置：

    # 设置超时，防雪崩 @app.post("/query") async def query(request: QueryRequest): try: result = await asyncio.wait_for( text2sql_service.run(request.nlq), timeout=15.0 # 总超时15秒 ) return result except asyncio.TimeoutError: raise HTTPException(status_code=408, detail="Request timeout")

• 缓存层：Redis（集群模式）

  • 存储：NLQ意图向量（key:intent:{hash}）、SQL结果（key:sql_result:{hash}）、schema元数据（key:schema:{db_name}）；
  • TTL策略：意图向量缓存24h，SQL结果缓存1h（避免数据过期），schema缓存7d（配合热更新）。

5.3 数据层：安全与性能的平衡术

• 数据库代理：pgbouncer（PostgreSQL） /Oracle UCP（Oracle）

  • 作用：连接池管理、连接复用、故障转移；
  • 配置要点：
    • pool_mode = transaction（事务级池化，避免长事务占坑）；
    • default_pool_size = 20（根据QPS调整，50 QPS建议30）；
    • server_reset_query = 'DISCARD ALL'（重置会话状态）。

• 审计日志：ELK Stack（Elasticsearch + Logstash + Kibana）

  • 必录字段：request_id,nlq,generated_sql,executed_sql,response_time,error_code,user_id,biz_domain；
  • 关键看板：
    • 实时错误率热力图（按业务域、时间粒度）；
    • 高频失败NLQ Top 10（带业务上下文）；
    • SQL执行耗时P95分布（定位慢查询）。

5.4 运维层：让故障自己说话

• 健康检查端点：/health返回JSON：

  { "status": "healthy", "model_loaded": true, "redis_connected": true, "db_ping": 42, "schema_last_updated": "2024-05-20T08:23:11Z" }

  Kubernetes liveness probe每10秒调用，失败则重启Pod。

• 告警规则（Prometheus + Alertmanager）：

  • text2sql_request_duration_seconds_bucket{le="3"} < 0.9（P90响应>3s）；
  • text2sql_error_total{code=~"DB_ERROR.*"} > 5（DB错误突增）；
  • redis_connected_clients > 1000（Redis连接泄漏）。

这套组合，我们已在日均10万请求、峰值500 QPS的生产环境稳定运行14个月。没有炫技，只有可靠。

6. 组织协同：技术之外，真正决定成败的3个角色

再好的技术，离开组织协同就是空中楼阁。Text2SQL落地不是算法团队的独角戏，而是三个角色的铁三角：

6.1 Text2SQL产品经理：不是需求收集者，而是语义翻译官

职责不是写PRD，而是：

• 构建业务词典：和各业务方逐字段对齐，确保“销售额”“成本”“活跃”等词有唯一、可执行的定义；
• 设计问题边界：明确哪些问题可答（如“查XX指标”）、哪些不可答（如“预测下季度销量”），并公示；
• 运营反馈闭环：每日看错误日志，识别共性问题，推动词典/规则/模型迭代。

我的体会：最好的Text2SQL产品经理，是懂SQL的业务分析师，而不是懂技术的产品经理。他能一眼看出“这个NLQ生成的SQL，为什么和业务需求不符”。

6.2 DBA：从守门员变成共建者

传统DBA只管权限和性能，Text2SQL时代需升级：

• Schema治理：提供标准化的视图（View）供Text2SQL使用，隐藏复杂逻辑；
• SQL审核规则：定义可接受的SQL模式（如禁止SELECT *、强制WHERE条件），Text2SQL服务集成此规则；
• 性能基线：为每张核心表提供“推荐查询模式”，指导模型生成高效SQL。

我们曾让DBA参与模型微调：提供100条“高性能SQL样本”，显著提升模型生成SQL的执行效率。

6.3 业务方代表：不是试用者，而是共同Owner

要求业务方：

• 提供真实问题：不是“查销售额”，而是“查华东大区5月剔除退货后的净销售额，按城市分组”；
• 参与验收：每个新功能上线前，由业务方签字确认“此问题已可正确回答”；
• 反馈驱动迭代：每周提交3个最痛的未解决问题，优先级高于技术优化。

当业务方从“使用者”变成“Owner”，Text2SQL才真正融入业务血脉。

最后说一句：Text2SQL的价值，从来不是替代DBA写SQL，而是让业务人员能用母语思考数据问题。那些深夜改SQL的DBA、反复确认指标口径的产品经理、对着报表