在过去的一年中，LLMs 的表现已经“足够好”可以应用于现实世界。LLMs 改进的速度，加上社交媒体上的大量演示，将推动预计到 2025 年 AI 投资达到 2000 亿美元。LLMs 的广泛可用性，让每个人，而不仅仅是机器学习工程师和科学家，都能在他们的产品中构建智能。虽然构建 AI 产品的门槛已经降低，但要创建那些不仅仅是演示效果好的产品，仍然充满挑战。

我们已经总结了一些关键但常常被忽视的经验和方法，这些方法通过机器学习得出，对于开发基于 LLMs 的产品至关重要。了解这些概念可以让你在无需机器学习专业知识的情况下，相对于大多数同行获得竞争优势！在过去的一年里，我们六个人一直在基于 LLMs 构建现实世界的应用。我们意识到有必要将这些经验教训汇总在一起，分享给整个社区。

我们来自不同的背景，并在不同的角色中工作，但我们都亲身经历了使用这项新技术带来的挑战。我们中的两个人是独立顾问，帮助许多客户将 LLM 项目从初始概念变成成功的产品，见证了决定成败的模式。我们中的一人是研究人员，研究机器学习和 AI 团队的工作方式以及如何改进他们的工作流程。我们中的两个人是应用 AI 团队的领导者：一个在科技巨头公司，另一个在初创公司。最后，我们中的一人教授了数千人学习深度学习，现在致力于让 AI 工具和基础设施更易于使用。尽管我们的经历不同，但我们对所学经验中的一致性感到震惊，并且惊讶这些见解没有得到更广泛的讨论。

我们的目标是将这本指南打造成围绕 LLMs 构建成功产品的实用手册，借鉴我们的亲身经验，并引用业界的例子。过去一年中，我们亲自动手实践，获得了宝贵的教训，很多时候是通过艰难的方式学到的。虽然我们不敢自称代表整个行业，但在这里我们分享了一些建议和经验，供任何构建 LLMs 产品的人参考。

这项工作分为三个部分：战术、运作和战略。这是其中的第一部分，深入探讨了使用大语言模型 (LLM) 的战术细节。我们分享了关于提示设计、设置检索增强生成、应用流程工程以及评估和监控的最佳实践和常见陷阱。

在本节中，我们分享了大语言模型核心组件的最佳实践，包括提高质量和可靠性的提示设计、评估输出的策略、改进基础的检索增强生成理念等。我们还探讨了如何设计人类参与的工作流程。

提示设计

我们建议在开发新应用时从提示设计开始。它的作用既容易被低估也容易被高估。被低估是因为正确的提示技术使用得当可以带来显著效果。被高估是因为即使是基于提示的应用也需要大量的工程工作才能运行良好。

如何最大化利用基本提示技巧

有几种提示技巧在各种模型和任务中都能显著提高性能：n-shot 提示与上下文学习、链式思维提示，以及提供相关资源。

通过 n-shot 提示进行上下文学习的核心思路是给大语言模型 (LLM) 提供一些示例，这些示例展示了任务要求，并引导模型输出符合预期。一些提示：

• 如果 n 过低，模型可能会过度依赖这些特定示例，影响其泛化能力。一般来说，n 应该不小于 5，甚至可以达到几十个。

• 示例应能代表预期输入的分布。如果您正在构建一个电影摘要生成器，请包含不同类型的样本，比例大致与实际情况相符。

• 不一定要提供完整的输入输出对。在很多情况下，仅提供期望输出的示例就足够了。

• 如果您使用支持工具的大语言模型，您的 n-shot 示例也应包括您希望智能体使用的工具。

在链式思维 (CoT) 提示中，我们鼓励大语言模型在返回最终答案之前解释其思维过程。可以把它看作是给模型提供一个草稿本，这样它就不必全部在记忆中完成。最初的方法是简单地在指令中添加“让我们一步一步思考”这个短语。然而，我们发现使链式思维更具体，通过添加一两句额外的说明，可以显著降低幻觉率。例如，当要求大语言模型总结会议记录时，我们可以明确步骤，例如：

• 首先，在草稿本上列出关键决策、后续事项和相关负责人。

