最近半年朋友圈几乎被各种模型发布的新闻刷屏。今天这家说推理能力又上了一个台阶明天那家宣布新模型免费开放参数量、上下文长度、推理成本一个比一个卷。表面上看模型这么多、这么强做应用的人应该省心了接个API就能跑。但真的做过交付的人都知道事情恰恰相反模型越丰富选择越困难系统越复杂结果越不稳定。而那些夹在“底层模型”和“上层业务”之间看似不起眼的中间环节反而成了整个链路里最值钱的部分。这篇东西我围绕“模型暴涨的半年中间层为什么反而更值钱了”来聊聊背后的逻辑、涉及的工程细节以及我实际搭过的一些经验。适合正在做AI应用落地的人看不管是开发者、技术负责人还是搞不清“为什么模型挺强但自家产品就是不好用”的产品经理都能从这里找到一些答案。1. 模型暴涨带来的三个没明说的变化1.1 选模型这件事比模型本身更耗人这半年模型数量膨胀到什么程度闭源的不说光开源的就有好几个阵营各家还在持续发新版本。看起来选择多了可落到一个真实项目里第一步就卡住了到底用哪个我接过一个小型客服问答项目需求是让用户直接问产品手册里的内容。团队一开始想用最强的旗舰模型觉得模型越强效果越好。真动手才发现问题不在“强不强”而在“适不适合”。有的模型中文产品名识别好有的模型对长文档的理解更好有的上下文长度够但输出不稳定有的模型便宜但工具调用能力一般。我们光是在不同模型之间做对比测试就花了一个多星期写了十几条典型问题逐条跑人工打分又做了成本估算才定下来。这个投入算过才知道有多贵。真要给“中间层”定义我觉得从选模型那一刻就已经开始了评测集怎么搭、评测指标怎么定、结果怎么对比全是额外工作量。模型越丰富这个决策链条就越长人力和时间成本直线上升。还有一点容易忽略模型换起来很贵。你以为先用A模型跑着后面随便换B模型天真。提示词要调返回格式可能要改工具调用的参数也可能不兼容甚至单纯因为某个模型的中文习惯不同整个评测结果就变了。所以模型选型这一步做扎实了能省后面一大笔学费而做扎实所需的功夫全落在中间层。1.2 模型能力同质化应用层开始拼“边界”第二个变化更微妙。这半年发布的新模型虽然宣传词各不相同但实际能力越来越像。榜单上的分数差距落到真实用户手里可能变成“差不多”。模型本身已经很难构成产品的长期壁垒。当底层模型趋于同质用户能感知到的差异就转移到别处回答是不是够快、是不是稳定、会不会突然抽风、每月账单是不是超预算、数据是不是安全可控。这些因素不取决于你用哪个模型而取决于在模型外面做了什么。我见过一个团队做智能写作助手一开始主攻模型选型恨不得把每个新模型都试一遍。后来他们发现用户流失不是因为回答质量差而是因为偶尔超长等待或者同一个问题两次回答风格差异太大。他们转而把精力放在中间层给请求设超时自动重试、给回答风格做约束模板、给并发做排队和限流。改完之后用户满意度比换更强模型明显提升。这就是我想说的核心模型暴涨之后模型不再值钱值钱的是让模型“可靠地为你所用”的那套工程。谁能在模型外面把边界条件管好谁就能做出体验稳定、成本可控的产品。1.3 模型降价反而是长期趋势价值必然迁移这半年还有一个明显的趋势推理成本在往下走。新模型一个比一个便宜有些甚至免费开放。这看起来对开发者是好事但背后藏着一个判断——如果模型本身越来越便宜那整个行业的利润池必然会向其他地方转移。往哪里转移向那些能解决实际问题、能降低集成成本、能提高系统稳定性的环节转移。换句话说模型在最底层价格被卷到地板而在它上面谁能把“数据”“上下文”“评估”“监控”“编排”这些环节做好谁就能创造独属于自己产品的价值。这就解释了为什么“中间层反而更值钱了”模型是公共基础设施中间层才是每个团队自己的护城河。2. 中间层到底包了哪些活儿中间层这个词听起来虚其实拆开就是几个具体领域。我按实际项目中接触最多的部分整理成四层每一层都有清晰的职责和常用工具。2.1 数据与上下文层决定模型“看到什么”只要是做知识库问答、RAG、AI客服、文档处理你一定会碰到这一层。它承担的活儿包括把杂乱无章的文档接进来做格式解析把长文档切分成适合检索的片段把切好的片段向量化存进向量库用户提问时去库里找出最相关的几个片段再拼进给模型的提示词里。这一层之所以重要是因为模型的“聪明”是建立在它看到的信息之上的。我在项目里见过太多这样的事模型本身很强但检索回来的内容不对回答自然就错。同一个模型换个分块策略或加个重排环节效果可能直接两个档次。这里有几个关键点值得多说。分块策略不好拍脑袋定。对结构化文档比如产品规格或规章制度按章节切块就很好。对连续性的技术文档按固定窗口分开又重叠更稳比如每块800到1000个中文字符重叠100到200字。块太大检索回来太粗糙块太小语义又不完整。这些参数得拿自己的测试集去试。向量库的选择也别跟风。项目初期数据量不大时简单方案就够用不用一上来就上分布式向量集群。关键是别忘了传统全文检索。很多场景下关键词匹配的效果并不差尤其用户会直接问“型号”“参数”“价格”这类明确词时全文检索加向量混合召回才是性价比更高的方案。我个人的经验是先拿30到50个真实用户问题当测试集用检索召回率衡量效果调分块大小、召回数量、重排方式而不是靠“感觉差不多”。只有让数据层稳定上层才有得玩。2.2 模型路由与编排层决定“用哪个模型干活”这一层很多人没有意识到但它恰恰是模型暴涨后最值得投入的方向。简单说就是让不同的任务走不同的模型而不是所有请求统统发给你那个最强也最贵的模型。我导过一个图做一个内容总结工具用户的输入长度差异非常大。短的几十字长的上万字。如果全部塞给旗舰模型账单会很感人如果全让小模型干复杂内容又总结不到位。后来我们搭了一个简单的路由策略任务分类模块先判断请求复杂度简单请求走一个便宜的小模型速度快成本低中等请求走标准模型兼顾效果和价格复杂请求或者需要多次推理的才走最强的旗舰模型。这个路由调好之后整体成本降了差不多一半用户体验还没下降。因为大多数时候用户并不会发那种需要惊动旗舰模型的难题。路由也不只是按成本分。还可以按模态分、按语言分、按领域分。比如客服系统里简单FAQ用检索匹配直接回答不走模型需要情感分析时走一个专门调过的小模型复杂售后问题再走大模型。也可以让一个模型当“调度员”判断请求类型后把任务转给其他专门模型。这就是常说的Multi-Agent雏形。编排的另一个重点是任务流程。很多业务不是一次模型调用就能完成的而是“理解用户意图—查数据—调工具—组织回答”的多步过程。这一系列动作得有地方编排什么时候该调工具、工具返回后怎么继续错一步整个流畅就断了。这些编排逻辑就是夹在“模型”和“最终输出”之间的核心价值。2.3 评估与治理层决定“怎么证明系统可用”如果说前面两层是让系统能干评估层就是让系统“可被信任”。这层包括自动化评估、质量回归、数据隐私保护、成本与调用监控等属于最容易省但其实最不能省的环节。模型生成的结果有天然的不稳定性。同一个问题今天问和明天问答案可能不一样。在项目要上线的时候怎么跟团队或客户证明“效果可以接受”靠拍胸脯没用靠两个例子也没用得有一批覆盖各种场景的测试题定期跑一遍量化看结果。我之前搭过一个自动化评测小工具准备一组测试题每道题配有标准答案和评分规则用脚本批量向系统提问再通过模型或规则打分最后生成一个质量报表。每次更新提示词、调整检索策略、换模型都跑一遍测试集对比分数。这么做至少能防止改一个地方把另一个地方改坏了。评估指标也不要只盯“准不准”。延迟、成本、兜底率有多少请求模型没答上来、有害内容拦截率都是要一起看的。做企业服务时客户更关心的是“这个系统会不会乱说话”“万一错了谁来兜底”而不是榜单上的准确率。治理层还包括护栏和审计。怎么防止模型输出公司敏感信息怎么保证操作记录可以追溯这半年的模型能力强意味着它能做的事更多潜在的越界风险也更大在中间层架一套“闸门”非常必要。2.4 可观测与运维层决定“系统能否长期跑”最后这一层很容易被小团队忽略因为产品没上线时感觉不到它的存在但只要一上线它就是救命的那层。我在项目上线后吃过亏某天下午用户反馈变慢我查了半天才发现新模型在某些情况下不肯返回结果导致请求反复重试把并发占满了。如果当时有“重试次数”“请求耗时”“调用错误率”这些指标的可观测面板这个问题几分钟就能定位。可观测层要做的事很简单把每次请求的输入、输出、用的模型、耗时、token数量、成本都记录下来再按小时或天汇总成趋势图。一旦出现异常才知道是量大了、模型慢了、还是检索这边堵了。这一层还必须考虑“稳定性”工程服务挂了怎么办、模型端限流怎么办、结果被拦截怎么办。给请求做超时控制、对上游做重试和熔断都是运维层的基本功。模型再强系统不稳用户还是会走。3. 实操从零搭一套最小可用的中间层前面讲了很多概念这里我给一个可复制的实操路径。假设场景是“企业内部知识库问答助手”目标是新员工能直接问制度、流程和产品资料。以下每一步都是我实测过且觉得必要的。3.1 先定边界再动工具动手之前先回答三个问题面向谁、处理什么内容、回答错了后果多大。面向内部员工不求面面俱到内容主要是制度文件和产品手册回答错了顶多是信息误导风险可控。边界清楚了技术选型才不会跑偏。3.2 数据准备与索引构建这一步把企业文档变成机器人能查的库。格式解析先用脚本把PDF、Word、Markdown统一转成纯文本或结构化HTML注意PDF里表格经常被解析错位要单独处理。分块按章节优先章节太长的再按固定窗口切每块约800到1000字重叠150字左右。这个参数是经验值具体还要拿测试集调。向量化选一个合适的向量模型中文场景下要注意模型对中文语义的支持。把每块内容转成向量存入数据库。额外索引同时建一个关键词索引。向量检索和关键词检索结合能明显提高召回质量尤其在用户提问含具体名称时。这块我踩过一个坑第一版只用了向量检索用户问“报销流程”返回的都是和“费用”“财务”相关的内容但找不到真正的流程页面。后来把全文检索的结果按BM25算法跑一遍再和向量结果加权融合问题就解决了。3.3 检索问答与提示词设计检索到相关内容后拼装给模型看的上下文。系统提示词我习惯写成固定模板包含角色、任务、可用信息范围、禁止行为。其中“禁止行为”一定要写具体比如“不要回答与提供材料无关的问题”“不要编造产品参数”。用户问题进来后先做一次查询改写把口语化表达变成更适合检索的书面表达比如“报销是不是要领导签字”改写成“报销申请领导签字要求”。改完再去做检索命中率会高很多。最后把检索到的片段按相关度排序拼进提示词送给模型生成答案。这个链路看起来简单但每一步的效果都对最终回答有直接影响。3.4 模型路由与多级推理给系统加一层简单路由先用小模型做意图判断区分“简单问答”“需要检索”“需要工具动作”。简单问答直接用小模型回答不走检索。需要检索的走数据层检索后再拼上下文。需要工具动作的交给带Function Calling的模型比如查余额、查工单去调对应API。我在一个项目里用了一个很小的模型做意图分类准确率在垂直场景里能到95%以上成本几乎可忽略。剩下的复杂场景再交给大模型整体成本下降非常明显。3.5 评估闭环与持续迭代上线前一两天把测试集建好。我的做法是拉上项目组里最常使用系统的3到5个人每人出10到20个真实问题再人工把标准答案写一遍。不求完美但覆盖高频场景。之后每次改动都跑一遍测试集看三个指标命中率系统是否给出了可用回答。正确率回答内容与标准答案是否一致。兜底率回答不了或拒绝回答的比例。如果命中率太低回到数据层调分块或检索如果正确率低但信息在库里调提示词或升级模型如果某项改了之后其他指标掉了就说明改动有问题。3.6 上线观测与成本控制上线后把日志接上记录每个请求的耗时、token数、模型名、得分。我每天早上瞄一眼昨天数据重点看有没有突刺比如某个模型调用量异常、某个提示词产生了大量重复输出、某个检索词永远没有结果。成本控制方面有个实用技巧给请求设置token上限问句和检索结果拼装后如果超限就做压缩截断。不要让它无限制生成扔掉一些走偏的追问整体费用可以压一截。4. 常见问题与排查思路实操中踩坑是常态我按出现频率整理了几类问题并附上排查方向和我的经验做法可以当速查表用。4.1 检索结果明显不相关问题表现系统回答引用的内容跟问题完全对不上。排查方向先看检索结果排序是不是把相似但不相关的片段排在了前面。常用解调大召回数量比如从5调到20再靠重排模型或更精细的匹配过滤掉不相关的再就是换成“向量关键词”混合检索。另外我习惯把用户原问句query的改写做前置先确认改写是否失真。4.2 上下文拼了很长效果却更差问题表现提示词里塞了大量检索片段但模型反而抓不住重点。排查方向信息过载模型被无关细节干扰。常用解限制输入片段数量只保留最相关3到5个片段并把最相关的放最前面。同时在提示词里加一句“优先依据第一段材料回答”实测能显著提升准确率。不是塞越多越好。4.3 不同模型结果不一致无法确定谁更好问题表现A模型和B模型面对同一批测试题各有胜负。排查方向模型能力方向不同单看总分没意义。常用解按测试题标签分维度统计比如“中文常识”“逻辑推理”“代码生成”“工具调用”。然后按业务场景给各维度加权比如知识库问答更看重中文常识和检索内容遵循能力那这个场景下就重点考察这两项得分。给不同场景单独算加权分比比较总分靠谱得多。4.4 模型输出格式不稳定程序解析经常报错问题表现要求返回JSON但偶尔多了一句解释或漏了一个字段。排查方向模型输出没有绝对稳定不能靠运气。常用解在提示词里给出结构示例并要求按示例输出再加一次格式校验解析失败就自动重试一次或调用格式化函数。重要的流程我还会加一层“输出修正”让模型先把自己生成的答案按要求重写一遍保证字段完整。多花一次调用换稳定的结构值。4.5 成本超支账单涨得比用户还快问题表现月底一算token费用远超预期。排查方向很多金子花在“无效生成”和“过度检索”上。常用解先抓大Token消耗点看是检索内容太长还是模型回复太长。检索侧做召回数量上限和片段筛选回复侧做输出长度限制。再做模型路由让简单任务走小模型。最后在日志里给每个环节标记成本肉眼观察哪一环最费钱再针对性优化。我见过最简单的一次把向量检索返回的片段长度多截掉一半成本直接降了30%。5. 验证与进一步优化以上这套中间层不仅适应知识库问答换个场景也一样。我做智能客服时把数据层换成工单历史路由层加了一个情绪判断模型评估层换成用户满意率回访效果依旧成立。这里有一个很重要但很容易被跳过的观点中间层不是一次搭完就结束的它是一套持续迭代的机制。模型在变产品在变用户的问题也在变。每个季度我都会重新跑一遍测试集处理新增的问题类型调整路由策略。这个“维护中间层”的日常成本才是真正长期投入的地方也是它“值钱”的真正原因。再分享一个后面可以继续扩展的方向把中间层的各个模块做沉淀抽象成可以被复用的服务。比如把检索、路由、评测分别做成独立模块不同项目直接复用新项目上来不用从头搭。我目前就在整理这样一套内部组件库。这么做团队积累的经验就不会散落在单个项目里而是变成一种持续增值的工程资产。回到标题那句话“中间层为什么反而更值钱了”——因为这半年模型本身已经变成了基础设施而决定用户能不能用得好、用得起、用得稳的恰好就是你围着模型做的那些功夫。谁能把中间层做得扎实谁就能在模型浪潮里真正拿到属于自己的价值。