这是一份涵盖战术、运营和战略方面的大语言模型产品成功建设的实用指南。

作者

发布时间

2024 年 6 月 8 日

同时在奥莱利媒体分三部分发布：战术，运营，战略。详情可参见播客。

构建大语言模型的时代令人兴奋。在过去一年中，大语言模型已经成熟到足以应用于现实世界，且每年都在提升性能和降低成本。随着社交媒体上一系列的演示，预计到 2025 年将有 2000 亿美元投资于人工智能。此外，供应商的 API 使得大语言模型更加普及，不仅机器学习工程师和科学家，任何人都可以将智能技术集成到他们的产品中。但是，即便进入 AI 领域的门槛降低了，要创造出真正有效的产品和系统，远比单纯的演示要复杂得多。

过去一年里，我们在建设过程中经历了不少挑战。虽然我们不能代表整个行业，但愿意分享我们的经验，帮助你规避我们曾犯的错误，并加速迭代。我们的经验总结为以下三大板块：

战术应用: 探讨如何有效利用提示 (prompting)、结果聚合生成 (RAG)、流程工程、效果评估和运行监控等实用技术。无论你是在专业领域使用大语言模型 (LLMs) 还是周末时间进行创新项目，这一部分都将为你提供指导。
日常运营: 涉及产品推出的组织日常管理和如何构建高效团队的实践指南。特别适合那些致力于持续可靠部署的产品或技术领导者。
战略规划: 从长远和宏观的角度出发，提供诸如“在实现产品市场契合 (PMF) 前不购买 GPU”和“专注于系统而非单一模型”的策略性建议，并探讨如何进行有效迭代。本节内容主要针对创始人和高层管理者。

本书旨在提供一个实用的指南，以我们的实际经验为基础，帮助您利用大语言模型 (LLMs) 构建成功的产品，并介绍行业内的相关案例。

准备好深入探索了吗？我们出发吧。

1 战术应用：深入大语言模型的实操细节

此处，我们分享关于新兴大语言模型技术栈核心部分的最佳实践：改进提示技巧以增强质量与可靠性、输出评估策略、利用检索增强的生成技术加强数据的确凿性、设计涉及人的回路工作流等。尽管这些技术还处于起步阶段，但我们相信这些经验对广泛的应用都具有参考价值，能助您打造出坚实的大语言模型应用。

1.1 提示技巧

我们建议在设计新应用的原型时首先考虑使用提示技巧。人们常常低估或高估其重要性：正确的提示技巧，若运用得当，能极大地推动项目前进；但仅依靠提示技巧，无论其设计多精妙，最终都需要围绕其构建复杂的工程解决方案。

1.1.1 专注于充分利用基本的提示技巧

一些常用的提示技巧在不同模型和任务中都显著提升了性能，包括：多示例提示和上下文学习、逐步思考法，以及提供相关资源。

通过多示例提示进行上下文学习的核心思想是向大语言模型 (LLM) 提供展示任务的示例，并使输出结果符合我们的预期。这里有一些实用的建议：

如果示例数量太少，模型可能会对这些特定的示例形成过度依赖，这会影响其泛化能力。一般来说，示例数量至少应为 5 个以上。你可以尝试使用数十个示例。
示例应当能够代表实际使用中的数据分布。例如，如果你正在开发一个电影总结工具，就应该包括不同类型的电影样本，并且比例应与实际相符。
有时候你不必非得提供输入和输出的配对，单纯提供期望的输出样本也足够了。
如果你打算让大语言模型使用工具，不妨提供一些相关工具使用的示例。

在逐步思考法 (CoT) 的提示中，我们鼓励大语言模型在给出最终答案前，先阐述其思考过程。你可以想象我们为大语言模型提供了一个“思维画板”，帮助它整理和分析信息。最初，我们只需在指令中加入“让我们一步步来思考”的说法，但我们发现，具体到某些细节的额外一两句话，能有效减少错误信息的生成。

例如，在要求大语言模型总结会议记录时，我们可以明确各个步骤：

首先，在“思维画板”中列出关键的决策、待办事项及责任人。
接着，核对“思维画板”中的内容与会议记录是否一致。
最后，将所有关键信息综合，形成一份简洁的会议总结。

请注意，最近有些研究对这一技术的有效性提出了质疑，不确定它是否像人们所认为的那样强大。此外，在使用连续思考推理 (Chain-of-Thought) 进行推理时，究竟发生了什么，这个问题也引发了广泛的讨论。尽管如此，这种技术还是值得一试。

提供相关资源可以扩大模型的知识库，减少错误信息的生成，并增强用户的信任感。这通常通过检索增强生成 (Retrieval Augmented Generation, RAG) 实现，即向模型提供可以直接用于回应的文本片段，这是一种关键的技术。在提供相关资源时，单单包含这些资源是不够的；需要确保模型优先使用这些资源，明确引用它们，并在资源不足时明确指出。这样可以确保智能体的回应更加贴合实际可用的资源。

1.1.2 结构化输入与输出

通过结构化输入和输出，模型能更精确地理解输入内容，并生成可以顺利与下游系统集成的输出。为输入添加序列化格式，能有效揭示上下文中不同 token（如标识）之间的关联，为特定 token 添加额外的元数据（例如类型），或将请求与模型的训练数据中相似的案例关联起来。

例如，许多网上有关编写 SQL 的问题都是从定义 SQL 架构开始的。因此，有效的 Text-to-SQL 提示应当包括结构化的架构定义。

结构化输入不仅明确了任务需求，而且与模型的训练数据格式相似，这增加了产生优质输出的可能性。结构化输出能简化系统下游组件的集成过程。使用 Instructor 可以优化 LLM API SDK 的输出结构；若采用自托管模型的 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>"
    }
]

1.1.3 编写单一功能的小提示词

在软件开发中，一个常见的反模式/代码异味是“God 对象”，即我们有一个类或函数包揽所有功能。对提示词也是如此。

一个提示词通常从简单开始：几句指令，几个示例，就可以了。但随着我们尝试提高性能并处理更多边缘情况，复杂性逐渐增加。更多的指令，多步推理，几十个示例。不知不觉中，我们最初简单的提示词变成了一个 2000 个 Token 的怪物。更糟的是，它在处理更常见和更简单的输入时性能更差！GoDaddy 分享了他们在使用 LLM 时的首要教训。

就像我们努力（即：挣扎）保持系统和代码简单一样，我们也应该对提示词这样做。与其为会议记录总结器编写一个全能提示词，我们可以将其分解为多个步骤：

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

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

1.1.4 创造你的上下文 token

重新考虑并质疑你对于需要向 AI 智能体提供多少上下文的原有看法。效仿米开朗基罗，不是去构建一座上下文的雕塑，而是要不断剔除多余部分，直至雕塑的形态显现。RAG 是一个流行的方法，用来整合所有可能相关的信息碎片，但关键是如何精准提取你真正需要的信息。

我们发现，把最终要发送给模型的提示——包括所有的上下文构建、元提示和 RAG 的结果——单独放在一张纸上阅读，可以极大地帮助你重新思考你的上下文。这种方式让我们识别出了文中的冗余、自相矛盾的表达和格式问题。

你上下文的结构同样重要。如果你整理的文档对人类阅读毫无帮助，同样也不会对 AI 智能体有益。你需要仔细考虑如何组织你的上下文，突出其内部各部分的联系，使得从中提取信息尽可能简单。

了解更多关于提示的基本技巧，如心理模型的建立、预设内容的填充、上下文的安排等，可以参考这里。

1.2 信息检索 / RAG

在提示外，另一个提高大语言模型效率的有效方法是在提示中直接提供知识。这种方式称为检索增强生成（RAG），能够将大语言模型固定在提供的上下文中，用于学习。实践中，RAG 被证实在提供信息和改进输出方面非常有效，而且比微调要节省大量的努力和成本。

1.2.1 RAG 的效果取决于检索文档的相关性、信息密度和详尽程度

RAG 的输出质量依赖于检索到的文档质量，这主要从以下几个方面考量：

首先，相关性是关键指标，通常通过诸如平均倒数排名 (MRR) 或归一化折扣累积增益 (NDCG) 这样的排名指标来量化。MRR 考察系统能否在排名列表中有效地置顶首个相关结果，而 NDCG 则评估所有结果的相关性及其排列顺序。这些指标反映了系统在提升相关文档和降低不相关文档排名的能力。比如，在生成电影评论摘要时，我们期望能高效筛选出与特定电影相关的评论。

就像传统的推荐系统一样，检索结果的排序对 LLM 完成后续任务的效果有显著影响。可以通过执行一个基于 RAG 的任务来测试这一点，但在此任务中打乱检索结果——观察这对 RAG 输出的影响如何。

接下来，考虑信息的密度。如果两份文档的相关性相同，我们更倾向于选择信息更集中、细节更少的文档。例如，在分析电影评论时，虽然电影剧本和所有用户评论都有其相关性，但评分高的评论和专业编辑的评论在信息密度上往往更胜一筹。

最后，要关注文档提供的细节层次。假设我们要构建一个从自然语言生成 SQL 查询的 RAG 系统。提供表结构和列名已足够，但如果加入列的描述和一些典型值，将有助于 LLM 更深入理解表的语义，从而生成更精确的 SQL 查询。

