【大模型理论篇】用于构建围绕 LLM 的成功产品的实用指南

本文链接：https://blog.csdn.net/weixin_65514978/article/details/139571601

【背景介绍】本文来自多位一线LLM工作者的亲身体会，发表在O'Reilly，深入探讨了与 LLM 工作的战术细节。分享关于提示、设置检索增强生成、应用流程工程以及评估和监控的最佳实践和常见陷阱。这些也是自己特别感兴趣的内容，因此将part1的部分进行了全文翻译，供自己和有兴趣的同学一起学习。

【原文】What We Learned from a Year of Building with LLMs (Part I)

【译文正篇 part1】

用大型语言模型 (LLM) 构建应用正处于一个令人兴奋的时代。过去一年中，LLM 已经变得足够好，可以应用于现实世界。LLM 的改进速度和社交媒体上的一系列演示预计将推动到 2025 年对人工智能投资达到 2000 亿美元。LLM 也变得广泛可用，使得不仅是机器学习工程师和科学家，每个人都可以在他们的产品中加入智能功能。尽管构建 AI 产品的入门门槛已经降低，但创建超越演示效果的有效产品仍然是一个具有欺骗性的困难任务。

我们发现了一些重要但常被忽视的机器学习课程和方法论，这些对于基于 LLM 的产品开发至关重要。了解这些概念可以让你在不需要机器学习专业知识的情况下，在该领域中获得竞争优势！过去一年里，我们六个人一直在基于 LLM 构建现实世界的应用。我们意识到，有必要将这些经验汇总到一个地方，以造福整个社区。

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

我们的目标是将这本实用指南用于构建围绕 LLM 的成功产品，结合我们的经验并引用行业中的示例。过去一年中，我们亲自动手，汲取了许多宝贵的教训，往往是通过艰难的方式获得的。虽然我们不声称代表整个行业，但在这里我们分享一些对于任何构建 LLM 产品的人都有用的建议和经验。

这项工作分为三个部分：战术、操作和战略。这是三部分中的第一部分，深入探讨了与 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 模式开始。因此，你可能会预期有效的 Text-to-SQL 提示应包括结构化的模式定义；确实如此。

结构化输出也有类似的目的，但它还简化了与系统下游组件的集成。Instructor 和 Outlines 适用于结构化输出。（如果你正在导入一个 LLM API SDK，使用 Instructor；如果你正在为自托管模型导入 Huggingface，使用 Outlines。）结构化输入清晰地表达任务，并类似于训练数据的格式，提高了更好输出的概率。

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

                                                     </> python
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>"     
   } 
]

保持简洁的提示：每个提示只做一件事，并且要做得好

在软件开发中，一个常见的反模式/代码味道是“上帝对象”，即一个类或函数承担了所有功能。对于提示（prompts）也是同样的道理。

一个提示通常从简单开始：几句指令，几个示例，就可以了。但是，当我们试图改进性能并处理更多的边缘情况时，复杂性就会逐渐增加。更多的指令，多步推理，数十个示例。很快，我们最初的简单提示就变成了一个2000个令牌的怪物。更糟糕的是，它在处理更常见和简单的输入时表现更差！GoDaddy分享了他们在构建LLM时遇到的这一挑战，这是他们的首要教训。

就像我们努力保持系统和代码的简洁一样，我们也应该对提示保持简洁。与其为会议记录总结器使用一个万能提示，不如将其分解为以下步骤：

提取关键决策、行动项和负责人并转换为结构化格式
检查提取的细节与原始记录的一致性
从结构化细节生成简洁的摘要

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

优化上下文令牌

重新思考并挑战你关于需要向agent发送多少上下文的假设。要像米开朗基罗一样，不要堆砌你的上下文雕塑——剔除多余的材料直到雕塑显现出来。RAG（检索增强生成）是一种收集所有潜在相关块的方法，但你做了什么来提取必要的内容？

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

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

信息检索/RAG

除了提示之外，另一种有效引导LLM的方法是将知识作为提示的一部分提供。这将LLM基于提供的上下文，用于上下文学习。这被称为检索增强生成（RAG）。实践者发现RAG在提供知识和改善输出方面有效，同时比微调需要更少的努力和成本。RAG的效果取决于检索到的文档的相关性、密度和详细程度。

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

