很多人第一次看到“七种大模型方法”这个说法会以为是要聊七个不同的模型。其实在我参与过的项目里真正决定交付效果的并不是模型本身而是使用模型的方法。同一个底座模型你可以用提示词让它写文案用函数调用替用户下单用检索增强回答私域知识问题也可以靠微调改变它的表达风格。这七种方法本质上是一条从“轻”到“重”的完整工具链也是我做技术选型时最常用的决策框架。这篇文章不打算讲太多理论我会把七种方法逐一拆开它们解决什么问题、核心原理是什么、上手时最容易被忽略的细节以及我踩过之后想告诉你的坑。内容适合三类人刚开始接触大模型开发的工程师、在给业务做技术选型的产品经理以及团队里需要把关方案的技术负责人。先提醒一句七种方法不是让你全用。一个项目用得越多链路越长问题越难查。最好的方案往往是“先轻后重用到为止”。下面我先给你一张总览图然后再一个一个展开。1. 先看清地图七种方法的关系与选型逻辑1.1 七种方法在做同一件事约束模型大模型本身是一套概率系统给它一段文本它就会续写出看起来合理的文本。业务系统真正需要的是可靠、可信、可控的输出。七种方法每一类都在做同一件事给这个概率系统加约束。提示词工程是软约束函数调用是结构化约束RAG是内容约束微调是能力约束Agent是过程约束结构化输出是格式约束量化部署是资源约束。这个视角对我做选型非常有用。用户说“模型回答不对”我不会马上去改提示词而是先想这是什么类型的约束失效了是缺少知识还是缺少工具还是输出格式不对还是能力上限不够。搞清楚约束类型才能选对方法。1.2 快速选型对照表方法解决的核心问题落地成本见效速度适合阶段提示词工程调用方式不对低最快验证阶段函数调用模型无法操作业务系统中快系统集成检索增强生成模型不知道私域知识中快知识问答模型微调模型领域能力不够高慢规模化智能体工作流单次调用无法完成多步任务高中复杂流程结构化输出模型输出无法被下游解析低快数据对接量化部署模型太大太贵中中上线运行1.3 一个项目通常要组合三种方法我见过做客服问答的团队最开始只用提示词后来接RAG解决资料库问题再后来加函数调用对接工单系统。七种方法不是互斥赛道而是可以互相叠加的积木。但越加越复杂每加一种都要配合新的测试和监控这是代价。所以我的口诀是能用一种解决不用两种能用提示词解决不上RAG能用检索解决不碰微调。2. 方法一提示词工程——门槛最低但最吃经验2.1 提示词本质上是在划定答案空间大模型生成每个词时都会在所有候选词上算出一个概率分布。提示词的作用是用文字把概率质量集中到我们期望的区域。这也就解释了为什么同一句指令换个说法效果完全不同不是模型对你有偏见而是不同文字诱发出来的概率分布差异巨大。举个实际例子。让模型处理一段客户投诉如果只说“请总结这段投诉”得到的往往是一段泛泛的概括。如果改成“你是一名客服质检员请按问题类型、客户情绪、建议措施三个字段总结并且先用一句话概括核心诉求”输出质量会明显提升。差别不在于命令更强硬而在于你帮模型缩小了回答空间。2.2 四个我还在天天用的具体技巧角色和目标绑定给模型一个专业角色紧跟着说清楚输出目标。角色的作用是自动带入判断标准和说话方式。比如“你是法务审核人员”“你是数据分析师”“你是面向小白用户的写作助手”不同角色会让模型自动调整语气和详略。给正反例我会给一个符合预期的例子再给一个不合格的例子。模型对反例的敏感度很高“不要做成什么样”往往比“应该做成什么样”更容易学会。少样本示例不是越多越好关键是和真实输入的分布保持一致。显式要求推理步骤对逻辑判断类任务要求“先列出已知条件再逐步推导最后给结论”。这一步能让数学计算、规则判断、多条件筛选类的任务准确率提升一大截。要让模型把思考过程写出来再给最终答案。给一个“不知道”的出口在提示词里写“如果信息不足以判断请直接回复无法判断不要推测”。这是减少幻觉最廉价的方法。不要指望模型主动承认不知道你得给它一个不必编造的理由。2.3 什么时候该放下提示词提示词工程解决不了两类问题一是模型根本不知道的事实二是模型本来就不具备的能力。我不止一次看到团队在提示词里塞了一长串行业资料期望模型记住结果效用很差。资料应该走RAG能力不够应该走微调提示词更擅长的是把已有能力调度好。2.4 提示词也需要版本和回归提示词也是有bug的。我吃过亏某次为了提升效果改了开头一句角色描述结果所有输出格式全部变化下游解析直接崩了。之后我强制要求每份提示词都维护对应测试集改动前先跑回归。提示词和代码一样需要纳入版本管理。提示提示词的每次改动都要用一个固定测试集验证。不要凭“感觉变好了”就上线。3. 方法二函数调用——把模型接到业务系统的调度台上3.1 函数调用到底是什么先理解一个痛点模型只是文本生成器它本身无法查订单、改库存、发短信。业务系统里有成千上万个函数模型不知道它们的名字和参数。函数调用的思路是你把允许模型“操作”的函数清单以结构化的一张表交给模型。模型根据用户输入决定调用哪个函数返回函数名和参数我们拿这个结果去执行真实代码。这是大模型从“聊天玩具”变成“业务执行器”的关键一步。你不再只是让模型说话而是让它变成调度中心。3.2 完整流程用一段伪代码看懂# 1. 定义可用函数清单 function_schema [ { name: query_order, description: 根据订单号查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } } ] # 2. 把用户消息 函数清单一起发给模型 messages [{role: user, content: 帮我查一下订单20250101123到哪里了}] model_response call_model_with_functions(messages, function_schema) # 3. 判断模型是否要调用函数 if model_response.is_function_call(): func_name model_response.get_function_name() func_args model_response.get_function_args() # 4. 执行真实函数 result execute_function(func_name, func_args) # 5. 把结果回填给模型让它组织最终答案 messages.append({role: function, content: result}) final_answer call_model_with_functions(messages, function_schema)3.3 最容易出问题的三个点第一参数校验。模型返回的 order_id 可能是“20250101123”也可能是“订单号20250101123”。业务代码一定要做严格类型和格式校验不合法就重新让模型生成一次不要直接信。第二函数太多。当函数清单超过二十个模型选错的概率会明显上升。我的做法是先做意图分组先分到“订单类/售后类/支付类”再在对应分组里放子函数清单。把所有函数一次性塞给模型效果并不好。第三无限调用。模型可能在一次任务里连续调用几十次函数既烧资源又拖慢响应。要设定最多调用次数到达上限就停止并让用户确认。我没有做这个限制之前真的出现过模型在一个失败函数上反复重试的情况。3.4 接入函数调用之前别忽略权限与审计函数调用意味着模型可以代用户触发业务动作。如果只是查订单还好但如果是删单、退款、改权限就必须有权限校验和审批流。我的习惯是每个函数都标注权限等级模型只能看到当前用户权限允许的函数所有调用都记录日志出了问题可以回放。没有审计的函数调用迟早会出大问题。4. 方法三检索增强生成——把私域知识变成模型能取到的上下文4.1 RAG链路拆解RAG也就是检索增强生成核心是在模型回答之前先把私域知识库里的相关内容检索出来作为上下文喂给模型。经典链路如下知识文档 → 清洗与切块 → 向量化 → 写入向量库 → 用户提问 → 生成查询向量 → 召回候选 → 重排 → 拼进提示词 → 模型回答。一开始我低估了前段的重要性觉得反正有模型兜底。后来发现检索不到再好的模型也白搭。整个RAG的上限其实卡在检索这一步而不是生成这一步。4.2 切块策略不能抄固定模板最常见的做法是设定固定块大小比如256或512字。但文档结构不同切块策略也应该不同。对政策文件先按章节切再按段落切对问答型数据一条问题加一条答案整体作为一个块对代码库按函数或类切。一个原则尽量让每个块在语义上是自洽的不要把一个完整意思拦腰切断。我自己的经验是块大小在300到800字之间比较常见。太小上下文信息不足太大检索结果噪音多而且填充大量无关内容会稀释模型的注意力。最终还是要跑测试集对比不要拍脑袋定。4.3 召回和重排检索质量的关键只用向量检索会漏掉关键词精确匹配的场景。举个例子检索“苹果售后服务电话”向量结果可能返回一堆关于苹果营养价值的内容。后来我做的方案是混合检索向量召回一路关键词召回一路合并结果再用一个重排模型重新打分把最相关的几条放前面。这个“多路召回加重排”的组合是效果提升最明显的一次改动。重排模型不需要很大关键是它比向量相似度更理解“语义相关性”和“关键词命中”之间的关系。重排之后我会固定取前3到5条作为上下文而不是把召回的全部塞进去。4.4 怎么知道RAG做得好不好不要只看最终回答顺不顺。我把评估拆成两段检测评测准备20到50条真实问题人工标注每条问题对应的正确片段看召回率一般看到前5条候选。低于60%问题多半出在切块策略或嵌入模型上。生成评测只看“模型回答是否能由召回片段支撑”。片段正确但回答还是错说明提示词约束不够片段不对先修检索再谈生成。我有一个固定测试集每次改切块、换嵌入模型、改提示词都会拿它重跑。没有这个测试集你很容易被一次“看起来不错”的回答骗过去。4.5 检索到了但模型不按检索内容回答最常见的坑是“检索到了但模型自己发挥了”。解决办法是在提示词里明确写“你只能根据参考片段回答如果片段中没有答案回复‘知识库中未找到相关信息’不要使用自己的知识补充。”这一句加上去幻觉率能降一大截。注意RAG的提示词一定要给“不知道”的出口否则模型会把检索片段和自己预训练知识混在一起编。5. 方法四模型微调——把通用底座改造成团队专属的利器5.1 微调改变的是模型本身提示词、RAG都是在不改模型的前提下想办法。当任务要求的表达方式、术语体系、输出习惯已经超出通用模型的能力边界时就该微调了。典型场景把口语化的客服记录改写成标准工单、按企业固定格式生成合同摘要、用特定文风写营销物料。这些任务不是“知识不够”而是“说话方式不对”微调可以直接重塑输出风格。5.2 用LoRA把微调成本打下来全参数微调需要大量算力对大部分团队不现实。我用LoRA也就是低秩适配的次数更多。可以这样理解全参微调是把整栋房子的所有墙面重刷一遍LoRA只是往墙上钉几个挂架房子结构不动但挂东西的能力强很多。低秩适配加量化的方案又进一步压了显存占用我在消费级显卡上也能跑通亿级参数模型的微调训练。5.3 数据质量胜过一切技巧微调最重要的其实是数据。我见过有人堆了两万条数据效果反而不如别人精心清洗过的三千条。做微调数据我会注意四件事每条都是“输入加期望输出”而且要覆盖真实使用场景不要只挑好看的样本。剔除重复和互相矛盾的数据。模型学到矛盾行为就会漂移不定。混入一部分通用数据比例可以按二八或者三七来。纯领域数据很容易让模型丢掉通用能力。格式要统一。所有输出都用同样的换行和缩进模型会不知不觉学成这个格式。5.4 微调之后怎么评估别只看训练误差训练误差下降只能说明模型记住了数据不能说明任务效果变好。我的做法是准备两套测试集一套领域任务集看目标指标和格式正确率另一套通用能力抽查集防止微调后模型在基础问答上退化。训练过程中隔一段时间就采样跑一次记录指标变化。有一次我发现领域指标在涨但通用能力掉得厉害就是因为领域数据比例开太高后来调回比例才恢复。这个回调动作没有通用测试集根本发现不了。5.5 我现在的选型原则我遵循的顺序是提示词然后RAG然后函数调用最后才微调。能靠前面方法解决的就不要轻易微调。微调最大的成本不在于训练本身而在于数据维护和持续迭代。一旦微调上线数据会变、业务会变每变一次都要重新走一遍数据清洗和训练评估流程这是一个长期包袱。6. 方法五智能体工作流——让模型自己跑完整个任务闭环6.1 智能体的本质是函数调用加上循环单个函数调用解决的是“一步操作”智能体解决的是“一个需要多步操作的任务”。它把“观察、思考、行动、再观察”做成一个循环模型先看当前状态决定调用哪个工具看到结果后再决定下一步。有点像让实习生去办一件事办一步回来说一步你不断纠偏直到完成。6.2 值得做智能体的任务特征我判断一个需求适不适合做成智能体主要看三点是否需要访问多个工具、是否存在多个决策分支、是否可以容忍一定的失败重试。适合的例子自动生成一份行业日报要查数据、写摘要、排版从一堆合同里提取关键条款并发送给相关人员。不适合的例子只需要一步固定处理的任务直接写死流程脚本反而更稳、更省。6.3 落地一个可上线的智能体我分成四块任务规划器决定下一步做什么这是大脑。工具集领域相关的函数调用这是手脚。记忆模块把中间结果、工具返回、用户补充信息都存起来避免每轮都重新问一遍。护栏机制限制最大循环次数、限制危险操作权限、设置超时时间。护栏不是可选项我在早期吃过亏智能体连续调用同一个查询接口几十次把后端服务打挂了。6.4 多智能体协作好看但不一定好用多智能体是热门话题但我的建议是“先单兵后团队”。多个智能体之间要传递信息、统一语境、协调优先级非常容易失控。我的经验是先把一个智能体跑到稳定再考虑拆角色。只有任务真的需要不同视角时比如一个负责检索、一个负责分析才值得拆开。绝大多数任务一个智能体带几个工具就够。6.5 没有trace就不要上线智能体最大的工程问题不是聪明程度而是可观测性。我每次排查线上问题第一步都是看完整轨迹每一轮它思考了什么、调用了什么工具、工具返回了什么、为什么决定结束。没有这套日志出了问题只能靠猜。所以从开发第一天起就要把轨迹埋好确保每轮决策都留痕。7. 方法六结构化输出——让模型吐数据而不是吐作文7.1 业务系统只认字段不认作文让大模型回答一段自然语言很容易但把它接进业务系统就需要固定字段。举个例子从客服对话里抽取用户诉求需要输出用户ID、问题类型、紧急程度、建议动作每一项都有枚举值和必填约束。如果模型输出的是自由文本就算它意思全对下游系统也没法直接用。结构化输出就是为了解决这个问题。7.2 最稳的做法让模型以函数调用方式输出结构我在方法二里已经讲过函数调用的机制这里想单独强调一点函数调用返回的参数本身就是一张结构表。把抽取任务伪装成一个“调用某个函数”的动作模型就会被这张结构表约束得很老实。比如定义“extract_customer_request”这个函数参数里有问题类型枚举值是投诉、咨询、维修、退换货紧急程度枚举值是高、中、低再有一个字符串型的摘要。模型在这种约束下很少会自由发挥。对比用自然语言提示词要求“请输出JSON”函数调用方式对格式的约束更硬跑偏概率更低。7.3 二次校验必须做别信模型输出模型输出得再规范也不能保证每一次都合法。我的铁律是模型给出的结构化结果必须经过代码层的严格校验。校验包括JSON能不能解析、必需字段齐不齐、枚举值合不合法、字符串长度超不超限。不合法就带着校验错误信息重新让模型生成一次连续两次不合法就不要硬试了转人工或给出兜底结果。省掉这一步线上迟早出现脏数据。很多团队说“模型输出老是变”其实不是模型乱来而是后端缺少强校验和重试机制。注意结构化输出必须配二次校验。模型是生成器不是协议校验才是系统可靠性的兜底。7.4 结构化输出不是所有任务都适合如果你需要的是创意文案、开放问答那强制结构化只会帮倒忙。结构化输出的适用场景非常清晰抽取、分类、工具参数、数据转换。判断标准很简单下游是需要把这个输出当成数据用还是只需要给人看。需要就上结构化只需要给人看自由文本更自然。8. 方法七量化与部署——把大模型塞进生产环境8.1 量化是什么意思大模型的权重默认用FP16或FP32存储占显存、跑得慢。量化是把权重从高精度映射到低精度比如INT8或INT4用更少的位来表示权重换来更小的体积和更快的推理。代价是效果会有一点点损失。这里可以用一个照片类比高清图转成压缩过的图片肉眼看起来差别不大但文件小很多如果压得太狠细节就会糊。8.2 不同精度的直观比较我常用下面这个对比表来决策具体数值会随模型变化但量级可以参考精度模式显存占用推理速度效果损失适合场景FP16基准基准无实验、效果优先INT8约降一半明显提升很小大多数线上服务INT4约为FP16的三分之一到四分之一更快可见但通常可接受追求低成本和低延迟我的建议是上线前先在FP16下跑通效果基线换INT8后对比关键指标损失可接受再上线。INT4要特别小心长文本和数学推理场景的损失往往比想象中明显。8.3 部署架构里的三件套我的典型部署架构很简单最外层是业务网关负责鉴权、限流、路由中间是模型推理服务加载量化权重配置并发和超时旁边是向量库负责RAG召回。部署时三个重点最大序列长度要根据业务收敛不要默认开到最大否则请求一多就会显存溢出。请求超时时间要设得比模型延迟的P95高一截避免偶发包导致大量重试。热点问题要做语义缓存相同问法直接命中缓存能省掉大量重复推理费用。8.4 上线之后量化模型最容易踩的坑量化上线后我遇到过两类经典问题。一类是换了一个量化版本输出格式悄悄变了下游解析率下降查了很久才发现是量化导致概率分布改变。所以我要求量化版本的变更也要走回归测试。另一类是长上下文输入下模型经常忽略中段信息这其实是量化加剧了注意力衰减。我的应对是把关键信息放在上下文开头或结尾实在不行就缩短上下文长度。8.5 运维指标才是质量真相部署不是终点。我盯的指标是请求延迟分布、每请求消耗的上下文量、重试率、格式化失败率、上下文超长比例。格式化失败率如果突然升高往往不是模型变笨了而是上游提示词改了或者检索回来的文档格式变了。指标能告诉你什么时候该动系统的哪一部分而不是靠用户投诉来发现问题。这套方法我用了挺长时间也反复调整过顺序。现在最深的体会是方法本身不神秘难的是判断什么时候该用、什么时候该停。我见过很多项目一开始就上智能体结果链路太长、问题层出不穷反而是先用提示词和结构化输出跑通再逐步加RAG和工具最后才考虑微调过程要顺利得多。如果你现在正要开始一个大模型项目我的建议是先想清楚你要解决的是哪种约束失效再选最轻的方法用到它顶不住时再加一种。没有一套万能方法但把这七种方法按轻重缓急排好你就能用更低的成本得到更可控的结果。希望这些经验能帮你少走几段弯路。