1.2.2 别忘了关键词搜索；将其作为基准，并用于混合搜索

基于嵌入的 RAG 演示非常普遍，很容易让人忽视了信息检索领域数十年的研究和成果。

虽然嵌入技术无疑非常强大，但它并非解决所有问题的方法。首先，嵌入技术虽然擅长捕捉高层次的语义相似性，但对于更具体的、基于关键词的查询（例如搜索名字如 Ilya、缩写如 RAG 或 ID 如 claude-3-sonnet）则可能表现不佳。这种情况下，专为此设计的基于关键词的搜索技术，例如 BM25，就显得尤为重要。多年来，用户已经习惯了基于关键词的搜索，如果他们期待的文档没有返回，可能会感到失望。

向量嵌入 并不能 神奇地解决搜索问题。事实上，重要的工作发生在利用语义相似性搜索重新排序之前。超越 BM25 或全文搜索并实现真正的进步是非常困难的。 — Aravind Srinivas, CEO Perplexity.ai

我们已经向我们的客户和合作伙伴传达了这个信息好几个月了。使用简单嵌入进行的最近邻搜索往往结果混乱，开始时采用基于关键词的方法通常更为稳妥。 — Beyang Liu, CTO Sourcegraph

其次，关键词搜索让我们能直观理解文档为何被检索到——我们可以直接看到与查询匹配的关键词。相比之下，基于嵌入的检索方法的可解释性较差。最后，多亏了像 Lucene 和 OpenSearch 这样经过多年优化和实战检验的系统，关键词搜索在计算效率上通常更优。

在多数情况下，采用混合方法效果最佳：对明显的匹配使用关键词匹配，对同义词、上义词、拼写错误及多模态内容（如图片和文字）使用嵌入技术。Shortwave 解释了他们如何建立其 RAG 处理流程，包括查询的重新编写、关键词加嵌入的检索以及排名过程。

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

RAG 和微调都能将新信息整合到大语言模型中，从而提高在特定任务上的表现。但是，哪一个更应该被优先考虑呢？

最新研究显示，RAG 在这方面可能更有优势。一项研究对比了 RAG 与无监督微调（也称为持续预训练），在 MMLU 的一个子集和当前事件上进行了评估。结果显示，无论是训练期间遇到的知识还是全新的知识，RAG 的表现都一致优于微调。在另一篇研究中，研究人员又将 RAG 与在农业数据集上的监督微调进行了比较，同样发现 RAG 带来的性能提升超过了微调，尤其是在 GPT-4 中（见表 20）。

除了性能上的提升，RAG 还具有其他实际优势。首先，相比连续预训练或微调，保持检索索引更新更为简单且成本更低。其次，如果我们的检索索引中存在含有有毒或偏见内容的问题文件，我们可以轻松地去除或修改这些文件，这就像是为问题文件设置了一个紧急停止的安全绳。

此外，RAG 的 R 字母代表的检索功能，提供了更精细的控制方式。比如说，如果我们为多个组织提供 RAG 系统服务，通过对检索索引进行分区，我们可以确保每个组织只能检索到自己索引中的文件，这样就避免了不小心泄露一家组织的信息给另一家。

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

Gemini 1.5 支持的最大 1000 万个 token 的上下文窗口，让一些人开始对 RAG 的前景产生疑问。

我个人认为，Gemini 1.5 的炒作有些过头了。有了 1000 万 token 的上下文窗口，大部分现有的 RAG 架构几乎可以说是多余的——你只需要把数据放进上下文，像平常那样跟模型交流即可。想想这会对那些投入大量精力在 RAG 上的初创公司、代理商和语言链项目造成多大的冲击😅。简而言之：1000 万的上下文终结了 RAG。干得漂亮，Gemini。——Yao Fu

虽然长上下文确实能在分析多份文档或与 PDF 交流等场景中起到革命性作用，但关于 RAG 将不复存在的说法显然被夸大了。

首先，即便是在 1000 万 token 的上下文下，我们仍需找到选取关键信息的方法。其次，除了特定的寻找针在干草堆中的评估外，我们还没有看到足够的数据证明模型能在如此庞大的上下文中有效推理。因此，如果缺乏有效的检索和排序，我们可能会让模型应对过多的干扰信息，或者甚至填充了完全不相关的内容。

最后，考虑到成本，Transformer 在推理时的时间复杂度与上下文长度成正比增加。虽然理论上有模型能在回答问题前阅读你整个组织的 Google Drive 内容，但这并不一定是明智之举。想想我们如何使用 RAM：尽管有的计算实例可用的 RAM 高达数十 TB，我们仍然需要从磁盘读写数据。

所以，现在还不是把你的 RAG 扔进垃圾桶的时候。随着上下文大小的增长，这一模式仍将保持其用武之地。

1.3 调整与优化工作流

使用大语言模型 (LLM) 仅仅是起点。要想充分利用这些模型，我们需考虑整个工作流程，而不仅仅是单一的输入提示。例如，如何将一个复杂任务拆分为多个简单环节？在什么情况下，通过微调 (finetuning) 或者缓存来提高性能同时减少等待时间和成本会更有效？我们在这里将分享一些行之有效的策略和现实案例，帮助您构建可靠高效的大语言模型工作流程。

1.3.1 分步骤、多轮次的流程能显著提高效率

大家都知道，把一个复杂的大型输入拆分成多个小型输入，能够取得更好的效果。例如，通过从单一输入转变为多步骤工作流的 AlphaCodium 就将 GPT-4 在编程竞赛中的通过率从 19% 提升到了 44%。这个流程包括：

对问题进行深入反思
针对公开测试进行逻辑推理
构思可能的解决方案
评估这些解决方案的有效性
创造模拟测试
在真实和模拟的测试中不断完善解决方案

清晰定义的小任务是构建有效流程的关键。虽然不是每一个操作都需要结构化的输出，但结构化的输出能极大地提高系统整合效率。这里有一些可行的策略：

设定一个详尽明确的计划步骤。可以考虑从事先设定的计划中进行选择。
把原始的用户输入转换成智能体的操作提示，虽然这个转换可能不完美。
智能体的行为可以是线性的、有向无环图 (DAGs) 或状态机，这些不同的结构对不同的任务规模有不同的适应性。你能否通过不同的任务架构来优化性能？
计划的验证；确保你的策划步骤包含如何评估其他智能体响应的指导，以保证整体任务的有效协同。
在固定的前提条件下进行提示工程，确保对智能体的各种可能情景进行有效评估。

1.3.2 当下应优先考虑确定性工作流

尽管 AI 智能体能够根据用户的需求和环境变化灵活响应，但其本质上的非确定性使得部署它们成为挑战。每个操作步骤都可能失败，并且从失败中恢复的几率极低。因此，随着操作步骤增多，智能体成功执行多步骤任务的概率急剧下降。这使得开发团队难以部署可靠的智能体。

一个可行的策略是，让智能体系统制定出确定性的计划，并严格按照这一计划执行。首先，基于一个高层次的目标或指令，智能体会制定出一个执行计划。随后，按照既定计划严格执行。这样做可以使每一步更加可预测和稳定。其优点包括：

制定的计划可用作引导或微调智能体的少样本示例。
确定性的执行提高了系统的可靠性，使得测试和调试更为简单。此外，当出现故障时，可以准确追溯到计划中的具体步骤。
制定的计划可以用有向无环图 (DAG) 形式表示，相较于静态指令，这种形式更易于理解和适应新的场景。

最有经验的智能体开发者往往是那些擅长管理初级工程师的专家。制定计划的过程类似于我们对初级工程师的指导和管理方式：我们为他们设定清晰的目标和具体的操作步骤，而不是模糊的、开放式的指示。我们对智能体的管理也应该采取同样的方法。

总之，构建可靠且有效的智能体的关键在于采用更加结构化和确定性的方法，并通过收集数据来精细调整指令和优化模型。如果没有这些措施，我们构建的智能体可能偶尔能够表现出色，但平均来看，可能会让用户感到失望。

1.3.3 超越调整温度参数以获得更多样化的输出

假设你的任务是在大语言模型 (LLM) 的生成结果中寻求多样性。你可能正在开发一个用于推荐购买商品的大语言模型流程，这些商品来自于用户之前的购买历史。当你多次运行同一个提示时，你可能会发现推荐结果过于类似——这时你可以考虑提高请求中的温度参数。

简单来说，提高温度参数会让大语言模型生成的回答更加多样。在选择下一个词汇时，其概率分布会变得更加均匀，使得一些不常出现的词汇变得更可能被选择。但是，提高温度也可能带来一些问题，例如可能导致一些合适的商品永远不会被推荐出来。如果温度调得太高，甚至可能生成一些毫无意义的内容。

换句话说，提高温度并不能确保大语言模型按照你期望的概率分布（如均匀随机）来生成结果。不过，我们还可以通过其他方式来增加结果的多样性。一个简单的方法是调整提示内容的元素。例如，如果提示包含一个商品列表，改变每次插入这些商品的顺序可以显著提升结果的多样性。

