企业官网建设流程全解析

1. 从兴奋到踩坑：NL2SQL在企业落地的真实体验

过去一年多，我前前后后参与了五六个ChatBI相关的项目，从早期的技术验证到后面的正式上线，几乎每个项目都踩过同一个坑：Demo阶段效果惊艳，一接真实业务库就原形毕露。最典型的一次，老板拿着手机录屏问我，为什么系统能把“上个月华东区退货率最高的三个品类”答得清清楚楚，到了生产环境问“最近退货咋样”就答非所问。

原因并不复杂。ChatBI的核心链路大家都很熟悉，用户输入自然语言，系统把它翻译成SQL，再到数仓或业务库里执行，最后把结果渲染成图表。这条链路里最关键的环节就是NL2SQL，也就是让大模型理解用户的问法，并生成能正确执行的SQL。但NL2SQL在跑通阶段表现优异，一旦面对企业真实的表结构、指标口径和权限体系，准确率通常只有50%到60%——这个数字不是我瞎编的，是我们自己测试集上一轮轮跑出来的真实结果。

我见过不少团队在这个阶段就放弃了，转头说“大模型做BI还不成熟”。其实问题不出在大模型上，而是出在“让大模型直接写SQL”这个思路上。NL2SQL本质上是个开放式的生成任务，模型要同时搞定语义理解、Schema理解、业务知识对齐、SQL语法生成四件事，任何一环出问题结果就崩。而企业数据环境的复杂程度，远超模型在训练阶段见过的那些公开数据集。

从准确率50%到90%，不是靠调prompt、换模型就能实现的，而是要把大量隐性知识从“让模型猜”变成“系统提供”。这篇文章我会把当前实践中真正跑通的三条技术路线拆开讲清楚，再用四个不同行业的落地案例说明，不同场景下应该怎么选、怎么做才能把准确率稳定拉上去。如果你正在做ChatBI相关的工作，或者正准备立项，这篇内容应该能帮你少走不少弯路。

1.1 Demo很惊艳，生产环境很骨感

先说说为什么NL2SQL在真实环境里这么容易翻车。第一个坑是Schema复杂度过高。一个中型企业的数仓动辄几百张表，每张表几十个字段，如果把这些全部塞给模型，模型根本没有能力在这么庞大的搜索空间里准确锁定目标表和字段。我见过一个零售客户，光销售域的表就有40多张，其中有“订单表”“订单明细表”“订单快照表”“订单退款表”，字段名更是五花八门。用户问“销售额”，模型可能去查订单表，也可能去查明细表，两张表算出来的数字天然就不一样。

第二个坑是业务口径问题。同一个指标，在不同部门、不同报表里的定义可能完全不同。比如“毛利率”，有的口径是（营业收入-营业成本）/营业收入，有的口径要扣除税金及附加，还有的要按SKU加权平均算。这些内容模型并不知道，如果不在系统层面约束，模型生成的SQL就算语法完全正确，算出来的数字也跟业务对不上。这种“SQL对但结果错”的情况，比执行报错更难排查。

第三个坑是权限管控。不是所有用户都能查全库数据，销售只能看自己区域的数据，财务能看到全公司，但模型在生成SQL时根本不知道怎么加权限条件。早期项目里我们直接在模型生成的SQL后面拼接where条件，结果模型生成了子查询或者group by，拼接后语法直接报错，折腾了很久才找到稳妥方案。

这三个问题叠加在一起，准确率50%已经算不错了。我当时就跟团队说，如果我们继续走“让大模型写SQL”这条路，要解决的问题清单会越拉越长，正确率提升却越来越慢，必须换个思路。

1.2 准确率是怎么定义的：先统一评估口径

聊提升之前，先把“准确率”这个指标定义清楚。很多团队在汇报时说准确率90%，但评估集里全是类似“一月份销量”这种简单问题，那这个数字没有参考价值。我们内部定义了一套相对严格的标准：一个问题跑通一次查询，结果要同时满足三个条件才算对——SQL能正确执行不报错、查询出的指标口径和业务定义一致、用户问的维度和筛选条件完整生效。

按这个标准做评估，早期的增强型NL2SQL方案在我们的测试集上（约200条覆盖了查询、对比、趋势、占比、排名等常见问法）只有54%的准确率。后来换到语义模型路线，同样一套测试集跑到了91%。这个提升不是某个环节的优化，而是整个架构设计思路的转变。