第一个也是最明显的指标是相关性。这通常通过排名指标如平均互惠排名（MRR）或归一化折扣累积增益（NDCG）来量化。MRR评估系统在排名列表中放置第一个相关结果的效果，而NDCG则考虑所有结果的相关性及其位置。它们衡量系统将相关文档排在更高位置而将不相关文档排在更低位置的能力。例如，如果我们检索用户摘要以生成电影评论摘要，我们会希望将特定电影的评论排在更高位置，同时排除其他电影的评论。

像传统推荐系统一样，检索到的项目的排名将对LLM在下游任务中的表现产生重大影响。为了衡量影响，运行一个基于RAG的任务，但检索到的项目顺序被打乱——RAG输出的表现如何？

其次，我们还要考虑信息密度。如果两个文档同样相关，我们应该选择一个更简洁且有较少多余细节的文档。回到我们的电影例子，我们可能认为电影剧本和所有用户评论在广义上都是相关的。然而，顶级评论和编辑评论可能信息更密集。

最后，考虑文档提供的详细程度。假设我们正在构建一个RAG系统以从自然语言生成SQL查询。我们可以简单地提供表架构和列名作为上下文。但是，如果我们包含列描述和一些代表性值呢？额外的细节可以帮助LLM更好地理解表的语义，从而生成更正确的SQL。

不要忘记关键词搜索；将其作为基线并在混合搜索中使用。

鉴于基于嵌入的RAG演示的普遍存在，很容易忘记或忽视信息检索中的几十年研究和解决方案。

尽管嵌入无疑是一个强大的工具，但它们并不是万能的。首先，尽管它们在捕捉高层语义相似性方面表现出色，但在处理更具体的基于关键词的查询时可能会挣扎，例如用户搜索名称（如Ilya）、首字母缩写词（如RAG）或ID（如claude-3-sonnet）时。关键词搜索（如BM25）专为此设计。经过多年的关键词搜索，用户可能已经习惯了，如果未返回他们期望检索到的文档，他们可能会感到沮丧。

向量嵌入并不能神奇地解决搜索问题。事实上，重排语义相似性搜索之前的步骤才是关键。真正改进BM25或全文搜索是很难的。— Aravind Srinivas，Perplexity.ai CEO

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

其次，通过关键词搜索更容易理解为什么检索到某个文档——我们可以查看匹配查询的关键词。相比之下，基于嵌入的检索则不那么可解释。最后，感谢Lucene和OpenSearch等经过长期优化和战斗测试的系统，关键词搜索通常更具计算效率。

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

优先选择RAG而非微调来获取新知识

RAG和微调都可以用来将新信息整合到LLM中并提高特定任务的性能。那么，首先应该尝试哪个？

最近的研究表明RAG可能有优势。一项研究比较了RAG和无监督微调（即持续预训练），评估了它们在MMLU子集和当前事件上的表现。研究发现，RAG在处理训练期间遇到的知识以及全新知识方面始终优于微调。另一篇论文比较了RAG和监督微调在农业数据集上的表现。同样，RAG的性能提升优于微调，尤其是对GPT-4。

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

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

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

随着Gemini 1.5提供最多10M令牌大小的上下文窗口，有些人开始质疑RAG的未来。

我倾向于相信Sora对Gemini 1.5的宣传过头了。一个10M令牌的上下文窗口实际上让大多数现有的RAG框架变得不必要——你只需将所有数据放入上下文中，然后像平常一样与模型对话。想象一下它对所有初创公司/agents/LangChain项目的影响，这些项目的大部分工程工作都集中在RAG上😅。或者一句话：10m上下文杀死了RAG。好工作，Gemini。— Yao Fu

虽然确实长上下文将成为分析多个文档或与PDF聊天等用例的游戏规则改变者，但关于RAG即将消亡的传言被大大夸大了。