此外，记录一份最近生成的结果列表也有助于防止重复。例如，在我们的商品推荐案例中，通过设置大语言模型避免推荐最近列表中的商品，或者拒绝与最近建议相似的结果，可以进一步提高答案的多样性。另一种有效的方法是变换提示语的措辞，比如使用“选择用户经常使用并喜欢的商品”或“选一个用户可能会推荐给朋友的产品”等表达方式，可以改变重点，从而影响推荐的商品种类。

1.3.4 缓存的重要性被低估了

缓存可以通过避免对同一输入的反复响应计算来节约成本并减少生成的延迟。如果某个响应已经过初步审核，那么我们可以直接提供这些经过认证的响应，这样做可以降低传递有害或不适内容的风险。

对于缓存的一个简单方法是，为处理的项目分配唯一 ID，比如用于总结新闻文章或产品评测。当有相关请求时，我们可以先检查缓存中是否已有相应的摘要。如果有，可以立即返回该摘要；如果没有，我们会生成、审核并提供这一内容，并将其保存在缓存中，以备后续使用。

对于更加开放式的查询，我们可以采用搜索领域的一些策略，该领域同样使用缓存来处理多变的输入。自动补全、拼写纠正和查询建议等功能，也有助于标准化用户输入，从而增加缓存的命中率。

1.3.5 何时进行微调

在某些任务中，即使是最巧妙设计的提示也可能无法奏效。例如，尽管进行了大量的提示工程优化，我们的系统可能还是无法提供可靠且高质量的输出。在这种情况下，为了特定任务，对模型进行微调可能是必要的。

以下是一些成功的实例：

Honeycomb 的自然语言查询助手：最初，"编程手册" 与多个示例一起用于上下文学习。这种方法虽有一定成效，但通过对模型进行微调，可以更好地处理特定领域语言的语法和规则。
Rechat 的 Lucy：此大语言模型需要生成特定格式的响应，该格式结合了结构化和非结构化数据，确保前端能正确渲染。因此，微调对于保证其效果至关重要。

尽管微调是有效的，它也涉及到显著的成本。我们需要标注微调数据，对模型进行微调和评估，并最终自行托管。因此，需要权衡是否值得承担更高的初始成本。如果通过简单的提示就能解决问题的 90%，那么微调可能并非必要。然而，如果我们选择进行微调，为了降低收集人工标注数据的成本，我们可以选择在合成数据上进行微调，或者利用开源数据进行启动。

1.4 评估与监控

评估大型语言模型（LLM）充满挑战，即便是顶尖的实验室也觉得这是一项艰巨的任务。大型语言模型（LLM）提供的是开放式输出，而我们设定的任务形式多样。然而，严格而周到的评估过程至关重要——不难发现，OpenAI 的技术领袖们正专注于评估工作并对评估结果进行反馈。

评估大型语言模型的应用涉及多种定义和简化方式，有时它是单元测试，有时又似乎更侧重于观察性，或者可以视为数据科学的一部分。我们认为这些观点都极具价值。本节中，我们将分享在构建评估与监控流程中的一些重要经验。

1.4.1 基于真实案例创建断言单元测试

编写单元测试（即断言），涉及生产环境中的输入输出样本，这些测试根据至少三个评价标准来预设结果。选用三个标准的原因是实用性，数量更少可能说明任务定义不够具体或过于泛化，比如通用聊天机器人。任何流程变更，比如修改指令、通过 RAG 增加新上下文或其他调整，都应触发这些单元测试或断言。此文章包含了一个针对具体应用场景的断言测试示例。

建议从定义特定短语的断言开始，这些短语可以帮助我们筛选或排除某些响应。还可以进行检查，确保词汇、项目或句子的数量处于合理范围内。对于其他类型的内容生成，断言的形式也可能有所不同。执行评估是一种测试代码生成质量的方法，你可以通过执行生成的代码来验证运行时状态是否符合用户需求。

比如，用户请求新增一个名为“foo”的功能；执行代码后，“foo”应可被调用。执行评估的挑战之一是，生成的代码可能会使运行环境与预期略有出入。适当放宽断言标准，仅保留对所有有效回答必需的最基本假设，这种方法通常较为有效。

最后，通过内部测试（即“自用”）使用产品，可以对真实场景中的失败模式进行了解。这不仅有助于发现潜在问题，还能提供转换为评估用的生产样本，从而增强产品的实用性。

1.4.2 大语言模型作为裁判：有其效用，但非完美解决方案

大语言模型作为裁判（LLM-as-Judge）的做法是利用一台性能强大的大语言模型来评价其他大语言模型的输出，这种方法一直备受争议。（最初，我们中的许多人对此表示怀疑。）然而，当这种做法得到恰当实施时，它能够与人类评判展现出良好的一致性，并且能够帮助我们初步了解新提示或新技术可能的表现。尤其是在进行控制组和处理组的成对比较时，大语言模型作为裁判通常能正确预测结果的趋势，虽然具体的胜负幅度可能会有些波动。

为了充分发挥大语言模型作为裁判的效果，可以参考以下几点建议：

采用成对比较方式：不是让大语言模型对单个输出进行打分，而是展示两个选项，让它选择较优者。这种方法往往能产生更稳定的结果。
控制顺序偏见：选项的呈现顺序可能会影响大语言模型的决策。为了减少这种影响，每次成对比较都应交换选项顺序，并确保正确记录每次比较的胜者。
允许平局存在：有时两个选项可能同样优秀。在这种情况下，应允许大语言模型判定为平局，避免不必要的选择。
引入思维链 (Chain-of-Thought)：要求大语言模型在给出最终判断前先解释其决策过程，这可以提高评估的准确性。此外，这种方式还允许使用更快速但计算能力较弱的大语言模型，而不影响结果。由于这部分通常是批量处理，额外的延迟不会造成问题。
控制回答长度：大语言模型倾向于偏好较长的回答。为避免这种偏见，应确保比较的两个回答长度相似。

大语言模型作为裁判在实际应用中的一个重要用途是，用于测试新的提示策略是否比过去的策略表现更差。如果你已经收集了一系列的生产结果，有时可以重新使用这些实例并采用新的提示策略，借助大语言模型作为裁判快速评估新策略的表现。

这是一个简单而有效的途径，用于改进以大语言模型为评判基准的方法，其中包括记录大语言模型的反应、评判的批评（即链式教学法）以及最终的结果。这些记录后续会与利益相关者一起回顾，从而识别改进空间。经过三次迭代，大语言模型与人类的一致性从 68% 提升至 94%！

然而，以大语言模型为评判标准并非解决所有问题的灵丹妙药。在语言的细微差别上，即便是最强的模型也可能无法可靠评估。此外，我们还发现，传统的分类方法和奖励模型在准确性上可以超过以大语言模型为基准的方法，并且成本更低，响应更快。在代码生成方面，以大语言模型为基准的评估也可能不如直接的执行评估方法有效。

1.4.3 评估生成物的“实习生测试”

在评估生成物时，我们常用的一个方法是“实习生测试”：如果你把完整的输入，包括上下文，交给一个相关专业的普通大学生，看他们能否完成这项任务，以及需要多少时间来完成。

如果因为大语言模型缺乏必要的知识而无法完成，那么考虑如何丰富上下文。
如果问题无法通过改善上下文来解决，那么这可能是一个对当前的大语言模型而言过于复杂的任务。
如果他们能完成，但需要较长时间，我们可以考虑简化任务的复杂性。看看这个任务是否可以分解，其某些方面是否可以模板化。
如果他们能迅速完成任务，那么就需要深入分析数据了。看看模型在哪些方面出了问题，是否能找到失败的模式。尝试在模型作出反应前后让模型进行自我解释，这可以帮助你建立一个关于其思维过程的理论。

1.4.4 过度强调某些评估可能会削弱整体表现（点击这里）

“当一项指标变成了目标，它就不再是一个好的衡量工具。” — 古德哈特定律。

以“大海捞针 (NIAH)”评估为例。这个评估最初旨在量化模型在上下文规模扩大时的回忆能力，以及“针”的位置如何影响回忆效果。然而，由于过度强调，它已成为图 1：Gemini 1.5 报告中的特色内容。此评估涉及在重复保罗·格雷厄姆文章的长文档中插入一个特定短语（“特殊魔法数字是：”），然后引导模型找出这个数字。

尽管一些模型几乎可以完美地回忆信息，但是否真的能够衡量现实世界中所需的推理和记忆能力，这一点仍有待商榷。想象一个更接近实际的场景：如果给定一个小时的会议记录，大语言模型是否能总结出会议的关键决策和接下来的行动步骤，并正确地把每项决策归因于相关人员？这种任务更具现实意义，它不仅仅是机械记忆，还包括了解析复杂对话、识别关键信息和合成总结的能力。

这是一个实际应用中的 NIAH 评估示例。使用医患对话的记录，询问大语言模型关于患者的用药情况。此外，它还包括了一个更具挑战性的任务，即随机插入一句话描述披萨的秘密配料，比如：“制作完美披萨所需的秘密成分包括：浸泡在意式浓缩咖啡中的枣、柠檬和山羊奶酪。”。在药物相关任务中，回忆率大约为 80%，而在披萨配料任务中，回忆率则降至 30%。

从某种程度上来说，过度重视 NIAH 评估可能会削弱在信息提取和内容总结任务的表现。由于这些大语言模型 (LLM) 经过精细的微调，专注于分析每个句子，它们可能会错误地把不相关的细节和干扰因素当作重要内容，进而错误地包含在最终的输出中（本不应如此！）

