商业智能这个领域过去十几年一直是重人力、重实施、重维护的典型代表。一个中等规模的公司想搭一套能用的BI系统通常要经历数据接入、ETL开发、指标口径对齐、看板设计、权限配置这一整套流程周期动辄几个月成本高得让中小企业望而却步。而大语言模型的出现让用自然语言直接问数据这件事从概念验证走向了真正可落地。但问题也随之而来用GPT这类大模型跑端到端BIToken成本高得离谱数据还要往外传很多企业根本不敢用。这篇内容我想聊的就是怎么用小模型把端到端商业智能跑通在效果基本追平大模型的前提下把成本压到原来的五十分之一左右。整套方案围绕LLM、AI智能体、商业智能BI、大模型微调这几个核心点展开适合正在做数据产品、想给现有BI加一层自然语言交互、或者单纯想搞清楚小模型到底能不能扛事的开发和产品同学参考。1. 为什么端到端BI这件事大模型跑不起1.1 端到端BI到底端在哪先把概念说清楚。所谓端到端商业智能指的是用户从提出一个业务问题到拿到可视化答案中间不需要人工介入写SQL、不需要数据分析师手动跑数。整条链路大致是这样的用户用自然语言提问比如上个月华东区哪些品类的复购率掉了超过5个点系统理解意图识别出这属于趋势对比维度筛选阈值告警类问题然后去元数据里找到对应的表、字段、指标定义生成可执行的查询语句跑出结果最后自动选一个合适的图表把结论呈现出来。这条链路里真正难的不是最后画图而是中间那几步理解和映射。自然语言是模糊的而数据库schema是精确的。用户说复购率你的表里可能叫repurchase_rate也可能要从订单表里现算。用户说上个月到底是自然月还是滚动30天不同业务口径完全不一样。这些歧义正是大模型擅长处理的地方也是它成本高的根源。1.2 大模型跑BI的成本账算一遍就心疼我拿一个真实的场景算过账。假设一家公司有200个活跃的BI用户平均每人每天问8个问题一个月按22个工作日算就是200×8×2235200次查询。每次查询如果走GPT-4级别的模型光是把schema、指标定义、历史对话、用户问题这些塞进上下文输入Token轻松就到3000到5000输出加上生成的SQL和解释按800算一次查询大概4000 Token上下。按当时主流大模型的定价输入加输出综合下来一次查询成本在人民币0.3到0.5元之间。35200次乘以0.4元一个月就是一万四千块左右。这还只是一个200人规模的公司如果上千人用成本直接奔着十万去。更别提很多问题其实很简单比如昨天销售额多少这种查询也要烧掉几千Token纯属浪费。除了钱还有两个隐性成本。一是延迟大模型一次推理动辄三五秒用户问个简单问题等半天体验很差。二是数据合规财务、用户、订单这些敏感数据要拼进Prompt发给外部API很多公司的安全团队直接一票否决。这两条加起来就注定了纯大模型方案在企业内部很难大规模铺开。1.3 小模型的机会窗口在哪小模型能翻身靠的是三个变化。第一开源小模型的能力上来了。7B到14B这个量级的模型经过针对性微调后在结构化输出这类任务上表现相当能打因为它们不需要懂天文地理只需要把自然语言稳定地翻译成SQL或者查询DSL。第二任务可以被拆解。端到端BI不是铁板一块它可以拆成意图识别、schema召回、SQL生成、结果解读几个子任务每个子任务都可以用专门的小模型或者规则来处理没必要一个巨无霸模型全包。第三微调成本降下来了。用LoRA这类参数高效微调方法一张消费级显卡就能跑几百到几千条高质量样本就能让模型在特定领域达到可用水平。我实测下来的结论是在垂直BI场景里一个微调过的7B模型配合合理的Agent编排SQL生成的准确率能做到大模型方案的90%到95%而单次推理成本能压到原来的五十分之一甚至更低。这个账值得好好算。2. 把端到端BI拆成智能体能干的活2.1 一个Agent包打天下是行不通的很多人一上来就想搞一个超级BI智能体把所有事都交给一个模型。我试过效果很糟。原因很简单任务太杂模型注意力被稀释。它既要理解业务黑话又要记住几百张表的字段还要保证SQL语法正确最后还得会挑图表。这么多目标塞进一个Prompt小模型直接懵大模型也经常顾此失彼。正确的做法是按职责拆分Agent每个Agent只干一件窄事用最适合它的模型规模。这就像公司分工你不会让一个人同时干销售、财务和法务各司其职效率才高。下面这套拆分是我踩了不少坑之后稳定下来的结构一共四个核心Agent加一个调度层。2.2 意图路由Agent先搞清楚用户到底想问什么第一个Agent负责意图识别和路由。用户输入一句话它要判断这属于哪类查询是简单的指标查询昨天GMV多少还是多维分析按渠道拆分看转化还是趋势对比这个月和上个月比或者是根本不该走BI的闲聊今天天气怎么样。这个任务其实不重用一个1.5B到3B的小模型微调就够甚至规则加小模型混合就能搞定。关键是分类要准因为路由错了后面全错。我的经验是意图类别不要设太多控制在8到12类每类给足样本。类别太多小模型分不清边界准确率断崖式下跌。这里有个细节值得说置信度阈值。小模型给出的分类置信度如果低于某个阈值我一般设0.75不要硬猜直接走兜底流程要么让用户澄清要么升级给大模型处理。这样既省成本又避免答非所问。2.3 Schema召回Agent别把几百张表全塞给模型第二个Agent负责从元数据里召回相关的表和字段。这是整个链路里最容易被忽视、但最影响准确率的一环。很多方案失败就是因为把整个数据库的schema一股脑塞进Prompt几千个字段模型根本抓不住重点还白白烧Token。我的做法是两阶段召回。第一阶段用向量检索把用户问题embedding之后去schema向量库里找最相关的20到30张表。第二阶段用一个小模型做精排从这20多张表里挑出真正需要的3到5张同时把相关的字段、指标定义、同义词映射一起带出来。这里的关键是元数据要养好。表名、字段名要有业务注释指标要有清晰的口径定义还要维护一份业务黑话到字段的同义词表比如成交额对应gmv客单价对应gmv/order_count。这份元数据质量直接决定了召回Agent的上限。我见过太多团队模型调得很辛苦最后发现是元数据一塌糊涂那再怎么调都没用。2.4 SQL生成Agent小模型的主战场第三个Agent是SQL生成这是小模型微调投入产出比最高的地方。因为SQL生成是个高度结构化的任务输入是用户问题召回的表字段指标定义输出是标准SQL格式固定非常适合用监督微调来打磨。我用的基座是7B级别的开源模型训练数据是几千条问题-SQL配对。数据来源有三个历史BI查询日志把用户当时的问题和最终执行的SQL配对、人工构造的覆盖各类查询模式的样本、以及用大模型批量生成再人工校验的合成数据。训练用LoRA一张24G显存的卡跑一两天就能出一版。实测下来在训练集覆盖的查询模式上微调后的7B模型SQL准确率能到92%以上接近大模型水平。但要注意泛化能力是小模型的短板。遇到训练时没见过的复杂嵌套查询它容易翻车。所以我在SQL生成Agent后面加了一个语法校验和自修复环节生成的SQL先做语法解析解析不过就让模型根据报错信息重试一次还不行就降级给大模型兜底。这个兜底比例通常控制在5%以内成本可控。2.5 结果解读Agent把数字翻译成人话第四个Agent负责结果解读和图表推荐。SQL跑出结果后不能直接把一张表格甩给用户得告诉他这个数字意味着什么。比如查询返回复购率环比下降6.2%解读Agent要能说出华东区美妆品类复购率下滑明显建议关注。这个任务对模型要求不高3B级别足够甚至可以用模板加规则来做只在复杂场景才调用模型。图表推荐同理根据结果的数据形态单值、时间序列、多维对比用规则映射到图表类型比让模型猜更稳。2.6 调度层Agent之间的编排逻辑四个Agent不是孤立的需要一个调度层把它们串起来同时管理上下文、处理异常、控制成本。调度层我建议用代码写死流程而不是让模型自己决定调用顺序。原因很直接BI查询的流程是相对固定的用代码编排可控性高、延迟低、调试方便。让模型自由发挥反而容易绕圈子。调度层还要负责缓存。很多查询是重复的比如每天早上大家都问昨日销售额。把问题指纹结果缓存起来命中直接返回能省掉大量推理。我实测缓存命中率能到30%左右这部分成本直接归零。3. 小模型微调的实操细节与数据准备3.1 基座模型怎么选选基座不能只看榜单分数要看你的任务类型和部署条件。BI场景的核心任务是指令跟随结构化输出对模型的推理深度要求中等但对格式稳定性要求极高。我对比过几个主流开源系列最后倾向选中文能力强、指令跟随稳、社区微调工具链成熟的7B到14B模型。具体选型时我会看几个指标一是模型在中文SQL生成类评测上的表现二是它的上下文窗口够不够BI场景经常要带不少schema8K起步16K更稳三是量化后能不能塞进你现有的显卡。如果部署资源紧张4bit量化后的7B模型一张16G卡就能跑延迟也能接受。提示不要盲目追新追大。我见过团队非要用最大的开源模型结果推理慢、显存爆最后上线不了。合适比先进重要。3.2 训练数据从哪来数据是小模型微调的命根子。BI场景的数据我一般从四个渠道凑历史查询日志这是最宝贵的。把用户当时输入的自然语言和系统最终执行的SQL配对就是天然的训练样本。注意要清洗掉错误的、被人工改过的查询。人工构造针对高频查询模式人工写一批标准问答对保证覆盖度。这部分质量最高但费人力一般构造几百到一千条打底。合成数据用大模型基于你的schema批量生成问题-SQL对再人工抽检。这部分能快速扩充量但一定要过滤合成数据里错误率不低。负样本这个很多人忽略。要专门收集模型容易生成错误SQL的案例作为难例加入训练能显著提升鲁棒性。数据量上我的经验是质量远比数量重要。一千条精标数据效果往往好过一万条脏数据。训练集、验证集按8:2分验证集一定要留出模型没见过的查询模式用来测泛化。3.3 LoRA微调的关键参数微调用LoRA是标配省显存、训练快、还能多版本共存。几个关键参数我列一下我的常用配置供参考参数常用取值说明LoRA rank16-32太小欠拟合太大易过拟合BI任务16够用LoRA alpha32一般是rank的2倍学习率1e-4到2e-4太高会崩太低收敛慢训练轮数3-5看验证集loss别死磕批次大小根据显存调配合梯度累积凑等效batch截断长度2048-4096覆盖schema问题SQL的长度训练过程中要盯验证集loss一旦开始上升就是过拟合信号赶紧停。我一般会保存多个checkpoint最后挑验证集表现最好的那版。3.4 评估不能只看准确率评估小模型BI能力光看SQL准确率是不够的。我一般分三层评第一层是语法正确率生成的SQL能不能被解析器接受这个应该接近100%。第二层是执行正确率SQL能不能跑通、返回结果。第三层才是语义正确率结果是不是用户真正想要的。很多方案卡在第二层SQL语法对但字段名写错、表关联错跑出来是错的。评估集要覆盖各类查询单表聚合、多表关联、时间窗口、同环比、TopN、阈值筛选等。每类都要有足够样本才能看出模型在哪类上弱。发现弱项就针对性补数据再训。4. 成本到底怎么降下来的4.1 五十分之一的账是怎么算的回到最开始那个成本问题。用大模型方案一次查询约4000 Token成本0.4元。换成小模型方案后成本结构完全变了。首先推理成本。7B模型4bit量化后部署在自己的机器上一次推理的电费加折旧摊到每次查询大概几分钱。就算按云上GPU实例算一张卡一小时几块钱一小时能处理几百次查询单次成本也就一两分钱。其次Token消耗大幅下降。因为schema召回Agent只带相关的几张表Prompt从几千Token压到几百Token。而且大部分简单查询走的是小模型甚至规则根本不碰大模型。最后缓存和兜底控制。30%的查询命中缓存零成本。只有5%的复杂查询降级给大模型这部分成本按大模型算但占比很小。综合下来单次查询成本从0.4元降到不到0.01元降幅确实在五十倍这个量级。当然这是理想情况实际部署有GPU闲置、运维等成本但数量级上的优势是实打实的。4.2 效果追平大模型靠的是什么成本降了效果不能垮。小模型方案效果能追平靠的是任务拆解领域微调工程兜底三件套。任务拆解让每个模型只干窄事难度降低领域微调让模型吃透了你的schema和业务黑话工程兜底语法校验、自修复、大模型降级把长尾错误接住。三者叠加最终端到端的用户满意度能做到大模型方案的九成以上。剩下那一成差距主要体现在极复杂的多轮追问和跨域分析上这类查询占比很低而且可以引导用户走人工或大模型通道。4.3 延迟和体验的改善成本之外小模型还有个隐性优势快。本地部署的小模型一次推理几百毫秒到一秒比大模型API动辄三五秒快得多。BI这种交互式场景响应速度直接影响用户愿不愿意用。我实测下来端到端响应从大模型方案的4秒左右压到1.5秒以内用户体感提升非常明显。再加上缓存高频查询基本秒回。这种体验上的改善往往比省下的钱更能推动用户真正把系统用起来。5. 上线后踩过的坑和应对5.1 元数据漂移导致召回失效系统上线跑了一阵业务改了表结构加了个字段、改了个指标口径结果召回Agent开始频繁找错表。这是元数据漂移问题。模型是按旧schema训的schema一变它就不认识了。应对办法是把元数据和模型解耦。schema召回走的是向量库和同义词表这些是配置不是模型权重。schema变了更新向量库和配置就行不用重训模型。同时加一个schema变更监控一旦检测到表结构变化自动触发向量库重建和回归测试。5.2 用户问法千奇百怪模型接不住真实用户的问法比训练数据野多了。有人问帮我看看那个啥卖得咋样有人一句话里塞三个条件还有人用内部黑话。小模型遇到没见过的表达容易懵。我的应对是建一个未识别问题收集池。凡是置信度低、走了兜底、或者用户点了答非所问的查询全部记录下来。每周review一次把高频的未识别问法补进训练数据或同义词表迭代一版模型。这样系统会越用越聪明而不是上线即巅峰然后慢慢烂掉。5.3 兜底大模型的调用要设上限降级给大模型是保底手段但如果不加控制可能被滥用。我见过因为小模型某类问题总失败导致大量查询都走大模型成本又回去了。所以要给兜底设配额和熔断。比如每天大模型调用不超过总查询的8%超了就只走小模型加提示该问题较复杂建议联系分析师。同时监控兜底率如果某类问题兜底率异常高说明小模型在这块有系统性缺陷要专项补数据。5.4 权限和数据安全不能忘BI系统涉及敏感数据权限必须做扎实。用户能查什么数据取决于他的角色。这个逻辑要在SQL生成之后、执行之前做校验确保生成的查询不会越权访问。小模型本身不负责权限权限是工程层的事但一定要在链路里卡死。另外本地部署小模型的一个大好处就是数据不出内网。用户的原始问题、schema、查询结果全程在企业自己的机器上流转不经过任何外部API。这一点对很多有合规要求的公司来说是决定性的。6. 几个能直接抄的落地建议6.1 先从单场景切入别一上来就全量我强烈建议不要一上来就做全公司全数据域的BI智能体。先选一个数据域清晰、查询模式相对固定的场景比如销售日报查询或者库存周转分析把这条链路跑通、跑稳验证效果和成本再逐步扩展。单场景切入的好处是数据好准备、评估好做、问题好定位。全量铺开问题会多到让你怀疑人生。6.2 把评估做成常态化流水线模型不是训完就完事。要建一套自动化评估流水线每次模型更新、schema变更、Prompt调整都自动跑一遍评估集看准确率有没有回退。评估集要持续扩充把线上发现的bad case不断加进去。没有评估流水线你根本不知道系统是在变好还是变坏。6.3 人机协同的兜底设计再好的系统也有答不上来的时候。与其硬答错不如优雅地承认不知道并给出下一步建议。比如这个问题我暂时无法准确回答你可以尝试换个问法或者点击这里转人工分析师。这种设计能大幅提升用户信任度。用户不怕你答不上来怕的是你一本正经地胡说八道。6.4 持续迭代的节奏我的迭代节奏是两周一个小版本。每两周收集一轮bad case补一批数据微调一版模型跑一遍评估灰度上线。这个节奏既能快速响应问题又不会因为频繁变更导致系统不稳定。模型迭代不是一锤子买卖是个长期工程节奏感很重要。最后分享一个我自己的体会小模型做端到端BI技术上的难点其实没有想象中那么大真正决定成败的是数据质量和工程细节。模型选型、微调参数这些网上教程一大堆照着做八九不离十。但元数据养得好不好、bad case收得勤不勤、兜底设计得合不合理这些才是拉开差距的地方。我见过太多团队把精力全砸在调模型上结果元数据一塌糊涂最后效果怎么都上不去。把功夫花在数据和工程上小模型给你的回报会超出预期。