首先，即使有10M令牌的上下文窗口，我们仍需要一种方式来选择信息以提供给模型。其次，除了狭窄的“大海捞针”评估外，我们还没有看到令人信服的数据表明模型能够有效地推理如此大的上下文。因此，如果没有良好的检索（和排名），我们有可能让模型被干扰信息淹没，或者甚至可能填满上下文窗口的完全不相关的信息。

最后，还有成本问题。Transformer的推理成本随上下文长度呈二次方（或线性地在空间和时间上）增长。仅仅因为存在一个模型可以在回答每个问题之前读取你组织的整个Google Drive内容，并不意味着这是个好主意。类比我们使用RAM的方式：我们仍然从磁盘读取和写入，即使存在运行数十TB RAM的计算实例。

所以，不要急着把你的RAG扔掉。即使上下文窗口的大小增加，这种模式仍然会有用。

调整和优化工作流

提示LLM只是开始。要充分利用它们，我们需要超越单一提示，接受工作流。例如，我们如何将一个复杂任务分解为多个简单任务？何时微调或缓存有助于提高性能并减少延迟/成本？在本节中，我们分享了一些经过验证的策略和实际案例，以帮助你优化和构建可靠的LLM工作流。

逐步、多轮“流程”可以大大提升效果。

我们已经知道，通过将一个大提示分解为多个小提示，我们可以获得更好的结果。AlphaCodium就是一个例子：通过从单一提示切换到多步工作流，他们在CodeContests上提高了GPT-4的准确率（pass@5）从19%到44%。

工作流包括：

反思问题
推理公共测试
生成可能的解决方案
排名可能的解决方案
生成合成测试
在公共和合成测试上迭代解决方案

具有明确目标的小任务是最佳的agent或流提示。并非每个agent提示都需要请求结构化输出，但结构化输出在与协调agent与环境互动的系统对接时大有帮助。

一些建议尝试

一个明确的计划步骤，尽可能紧密地指定。考虑使用预定义计划进行选择。
将原始用户提示重写为代理提示。注意，这个过程是有损的！
Agent行为如线性链、DAG和状态机；不同的依赖关系和逻辑关系对于不同的规模可能更或更不适用。你能从不同任务架构中挤出性能优化吗？
计划验证；你的计划可以包含如何评估其他agent响应的指令，以确保最终组合良好。
固定上游状态的提示工程——确保你的代理提示针对可能发生的各种变体进行评估。

优先考虑确定性的工作流

虽然AI agents可以动态响应用户请求和环境，但其不确定性使其部署成为挑战。agent每执行一步都有可能失败，且从错误中恢复的机会很小。因此，agent成功完成多步任务的概率随着步骤数量的增加而呈指数下降。结果是，构建agents的团队发现难以部署可靠的agents。

一个有前途的方法是让代理系统生成确定性计划，然后以结构化、可复制的方式执行计划。在第一步中，给定一个高层次目标或提示，代理生成一个计划。然后，计划以确定性的方式执行。这使得每一步更加可预测和可靠。好处包括：

生成的计划可以作为少样本示例来提示或微调agent。
确定性执行使系统更可靠，因此更容易测试和调试。此外，失败可以追溯到计划中的特定步骤。
生成的计划可以表示为有向无环图（DAG），相对于静态提示，更容易理解和适应新情况。

最成功的代理构建者可能是那些在管理初级工程师方面经验丰富的人，因为生成计划的过程类似于我们指导和管理初级工程师的方式。我们给初级工程师明确的目标和具体的计划，而不是模糊的开放式指示，我们也应该对agents这样做。

最终，构建可靠、工作正常的代理的关键可能在于采用更结构化、确定性的方法，以及收集数据来完善提示和微调模型。否则，我们将构建一些有时可能非常出色但总体上令人失望的代理，导致用户留存率下降。

获得超越调节温度的多样化输出

假设你的任务需要生成多样化的LLM（大型语言模型）输出。比如，你可能在编写一个LLM流水线，基于用户之前购买的产品列表，建议从你的产品目录中购买新的产品。当你多次运行你的提示时，你可能会注意到结果推荐过于相似，因此你可能会增加LLM请求中的温度参数。

简而言之，增加温度参数会使LLM的响应更具多样性。在采样时，下一令牌的概率分布变得更加平坦，这意味着通常不太可能的令牌会被选择得更频繁。不过，当增加温度时，你可能会注意到一些与输出多样性相关的失败模式。例如：