这种情况也可能适用于其他评估和应用场景。比如，在进行内容总结时，如果过分强调事实一致性，可能会导致总结过于笼统，降低了事实错误的风险，但相关性可能会受到影响。相反，如果过分追求文风和辞藻的华丽，可能会导致使用过于花哨、具有营销倾向的语言风格，这又可能引入事实上的错误。

1.4.5 简化为二元任务或对比任务

要求标注者对模型输出进行开放式反馈或在利克特量表 (Likert scale) 上打分，这在认知上是一个挑战。由于评价者之间存在差异，收集到的数据通常较为杂乱，因而用处不大。一个更实际的解决办法是简化任务，减轻标注者的认知负担。最有效的两种方法是进行二元分类和成对比较。

在二元分类任务中，标注者需要对模型输出进行简单的是非判断。例如，他们可能需要判断生成的摘要是否与原文事实相符，提出的回应是否相关，或者内容是否包含有害信息。与利克特量表相比，二元选择不仅更加精确，而且在评价者间具有更高的一致性，还能显著提高工作效率。例如，Doordash 就是通过一系列是或否的问题来为菜单项设置标签队列的。

在成对比较中，标注者需要比较两个模型回应，选择更优的一个。与给单个选项打分相比，直接比较哪个更好通常更加直观快捷，也能获得更稳定可靠的结果。在 Llama2 的一次聚会上，论文作者 Thomas Scialom 确认，与收集监督式微调数据相比，进行成对比较的速度更快，成本更低。前者的成本是每个任务 3.5 美元，后者则高达每个任务 25 美元。

若你正编写标注指南，这里是 Google 和 Bing 搜索提供的一些示范指南。

1.4.6 无需参考的评估和防护可以互为替代

防护功能用于识别不适当或有害的内容，而评估功能则用来检测模型输出的质量与准确度。当评估不依赖于任何“标准”答案，如人工撰写的回答时，它们同样可以作为防护工具。这种无需参考的评估能够仅通过输入的提示和模型的反应来判断输出的质量。

例如，在总结评估中，我们仅根据输入的文档来评价摘要的事实一致性和相关性。如果这些摘要在这些评价指标上表现不佳，我们可以选择不向用户展示，从而有效地利用评估作为一种防护措施。同理，无需参考的翻译评估也可以在无需人工翻译对照的情况下，评估翻译的质量，再次作为防护使用。

1.4.7 大语言模型 (LLM) 有时会在不该输出的时候也输出信息

在操作大语言模型时，一个显著的挑战是，它们有时会在不适当的情况下产生输出。这种输出可能是无害的，但却毫无意义，有时甚至会产生有害或危险的内容。例如，在请求提取文档的特定属性或元数据时，大语言模型可能会错误地自信满满地返回一些根本不存在的数据。此外，如果输入的是非英语文档，模型有可能用其他语言进行回答。

我们虽然可以尝试引导模型给出“不适用”或“未知”的答复，但这种方法并非总是可靠。即使我们能得到模型的预测概率，这些数据也并不是衡量输出质量的好工具。预测概率虽然能显示某个词出现的可能性，但并不能确保输出内容的准确性。特别是对于那些经过特别训练，用于回答问题和生成连贯回答的模型，这些概率往往并不准确。因此，即便是高预测概率也只能说明输出内容的流畅性，而非其准确性或相关性。

虽然精心设计的提示可以在一定程度上提高输出质量，但更有效的方法是结合使用强大的安全措施，这些措施能检测并防止不希望的输出。例如，OpenAI 提供了一个内容审查 API，可以检测到潜在的危险内容，如仇恨言论、自伤或色情信息。还有很多工具可以帮助检测个人身份信息。这些安全措施的一个优势是它们通常与具体应用场景无关，可以广泛适用于所有输出。此外，借助精确的信息检索技术，如果系统找不到相关的文档，它可以直接回答“我不知道”。

有时，大语言模型在需要输出时可能无法做到，这可能是由于多种原因，如 API 提供商的延迟或内容审查机制的干预。因此，持续地记录输入和输出（或缺少输出）对于系统的调试和监控至关重要。

1.4.8 虚假信息生成：一个难以根除的问题

与内容安全或个人信息保护问题不同，后者因为受到广泛关注而较少发生，虚假信息生成的问题却十分顽固且更难以发现。这种问题的常见频率为 5 - 10%，根据我们从大语言模型提供商处获得的信息，即使是在执行简单任务如内容总结时，将其减少到 2% 以下仍然是一个挑战。

为了应对这一挑战，我们可以在生成内容前后分别采用提示工程和信息真实性检验。在生成前，采用如 CoT 等技术可以通过让大语言模型先解释其推理过程来减少错误生成。在生成后，我们可以实施信息真实性检验，通过评估内容摘要的真实性来筛选或重生成错误信息。在某些情况下，可以确定性地检测到这些错误信息。例如，在使用 RAG 检索技术时，如果输出内容结构清晰且能够明确资源来源，我们可以手动核实这些资源是否确实来自于输入内容。

2 运营关注：日常与组织事务

2.1 数据

正如食材质量决定菜肴口味一样，输入数据的质量直接影响机器学习系统的表现。此外，输出数据是唯一能显示产品是否正常工作的指标。因此，所有研究者都关注数据，他们会定期审视输入与输出，深入分析数据的分布特征、极端案例以及模型的局限性。

2.1.1 检查开发 - 生产偏移检查链接

传统机器学习流程中常见的一个错误源是“训练 - 服务偏移”，发生于训练用的数据与模型在实际运用中遇到的数据不一致的情况。尽管我们可以在不训练或微调的情况下使用大语言模型 (LLM)，不存在训练集，但开发与生产间的数据偏差同样可能发生。基本上，我们在开发阶段测试的数据应与系统在实际使用中遇到的数据保持一致，否则可能导致生产中的准确度下降。

大语言模型的开发 - 生产偏移主要有两种：结构性和基于内容的。结构性偏移涉及到格式上的不一致，如 JSON 字典与列表类型值之间的差异、大小写不一致、拼写错误或句子不完整等问题。这些问题可能使模型表现不稳定，因为不同的大语言模型针对特定的数据格式进行训练，对细微变化极为敏感。基于内容的偏移则涉及数据意义或上下文的差异。

像处理传统机器学习问题一样，定期检测大语言模型输入与输出间的偏移是很有帮助的。通过简单的指标，如输入输出的长度或特定格式要求（如 JSON 或 XML）可以直接监测变化。对于更高级的漂移检测，可以通过聚类输入输出对的嵌入来识别主题漂移，这可能表明用户正探索模型未覆盖的新领域。

在进行如提示工程等测试更改时，确保使用的保留数据集是最新的，并能反映用户最近的交互方式。例如，如果生产中常见的输入错误也应反映在保留数据中。除了进行数值偏移测量，还应定期对输出进行质量评估。常规的模型输出审查——俗称“氛围审查”——确保结果符合预期并满足用户需求。最后，引入非确定性到偏移检查中也十分关键，通过对测试集中每个输入重复运行多次并分析所有输出，我们能更好地捕捉偶尔出现的异常。

2.1.2 每日查看大语言模型的输入与输出样本

大语言模型 (LLM) 是动态发展的系统。尽管它们在零样本 (zero-shot) 场景下表现卓越，输出常常令人欣喜，但其失败模式却极难预测。对于特定任务，定期检查样本数据对于深入理解大语言模型的表现至关重要。

从实际生产中获取的输入输出对是大语言模型应用的实际检验（即“现场实物检查”genchi genbutsu），这是不可替代的。近期研究表明，随着开发者与更多数据的交互，对“优质”与“劣质”输出的认识会逐渐变化（这一现象称为“评价标准漂移”criteria drift）。虽然开发者可以预先设定一些评估大语言模型输出的标准，但这些标准通常是不全面的。例如，在开发过程中，我们可能需要更新提示语，以提高优质回应的概率并降低劣质回应的出现。这一评价、重新评价及标准调整的循环过程是必要的，因为未直接观察输出前，很难准确预测大语言模型的行为或用户偏好。

为了有效地管理这一过程，我们应当记录大语言模型的输入和输出。通过每日检查这些日志样本，我们能迅速识别并适应新出现的模式或失败模式。一旦发现新问题，我们就可以立即进行断言或进行评估处理。同时，任何对失败模式定义的更新也应该及时反映在评价标凈中。这些“情况检查”是判定输出质量的重要信号；通过编码和断言来具体操作。最终，这种做法还需要在团队中推广，比如在日常轮值中增加对输入和输出的审核或标注任务。

2.2 模型应用

通过大语言模型的 API，我们能够依赖少数供应商提供的智能服务。这虽然为我们带来便利，同时也意味着我们需要在性能、响应时间、数据处理能力和成本等多方面进行权衡。随着每个月都有新的、更优秀的模型推出，我们必须随时准备升级我们的产品，从旧模型过渡到新模型。在这一节中，我们将分享在使用那些无法完全控制、无法自托管和管理的技术时的心得体会。

2.2.1 简化集成的结构化输出

