企业官网建设流程全解析

同一个团队，问一句“上个月华东区的退货率是多少”，一个模型直接拼出了能跑的SQL，另一个模型先是编造了一张不存在的表，被数据库报错之后又开始二次幻觉。SQL生成这个场景，可能是大模型落地里最两极分化的战场：做出来的团队觉得简单到不值得吹，做不出来的团队觉得模型全是废物。两边都是对的，差别不在模型智力，而在定制能力和推理稳定性这两条线上下的功夫。

写SQL不是写作文。数据库有严格的schema约束、方言差异、权限边界和执行代价，模型输出哪怕只差一个字段名，从“看起来能跑”直接变成“跑了错账”。所以在选模型这件事上，我始终坚持一个判断标准：不要选“参数最大”的，要选“最懂你的库、且敢为结果兜底”的。这篇文章就先把这个判断标准拆开讲清楚，再给你一套可以直接复用的选型框架、定制方法和推理稳定性保障方案。针对标题里提到的火山引擎，我结合自己实际使用的经验，讲清楚它在算力支撑层面到底解决了什么问题，以及你在搭智能Agent的时候应该怎么用。

1. SQL生成场景的需求拆解：为什么选型比想象中难

1.1 定制能力：模型必须“懂你的库”

很多刚接触这个方向的同学有一个误区，觉得SQL生成就是把自然语言丢给大模型，让它输出一段SQL。如果你跑通的是MySQL自带库、网上公开的样例表，确实如此。但凡是落到企业内部的业务系统，问题立刻变得不一样：表名是几十个字母的缩写，字段命名规范混合了三种风格，业务口径埋藏在存储过程里，同义词和指标在ETL层做了三层映射。这种环境里，通用模型再强也是“外人”，它不知道你们公司说的“有效订单”到底是什么口径。

定制能力在这里体现为几个具体层面。第一是schema感知，模型要能理解你的表结构、字段含义、主外键关系，而不是对着空气猜表名；第二是方言适配，同样一句“取前十条”，MySQL要LIMIT，SQL Server要TOP，Oracle要ROWNUM，模型输出要是用错方言，整个Agent流程直接断掉；第三是业务语义对齐，比如“GMV”“净收入”“退款率”这类指标，模型要知道SQL里对应哪个字段、要不要排除某些状态。这三个层面做不到，SQL准确率就上不去。

1.2 推理稳定性：准确之外还要扛得住高并发

定制能力解决的是“写得对不对”，推理稳定性解决的是“写得稳不稳、跑得快不快”。我第一次把SQL生成Agent推到内部测试时，最大的感受是：单条query的效果再好，也扛不住生产环境的多轮并发。用户翻来覆去地问、不同的人同时问、一次对话里带着前文的上下文接着问，模型在压力下会出现几种典型退化：要么首字延迟高到用户以为系统挂了，要么上下文一长就开始丢前面的表结构约束，要么多个请求并发时整卡推理速度雪崩。

不要小看“稳”这个字。对一个Agent系统来说，稳定性的本质是延迟可控、错误可预期、资源水位可管理。SQL生成虽然单次请求大概只有几百毫秒到几秒，但它后面挂着数据库执行、结果集格式化、前端渲染，任何一个环节因为模型推理抖动拖长，整个链路的P99都会很难看。我们在实际项目中把目标定在P95小于4秒，P99小于8秒，这在纯模型评测里根本看不出差距，但在生产环境里就是能不能用的分水岭。

1.3 定制与稳定为什么天然打架

这是最容易被忽略的一点：定制能力和推理稳定性往往是冲突的。给模型做微调，权重变了，可能损害通用能力；给prompt堆schema和few-shot，上下文变长，首字延迟和KV缓存开销跟着涨；引入RAG检索元数据，又多了一层检索失败的抖动。说到底，定制是在增加系统的复杂度和计算负担，而稳定是要把这些复杂度控制在可接受的范围内。选型的时候只看模型本身的分数是不够的，必须把“定制方案+算力底座+Agent编排”放在一起通盘考虑，这也是这篇文章想给你的核心思路。

2. 大模型选型：我用九个指标代替“哪家更强”

2.1 决策维度拆解：从模型能力到工程约束

先说结论：SQL生成场景下选模型，我建议你用一套固定的指标矩阵去打分，而不是听别人说“某某模型写SQL很猛”就直接上车。我自己的评估矩阵包含九个维度，分成模型能力和工程约束两组。

