5月28日，六位一线AI工程师和创业者Eugene Yan、Bryan Bischof、Charles Frye、Hamel Husain、Jason Liu 、Shreya Shankar，在oreilly网站上公开分享了，他们对过去1年LLM（大语言模型）开发的心得总结。

这篇干货长文，在ycombinator开发者社区引起了广泛讨论。总结分为3个部分：战术篇、运营篇和战略篇。今天，主要介绍的是战术篇。包含了提示词、RAG（检索增强生成）、微调、Agent与工作流、评估与监测等部分。
放心，这篇不是技术文，而是所有AI从业者和使用者都能够读懂的实操文。有网友评价，这是LLM少有的“实操性见解”，非常值得一读。

以下是干货全文：前言这是使用大语言模型 （LLMs） 进行开发的激动人心的时刻。在过去一年里，LLMs已经变得“足够好”，可以用于各种开发应用。随着LLMs的迭代，加上社交媒体上一系列的demo演示，预计到2025年将推动人工智能产业约2000亿美元的投资。LLMs已可以广泛使用，允许每个人，而不仅仅是机器学习（ML）工程师和科学家，将AI开发应用到他们的产品中。虽然开发AI产品的门槛已经降低，但开发超越Demo演示之外的有效产品，仍然是一项看似困难的工作。我们已经确定了一些关键但经常被忽视的经验教训和方法，这些经验和方法论由机器学习提供信息，这些经验和方法对于开发基于LLMs的产品至关重要。了解这些概念可以让您在不需要ML专业知识的情况下获得与该领域大多数其他人的竞争优势！在过去的一年里，我们六个人一直在LLMs之上开发现应用程序。我们现在意识到，有必要将这些经验教训总结到一个地方，以造福开发者社区。
我们来自不同的背景，担任不同的角色，但我们都亲身体验了使用这项新技术所带来的挑战。我们中的两位是独立顾问，他们帮助众多客户将LLM项目从最初的概念转变为成功的产品，看到了决定成功或失败的模式。我们中的一位是研究ML/AI团队如何工作以及如何改进他们的工作流程的研究人员。还有两个人是应用人工智能团队的领导者：一个在科技巨头，一个在初创公司。还有一个人已经向数千人教授了深度学习，现在致力于使人工智能工具和基础设施更易于使用。尽管我们的经历不同，但我们对获得经验总结中一贯的主题感到震惊，并且我们惊讶地发现这些见解没有被更广泛地讨论。我们的目标是使这成为一个实用指南，围绕LLMs开发成功的产品，借鉴我们自己的经验，并引导成为行业的实例。在过去一年里，我们一直在亲自动手，并获得宝贵的经验教训。虽然我们并不声称代表整个行业，但在这里，我们分享了一些建议和教训，供任何使用LLMs开发产品的人参考。
总结分为三个部分：战术、运营和战略。这是三部分中的第一部分，它深入探讨了与LLM合作的战术细节。我们分享了关于提示词、设置增强检索生成、应用流程工程以及评估和监控的最佳实践和常见陷阱。无论你是LLM开发的从业者，还是使用AI的爱好者，这一部分都是为你写的。请期待接下来的运营和战略部分。
准备好了吗？Let's go.
1、提示词篇很多开发者都陷入了一个误区：以为设计一个涵盖一切的“终极提示词”就能完美解决问题。
就像过去软件开发中也有希望一个类或函数可以完成所有事情的误区。
实际情况恰恰相反，随着需求的复杂化，这样的Prompt会越来越臃肿，性能反而每况愈下。
那么正确的做法是什么呢？提示词也应该像代码一样保持简洁，以会议记录总结场景来说，可以分解为以下步骤：

• 将关键决策、待办事项和执行者提取为结构化格式

• 检查提取的详细信息与原始会议记录的一致性

• 从结构化详情生成简明摘要

通过拆分，每个提示词都简单、突出重点且易于理解，更重要的是接下来可以单独迭代和评估每个提示词。
比如思维链鼓励AI在最终回答之前写下思维过程，除了“一步一步思考”之外，还可以用一些技巧显著降低幻觉。

还以会议记录总结场景为例，迭代后的提示词示例为：

- 首先，在草稿中列出关键决策、待办事项和相关执行者。- 然后，检查草稿中的细节是否与文字记录相符。- 最后，根据要点合成简洁的总结。

在提示词方面，作者们还提出了更多具体经验。
对于给大模型提供示例的上下文学习：

• 提示词中的示例数量追求≥5（也不要害怕用上几十个）。太少会让模型过度遵循特定示例、损害泛化能力。

• 示例应该反映预期的输入分布。比如做电影剧情总结，示例中不同类型电影的比例大致应与实践中期望看到的相同。