在大多数实际应用场景中，LLM 的输出会通过某种机器可读格式被下游应用程序所使用。例如，Rechat——一个房地产客户关系管理系统，就需要前端能够渲染的结构化响应。类似地，Boba——一个产品策略创意生成工具，也需要有标题、摘要、可行性评分和时间框架的结构化输出。LinkedIn 则介绍了如何限制 LLM 生成 YAML 格式的输出，以便决定使用哪些技能，并提供执行这些技能所需的参数。

这种应用模式是对 Postel 法则（在接受时宽容，在发送时严格）的一种极致实践，预计这种模式将具有很高的持久性。

目前，Instructor 和 Outlines 是指导 LLM 输出结构化数据的行业标准。如果你在使用 LLM API（如 Anthropic 或 OpenAI），那么应选择使用 Instructor；如果你在使用自托管模型（如 Huggingface），则应选用 Outlines。

2.2.2 在不同模型间迁移提示指令的挑战

有时候，我们精心构建的提示指令在某一模型上能够发挥出色，却可能在另一款模型上表现不佳。这类情况通常出现在我们更换模型提供商或升级同一模型的不同版本时。

以 Voiceflow 为例，他们在从 gpt-3.5-turbo-0301 迁移到 gpt-3.5-turbo-1106 的过程中，发现其意图分类任务的准确率下降了 10%（幸运的是，他们进行了评估）。同样，GoDaddy 观察到，升级到版本 1106 后，gpt-3.5-turbo 与 gpt-4 之间的性能差异有所缩减。如果你足够乐观，可能会对 gpt-4 在新版本中领先优势的减少感到些许失望。

因此，当我们需要在不同的模型间迁移提示指令时，需要的时间可能比简单更换 API 端点要多。不应期待同一提示指令在不同模型中能得到相同或更好的效果。同时，有可靠的自动化评测可以在迁移前后帮助我们测量任务性能，减少人工验证的工作量。

2.2.3 版本及固定您的模型

在任何机器学习流程中，“改变任何事物都将改变一切”这一点尤其重要。当我们依赖那些非自行训练且可能悄无声息变化的组件，如大语言模型（LLM）时，这一点更为显著。

幸运的是，许多模型供应商提供了“固定”特定版本模型（如：gpt-4-turbo-1106）的选项。这样，我们就可以使用特定版本的模型权重，确保其不会改变。在生产环境中固定模型的版本可以防止模型行为出现不预期的变化，从而避免客户对模型更换引起的问题（如过度冗长的输出或其他未预见的失误）提出投诉。

此外，还应考虑维护一个影子流程，该流程镜像您的生产环境但使用最新的模型版本。这样可以安全地进行新版本的测试和尝试。一旦验证了这些新模型输出的稳定性和品质，您便可以自信地在生产环境中更新模型版本。

2.2.4 选择适合任务的最小型模型

当我们开发新应用时，往往倾向于选择最强大的模型。但一旦证明任务技术上可行，不妨试试看是否一个更小的模型也能达到类似的效果。

小型模型的优点在于它们的响应更快，成本更低。虽然这些模型可能能力较弱，但是借助思考链路、多样本提示和上下文学习等技术，小型模型完全有可能发挥出超乎预期的效果。除了直接使用大语言模型的 API 外，对特定任务进行微调同样能够提升性能。

通过精心设计的工作流，小型模型往往能达到甚至超越大模型的表现，且更快更省钱。例如，这条 tweet 中分享了 Haiku 搭配十样本提示在某些情况下能胜过无样本的 Opus 和 GPT-4 的实例。展望未来，我们预计将见证更多通过优化小型模型以平衡输出质量、响应速度和成本的工作流程设计。

以分类任务为例，像 DistilBERT（67M 参数）这样的轻量级模型已经是一个强大的基准。而在开源数据上进行微调的 400M 参数的 DistilBART，其表现甚至可以以 0.84 的 ROC-AUC 识别虚假内容，效率远超大多数大型模型，同时大幅降低了延迟和成本。

因此，我们不应忽视小型模型的潜力。虽然使用大模型解决问题似乎很简单，但通过一些创新和尝试，我们往往可以找到更有效的方法。

2.3 产品

尽管新技术开辟了前所未有的可能性，优秀产品的构建原则却历久弥新。因此，即使我们首次面对新问题，也无需在产品设计上重新起步。坚实的产品基础能让我们在开发大语言模型应用时，为服务对象创造真正的价值。

2.3.1 从早期就频繁参与设计

设计师的参与会促使你深入思考产品的构建和呈现方式。设计师不仅仅是美化产品的人。他们会深度挖掘和优化用户体验，哪怕这意味着需要颠覆传统规则和模式。

设计师擅长于将用户需求转化为多种形态，有的形态更易于解决问题，从而为 AI 解决方案提供更多机会。构建 AI 产品应聚焦于用户需要完成的任务，而不仅仅是技术本身。

思考这样的问题：“这个产品需要完成哪些用户的需求？是不是适合用聊天机器人来做？自动填充功能是否足够？或者说，需要一种全新的方法？”思考现有的设计模式以及它们如何服务于用户的需求。这些设计思维是设计师为团队带来的宝贵财富。

2.3.2 为人在环中设计您的用户体验 (Design your UX for Human-In-The-Loop)

要获得高质量的数据标注，一个有效的方式是将人在环中 (Human-in-the-Loop, HITL) 融入到用户体验 (User Experience, UX) 的设计中。通过便捷的反馈和更正方式，我们不仅能即时优化输出结果，还能收集宝贵数据，进而提升模型的性能。

设想这样一个电商平台，用户在这里上传并对自己的商品进行分类。对用户体验的设计可以有多种方式：

用户亲自挑选正确的商品类别，而大语言模型 (LLM) 则定期对新商品进行检查，并在后台纠正分类错误。
用户无需选择任何类别，大语言模型会定期在后台对商品进行分类，这种方式可能会有错误发生。
大语言模型在实时向用户推荐商品类别，用户随后可以确认并根据需要进行调整。

这三种方式虽然都涉及到大语言模型，但提供的用户体验截然不同。第一种方法让用户初步承担分类任务，大语言模型则作为后续的核查工具。第二种方法用户毋须付出任何努力，但这样也无法给用户透明度或控制权。第三种方法则较为平衡，大语言模型事先提出分类建议，这不仅减轻了用户的认知负担，还避免了用户必须熟悉分类体系的需要。同时，用户可以审核并修改建议，最终决定商品的分类，从而确保了控制权在自己手中。此外，这种方式还形成了一个自然的模型改进反馈循环：合适的建议得到采纳（正面反馈），不当的建议则被修正（负面后跟正面反馈）。

这一模式——提出建议、用户验证和数据收集，在多个应用场景中已经得到广泛应用。

编程助手：用户可以完全采纳建议（极大支持），稍作修改后采纳建议（支持），或忽略建议（反对）
Midjourney：用户可以选择升级并下载图片（极大支持），修改图片（支持），或生成一组新的图片（反对）
聊天机器人：用户可以对回答点赞（支持）或点踩（反对），或如果回答质量很差，可以选择重新生成回答（极度反对）。

反馈可以是直接或间接的。直接反馈是用户应产品的请求而提供的信息；间接反馈是我们通过用户的互动行为间接获得的信息。编程助手和 Midjourney 就是间接反馈的例子，而点赞和点踩则是直接反馈的例子。如果我们的用户体验设计得当，如编程助手和 Midjourney 那样，我们就能从中收集大量的间接反馈，进而优化我们的产品和模型。

2.3.3 毫不留情地排序你的需求层次

在我们计划将演示产品投入使用时，我们需要考虑以下几个方面的要求：

可靠性：保持 99.9% 的在线时间，确保输出结构化
无害性：不制作攻击性、不适宜工作场所或其他有害内容
事实一致性：保持对提供背景的忠诚，不编造内容
有用性：满足用户的需求和请求
可扩展性：响应时间协议，支持的吞吐量
成本：因为我们的预算是有限的
其他：包括安全、隐私、公平、GDPR、DMA 等方面的考量。

如果我们尝试一次性解决所有这些要求，我们将无法推出任何产品。因此，我们需要果断地优先排序。这意味着要清楚哪些是基本要求（例如，可靠性、无害性），没有这些，我们的产品无法正常运行或无法市场化。关键在于找到最受欢迎的基本产品。我们必须接受首个版本不会完美，并立即投入市场进行调整。

2.3.4 根据用例调整风险承受能力

在选择语言模型和应用程序审查标准时，应考虑具体用例和目标受众。例如，在面向客户的聊天机器人中提供医疗或财务咨询时，我们必须设定极高的安全和准确性门槛。任何错误或失误都可能造成严重后果并损害用户信任。然而，对于一些关键性较低的应用，如推荐系统或是用于内部的内容分类和总结工具，过于严苛的要求可能会无谓地拖慢进程，并不会带来更多的价值。

这一点从最新的 a16z 报告中可以看出，许多企业在推进内部大语言模型应用的速度快于外部应用（见下图）。通过内部试验 AI 技术，企业不仅可以开始实现价值，还能在一个更加可控的环境中学习如何管理风险。随着信心的增强，他们逐步可以将应用扩展到面向客户的场景。

企业在内部和外部用例中使用大语言模型的比例 (来源：a16z 报告)

2.4 团队及其角色