• 然后，检查草稿本中的细节是否与记录一致。

• 最后，将关键点综合成一个简洁的摘要。

最近，关于这种技术是否像人们认为的那样有效，有一些质疑 。此外，对于使用链式思维进行推理时具体发生了什么，也存在许多争论。无论如何，这种技术在可能的情况下值得尝试。

提供相关资源是一种强大的方法，可以扩展模型的知识库，减少幻觉，并增加用户的信任。通常通过检索增强生成 (RAG) 实现，向模型提供它可以直接在响应中使用的文本片段是一种关键技术。在提供相关资源时，仅仅包含它们是不够的；还需要告诉模型优先使用这些资源，直接引用它们，并在资源不足时提到这一点。这些有助于让智能体的响应基于一组资源。

输入输出结构化

将输入和输出进行结构化可以帮助模型更好地理解输入，并返回可以可靠集成到下游系统的输出。为输入添加序列化格式能够提供更多关于上下文中 tokens 之间关系的线索，为特定 tokens 提供额外的元数据（如类型），或将请求与模型训练数据中的类似示例联系起来。

例如，很多关于编写 SQL 的问题在互联网上都以指定 SQL 模式开始。因此，针对文本到 SQL 的有效提示应该包括结构化的模式定义。

结构化输出不仅具有类似的目的，还简化了与系统下游组件的集成。Instructor和 Outlines在结构化输出方面表现良好。（如果您正在导入 LLM API SDK，请使用 Instructor；如果您正在导入 Huggingface 进行自托管模型，请使用 Outlines。）结构化输入可以清晰地表达任务，并且格式类似于训练数据，从而增加了获得更好输出的概率。

在使用结构化输入时，请注意每种大语言模型都有自己的偏好。Claude 偏好 xml，而 GPT则偏好 Markdown 和 JSON。使用 XML 时，您甚至可以通过提供 response 标签来预先填充 Claude 的响应。

messages=[{"role": "user","content": """Extract the <name>, <size>, <price>, and <color> from this product description into your <response>.<description>The SmartHome Mini is a compact smart home assistant available in black or white for only $49.99. At just 5 inches wide, it lets you control lights, thermostats, and other connected devices via voice or app—no matter where you place it in your home. This affordable little hub brings convenient hands-free control to your smart devices.</description>""" }, {"role": "assistant","content": "<response><name>" }]

编写小而精的提示词，专注做好一件事

在软件开发中，有一个常见的反模式叫“万能对象”，即一个类或函数承担了所有的功能。提示词也有类似的问题。

提示词通常从简单开始：几句指令、几个例子，就可以使用了。但随着我们不断提高性能，处理更多边缘情况，复杂性就会增加。更多的指令，多步骤推理，几十个例子。不知不觉中，我们原本简单的提示词变成了一个包含 2000 个 token 的复杂体。而更糟的是，它在处理常见和简单输入时的表现更差！

我们在保持系统和代码简单的同时，也应该保持提示词的简洁。与其为会议记录摘要器提供一个包罗万象的提示词，我们可以将任务分解为几个步骤：

• 提取关键决策、行动项和负责人，并转化为结构化格式

• 检查提取的细节与原始记录的一致性

• 从结构化细节中生成简明的摘要

通过这样分解，我们将单一提示词拆分成了多个简单、专注且易于理解的提示词。这样，我们可以分别迭代和评估每个提示词的效果。

精心设计你的上下文信息

重新思考并挑战你关于需要向智能体发送多少上下文信息的假设。像米开朗基罗雕塑一样，不是不断堆砌上下文，而是剔除多余的部分，直到雕塑显现。RAG 是一种流行的收集所有可能相关信息块的方法，但你在提取必要信息时做了什么？

我们发现，将最终发送给模型的提示词——包括所有的上下文构建、元提示词和 RAG 结果——放在一张空白页上阅读，确实有助于重新思考上下文。通过这种方法，我们发现了冗余、自相矛盾的语言和糟糕的格式。

另一个关键的优化点是上下文的结构。你的文档堆积对人类没有帮助，不要以为对智能体就有用。仔细考虑如何结构化你的上下文，以突出其各部分之间的关系，并尽量简化提取过程。