可能适合的目录中的某些产品可能永远不会被LLM输出。
如果某些产品在训练过程中被LLM认为是高度相关的，它们可能在输出中被过度代表。
如果温度过高，你可能会得到引用不存在产品（或无意义内容）的输出。

换句话说，增加温度并不能保证LLM会按照你期望的概率分布（例如，均匀随机）生成输出。不过，我们还有其他方法可以增加输出的多样性。最简单的方法是调整提示中的元素。例如，如果提示模板包括一系列项目，如历史购买记录，每次将这些项目插入提示时随机排列顺序可以显著改变输出。

此外，保持一份近期输出的简短列表可以帮助防止重复。在我们的推荐产品示例中，通过指示LLM避免建议最近列表中的项目，或拒绝和重新采样与最近建议相似的输出，可以进一步增加响应的多样性。另一种有效的策略是改变提示中的措辞。例如，加入类似“选择一个用户可能会经常使用的产品”或“选择一个用户可能会推荐给朋友的产品”这样的短语，可以改变焦点，从而影响推荐产品的多样性。

缓存被低估了

缓存可以节省成本并消除生成延迟，因为它消除了为相同输入重新计算响应的需要。此外，如果一个响应之前已经过了安全检查，我们可以提供这些经过验证的响应，从而减少提供有害或不当内容的风险。

一种简单的缓存方法是为正在处理的项目使用唯一ID，例如我们正在总结新文章或产品评论。当收到请求时，我们可以检查缓存中是否已经存在摘要。如果存在，我们可以立即返回它；如果不存在，我们生成、检查并提供它，然后将其存储在缓存中以供将来使用。

对于更开放的查询，我们可以借鉴搜索领域的技术，该领域也利用缓存处理开放输入。自动完成和拼写校正等功能也有助于规范用户输入，从而提高缓存命中率。

什么时候需要微调

在某些任务中，即使使用最巧妙设计的提示，仍然可能无法得到满意的结果。例如，即使经过大量提示工程，我们的系统可能仍然无法返回可靠的高质量输出。如果是这样，那么可能有必要为特定任务微调模型。

成功的例子包括：

Honeycomb的自然语言查询助手：最初，“编程手册”被与n-shot示例一起提供作为提示进行上下文学习。虽然这工作得不错，但微调模型后，在语法和领域特定语言规则方面的输出更好。
ReChat的Lucy：LLM需要生成特定格式的响应，将结构化和非结构化数据结合起来，以便前端正确呈现。为了让它一致地工作，微调是必不可少的。

尽管如此，微调虽然有效，但也伴随着显著的成本。我们必须标注微调数据，微调和评估模型，并最终自行托管它们。因此，需要考虑这种较高的前期成本是否值得。如果提示已经能达到90%的效果，那么微调可能不值得投资。然而，如果我们决定进行微调，为了减少收集人工标注数据的成本，可以生成并微调合成数据，或利用开源数据启动。

评估与监控

评估LLM可能会很棘手。LLM的输入和输出是任意的文本，且我们设置的任务多种多样。然而，严格和深思熟虑的评估是至关重要的——OpenAI的技术领导者正是对评估进行研究并对个别评估提供反馈。

评估LLM应用程序需要多样的定义和简化：它既是单元测试，也类似于可观察性，或只是数据科学。我们发现所有这些观点都是有用的。在以下部分中，我们分享了一些关于构建评估和监控流水线的重要经验教训。

根据实际输入/输出样本创建一些基于断言的单元测试

从生产环境中的输入和输出样本创建单元测试（即断言），并基于至少三个标准对输出进行预期。虽然三个标准看起来有些随意，但这是一个实用的起点；更少的标准可能表明你的任务定义不充分或过于开放，如通用聊天机器人。这些单元测试或断言应该在管道的任何更改（无论是编辑提示，添加新的上下文通过RAG，还是其他修改）时被触发。这个写作示例展示了一个实际使用案例的基于断言的测试示例。