虽然定义任何一个职位都不是件容易的事，但为这个新兴领域撰写职位描述尤其具有挑战性。我们不会采用交叉职称的维恩图或是职位描述的建议。相反，我们将确认 AI 工程师这一新兴角色，并探讨其定位。同时，我们还会讨论团队其他成员的职责分配方式。

2.4.1 注重过程而非工具

在面对像大语言模型 (LLM) 这样的新兴技术时，软件工程师往往更倾向于关注工具。这种偏好导致我们忽略了工具应解决的问题和相关过程，进而引入了无意的复杂性，严重影响了团队的长期效率。

例如，这篇文章讨论了一些工具如何自动生成大语言模型的提示。文章正确地指出，不先理解解决问题的方法或流程就急于使用这些工具的工程师，将不可避免地累积技术债务。

此外，这些工具往往规定不明确。比如，目前市场上涌现出许多评估大语言模型的工具，它们提供了一套“即开即用的大语言模型评估工具”，包括对毒性、简洁度、语调等的评估。但我们看到，许多团队在没有深入考虑自己业务领域的特定风险时就匆忙采用这些工具。与之形成鲜明对比的是 EvalGen，它专注于教育用户如何参与到每一个步骤中，从定义评估标准到标记数据，再到评估验证，以此来创建符合行业特点的评估流程。软件将用户引导完成以下工作流程：

Shankar, S., et al. (2024). 谁来验证验证者？将大语言模型辅助的评估与人类偏好相对齐。检索自 https://arxiv.org/abs/2404.12272

EvalGen 引导用户实施一套最佳实践，以制定有效的大语言模型评估：

定义特定领域的测试，这些测试根据提示自动形成，并可以通过代码断言或使用大语言模型作为评判。
强调与人类判断的一致性，确保测试能准确反映出设定的标准。
随着系统（如提示）的更新，持续改进这些测试。

EvalGen 为开发者提供了一个关于评估构建过程的心理模型，不局限于任何特定工具。我们发现，在向 AI 工程师提供这种背景知识后，他们通常会选择更简洁的工具或自己开发工具。

LLM 包含的组件众多，这里不可能详尽列举。但 AI 工程师在开始使用这些工具之前，了解这些过程是非常重要的。

2.4.2 持续尝试新实验

机器学习产品的发展与实验紧密相关。这不仅包括 A/B 测试或随机对照试验，更多的是不断尝试修改系统的最小组件，并进行离线评估。人们如此看重评估的原因，并非仅仅是因为它的可信度和可靠性，更因为评估能够促进实验的进行。优秀的评估能让你更快速地迭代实验，从而更迅速地优化你的系统至最佳状态。

由于现在实验成本极低，尝试用不同方法解决相同的问题已经成为常态。数据收集和模型训练的高成本已大幅度降低——提示工程的成本几乎只是人力成本。确保你的团队每个成员都掌握了提示工程的基本知识，这样可以激励团队成员进行实验，从而产生更多创新想法。

此外，实验不仅是为了探索新领域，更是为了充分利用现有资源。如果你有一个新任务的初步版本，不妨尝试让团队中其他成员以不同的方法来完成这一任务，或者寻找更快的解决方案。探索如连锁思维或少样本等高效的提示技术，以提升任务的品质。不要因为工具的限制而阻碍你的实验；如果有必要，可以重新构建工具，或者购买更优秀的工具。

最后，在进行产品或项目规划时，要预留足够的时间用于建立评估系统和进行多次实验。可以参考工程产品的规格书，但要在其中加入明确的评估标准。在制定项目路线图时，不要低估实验和评估所需的时间——预计在正式投入生产前，需要多次迭代开发和评估。

2.4.3 促进每个人都能使用新的 AI 技术

随着生成式 AI 越来越多的被采用，我们希望团队中的每一个成员——不只是专家——都能够理解并掌握这项新技术。没有比直接使用大语言模型 (LLMs) 更有效的方法来培养对它们的工作原理（如：响应时间、失败模式、用户体验 (UX)）的感知了。大语言模型的使用门槛较低：即使不会编程，也能通过优化提示和评估来提高性能。

教育是这一过程的重要组成部分。它可以从简单的提示工程基础开始，通过如 n-shot 提示和 CoT 这样的技术调整模型，以产生期望的输出。熟悉这些知识的人还可以对大语言模型的自回归输出生成方式进行更技术性的讲解。也就是说，尽管输入的 token 是并行处理的，输出的 token 则是逐个产生的。因此，响应时间更多地取决于输出的长度，而非输入的长度——这在设计用户体验和设置性能预期时至关重要。

我们还可以提供更多实际操作和探索的机会。或许可以举办一次编程马拉松？虽然让团队花几天时间探索新项目似乎成本很高，但得到的成果可能会出乎意料。我们知道，有的团队通过编程马拉松加速实现了他们三年的发展规划，仅用了一年时间。另一个团队的编程马拉松则催生了创新的用户体验设计，这些设计得益于大语言模型的能力，已被列为今年及未来的重点项目。

2.4.4 别误认为“只要有 AI 工程就够了” [20]

随着职场新职位的涌现，人们最初往往对这些角色的能力期望过高，这种误解通常随着职责的真实范围揭晓而需要痛苦地修正。新进人员及招聘经理可能会言过其实，期望值过高。过去十年里的典型例子包括：

数据科学家：“在统计方面超过任何软件工程师，在软件工程方面超过任何统计学家。”
机器学习工程师 (MLE): 一种侧重于软件工程视角的机器学习认识

起初，人们认为仅靠数据科学家就能胜任数据驱动的项目。然而，很快就显现出，数据科学家需要与软件和数据工程师合作，才能有效地开发和部署数据产品。

这种误解在 AI 工程师这一新兴角色中再次显现，一些团队误以为拥有 AI 工程师就足够了。实际上，打造机器学习或 AI 产品需要涉及广泛的专业角色。我们在咨询超过十几家公司的 AI 产品开发中发现，他们通常会落入“只要有 AI 工程就行”的误区。这导致产品往往难以从演示阶段向更广泛的应用扩展，因为企业忽视了构建产品过程中的关键环节。

例如，产品从初步概念到实际应用的扩展，评估和测量是至关重要的。有效的评估技能需求与机器学习工程师传统优势相符，一个纯粹由 AI 工程师组成的团队可能缺失这些技能。合作者 Hamel Husain 在他最新的关于识别数据漂移和设计领域特定评估方法的研究中，突显了这些技能的重要性。

以下是在构建 AI 产品的过程中，你需要的各种角色类型及其必要时机的大致概述：

首先，专注于构建产品。虽然可能需要 AI 工程师，但并非必需。AI 工程师在快速原型设计和产品迭代方面（如用户体验和系统架构）极具价值。
其次，通过部署监控系统和数据收集，为系统打下坚实基础。视数据的类型和规模，你可能需要部署平台和/或数据工程师，并建立数据查询及分析系统来解决问题。
接着，你将需要对 AI 系统进行优化，这不一定涉及模型训练。基本步骤包括设计评估指标、建立评估体系、进行实验、优化信息检索、调试随机系统等。机器学习工程师非常擅长这些工作（AI 工程师也能胜任）。通常，除非已经完成了前期的必要步骤，否则不宜急于聘用机器学习工程师。

此外，任何时候都需有领域专家在场。在小型公司，理想情况下由创始团队担此角色；在大公司，则可由产品经理承担。明智地安排人员的招聘和职责顺序至关重要。在不适当的时间聘用人员（如过早聘用机器学习工程师）或错误的建设顺序，都会造成资源浪费和员工流失。此外，项目初期阶段，定期而非全职地与机器学习工程师进行沟通，将有助于建立坚实的基础。

3 策略：在不被超越的情况下使用大语言模型构建

成功的产品依赖于深思熟虑的计划和优先级排序，而不是无止境的原型测试或追随最新的模型和趋势。在本节中，我们将深入探讨构建卓越 AI 产品的战略要点。我们还会评估团队可能面临的关键折衷选择，例如何时自主开发何时采购，并提出一套针对早期大语言模型应用开发的策略“剧本”。

3.1 在达到产品市场契合前不要急于使用 GPU

一个卓越的产品，远不止是简单地利用他人的 API 进行次级封装。相反的错误可能带来更高的成本。过去一年，风险投资的涌入包括一个高达六十亿美元的 A 轮融资，这些资金被用于训练和定制模型，却没有清晰的产品方向或目标市场。在这一节中，我们将讨论为什么急于自行训练模型是不明智的，并探讨自我托管的重要性。

3.1.1 几乎没有必要从头开始训练 (几乎)

对于绝大多数组织而言，从头开始预训练一个大语言模型 (LLM) 往往是一种资源的浪费。

虽然这听起来非常吸引人，仿佛人人都在此尝试，但实际上，开发和维持一套机器学习基础设施非常消耗资源。这涉及到数据的收集、模型的训练与评估以及最终的部署。如果你的产品尚在市场验证阶段，这些工作可能会大大分散你的注意力，使你无法专注于核心产品的开发。即便你具备了足够的计算力、数据资源和技术实力，预训练出的模型也可能在几个月内迅速过时。