模型能力组：指令遵循与Schema感知、SQL方言支持度、多轮上下文保持、复杂嵌套与子查询生成、自然语言反问与澄清能力。工程约束组：推理延迟与并发表现、私有化部署或API成本、微调/定制开放度、周边生态和工具链成熟度。

为什么把“指令遵循”放在能力组第一？因为SQL生成本质上是一个强约束生成任务，模型必须严格按照你给的表结构信息来生成，而不是凭训练记忆“自由发挥”。不少通用模型在开放写作里表现惊艳，一到严格约束场景就开始胡编，这类模型再聪明也不能用。

方言支持度这一点容易被低估。如果你只需要润色一段MySQL，模型差距不大；但如果你面对的是SQL Server、Oracle、达梦、PostgreSQL混用的老企业，方言支持度直接决定你要不要花大力气做后处理。实测下来，主流商用模型和部分开源模型在常见方言上的支持已经不错，但冷门方言还是得靠few-shot把语法样例喂进去。

2.2 开源闭源怎么配：三种主流组合

我给三档不同诉求的团队分别给过选型建议，这里也分享一下。

第一档是快速验证型，团队规模小、要一周内出Demo，直接选用托管API形式的商用模型，比如火山引擎豆包大模型。理由很直接：不考虑部署成本，推理速度和稳定性由平台兜底，你只需要专注把Agent流程跑通。第二档是数据敏感型，SQL涉及核心经营数据，不允许出域，选开源基座私有化部署，比如Qwen系列、DeepSeek系列，配合LoRA微调做定制。第三档是混合型，把不敏感的通用查询走API，把高敏感、高复杂度查询走私有化小模型，中间用Agent做路由。混合型是大多数中大型企业最终会走向的形态，但不要一上来就做，先把业务边界摸清再切。

2.3 用你自己的表做评测，别信公开Benchmark

选型阶段最忌讳直接拿公开榜单说话。榜单上写的是通用任务平均分，不是你的业务SQL准确率。我在多个项目里反复验证过一个事实：同一款模型，在公开Text-to-SQL榜单上排名前列，到了你公司的业务库上可能被一个小众表结构打得找不着北。

正确做法是自建评测集。从真实业务里收集50到100条用户问句，覆盖单表查询、多表Join、复杂聚合、时间区间过滤、业务口径别名这几类典型场景，然后人工写出标准SQL作为答案。跑的时候统计三个核心指标：SQL完全匹配率、SQL可执行率（语法和schema都正确）、结果集正确率。前两个能快速筛掉不合格的选手，第三个才是真正的业务可用性指标。这里有个容易踩的坑：完全匹配率低不代表不能用，因为同一句问话本来就有多种等价写法，所以我会同时用“可执行率+结果集正确率”作为主要筛选条件，完全匹配率只做参考。

3. 定制能力的落地姿势：提示词、索引与微调的三层漏斗

3.1 第一层：提示词与工具定义，轻量且见效快

定制不一定非要动模型。在SQL生成场景里，一半以上的准确率问题可以靠提示词工程和工具定义解决。我经常说，把模型想象成一个刚入职的实习生，你把表结构文档、SQL编写规范、历史正确示例给他看，他写出来的东西天然比凭记忆瞎写靠谱。

具体做法是设计一套标准的System Prompt，里面写清楚：数据库类型和版本、Schema摘要、字段命名规范、SQL输出格式要求，比如只输出SQL不输出解释、禁用SELECT *、金额字段必须用DECIMAL处理、时间字段统一格式。再配合几个高质量few-shot示例，一个示例覆盖一种query类型，示例里的表和字段都用实际业务的，而不是网上抄来的。

工具定义对Agent场景更重要。给模型暴露三个工具：list_tables，返回库里的表清单；get_schema，返回指定表的字段、类型、注释、索引；execute_sql，在只读权限下执行SQL并返回结果。这三个工具组合起来，模型就能在“先看有哪些表、再看字段结构、生成SQL、执行验证”这个闭环里工作。用工具定义做定制的好处是，它不增加模型本身的计算负担，只是在推理时多几次工具调用，延迟增加有限，但准确率提升非常明显。

3.2 第二层：RAG把元数据灌进去，动态拼装上下文

固定写在Prompt里的Schema信息有上限。当一个库有几百张表、上千个字段，你不可能全部塞进去，塞进去模型也记不住，还会把真正重要的约束淹没掉。这时候就要上RAG，把元数据、业务口径、历史SQL示例切分成片段，根据用户问句实时检索出最相关的部分，动态拼装成上下文。