2. 技术路线一：增强型NL2SQL，先别急着换方案

先说第一种路线，也是ChatBI落地最普遍的起点——增强型NL2SQL。所谓增强，就是在“自然语言到SQL”这条主链路旁边，增加一系列辅助模块来提升生成质量，而不是让模型裸奔去写SQL。做得好，准确率能从50%提到70%上下；做得极致，有些场景能逼近80%。但它始终有个天花板，后面我会讲原因。

我一向建议团队先从这条路线起步，因为改动最小，可以复用现有的大模型能力，一两个星期就能出一个可演示的版本。而且它能帮你积累一批真实用户问题样本，这些样本是后续做语义模型、做评估集都离不开的资产。

2.1 核心玩法：给模型“瘦身”而不是“硬扛”

增强型NL2SQL的第一个关键是Schema精简。前面提到几百张表直接塞给模型是不现实的，我们的做法是建一个语义层配置，把用户最常查询的几十张表、每张表的核心字段、字段的业务含义、表之间的关联关系整理出来，形成一份精简后的“模型Schema”。这些信息存成结构化配置，每次请求时只把这份精简Schema注入prompt，而不是把整个库的元数据都丢给模型。

比如一个销售分析场景，精简后可能只需要订单表、客户表、商品表、区域表四张表。每张表只保留核心字段，像订单表就放订单ID、下单时间、订单金额、客户ID、商品ID、区域ID、订单状态。字段注释要写得足够清楚，比如“订单金额”后面加一句“优惠后实付金额，不含退款订单”，这样模型理解起来容易很多。

第二个关键是同义词和枚举值映射。业务人员说话不会用字段名，他们说的是“华东”“江浙沪”“老板”“客户”，这些词本身没有出现在字段里。我们建了一张词表维护业务词和字段、枚举值的对应关系，比如“华东”映射到region_code in ('SH','JS','ZJ')，“回头客”映射到is_return=1。这套映射表一开始人工维护，后续从用户问句里持续沉淀新词，两三个月就能覆盖大部分高频说法。

第三个关键是Few-shot示例。通用模型对业务SQL的写法不一定熟练，我们就在prompt里放几个“问题-SQL”的标准示例，尤其是带复杂计算的SQL写法。比如“上月各区域销售额对比”这个高频问题，我们给出标准SQL写法，模型在生成类似问题时就会照着这个格式走。示例不用多，五到十条足够，多了反而干扰模型判断。

2.2 自纠正机制：让模型自己改错

即使做了上面这些优化，模型也一定会写出有问题的SQL。我们的做法是加一道执行校验环节：生成的SQL先做语法检查，能执行就执行，执行报错就把错误信息回传给模型，让它根据报错信息修改SQL，最多重试两次。实测下来，这一招能把“执行报错”类问题的比例降低一半以上。

再进阶一点，可以加“结果校验”。比如SQL执行成功但返回空结果，可以拆成两种情况：一种是用户问的就是一个本身没有数据的维度组合，另一种是SQL写错了导致查不到。系统可以尝试放宽时间范围或者去掉部分过滤条件再查一次，如果结果不为空，说明原SQL的过滤逻辑有问题，就触发重写。这个机制虽然不能100%判断准确，但确实能挽回一部分看起来“答非所问”的case。

增强型NL2SQL的极限在哪里？我自己的体感是，对于结构相对规整、指标口径不复杂的分析场景，它能到75%到80%。但一旦遇到指标口径多元、需要跨多张事实表做统计的复杂场景，它就非常吃力了——因为业务口径这件事，本质上不该由模型来理解，而是应该沉淀在系统里。

2.3 增强型NL2SQL的适用边界

我给增强型NL2SQL画了一条边界：适合表结构清晰、指标口径相对统一、查询模式比较固定的场景。比如运营后台的数据看板、内部管理报表的问答化改造、初创公司的轻量级数据分析，这些场景里用户问的问题高度重复，把高频问题对应的SQL沉淀成few-shot示例之后，准确率能维持在一个可用的水平。

不适合的场景也很明确：指标口径复杂、部门间定义不一致、查询链路长、数据权限要求严格的企业级数据平台。在这些场景里硬刚NL2SQL，团队会陷入无休止的“补prompt、加映射、调示例”循环中，每解决一个问题又会冒出两个新问题，最终效果还是不达预期。遇到这种情况，我建议果断切到第二条路线。

3. 技术路线二：语义模型+指标平台，把口径变成系统的一部分

