构建大型语言模型（LLM）产品的实战指南

  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿进展吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与全球数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个机会，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

使用大型语言模型（LLM）进行开发的时代令人兴奋。过去的一年中，LLM在实际应用中的表现已经达到“足够好”的水平，并且每年都在变得更好且更便宜。再加上社交媒体上的一系列演示，到2025年，预计将有2000亿美元的投资进入人工智能领域。此外，提供者的API使LLM变得更加易于访问，使得不仅是机器学习工程师和科学家，任何人都可以将智能融入他们的产品。然而，尽管构建AI的门槛已经降低，但创建真正有效的产品和系统——不仅仅是演示——仍然非常困难。

我们过去一年一直在构建过程中，发现了许多棘手的问题。虽然我们不敢说代表整个行业，但我们希望分享我们的经验，以帮助你避免我们犯过的错误，并加速你的迭代。这些经验分为三个部分：

战术层面：提示、RAG、流程工程、评估和监控的实践。不管你是构建LLM的从业者，还是周末项目的爱好者，这部分内容都是为你而写。

操作层面：产品发布的组织和日常关注点，以及如何打造高效团队。针对希望可持续且可靠地部署产品的产品/技术领导者。

战略层面：长远的宏观视角，带有明确观点，如“在产品市场契合前不使用GPU”和“关注系统而非模型”，以及如何迭代。专为创始人和高管们撰写。

我们的目的是提供一份实际指南，帮助你成功构建LLM产品，基于我们的经验，并引用行业中的案例。

准备好深入探讨了吗？让我们开始吧。

战术层面：使用LLM的具体操作

在本部分中，我们分享了新兴LLM堆栈核心组件的一些最佳实践：提高质量和可靠性的提示技巧、评估策略、改进基础生成的检索增强生成（RAG）思路等。我们还将探讨如何设计人机协作工作流。尽管技术仍在快速发展，但我们希望这些经验——我们通过无数实验获得的副产品——能够经受住时间的考验，帮助你构建和发布可靠的LLM应用。

提示

开发新应用时，我们建议从提示开始。提示的作用经常被低估和高估。低估是因为正确的提示技术，使用得当，可以取得非常好的效果。高估是因为即使基于提示的应用，也需要围绕提示进行大量工程工作以取得良好效果。

充分利用基本提示技术

一些提示技术在各种模型和任务中一贯有助于提高性能：n-shot提示+上下文学习、链式思维（CoT）以及提供相关资源。

通过n-shot提示进行上下文学习的理念是向LLM提供几个示例，展示任务并对齐输出和我们的期望。一些小建议：

• 如果n值太低，模型可能会过度依赖这些特定示例，削弱其泛化能力。经验法则是，n值≥5。不妨尝试几打示例。
• 示例应代表预期的输入分布。如果你在构建一个电影摘要器，包含不同类型的样本，与实际情况中看到的大致相同。
• 不一定要提供完整的输入-输出对。在许多情况下，期望输出的示例就足够了。
• 如果使用支持工具使用的LLM，n-shot示例也应使用你希望代理使用的工具。

在链式思维（CoT）提示中，我们鼓励LLM在返回最终答案之前解释其思考过程。可以将其视为提供给LLM的草图本，使其不必全在记忆中完成。原始方法是简单地将短语“让我们一步步思考”添加到指令中，但我们发现，通过添加一两句额外的句子使CoT更具体，通常可以显著减少幻觉率。例如，当要求LLM总结会议记录时，我们可以明确步骤，如：

• 首先，列出关键决策、跟进事项及相关负责人。
• 然后，检查草图本中的细节是否与记录一致。
• 最后，将关键点综合成简洁的摘要。

请注意，最近一些人对这一技术的实际效果提出了质疑。此外，关于使用链式思维进行推理时具体发生了什么，也存在大量争论。不管怎样，当有可能时，这一技术值得尝试。

提供相关资源是一种强大的机制，可以扩展模型的知识库，减少幻觉，并增加用户的信任。通常通过检索增强生成（RAG）实现，向模型提供可以直接在响应中使用的文本片段是一种基本技术。在提供相关资源时，不仅仅是包括它们；还要告诉模型优先使用它们，直接引用它们，有时还要提到当资源不足时。这些有助于将代理响应“定位”到资源库。

结构化输入和输出

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

例如，许多互联网上关于编写SQL的问题都会先指定SQL模式。因此，你可能期望有效的文本到SQL提示应包括结构化模式定义；确实如此。

结构化输出也有类似的目的，但它还简化了与系统下游组件的集成。Instructor和Outlines在结构化输出方面表现良好。（如果你正在导入LLM API SDK，请使用Instructor；如果你正在导入Huggingface用于自托管模型，请使用Outlines。）结构化输入清晰表达任务，类似于训练数据的格式，增加了更好输出的可能性。

在使用结构化输入时，注意每个LLM家族有其自己的偏好。Claude偏好，而GPT偏好Markdown和JSON。使用XML时，你甚至可以通过提供标签来预填充Claude的响应，如下所示：

