大模型选型与智能体落地实战：从能力分层到微调部署的完整指南

1. 大模型全景的观察坐标系从参数竞赛到能力分层聊大模型这件事最容易掉进去的坑就是一上来就比参数、比榜单、比谁家又发了新版本。我做了几年模型落地越来越觉得这种比法没什么意义——就像评价一个员工不能只看学历评价一个大模型也不能只看参数量和跑分。真正要建立的是一个观察坐标系让你在面对任何一个新模型时能快速判断它适合干什么、不适合干什么、值不值得投入时间。1.1 为什么参数越大越强是个过时的判断标准2023年那会儿大家确实习惯用参数量来粗暴划分模型档次百亿级是入门千亿级是主流万亿级是顶尖。但到了现在这个逻辑已经站不住了。一个70B的模型经过高质量数据训练和对齐在很多具体任务上能打得过某些千亿级模型。原因很简单——训练数据的质量、配比和清洗程度对最终能力的影响已经超过了单纯的参数规模。我自己做过一个对比测试用同一个代码生成任务分别跑一个130亿参数但经过大量代码数据专项训练的模型和一个700亿参数但通用训练为主的模型。结果前者在代码补全和bug修复上的表现明显更稳后者虽然知识面更广但写出来的代码经常有微妙的逻辑错误。这个经验告诉我选模型的第一原则是看它的训练数据偏向什么领域而不是看它有多大。另一个容易被忽略的点是推理成本。参数越大部署成本越高响应延迟越大。如果你要做的是一个高频调用的客服智能体用一个千亿级模型可能每次响应要等好几秒用户体验直接崩掉。这时候一个经过领域微调的中等规模模型反而是更务实的选择。1.2 能力分层的四个维度知识、推理、生成、对齐我习惯把大模型的能力拆成四个维度来看这样在选型时能更有针对性。知识维度指的是模型知道什么。这取决于训练数据的覆盖范围和时效性。有些模型在通用知识上很强但一问到某个垂直行业的专业术语就开始胡编。这时候就需要通过RAG检索增强生成或者微调来补。推理维度指的是模型能不能想清楚。这体现在多步逻辑推理、数学计算、代码调试等任务上。推理能力强的模型你给它一个复杂问题它能拆解成步骤一步步推推理能力弱的直接就给你一个似是而非的答案。生成维度指的是模型写得好不好。这包括语言流畅度、风格一致性、格式遵循能力。有些模型知识很全但写出来的东西像机器翻译有些模型知识一般但文笔极佳适合做内容创作。对齐维度指的是模型听不听话。这包括指令遵循、安全边界、拒绝不当请求的能力。对齐做得好的模型你说用JSON格式输出它就真的只输出JSON不会给你加一堆解释。这四个维度很难有一个模型全都顶尖。所以实际工作中我经常是组合使用用一个推理强的模型做规划用一个生成强的模型做内容输出用一个对齐好的模型做最终审核。1.3 开源与闭源的真实差距在哪里很多人喜欢争论开源和闭源谁更强我觉得这个问题问错了。应该问的是在你的具体场景下哪种更适合。闭源模型的优势在于开箱即用、持续更新、通常有更好的对齐和安全保障。你不需要操心部署、不需要调参、不需要维护推理集群。缺点是API调用有成本、数据要出境、无法深度定制、随时可能涨价或下线。开源模型的优势在于可以本地部署、数据完全可控、可以自由微调、没有调用次数限制。缺点是需要自己搞定推理环境、需要自己做好对齐、版本更新要自己跟进、效果通常比同级别的闭源模型差一截。我自己的做法是原型验证阶段用闭源API快速跑通确认需求后再评估是否需要用开源模型做私有化部署。这样既省了前期的时间又避免了过早投入基础设施。2. 主流模型谱系拆解谁在做什么做得怎么样这一部分我不打算做成一个排行榜而是按模型的设计哲学和应用场景来分类。因为同一个模型在不同任务上的表现可能天差地别单纯排名没有意义。2.1 通用对话模型日常任务的主力军通用对话模型是大多数人接触大模型的第一站。这类模型的特点是知识面广、语言能力强、能处理多种类型的任务。它们适合做日常问答、文案撰写、信息总结、翻译润色、头脑风暴。在这个类别里不同模型有各自的性格。有些偏向严谨保守回答问题时喜欢加限定条件有些偏向开放创造给出的答案更有想象力。这个差异主要来自训练数据和对齐策略的不同。我实际用下来的感受是如果你要做的是面向终端用户的产品选一个对齐好、拒绝率低的模型比选一个跑分高的模型更重要。因为用户不会去看你的模型在某个榜单上排第几他们只关心问问题能不能得到有用的回答。一个动不动就说我不能回答这个问题的模型跑分再高也没用。另外要注意的是上下文窗口。现在主流模型基本都支持几万到几十万token的上下文但支持和用好是两回事。我测试过在超长上下文中让模型找一条特定信息很多模型会出现中间遗忘的现象——开头和结尾的信息能记住中间的就模糊了。所以如果你要处理长文档最好还是做分段处理加检索不要指望模型一次性吃下整本书。2.2 推理增强模型复杂任务的攻坚手推理增强模型是这两年最值得关注的方向。这类模型在回答前会先思考——生成一段内部的推理过程然后再给出最终答案。这个机制让它们在数学、编程、逻辑推理等任务上的表现有了质的飞跃。我拿一个实际案例来说明差异。我让一个普通对话模型和一个推理增强模型同时做一道需要多步计算的题目某公司第一季度营收增长15%第二季度在第一季度基础上下降8%第三季度恢复增长12%问第三季度相对第一季度的增长率是多少。普通模型直接给了一个错误答案因为它跳过了中间步骤。推理增强模型则一步步算设第一季度为100第二季度为92第三季度为103.04最终得出增长3.04%。但推理增强模型也有代价响应时间更长、token消耗更大。因为它要先生成推理过程再生成答案。所以不是所有任务都需要用推理模型。简单的信息提取、格式转换、文本润色用普通模型就够了。只有当你需要多步推理、复杂计算、代码调试时推理模型的优势才体现出来。还有一个实际使用中的技巧推理模型的思考过程本身是有价值的。你可以把它的推理链拿出来检查看它是在哪一步出了错。这对于调试和优化prompt非常有帮助。2.3 代码专用模型程序员的第二双手代码专用模型是落地效果最明显的方向之一。这类模型在大量代码数据上训练过能理解多种编程语言的语法和惯用法可以做代码补全、bug修复、单元测试生成、代码解释、重构建议。我用代码模型最频繁的场景是写那些我知道怎么写但懒得写的代码。比如一个标准的CRUD接口、一个数据清洗脚本、一个正则表达式。这些任务不需要创造性但需要准确性和速度代码模型正好擅长。但代码模型也有明显的边界。它不擅长的是理解你项目的整体架构、处理跨文件的复杂依赖、做需要业务背景知识的决策。我踩过的一个坑是让模型帮我重构一个模块它给出的代码单独看没问题但和项目里其他模块的接口对不上。后来我学乖了给代码模型提供足够的上下文——相关的接口定义、数据结构、调用示例它的输出质量会高很多。另一个实用技巧是用测试驱动的方式让代码模型工作。你先写好测试用例然后让模型生成能通过测试的代码。这样你不需要逐行审查它的输出只要跑测试就行。这个方法我用了大半年效率提升非常明显。2.4 多模态模型从文字到图像的跨越多模态模型能同时处理文字和图像输入有些还能生成图像。这个方向的应用场景很广图片描述、图表理解、文档OCR、视觉问答、UI截图转代码。我实际用得多的是文档理解场景。比如给模型一张发票照片让它提取金额、日期、供应商信息。这个任务传统OCR也能做但多模态模型的优势在于它能理解版面结构知道哪个数字是金额、哪个是税号不需要你写复杂的模板规则。但多模态模型目前还有明显的短板。空间推理能力普遍偏弱——你问它图中左边的物体和右边的物体哪个更大它经常答错。细粒度识别也不够稳——两张相似的图表它可能分不清哪张是柱状图哪张是折线图。所以如果你的场景对精度要求很高多模态模型目前还只能做辅助不能完全替代人工审核。3. 从模型到智能体能力落地的关键一跃模型本身只是一个大脑要让它真正干活还需要给它配上手脚——工具调用、记忆管理、任务规划。这就是智能体Agent要解决的问题。3.1 智能体的核心组件不只是套个壳很多人以为智能体就是大模型加几个API调用这个理解太浅了。一个完整的智能体系统至少包含四个核心组件规划模块负责把用户的高层目标拆解成可执行的步骤。比如用户说帮我分析这份销售数据并生成报告规划模块要拆成读取数据、清洗数据、计算指标、生成图表、撰写报告。工具模块负责执行具体操作。这包括代码执行器、搜索引擎、数据库查询、文件读写、API调用等。工具的设计直接决定了智能体的能力边界。记忆模块负责管理上下文。短期记忆保存当前对话的状态长期记忆保存跨会话的知识。记忆管理做得好不好直接决定了智能体能不能处理复杂的长周期任务。反思模块负责检查自己的输出。这包括结果验证、错误纠正、策略调整。没有反思模块的智能体一旦某一步出错就会一路错到底。我搭过几个智能体最大的体会是规划模块和反思模块是最难做好的。工具调用和记忆管理有成熟的框架可以用但规划和反思需要大量的prompt工程和测试。3.2 工具调用的设计原则少而精稳而准给智能体配工具不是越多越好。我见过有人给智能体配了二十几个工具结果模型经常选错工具或者在一个简单任务上反复调用不同的工具。我的经验是工具数量控制在5到8个每个工具的功能要清晰、边界要明确。比如搜索和浏览网页就是两个容易混淆的工具不如合并成一个。再比如读文件和写文件可以分开但读CSV和读JSON就没必要分开让模型自己判断格式就行。工具的描述也很关键。描述要写清楚这个工具做什么、什么时候用、输入输出是什么格式。我习惯在工具描述里加一两个使用示例这样模型选错工具的概率会低很多。还有一个容易忽略的点工具调用失败的处理。网络超时、API限流、返回格式异常这些情况都要有兜底逻辑。我的做法是让智能体在工具调用失败时先重试一次如果还失败就换一个替代方案实在不行就向用户报告并请求指示。3.3 记忆管理让智能体记住该记住的智能体的记忆管理是个技术活。全记住不行——上下文窗口有限而且无关信息会干扰推理。全忘掉也不行——用户上次说过的偏好、之前任务的结果这些都需要保留。我的做法是分层记忆工作记忆当前任务的上下文包括用户输入、工具返回结果、中间推理步骤。这部分放在prompt里任务结束就清掉。会话记忆当前对话的历史摘要。不是逐字记录而是提炼关键信息。比如用户偏好简洁的回答风格用户正在处理一个电商项目。长期记忆跨会话的持久化知识。这通常存在外部数据库里需要时通过检索调取。实际使用中会话记忆的摘要质量最关键。摘要太简略会丢失重要信息太详细又浪费上下文。我一般会让模型在每轮对话后生成一个三到五句话的摘要包含用户的核心诉求、已达成的共识、待解决的问题。3.4 智能体的评估怎么判断它到底行不行评估智能体比评估模型难得多。模型评估可以用标准测试集但智能体的行为是动态的、多步的、依赖环境的。我用的评估方法是场景回放准备一批真实的任务场景每个场景包含初始状态、用户输入、预期结果。然后让智能体跑这些场景记录每一步的决策和输出。评估指标包括任务完成率、步骤效率用了多少步、工具调用准确率、错误恢复能力。这个方法的优点是能发现很多隐藏问题。比如我测过一个客服智能体在标准测试集上表现很好但场景回放时发现它在处理退款请求时会先查订单、再查支付记录、再查退款政策三步才能给出答复。而实际上用户提供订单号后一步就能查到所有信息。这就是规划模块的效率问题。另一个重要的评估维度是边界处理。用户提出一个智能体能力范围之外的需求时它是会胡编一个答案还是会诚实地说我做不到建议你这样做后者才是可用的智能体。4. 微调与部署把通用模型变成自己的模型通用模型再好也不可能完全贴合你的业务需求。微调就是让模型入乡随俗的过程。4.1 什么时候该微调什么时候不该微调不是万能的。我见过太多人一上来就说我要微调一个模型结果花了几周时间效果还不如好好写prompt。该微调的场景你需要模型掌握一种特定的输出格式比如公司内部的报告模板你需要模型理解大量行业术语和内部黑话你需要模型模仿一种特定的语言风格你有大量标注数据且通用模型的表现确实不够好。不该微调的场景你只是想让模型知道一些新知识用RAG更合适你的数据量很少少于几百条你的需求用prompt就能解决你没有评估微调效果的能力。我的判断标准很简单先用prompt和RAG试如果效果能达到要求的80%就不微调。如果怎么调都差得远再考虑微调。因为微调的成本不只是训练本身还包括数据准备、效果评估、版本管理、后续维护。4.2 微调数据的准备质量比数量重要得多微调数据的质量直接决定微调效果。我见过有人拿几万条脏数据去微调结果模型学会了各种错误模式。数据准备的核心原则多样性覆盖各种输入情况包括边界情况和异常输入。一致性输出格式要统一不能一会儿用JSON一会儿用YAML。准确性标注必须正确错误的标注比没有标注更糟糕。平衡性各类别的样本数量要均衡避免模型偏向某一类。我一般会准备三份数据训练集80%、验证集10%、测试集10%。训练集用于训练验证集用于调参测试集用于最终评估。测试集绝对不能参与训练过程否则评估结果没有意义。数据量方面对于指令微调几百到几千条高质量数据通常就能看到明显效果。对于领域适应可能需要几千到几万条。但记住一千条精心准备的数据胜过一万条随便凑的数据。4.3 微调方法的选择全量、LoRA还是其他微调方法主要有几类全量微调更新模型的所有参数。效果最好但计算成本最高需要大量显存。适合有充足计算资源且对效果要求极高的场景。**LoRA低秩适应**只更新一小部分参数。计算成本低效果接近全量微调是目前最常用的方法。适合大多数场景。QLoRA在LoRA基础上做了量化进一步降低显存需求。适合显存有限的场景但训练速度会慢一些。我自己的选择逻辑是先用LoRA跑一版看效果。如果效果不够再考虑全量微调。大多数情况下LoRA就够了。而且LoRA的另一个好处是你可以同时训练多个LoRA适配器每个对应不同的任务推理时动态切换。4.4 部署方案从单机到集群的渐进路线模型部署的方案选择取决于你的调用量和延迟要求。单机部署适合调用量不大的场景。一张消费级显卡就能跑起中等规模的模型。我用一张24G显存的卡跑过一个130亿参数的量化模型响应速度完全够个人和小团队使用。多卡部署适合调用量较大的场景。通过张量并行或流水线并行把模型拆到多张卡上。这需要更复杂的配置但能支撑更高的并发。集群部署适合企业级应用。需要考虑负载均衡、自动扩缩容、监控告警、灰度发布等。这通常需要专门的运维团队。我的建议是从单机开始根据实际压力逐步扩展。不要一上来就搞集群那是给自己找麻烦。大多数应用场景单机加一个请求队列就能撑住。部署时还要注意量化。把模型从FP16量化到INT8或INT4能大幅降低显存需求代价是轻微的效果损失。我实测下来INT8量化的效果损失基本可以忽略INT4会有一些可感知的下降但在很多场景下仍然可用。5. 评估与选型怎么找到最适合你的那个模型评估大模型是个技术活也是个经验活。榜单可以参考但不能全信。5.1 公开榜单的参考价值与局限公开榜单如各类LLM排行榜的价值在于快速了解一个模型的整体水平。如果一个模型在所有榜单上都排在前列那它大概率不会太差。但榜单的局限也很明显榜单任务和实际任务有差距。榜单上的题目通常是标准化的、有明确答案的而实际业务中的问题往往是模糊的、需要多步推理的。榜单可以被优化。有些模型会针对榜单任务做专项训练导致榜单分数虚高但实际使用体验并不好。榜单不反映成本和延迟。一个榜单第一的模型可能推理成本是第十名的十倍响应速度是五分之一。在实际产品中成本和延迟往往比那一点效果差异更重要。我的做法是用榜单做初筛把候选范围缩小到三五个模型然后用自己的实际任务做测试。这个测试集不需要很大几十条真实数据就够但必须是你业务中真实遇到的问题。5.2 构建自己的评估集少而精的原则构建评估集的关键是代表性。我一般会从实际业务中抽取以下几类样本高频任务日常处理最多的请求类型占评估集的50%。困难任务模型容易出错的情况占30%。边界任务异常输入、模糊需求、多意图混合占20%。每条样本包含输入、期望输出、评估标准。评估标准可以是精确匹配、关键词覆盖、人工评分等。评估时我习惯用盲测把不同模型的输出混在一起不标注来源让评估者打分。这样能避免品牌偏见。5.3 成本、延迟与效果的三角权衡选模型本质上是在成本、延迟、效果之间找平衡。维度高要求场景中等要求场景低要求场景效果推理增强模型通用大模型小模型/量化模型延迟可接受秒级响应需要亚秒级响应需要毫秒级响应成本可接受较高API费用需要控制成本需要极低成本我的经验是先确定延迟和成本的硬约束再在这个范围内选效果最好的模型。比如一个实时客服场景延迟要求是500毫秒以内那千亿级模型基本就排除了只能在中等规模模型里选。还有一个容易被忽略的点不同任务可以用不同模型。比如意图识别用一个小模型答案生成用一个大模型最终审核再用一个中等模型。这种组合策略往往比单一模型效果更好、成本更低。5.4 实际选型中的几个反直觉发现做了这么多选型有几个发现和直觉不太一样小模型在特定任务上可以超过大模型。一个经过领域微调的70亿参数模型在它擅长的任务上表现可以超过没有微调过的千亿模型。模型版本更新不一定带来提升。有些模型的新版本在通用能力上提升了但在你的特定任务上反而下降了。所以每次模型更新都要重新跑评估集不能想当然。prompt的影响可能比模型选择更大。同一个模型好的prompt和差的prompt效果差距可能超过换一个模型。所以在纠结选哪个模型之前先把prompt优化到位。多模型投票有时比单模型更稳。让三个不同的模型分别回答然后取多数一致的结果。这个方法在分类任务上特别有效能显著降低错误率。6. 落地实践中的经验与教训这一部分分享一些我在实际项目中踩过的坑和总结的经验都是文档里不会写的。6.1 从Demo到生产那些Demo阶段不会暴露的问题Demo阶段一切都很美好但一上生产就各种问题。我总结了几类典型情况并发问题。Demo时一个人用生产时一百个人同时用。模型推理是计算密集型的并发上来后响应时间会急剧上升。解决方案是加请求队列和限流或者部署多个推理实例做负载均衡。输入长度问题。Demo时输入都是短文本生产时用户可能粘贴一整篇文档。超出上下文窗口的输入需要截断或分段处理这个逻辑要在应用层做好。异常输入问题。用户会输入各种奇怪的东西空字符串、超长文本、特殊字符、多语言混合。这些都要有兜底处理不能让模型直接崩掉。成本失控问题。Demo时调用量小成本不敏感。生产时如果没做好缓存和限流账单可能会吓死人。我一般会设置每日调用上限和单用户调用频率限制。6.2 提示词工程的实战心得提示词工程不是玄学但确实有很多细节需要注意。结构化提示词比自然语言提示词更稳。用明确的段落划分角色定义、任务描述、输入数据、输出要求、示例。这样模型不容易漏掉关键信息。少样本示例要精选。给模型看几个示例它就能理解你要的格式和风格。但示例不是越多越好三到五个就够了。示例要覆盖不同的情况包括边界情况。输出格式要明确指定。如果你要JSON就明确说输出JSON格式包含以下字段...。不要指望模型自己猜。让模型先思考再回答。对于复杂任务在prompt里加一句请先分析问题再给出答案效果会好很多。这个技巧对推理类任务特别有效。迭代优化。提示词不是一次写好的要反复测试和调整。我一般会准备一个测试集每次修改提示词后跑一遍看效果是提升还是下降。6.3 安全与合规的边界处理做AI应用安全合规是绕不过去的。我的原则是宁可保守不可冒险。输入过滤对用户输入做基本的安全检查过滤明显不当的内容。输出审核对模型输出做二次审核可以用另一个模型或者规则引擎来检查。日志记录记录所有请求和响应便于事后审计和问题排查。但要注意用户隐私敏感信息要脱敏。边界声明在产品中明确告知用户AI的能力边界不要过度承诺。人工兜底对于高风险场景保留人工审核和干预的通道。6.4 团队协作与迭代节奏大模型应用的开发不是一个人的事需要算法、工程、产品、运营多方协作。算法团队负责模型选型、微调、评估。工程团队负责部署、接口、监控。产品团队负责需求定义、交互设计、效果验收。运营团队负责数据标注、用户反馈收集。迭代节奏上我建议小步快跑。不要憋一个大版本而是每周或每两周发一个小版本快速收集反馈快速调整。大模型应用的效果优化是个持续过程没有一劳永逸的方案。最后分享一个我自己的习惯每次遇到模型表现不好的案例都记录下来。这些案例是最宝贵的优化素材。积累一段时间后你会发现很多问题是有共性的解决一个就能解决一类。