第二条路线是我的主推路线，也是让我们把准确率稳定拉到90%的关键。核心思路一句话：别让模型写SQL，让模型做选择题。

具体来说，在数据库和模型之间加一层“语义模型”，也叫指标平台。这层把所有业务指标、维度、口径、权限规则用结构化方式定义好，模型的任务不是生成SQL，而是把用户的自然语言映射到语义模型上的指标、维度和过滤条件，再交给一个确定性的查询引擎去生成并执行查询。SQL的生成从“自由发挥”变成了“按模板拼装”，准确率自然就上来了。

3.1 核心思路：让模型做选择题，不做填空题

打个比方，NL2SQL的做法像是让一个新人直接去写法律文书，他得懂法律、懂格式、懂案例，出错概率很高。语义模型的做法是先给他一张满是选项的表单，他只需要把用户的需求对应到表单选项上，后面的文书由系统自动拼装。后者对模型能力的要求低得多，但准确率高得多。

在我们的实现里，语义模型定义了三个核心要素：指标、维度、条件。指标就是“销售额”“订单量”“毛利率”这些可计算的度量值，每个指标绑定一个SQL表达式，比如“销售额”绑定sum(pay_amount)，“订单量”绑定count(distinct order_id)。维度是“区域”“品类”“门店”“时间”这些分组字段。条件是“区域=华东”“时间=上个月”“金额大于1000”这类过滤逻辑。

模型要做的事情，是从用户问句里识别出意图——是查数值、看趋势、做对比还是查排名，然后从预定义的指标和维度列表里挑出对应的项，再抽出筛选条件里的枚举值和时间范围。以“上个月华东区退货率最高的三个品类”为例，模型只需要输出：指标=退货率，维度=品类，筛选条件=时间（上个月）、区域（华东），排序=降序取前3名。后面所有的SQL拼装、表关联、聚合逻辑都由系统模板完成。

3.2 语义层的落地细节与建模方法

这个路线落地最重要的工作，是把业务口径梳理清楚并固化到系统里。我们每接一个新客户，通常要花一到两周和业务方一起过指标口径，把每个指标的公式、取数来源、特殊规则确认清楚，然后录入指标平台。比如“销售额”到底含不含退款，不同渠道的订单怎么归并，这些都要在指标定义里写明白。

指标定义是结构化的，比如退货率我们定义成退单金额/实付金额，并且限定了只统计已发货订单。系统生成SQL时，所有指标都按照这个定义展开，不存在理解偏差。即使是同一个指标在不同场景下有两种口径，也可以定义成两个不同的指标，比如“销售额（含退款）”和“销售额（净额）”，让系统根据用户问法自动匹配。

维度模型同样重要。我们维护了维度层级关系，比如时间维度支持年、季、月、周、日粒度，用户可以问“每周的趋势”也可以问“1月份的销量”，系统自动转换。区域维度支持大区、省、市三级下钻，用户问“华东”时，系统能自动展开成华东包含的省份集合。

权限规则也在这一层统一管控。用户请求进来后，系统先解析出用户所属的数据权限范围，再作为一个强制过滤条件注入到查询模板里，无论模型怎么理解，最终生成的SQL都自动带有权限约束。这一块在合规性要求高的行业特别重要。

3.3 基于语义模型的查询DSL实战示例

为了让概念落地得具体一点，我贴一份我们项目里实际使用的查询DSL结构。模型输出的是JSON格式的查询计划，而不是SQL：

{ "intent": "ranking", "query": "上个月华东区退货率最高的三个品类", "metrics": [{"name": "return_rate", "alias": "退货率"}], "dimensions": [{"name": "category", "alias": "品类"}], "filters": [ {"field": "region", "operator": "in", "values": ["华东"]}, {"field": "month", "operator": "last_month"} ], "order_by": {"metric": "return_rate", "direction": "desc"}, "limit": 3 }

这份JSON看起来简单，但价值在于它完全避开了SQL的复杂性。模型只需要输出语义层面的内容，比如“华东”这个值我们不会直接拿去数据库匹配，而是通过映射层把“华东”转成大区编码对应的省份列表，再把省份列表注入到最终SQL里。这样即使模型对底层表结构一无所知，也不影响查询结果的正确性。

执行引擎拿到DSL后，根据指标和维度的定义动态生成SQL。因为所有指标、维度都预先绑定了字段和表达式，SQL生成过程是确定性的，不会像大模型自由生成那样出现“左连接还是右连接”“按什么粒度聚合”这类随机性错误。这也是准确率能到90%的根本原因。