• 不一定需要提供完整的输入-输出对。在许多情况下，只有输出的示例就足够了。

• 如果所用的大模型支持工具调用，则示例也应包含希望AI使用的工具。

对于结构化输入输出：

• 优化上下文结构，让模型更容易理解和处理。单纯打包一堆文件人类看着头疼，AI看着也费劲。

• 只保留必要信息，像雕刻艺术家一样剔除冗余、自相矛盾和格式化错误。

• 每个大模型都有自己的偏好，Claude更喜欢xml格式，GPT系列更喜欢Markdown和JSON。

比如给Claude的提示词，甚至可以用xml tag来预填充输出模板。

2、RAG（检索增强生成）篇2.1 不要忘记关键词搜索基于Embedding的RAG演示很多，让人们容易忘记信息检索领域数十年来积累的经验。
作者认为向量检索无疑是强大的工具，但不是全部。虽然擅长捕获高级语义相似性，但它们可能难以处理更具体的关键字，比如人名、首字母缩略词或者ID。
不要忘记传统的关键词匹配（如BM25算法），在大多数情况下，混合关键字匹配和向量搜索效果最好：

先匹配最明显的关键词，再对同义词、上位概念和拼写错误做向量查询，以及多模态向量查询。

2.2 RAG输出的质量取决于检索文档的质量具体来说，检索文档的质量又取决于几个因素。
第一个也是最明显的指标是相关性。与传统推荐系统一样，检索到的项目的排名对大模型输出产生重大影响，要衡量这种影响，可以试试打乱顺序并观察大模型行为变化。
第二个是信息密度。如果两份文档同样相关，应该选择更简洁、无关细节更少的那个。
最后是信息的详细程度，附加的详细信息可以帮助大模型更好地理解。2.3 优先RAG，而不是对新知识微调RAG和微调都可让大模型掌握新知识并提高特定任务的性能。那么，应该优先选择哪一个呢？
微软一篇论文比较RAG与无监督微调（又叫持续预训练），发现对于新知识RAG性能始终优于微调。

除了改进性能之外，RAG容易更新而且成本更低。如果知识库中发现错误，RAG方法只需简单删除有问题的文档即可。
RAG还可以给文档权限提供更细粒度的控制，确保每个用户只能访问自己有权限的文档，不会泄露信息。2.4 长上下文不会让RAG过时首先，即使上下文窗口达到一千万tokens，仍然需要一种方法来选择要输入模型的信息。
其次，除了简单大海捞针评估之外，还没有看到令人信服的数据表明模型可以在如此大的上下文进行有效的推理。如果没有良好的检索和排名，干扰因素可能淹没模型，甚至可能用完全不相关的信息填满了上下文窗口。
最后还有成本问题，ransformer的推理成本随上下文长度二次增长，过度依赖长上下文可能不划算。
3、微调篇当最巧妙的提示词设计也无法完成一些任务时，可能就需要考虑微调了。虽然微调可能是有效的，但它会带来巨大的成本。必须注释微调数据、执行微调和评估模型，并最终自行部署模型。因此，请考虑较高的前期成本是否值得。
作者们的经验是：

• 如果提示词已完成了90%的任务，那么微调可能不值得投资。

• 如果确定要微调，可以考虑合成数据或开源数据集，降低人工收集注释数据的成本。

4、Agent与工作流最成功的Agent开发者可能也是工程师团队的管理者，因为给AI制定计划的过程和管理初级员工的方式类似。我们给人类新手明确的目标和具体的计划，而不是模糊的开放式指示，对Agent也应该这样做。4.1 优先考虑确定性工作流程Agent被期待动态对用户请求做反应，但随着执行步数增加，失败的可能性指数增加，并且从错误中恢复的机会很小。
一种有前途的方法是使用Agent系统来生成确定性计划，然后以结构化、可重复的方式执行这些计划，好处包括：

• 生成的计划可以作为提示词中的少数样本，或微调数据。

• 使系统更加容易测试和调试，失败可以追溯到计划中的具体步骤。

• 生成的计划可以表示为有向无环图 (DAG)，相对于静态提示词，它更容易理解和适应新情况。

