🤖我们在使用大语言模型 (LLMs) 构建产品一年中的经验总结 (第一部分）

一、提示词设计 1. n-shot 多样例在提示词中加入 5 个以上不同类型的示例，覆盖各种可能情况 2. CoT 思维链让 LLM 在输出结果之前解释其思维过程。简单的加入“让我们一步步思考”还不够好，最好是明确步骤 3. 输入输出的结构化在使用结构化输入时，请注意每种大语言模型都有自己的偏好。Claude 偏好 xml，而 GPT 则偏好 Markdown 和 JSON。 4. 编写小而精的提示词，专注做好一件事不要试图在一段复杂的中解决所有问题，尝试拆分成多个小而专注的提示词 5. 精心设计上下文信息上下文信息并非越多越好，而是要提供关键的有效信息，而不是冗余、自相矛盾和结构混乱的信息。 二、信息检索/检索增强生成（RAG） 1. RAG 输出的质量取决于所检索文档的质量所检索的信息相关性越高、信息密度越高、文档细节越丰富，检索效果越好。 2. 关键字检索同样很重要现在大部分 RAG 教程演示都是基于嵌入（Embedding），但很多应用场景关键字检索效果可能更好，最好是将嵌入和关键字结合使用 3. 优先使用 RAG 而不是微调大部分时候是不需要微调的，RAG 便宜、容易实施，并且 RAG 提供了更精细的文档检索控制。 4. 即使是模型的上下文越来越长，RAG也不会过时需要 RAG 来筛选输入模型的信息来提升上下文信息质量得到更好的结果，另外长上下文成本比较高。 三、从提示工程到工作流 1. 逐步多轮的工作流能显著提升效果将一大段复杂提示词分解为若干段短小提示词可以取得更好的效果，而多个短小提示词需要有工作流来支撑 2. 优先采用确定性工作流工作流越确定越容易管理和控制 3. 合理使用温度（temperature）参数如果希望 LLM 生成结果更加多样化，那么调高温度参数，如果希望更加确定性，则调低。 4. 不要忘记缓存对于 LLM 生成的结果，可以缓存起来，下次有相同的请求可以重用节约成本。 5. 微调有一些任务，即使是最巧妙设计的提示也无法胜任。例如，即使经过大量提示工程，我们的系统可能仍然无法返回可靠的高质量输出。如果是这样，那么可能有必要为特定任务微调模型。 如果决定微调，为了减少收集人工标注数据的成本，可以 生成并在合成数据上进行微调，或 在开源数据上引导。 四、评估与监控 1. 基于实际输入输出样本编写单元测试收集实际应用的输入输出样本，用这些数据编写测试。由于 LLM 输出存在一定的开放性，可以用一些特殊的验证方式，比如字数、句子数在范围内，比如格式是否符合要求等。 2. 用 LLM 评估 LLM 生成结果可行，但不是万能的。 3. “实习生测试”把 LLM 当成大学实习生，如果这个任务实习生能完成，那么模型是不是也可以？如果实习生都不能完成，那么是不是应该简化拆分？ 4. 过分强调某些评估指标可能损害整体性能“当一个衡量标准变成目标时，它就不再是一个好的衡量标准。” 其他还有几个评估与监控方法，不再总结，有兴趣请阅读原文。