1. 榜单上的模型越来越高我们盯的却是工单这条线去年我们团队决定做AI落地的时候内部有个不太雅的比喻模型负责上天我们仨负责把它拽回地面。当时模型圈的新闻全在天上——新架构、新榜单、参数竞赛一轮接一轮今天是这个模型刷新了推理能力明天又是另一个模型号称逼近人类水平。可真实业务里没人关心这些。大家只关心一件事下午三点工单高峰的时候系统能不能把售后问题接得住、回得准、不宕机。我们团队就三个人。老陈以前搞运维小林以前做数据分析我写后端没有一个算法科班出身。三个人敢接AI落地这个活不是说我们多懂模型而是我们慢慢摸清了一个规律一个AI项目能不能成决定性因素往往不在模型本身而在模型之外的数据、部署、工程和场景匹配。这篇文章不聊前沿算法只聊我们三个野心家把大模型塞进售后工单系统这半年多踩过的坑、算过的账、沉淀下来的方法。如果你也想把AI落到自己的业务场景里而不是停留在调API玩一玩的层面这篇内容应该能帮你省下不少试错成本。1.1 天上跑的模型和工位上跑的模型不是一回事先说清楚一个很多人容易混淆的点。你在新闻里看到的模型很强是它在海量公开数据、巨额算力、专业评测集上的表现但放到真实业务里模型面对的是冷冰冰的工单文本、残缺的客户信息、随时变化的业务流程。举个最直观的例子公开榜上排名靠前的模型你问它如何退货它能给你写一篇完整的退货政策说明但你的业务里退货要分订单来源、支付方式、商品品类、是否拆封每个组合对应的处理路径都不一样。通用模型不知道这些它只会给你一个看起来正确但没法直接用的答案。这就是上天和落地之间的鸿沟。天上比的是模型的知识上限地上比的是模型在你这套业务规则里的行为准确度。知识上限再高行为不贴合场景生产环境就用不了。所以我们从一开始就没打算追最新最强的模型而是把精力放在三层事情上第一把模型稳定地部署到自己的服务器上第二用业务数据把模型驯化成懂这套业务流程的专家第三通过Agent编排让模型能调用内部工具真正把事办了。1.2 为什么偏偏选售后工单这个场景选场景是AI落地里最容易被低估的一步。我们当时列了几个候选智能客服、文档问答、代码辅助、数据报表生成。最后选了售后工单理由是四个字闭环够短。售后工单有三个天然优势。第一有存量数据——过去一年系统里积累了十几万条已完结工单每条都带着问题描述、处理过程、最终结果这是微调和评估最好的原料。第二效果可量化——工单分类准不准、回复是否被客服采纳、平均处理时长有没有下降都是硬指标不用靠感觉说话。第三容错空间合适——生成的内容先给客服参考不是直接面向客户出错了有人兜底不至于一上线就翻车。我们给这个场景定的目标也很朴素先把工单自动分类准确率从人工的72%提到85%以上再让系统根据历史工单和知识库生成回复草稿最后能做到客服看一眼改几个字就能发出去。这个目标听着不性感但半年后回头看恰恰是这种不好高骛远的目标让项目活了下来。2. 第一棒把模型从云端请回本地推理性能的实测账本我们这半年走下来的节奏基本上是接力赛。老陈跑第一棒模型部署和推理性能。这一棒跑不扎实后面的微调和Agent全都是空中楼阁。2.1 本地部署还是全走API先把账算清楚现在市面上商用API的体验确实很好开箱即用效果也强。但我们在场景评估阶段就排除了全走API的选项核心原因有三个。第一是数据安全工单里包含客户姓名、电话、订单明细这些数据出域到第三方API合规上就过不了关。第二是成本我们这业务一天几千条工单高峰期还要并发调用按token计费一个月下来是笔不小的开支而且业务量涨账单跟着涨成本完全不可控。第三是定制空间API能给的参数和微调能力有限我们想要的领域适配和结构化输出走API就像隔着玻璃操纵机器人总差那么点意思。当然本地部署不是什么都好。初期调试成本高、需要专门维护GPU服务器、模型版本更新要自己跟进这些都是实打实的麻烦。我们的策略是前期用API验证效果后期迁移到本地。先用API跑通业务流程、确认效果达标再让老陈把模型搬到本地两件事并行不互相等。2.2 模型选型与量化14B够用就别硬上72B模型选型这件事我们踩过最大的坑就是参数越大越好的惯性思维。第一版方案用的是当时能拿到的最大开源模型部署上去之后老陈的头发掉了一半——显存吃紧、推理延迟高、并发上不去最后效果也没比14B模型好多少。后来我们总结出一条原则模型大小取决于任务复杂度而不是你的显卡能塞下什么。我们的核心任务有三类工单分类意图识别、信息抽取订单号、产品型号、问题类型、回复生成根据上下文生成可参考的答案。这三类任务7B模型能做但细节差一些尤其信息抽取容易漏14B模型基本够用72B当然更强但推理成本是14B的四五倍收益却不到一倍。综合评估后我们选了Qwen2.5-14B-Instruct作为主力模型用GGUF量化格式部署。这里给一张我们自己实测的量化对比表环境是单张RTX 4090仅供参考量化档位显存占用加载后生成速度效果损失Q4_K_M约10GB38-42 tokens/s轻微信息抽取偶发丢字段Q5_K_M约12GB28-32 tokens/s极小接近FP16效果Q8_0约16GB18-22 tokens/s几乎无损最终我们选了Q5_K_M理由是在工单这种对细节敏感的场景里Q4偶尔会漏关键信息一次漏检带来的后续处理成本远大于省下来的那点显存。Q8效果最好但速度慢24GB显存的卡跑起来余量也不够。Q5_K_M是效果和性能的平衡点。这个结论不一定普适但如果你也在做类似的文本分类和生成任务可以拿这个当起点去测。2.3 推理框架Ollama负责调试vLLM负责生产模型选完接着是推理框架。我们中间试过Ollama、llama.cpp、vLLM三套方案简单说说各自定位。Ollama最适合开发和调试阶段。它的优势是安装简单、模型管理方便、提供了兼容OpenAI的API开发时一个命令就能把模型拉起来测。而且现在Ollama配套的UI工具也很顺手能直接看正在跑的模型占多少显存、每秒生成多少token用来快速验证量化档位和提示词模板非常方便。我们初期所有的接口联调都是在Ollama上完成的。但Ollama的生产能力偏弱。它的并发调度和前缀缓存策略比较基础一旦请求量上来显存管理就不够精细容易出现显存碎片化或排队堆积。所以正式上生产时老陈换成了vLLM。vLLM这名字在AI infra圈子里不算陌生它对显存的管理颗粒度细很多支持连续批处理和PagedAttention同样的两张RTX 4090vLLM的吞吐量比Ollama高出一大截。压测下来32路并发下P95首token延迟能压在500毫秒以内单条工单的完整回复生成在三秒内这个数字在老陈看来属于可以上线的水平。至于llama.cpp它更擅长CPU推理和边缘设备场景我们只在没有GPU的备用机上试过一版效果能用但速度不理想后来就放弃了这个方向。一句话总结开发用Ollama图省事生产用vLLM图稳定llama.cpp留给没有GPU的环境。3. 第二棒蒸馏加微调把通用大模型驯成业务老师傅模型部署好了能跑起来了但直接用通用模型上业务你会发现一个尴尬的事实它什么都懂一点就是不懂你这一亩三分地。这一棒由小林负责核心手段是蒸馏和微调。3.1 直接拿通用模型上业务会有哪些别扭我们当时用14B模型做了两周的裸奔测试也就是不微调、不做任何业务适配直接让它处理真实工单结果问题一大堆。最典型的是三类第一回复太教科书比如客户问我买的A300耳机左耳没声音怎么办它会给出通用的耳机故障排查步骤但我们的A300还有一个已知的固件bug需要先升级固件再排查硬件这个信息它根本不知道。第二格式不统一同一个问题有时候回复是一段话有时候是折叠的要点列表客服用起来非常割裂。第三术语理解偏差比如我们内部说的返修件换新件维修单这几个概念模型会混用导致信息抽取结果没法直接进流程。这些问题靠提示词工程解决了一部分比如强制它按模板输出、给它少量示例但根子上的领域知识缺口提示词填不了。模型的领域知识要么来自训练数据要么来自外部检索。外部检索我们后来通过RAG补了但训练数据这个层面就需要靠微调来补。小林当时说了句话我印象很深通用模型是个博士生懂很多但他没在我们公司上过班。微调就是让他入职培训。我觉得这个类比挺准。3.2 蒸馏的目的不是让模型变聪明而是让模型懂规矩说到蒸馏很多人第一反应是用小模型学大模型的能力这个理解没错但实操里有个更重要的维度蒸馏不只是能力迁移更是行为对齐。我们没有任何自研的基础模型蒸馏在这里的角色是用更大更强的模型按我们的业务规范生成一批标准答案然后让14B模型去学这批答案的表述方式。具体流程是这样的。第一步从工单系统导出过去一年五万多条已完结工单清洗掉重复、乱码、超长和涉敏数据。第二步从中挑出四千条高质量工单每条都包含完整的问题描述、处理过程和满意结案的结果这些是原料。第三步把原料交给旗舰模型让它按照我们预先定义好的回复模板包含问题确认、原因分析、解决方案、后续提示四个段落重写回复同时把工单分类标签和信息抽取字段也一并生成。第四步人工抽检——两个人花了三天时间抽检了其中20%的数据把答错、漏字段、语气不对的样本修正或剔除。最终得到约八千条有效训练数据和三百条评估数据。这里我想多说一句。很多团队做蒸馏恨不得一次性生成五万条十万条数据量大管饱。但我们实测下来数据质量比数量重要太多。八千条干净、格式统一、答案明确的数据训练出来的效果比三万条机器生成但没人抽检的数据要好。因为蒸馏出来的错误会被模型照单全收错误的数据进训练集等于你亲手把模型教歪。3.3 LoRA微调的关键参数和翻车记录微调框架我们用的LLaMA-Factory方法选的QLoRA。选它而不是全量微调原因很现实全量微调一个14B模型显存不够时间也长QLoRA把基础模型量化到4bit只训练一小部分低秩矩阵单张24GB显卡就能跑训练一轮大约四十分钟足够我们频繁迭代。几个关键参数给小林实测下来的版本参数项数值说明基础模型Qwen2.5-14B-Instruct加载时Q5量化配合推理端同源模型量化4bit QLoRA节省显存LoRA rank16太小学不进去太大容易过拟合LoRA alpha32与rank保持2倍关系学习率2e-4cosine衰减试过1e-4收敛太慢训练轮数3轮早停在2.3轮第4轮开始过拟合训练数据8000条蒸馏数据 400条通用指令后者用来防灾难性遗忘数据格式用的是标准的instruction-input-output三段式。比如输入是客户反映A300右耳连接蓝牙后五秒内频繁断开已尝试重置问题依旧输出是带工单分类、关键字段和回复正文的JSON。让小模型学这种结构化输出比让它学自由文本靠谱得多。翻车记录也得说。第一次训练我们直接跑了五个epoch训练集loss漂亮得感人结果评估集F1反而从0.85掉到0.81。这就是典型的过拟合——模型把训练数据背下来了遇到没见过的说法就懵。后来加了early stopping在验证集loss开始回升的地方截住问题解决。第二次翻车是灾难性遗忘微调后的模型处理工单很专业但你问它你好它居然也回工单风格的模板话。原因是训练数据里全是业务样本没有寒暄和通用对话。解决方法是往训练集里混了10%通用指令数据把日常对话能力兜住。这个细节特别容易被忽略但上线后影响很大。3.4 微调不是终点评估集才是裁判每次微调完我们都要跑一遍固定的评估集。三百条样本包含工单分类、信息抽取、回复生成三个子任务分别算分类F1、字段召回率和格式规范率。微调前后的对比非常明显指标微调前通用模型微调后LoRA工单分类F10.760.92订单号抽取召回率0.620.95回复格式规范率约70%98%客服采纳率约35%约68%有了这套评估集我们后面每次叠加新数据、调整Prompt、换模型版本都能快速判断是变好了还是变差了。顺便提一句我们也试过市面上聊得火热的模型融合方案想把多个模型的长处合并到一个模型里。折腾了一周效果提升非常有限反而把部署和调试复杂度拉高了。对大部分业务团队我的建议是先把蒸馏微调评估这套基础闭环跑通模型融合这种高阶玩法等基础扎实了再考虑。4. 第三棒Agent编排让模型长出手脚去办事前两棒跑完模型已经能理解工单问题并生成像样的回复了。但到这一步它还只是一个高级的文本生成器——不能查订单、不能调知识库、不能推动工单状态流转。第三棒由我负责Agent编排也是我自己觉得整个项目里最有意思的部分。4.1 从回答得对到事情办得成中间还差一层工具我习惯用一句话跟外行解释Agent和纯模型之间的区别模型是大脑Agent是大脑加手脚。大脑可以分析问题、构思答案但没有手脚它没法去数据库查这个客户是不是VIP没法去订单系统确认这笔退款有没有到账也没法把生成的工单保存到系统里。Agent编排要做的就是把大脑和手脚之间的连接打通。以我们工单系统的实际场景举例一条帮我看下订单12345退款到账了没的客户问题单纯的模型只能回复一篇请登录App查询退款状态的模板话。而Agent的做法是先调用意图识别判断这是查单类问题再从问题里抽取订单号调用订单系统的API查询退款状态把查询结果拼进上下文最后让模型基于真实状态生成回答。这时候回答就变成了订单12345的退款已于昨天15:02退回原支付账户预计1-3个工作日到账。客户体验完全不一样。从工程视角看Agent最关键的不是模型能力而是工具调用的设计。我们给系统定义了四类工具订单查询、工单历史检索、知识库检索、客户信息查询。每个工具都有自己的入参schema模型先判断该不该调用、需要传什么参数再按JSON格式输出调用指令系统层执行后把结果回填给模型。这套逻辑听起来简单但真正跑起来第一个让人头疼的问题就是模型传参不够准。4.2 工具调用与RAG的配合方式工单系统里大量的售后问题不是退没退款这种能靠API直查的问题而是A300耳机连接不上怎么办这种需要查知识库的。这部分我们用了RAG检索增强生成。知识库存的是产品手册、标准回复话术、历史优质工单每一条先切成512个字符的块块与块之间保留64个字符的重叠避免检索时把关键信息截断。向量化用的bge-m3模型同样部署在本地检索时取相似度最高的前五块拼进上下文让模型参考这些内容生成回答。工具调用和RAG并不是互斥的实际流程是串联的。第一步Agent判断问题类型第二步如果是知识型问题先做向量检索拿到相关资料如果是状态型问题先调API拿真实数据第三步把检索结果或API结果作为上下文连同原始问题一起交给模型第四步模型输出结构化结果包含回复正文、工单分类、建议处理人。整个过程对客服来说是无感的他在工单系统里输入问题几秒钟后页面上多了一段草稿回复并附带了信息来源链接方便他追溯。这里有个设计心得RAG检索出来的内容一定不能让模型自由发挥。我们的提示词里明确要求回复内容只能基于检索到的资料和上下文不能引入资料之外的信息。这样既控制了幻觉也保证了客服能看到每个结论的来源。4.3 为什么没有直接上Spring AI而是自己写编排层项目启动前我们认真评估过Spring AI和LangChain这类现成的Agent框架。先说结论不是它们不好而是跟我们需求不匹配。Spring AI在Java生态里集成度高适合团队本身就是Java技术栈、需要和Spring Boot应用深度绑定的场景LangChain功能丰富适合研究原型和快速验证。但我们的场景其实很窄固定的工单流程、固定的几个工具、固定的结构化输出需要的是一套正好够用的编排层而不是一个什么都能干的框架。自研编排层到底写了多少东西核心其实就一个状态机加一个调度器。状态机维护每个对话的生命周期从初始意图识别到工具调用、上下文组装、模型生成、结构化解析再到最终动作执行。调度器负责把模型输出和工具调用衔接起来处理超时、重试和异常。核心代码量不大但每条路径都是我们亲手控制的出问题能立刻定位。桩代码大概长这样def handle_work_order(question: str) - WorkOrderResult: intent classify_intent(question) if intent ORDER_STATUS: order_id extract_order_id(question) order_info query_order_api(order_id) context build_context(question, order_info) elif intent PRODUCT_AFTER_SALE: docs retrieve_knowledge(question, top_k5) context build_context(question, docs) else: context build_context(question) raw_output llm.generate(context, response_formatjson) return parse_work_order_result(raw_output)用了自研方案之后我们反而能更快接入第三方能力。比如后来换了更好的向量模型只需要改一个函数不会因为框架的抽象层卡住。当然如果你们的团队规模更大、场景更复杂直接用成熟的Agent框架是合理的。选择的原则很简单你能掌控的复杂度才是合适的复杂度。4.4 提示词与结构化输出这些细节决定上线体验Agent编排层搭好之后真正影响用户体验的反而是几个不起眼的细节。第一个是结构化输出。我们要求模型每次返回一个JSON包含reply_text、category、extracted_fields三个字段。为了让格式稳定我们在请求里带上了JSON Schema约束并且做了解析失败的兜底——一旦JSON解析失败就把模型原始输出原样交给客服不让流程卡死。第二个是超时和重试。模型生成不是无限快的高峰期如果排队太长该放弃就得放弃。我们的策略是单次生成超时30秒工具调用超时5秒超时后自动降级为仅展示检索资料、不生成回复的模式。这样最差的情况客服也能拿到知识库里的参考文章不至于两手空空。第三个是提示词里的负面约束。模型天生倾向于讨好用户有时候客户问题里明明没提到的信息它会脑补出来比如虚构一个退款单号。我们就在系统提示词里加了一条硬性规定如果上下文中没有足够信息明确告知用户需要补充不要编造。这条约束配合RAG的来源引用把工单回复的幻觉率压到了可以接受的范围。5. 半年后回头看高频故障、成本账和场景边界系统跑了大半年基本稳定了但中间踩过的坑、交过的学费值得单独拿出来说说。这一节算是一份沉淀下来的排查清单和决策参考。5.1 上线后碰到的几个高频故障与排查链路先抛一个最常遇到的问题输出截断。工单回复有时候需要写得很完整尤其涉及多步骤排查时模型容易在生成到一半时撞上输出token上限导致回复戛然而止。第一次发现这个问题是客服反馈有的回复最后一句是半截话。排查链路如下先看vLLM的日志确认是不是max_tokens参数设得太小再看评估集里长样本的比例发现超过80%的工单回复文本量在500字以内少数复杂工单需要800字以上。最终方案是把max_tokens从512提到1024同时在提示词里要求优先给出最关键的三个步骤不要展开无关细节。双管齐下截断问题基本消失。第二个高频问题是上下文溢出。Agent每个步骤都会往上下文里塞内容问题、检索结果、API返回、历史对话如果链路多轮token很快吃紧。我们踩过的一次事故是一个客户连续追问了十几轮上下文里积累了大量历史信息模型突然开始答非所问。排查后发现是上下文窗口被占满早期的关键信息被挤掉了。解决方案是给对话加了滑动窗口只保留最近五轮完整对话更早的内容每轮做一次摘要压缩并把用户的原始诉求单独拎出来长期保留。这个方案既不丢关键信息又能控制token开销。第三个问题是Agent工具调用的参数幻觉。模型有时候会从问题里抽出一个看起来很合理的订单号但那个订单号根本不存在。原因是客户在问题里附带了一个和当前工单无关的历史订单号模型分不清该用哪个。我们当时从两个方向修一是让工具API增加一层校验订单号不存在就返回未找到并提示模型向用户确认二是在Prompt里告诉模型优先使用当前工单关联的订单号如果不存在向用户确认后再查询。工具层和应用层各加一道保险问题才彻底解决。5.2 算一笔真实的成本账很多团队评估本地部署只看显卡采购价觉得太贵了。但完整算下来结论可能跟你想的不一样。成本项月均费用说明硬件折旧约1250元两台RTX 4090加一台64GB内存服务器总计约4.5万按36个月折旧电费约300元日均功耗约500W按商业电价估算商用API替代成本约数万元若全走API按10万工单/月、每单3000 token估算人力成本三人均摊这是大头但属于项目必投看到没有硬件和电费加起来一个月不到两千块相比同等调用量的API费用成本优势非常明显。真正贵的是人力——三个人半年多的开发时间。但这是固定成本系统上线后边际成本极低。如果你处于业务验证阶段建议先用API跑通确认有真实效果再投入人力做本地化这样风险可控。另外要注意token消耗的分布。我们后来统计了一下生成回复本身消耗的token占比不到40%更多token花在了工具调用产生的上下文回填、知识库检索结果的拼接、历史对话的保留上。这提醒我们优化token成本不能只盯着模型输出长度上下文管理策略也很重要。5.3 哪些场景适合这么干哪些暂时别碰做完这个项目我对AI落地的适用边界有了更清晰的认识。适合这么干的场景通常具备四个特征第一业务有标准化流程输入输出可以被规则描述第二有存量数据闭环能不断拿到真实反馈来迭代第三容错空间较高AI出错可以被人工兜住第四数据敏感或调用量大本地部署在合规和成本上更有优势。反过来有几类场景我建议你谨慎。一类是强合规场景比如医疗诊断、金融风控的最终决策AI的建议必须经过严格的审核流程别指望模型直接拍板。另一类是低容错场景比如完全没有人工复核的自动回复、无人值守的客服入口模型一旦出错客户体验损失可能远超节省的成本。还有一类是开放域创意生成比如让模型做营销文案、写短视频脚本这种没有标准答案的场景评估和迭代都很困难投入产出比不一定划算。那些动不动宣传无限制AI的到了真实业务里基本站不住脚。限制不是束缚而是护栏。没有护栏的模型在工单场景里跑一天你可能得花三天收拾它。越早接受限制本身就是工程的一部分这个事实你的落地之路就越顺。5.4 三个人怎么配合才能把接力赛跑完最后聊点协作层面的体会。AI落地是个跨工种工程算法、工程、业务三条线必须同时转。我们的协作方式很简单老陈保证模型随时能被调用小林保证模型输出符合业务要求我保证业务方使用体验顺畅。每周一次固定迭代从业务系统里拉新工单经过蒸馏和人工抽查后增量合成训练数据重跑微调再上评估集验证效果提升或至少不减就灰度上线。这套流程走顺之后有个很大的好处是人人都有抓手。老陈可以用显存和延迟说话小林用评估集指标说话我用客服采纳率说话谁也甩不了锅。遇到模型效果不好我们的排查顺序永远是先看数据、再看微调参数、最后才怀疑模型本身。事实上大半的问题最后都出在数据质量上这也是做AI落地和发论文最不一样的地方。论文里你调参调网络结构生产里你调的是数据管道和预期管理。模型在榜单上怎么上天那是别人的事。我们更关心的是工单高峰来的时候这套系统能不能稳稳地把答案递到客服手边让今天的工作按时下班。如果你也正在做或者准备做类似的事情记住这句话别让模型成为你唯一关注的东西。部署、数据、评估、编排每一环掉链子模型再强也落不了地。这半年多我们仨也没做出什么惊天动地的成果就是靠着把每一环都磨到及格以上把系统从演示能用推到了天天在用。这条路走得不快但走得稳。