大模型落地实战指南：从模型选型到RAG与Agent的工程链路

大模型聊了两年各家发布会看了无数轮参数越卷越大榜单刷了一波又一波。但真到了自己负责的产品里你发现吹过的牛全变成了具体而琐碎的问题部署在哪个环节、该用多大参数的模型、幻觉怎么处理、业务方要的“精准回答”到底怎么做、成本摊到每个用户头上是多少钱。我这两年带着团队帮不同行业做了不少LLM落地的项目最大的感受是阻碍LLM落地的从来不是模型能力而是大家对“从模型到产品”这条链路缺乏一个系统化的实操认识。这篇文章不聊论文不吹架构只讲我在实际项目里怎么选型、怎么搭RAG、怎么调Agent、怎么准备垂域数据以及真正上线时会踩哪些坑。目标读者是那些手里有产品、有业务场景想把LLM接进去但还没想清楚“第一步迈哪只脚”的团队。文章会比较长因为每一段后面都是真金白银的教训。1. 先从根上想清楚LLM在你的产品里到底扮演什么角色很多团队第一步就搞反了——先选模型再想场景。正确做法是先定义清楚LLM在你的产品里解决什么问题这会直接决定后面所有的技术选型。1.1 四个定位决定了完全不同的技术路线我习惯把产品里的LLM角色分成四类对话中枢用户直接和模型对话典型如客服机器人、AI助理。这类场景对交互体验、响应速度要求极高现在通常用Agent架构来组织。内容生成器帮用户写文案、总结报告、生成邮件。对输出的格式稳定性要求高需要强指令约束。语义理解引擎不直接面向用户而是在后台做分类、抽取、情感判断。这类是当前ROI最高的落地方式因为出错的影响可控。流程决策大脑模型自主决策调用哪些工具、走哪条业务逻辑。比如AIoT里的智能家居管家模型根据用户模糊指令编排设备联动。这四个定位对应的工作量天差地别。最稳妥的切入点是“语义理解引擎”因为它不需要模型输出长篇大论容错率高可以先用小参数模型跑通。最需要谨慎的是“流程决策大脑”因为一旦让模型做自主决策就必须配套完整的安全护栏和回退机制。我见过一个典型的反面案例某团队想做智能客服上来就采购了市面上最大的商用模型结果每次调用的成本是行业均价的几十倍响应延迟还让用户反复催单。后来我们把场景拆成意图识别、知识检索、话术生成三段前两段用开源小模型本地部署最后一段才调用大模型整体成本直接降了一个数量级。这就是“角色定位决定方案”的典型体现。1.2 “大模型万能论”为什么会让项目烂尾现在行业内有一种风气觉得LLM什么都能干什么场景都往里塞。这种“万能论”是项目烂尾率最高的原因。我拆解过一些失败项目共性惊人的一致团队没有想清楚“模型回答错了会怎样”。以法律咨询为例模型给合同纠纷给错了建议用户真去起诉责任算谁的以医疗为例模型推荐错了用药方向出了事故谁兜底这不是技术问题是产品定责问题。一个可以承担部分错误的产品和一个绝对不能出错的产品技术方案完全是两套。所以我的建议是先盘点你产品里的所有需求按“容错率”分级优先做容错率高的场景。比如新闻资讯的摘要、非敏感数据的分类、辅助人类决策的打标这些场景就算错了也有办法兜底适合做LLM的“试验田”。等团队积累够RAG调优、Agent编排、模型微调的真实手感再逐步向高容错率要求的核心业务推进。2. 选型到底用闭源API还是开源模型私有化部署选型是项目里第一个让团队吵架的环节。技术负责人想私有化保障数据安全业务负责人想快速上线选商用API财务在旁边看成本预算。我的经验是这个决策不需要纠结太久因为两者之间的差距正在快速缩小但有一个判断标准特别实用——你的业务数据是否允许出域。2.1 开源闭源的决策树和真实成本账先给一张我实际做项目时用的选型参考表是我自己整理的经验值不同地区价格有差异但结构是通用的维度闭源商用API开源模型私有化部署首次接入周期1-2天1-4周取决于算力和团队经验单次调用成本按Token计费长期成本高主要是硬件折旧和电费数据安全数据出域依赖供应商承诺完全控制在企业内部性能上限通常最强顶级模型取决于显存和量化程度定制空间只能通过Prompt工程调可以微调、改结构适合场景快速验证、通用对话垂域明确、数据敏感、高频调用如果你问我要一个更简单的决策规则我会说日均调用量低于10万次闭源API通常更划算超过这个量级且数据敏感私有化部署的性价比开始凸显。这不是精确的数学公式而是我做过多次成本测算后的经验判断。闭源API的综合成本不只是调用费还包括你为合规做的数据脱敏改造、审计系统的开发成本。有个做企业知识库的客户让我印象很深。他们一开始用闭源API每个月账单在6位数而且每次大版本升级Prompt就失效需要重调。后来我们把36B参数的开源模型部署到两台8卡机器上一次性硬件投入虽然大但三个月后综合成本已经低于API费用关键是再也不用担心哪天API策略调整导致产品停摆。核心权衡逻辑是短期项目用闭源长期产品自建。2.2 参数量不是越大越好7B、14B、72B怎么选大模型领域有一个普遍误区参数越大越聪明所以我选最大的。现实是“够用”比“最强”重要得多。我自己的项目经验可以分享几个参考值7B-8B级别如Qwen2.5-7B、Llama3.1-8B意图识别、文本分类、信息抽取、简单的格式转换。单张消费级显卡即可部署延迟极低适合高频调用。14B-32B级别如Qwen2.5-14B/32B、GLM-4-9B复杂指令跟随、多轮对话、有一定推理要求的场景。需要一张48G或两张24G的显卡是“性价比甜点区”。70B级别及以上复杂推理、深度分析、长文本理解。至少需要4张以上48G显卡推理成本较高适合对答案质量极度敏感的垂域场景。这里有个反直觉的经验小模型的“调教潜力”被严重低估了。在特定垂域任务上一个经过精心微调的7B模型效果可以接近甚至超过通用大模型。因为垂域数据的高质量指令能让小模型把参数专注在特定模式上。所以选型时别只盯着参数先评估你手里的数据质量、标注能力和场景复杂度。从另一个角度看参数量选择本质是“智能密度”的权衡。最近行业里的趋势是所谓“小而专”的模型越来越能打。你有个做合同审查的场景用72B的通用模型和用基于千条高质量标注微调过的7B模型比后者在合同条款识别这个单一技能上反而可能更强、更快、更便宜。这就是垂域模型存在的意义。2.3 量化、上下文长度和推理框架的经验值选定模型后具体部署时还有几个关键参数。我直接给结论和踩坑经验量化。如果追求极致性能优先考虑4-bit量化如AWQ、GPTQ或GGUF的Q4_K_M)。4-bit下模型显存占用约为原始FP16的四分之一推理速度提升明显质量损失通常是可接受的。但注意如果任务涉及代码生成、数学推理、长文档复核建议至少保留6-bit或8-bit。另外我自己用的习惯是跑一批测试集做量化前后对比别拍脑袋决定。对比维度包括关键指标是否变化、生成格式是否稳定、长文本下是否更容易“胡说八道”。上下文长度。开头和结尾最容易被模型重视中间部分容易“迷失”。所以长文档场景务必配合“引用溯源”强迫模型在回答中引用原文片段既能缓解幻觉也方便用户复核。还有一个小技巧上下文窗口不是越长越好过长的输入会让生成质量下降因为注意力被分散了。对大多数场景4K到8K的输入足够除非是做文档级分析。推理框架。通用推荐vLLM吞吐量高、兼容性好。需要注意vLLM对显存的管理策略比较激进建议关闭自动显存分配手动设置gpu-memory-utilization为0.85-0.9更稳定。轻量场景可以考虑Ollama或llama.cpp胜在部署简单。如果是超大并发生产环境需要做张量并行和流水线并行时可考虑TensorRT-LLM它针对NVIDIA显卡有更深的优化但配置复杂度也更高。3. RAG让模型“用数据说话”的完整工程链路RAG检索增强生成几乎是目前把LLM落地到企业知识库、智能客服、文档问答场景的必选方案。但很多团队以为RAG就是“向量数据库Prompt拼装”结果做出来的效果不如直接用搜索引擎。原因很简单RAG的坑不在架构而在各种细节的串联。3.1 文档解析和切分的那些细节RAG链路的第一步是知识库数据准备也是决定效果上限的一步。这里最大的坑是“格式丰富陷阱”。很多团队拿到一堆PDF就急着灌进向量库结果答案质量惨不忍睹。真实场景中我会按这样的优先级处理源文档优先拿原始电子文档Word、Markdown、HTML比拿PDF去解析强一个数量级。PDF优先用带文本层的不要用扫描件。扫描件需要OCR而OCR对表格、公式、多栏排版的识别错误会传导到RAG检索阶段。表格结构尽量转成Markdown表格或HTML表格转成纯文本后列对齐信息丢失检索效果明显变差。切分策略上我总结的规律是固定窗口切分是最差方案虽然它最省事。固定按512个字切把一段完整的业务逻辑拦腰截断检索时就找不准。更好的做法是“按语义结构切分”——先按文档的标题层级H1、H2、H3分块块内如果太长再结合段落和句子边界处理。块与块之间保留一定重叠通常50-100个字符防止边界处语义断裂。关于chunk大小给一组经验值面向“定位型问答”问某个具体数值、条款的chunk建议256-512个字符面向“综述型问答”总结某章节内容的chunk建议1024-2048个字符。这不是死标准你要根据实际检索结果的命中情况反复调。还有个小窍门chunk里可以手动加上“标题链路”比如“某合同/第三章/违约责任/第三款”让模型能理解这个chunk在整体结构中的位置大幅度提升回答准确性。3.2 Embedding模型选择和混合检索策略向量化模型是RAG的另一个关键组件。这个领域变化非常快我的建议是放弃“追求SOTA”的心态专注三个要素领域适配度、向量维度、中文本地化支持。领域适配度是指模型对你业务领域文本的理解能力。通用Embedding模型在财经、法律、医疗这些专业术语密集的领域表现都不算好。如果你所在的行业比较垂直建议用行业语料对Embedding模型做二次训练这个技术叫“领域自适应对比学习”实现起来比微调LLM简单但收益非常显著。向量维度和索引性能相关维度越高越占内存检索越慢但通常效果越好。看你的数据规模百万级以下512维够用几百万到千万级考虑256维或加降维。索引方式上绝大多数场景用HNSW分层导航小世界就够配置M16、efConstruction100起步检索时efSearch设到检索量级的合理范围。但我必须强调纯向量检索撑不起生产级RAG。正式项目一定要做混合检索——向量检索捕捉语义相似BM25或全文检索捕捉关键词命中。现实情况是很多用户问的是代码标识符、型号、编号、人名这类“字面精确匹配”的信息语义相似的向量检索反而找不到。混合检索再把两部分结果用RRF倒数排名融合合并实测下来的效果每一次都比纯向量检索好。3.3 重排最容易被忽视却最值钱的一步我发现很多团队做RAG到混合检索就停了直接把Top-K结果丢给大模型。这导致了一个尴尬检索召回了正确相关内容但因为答案在第三四位前面的噪音干扰了模型最终输出并不理想。解法就是加一个重排模型Reranker。重排模型的原理说起来简单——把检索回来的几十条候选重新按相关度精排一遍。但它的价值巨大因为粗排向量检索追求的是效率精排重排追求的是准确度。我实测过的典型场景里加一个重排模型首位命中率能提升20到30个百分点这个提升幅度在NLP任务里非常可观。实操上注意几点。重排模型的输入通常是“查询文档”对计算量比向量模型大不要用来跑全库检索只处理粗排后的Top-50结果就好。生产环境可以把它单独部署到GPU上加一层缓存相同的查询直接命中。重排模型同样有领域适配问题如果你的业务术语很专业考虑在领域数据上微调重排模型。当前中文场景里有不少开源重排模型选择标准是看它在你要用的领域数据上的表现而不是刷榜分数。3.4 RAG效果调优的“三板斧”如果你的RAG问答效果还不满意按这个顺序排查90%的问题能解决第一板斧看召回质量。先在库里搜索一个你确定有标准答案的问题看相关chunk有没有被召回。没召回问题在切分或Embedding召回了但不对问题在重排。这一步可以借助向量检索界面直接观察Top-K结果不用反复调用完整链路。第二板斧看上下文组织。召回对了但模型答不上来大概率是Prompt里给模型的上下文太乱。我的做法是把召回结果按相关度排序附上文档来源标签在Prompt中明确告诉模型“优先依据带[高相关]标签的内容回答内容冲突时说明冲突”。给模型一条清晰的使用逻辑比堆砌更多片段更有效。第三板斧看答案评估。用一套固定的测试集持续回归。测试集至少100条真实用户问题覆盖正常问法、模糊问法和刁钻问法。每次调参后跑一遍看正确率变化。不要凭感觉认为“这次效果好像变好了”要用数据说话。4. Agent别急着给产品加“自主决策”Agent是LLM应用里听着最性感、落地最容易翻车的话题。所谓Agent本质是让模型作为“大脑”根据目标自主调用外部工具、规划步骤和执行动作。这个方向确实能解决很多复杂任务但我的态度很明确先在受控环境里跑通工具调用再谈自主规划。4.1 工具调用的工程化实现细节大多数Agent框架LangChain、Dify、Coze等底层原理一致把外部功能封装成“工具”每个工具有明确的名称、描述和参数Schema模型根据用户指令选择工具并回填参数程序收到参数后执行真实逻辑。这里面最容易忽略的是“工具描述”的质量。很多团队写工具描述极度敷衍比如“获取天气”。模型是靠描述理解工具的它不知道这个工具能干什么、参数怎么填、什么场景下用。好的工具描述应该长这样“获取指定城市当前天气情况支持中文城市名和经纬度坐标返回内容包括温度、湿度、风力和降水概率适用于用户询问天气、出行建议、穿衣建议时调用”。描述越准确模型选对工具的概率越高。参数Schema同样要精细。类型要严格integer就是integer别填成string、必填项要明确、取值范围要给枚举或正则约束。实际环境中很多工具调用失败都是参数非法导致的这不是模型笨是你在Schema设计上就给错误留了门。4.2 ReAct模式的两条安全红线当下Agent任务规划的主流范式是ReAct——让模型先思考Reason再行动Act循环进行。这种模式在演示Demo里非常酷模型可以自己拆解任务逐条调用工具最后汇总结果。但在生产环境里有两个安全红线必须提前设防。第一个是动作白名单。模型能调用的工具必须经过严格审批默认最小权限。比如你做智能家居的AIoT agent模型可以控制灯光、空调、窗帘但绝不能让模型有权限执行“删除用户配置”“修改安全密码”这类高风险动作。白名单机制要在产品架构层做硬约束不能只靠Prompt告诉模型“你小心一点”——LLM的指令遵循能力在多轮复杂对话里会下降你依赖它的自觉就等着出事。第二个是流程步数上限。给Agent的整个任务循环设一个最大步数比如10步超过就强制停止并切换到人工兜底。这是防模型进入死循环的关键保险。我见过一个真实案例Agent要查一个订单状态调了查询工具发现查不到于是反复重试、改写参数、调用关联工具总共跑了40多步产生了大量无效调用和延迟。设置步数上限后这种场景会在可控范围内自动停止用户体验反而更好。4.3 Agent的“确定性”改造预设流程为主、自由规划为辅如果你现在要设计一个面向真实用户的Agent产品我的建议是别一上来就追求“完全自主”尽量采用“预设流程为主、自由规划为辅”的混合模式。具体做法是把高频场景固化成流程模板。比如客服场景里的“退款流程”第一步收集订单号第二步验证订单状态第三步核对退款原因第四步确认退款金额。每一步都绑定特定的工具调用模型不需要自行规划只需要按模板一步步执行每步执行完校验结果。这种设计下的出错面非常小因为流程是确定的模型只是在流程里做填参和判断。对于流程模板覆盖不到的长尾场景再开放模型自由规划但设置更严格的安全护栏和人工审核节点。这样做的好处是高频场景稳定可靠长尾场景保留灵活性整个产品给人“聪明但靠谱”的体验。市面上真正成功的Agent产品基本都是这个路子。那些动不动就“你随便说我自己规划”的产品秀完Demo后往往留下一地鸡毛。5. 垂域数据的准备与微调什么时候该动模型本身很多团队做垂域LLM第一反应是“我要微调”。但我的经验是至少一半的垂域场景靠RAG就能解决不需要微调。微调是高成本、高风险、不可逆的动作应该在RAG和Prompt工程都证明不够之后才考虑。5.1 先判断要不要微调三种必须微调的情况就我的实践经验有三种情况是值得做微调的其他情况请先回去优化RAG。第一种是输出格式和风格有硬性要求。比如你的产品要求模型必须按企业标准化格式输出报告固定章节结构、固定措辞风格、特定术语表达。这种“格式刚性”需求光靠Prompt很难稳定满足微调模型在这方面很有效。第二种是领域知识与表达习惯差异巨大。比如中医问诊场景、航空维修场景、企业内部审批场景这些领域的语料分布和通用互联网语料差异太大模型的领域词汇表达完全不在线。用几万条高质量领域数据做微调模型在领域内的流畅度和准确性能有质的提升。第三种是推理链路需要模仿特定专家路径。比如法律条款分析专家会先看案件事实再匹配法律条文再分析既往判例最后给出结论。这种分步骤的推理过程可以做成“思维链”数据微调让模型学会这套分析路径。5.2 垂域数据准备质量比数量重要一个数量级垂域微调最核心的是数据准备。很多数据团队的做法是到处爬数据凑够几十万条再开始训练。这个思路说实话不太对。有效的垂域数据应该有几个特征。第一是“指令-回答”对齐明确。不要只准备一堆领域文档然后期望模型从中“感悟”要明确构造大量“你问什么-模型该答什么”的配对样本。第二是覆盖边界案例。模型犯错常常因为没见过“不该这么做”的例子准备一些困难样本、易错样本模型才能学会边界在哪。第三是去重和清洗非常关键。重复数据会让模型过拟合噪声数据会让模型学到错误模式。关于数据量我的经验参考是不要少于5000条高质量指令对不要超过5万条SFT阶段。少于5000条模型学不到稳定的领域模式超过5万条且质量一般收益会明显递减甚至开始出现灾难性遗忘——模型变得只会垂域任务通用能力反而下降了。数据质量的重要性怎么强调都不过分。我见过用8000条精选数据和用8万条网爬数据微调出的模型前者的效果明显更稳定因为精选数据里的每个样本都是经过人工校验的。5.3 微调之后别忘了评测和回归微调最容易被忽视的是评测环节。很多团队微调完拿几条测试数据试一下觉得“效果不错”就上线了。这是非常危险的。我建议微调项目必须建一套三层评测体系。第一层是领域能力评测——用你准备的测试集检查在垂域任务上的准确率、召回率是否符合预期。第二层是通用能力回归——用一套通用能力基准常识问答、数学计算、代码生成、逻辑推理测试确保模型没出现明显的灾难性遗忘。第三层是安全性测试——用对抗样本、恶意Prompt、越狱攻击等评测集确认模型在加入垂域知识后没有变得更容易被诱导输出不安全内容。三层评测都通过后再考虑灰度上线。上线后还要持续收集badcase定期打标、补充数据、做增量训练。垂域模型不是一个“训练一次用一年”的东西它是需要持续运营的资产。6. 落地工程实践推理成本、迭代节奏和评估体系前五节讲的都是模型和应用层最后一节聊聊真正上生产时那几个容易被忽视的工程问题。这几件事决定你的LLM功能能不能长期稳定跑下去而不只是“演示能跑通”。6.1 推理成本到底怎么算不只是GPU价格很多团队核算推理成本只盯着GPU采购或租赁价格这是明显不够的。真实生产环境里推理成本由四部分组成计算资源成本、延迟成本用户体验变差导致的流失、运维成本监控、告警、模型更新、数据成本RAG链路中知识库的维护更新。计算资源这块有个很实用的优化手段用模型路由Routing把简单请求和复杂请求分流。做一个轻量级意图分类器识别“简单问候、关键词查询、格式转换”这类基础请求直接走小模型或预设模板不需要上大模型只有真正复杂的请求才路由到满血版大模型。这个优化最多能省下80%左右的推理成本而且响应速度更快。此外不要忽视Prompt缓存、KV Cache复用这类工程优化。同一个高频问题在短时间内被反复问到Prompt前缀其实是一样的通过语义缓存直接命中结果不用每次都跑一次模型推理。这些优化在规模上来后效果非常明显但需要你在架构设计阶段就留好接口后期再加比较痛苦。6.2 迭代节奏小步快跑别憋大招LLM领域的迭代速度和传统软件工程完全不同。模型一个季度就出一代Prompt的技巧几个月就可能过时。如果你的团队用“六个月一次大版本”的节奏来做LLM功能等你上线时用的可能已经是上一代技术。我的经验是建立两周一个迭代周期的节奏。每个周期做四件事收集badcase、评估现有方案的效果短板、针对短板做Prompt优化或RAG调参或数据补充、灰度发布并继续收集badcase。这个循环看着平淡但坚持三个周期以后产品效果会有肉眼可见的提升。原因很简单LLM产品的效果优化是一个逐步逼近的过程数据反馈驱动的迭代效率远高于一次性设计的效率。迭代时要注意变更管理的规范性。Prompt的每次改动都要记录版本模型的每次替换都要跑完整回归。我在项目里吃过亏有一次升级了Embedding模型没跑回归结果所有旧文档没重新向量化检索全部走偏用户在线上搜什么都相当于全库扫描。这种事故其实是完全可以避免的。6.3 建立可量化的评估体系没有度量就没有优化最后这一点我想多说两句。LLM产品最常被吐槽的一点是“效果说不清楚”。业务方问“这功能到底行不行”你只能说“感觉还行”。这种状态对项目非常不利——你无法证明自己的价值也无法说服团队继续投入。所以从第一天起就要建评估体系。核心是三类指标效果指标回答准确率、召回率、幻觉率、性能指标首Token延迟、总响应时间、吞吐量、商业指标用户留存、任务完成率、客服转人工率。效果指标需要人工标注或LLM-as-Judge辅助评估性能指标靠监控系统采集商业指标接产品数据分析。LLM-as-Judge是一种用大模型来给模型回答打分的评估方式实测下来和人工评估的相关性很高可以大大降低评估成本。具体做法是构造一个评估Prompt把原始问题、模型回答、参考答案一起丢给一个强模型让它输出1到5分的评分和理由。需要定期校验评估模型和人工评分的一致性防止评估模型“口味漂移”。有了这套评估体系你的每次优化都变成了可验证、可量化、可复盘的动作。它不会直接提升模型效果但它是你后续所有优化工作的基石。我做过近十个LLM落地项目凡是从第一天就建立评估体系的项目上线后的迭代质量都明显优于凭感觉优化的团队。这不是玄学是工程方法论的力量。我个人做了这么多LLM落地项目后最深的体会是这个领域虽然变化快但只要把场景定位、数据链路、评估闭环和成本结构这四件事想清楚不容易跑偏。模型会有更替框架会有更迭但围绕真实业务场景持续打磨确定性、降低不确定性的思路会一直是落地的核心。如果这篇文章能帮你的项目少走一步弯路那就很值了。