考虑从指定短语或观点的包含或排除的断言开始。还可以考虑检查单词、项目或句子的数量是否在一定范围内。对于其他类型的生成，断言可能看起来不同。执行评估是一种强大的代码生成评估方法，其中你运行生成的代码并确定运行时状态是否满足用户请求。

例如，如果用户要求生成一个名为foo的新函数；那么在执行代理生成的代码后，foo应该是可调用的！执行评估的一个挑战是agent代码经常使运行时的状态与目标代码略有不同。有效的方法是“放宽”断言，至任何可行答案都能满足的最弱假设。

最后，以客户预期的方式使用你的产品，可以提供关于实际数据失败模式的见解。这种方法不仅有助于识别潜在的弱点，还提供了有用的生产样本，可以转换为评估。

LLM作为裁判可以奏效（一定程度上），但它不是银弹

LLM作为裁判，用强大的LLM评估其他LLM的输出，一些人对此持怀疑态度。（我们中有些人最初也是极大的怀疑者。）然而，当实施得当时，LLM作为裁判可以与人类判断达到不错的相关性，并至少可以帮助建立对新提示或技术表现的先验认识。特别是，在做成对比较时（例如，控制对比处理），LLM作为裁判通常能正确地判断方向，尽管胜负的幅度可能带噪声。

以下是一些最大化LLM作为裁判效果的建议：

使用成对比较：与其让LLM在Likert量表上评分单个输出，不如给它两个选项并要求它选择更好的那个。这往往会导致更稳定的结果。
控制位置偏差：选项的顺序会影响LLM的决策。为减轻这一点，可以对每对比较进行两次，交换顺序每次交换顺序。只要确保在交换后正确归因胜利。
允许平局：在某些情况下，两个选项可能同样好。因此，允许LLM宣布平局，这样它就不必任意选择一个赢家。
使用链式思维：要求LLM在给出最终偏好之前解释其决策可以提高评估的可靠性。作为额外奖励，这使你可以使用较弱但更快的LLM，仍然达到类似的结果。因为这个部分通常在批处理模式中，CoT的额外延迟不是问题。
控制响应长度：LLM往往偏向于较长的响应。为减轻这一点，确保响应对的长度相似。

LLM作为裁判的一个特别强大的应用是检查新提示策略是否存在回归。如果你跟踪了一系列生产结果，有时你可以使用新的提示策略重新运行这些生产示例，并使用LLM作为裁判快速评估新策略可能存在的问题。

以下是一个简单但有效的LLM作为裁判迭代示例，我们只是记录LLM响应、裁判的批判（即CoT）和最终结果。然后与利益相关者一起审查以识别改进领域。经过三次迭代，与人类和LLM的协议从68%提高到94%。

LLM-as-Judge 并非万能良方

尽管如此，LLM-as-Judge 并不是万能的。对于语言的一些微妙方面，即使是最强大的模型也无法可靠地评估。此外，我们发现传统的分类器和奖励模型的准确性往往高于LLM-as-Judge，并且成本和延迟更低。在代码生成方面，LLM-as-Judge 的表现可能不如直接的评估策略（如执行评估）来得强。

“实习生测试”用于评估生成效果

我们喜欢用以下的“实习生测试”来评估生成效果：如果你把语言模型的确切输入（包括上下文）交给一个相关专业的普通大学生作为任务，他们能完成吗？需要多长时间？

如果答案是否定的，因为LLM缺乏所需知识，可以考虑丰富上下文。
如果答案是否定的，并且我们无法通过改善上下文来解决问题，那么这可能是一个当代LLM无法胜任的任务。
如果答案是肯定的，但需要较长时间，我们可以尝试降低任务的复杂性。任务是否可分解？是否可以使任务的某些方面更加模板化？
如果答案是肯定的，并且他们可以很快完成，那么就需要深入研究数据。模型错在哪？是否能发现失败的模式？尝试让模型在回答之前或之后解释其答案，以帮助你建立思维模型。

过度重视某些评估可能会影响整体表现

“当一个衡量标准变成目标时，它就不再是一个好的衡量标准。”——古德哈特定律