以金融领域的 BloombergGPT 为例，该模型是由九位全职员工（四名 AI 工程师和五名机器学习产品及研究人员）共同努力，基于 3630 亿个数据令牌进行预训练的。然而，不到一年的时间，它就被新一代的模型 gpt-3.5-turbo 和 gpt-4 在同样的任务上超越。

这一例子以及其他类似情况说明，对于大多数实际应用，从头开始预训练大语言模型，哪怕是针对特定领域的数据，也并非最佳选择。团队应该更倾向于对现有的强大开源模型进行微调，以满足自身的特定需求。

有些情况除外。如 Replit 的代码模型，这是一个专为代码生成和理解而设计的模型。通过预训练，Replit 成功超越了其他大型模型，如 CodeLlama7b。然而，随着越来越多高效的模型问世，维持其有效性需要不断的投入。

3.1.2 除非必要，否则不要急于微调

对大部分组织而言，微调通常是出于对错失良机（FOMO）的担忧，而非基于清晰的战略考虑。

许多组织过早地开始微调，试图摆脱他人认为这只是在进行表面包装的质疑。事实上，微调应当视为重型设备，只有在收集到足够证明其他方法不足的数据后，才应当采用。

一年前，许多团队对微调充满期待，但寻找到的产品市场契合度少之又少，大多数团队对此后悔不已。如果你决定微调，那么在基础模型不断优化的过程中，你需要非常确定自己能够一次又一次地应对挑战——请参考下文的“模型不是产品”和“构建 LLMOps”。

在什么情况下，微调才是正确的选择？当应用场景需要的数据不在现有模型训练时所使用的广泛开放的网络数据集中可获得，且你已经构建了展示现有模型不足的最小可行产品时。但需谨慎：如果连模型开发者都难以获得优质训练数据，你又怎能轻易得到呢？

由大语言模型支持的应用不应仅仅是科学实验，其投资应与它们对企业战略目标和市场竞争力的实际贡献相符。

3.1.3 从推理 API 入手，但也不妨考虑自建服务

利用大语言模型 API，创业公司可以轻松集成语言模型功能，无需自行从头开始训练模型。Anthropic 和 OpenAI 等公司提供的通用 API 能让你的产品轻松智能化，仅需几行代码。利用这些服务，你可以节省精力，更专注于为客户创造价值，快速验证创意并实现市场适配。

然而，就像数据库服务一样，随着规模的扩大和需求的增加，托管服务并不总是最佳选择。例如，在医疗和金融等受监管的行业，或是根据合同或保密要求，你可能只能通过自建服务来使用模型，以确保敏感数据不离开内部网络。

此外，自建服务可以避免受到推理服务提供商的种种限制，如使用频率限制、模型淘汰和使用约束等。自建服务还可以让你完全掌控模型，更容易构建出具有特色的优质系统。特别是在大规模应用时，自建服务还可以显著降低成本。例如，Buzzfeed 就曾分享过他们如何通过微调开源大语言模型来减少 80% 的成本。

3.2 不断迭代，迈向卓越

为了长期保持竞争力，你需要考虑的不仅是模型本身，还要思考如何使你的产品独一无二。执行速度虽重要，但不应是你唯一的优势。

3.2.1 模型并非产品本身，真正的产品是围绕它的系统

对于不直接构建模型的团队而言，技术创新的快速进展提供了从一个顶尖模型过渡到另一个的机会，通过不断追求上下文处理能力、逻辑推理能力以及性价比的提升，使产品变得日益完善。这种进步既令人激动也是可以预见的。总的来看，模型可能是系统中最易更新的部分。

相反，应专注于那些能够带来持久价值的方面，例如：

性能评估（Evals）: 跨不同模型可靠地衡量你的任务表现
安全防护（Guardrails）: 确保任何模型都不会产生不希望的输出
数据缓存（Caching）: 通过规避直接使用模型来减少延迟和成本
数据驱动（Data flywheel）: 助力上述所有环节的持续改进

这些组件构成了比模型本身更坚固的产品质量防线。

但这并不意味着在应用层面的开发没有风险。避免在与 OpenAI 或其他模型供应商重复劳动的方向上浪费精力，他们将会处理这些通用需求。

例如，有些团队投资于开发自定义工具，以校验模型输出的结构化数据；适度投资是必要的，但过度投资则可能是时间的浪费。OpenAI 将确保你所需的函数调用正确无误——因为这是所有客户的共同需求。在这方面，可以适当地“战略性地推迟”行动，只构建必需的部分，等待供应商技术的明显进步。

3.2.2 构建信任：一步一个脚印

试图开发一个面面俱到的产品往往会陷入平庸。为了打造出吸引人的产品，公司需致力于打造让用户不断回归的吸引力体验。

设想一个旨在解答用户任何问题的通用 RAG 系统。这种系统因为不专注而无法优先处理最新信息、解析领域特定格式或充分理解特定任务的复杂性。结果就是用户只能得到一个肤浅且不稳定的体验，很难满足他们的需求，最终导致用户流失。

解决这个问题的办法是专注于特定领域和具体应用场景，深耕细作而不是广撒网。这样做不仅可以开发出与用户需求高度契合的领域工具，而且可以清楚地告知用户系统的功能和局限。系统的透明度不仅能增强自我认知，也让用户明确知道这套系统能在哪些方面为他们带来最大的价值，从而建立起信任和信心。

3.2.3 构建大语言模型运维 (LLMOps)，目标明确：追求更快的迭代链接

DevOps 的本质并非仅在于建立可复制的工作流程，或是提前介入、赋能小团队 —— 它绝对不只是写 YAML 文件那么简单。

DevOps 的真正意义在于缩短工作与结果之间的反馈周期，使得优化能持续积累，而非错误。其思想源自精益生产及丰田生产系统，强调的是迅速换模和持续的改进 (Kaizen)。

而当 MLOps 将 DevOps 应用于机器学习时，虽有可复现的实验和一体化工具套件支持模型开发，但问题是，它并没有缩小模型在实际运用中的反馈延迟。

值得欣慰的是，大语言模型运维 (LLMOps) 正从处理小问题如提示管理转向更为严峻的挑战：通过评估连接的生产监控和持续改进。

现已出现了如 LangSmith、Log10、LangFuse、W&B Weave、HoneyHive 等工具，这些不仅能收集和整理生产数据，更能通过与开发的深度融合，利用这些数据优化系统。可以选择使用这些工具，或是自行开发。

3.2.4 避免自行开发可购买的大语言模型 (LLM) 功能

大部分成功的企业并非依赖大语言模型 (LLM) 运营。然而，大多数公司都能通过大语言模型 (LLM) 提升业务效率。

这两个观点常常误导领导层急于将大语言模型 (LLM) 整合进现有系统，不仅增加了成本，也降低了效率，并以此推出带有现已令人厌恶的闪光标志的伪装“AI”功能。有一种更理智的方法：关注那些真正符合你的产品目标并能够提升核心业务的大语言模型 (LLM) 应用。

以下是一些误入歧途的尝试，它们浪费了团队的时间：

为你的业务开发定制的文本到 SQL (text-to-SQL) 功能。
创建一个能与你的文档进行对话的聊天机器人。
将你公司的知识库与客户支持聊天机器人进行整合。

尽管这些都是大语言模型 (LLM) 应用的基础示例，但对一个产品公司来说自行开发它们并不明智。这些普遍存在的问题，从看似有前景的演示到可靠的组件之间，存在巨大的鸿沟，这通常是软件公司的主战场。将宝贵的研发资源投入到当前 Y Combinator 一批批正在解决的普遍问题中，实在是不智之举。

如果这听起来是陈词滥调的商业建议，那只是因为在当前的炒作浪潮中，很容易被“大语言模型 (LLM)”这样的前沿标签所迷惑，而忽视了那些已经成为常态的应用。

3.2.5 人工智能参与其中；人类处于核心

目前，由大语言模型驱动的应用非常脆弱。它们需要大量的安全防护和防御性工程设计，但预测难度依旧很大。然而，在功能定位精确时，这些应用却能展现出惊人的效用。这表明，大语言模型是加快用户工作流程的优秀工具。

虽然可以设想将基于大语言模型的应用完全取代某个工作流程或职能，但在当今，最有效的模式实际上是人机协作模式（如“半人马象棋”(Centaur chess)）。当能力出众的人类与专为快速应用而优化的大语言模型功能结合时，执行任务时的效率和满意度可以大幅提升。GitHub CoPilot 作为大语言模型的标志性应用之一，其强大的工作流程效果已经得到证实：

“开发者们反馈，使用 GitHub CoPilot 和 GitHub CoPilot Chat 后，他们编程时感觉更自信，因为编码过程更简单、更少出错、更易于阅读、更易于重用、更加简洁、更易维护，且更具有弹性，比起没有使用这些工具时效果更佳。” - Mario Rodriguez, GitHub

对于长期从事机器学习的专家来说，可能会马上想到“人在循环中”这一概念，但情况稍有不同。人在循环中的机器学习模式侧重于由人类专家确保模型按预期行为运行。尽管这与我们提出的观点相关，但我们在这里强调的是更为细微的差别。大语言模型驱动的系统不应成为现今大部分工作流程的主导力量，而应仅作为一种辅助资源。

