诊断大语言模型输出问题：何时该使用提示词、检索或微调
一种以症状为导向的方法，用于判断弱人工智能功能是否需要更好的提示、检索层或微调，以及为何用事实数据训练模型反而会适得其反。
任何人工智能功能的初始版本产生的结果都未必完全准确。你有三种方法可以解决这个问题：修改指令、为模型提供其缺失的文档，或用你自己的示例对模型进行重新训练。这三种方法的成本差异巨大，从几分钟的工作量到数周的数据收集时间不等，且各自能解决不同类型的故障。本指南会引导你从症状出发选择合适的方法，从而避免在根本不需要解决的问题上浪费数周时间。
把模型视作一名能力出色的新员工
一个实用的心智模型是将模型想象成第一天入职的优秀员工。他们对整个世界有相当丰富的了解，但对你的公司却一无所知：不了解你的产品、政策，也不清楚你的团队希望怎样的回复风格。他们会犯错，就像任何有才华的新人一样。
你可以通过三种方式帮助那位新员工。你可以更好地向他们说明情况，把参考资料交给他们，或者送他们去参加培训课程。这三种方法分别对应提示、检索和微调，且成本从低到高排列。关键在于根据问题选择合适的干预方式，因此按此顺序考虑是合理的。
提示法：先重新撰写说明
始终从这里开始。提示其实就是你随请求一起发送的指示：任务内容、一两个优秀答案的示例、目标受众以及期望得到的格式。修改提示无需任何成本，只需几分钟时间。很多“人工智能表现不佳”的投诉，其实都是因为提示不够明确所致。
假设你的功能收到的回复冗长且生硬，其实无需重新训练模型。只需添加诸如“用三句话、温暖平实的口吻回复”这样的指令，再粘贴一个优秀的示例回复，通常一次迭代就能解决问题。为每个请求预先设定的这些指令被称为系统提示词；而用来展示某种回复模式的示例答案则称为少样本示例。
不过，提示词方法也有其局限性：指令无法提供模型从未见过的知识。如果新员工从未见过本季度的数据，要求他们“更精确些”也无法生成这些数据。当真正的障碍是信息缺失时，就需要采用另一种方法。
继续之前快速检查
在认定提示策略失败之前，请先确认您已经尝试过那些显而易见的改进措施：明确指定输出格式，给出至少一个具体示例，说明当答案未知时应如何处理，以及使用一小组固定的真实输入进行测试，而非仅凭一两个挑选出来的案例。没有这组固定数据，就很难判断某项改动是否真的有效。
检索：移交文件
检索增强生成技术，通常简称为RAG，能让模型在回答问题时直接访问您的文档：当前的价目表、退货政策、特定客户的订单记录等。它能弥补那些缺失的、频繁变化的或仅限于您组织内部的知识。当文档更新时，模型的回答也会随之改变，且无需重新训练。只要相关知识属于您所有、会频繁变动或需要被引用，这就是最佳选择。关于模型权重中存储的知识与回答问题时检索到的知识之间的区别，可详细了解AI记忆、上下文、嵌入向量与模型权重有何不同一文。
在面向新员工的场景中，你不再需要向他们讲解；只需提供手册，让他们在回复前查阅即可。现在他们能够回答模型训练完成很久之后发生的变化相关问题，并且能准确指出每个答案的来源。
其成本高于简单的提示词调整。你需要构建一个用于存储文档并按语义进行搜索的小型流程，这通常需要数天的工作量而非几分钟。尽管如此，它仍远比微调便宜，而且系统会随着文档的更新而保持最新状态。同时它也增加了需要维护的环节：如何分割文档、如何衡量搜索质量，以及未找到相关内容时该如何处理。
检索有其明确的界限。文档可以填补模型已知信息的空白，但不会改变模型的行为方式。将手册交给某人并不会改变他们的写作风格或判断力，这些需要通过培训来培养。
微调：让其在训练课程中学习
微调是通过大量示例对模型进行重新训练，直到某种风格或技能变得自动化。当提示词无法实现一致的行为效果，或者当你的提示词已发展成一页页规则却依然不可靠时，微调就是解决问题的手段。想象一下，在百万次对话中，每个回复都必须遵循极其特定的品牌语调且不能有任何偏差——通过数千个示例的训练，可以让这种行为成为默认状态，而无需额外指令。
人们最容易误解的一点是：微调改变的是模型的行为方式，而非它所掌握的知识。这一过程既缓慢又昂贵，需要大量示例数据，而且一旦相关事实发生变化，预先植入的任何事实信息都会立刻过时。因此不应用它来存储事实——那才是检索系统的用途。在三种方案中，微调属于训练类方法：当问题确实与行为表现相关时它非常有效，但对于那些通过更清晰的说明就能解决的问题而言则纯属浪费。如需了解这一决策的经济成本分析，可参阅微调模型与调用API的成本对比。
根据症状选择
先从一个问题入手：输出结果到底存在什么问题？
- 格式或语气有误，或者模型忽略了指令中的部分内容。这是提示词问题，需改进提示语。
- 存在事实缺失或过时情况，模型引用的版本不正确，或者需要其注明信息来源。这是知识问题，需增加信息检索功能。
- 事实本身正确，但无论如何表述请求，某种行为都无法保持一致，且需要在数千次响应中都具备稳定性。这是行为问题，可考虑进行微调。
根据症状选择对应的解决方案。还有两点容易被忽视。
各调整手段是协同而非相互冲突的
几乎所有功能都是从提示语开始的。许多系统在需要实时或私有数据时会加入检索功能，还有少数系统会为提示语无法实现的行为进行微调。通常你需要决定下一步添加哪一层功能，而非固定采用某一种方法。经过微调的模型依然需要提示语，RAG系统同样依赖指令来告诉模型如何使用它检索到的信息。
仅做到解决症状所需程度
由于这些选项的成本是从低到高排列的，因此找到第一个能解决问题即可停止。在构建任何系统之前也适用同样的逻辑：如果任务依赖于会变化的数据，那就考虑使用检索功能；如果需要以极高处理量实现某种精确行为，或许最终有必要进行微调；其他所有情况都应从提示语开始。
代价高昂的错误：通过微调来传授事实
特别需要指出的是那种试图通过微调让模型掌握某些知识的做法。这听起来像是一个严肃且需要大量工程技术的解决方案，也正是团队首先会考虑的方式。但那些不断变化的事实并不属于模型的固有习惯，而应该记录在模型可以查询的文档中。如果反其道而行之，你可能会花费数周时间去教模型一个本就错误的事实，等到产品上线时问题依旧存在，而且还无法轻易说明答案的来源。
另一个类似的陷阱是为那些实际上表述模糊的提示进行微调。如果你还没有尝试使用明确的格式化指令以及针对固定测试集的一些优质示例，那就还无法确定是否存在行为问题。
关键要点
- 先诊断再投入：弄清楚故障是出在指令、知识还是行为方面。