我见过很多团队在RAG这一层翻车，原因高度一致：把文档直接切块丢进向量库，以为向量检索就万事大吉。SQL场景的难点在于，用户问的是“退款率”，但相关文档里可能叫“退款金额占比”，语义上相关但字面完全不同；而表里的字段可能叫rb_rate，纯向量检索很难命中。我的经验是，RAG这套不能只用向量，要做一个混合检索：向量召回+关键词/规则召回+业务别名映射表，三层一起上。别名映射表尤其重要，把业务常用语和字段别名做成静态映射，成本极低但效果立竿见影。

3.3 第三层：LoRA微调，什么时候该动模型

如果提示词和RAG都做足了，准确率还是卡在某个瓶颈上，说明问题可能出在模型本身，比如模型对特定SQL方言的语法结构生成能力不足，或者对你们业务里的复杂嵌套查询力不从心。这时候才考虑微调，而且我建议只做LoRA这类参数高效微调，不要一上来就全参微调。

微调不是数据越多越好，而是要精。我的项目经验是，先攒200到500条高质量样本，每条包含“业务问句+正确SQL+SQL说明”三部分，样本要刻意覆盖RAG和提示词搞不定失败场景，比如长尾方言、复杂子查询、字段别名映射等。微调完不是结束，而是回到第2.3节的自建评测集上重新跑，看三类指标有没有提升，同时要做回归测试，确保微调没有破坏模型的通用指令遵循能力。这一层的定制能力最强，但成本和风险也最高，所以我的建议永远是把它放在最后一层，先把前两层的钱花到位。

4. 推理稳定性与算力支撑：火山引擎在关键位置做的事

4.1 资源水位规划：一张表算出你要多少GPU

先回答一个非常多团队问我的问题：“SQL生成到底需要多大的算力？”答案取决于三个变量：模型参数量、并发请求量、平均上下文长度。它们共同决定了显存容量和推理吞吐，算起来并不复杂。

显存的估算逻辑是模型权重+KV Cache+推理开销。7B模型权重半精度大概14GB，14B大概28GB，32B大概64GB，这是纯权重的量。但真正吃显存的是KV Cache，上下文越长、并发越高，KV Cache指数级膨胀。我自己常用的经验公式是：单实例显存需求约等于权重占用乘以1.5到2倍，比如32B模型权重大概64GB，单实例建议配A100/H100 80GB或两张L40S。

并发和吞吐要一起算。假设你的Agent平均每天有2000次SQL生成请求，峰值是均值的三倍，也就是6000次，均匀分布在8小时的业务高峰里，平均每秒大概0.7次，峰值大概2次。这个量级其实不高，但如果你要做多轮Agent循环，一次用户提问可能触发3到5次模型推理，实际QPS要按倍数放大。QPS乘以单次推理耗时就得到需要的并发推理能力，再乘以算力冗余系数，一般留1.5倍高峰余量，就能得到GPU实例数。这个表我建议每个团队在选型之前自己填一遍，不填不知道自己到底在为什么买单。

4.2 推理加速的工程手段：连续批处理与KV Cache复用

选好了GPU资源，还要把推理引擎配对。同样是跑开源模型，直接用HuggingFace的Transformers库硬跑，和用vLLM这类推理框架跑，吞吐差距能到好几倍。SQL生成场景特别适合用连续批处理与PagedAttention这类优化，因为请求的特点是短文本多轮交互、上下文在变化，KV Cache管理得当能大幅降低显存碎片。

火山引擎在推理稳定性上的价值恰恰体现在这里。如果你走火山方舟的托管推理服务，底层推理框架、KV Cache管理、显存调度这些事平台已经帮你优化过了，你不用自己调vLLM参数，也不用在凌晨三点爬起来看是不是OOM了。如果你要私有化部署开源模型，火山引擎的GPU云服务器配合镜像市场里预装好的推理框架，也能少走很多弯路。就我的经验，团队做SQL生成Agent，前两三周根本不该花时间在推理优化上，应该先用托管服务把业务跑通，等QPS和延迟数据出来了，再决定要不要自己做推理层优化。

4.3 应用层弹性与高可用：不要让模型成为单点