当然，这条路线也有代价。前期梳理指标口径、建立语义模型需要投入不少时间，通常需要业务分析师的深度参与。如果企业连基本的指标体系都还没建立，不建议直接上这条路线，应该先用第一条路线跑起来，边用边梳理口径。

4. 技术路线三：Text2API，让模型只做意图理解

第三条路线跟前两条有本质区别。前两条不管怎么做，最终都是要查数据库的，只是SQL是由模型直接生成还是由模板拼装。Text2API则换了个方向：不直接查库，而是把数据分析能力封装成一组标准API，模型只负责理解用户意图、抽取参数，然后调用对应API，由API后端的确定性逻辑完成取数和计算。

这条路线在特定场景下的优势极其明显，尤其是数据源非常分散、权限极其复杂、或者底层存储不是传统关系型数据库的时候。我接过一个金融客户，数据分散在多个业务系统里，有些数据甚至存放在第三方平台上，根本没法用一条SQL搞定。这时候Text2API几乎是唯一可行的路线。

4.1 核心做法：把高频分析场景抽象成接口

Text2API的第一步和语义模型类似，但要抽象的对象不是指标和维度，而是“分析能力”。我们和业务方坐在一起，把高频问题分成几大类：单指标查询、趋势分析、品类对比、排名、同环比、日报周报等。每一类都设计成独立的API，输入输出参数明确定义。

举个例子，趋势分析API的入参可能包括：指标编码、时间范围、时间粒度（日/周/月）、维度筛选条件。排名的API入参是：指标编码、排序方式、TopN、筛选条件。模型的职责变成了从用户问句里抽取这些参数，并匹配到对应的API上。

一旦模型的输出从SQL变成了结构化的API调用参数，“生成对错”的问题就大大减少了。SQL是开放的、组合方式无穷无尽的，而API是封闭的、参数是有限的，模型只需要做有限的选择和抽取，错误率自然大幅下降。我们在这个客户上的准确率稳定在88%以上。

4.2 Text2API的权限和审计优势

Text2API对权限控制和审计特别友好。因为数据访问被封装在API里，权限校验在API网关层统一处理，天然就能实现“用户只能查询自己有权限的数据”。接口层还有一层好处是审计日志非常干净，谁的什么请求返回了什么数据，全部可以通过网关日志追踪到，这在金融和政务场景是刚需。

这种方式还顺带解决了一个NL2SQL路线的隐性问题——行级权限注入。直接让模型生成SQL时，哪怕我们在prompt里写清楚权限条件，模型也可能会遗漏或者写错位置。而在Text2API模式下，权限校验在API内部完成，模型根本没有权限去影响查询的数据范围。

4.3 Text2API的短板和适用判断

Text2API也有明显短板，最突出的是灵活度不足。语义模型可以覆盖所有指标和维度的自由组合，而API必须预先定义好能力的边界，遇到没有设计过的分析场景，系统就会“听不懂”。解决方式是搭一个兜底策略：当模型识别不了用户意图或者匹配不到合适API时，自动转人工或者提示用户换个说法，而不是硬着头皮返回一个错误答案。

所以在项目选型时，我会优先做场景评估：如果分析场景相对固定，用户问的问题八九不离十，Text2API是非常高效的选择；如果期望用户自由探索数据、随意组合分析维度，那它很快就会显得思维僵化，语义模型会是上限更高的选择。还有一些项目会把两条路线混合使用，常规高频问题走API，长尾探索性问题走语义模型，互补短板。

5. 四个企业案例拆解：从选型到落地的完整实录

技术路线说完了，聊聊具体的落地案例。为了隐私考虑，客户名称做了脱敏，但项目里的细节、数据和技术方案都是真实的。这四个案例分别对应零售、金融、电商、制造四个行业，选型逻辑和落地路径各有代表性，希望能给你一些参考。

5.1 零售连锁：从NL2SQL陡坡到语义模型的转折

这个客户是国内一家门店数超过3000家的连锁零售企业，原有BI报表体系很成熟，但业务人员查数据要提工单排期，严重拖慢经营决策。老板拍板做ChatBI，目标是让区域经理用自然语言查销售、库存、坪效、人效等核心数据。