{
    "messages": [
        {
            "role": "user",
            "content": "从这个产品描述中提取<name>, <size>, <price>和<color>并放入<response>标签中。\n<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个标记的怪物。而且更糟糕的是，它在更常见和简单的输入上表现更差！GoDaddy分享了他们构建LLM的第一大教训，正是这个问题。

就像我们努力（艰难）保持系统和代码简单一样，我们也应该对提示保持简单。不要将所有任务放在一个提示中，而是将其分解成多个步骤。例如，对于会议记录摘要器，我们可以将其分解为：

• 将关键决策、行动项和负责人提取成结构化格式
• 将提取的细节与原始记录进行一致性检查
• 根据结构化细节生成简洁摘要

结果是，我们将一个提示分解成多个简单、专注且易于理解的提示。通过分解，我们可以单独迭代和评估每个提示。

设计上下文标记

重新思考并挑战你关于需要多少上下文才能发送给代理的假设。像米开朗基罗一样，不要堆砌你的上下文雕塑——削减多余的材料，直到雕塑显现。RAG是一种汇集所有可能相关信息的流行方法，但你做了什么来提取必要的内容？

我们发现，将发送给模型的最终提示——包括所有上下文构建、元提示和RAG结果——放在一个空白页面上阅读，真的有助于重新思考你的上下文。我们发现冗余、自相矛盾的语言和糟糕的格式。

另一个关键优化是上下文的结构。你的文档袋表示对人类没有帮助，不要假设它对代理有用。仔细考虑如何结构化你的上下文，以突出其各部分之间的关系，并尽可能简化提取过程。

信息检索 / RAG

除了提示，另一种有效引导LL

M的方法是提供知识作为提示的一部分。这使LLM能够在提供的上下文中进行在上下文学习。这被称为检索增强生成（RAG）。实践者发现，RAG在提供知识和改进输出方面有效，同时所需的精力和成本远低于微调。RAG的效果取决于检索到的文档的相关性、密度和详细程度。

RAG输出质量取决于检索到的文档质量，可以从几个方面考虑：

• 首先是相关性。通常通过排名指标如平均倒数排名（MRR）或归一化折扣累计增益（NDCG）来量化。MRR评估系统在排名列表中第一个相关结果的表现，而NDCG则考虑所有结果的相关性及其位置。
• 其次是信息密度。如果两个文档同样相关，我们应该选择更简洁、没有多余细节的那个。
• 最后是文档的详细程度。想象我们在构建一个RAG系统，用于从自然语言生成SQL查询。我们可以简单地提供表模式及列名作为上下文。但如果我们包括列描述和一些代表性值呢？额外的详细信息可以帮助LLM更好地理解表的语义，从而生成更正确的SQL。

不要忘记关键词搜索；将其作为基线和混合搜索的一部分

在嵌入式RAG演示如此流行的情况下，很容易忽略或忘记信息检索领域的几十年研究和解决方案。

虽然嵌入无疑是强大的工具，但它们并不是万能的。首先，它们在捕捉高级语义相似性方面表现出色，但在更具体的基于关键词的查询（如用户搜索名字、首字母缩略词或ID）时可能表现较差。基于关键词的搜索（如BM25）就是专门为此设计的。并且经过多年的关键词搜索，用户可能已经习惯了它，如果未能返回他们期望检索到的文档，可能会感到沮丧。

矢量嵌入并没有神奇地解决搜索问题。事实上，繁重的工作在于你用语义相似性搜索重新排序之前的步骤。要在BM25或全文搜索基础上取得实质性改进是很难的。——Aravind Srinivas，Perplexity.ai CEO

我们一直在向客户和合作伙伴传达这一信息。使用简单嵌入的最近邻搜索会产生非常嘈杂的结果，你可能更适合从关键词搜索开始。——Beyang Liu，Sourcegraph CTO

其次，用关键词搜索更容易理解为什么某个文档会被检索到——我们可以查看与查询匹配的关键词。相比之下，基于嵌入的检索则不那么可解释。最后，感谢像Lucene和OpenSearch这样的系统经过几十年的优化和实战测试，关键词搜索通常在计算效率上更高。

在大多数情况下，混合搜索效果最好：关键词匹配用于显而易见的匹配，嵌入用于同义词、上位词和拼写错误，以及多模态（如图像和文本）。Shortwave分享了他们如何构建RAG管道，包括查询重写、关键词+嵌入检索和排名。

优先使用RAG而非微调以获取新知识

RAG和微调都可以用于将新信息纳入LLM，并提高特定任务的性能。那么，应该先尝试哪个呢？

最近的研究表明，RAG可能占有优势。一项研究比较了RAG和无监督微调（又称连续预训练），在MMLU子集和当前事件上进行评估。他们发现，RAG在处理训练中遇到的知识和完全新知识方面， consistently outperformed fine-tuning for knowledge encountered during training as well as entirely new knowledge。另一篇论文中，他们比较了RAG和有监督微调在农业数据集上的表现。同样，RAG的性能提升大于微调，特别是对于GPT-4。

除了改进的性能外，RAG还具有一些实际优势。首先，与连续预训练或微调相比，保持检索索引的最新状态更容易——也更便宜！其次，如果我们的检索索引中包含有毒或偏见内容的问题文档，我们可以轻松删除或修改这些文档。

此外，RAG提供了更细粒度的控制。例如，如果我们为多个组织托管一个RAG系统，通过分区检索索引，可以确保每个组织只能检索其自己的索引文档，防止无意中将一个组织的信息暴露给另一个组织。

长上下文模型不会使RAG过时

随着Gemini 1.5提供长达10M标记的上下文窗口，一些人开始质疑RAG的未来。

我倾向于认为Sora对Gemini 1.5的宣传过头了。10M标记的上下文窗口实际上使现有的大多数RAG框架变得不必要——你只需将你的数据放入上下文中，然后像平常一样与模型对话。想象一下，这对所有初创公司/代理/语言链项目的影响，其中大部分工程工作都是RAG