推理稳定性还包含一个容易被忽视的层面：高可用。模型推理服务一旦挂掉，整个Agent全链路瘫痪。落到具体实践上，至少要做三件事：多副本部署，关键路径上的模型推理至少两个副本，故障时自动切换；限流与排队，在入口做令牌桶限流，超出水位时让请求排队而不是直接压垮后端；降级策略，模型服务不可用时，回退到模板SQL或人工入口，不要让用户直接面对错误页。

火山引擎在这个层面的价值是算力池的弹性伸缩。SQL生成请求有明显的波峰波谷，比如月初月末财务对账密集，平时相对平稳。用固定规格的GPU实例去扛波峰，成本浪费很大；用弹性伸缩组根据队列深度自动扩容缩容，能把成本控制得比较理想。我在一个数据服务项目里实践过这套：把CPU部分放在普通云服务器上，把模型推理放在按需创建的GPU实例上，冷启动问题用常驻最小副本解决，高峰时自动扩容到4个副本，实测成本下降了差不多三分之一，P99延迟基本稳定。

4.4 Agent编排层的输入输出：流式、超时与降级

如果你的SQL生成Agent是面向对话交互的，那么流式输出是必选项。用户看到“正在生成SQL…”转圈超过3秒就会失去耐心，但SQL本身可能就要生成5秒甚至10秒，流式输出能把首字延迟压到几百毫秒，让用户感知到“系统在动”。火山引擎的豆包大模型API原生支持流式输出，在Spring AI这类框架里配置streaming选项就行，我在多个项目里都是直接启用，几乎没额外成本。

超时控制比想象中重要。SQL生成虽然快，但加上RAG检索、工具调用、数据库执行，整条链路可能膨胀。我给团队定的超时规范是：RAG检索500毫秒、模型首字延迟2秒、SQL完整生成10秒、数据库执行30秒，每层独立超时，超过就返回“当前请求繁忙，请稍后重试”。这套规范上线之后，用户投诉率掉了60%以上，原因不是模型变强了，而是系统不再让人干等了。

5. Agent编排与错误兜底：SQL生成能落地的另一半功夫

5.1 工具设计的正确打开方式

SQL生成Agent能不能稳定产出，工具设计占一半。我把工具设计成三个，尽量精简，避免给模型过多选择。

list_tables工具返回数据库内表清单及各表注释。get_schema工具接收一个表名，返回建表语句级别的字段清单，包含字段名、类型、注释和索引信息。execute_sql工具接收模型生成的SQL，在只读账号下执行并返回前50行结果和行数。这三个工具的调用顺序一般是固定的：先list_tables缩小范围，再get_schema确认字段，最后生成SQL并用execute_sql验证。模型不是靠逻辑推理一步步来的，而是靠工具反馈一步步校准的。

5.2 把SQL执行错误变成模型的“第二次机会”

这里分享一个让准确率直接提升10个点的技巧：不要指望模型一次生成正确，而是把SQL执行后的报错信息重新喂给模型，让它根据报错修正。数据库报错本身就是最强的提示，比如“字段user_id不存在，你是不是想用uid”，模型拿到这个反馈之后，大概率能在新一轮生成里修正。

这个机制在代码里写起来很简单：模型生成SQL → 执行 → 如果报错，把完整报错信息拼进上下文 → 重新生成。关键在于控制重试次数，一般最多2轮，超过就放弃并返回人工兜底。我见过有些团队让模型无限重试，结果模型在错误循环里打转，还消耗大量推理资源。两轮以内的修正收益明显，三轮以上边际收益骤降。

5.3 安全护栏：只读、超时、LIMIT是底线

SQL生成Agent放生产环境，安全不能靠“相信模型”。第一道护栏是数据库账号权限，必须用只读账号，最好连存储过程都禁用。第二道是强制LIMIT，模型生成的查询必须限制返回行数，防止一条失控SQL把数据库拖垮。第三道是超时熔断，数据库执行超过30秒直接杀掉查询。第四道是敏感字段脱敏，查询结果里的手机号、身份证、银行账号等字段做脱敏处理再展示。

这套护栏的成本极低，但重要性远高于任何模型优化。我在上线初期就遇到过一次模型生成了一条全表扫描加笛卡尔积的SQL，直接把业务库CPU打满，从那次之后所有Agent的SQL执行都强制套上了超时和LIMIT，再也没有出过类似事故。

5.4 评测闭环：不止上线前，还要上线后持续盯