项目一开始，我们的技术团队直接用了增强型NL2SQL方案，模型选了当时效果最好的开源模型，做了Schema精简和同义词映射，信心满满地上了测试集。结果准确率只有52%。排查发现，最大的问题出在指标口径上——光“销售额”就有含税、不含税、含退款、净回款四种口径，模型根本无法判断该用哪个；而且订单表拆得很散，一张主表加七张扩展表，模型自己JOIN出来的SQL经常漏掉扩展表。

后来我们花了三周时间，和业务分析师一起把所有核心指标的口径梳理清楚，建了语义模型和指标平台。模型换成任务更简单的意图识别+指标匹配，底层查询全部由模板引擎生成。还是同一套测试集，准确率直接跳到了89.6%，又经过两轮迭代和扩充，稳定在了92%左右。这个案例让我坚定了看法：口径问题靠prompt是永远解决不了的，必须靠系统约束。

5.2 金融服务：Text2API解决权限和数据分散难题

这是一家做供应链金融的公司，数据分散在核心业务系统、风控系统、第三方征信平台好几个地方，字段命名严重不统一，而且数据权限极其严格，不同职级的人能看的数据范围差异很大。一开始我们评估过NL2SQL方案，光统一数据这一关就过不去，于是转向Text2API。

我们跟业务方梳理出了12个高频分析场景，封装成9个标准API，比如客户风险评级分布、放款金额趋势、逾期率统计、区域不良排行等。模型接收到用户问题后，先识别出对应的场景，再抽取业务参数（比如时间、客户分类、金额区间），生成API调用。准确率第一次跑就到了85%，补了一些边缘case之后到了89%。

这个项目的关键收获是Text2API和权限系统的天然契合。所有的数据访问都在API层做鉴权，用户的职级、部门、可查客户范围全部在网关层自动过滤。合规团队对这套方案非常满意，因为每一次数据访问都有完整的审计日志。对于数据敏感、监管严格的行业，这几乎是最稳妥的ChatBI打开方式。

5.3 电商广告：混合路线效果互补

这个客户是做电商代运营的，他们的场景比较特殊，既要支撑内部运营团队做日常数据分析，又要面向品牌客户提供数据汇报。内部运营问的问题五花八门，今天问“某个SKU在各渠道的转化率”，明天问“大促期间的流量结构变化”，适合用语义模型；而对外的品牌汇报问题相对固定，就那些周报月报的固定模板，适API封装。

我们最终采用了混合架构：核心分析走语义模型，用户自由提问；高频汇报模板走接口，保证输出格式稳定统一。两个入口共用一套用户权限体系，数据结果都落到同一个查询日志里做后续分析。这套架构上线后，内部问题的准确率在90%左右，对外汇报模板的准确率接近100%，关键是运营团队终于不用每天手动拉数贴PPT了。

5.4 制造业：轻量起步，增强NL2SQL快速见效

这个客户是一家汽车零部件制造企业，想让车间主管和计划员用自然语言查生产进度、设备OEE、不良率等指标。他们原有的数字化基础比较薄弱，数据分析师只有一个人，建模和运维能力有限。考虑到投入产出比，我们没有强行上语义模型，而是先走增强型NL2SQL路线。

因为生产场景的表结构相对规整，指标口径也相对统一，增强型NL2SQL的适配效果出乎意料地好。我们做了字段注释标准化，整理了十几个高频问题作为few-shot示例，又建了同义词表（比如“开机率”对应“设备利用率”），首轮准确率就到了76%。后续把常见问题和修正后的SQL沉淀成知识库，引入检索增强生成，准确率提升到了82%。

这个项目让我认识到一个道理：技术路线不是越先进越好，而是要匹配企业的实际能力和场景复杂度。制造业这类指标稳定、表结构简单的场景，花大代价建设语义模型反而有些浪费，不如轻量方案先跑起来，看到真实收益再逐步演进。

6. 常见问题与排查技巧实录

最后这一部分，我把做ChatBI项目以来经常遇到的问题和排查思路整理成一份速查表，这些问题不分技术路线，在实战中出现的频率极高，希望能帮你在项目里少踩几个坑。

6.1 多轮对话的上下文管理

用户会连续问“上个月华东区销量多少”“那华南呢”“跟去年同期比呢”，如果系统不维护上下文，第二问和第三问就会丢失主语和指标。我们的方案是把语义模型解析后的结构化查询条件作为上下文传给下一轮，而不是传原始的对话文本或SQL。这样做的好处是，上下文是精准的指标、维度、过滤条件，即使模型在下一轮生成时“忘了”，系统也能自动继承上一轮的约束。

