大模型应用七种方法：从提示词工程到量化部署的实战指南

很多人第一次看到“七种大模型方法”这个说法，会以为是要聊七个不同的模型。其实在我参与过的项目里，真正决定交付效果的并不是模型本身，而是使用模型的方法。同一个底座模型，你可以用提示词让它写文案，用函数调用替用户下单，用检索增强回答私域知识问题，也可以靠微调改变它的表达风格。这七种方法，本质上是一条从“轻”到“重”的完整工具链，也是我做技术选型时最常用的决策框架。

这篇文章不打算讲太多理论，我会把七种方法逐一拆开：它们解决什么问题、核心原理是什么、上手时最容易被忽略的细节，以及我踩过之后想告诉你的坑。内容适合三类人：刚开始接触大模型开发的工程师、在给业务做技术选型的产品经理，以及团队里需要把关方案的技术负责人。

先提醒一句：七种方法不是让你全用。一个项目用得越多，链路越长，问题越难查。最好的方案往往是“先轻后重，用到为止”。下面我先给你一张总览图，然后再一个一个展开。

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要特别小心，长文本和数学推理场景的损失往往比想象中明显。

8.3 部署架构里的三件套

我的典型部署架构很简单：最外层是业务网关，负责鉴权、限流、路由；中间是模型推理服务，加载量化权重，配置并发和超时；旁边是向量库，负责RAG召回。部署时三个重点：

• 最大序列长度要根据业务收敛，不要默认开到最大，否则请求一多就会显存溢出。
• 请求超时时间要设得比模型延迟的P95高一截，避免偶发包导致大量重试。
• 热点问题要做语义缓存，相同问法直接命中缓存，能省掉大量重复推理费用。

8.4 上线之后：量化模型最容易踩的坑

量化上线后我遇到过两类经典问题。一类是换了一个量化版本，输出格式悄悄变了，下游解析率下降，查了很久才发现是量化导致概率分布改变。所以我要求，量化版本的变更也要走回归测试。另一类是长上下文输入下，模型经常忽略中段信息，这其实是量化加剧了注意力衰减。我的应对是：把关键信息放在上下文开头或结尾，实在不行就缩短上下文长度。

8.5 运维指标才是质量真相

部署不是终点。我盯的指标是：请求延迟分布、每请求消耗的上下文量、重试率、格式化失败率、上下文超长比例。格式化失败率如果突然升高，往往不是模型变笨了，而是上游提示词改了，或者检索回来的文档格式变了。指标能告诉你什么时候该动系统的哪一部分，而不是靠用户投诉来发现问题。

这套方法我用了挺长时间，也反复调整过顺序。现在最深的体会是：方法本身不神秘，难的是判断什么时候该用、什么时候该停。我见过很多项目，一开始就上智能体，结果链路太长、问题层出不穷；反而是先用提示词和结构化输出跑通，再逐步加RAG和工具，最后才考虑微调，过程要顺利得多。

如果你现在正要开始一个大模型项目，我的建议是：先想清楚你要解决的是哪种约束失效，再选最轻的方法，用到它顶不住时再加一种。没有一套万能方法，但把这七种方法按轻重缓急排好，你就能用更低的成本，得到更可控的结果。希望这些经验能帮你少走几段弯路。