提示词、RAG 与微调，企业应该怎样选择？

开场问题

企业准备引入大模型时，常会遇到三个听起来都很合理的建议：把提示词写好、接入企业知识库、用自己的数据微调模型。它们似乎都能让回答更准确，却对应完全不同的问题。如果一开始就选错路线，团队可能花了不少时间，最后只得到一个昂贵而难维护的演示系统。

真正要问的不是“哪种技术更先进”，而是：当前效果不好，究竟是任务没说清、知识没提供，还是模型的行为方式不合适？找到问题来源，选择通常就不难。

提示词、RAG 与微调对应不同问题和投入的选择图解

图解：提示词解决任务表达，RAG 补充可更新的外部知识，微调改变模型的稳定行为；三者不是同一种升级路线。

核心解释

提示词、RAG 和微调，可以理解为改善 AI 表现的三个层次。

提示词是在每次任务开始前，把角色、目标、背景、步骤、限制和输出格式讲清楚。它适合解决“模型不知道这次要怎么做”的问题，例如要求模型按固定栏目总结会议、以某种口吻改写文案，或先检查数据再给结论。它启动最快，试错成本较低，但复杂提示词会越来越长，也可能因输入差异而表现波动。

RAG，即检索增强生成，是先从企业文档、制度、产品资料或业务记录中找到相关内容，再把这些内容连同问题交给模型。它适合解决“模型不知道企业内部事实”以及“知识会持续更新”的问题。知识可以单独维护，回答还能附上来源。不过，文档切分、检索质量、权限过滤和内容更新都需要工程投入。

微调是用一批经过整理的示例继续训练模型，使它更稳定地形成某种表达方式、分类习惯或操作模式。它适合解决“任务反复出现，且仅靠提示词很难保持一致”的问题，例如大量文本要按照企业特有规则分类。微调并不是把资料永久塞进模型；如果产品价格、制度条款经常变化，仍应使用可更新的数据源或 RAG。

可以用下面的顺序做判断：

主要问题	优先选择	典型场景	主要成本
任务要求和输出不清楚	提示词	摘要、改写、分析框架	设计、测试和维护提示词
缺少内部或最新知识	RAG	制度问答、产品助手、售后知识	文档治理、检索、权限与评估
行为或格式长期不稳定	微调	专有分类、固定风格、稳定结构化输出	样本制作、训练、部署和回归测试

决策时再追问四件事：知识是否频繁变化，答案是否必须给出处，任务量是否足够稳定且重复，错误后果是否需要人工把关。知识越动态、越需要引用，越偏向 RAG；任务越固定、合格示例越充足，微调才越有价值。多数企业并非三选一，而是先用提示词定义任务，再用 RAG 补充事实，确有稳定性瓶颈时才考虑微调。

生活化类比或实例

把大模型想成一位能力不错的新员工。提示词像任务单：告诉他今天要做什么、按什么格式交付。RAG 像允许他进入公司的资料室，并且只拿到与当前问题相关、本人有权查看的文件。微调则像一段集中训练，让他通过大量合格案例形成稳定的工作习惯。

例如，企业要做售后回复助手。第一步可以用提示词规定“先识别问题类型，再给处理建议，不确定时转人工”。如果模型不了解某型号的保修规则，就需要从最新售后手册中检索并引用相关条款。只有当每天都有大量相似工单，而且分类边界具有企业自己的特殊规则，团队才值得评估微调。即便进行了微调，最新保修政策仍应来自知识库，而不是依赖训练时的旧内容。

常见误区

第一，认为提示词越长越专业。过多背景会稀释重点，关键是任务、输入、边界和输出标准清楚。第二，认为接入知识库就一定准确。检索找错文档、旧版本未下线，模型仍会基于错误材料作答。第三，认为微调能消除所有“幻觉”。微调改变的是行为倾向，不能保证事实永远正确。第四，只比较一次建设费用。RAG 需要持续更新文档和权限，微调需要维护样本并在模型或业务变化后重新评估，真正应比较的是全生命周期成本。

实践建议

先选一个边界明确、能收集真实反馈的场景，建立一组包含正常、模糊和高风险问题的测试集。随后用最简单的提示词做基线，记录准确性、格式合格率、引用是否正确以及人工修改量。若错误主要来自缺知识，再建设小规模 RAG，并先解决文档版本、权限和来源展示；若知识已经充分，行为仍在大量重复任务中不稳定，再准备高质量示例评估微调。

每次只改变一个变量，并保留人工兜底。这样团队能知道效果提升来自哪里，也能在收益不足时及时停止，而不是被已经投入的技术成本绑住。