一个例子是 Needle-in-a-Haystack (NIAH) 评估。最初，这种评估有助于量化随着上下文规模增长模型的回忆能力，以及针的位置如何影响回忆。然而，它被过度强调，甚至出现在 Gemini 1.5 的报告中。NIAH 评估涉及将特定短语插入到一篇长文档中，然后提示模型回忆这个魔法数字。

虽然一些模型能实现接近完美的回忆，但NIAH是否真正反映了实际应用所需的推理和回忆能力是值得质疑的。考虑一个更实际的场景：给定一小时会议的转录，LLM能否总结关键决策和下一步行动，并正确归属每个项目到相关人员？这个任务更具现实意义，超越了机械记忆，考虑了解析复杂讨论、识别相关信息和综合总结的能力。

举例来说，一个实际的 NIAH 评估可以使用医生和病人视频通话的转录，询问模型有关病人用药的信息。也可以包括更具挑战性的NIAH，如插入关于披萨配料的随机短语。对于用药任务，回忆率约为80%；对于披萨任务，回忆率约为30%。

顺便提一下，过度强调NIAH评估可能会导致提取和总结任务的表现下降。因为这些LLM过度调整以关注每一个句子，它们可能开始将无关的细节和干扰视为重要，从而在最终输出中包含这些不该包含的内容。

简化注释为二元任务或成对比较

为模型输出提供开放式反馈或在Likert量表上评分认知负担很重。因此，收集的数据更加噪声化——由于人工评分员之间的差异——因此用处更小。一种更有效的方法是简化任务并减轻注释者的认知负担。两种有效的任务是二元分类和成对比较。

在二元分类中，注释者被要求对模型的输出做出简单的“是”或“否”的判断。他们可能被问及生成的摘要是否与源文档事实一致，或建议的回应是否相关，或是否包含有害内容。相比于Likert量表，二元决策更精确，评分员之间一致性更高，吞吐量也更高。这就是Doordash如何设置他们的标注队列，通过一个是非问题树来标记菜单项。

在成对比较中，注释者会看到一对模型响应，并被要求选择更好的一个。因为人们更容易说“A比B好”，而不是为A或B单独打分，这导致注释（相比于Likert量表）更快、更可靠。在Llama2见面会上，Llama2论文的作者之一Thomas Scialom证实，成对比较比收集监督微调数据（如书面响应）更快、更便宜。前者的成本为每单位$3.5，而后者的成本为每单位$25。

（无参考）评估和护栏可以互换使用

护栏有助于捕捉不适当或有害的内容，而评估有助于衡量模型输出的质量和准确性。在无参考评估的情况下，它们可以被视为一枚硬币的两面。无参考评估是不依赖于“金标准”参考（如人工撰写的答案）的评估，能够仅根据输入提示和模型的响应评估输出的质量。

例如，摘要评估中，我们只需考虑输入文档来评估摘要的事实一致性和相关性。如果摘要在这些指标上得分较低，我们可以选择不向用户显示，从而有效地将评估用作护栏。同样，无参考翻译评估可以在不需要人工翻译参考的情况下评估翻译质量，从而允许我们将其用作护栏。

LLM会返回它们不应该返回的输出

在使用LLM时，一个关键挑战是它们经常会生成不应该生成的输出。这可能导致无害但无意义的响应，或者更严重的缺陷，如有害或危险的内容。例如，当被要求从文档中提取特定属性或元数据时，LLM可能会自信地返回即使这些值不存在的值。或者，模型可能因为我们在上下文中提供了非英语文档而用非英语作答。

虽然我们可以尝试提示LLM返回“不可用”或“未知”的响应，但这并不万无一失。即使日志概率可用，它们也是输出质量的一个糟糕指标。尽管日志概率指示了一个标记出现在输出中的可能性，但它们并不一定反映生成文本的正确性。相反，对于那些经过指令微调的模型（被训练以响应查询并生成连贯响应），日志概率可能未得到很好的校准。因此，尽管高日志概率可能表明输出流畅且连贯，但并不意味着它是准确或相关的。

