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