很多团队的评测只做上线前一次，上线之后就再也不看了。SQL生成Agent上线后，业务问法演进、数据库表结构变更、新业务口径出现，都会导致准确率缓慢下滑。要建立一个持续评测机制：每日从真实流量里抽样一批用户问句和模型SQL，自动执行验证，生成准确率和可执行率报表，低于阈值自动告警。同时通过用户反馈按钮和人工抽检，把离线评测集不断补充进新的bad case。

我用这套机制的实际感受是：上线一个月后模型没变，SQL准确率却从上线初的86%掉到了79%，排查后发现是数据库新增了三张业务表，RAG的元数据索引没同步更新。持续评测暴露的是系统性问题，不只是模型能力问题。

6. 常见问题与踩坑实录

6.1 不扫清这些坑，模型再强也白搭

第一个高频坑是模型幻觉字段名。模型生成了一条SQL，字段名看着合理，实际在表里根本不存在。排查下来原因几乎都是RAG没有把正确schema喂进去，模型凭训练记忆“猜了一个字段”。解决办法是上线前对每个数据库连接做一次字段名有效性校验清单，在Prompt里明确写出禁用词表，自己先枚举常见的幻字段名。

第二个坑是方言差异。同一个模型，在MySQL上调通了，切到SQL Server就废了一半。模型基座更倾向生成MySQL语法，要提前在Prompt里强制声明数据库类型，并给3到5条对应方言语法的few-shot示例。

第三个坑是上下文过长导致首字延迟飙升。业务复杂时，用户的问题+RAG检索结果+历史对话可能堆到几千个token，模型首字延迟从300毫秒飙到2秒。光靠调整模型解决不了，要在应用层做上下文裁剪：只保留最近两轮对话、RAG结果只取top3。

第四个坑是并发打满。早期用单GPU实例扛所有流量，用户一多，请求排队超过20秒，体验极差。后来上了弹性伸缩和多副本，这个问题才算彻底解决。

6.2 火山引擎实操配置心得

这里讲几个我在火山引擎上实际遇到并解决的配置问题。第一个是API Key权限管理，团队里每个人各开各的Key，密钥散落各处，后来统一收敛到项目级的API Key，在服务端统一调用，前端不直连模型服务。第二个是弹性伸缩策略配置，一开始把冷却时间设得太短，GPU实例频繁创建销毁，反而花了冤枉钱，后来把冷却时间调长到5分钟，配合队列深度作为伸缩指标，稳定了很多。第三个是如果桌面端或本地调试工具要接入火山引擎的模型服务，注意确认Endpoint配置和鉴权方式要对得上，我自己在调试阶段就遇到过Endpoint填错导致一直401的情况，排查了半天。

另外一个小技巧，如果你用的是Spring AI这类框架接入火山引擎豆包大模型，流式输出的配置项记得打开，默认情况下有些框架版本是非流式的，首字延迟体验差距很大。还有一点，模型服务的超时时间要在客户端和服务端两侧都设置，只设一边不够，我之前只设置了服务端超时，客户端那边一直等待到浏览器超时才报错，体验非常糟糕。

6.3 一条完整的上线复盘Checklist

最后整理一份我在多个SQL生成Agent项目里沉淀下来的上线检查清单，仅供参考：

• 数据库账号：只读权限、独立账号、禁用DDL
• Schema索引：元数据同步任务、字段变更检测
• 评测集：50到100条真实问句、三类指标基线
• 安全护栏：强制LIMIT、超时熔断、脱敏规则
• 弹性与高可用：多副本、自动伸缩、降级方案
• 可观测性：日志追踪、延迟指标、成本监控
• 灰度策略：先内部团队、再少量用户、再全量

这份清单每个项目都过一遍，能过滤掉我前面踩过的大半坑。选型不是一次性的，要配合灰度数据持续调整，模型版本更新、业务场景变化都会影响最终效果。

我个人在实际操作中的体会是，SQL生成这个方向，选型大于调参，工程大于模型。模型就像一个聪明但需要管教的实习生，给它明确的表结构、严格的规则、可靠的算力底槽，它能顶半个团队；但你要是只把它丢进生产环境，指望它天生就会，幻觉分分钟教你做人。火山引擎这类算力平台要解决的不是“让模型变得更聪明”，而是“让聪明模型稳定地输出结果”，这件事做好了，Agent的质量才有真正的下限保障。如果你正准备给自己的Agent接SQL生成能力，我建议你先别纠结选哪个模型，按照第2节的思路把自家业务评测集搭起来，跑一轮数据，比听任何人的经验都管用。