尽管仔细的提示工程在一定程度上有所帮助，我们还应辅以健壮的护栏来检测和过滤/重新生成不期望的输出。例如，OpenAI提供的内容审核API可以识别不安全的响应，如仇恨言论、自残或色情内容。同样，也有许多包用于检测个人身份信息（PII）。一个好处是，护栏在很大程度上与使用案例无关，因此可以广泛应用于特定语言的所有输出。此外，通过精确的检索，如果没有相关文档，我们的系统可以确定性地回答“我不知道”。

这里的一个推论是，LLM可能在预期情况下无法生成输出。这可能由于各种原因发生，从API提供商的长尾延迟等简单问题，到更复杂的输出被内容审核过滤器拦截。因此，记录输入和（潜在的缺失的）输出对于调试和监控至关重要。

幻觉问题顽固存在

与内容安全或PII缺陷相比，幻觉问题更加顽固且更难检测。它们更常见，基线发生率为5-10%，而根据我们从LLM提供商那里了解到的信息，即使在诸如摘要这样简单的任务中，要将其降低到2%以下也具有挑战性。

为了解决这个问题，我们可以结合提示工程（生成上游）和事实不一致护栏（生成下游）。对于提示工程，像链式思维（CoT）这样的技术通过让LLM在返回最终输出之前解释其推理，有助于减少幻觉。然后，我们可以应用事实不一致护栏来评估摘要的事实性，并过滤或重新生成幻觉。在某些情况下，幻觉可以通过确定性方法检测。当使用RAG检索的资源时，如果输出是结构化的并标识了资源，那么应该能够手动验证它们是从输入上下文中提取的。

关于作者

Eugene Yan 设计、构建并运营大规模服务客户的机器学习系统。目前，他是亚马逊的高级应用科学家，负责构建服务全球数百万客户的推荐系统（RecSys），并在 RecSys 2022 和 AI Eng Summit 2023 上发表主题演讲。他曾在 Lazada和一家健康科技A轮公司领导机器学习工作。他在 eugeneyan.com 和 ApplyingML.com 上撰写和演讲关于机器学习、推荐系统、LLM和工程学的内容。
Bryan Bischof 是 Hex 的 AI 负责人，领导工程师团队构建数据科学和分析助手“Magic”。Bryan 在数据栈的各个领域工作过，带领分析、机器学习工程、数据平台工程和 AI 工程团队。他在 Blue Bottle Coffee 创建了数据团队，在 Stitch Fix 领导多个项目，并在 Weights and Biases 建立了数据团队。Bryan 曾与 O'Reilly 合著《Building Production Recommendation Systems》一书，并在罗格斯大学教授数据科学和分析课程。他拥有纯数学博士学位。
Charles Frye 教授人们构建 AI 应用。在发表了心理药理学和神经生物学方面的研究后，他在加州大学伯克利分校获得博士学位，论文研究领域是神经网络优化。他通过 Weights and Biases、Full Stack Deep Learning 和 Modal 等教育和咨询工作，向数千人教授从线性代数基础到 GPU 专门知识及构建可行商业项目的整个 AI 应用开发流程。
Hamel Husain 是一位拥有超过25年经验的机器学习工程师。他曾在 Airbnb 和 GitHub 等创新公司工作，参与了 OpenAI 用于代码理解的早期 LLM 研究。他还领导并参与了众多流行的开源机器学习工具项目。目前，Hamel 是一名独立顾问，帮助公司将大型语言模型（LLM）投入运营，加速其 AI 产品开发进程。
Jason Liu 是一位知名的机器学习顾问，以成功领导团队发布 AI 产品而著称。Jason 的技术专长涵盖个性化算法、搜索优化、合成数据生成和 MLOps 系统。他曾在 Stitch Fix、Meta、纽约大学以及 Limitless AI 和 Trunk Tools 等初创公司任职，创建了处理每天3.5亿次请求的推荐框架和可观察性工具。
Shreya Shankar 是加州大学伯克利分校计算机科学专业的博士生和机器学习工程师。她曾在两家初创公司担任首席机器学习工程师，从零构建每天服务数千用户的 AI 驱动产品。作为研究人员，她的工作集中在通过以人为本的方法解决生产机器学习系统中的数据挑战。她的研究成果发表在 VLDB、SIGMOD、CIDR 和 CSCW 等顶级数据管理和人机交互会议上。