容易出的问题有两个：一是“那华南呢”这类问题需要替换部分筛选条件而不是追加，如果一律追加，就会得到“华东且华南”这种永远查不到数据的组合；二是用户主动切换话题后，旧上下文应该被清空。我们的处理方式是给上下文加一个置信度分数，模型判断出新意图和当前上下文不一致时主动重置，实际效果还不错。

6.2 同义词和业务术语的持续沉淀

同义词问题第一周就能暴露出来，每个行业的行话都不一样。零售行业说“动销率”，制造业说“完工率”，金融行业说“不良率”，用户默认系统应该能听懂，但模型在通用语料里根本没有这些概念的精确定义。

我们的答案是建一个业务词表并持续迭代。具体做法是每次用户问完，如果结果不理想，就把用户问句里未被识别的词标记出来，由数据分析师判断这个词对应到哪个字段或枚举值，写进词表。测试过三四个月后，词表的覆盖率能把“模型理解不了”的case比例降到5%以下。词表本身是带优先级的，比如“华东”在区域词表里命中后，就不会再被尝试映射到其他字段。

6.3 评估集的建设是长期投资

很多团队做ChatBI项目，评估集就是用几十个常见问题跑一遍，看到效果还行就上线。但真正的瓶颈往往在后期，每次优化一个模块，很难判断到底是变好了还是变差了，因为没有标准答案可用。我们建议从项目第一天就建设评估集，把每个问题的“正确答案”定义清楚。

评估集不只是问题和SQL，建议包含以下字段：问题描述、期待返回的指标、维度、筛选条件、排序方式、期望SQL或者DSL、备注（比如口径说明）。每次系统更新后，用同一套评估集跑回归测试，准确率升降一目了然。我们的评估集目前有500多条用例，覆盖了查询、对比、趋势、占比、排名、同环比、异常检测七大类场景，每次迭代大概花两个小时跑完，收益非常大。

6.4 性能与缓存：别让体验毁在最后一步

ChatBI不仅要答得对，还要答得快。大模型推理本身就有几百毫秒到一两秒的延迟，加上查询执行时间，用户等超过五秒就会开始烦躁。我们的优化方案有两层：一是对高频问题做结果缓存，相同问法在数据未更新时直接返回上一次的结果，秒开；二是对趋势、排名这类固定模式查询，把SQL模板预编译好，减少执行计划的生成时间。

缓存方案要注意数据时效性，我们给缓存设置了五分钟到一小时的过期时间，并支持在数据更新任务完成后主动清理相关缓存。还有一个细节是用户提问相似但不完全相同时，可以利用向量检索找出“历史相似问题”，如果相似度超过阈值就复用之前的解析结果，只更新时间等参数，这个技巧能把系统响应时间降低50%左右。

6.5 用户反馈闭环：准确率持续提升的发动机

不要只依赖评估集，真实用户反馈才是提升准确率最宝贵的素材。我们在系统里做了点赞和点踩按钮，用户点踩时自动记录当时的解析结果和用户的原始意图。每周我们团队会花半天时间review这些case，把模型理解错误的、生成不准确的、口径不匹配的分门别类，优先处理出现频率最高的那批问题。

做过几个项目之后，我发现一个规律：准确率提升最快的时间段不是开发期，而是上线后头三个月，因为那个阶段的真实用户反馈量最大，质量也最高。如果预算允许，专门安排一名数据分析师负责反馈case的标注和优化，投入产出比非常可观。

回到开头说的准确率问题，我个人的体会是：ChatBI能让企业问答式数据分析真正落地，但前提是别把宝全押在NL2SQL上。模型理解自然语言的能力很重要，但真正决定系统上限的，是你把多少业务知识沉淀到了系统里。语义模型和API封装本质上都是在做同一件事——把开放的、不确定的问题，转化为封闭的、确定的匹配问题。模型负责它擅长的事情（理解语义），系统负责它擅长的事情（保证正确），各司其职，准确率自然就上去了。

最后再分享一个实用的小技巧：如果你的项目正处于选型阶段，别急着比模型参数大小，先花两三天时间把目标场景里的100条真实用户问题收集起来，手工标注答案，再分别用不同方案跑一遍。这100条问题的通过率，基本就能预测正式上线后的表现。这套预评估方法我用了很多次，每次都准，省下了不少试错成本。