4.2 多样化输出不止提高温度如果任务需要输出的多样性，比如根据用户之前购买过的产品推荐新产品，简单增加大模型的温度参数可能会产生问题。
如果温度太高，可能会生成不存在的产品，甚至输出乱码。
其他增加输出多样性的方法包括：
最简单的是调整提示词内的元素顺序，打乱用户历史购买记录的顺序，就可能产生显著差异。
还可以在上下文中保留前几轮的输出，并要求大模型避免重复最近推荐过的产品。
另一个策略是改变提示词的措辞，比如“选择用户喜欢经常使用的产品”和“选择用户可能会推荐给朋友的产品”。
5、评估与监测大模型的输入和输出是任意文本，要完成的任务是多种多样的。尽管如此，严格且深思熟虑的评估仍至关重要。5.1 从真实的输入/输出样本中创建基于断言的单元测试作者建议创建由生产中的输入和输出样本组成的单元测试，并基于至少3个指标测试。
3个指标是实践中总结出来的，更少可能表明任务没有充分定义，或过于开放。
这些单元测试应该由工作流的任何更改触发，无论是编辑提示词、通过RAG添加新上下文还是其他修改。5.2 大模型当裁判可能起作用，但不是万能的作者认为，让最强大的模型当裁判、给其他模型的输出打分，用于定性比较优劣可能有用，但具体输赢的幅度就没什么参考价值了。

• 不要让大模型在量表上对单个输出进行评分，而是提供两个选项，要求选择更好的一个，这往往会带来更稳定的结果。

• 提供的选项顺序可能会影响结果，为了缓解这种情况，请将每个成对比较进行两次，每次交换顺序。

• 在某些情况下，两种选择可能同样好。因此允许大模型宣布平局，这样就不会武断地选一个胜者。

• 使用思维链：要求大模型在给出最终偏好之前解释其决定，可以提高评估的可靠性，还可以让更小的模型获得与大模型类似的结果。

• （这部分流程通常处于并行批处理模式，思维链带来的额外延迟并不造成问题。）

• 大模型往往偏向于较长的回答，为减少这种情况，请确保成对的回答长度相似。

5.3 “实习生测试”如果将提示词（包括上下文）作为一项任务，交给相关专业的普通大学生，他们能成功吗？需要多长时间？
如果大学生都做不到，就该考虑如何给大模型提供更丰富的上下文资料了。
如果根本无法通过改进上下文来解决这个问题，那么这就是对当代大模型来说太难的任务。
如果大学生能做到，但需要一段时间。可以尝试降低任务的复杂性。分解任务，或某些方面是否可以更加模板化。
如果大学生能做到，而且很快，但大模型不行。那么就该深入研究大模型反馈的数据了。尝试找到失败的模式，让模型在输出之前或之后解释自己。5.4 过分强调某些指标可能影响整体著名的古德哈特定律表示，“当一项指标成为目标时，它就不再是一项好指标”。
比如针对长上下文的“大海捞针”测试最早是网友提出的，迅速成为行业通用方法之后，就很容易针对性优化、刷榜。
更好的指标可能正是复杂的实际任务，比如“给定一个小时的会议记录，大模型能否总结出关键决策、待办事项和相关负责人”。
这项任务更切合实际，超越了死记硬背的范畴，还考虑到了解析复杂讨论、识别相关信息和归纳总结的能力。
在总结中强调事实一致性可能会导致摘要不那么具体（因此不太可能与事实不一致），也可能不那么相关。
反之，如果强调写作风格和口才，则可能导致更多花哨的话术，从而造成与事实不符的情况。5.5 LLMs甚至会在不应该返回输出时返回输出大模型经常会在不应该生成输出的情况下生成输出。可能是无害但无意义的输出，也可能是更严重有害输出。
例如，当被要求从文档中提取特定属性或元数据时，大模型可能会自信地返回不存在的结果。可以尝试让大模型回答“不适用”或“不知道”，但也并非万无一失。
虽然谨慎的提示工程可以在一定程度上起作用，但还应辅之以强大的“护栏”机制，以检测和过滤/重新生成不受欢迎的输出。
例如，OpenAI提供了一个内容过滤API，可识别不安全的响应，如仇恨言论、自残或性内容。同样，还有许多用于检测个人身份信息 (PII) 的软件包。这样做的好处之一是，”护栏”在很大程度上与场景无关，因此可广泛应用于特定语言的所有输出。
此外，通过精确检索，如果没有相关文档，系统也可以确定地回答 “我不知道”。
在实际应用中，最好持续记录输入和输出，以便进行调试和监控。5.6 幻觉很难彻底解决与安全问题不同，幻觉可能很难被发现。
根据作者们从大模型供应商那里了解到的情况，要将幻觉率降低到2%以下是非常困难的，即使是在摘要等简单任务中也是如此。
为了解决这个问题，可以将提示工程（生成的上游）和事实不一致护栏（生成的下游）结合起来。
对于提示词工程，思维链等技术可以让大模型在最终返回输出之前解释其推理，从而帮助减少幻觉。然后，可以应用事实不一致护栏来评估摘要的事实性，并过滤或重新生成。

以上是技术篇的干货全文。除了技术篇外，昨天也刚刚发布了运营篇，围绕数据、模型、产品、团队发展等四个话题展开。对于LLM从业者来说，非常值得一读。