将人类置于核心，探询大语言模型如何扶持他们的工作流程，可以引发截然不同的产品和设计决策。这最终会促使你开发出与那些急于将所有责任推给大语言模型的竞争对手不同的产品——更优质、更实用、风险更低的产品。

3.3 开始提示、评估和数据收集

前几节向我们提供了众多技巧和建议，信息量巨大。现在让我们回归到最实用的建议：如果一个团队想构建一个大语言模型 (LLM) 产品，他们应从何入手？

过去一年的实践已经足以证明，成功的大语言模型应用都遵循着一条一致的轨迹。本节将介绍这套基本的入门策略。其核心思想是从简单做起，仅在必要时增加复杂性。一个实用的规则是，每增加一层复杂度，通常需要的努力至少是前一层的十倍。这是一个值得记住的点。

3.3.1 从提示工程开始

首先进行提示工程。应用我们之前在策略部分讨论过的所有技术，如思维导图、少样本示例以及结构化的输入与输出，这些通常都是明智之选。应先使用最先进的模型进行原型设计，再考虑提升较弱模型的性能。

只有当提示工程无法实现所需的性能水平时，才考虑进行微调。如果有非功能性需求（如数据隐私、完全控制权或成本问题）阻碍了使用专有模型，导致需要自行托管，这种情况可能会更常见。但务必确保这些隐私需求不会妨碍你使用用户数据来进行微调！

3.3.2 构建评估并启动数据驱动飞轮

即使是初创团队也需要进行评估工作。没有评估，你就无法确定你的提示工程是否足够好，或者何时你的微调模型（fine-tuned model）准备好取代原始模型（base model）。

有效的评估应该针对具体的任务，并且能够反映实际使用情况。我们首先推荐进行单元测试。这种简单的测试可以发现潜在的错误，并帮助我们在项目初期做出设计决策。你还可以查看其他针对特定任务的评估，如分类、总结等。

单元测试和基于模型的评估固然重要，但它们不能取代人工评估的角色。应让用户亲自试用你的模型或产品，并提供反馈。这样不仅可以测试产品在现实世界中的表现和发现可能的缺陷，还可以收集高质量的数据，为将来的模型微调提供帮助。这样形成的正向反馈循环，即数据驱动飞轮，会随着时间推移而逐渐增强：

通过人工评估来测试模型性能或识别问题
利用收集到的数据来微调模型或更新提示
不断重复这一过程

举个例子，当我们在检查由大语言模型生成的摘要时，可能会对每个句子做出详细反馈，指出其中的事实错误、不相关内容或表达风格问题。然后，我们可以利用这些反馈来训练一个识别幻觉的分类器或是一个关于相关性的奖励模型。LinkedIn 也分享了他们如何利用基于模型的评估器来检测生成内容的幻觉、遵守 AI 伦理的情况和内容的连贯性等。

通过这种方式，我们把构建评估从一项单纯的运营成本转变为一种战略投资，并在此过程中逐步构建我们的数据驱动飞轮。

3.4 低成本智能的趋势展望

1971 年，Xerox PARC 的研究者们对未来进行了预测：一个充满网络化个人电脑的世界，正是我们今天所处的环境。他们通过关键性地参与 Ethernet、图形渲染技术、鼠标及窗口系统等发明，为这个未来的到来做出了贡献。

他们还进行了一个简单的预测练习：先是找出那些非常有用却成本高昂的应用（比如视频显示技术），然后根据这些技术的历史价格趋势（参照摩尔定律）来预测它们何时会变得经济实惠。

对于大语言模型技术，我们也可以采取类似的策略。例如，选取广受欢迎的大规模多任务语言理解数据集，配合一致的输入方法（五次尝试），进而比较不同性能等级的语言模型在此基准上运行成本的时间变化。

图 1: 固定成本下，模型能力快速提升；在固定能力水平下，成本则在迅速降低。图由合著者 Charles Frye 在 2024 年 5 月 13 日利用公开数据创建。

从 OpenAI 的 davinci 模型作为 API 发布至今四年间，执行相同任务的模型运行成本，从每百万字符 20 美元降至不到 10 美分，减半时间仅需六个月。至 2024 年 5 月，通过 API 或自行部署 Meta 的 LLaMA 3 8B 的成本仅为每百万字符 20 美分，与 OpenAI 的 text-davinci-003 表现相当，而后者在 2023 年底发布时，每百万字符的成本也是 20 美元。仅在 18 个月内，成本已经减少了两个数量级，这比摩尔定律预测的翻倍速度要快得多。

现在，我们来看看大语言模型（LLM）的一个非常实用的应用：为生成式视频游戏角色赋能，类似于 Park et al 的研究。虽然目前这种应用的成本还不够经济（据此处估计，其成本为每小时 625 美元），但自从该论文于 2023 年 8 月发布以来，成本已经大幅下降，目前约为每小时 62.50 美元。预计在未来九个月内，这一成本可能进一步降至每小时 6.25 美元。

同时，回顾 1980 年推出的吃豆人游戏，当时 1 美元可以让你玩几分钟到几十分钟，相当于每小时大约六场游戏，或者每小时消费 6 美元。这样一来，通过粗略估算可以看出，到 2025 年，引人入胜的大语言模型增强的游戏体验将变得更加经济实惠。

这些趋势尽管只出现了几年，但未来几年内这一进程减缓的可能性很小。尽管我们可能已经利用了一些算法和数据集中较容易取得的成果，如超越“Chinchilla 比率”（约每个参数 20 个 token），但数据中心和硅层的深层次创新和投资有望补足这一不足。

更为关键的战略看点是：今天看似完全不可行的展示或研究，几年后可能变成高端功能，随后很快普及成为常见产品。我们应以此为考虑，构建我们的系统和组织结构。

4 从零到一的演示已足够，现在是时候开发从一到多的产品了

我们知道，开发大语言模型 (LLM) 的演示项目非常吸引人。只需几行代码、一个向量数据库和一个精心设计的提示语，我们便能创造出令人惊叹的效果✨。过去一年中，这种创新被频繁地比喻为互联网、智能手机乃至印刷机的重大突破。

然而，正如任何一位有经验的软件开发者都会明白，一个在实验环境中表现良好的演示和一个在实际应用中能够稳定运行的产品，二者之间存在着巨大的差异。

有许多问题看似易于构思和演示，实际上要将其发展成成熟的产品却异常艰难。以自动驾驶为例，演示一辆汽车在街区自行驾驶似乎轻而易举，但要真正将其商业化则可能需要十年的时间。 - Andrej Karpathy

举自动驾驶汽车为例，最初的由神经网络控制的汽车诞生于 1988 年。二十五年后，Andrej Karpathy 体验了 Waymo 的首次试驾。再过十年，该公司获得了无人驾驶许可证。从原型到商品化，整整经历了三十五年的精心工程设计、反复试验、持续改进以及严格的法规遵守。

在工业界和学术界，我们观察到了过去一年 LLM 应用的跌宕起伏。我们希望从我们学到的课程中——包括如评估、构建提示和安全防护的战术措施，到运营技术和团队建设，再到如何内部培养能力的战略洞察——能帮助您在未来的第二年及其后，一同推动这项激动人心的新技术。

5 保持联系

如果您发现这些内容有用，并想获取最新的文章、课程和活动更新，请点击下方订阅。

您也可以在我们的关于页面上查找到我们的个人联系信息。

6 致谢

这一系列文章起源于一次群聊中的对话，当时 Bryan 开玩笑说他打算写《AI 工程的一年》。随后，✨奇迹✨ 发生了，我们大家开始互相分享迄今为止学到的知识。

我们要特别感谢 Eugene，他不仅负责了大部分文档的整合和整体架构，还贡献了众多课程内容。同时，他还担任了文档的主编辑。我们还要感谢 Bryan，正是他的点子激发了这篇总结的诞生，他还帮助将内容结构化为战术、运营和战略部分，并激励我们思考如何更好地服务社区。感谢 Charles 对成本控制和 LLMOps 的深入研究，以及他在整合课程内容上的努力，正因为他，这篇文章才精简至 30 页而非 40 页。我们也要感谢 Hamel 和 Jason，他们从顾问服务和前线经验中汲取的洞察，以及对工具的深厚理解，都为我们提供了宝贵的学习资源。最后，感谢 Shreya 提醒我们评估和严格生产实践的重要性，她的研究成果也极具启发性。

最后，我们感谢所有那些慷慨分享自己经验教训的团队，以及活跃参与此次讨论的 AI 社区成员。

6.1 关于作者

想了解更多作者信息，请访问关于页面。

若本文对您有帮助，请按以下方式引用：

严歌苓，Bryan Bischof, Charles Frye, Hamel Husain, 刘嘉显，以及 Shreya Shankar. 2024. ‘应用大语言模型 - 我们在构建大语言模型的一年中学到了什么’. 应用大语言模型。2024 年 6 月 8 日。https://applied-llms.org/.

或

@article{AppliedLLMs2024,
  title = {What We've Learned From A Year of Building with LLMs},
  author = {Yan, Eugene and Bischof, Bryan and Frye, Charles and Husain, Hamel and Liu, Jason and Shankar, Shreya},
  journal = {Applied LLMs},
  year = {2024},
  month = {Jun},
  url = {https://applied-llms.org/}
}

使用大语言模型 (LLMs) 构建产品一年后的经验总结 [译]