LLM落地实践指南：从RAG到微调的技术选型与成本优化

1. 别急着写代码先回答这三个问题我这两年看过太多LLM项目死在第一步。技术选型、Prompt设计、微调方案都还没定团队就急着把LangChain框架搭起来结果折腾两个月发现需求方真正想要的其实是一个关键词匹配的搜索框。在决定用LLM做点什么之前先把下面三个问题写在纸上答不上来就不要动代码。第一个问题这个场景有没有“模糊正确”的空间LLM本质上是概率模型它给不了确定性的结果。你要判断的客户投诉分类、要生成的商品描述、要抽取的合同条款这些任务本身就允许一定程度的模糊和变化。反过来如果你的场景要求100%准确比如算工资、算库存、验证身份那LLM就不是最优解至少不该是唯一解。我在项目里经常看到团队费力把LLM的输出强行约束成JSON去对接财务系统这种别扭的用法迟早要出事。第二个问题你的用户愿意等多久一次LLM调用的延迟从几百毫秒到几十秒都有可能取决于模型大小、输入长度和推理部署方式。如果你的产品场景是用户点一下按钮立刻要结果那大参数模型的推理延迟可能直接劝退用户。很多人的解决方案是“先用小模型顶着”这没问题但你要想清楚小模型的能力上限在哪里哪些业务场景必须用大模型第三个问题你的团队撑得起持续迭代吗LLM项目不是一次性交付就完事Prompt要反复调、模型要持续评测、数据要不断补充这些都需要有人持续投入。如果你是个人开发者或者小团队建议先从轻量方案入手比如调API而不是自己部署模型用现成的编排框架而不是自己从零实现一套。这三个问题都过关之后才有资格进入下一步选一条真正适合你业务场景的技术路线。2. 技术路线选择是生死决策不是技术偏好很多团队一提到LLM落地第一反应就是“微调一个行业大模型”好像不做微调就显得不够专业。我的建议恰恰相反先从RAG开始微调是最后的手段。2.1 RAG和微调怎么选才不至于翻车RAG检索增强生成和微调解决的是两种完全不同的病。RAG解决的是“模型不知道你说的事”的问题——比如你的企业内部知识库、最近发生的新闻事件、某个垂直领域的专业词汇。它通过在调用模型之前先从外部知识库检索相关文档片段把检索结果拼到Prompt里一起交给模型生成答案。这种方式的好处是知识更新只需要换文档不涉及模型训练成本低、见效快。微调解决的是“模型知道但不会用”的问题——比如让它学会某种特定的回答格式、语气风格、或者是复杂的指令跟随能力。微调需要准备成百上千条高质量样本需要GPU资源还需要面对灾难性遗忘的风险也就是模型学会新任务后忘了老任务。在现实中80%以上的企业场景更适合RAG。我给你举个例子某家做合同审查的公司想把几万份历史合同里的条款抽出来做结构化分析。这种场景模型本来就能理解自然语言问题的核心在于“没看过你的合同长什么样”所以RAG就能解决。他们只需要把合同文本切成片段、建好向量索引用户提问时先检索出相关段落再交给模型分析效果已经很好了。微调真正适合的场景是模型回答的风格和行为模式需要深度对齐的场景。比如你要做一个针对特定年龄段儿童的AI伴读产品模型的语气、措辞、知识深度都需要精确控制这种时候微调才值得投入。2.2 自建模型还是调用API账要算清楚这个选择题很多人纠结到失眠。我先说结论再给账本。如果是企业级应用优先考虑调用商业API。以中文能力比较强的主流模型API为例输入和输出综合成本大约是每百万token几十元的量级。一个中型客服系统的日均调用量大约50万次每次请求约2000字输入输出一天的token消耗量约10亿折合成本大约每月十几万元。听起来贵但你自建模型的话光是GPU服务器采购就得好几十万还没算电力、运维、带宽和算法工程师的月薪。如果是个人项目或者是简单场景的原型验证更不用纠结了直接调API。自建模型唯一的合理理由有三条数据敏感不允许出域、调用量极大大到规模效应明显、需要深度定制模型行为。这三条都是硬约束不是偏好问题。如果你的数据合规部门说“数据绝对不能出内网”那你没有选择只能自建。但你要做好心理准备自建模型意味着你需要一个至少能搞定推理部署的算法工程师还要承受模型更新换代的压力。2.3 一个决策清单帮你快速定位方案我把自己做项目时用的决策逻辑整理成清单照着走一遍基本不会走偏如果业务知识更新频率低于季度级且知识库结构化程度高选择RAG方案如果模型行为需要对齐特定的输出格式或语气风格且难以通过Prompt模板实现考虑轻量微调如LoRA如果日活用户超过10万且token消耗成本占总成本的比重超过40%提前规划自建推理集群做好冷热链路分层如果数据合规要求严格必须私有化部署预算充足可直接自建预算有限则用开源模型配合本地检索这套逻辑的核心就一句话技术选择跟着业务约束走不要跟着技术热度走。我见过太多团队为了“显得先进”强行上微调结果模型没调好、业务也没跑通还浪费了三个月时间。3. 垂域数据准备决定RAG系统成败的隐藏工程很多人以为RAG系统的核心是模型能力其实真正的胜负手是数据准备。模型只是发动机数据才是汽油。劣质汽油会把发动机堵死再强的模型也跑不起来。3.1 知识库拆分的分层逻辑不是拍脑袋定chunk_size做RAG系统第一步是知识库文档的拆分。很多人直接定“每500个字切一段”这是最省事但也是最不负责任的做法。拆分粒度直接决定后续检索的准确率拆小了语义不完整、检索出来牛头不对马嘴拆大了噪音太多、模型上下文装不下。我常用的策略是结构化优先的多级拆分法。先按文档结构层级章节、标题、段落作为粗粒度边界再在粗粒度块内按语义完整性和最大长度做二次切分。比如一份产品说明书先按章节切每个章节如果超过1500字再按段落切确保每段语义闭环。这里有一个关键参数值得留意重叠率overlap。切分时通常需要让相邻片段有少量重叠一般控制在10%到20%之间。原因在于许多关键信息正好落在切分边界上完全没有重叠的话这条信息会被拦腰截断检索时就找不到了。重叠能够有效保证这种边界信息的完整性。切完后还得给每个片段打标签。标签分两类一类是显式元数据比如文档来源、日期、作者、所属产品线另一类是隐式主题词可以用轻量模型自动抽取。标签的作用是给检索阶段提供过滤条件用户问“2024年的A产品故障处理”系统可以先用标签把时间范围圈住再在限定范围内做语义检索精度会高很多。3.2 向量化与混合检索的实战配置向量化模型选择有一个常见误区盲目追求所谓的高维模型。实际使用中嵌入向量的维度和检索准确率并不完全相关。我现在习惯用768维左右的中等规模模型原因是检索准确率和计算成本的平衡点最合适。向量检索的相似度阈值也值得细调。一般用余弦相似度阈值设在0.7到0.8之间比较稳。低于0.7的数据基本不相关检索出来只会稀释答案质量高于0.8则可能漏掉有价值的信息。这个阈值不是固定的需要在真实测试集上反复试。真正让RAG效果上台阶的是混合检索。向量检索擅长处理语义相关但表达方式不同的问题比如用户问“怎么退款”和文档里的“退货流程”语义上相关但字面差异大。关键词检索BM25擅长精确匹配专有名词和编码比如项目编号“PRJ-2024-083”。单用任何一种都有盲区把两者结合、用RRFReciprocal Rank Fusion倒数排名融合算法合并结果是最实用也最稳妥的方案。RRF的实现逻辑很朴素对同一查询分别用向量检索和关键词检索各拿回一批结果每个结果都有排名位置然后按公式计算融合分分数最高的排最前。这样做的好处是即使向量检索漏掉了某个精确匹配项关键词检索也能把它捞回来同时只要调到两条路线的置信度权重整体的精确率和召回率通常会比单跑任意一种高出一截。3.3 评测集是数据的“镜子”没有评测集就是盲人摸象RAG上线前必须准备一个评测集。所谓评测集就是一批真实用户问题每个问题配上标准答案和对应的文档片段。规模不用太大100到200条就够了但质量一定要高得来自真实业务场景不是你坐在办公室凭空想的。评测指标分两部分检索质量和生成质量。检索质量用RecallK也就是正确答案的文档有没有出现在召回的前K条里K一般取3到5生成质量用准确率、完整度、相关性或者直接人工打分。我习惯每次改动检索参数或Prompt后都在评测集上跑一遍对比分数用数据说话而不是“感觉变好了”。团队如果没有人力和预算人工评分还有个折中方案用GPT-4等大模型当评委让模型给答案打分。这种做法不是绝对客观但一致性比人工高作为内部迭代的参照物完全够用。4. Agent编排LLM从“回答问题”到“完成任务”的惊险一跳当你的LLM能力不再局限于“回答一个问题”而是要完成一个多步骤的任务比如自动处理客户退款、自动生成竞品分析报告Level就不一样了。这时候单次Prompt已经不够用了你需要Agent。4.1 从单次调用到Agent差的不是代码是任务拆解能力Agent的核心机制是把一个大任务分解成多个小步骤每一步调用不同工具或模型并根据前一步的输出决定下一步动作。听起来高级本质上就是一个“计划-执行-观察”的循环。我实操下来最关键的是任务拆解的粒度控制。拆得太粗模型一步完不成任务容易编造虚假信息拆得太细交互次数翻倍延迟和成本同步上升。我的经验是每个子任务的目的要单一、输出要明确、依赖关系要清晰。比如“整理今日销售数据”可以拆成调取销售数据库→按产品线聚合计算→生成趋势摘要→输出总结报告四个步骤就够不需要再细分了。模型在思考调度策略时会消耗大量推理Token这也是Agent方案成本高于普通RAG的主要原因。一个复杂的Agent任务一次完整执行可能要消耗3到5倍的Token量。做成本预估时要有心理准备。4.2 工具调用Function Calling的工程化坑与对策Function Calling是Agent的右臂也是工程化中最容易出bug的地方。它让模型在对话中识别用户意图然后输出一个结构化的函数调用请求你的系统按请求执行函数并把结果返回给模型。最常见的坑有两个。第一个是函数描述写得太模糊。模型的工具选择完全依赖你的函数描述描述不清晰模型就会瞎猜或者干脆不调用。描述要包含函数做什么、参数含义、在什么场景下使用、返回值格式。写完后自己先拿几个典型问题测一遍看看模型能不能正确触发。第二个坑是参数校验和兜底逻辑缺失。模型输出的参数它自己并不可靠经常出现缺字段、类型错误的情况。不要指望模型能规范地填对每个参数要有一个校验层把模型输出的参数强制校验和纠偏。我用过一个直观的方案设计一个中间表示层让模型优先输出语义化的意图代码由系统把这个意图代码映射到具体的函数调用。比如用户说“帮我查一下上个季度华东区的销售额”模型先输出一个规范化的查询意图再由代码转换成具体的API调用参数。这种方式相比直接让模型输出函数调用容错率高很多因为意图识别层出错的概率比参数级生成低得多。4.3 多Agent协作模式什么时候用才不是炫技每次看到有人把五个Agent串成一个流水线我都会问一句解决了什么单Agent解决不了的问题吗多Agent协作的真正价值在于角色隔离和上下文隔离。比如一个复杂的报告生成任务可以让一个Agent负责资料收集另一个负责结构化梳理第三个负责最终润色。每个Agent的上下文窗口只装自己需要的那部分信息避免上下文过长导致的“迷失在中间”问题也避免互相干扰。但多Agent的代价很明显协调开销大、出错面广、调试困难。我的建议是团队第一次做Agent项目老老实实从单Agent多工具做起等跑通了再考虑多Agent。你会惊讶地发现很多看起来适合多Agent的任务单Agent精心设计的Prompt流动框架就能解决得很好。5. 成本治理与性能优化LLM项目的长跑生存指南LLM项目的成本不是一次性投入而是持续燃烧。上线只是起点后面每个月的Token账单才是真正的考验。我见过好些项目功能做得挺顺最后因为账单太贵被公司叫停非常可惜。5.1 Token成本模型几笔不得不算的账算Token消耗不只是“输入输出”这么简单。实际运营中还有几笔隐形成本第一笔是Prompt膨胀成本。系统Prompt越长每一次调用花在固定输入上的Token就越多。假设你的系统Prompt有2000字每天调用10万次这块固定消耗的Token大概是多少2000字的Token数按2000估算中文大致1字≈1到1.5个Token乘以10万次一天的消耗就是2亿Token。按主流API价格估算这部分成本可能占据总费用的一半以上。所以Prompt设计得精简不是在优化体验而是在优化成本。第二笔是重试成本。模型偶尔输出格式不对或者内容明显错误需要重试。重试率一高成本至少增加20%以上。第三笔是评测成本。每轮评测都要消耗Token次数多了也不便宜。应对策略是分层模型策略简单任务用便宜的小模型复杂任务才上大模型。我经常用的方案是意图识别和实体抽取用轻量模型生成合同摘要或关键决策建议用性能更强的模型相当于在成本和能力之间做一个两段式分配。实测下来70%的请求都可以被便宜模型接住总成本能降40%以上。5.2 推理性能玄学延迟、吞吐、缓存的三重博弈推理延迟是用户能直接感知的指标也是优化空间最大的地方。核心参数有四个模型大小、输入长度、并发数、显存规格。先说并发和显存的关系。一张消费级显卡24GB显存跑7B参数模型显存占用大约16GB左右剩下的空间决定并发上限。如果每路请求最多占20%的显存单卡最多同时服务几路请求。多路并发时延迟必然上升这是物理限制。低延迟场景有几个有效手段一是Prefix Caching相同前缀的Prompt只需要计算一次多轮对话里这个优化效果很明显二是流式输出边生成边返回用户的等待感会大幅下降三是动态Batch把并发请求拼在一起推理GPU利用率能提高不少吞吐量能提升两到三倍。如果做的是企业级应用尽量提前做压测。用真实业务流量录制回放观察延迟的分位数P95、P99而不是只看平均值。平均值很平滑不代表没有长尾长尾响应往往才是用户投诉的重点原因。5.3 缓存、降级与熔断一个都不能少LLM接口终究是外部依赖不稳定才是常态。最稳妥的系统设计是预设降级方案核心链路一旦调用失败立刻切换到备选模型或者降级到检索直接返回结果不调用生成环节。我上一家公司的客服系统就是三层降级方案大模型生成层挂了切到小模型小模型也挂了就返回预先配置的FAQ精准命中结果。实测效果是系统可用性从97%提升到了99.9%以上用户几乎无感。缓存策略同样重要。高频重复问题比如“怎么开发票”“退款多久到账”直接把模型答案缓存下来命中率能到20%到30%。缓存命中的请求不消耗Token、不需要模型推理响应时间直接从秒级降到毫秒级。6. 效果评测与持续运营LLM上线才是麻烦的开始很多人以为模型上线跑通就大功告成了这是最大的错觉。LLM系统是活的用户需求在变、知识库在变、模型底座也在变任何一个变化都可能让效果肉眼可见地变差。6.1 评测迭代机制用数据而不是感觉做决策我建议项目一上线就建立一套双轨评测机制离线评测和在线监控。离线评测针对每次改动改Prompt、换模型、调参数用固定的评测集跑分。评分要比上一版高才算有效改动否则回滚。这套机制保证你不会在改动的迷宫里越绕越远。在线监控是针对生产环境的真实流量。核心指标四个调用成功率、平均延迟、用户反馈率、以及答案采纳率如果产品有点赞/点踩功能。这四个指标任何一个掉了超过10%就要触发告警需要排查是输入分布变了、还是模型服务出了问题。6.2 用户反馈闭环让数据帮你迭代真实用户的问题分布和你的评测集往往差距巨大。评测集是你想象中的问题线上用户问的是千奇百怪的实际问题。所以一定要做数据回流收集所有线上真实的问题和模型回答人工抽样标注错误类型答非所问、内容过时、幻觉编造、语气不当按类型归因后反哺优化。把高频问题输入检索测试集保证它对这类问题的召回率把标注的错误回答日志输入Prompt优化脚本针对错误模式微调Prompt策略每周固定跑一轮统计优化前后各类错误的比例变化。这个过程是LLM项目效果提升的复利引擎跑三个月后效果和第一天上线的效果会拉开明显差距。6.3 幻觉治理不可能让模型撒谎但可以教它说“不知道”幻觉是LLM项目绕不过去的坎。模型一本正经地编造事实在企业级场景是会出事故的。我的治理方案分三层。第一层在Prompt里明确要求“如果没有对应信息请直接回答不知道不要推测”这个约束能显著降低无中生有的比例。第二层把RAG检索结果作为唯一知识源限制模型的回答范围检索不到就让模型说不知道。第三层增加一个后置校验步骤把生成的答案与检索到的文档片段做一致性比对有明显冲突的标记出来返给用户时加上“AI生成内容仅供参考”的提示。三层一起做虽不能根除幻觉但能把严重幻觉的比例压到个位数以内。做企业级应用手里多一层校验就是多一层底气。7. 落地的最后一公里组织、流程与长期主义方法论和技术都聊完了最后说点大实话LLM落地最大的障碍往往不在技术而在人和流程。我见过的失败项目十有八九因为团队把LLM当成一个神奇的插件以为装上去就能解决所有问题。实际上LLM只是整个系统中的一个组件它的上下文需要靠业务逻辑来供给它的输出需要靠工程逻辑来验证和兜底。实际推进的过程中团队里最重要的角色不是算法专家而是既懂业务又懂技术的产品经理。这个人能做需求拆解、数据梳理、评测体系搭建能把“用AI优化运营”这种模糊愿望变成一个个具体的、可执行的技术需求。步子也得迈小一点。我的习惯是先用2到4周做一个最小闭环场景聚焦、数据最小化、流程简单化。跑通后积累数据再逐步扩大场景用真实数据说服业务方加大投入。先用几个月的时间在数据和反馈的基础上一步步把系统做深做厚远好过一开始就铺一个宏大但没有人运转得动的盘子。最后说个细节。最近一年我最大的收获是养成了每次上线前六连问的习惯数据准备好没有评测集建了没有降级方案验证过没有成本模型算过没有监控告警配了没有回滚预案写了没有六个问题全是“是”才敢点发布按钮。这六个问题背后对应的其实就是这一路踩坑踩出来的所有心得了。