大语言模型（LLM）构建产品的一年经验总结【干货长文】

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

现在是构建大型语言模型（LLM）的激动人心的时刻。在过去的一年里，LLM已经变得足够好，可以用于实际应用。而且它们每年都在变得更好更便宜。伴随着社交媒体上的一系列演示，预计到2025年，AI的投资将达到2000亿美元[11]。此外，供应商的API使LLM更加易于访问，使得不仅仅是机器学习工程师和科学家，任何人都可以将智能嵌入到他们的产品中。然而，尽管构建AI的入门门槛已经降低，创建有效的产品和系统，相比单纯的演示而言要困难许多。

我们过去一年都在构建过程中，发现了许多困难的挑战。尽管我们不能代表整个行业发言，但我们希望分享我们学到的经验，以帮助你避免我们的错误并更快地迭代。这些内容分为三个部分：

战术[12]：关于提示、RAG、流程工程、评估和监控的一些实践。不管你是使用LLM的从业者，还是周末项目的黑客，这部分都是为你而写。
运营[13]：关于发布产品的组织和日常问题，以及如何建立一个有效的团队。适合希望可持续和可靠地部署产品/技术的领导者。
战略[14]：长期、大局观的观点，以及“在找到市场契合点之前不要使用GPU”和“关注系统而非模型”等观点，适合创始人和高管们。

我们打算将其打造为使用LLM构建成功产品的实用指南，借鉴我们的经验并指出行业内的实例。

准备好深入研究了吗？让我们开始吧。

战术：使用LLM的细节与实用技巧

在这一部分，我们分享了关于新兴LLM堆栈核心组件的最佳实践：改进质量和可靠性的提示技巧、评估策略、增强生成（RAG）的想法、如何设计人机协同工作流程等。尽管技术仍处于初期阶段，我们相信这些经验具有广泛的适用性，能够帮助你发布稳健的LLM应用。

提示技巧

在新应用原型设计时，我们建议从提示词入手。人们容易低估和高估其重要性。低估是因为正确的提示技巧在使用得当时，可以走得很远。高估是因为即使是基于提示的应用，也需要围绕提示进行大量工程设计才能很好地工作。

集中精力充分利用基本的提示技巧

一些提示技巧在各种模型和任务中始终有助于提高性能：n-shot提示+上下文学习、思维链（Chain-of-Thought）和提供相关资源。

上下文学习通过n-shot提示的想法是向LLM提供示例，展示任务并将输出对齐到我们的期望。几点建议：

如果n太低，模型可能会过于依赖那些具体示例，影响其泛化能力。通常情况下，n ≥ 5。如果可能，不妨提供几十个示例。
示例应能代表产品的分布。如果你在构建电影摘要器，应包括不同类型的电影样本，大致与实践中预期看到的比例相同。
不一定总是需要提供输入-输出对；仅提供期望输出的示例可能就足够。
如果计划让LLM使用工具，应包括使用这些工具的示例。

思维链（Chain-of-Thought，CoT）提示中，我们鼓励LLM在返回最终答案之前解释其思维过程。可以将其视为给LLM提供草稿本，使其不必在内存中完成所有工作。最初的方法是简单地将“让我们一步一步思考”作为指令的一部分，但我们发现使CoT更具体，在指令中添加一句或两句具体描述，通常可以显著减少幻觉率。

例如，在要求LLM总结会议记录时，我们可以明确步骤：

首先，列出关键决策、后续事项及其相关负责人。
然后，检查草稿本中的细节是否与记录一致。
最后，将关键点综合成简洁的总结。

需要注意的是，最近一些研究[15]质疑这种技术是否真的像人们认为的那样强大。此外，关于在推理过程中究竟发生了什么也存在很大争议。不管怎样，这种技术在可能的情况下值得一试。

提供相关资源是扩展模型知识库、减少幻觉和增加用户信任的有效机制。通常通过增强生成（RAG）实现，为模型提供其可以直接在响应中利用的文本片段是一个基本技巧。在提供相关资源时，光是包括它们还不够；别忘了告诉模型优先使用这些资源，直接引用它们，并在没有足够资源时提到这些情况。这有助于将代理响应与资源库“对接”。

结构化输入和输出

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

例如，互联网上许多关于写SQL的问题通常从指定SQL模式开始。因此，有效的文本到SQL提示应包括结构化模式定义[16]。

结构化输入清晰地表达任务，并类似于训练数据的格式，增加了更好输出的概率。结构化输出简化了与系统下游组件的集成。Instructor[17]和Outlines[18]在结构化输出方面表现良好。（如果你导入LLM API SDK，请使用Instructor；如果你使用自托管模型，请使用Outlines。）

使用结构化输入时，请注意每个LLM家族都有自己的偏好。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个标记的怪物。更糟糕的是，它在更常见和简单的输入上的表现更差！GoDaddy分享了构建LLM的第一课[19]就是这个挑战。

就像我们努力保持系统和代码简单一样，我们也应该保持提示的简单。与其为会议记录摘要器编写一个通用提示，不如将其分解为多个步骤：

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

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

设计你的上下文标记

重新思考并挑战你关于发送给代理的上下文数量的假设。像米开朗基罗一样，不要建造你的上下文雕塑，而是雕刻掉多余的材料，直到雕塑呈现出来。RAG是一种汇集所有可能相关信息块的流行方式，但你在提取必要信息时做了什么？

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

另一个关键优化是上下文的结构。如果你的文档包表示对人类无用，不要假设它对代理有用。仔细考虑如何组织你的上下文，以突出其各部分之间的关系，使提取尽可能简单。

可以到这里查看更多提示基础[20]，如提示思维模型、预填、上下文放置等。

信息检索 / RAG

除了提示，另一种有效引导LLM的方法是提供知识作为提示的一部分。这使LLM在提供的上下文上进行学习，被称为检索增强生成（RAG）。实践者发现，RAG在提供知识和改进输出方面非常有效，同时比微调所需的努力和成本少得多。

RAG的质量取决于检索文档的相关性、密度和细节

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

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

像传统的推荐系统一样，检索项的排名对LLM在下游任务中的表现有重大影响。为了衡量影响，可以运行一个基于RAG的任务，但将检索项随机打乱，看看RAG输出的表现如何。

其次，我们还要考虑信息密度。如果两个文档同样相关，我们应该优先选择更简洁、无多余细节的文档。回到我们的电影示例，我们可能会认为电影的完整剧本和所有用户评论在广义上是相关的。然而，最高评级的评论和编辑评论可能会包含更多信息。

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

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

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

尽管嵌入毫无疑问是一种强大的工具，但它们并非万能。首先，尽管它们擅长捕捉高层语义相似性，但在处理更具体的基于关键词的查询时可能会遇到困难，例如用户搜索名称（如Ilya）、缩写词（如RAG）或ID（如claude-3-sonnet）时。基于关键词的搜索，如BM25，正是为此设计的。最后，在多年使用基于关键词的搜索之后，用户可能已经习惯于这种方式，如果他们预期检索到的文档没有返回，可能会感到沮丧。

矢量嵌入 并不会 神奇地解决搜索问题。实际上，主要的工作是在你用语义相似性搜索重新排序之前的步骤。真正改进BM25或全文搜索是很难的。——Aravind Srinivas, Perplexity.ai首席执行官[23]

我们已经向我们的客户和合作伙伴传达了几个月了。使用简单嵌入的最近邻搜索会产生非常嘈杂的结果，你可能更应该从关键词搜索开始。——Beyang Liu, Sourcegraph首席技术官[24]

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

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

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

RAG和微调都可以用于将新信息整合到LLM中，并提高特定任务的性能。然而，我们应该优先考虑哪一种？

最新研究表明RAG可能具有优势。一项研究[26]比较了RAG与无监督微调（即继续预训练），在MMLU子集和当前事件上进行了评估。他们发现，RAG在处理训练期间遇到的知识和全新知识时，表现都优于微调。在另一篇论文[27]中，他们将RAG与有监督微调在农业数据集上进行了比较。同样，RAG的性能提升超过了微调，尤其是在GPT-4上（见表20）。

除了改进性能外，RAG还有其他实际优势。首先，相对于持续预训练或微调，保持检索索引的更新更容易且更便宜。其次，如果我们的检索索引包含有毒或偏见内容的有问题文档，我们可以轻松删除或修改这些文档。可以将其视为一种文档中的安东绳[28]，用来检测并排除有问题的内容。

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

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

随着Gemini 1.5提供的上下文窗口大小达到1000万个标记，一些人开始质疑RAG的未来。

我倾向于认为Gemini 1.5被Sora大大夸大了。上下文窗口大小为1000万个标记基本上使现有的大多数RAG框架变得不必要——你只需将所有数据放入上下文中，像平常一样与模型对话。想象一下，这对所有初创公司/代理/语言链项目意味着什么，其中大多数工程工作都用于RAG😅或者一句话：1000万个上下文标记杀死了RAG。干得好Gemini——Yao Fu[29]

尽管长上下文对分析多个文档或与PDF聊天等用例将是一个游戏规则改变者，但RAG的消亡谣言被大大夸大了。

首先，即使有1000万个标记的上下文窗口，我们仍然需要一种选择相关上下文的方法。其次，除了狭窄的草堆找针/大海捞针评估外，我们还没有看到令人信服的数据，表明模型可以有效地在大上下文大小上进行推理。因此，没有好的检索（和排序），我们有可能使模型被干扰项淹没，或者可能在上下文窗口中填充完全不相关的信息。

最后，是成本问题。在推理期间，Transformer的时间复杂度随着上下文长度线性增加。尽管存在可以在回答每个问题之前读取整个组织的Google Drive内容的模型，但这并不是一个好主意。可以类比我们如何使用RAM：我们仍然从磁盘读取和写入，即使存在运行内存达到几十TB的计算实例（如AWS的高内存实例）。

所以不要急着扔掉你的RAG。即使上下文大小增加，这种模式仍将保持有用。

调优和优化工作流程

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

分步、多轮“流程”可以大幅提升性能

将单个大提示分解为多个小提示可以获得更好的结果是常识。例如，AlphaCodium[30]：通过从单个提示切换到多步骤工作流程，他们将GPT-4在CodeContests上的准确率（pass@5）从19%提高到44%。工作流程包括：

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

小任务具有明确的目标，适合作为代理或流程提示。并不是每个代理提示都需要请求结构化输出，但结构化输出有助于与代理与环境交互的系统进行接口。可以尝试以下几种方法：

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

现在优先考虑确定性的工作流程

虽然AI代理可以动态响应用户请求和环境，但其非确定性本质使其难以部署。每个代理步骤都有失败的可能，而从错误中恢复的机会很小。因此，代理完成多步骤任务的成功概率随着步骤数量的增加呈指数下降。因此，构建代理的团队发现很难部署可靠的代理。

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

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

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

最终，构建可靠的工作代理的关键可能在于采用更结构化、确定性的方法，以及收集数据以改进提示和微调模型。没有这些，我们构建的代理可能在某些时候表现异常好，但总体上让用户失望。

获取更多多样化输出的方法

假设你的任务需要LLM输出的多样性。也许你正在编写一个LLM管道，以根据用户以前购买的产品列表推荐新的产品。当多次运行你的提示时，你可能会注意到生成的推荐太相似——所以你可能会增加LLM请求中的温度参数。

简单来说，增加温度参数会使LLM的响应更加多样化。在采样时，下一标记的概率分布变得更平坦，通常不太可能的标记更频繁地被选择。然而，增加温度时，你可能会注意到与输出多样性相关的一些失败模式。例如，某些可能合适的产品可能永远不会被LLM输出。如果温度太高，你可能会得到引用不存在产品（或胡言乱语）的输出！

换句话说，增加温度并不保证LLM会按你预期的概率分布采样输出（例如，均匀随机）。然而，我们还有其他技巧来增加输出多样性。最简单的方法是调整提示中的元素。例如，如果提示模板包含一个项目列表，如历史购买，每次将这些项目插入提示时打乱其顺序会产生显著差异。

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

缓存被低估了

缓存节省成本并消除生成延迟，通过消除为相同输入重新计算响应的需要。此外，如果之前已对响应进行审核处理，我们可以提供这些经过认证的响应，减少提供有害或不适当内容的风险。

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

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

何时进行微调

我们可能有一些任务，即使设计最巧妙的提示也无法满足。例如，即使在进行了大量提示工程后，我们的系统可能仍然无法返回可靠的高质量输出。如果是这样，那么可能需要对模型进行微调以完成特定任务。

成功的示例包括：

Honeycomb的自然语言查询助手[32]：最初，“编程手册”与n-shot示例一起提供，用于上下文学习。虽然效果尚可，但对模型进行微调后，输出在语法和领域特定语言规则上有所改进。
Rechat的Lucy[33]：LLM需要生成一种非常特定的格式，该格式结合了结构化和非结构化数据，以便前端正确渲染。微调对于使其稳定工作至关重要。

尽管如此，尽管微调可以有效，但它带来了显著成本。我们必须标注微调数据、微调和评估模型，并最终自托管它们。因此，考虑前期成本是否值得。如果提示已经让你达到了90%的目标，那么微调可能不值得投资。然而，如果我们决定进行微调，为了降低收集人工标注数据的成本，我们可以生成并使用合成数据进行微调[34]，或使用开源数据进行引导[35]。

评估与监控

评估LLM是一个雷区[36]，即使是最大的实验室也发现它具有挑战性[37]。LLM返回开放式输出，我们设置的任务多种多样。尽管如此，严格而周到的评估至关重要——OpenAI的技术领导们也在进行工作评估并对个别评估提供反馈[38]。

评估LLM应用涉及多种定义和简化：它只是单元测试，或更像可观察性，或者只是数据科学。我们发现这些视角都很有用。在本节中，我们提供了一些关于构建评估和监控管道的重要经验。

从真实输入/输出样本

创建几个基于断言的单元测试

创建单元测试（即断言）[39]，包括来自生产的输入和输出样本，并基于至少三个标准对输出进行预期。尽管三个标准可能看似武断，但这是一个实际的起点；较少可能表明你的任务定义不充分或太开放，例如通用聊天机器人。这些单元测试或断言应由管道中的任何更改触发，无论是编辑提示，添加新上下文通过RAG，还是其他修改。这里的示例[40]，展示了一个实际使用案例的基于断言的测试。

考虑从指定包含或排除响应的短语开始。还可以尝试检查字数、项目数或句子数是否在范围内。对于其他类型的生成，断言可能会有所不同。基于执行的评估[41]是一种评估代码生成的方法，其中运行生成的代码并检查运行时状态是否满足用户请求的要求。

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

最后，像客户那样使用你的产品（即“dogfooding”）可以提供有关实际数据失败模式的洞见。这种方法不仅有助于识别潜在弱点，还提供了可转换为评估的生产样本来源。

LLM作为评判者可以工作（某种程度上），但不是万能药

LLM作为评判者，即使用强LLM评估其他LLM的输出，备受质疑。（我们中的一些人最初对此持巨大怀疑态度。）尽管如此，如果实施得当，LLM作为评判者可以实现与人类判断的良好相关性，并至少有助于建立对新提示或技术表现的先验。特别是在做成对比较时（控制与处理），LLM作为评判者通常能得出正确的方向，尽管胜/负的幅度可能不稳定。

以下是一些建议，帮助你最大限度地利用LLM作为评判者：

使用成对比较：而不是让LLM对单个输出评分，呈现两个选项并让它选择更好的一个。这通常会带来更稳定的结果。
控制位置偏差：选项的顺序会影响LLM的决定。为减轻这种影响，每次进行成对比较时交换选项顺序。只要在交换后确保胜利归于正确的选项！
允许平局：在某些情况下，两个选项可能同样好。因此，允许LLM宣布平局，使其不必随意选一个赢家。
使用思维链：在给出最终答案之前让LLM解释其决定，可以提高评估的可靠性。一个额外的好处是，这允许你使用更弱但更快的LLM，仍然能取得类似的结果。因为这一部分管道通常批量运行，思维链带来的额外延迟不是问题。
控制响应长度：LLM倾向于偏向更长的响应。为减轻这种影响，确保响应对长度相似。

LLM作为评判者的一个有用应用是检查新提示策略是否有回归。如果你跟踪了一组生产结果示例，有时你可以用新提示策略重新运行这些生产示例，并使用LLM作为评判者快速评估新策略的表现。

这是一个简单但有效的方法[42]，用于迭代LLM作为评判者，记录LLM响应、评判者的批评（即思维链）和最终结果。然后与利益相关者一起审查以确定改进的领域。通过三次迭代，与人类和LLM的协议从68%提高到94%！

图1

然而，LLM作为评判者并非万能药。在语言的细微方面，即使是最强的模型也难以可靠评估。此外，我们发现传统分类器[43]和奖励模型的准确性高于LLM作为评判者，且成本和延迟更低。对于代码生成，LLM作为评判者可能不如更直接的评估策略如执行评估。

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

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

如果答案是否定的，且这是因为LLM缺乏所需知识，考虑丰富上下文的方法。
如果答案是否定的，且我们无法改进上下文来解决，那么我们可能遇到了对当代LLM来说太难的任务。
如果答案是肯定的，但需要很长时间，我们可以尝试减少任务的复杂性。它是否可以分解？任务的某些方面是否可以模板化？
如果答案是肯定的，他们会很快完成，那么是时候深入研究数据了。模型哪里出错了？能否找到失败模式？尝试在响应前或响应后让模型解释自己，以帮助你建立心智模型。

过度强调某些评估可能会损害整体性能

“当一个指标成为目标，它就不再是一个好的指标。”——古德哈特定律。

一个例子是大海捞针（NIAH）评估。最初的评估帮助量化了上下文大小增长时模型的召回率，以及针的位置对召回率的影响。然而，它被过度强调，以至于成为Gemini 1.5报告的图1[44]。评估涉及在长文档中插入特定短语（“The special magic {city} number is: {number}”），然后提示模型回忆魔法数字。

尽管一些模型实现了近乎完美的召回，但质疑NIAH是否真正衡量了实际应用中所需的推理和召回能力。例如，给定一个小时长的会议记录，模型能否总结关键决策和后续步骤，并正确归因于相关人员？这个任务更现实，不仅仅是机械记忆，还考虑了解析复杂讨论、识别相关信息和综合总结的能力。

这是一个实际NIAH评估的例子[45]。使用医生-患者记录[46]，LLM被查询关于患者用药情况。还包括一个更具挑战性的NIAH，插入随机成分的披萨配料短语，如“The secret ingredients needed to build the perfect pizza are: Espresso-soaked dates, Lemon, and Goat cheese.”。在用药任务上的召回率约为80%，在披萨任务上的召回率约为30%。

图2

顺便提一下，过度强调NIAH评估可能会降低抽取和总结任务的性能。因为这些LLM过度调优，以至于关注每一句话，它们可能会将不相关的细节和干扰项视为重要，因而将其包含在最终输出中（当它们不应该这样做时！）

这也可能适用于其他评估和用例。例如，总结。强调事实一致性可能会导致总结不够具体（因此不太可能出现事实不一致），可能也不太相关。相反，强调写作风格和优雅可能会导致更华丽的营销语言，可能引入事实不一致。

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

提供开放式反馈或对模型输出的评分在李克特量表[47]上是认知上很费劲的任务。因此，收集的数据更嘈杂——由于人类评分者之间的可变性——因此不太有用。一种更有效的方法是简化任务，减轻评分者的认知负担。两种有效的方法是二元分类和成对比较。

在二元分类中，评分者被要求对模型的输出做出简单的“是”或“否”判断。他们可能被问及生成的摘要是否与源文档事实一致，或建议的响应是否相关，或是否包含有害内容。相比李克特量表，二元决策更精确，评分者之间的一致性更高，吞吐量也更高。Doordash就是这样设置他们的标签队列的[48]，通过一个树状的“是-否”问题对菜单项进行标签。

在成对比较中，评分者会看到一对模型响应，并被要求选择更好的一个。因为对人类来说“A比B好”比单独为A或B评分更容易，这导致了更快、更可靠的注释（相比李克特量表）。在一次Llama2会议[49]上，Llama2论文的作者Thomas Scialom确认，成对比较比收集监督微调数据（如书面响应）更快、更便宜。前者的成本为每单位3.5美元，而后者的成本为每单位25美元。

如果你在编写标签指南，可以参考这些示例指南[50]来自Google和Bing搜索。

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

防护有助于捕捉不适当或有害内容，而评估有助于衡量模型输出的质量和准确性。如果你的评估没有参考标准，它们也可以用作防护。无参考评估是指不依赖“黄金”参考（如人类写的答案），仅基于输入提示和模型响应来评估输出质量。

一些示例包括总结评估[51]，我们只需要考虑输入文档来评估总结的事实一致性和相关性。如果总结在这些指标上得分较低，我们可以选择不向用户显示它，从而实际上将评估用作为一种防护措施。类似地，无参考翻译评估[52]可以评估翻译质量而不需要人类翻译的参考，同样允许我们将其用作防护。

LLM会在不应该的时候返回输出

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

虽然我们可以尝试提示LLM返回“不可用”或“未知”响应，但这并不可靠。即使我们能得到预测概率，它们也是输出质量的一个差指标。尽管预测概率表示标记出现在输出中的可能性，但它们不一定反映生成文本的正确性。相反，对于训练用来回答查询和生成连贯响应的指令调整模型，预测概率可能没有很好校准。因此，尽管高预测概率可能表示输出流利且连贯，但并不意味着它是准确或相关的。

尽管精心设计的提示工程在一定程度上有帮助，我们应辅以健全的防护来检测和过滤/重新生成不期望的输出。例如，OpenAI提供了一个内容审核API[53]，可以识别不安全的响应，如仇恨言论、自残或性内容。同样，有许多用于检测个人身份信息[54]的包。一个好处是防护在很大程度上与用例无关，因此可以广泛应用于所有输出。此外，通过精确检索，我们的系统可以确定地响应“我不知道”，如果没有相关文档的话。

一个相关的问题是LLM可能在预期时未能生成输出。这可能由于各种原因，从API提供者的尾部延迟到输出被内容审核过滤器阻止的更复杂问题。因此，持续记录输入和（潜在的缺失）输出对于调试和监控非常重要。

幻觉问题顽固

与内容安全或PII缺陷不同，它们受到广泛关注，因此很少发生，而事实不一致问题顽固且更难检测。它们更常见，发生基线率为5-10%，而据我们从LLM提供者处了解，即使在简单任务如总结上，也难以将其降至2%以下。

为了解决这个问题，我们可以结合提示工程（生成前）和信息真实性检测（生成后）。提示工程中，思维链技术通过让LLM在返回最终输出前解释其推理，有助于减少幻觉。然后，我们可以应用一个信息真实性检验[55]来评估总结的真实性，并过滤或重新生成幻觉。在某些情况下，幻觉可以确定性地检测。当使用RAG检索的资源时，如果输出是结构化的并标识了资源，我们应该能够手动验证它们来自输入上下文。

运营：日常和组织关注

数据

就像食材的质量决定了菜肴的味道一样，输入数据的质量限制了机器学习系统的性能。此外，输出数据是判断产品是否工作的唯一方式。所有作者都专注于数据，每周花费数小时查看输入和输出，以更好地了解数据分布：它的模式、边缘情况和模型的局限性。

检查开发-生产偏差

传统机器学习管道中的一个常见错误来源是训练-服务偏差。这发生在训练中使用的数据与模型在生产中遇到的数据不同的情况。虽然我们可以在没有训练或微调的情况下使用LLM，因此没有训练集，但开发-生产数据偏差也会发生。基本上，我们在开发期间测试系统的数据应当与系统在生产中面临的数据保持一致。如果不一致，我们可能会发现生产准确性受到影响。

LLM开发-生产偏差可分为两种类型：结构性和基于内容的偏差。结构性偏差包括格式差异，如JSON字典中值的列表类型与JSON列表之间的差异、不一致的大小写以及错误如拼写错误或句子片段。这些错误会导致模型性能不可预测，因为不同的LLM在特定数据格式上进行了训练，提示对微小变化高度敏感。基于内容或“语义”偏差指数据的意义或上下文的差异。

和传统的ML一样，定期测量LLM输入/输出对之间的偏差是有用的。简单的指标如输入和输出的长度或特定格式要求（如JSON或XML）是跟踪变化的直接方法。对于更“高级”的漂移检测，考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，例如用户讨论主题的变化，这可能表明他们在探索模型未暴露的新领域。

在测试更改时，如提示工程，确保保留数据集是最新的，并反映最新类型的用户交互。例如，如果生产输入中拼写错误很常见，它们也应该出现在保留数据中。除了数值偏差测量，进行输出的定性评估也很有益。定期审查模型的输出——一种称为“氛围检查”的做法——确保结果与期望一致并继续满足用户需求。最后，将非确定性纳入偏差检查也很有用——通过对测试数据集中的每个输入多次运行管道并分析所有输出，增加了捕捉偶发异常的可能性。

每天查看LLM输入和输出样本

LLM是动态的，不断演变。尽管它们具有令人印象深刻的零样本能力，且输出常常令人愉悦，但其失败模式可能高度不可预测。对于定制任务，定期查看数据样本对于培养LLM表现的直观理解至关重要。

生产中的输入输出对是LLM应用的“真实事物，真实地点”（genchi genbutsu），无法替代。最近的研究[56]强调了开发者对“好”与“坏”输出的看法随着与更多数据的交互而变化（即标准漂移）。虽然开发者可以预先制定一些评估LLM输出的标准，但这些预定义标准通常不完整。例如，在开发过程中，我们可能会更新提示，以增加好响应的概率并减少坏响应的概率。这种评估、重新评估和标准更新的迭代过程是必要的，因为在没有直接观察输出的情况下，很难预测LLM行为或人类偏好。

为有效管理这一点，我们应记录LLM输入和输出。通过每天检查这些日志的样本，我们可以快速识别和适应新模式或失败模式。当发现新问题时，可以立即围绕它编写断言或评估。同样，任何对失败模式定义的更新都应反映在评估标准中。这些“氛围检查”是坏输出的信号；代码和断言将它们操作化。最终，这种态度必须被社会化，例如通过将输入和输出的审查或注释添加到你的随叫随到轮班中。

使用模型

通过LLM API，我们可以依赖少数提供商的智能。虽然这是一个好处，但这些依赖关系也涉及性能、延迟、吞吐量和成本的权衡。此外，随着新模型的推出（在过去一年中几乎每月一次），我们应准备好更新产品，以便弃用旧模型并迁移到新模型。在本节中，我们分享了使用我们无法完全控制的技术的经验教训，其中模型无法自托管和管理。

生成结构化输出以简化下游集成

对于大多数实际用例，LLM的输出将通过某种机器可读格式由下游应用程序使用。例如，Rechat[57]需要结构化响应，以便前端渲染小部件。同样，Boba[58]生成产品战略想法的工具需要结构化输出，包含标题、摘要、可信度评分和时间跨度字段。最后，LinkedIn分享了如何限制LLM生成YAML[59]，用于决定使用哪个技能以及提供调用技能的参数。

这个应用模式是Postel定律的极端版本：在接受（任意自然语言）方面要宽容，在发送（类型化、机器可读对象）方面要保守。因此，我们预计它将非常持久。

目前，Instructor[60]和Outlines[61]是从LLM中引导结构化输出的事实标准。如果你使用LLM API（例如Anthropic, OpenAI），使用Instructor；如果你使用自托管模型（例如Huggingface），使用Outlines。

跨模型迁移提示是个痛苦的过程

有时，我们精心设计的提示在一个模型上效果很好，但在另一个模型上效果不佳。这可能发生在我们切换不同模型提供商之间，或者在升级同一模型的不同版本时。

例如，Voiceflow发现，从gpt-3.5-turbo-0301迁移到gpt-3.5-turbo-1106导致其意图分类任务下降了10%（幸好他们有评估！）。同样，GoDaddy观察到一个正向趋势，升级到版本1106缩小了gpt-3.5-turbo和gpt-4之间的性能差距（或者，如果你是一个乐观主义者，你可能会失望地发现，新的升级减少了gpt-4的领先优势）

因此，如果我们必须跨模型迁移提示，预计这将比简单地更换API端点花费更多时间。不要以为插入相同的提示会带来相似或更好的结果。此外，拥有可靠的自动化评估有助于在迁移前后测量任务性能，减少手动验证的工作量。

版本和固定你的模型

在任何机器学习管道中，“改变任何事物都会改变一切”。当我们依赖诸如大语言模型（LLM）等不是我们自己训练，且可能会在我们不知情的情况下改变的组件时，这一点尤为相关。

幸运的是，许多模型提供商提供了“固定”特定模型版本的选项（例如gpt-4-turbo-1106）。这使我们能够使用特定的模型权重版本，确保它们保持不变。在生产中固定模型版本可以避免模型行为的意外变化，这可能会导致客户抱怨由于模型更换而出现的问题，如输出过于冗长或其他不可预见的失败模式。

此外，考虑维护一个镜像你的生产设置但使用最新模型版本的影子管道。这允许安全地进行实验和测试新版本。一旦你验证了这些新模型的输出的稳定性和质量，可以自信地更新生产环境中的模型版本。

选择能完成任务的最小模型

在开发新应用时，使用最大的、最强的模型是很诱人的。但一旦确定任务在技术上可行，值得尝试看看是否一个更小的模型可以达到类似的结果。

较小模型的好处是延迟和成本更低。虽然它可能较弱，但技术如思维链、多样本提示和上下文学习可以帮助较小模型发挥超常水平。除了LLM API，微调我们的特定任务也有助于提高性能。

综上所述，使用精心设计的工作流程的小模型通常可以匹配甚至超过单个大模型的输出质量，同时更快且更便宜。例如，这条推文[62]分享了Haiku+10样本提示在某些任务上超越零样本Opus和GPT-4的情况。长期来看，我们预计会看到更多流工程[63]使用较小模型，在输出质量、延迟和成本之间找到最佳平衡。

另一个例子是简单的分类任务。像DistilBERT（6700万个参数）这样轻量级模型是一个出人意料的强大基准。400M参数的DistilBART也是一个很好的选择——当在开源数据上微调时，它可以以0.84的ROC-AUC识别幻觉[64]，超过大多数LLM，延迟和成本不到5%。

重点是，不要忽视较小模型。尽管很容易对每个问题使用大模型，但通过一些创造力和实验，我们通常可以找到更有效的解决方案。

产品

尽管新技术提供了新的可能性，但构建优秀产品的原则是永恒的。因此，即使我们在第一次解决新问题，我们也不必在产品设计上重新发明轮子。将LLM应用开发扎根于坚实的产品基础，我们可以为用户提供真正的价值。

早期并频繁地参与设计

拥有设计师会推动你深入理解和思考如何构建和呈现你的产品给用户。我们有时会将设计师刻板印象化为那些让事物变漂亮的人。但除了用户界面之外，他们还会重新思考如何改善用户体验，即使这意味着打破现有规则和范式。

设计师尤其擅长将用户需求重新表述为各种形式。有些形式比其他形式更容易解决，因此可能提供更多或更少的AI解决方案机会。像许多其他产品一样，构建AI产品应围绕要完成的工作，而不是推动它们的技术。

专注于问自己：“用户要求这个产品为他们完成什么工作？这项工作是聊天机器人擅长的吗？自动完成怎么样？也许是其他东西！”考虑现有的设计模式[65]及其与要完成的工作的关系。这些是设计师为你的团队能力带来的无价资产。

设计你的用户体验以进行人类参与

获取高质量注释的一种方法是将人类参与（HITL）集成到用户体验（UX）中。通过允许用户轻松提供反馈和修正，我们可以改善即时输出并收集宝贵数据以改进我们的模型。

想象一个电子商务平台，用户上传并分类他们的产品。有几种方法可以设计UX：

用户手动选择正确的产品类别；LLM定期检查新产品并在后台纠正错误分类。
用户根本不选择任何类别；LLM定期在后台分类产品（可能有错误）。
LLM实时建议产品类别，用户可以根据需要验证和更新。

尽管这三种方法都涉及LLM，但它们提供了非常不同的用户体验。第一种方法将初始负担放在用户身上，LLM作为后处理检查。第二种方法要求用户零努力，但提供了零透明度或控制。第三种方法找到了正确的平衡。通过提前建议类别，我们减少了用户的认知负担，他们不需要学习我们的分类法来分类他们的产品！同时，通过允许用户审查和编辑建议，他们对产品的分类有最终决定权，将控制权牢牢掌握在自己手中。作为一个额外的好处，第三种方法创建了一个自然的反馈循环以改进模型[66]。好的建议会被接受（正面标签），而坏的建议会被更新（负面，然后是正面标签）。

这种建议、用户验证和数据收集的模式在多个应用中常见：

编码助手：用户可以接受建议（强烈肯定），接受并调整建议（肯定），或忽略建议（否定）
Midjourney：用户可以选择放大并下载图像（强烈肯定），变体图像（肯定），或生成一组新图像（否定）
聊天机器人：用户可以对响应提供点赞（肯定）或点踩（否定），或选择重新生成响应（强烈否定）。

反馈可以是显式的或隐式的。显式反馈是产品请求用户提供的信息；隐式反馈是从用户交互中学到的信息，无需用户故意提供反馈。编码助手和Midjourney是隐式反馈的例子，而点赞和点踩是显式反馈。如果我们设计好UX，像编码助手和Midjourney一样，我们可以收集大量隐式反馈来改进我们的产品和模型。

无情地考虑优先级

当我们考虑将演示产品投入生产时，我们必须考虑以下要求：

可靠性：99.9%的正常运行时间，遵守结构化输出
无害性：不生成冒犯性、NSFW或其他有害内容
事实一致性：忠实于提供的上下文，不虚构
有用性：与用户需求和请求相关
可扩展性：延迟SLA，支持的吞吐量
成本：因为我们没有无限预算
还有更多：安全、隐私、公平、GDPR、DMA等。

如果我们试图一次性解决所有这些需求，我们永远不会发布任何东西。因此，我们需要分优先级考虑。无情地。这意味着要清楚什么是不可协商的（例如，可靠性，无害性），没有这些我们的产品无法运作或不可行。这全是关于识别最小可爱的产品。我们必须接受第一个版本不会完美，然后发布并迭代。

根据用例调整风险容忍度

在决定语言模型和应用程序的审查水平时，请考虑用例和受众。对于提供医疗或财务建议的面向客户的聊天机器人，我们需要非常高的安全性和准确性标准。错误或不良输出可能会造成实际伤害并破坏信任。但对于不太关键的应用程序，例如推荐系统，或内部应用程序如内容分类或总结，过于严格的要求只会拖慢进度而不会增加太多价值。

这与最近的a16z报告[67]显示的许多公司在使用LLM时对内部应用程序比外部应用程序进展更快的情况一致。通过尝试AI以提高内部生产力，组织可以在更受控的环境中学习如何管理风险，并开始捕获价值。然后，随着信心的增加，他们可以扩展到面向客户的用例。

企业LLM使用跨内部和外部用例的比例（来源：a16z报告[68]）

团队与角色

定义任何工作职能都不容易，但为这个新领域的工作编写职位描述比其他更具挑战性。我们将放弃交叉职位标题的维恩图或职位描述的建议。然而，我们将承认一个新角色——AI工程师的存在，并讨论其位置。重要的是，我们将讨论团队的其他部分以及责任如何分配。

专注于流程，而不是工具

面对新范式，如LLM，软件工程师倾向于偏爱工具。结果，我们忽视了工具应该解决的问题和流程。在这样做时，许多工程师假设偶然的复杂性，这对团队的长期生产力产生负面影响。

例如，这篇文章[69]讨论了某些工具如何自动创建大语言模型的提示。它认为（IMHO正确）没有首先理解问题解决方法或流程而使用这些工具的工程师最终承担了不必要的技术债务。

除了偶然的复杂性，工具通常是未完全说明的。例如，有一个日益增长的LLM评估工具行业，提供“盒子里的LLM评估”，带有毒性、简洁、语气等的通用评估器。我们看到许多团队在没有认真考虑其领域的特定失败模式的情况下采用这些工具。相比之下，EvalGen专注于教用户创建领域特定评估的过程，通过深度参与每一步，从指定标准、标注数据到检查评估。该软件引导用户完成如下工作流：

Shankar, S., 等（2024）。谁验证了验证者？对齐LLM辅助评估LLM输出与人类偏好的对齐。检索自https://arxiv.org/abs/2404.12272[70]

EvalGen通过最佳实践指导用户创建LLM评估，即：

定义领域特定测试（自动从提示引导）。这些被定义为带有代码的断言或LLM作为评判者。
对齐测试与人类判断的重要性，以便用户可以检查测试是否捕捉到指定标准。
随系统（提示等）变化迭代测试。

EvalGen为开发人员提供了评估构建过程的心智模型，而不将其固定在特定工具上。我们发现，在提供这种背景信息后，AI工程师通常会选择更精简的工具或自己构建。

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

始终在实验

ML产品与实验密切相关。不仅仅是A/B，随机对照试验，还包括频繁尝试修改系统最小组件并进行离线评估。每个人都热衷于评估并不是关于可信度和信心——而是关于使实验变得可能！你的评估越好，你的实验迭代越快，因此你能更快地达到系统的最佳版本。

现在尝试不同方法解决同一问题很常见，因为实验变得如此便宜。收集数据和训练模型的高成本被最小化——提示工程几乎只需要人力。定位你的团队，使每个人都掌握提示工程基础[71]。这鼓励每个人进行实验，并从整个组织带来多样化的想法。

此外，不仅要进行探索性实验，还要利用它们进行开发！有新任务的工作版本吗？考虑让团队中的其他人用不同的方法解决。尝试更快的方式。调查提示技术如思维链或多样本提示，使其质量更高。不要让你的工具束缚实验；如果它是，重建它，或购买更好的工具。

最后，在产品/项目规划期间，留出时间进行评估并进行多次实验。在工程产品的产品规格中加入评估的明确标准。并且在路线图规划期间，不要低估实验所需时间——预计在获得生产许可之前进行多次开发和评估迭代。

赋权每个人使用新的AI技术

随着生成AI的采用增加，我们希望整个团队——不仅仅是专家——了解并感到有能力使用这项新技术。没有比使用LLM更好的方法来发展对LLM工作原理的直觉（例如延迟、失败模式、UX）。LLM相对易于访问：你不需要懂得编码来改进管道的性能，每个人都可以通过提示工程和评估开始贡献。

教育是这一过程的重要组成部分。可以从提示工程基础[72]开始，技术如多样本提示和思维链有助于将模型调条件到期望的输出。那些掌握知识的人也可以教育更多技术方面，如LLM在生成输出时是自回归的。换句话说，虽然输入标记并行处理，但输出标记是顺序生成的。因此，延迟更多取决于输出长度而非输入长度——这是设计用户体验和设定性能预期时的关键考虑因素。

我们可以更进一步，提供动手实验和探索的机会。也许举办一个黑客马拉松？虽然看起来让团队花几天时间在投机项目上很昂贵，但结果可能会让你惊喜。我们知道有一个团队，通过黑客马拉松，加速并几乎完成了他们的三年路线图在一年内。另一个团队的黑客马拉松则催生了创新的用户体验设计，这些设计得益于大语言模型的可能能力，已被列为今年及未来的重点项目。

不要陷入“AI工程就是我需要的一切”的陷阱

新职位标题被创造时，通常会夸大这些角色的能力。随着这些工作的实际范围变得清晰，这通常会导致痛苦的纠正。进入该领域的新手和招聘经理可能会做出夸张的声明或有膨胀的期望。过去十年中一些显著的例子包括：

数据科学家：“比任何软件工程师更擅长统计学，比任何统计学家更擅长软件工程[73]。”
机器学习工程师（MLE）：软件工程师视角的机器学习

起初，许多人认为数据科学家独自足以完成数据驱动的项目。然而，事实证明，数据科学家必须与软件和数据工程师合作才能有效开发和部署数据产品。

这一误解再次出现在AI工程师这一新角色上，一些团队认为AI工程师就是他们需要的一切。实际上，构建机器学习或AI产品需要广泛的专业角色[74]。我们咨询了十几家公司关于AI产品，始终观察到他们认为“AI工程就是一切所需”的陷阱。因此，产品往往难以扩展超出演示，因为公司忽视了构建产品所需的关键方面。

例如，评估和测量对于扩展产品超出氛围检查至关重要。有效评估的技能与机器学习工程师的传统优势对齐——由仅由AI工程师组成的团队可能缺乏这些技能。合著者Hamel Husain在最近关于检测数据漂移[75]和设计领域特定评估[76]的工作中，展示了这些技能的重要性。

这是构建AI产品过程中你需要的角色类型及其时间的粗略进展：

首先，专注于构建产品。这可能包括AI工程师，但不一定。AI工程师对于快速原型和迭代产品（UX，管道等）很有价值。
接下来，通过测量你的系统并收集数据创建正确的基础。根据数据的类型和规模，你可能需要平台和/或数据工程师。你还必须有系统来查询和分析这些数据以调试问题。
然后，你最终会希望优化你的AI系统。这不一定涉及训练模型。基本步骤包括设计指标、构建评估系统、运行实验、优化RAG检索、调试随机系统等。MLE非常擅长这些（尽管AI工程师也可以学习）。除非你完成了前提步骤，否则通常没有意义雇用MLE。

除此之外，你始终需要领域专家。在小公司，理想情况下是创始团队——在大公司，产品经理可以扮演这个角色。了解角色的进展和时间是关键。错误时间雇用（例如，太早雇用MLE[77]）或按错误顺序构建浪费时间和金钱，并导致流失。此外，在阶段1-2期间定期与MLE检查（但不全职雇用）将帮助公司建立正确的基础。

策略：构建LLM而不被超越

成功的产品需要深思熟虑的规划和优先排序，而不是无休止的原型或跟随最新的模型发布或趋势。在本节最后，我们环顾四周，思考构建伟大AI产品的战略考量。我们还讨论团队将面临的关键权衡，如何时构建和何时购买，并建议早期LLM应用开发策略的“剧本”。

在找到产品市场契合度之前不要买GPU

要成为伟大的产品，你需要的不仅仅是一个薄薄的包装围绕某人的API。但是错误的方向更为昂贵。过去一年还见证了大量风险投资，包括一个令人瞠目的六十亿美元A轮融资，花在训练和定制模型上，而没有清晰的产品愿景或目标市场。在本节中，我们将解释为什么立即训练自己模型是一个错误，并考虑自托管的作用。

从头训练（几乎）从来没有意义

对于大多数组织来说，从头预训练LLM是从产品开发中分心的行为。

尽管它很令人兴奋，并且看起来每个人都在做这件事，开发和维护机器学习基础设施需要大量资源。这包括收集数据，训练和评估模型以及部署它们。如果你还在验证产品市场契合度，这些努力将分散开发核心产品的资源。即使你拥有计算能力、数据和技术实力，预训练的LLM可能会在几个月内过时。

考虑BloombergGPT[78]，一个专门为金融任务训练的LLM。模型在363B个标记上进行预训练，由九名全职员工[79]的英勇努力完成，四名来自AI工程，五名来自ML产品和研究。尽管如此，它在这些任务上的表现仍然被gpt-3.5-turbo和gpt-4超越[80]。

这个故事和其他类似的故事表明，对于大多数实际应用来说，从头预训练LLM，甚至在特定领域数据上，不是资源的最佳利用。相反，团队最好将最强的开源模型微调以满足特定需求。

当然有例外。一个闪亮的例子是Replit的代码模型[81]，专门为代码生成和理解训练。通过预训练，Replit能够超越其他更大规模的模型，如CodeLlama7b。但随着其他越来越强大的模型发布，保持效用需要持续投资。

直到证明必要之前不要微调

对于大多数组织来说，微调更多是由FOMO驱动，而不是清晰的战略思考。

组织过早地投资于微调，试图击败“只是另一个包装”的指责。实际上，微调是重型机械，只有在你收集了大量示例并确信其他方法不足时才应部署。

一年前，许多团队告诉我们他们对微调感到兴奋，但却很少找到产品市场契合度，大多数团队后悔他们的决定。如果你要微调，你最好非常自信你已经准备好一次又一次地做，随着基础模型的改进——参见下面的“模型不是产品”和“构建LLMOps”。

什么时候微调实际上是正确的决定？如果用例需要现有模型训练中不可用的数据——并且你已经构建了MVP，证明现有模型不足。但要小心：如果优秀的训练数据对模型构建者来说不容易获得，你从哪里得到它？

LLM驱动的应用程序不是科学展览项目。对它们的投资应与其对企业战略目标和竞争优势的贡献成比例。

从推理API开始，但不要害怕自托管

借助LLM API，初创企业比以往更容易采用和集成语言建模功能，而无需从头训练自己的模型。提供商如Anthropic和OpenAI提供的通用API可以用几行代码为你的产品增添智能。通过使用这些服务，你可以减少投入的努力，而专注于为客户创造价值——这让你可以更快地验证想法和迭代产品市场契合度。

但正如数据库一样，托管服务并不适合每个用例，尤其是随着规模和需求的增加。事实上，在某些情况下，尤其是受监管行业如医疗保健和金融，自托管可能是唯一的选择，因为这些行业要求在不将数据发送到网络之外的情况下使用模型，或出于合同义务或保密要求。

此外，自托管绕过了推理提供商施加的限制，如速率限制、模型弃用和使用限制。此外，自托管使你对模型有完全控制，便于构建差异化、高质量的系统。最后，自托管，特别是微调的模型，可以在大规模下降低成本。例如，Buzzfeed分享了他们如何通过微调开源LLM将成本降低80%[82]。

迭代出优秀的产品

为了在长远上保持竞争优势，你需要考虑除了模型之外的东西，并考虑是什么将使你的产品与众不同。虽然执行速度很重要，但它不应该是你唯一的优势。

模型不是产品，系统才是

对于不构建模型的团队来说，快速的创新步伐是一种恩惠，他们通过追逐上下文大小、推理能力和性价比的提高来构建更好的产品。这种进步既令人兴奋又可预测。综合起来，这意味着模型可能是系统中最不持久的组件。

相反，将精力集中在将提供持久价值的东西上，例如：

评估：可靠衡量模型在任务上的表现
防护：防止任何模型的非期望输出
缓存：通过避免模型来减少延迟和成本
数据飞轮：推动以上所有内容的迭代改进

这些组件创造了比原始模型能力更厚的产品质量护城河。

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

例如，一些团队投资于构建自定义工具以验证专有模型的结构化输出；在这里进行基本投资很重要，但深度投资不是一个好用的时间。OpenAI需要确保当你请求函数调用时，你得到的是有效的函数调用——因为所有客户都希望如此。在这里进行一些“战略性拖延”，构建你绝对需要的东西，等待显而易见的能力扩展。

通过从小处着手建立信任

构建一个试图为所有人做所有事情的产品是平庸的配方。要创建引人注目的产品，公司需要专注于构建让用户不断回来的粘性体验。

考虑一个试图回答用户可能提出的任何问题的通用RAG系统。缺乏专业化意味着系统无法优先考虑最新信息，解析特定领域格式，或理解特定任务的细微差别。结果是用户得到一个浅薄、不可靠的体验，不满足他们的需求，导致流失。

为了解决这个问题，专注于特定领域和用例。通过深入而不是广泛来缩小范围。这将创建与用户产生共鸣的领域特定工具。专业化还允许你明确系统的能力和局限性。透明地展示你的系统可以做什么和不能做什么，展示自我意识，帮助用户了解它在哪里能增加最大的价值，从而建立对输出的信任和信心。

构建LLMOps，目标要明确：更快的迭代

DevOps的本质不在于可重复的工作流或向左转移或授权小团队——当然也不在于编写YAML文件。

DevOps的本质在于缩短工作和结果之间的反馈周期，以便改进积累而不是错误。其根源可追溯到精益创业运动，通过精益制造和丰田生产系统，强调单分钟换模和持续改进。

MLOps已将DevOps的形式适应于ML。我们有可重复的实验和整合所有功能的套件，赋予模型构建者发货的能力。而且，我们有很多YAML文件。

但作为一个行业，MLOps没有采纳DevOps的功能。它没有缩短模型与生产中推理和交互之间的反馈差距。

令人鼓舞的是，LLMOps领域已从关注提示管理等小事转向阻碍迭代的难题：生产监控和持续改进，通过评估连接。

我们已经有了用于中立、众包评估聊天和编码模型的交互竞技场——一个集体迭代改进的外循环。像LangSmith、Log10、LangFuse、W&B Weave、HoneyHive等工具不仅收集和整理生产系统结果的数据，还通过深度整合开发来改进这些系统。拥抱这些工具或自己构建。

不要构建可以购买的LLM功能

大多数成功的企业不是LLM企业。同时，大多数企业有机会通过LLM改进。

这对观察往往误导领导者迅速改造系统，使成本增加，质量下降，并推出伪劣“AI”功能，配有现已令人厌恶的闪亮图标[83]。有更好的方式：专注于与产品目标真正对齐并提升核心运营的LLM应用。

考虑一些误导的冒险，浪费你的团队时间：

为你的业务构建自定义的文本到SQL功能。
构建一个聊天机器人与文档对话。
将公司的知识库与客户支持聊天机器人集成。

尽管这些是LLM应用的示例，但对产品公司来说，自行构建这些没有意义。这些是一般性问题，许多企业需要大量的努力才能从有前景的演示变成可靠的组件——软件公司的传统领域。将宝贵的研发资源投入到当前 Y Combinator 一批批正在解决的普遍问题中，实在是不智之举，简直是浪费。

如果这听起来像陈词滥调的商业建议，那是因为在当前的炒作浪潮中，很容易将任何“LLM”误认为是前沿的而迷惑，而忽视那些应用已经是老掉牙的应用才是常态。

人在循环中；人类在中心

目前，LLM驱动的应用程序是脆弱的。它们需要大量的保护和防御性工程，但仍然难以预测。此外，当范围明确时，这些应用可以非常有用。这意味着LLM是加速用户工作流的优秀工具。

虽然想象LLM应用完全替代一个工作流或担任一个职能的想法很诱人，但今天最有效的范式是人机混合（如赛博象棋[84]）。当有能力的人与调校好快速利用的LLM能力配对时，生产力和完成任务的幸福感可以大大提高。LLM的旗舰应用之一，GitHub CoPilot，展示了这些工作流的力量：

“总体上，开发人员告诉我们，因为GitHub Copilot和GitHub Copilot Chat编程更容易、更少错误、更可读、更可重用、更简洁、更可维护和更具弹性，他们感到更有信心。” - Mario Rodriguez, GitHub[85]

对于那些长期从事ML工作的人，你可能会跳到“人类在循环中”的想法，但不要太快：HITL机器学习是一个基于人类专家确保ML模型按预期表现的范式。虽然相关，但这里我们提出的是更微妙的东西。LLM驱动的系统今天不应成为大多数工作流的主要驱动因素，它们仅应成为一种资源。

以人为中心，并问LLM如何支持他们的工作流，这将导致截然不同的产品和设计决策。最终，它将驱使你构建不同的产品，比试图迅速将所有责任移交给LLM的竞争对手更好、更有用和风险更低的产品。

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

前几节已经提供了大量技术和建议。信息量巨大。让我们考虑最小的有用建议：如果一个团队想构建一个LLM产品，应该从哪里开始？

过去一年，我们看到成功的LLM应用遵循一致的轨迹。在本节中，我们逐步介绍这个基本的“入门”剧本。核心思想是从简单开始，只在需要时增加复杂性。一个不错的经验法则是每个级别的复杂性通常需要至少比前一个级别多一个数量级的努力。记住这一点…

提示工程先行

从提示工程开始。使用我们在策略部分讨论的所有技术。思维链、多样本示例、结构化输入和输出几乎总是个好主意。原型时使用最强大的模型，然后尝试用较弱的模型提升性能来替代。

只有当提示工程无法达到所需的性能水平时，才考虑微调。这将更常见，如果有非功能性要求（例如，数据隐私、完全控制、成本）阻止使用专有模型，从而需要自托管。但务必确保这些隐私要求不会阻止你使用用户数据进行微调！

构建评估并启动数据飞轮

即使刚开始的团队也需要评估。否则，你不知道你的提示工程是否足够，或者你的微调模型是否准备好替换基础模型。

有效评估特定于你的任务[86]并反映预期的用例。我们推荐[87]的第一级评估是单元测试。这些简单的断言检测已知或假设的失败模式，有助于早期设计决策。另见其他任务特定评估[88]如分类、总结等。

虽然单元测试和基于模型的评估很有用，但它们不能替代人工评估。让人们使用你的模型/产品并提供反馈。这双重作用是测量现实世界性能和缺陷率，同时收集可用于微调未来模型的高质量注释数据。这创建了一个正反馈循环或数据飞轮，随着时间的推移会复利：

人工评估以评估模型性能和/或发现缺陷
使用注释数据微调模型或更新提示
重复

例如，在审核LLM生成的摘要时，我们可以对每个句子进行细粒度反馈，标识事实不一致、不相关或风格差。然后，我们可以使用这些事实不一致注释训练幻觉分类器[89]，或使用相关性注释训练相关性奖励模型[90]。另一个例子，LinkedIn分享了使用基于模型的评估[91]估计幻觉、遵守 AI 伦理的情况和内容的连贯性等。

通过创建随着时间推移其价值复利的资产，我们将构建评估从纯粹的运营成本升级为战略投资，并逐步构建我们的数据飞轮。

低成本认知的高层趋势

1971年，Xerox PARC的研究人员预测了未来：我们现在生活的网络个人计算机世界。他们通过在以太网和图形渲染到鼠标和窗口的发明中扮演关键角色帮助实现了这一未来。

但他们还进行了一个简单的练习：他们看了一些非常有用但尚未经济可行的应用（例如视频显示器），然后查看这些技术的历史价格趋势（如摩尔定律），预测这些技术何时变得经济可行。

我们可以对LLM技术做同样的事情，尽管我们没有如晶体管、每美元那样清晰的东西。采取一个受欢迎、长期存在的基准，如大规模多任务语言理解数据集，并使用一致的输入方法（五次提示）。然后，比较具有各种性能水平的语言模型的运行成本的时间变化。

图。对于固定成本，能力迅速增加。对于固定能力水平，成本迅速下降。由合著者Charles Frye使用公开数据创建于2024年5月13日。

在OpenAI的davinci模型作为API发布后的四年中，运行具有相同任务性能的模型的成本在百万标记规模（大约一百份本文）下降从20美元到不到10美分——每六个月就减半。同样，Meta的LLaMA 3 8B模型在2024年5月通过API提供商或自行托管运行，成本仅为每百万标记20美分，其性能与ChatGPT启用的OpenAI的text-davinci-003相当。该模型在2023年11月底发布时每百万标记的成本约为20美元。也就是说，在短短18个月内下降了两个数量级——同一时间框架内摩尔定律仅预测了两倍。

现在，让我们考虑一个非常有用但尚未经济可行的LLM应用（例如驱动生成视频游戏角色，见Park et al[92]）的应用，他们估计其成本为每小时625美元，见此处[93]。自2023年8月发表以来，成本大约下降了一个数量级，达到每小时62.50美元。我们可能期望在九个月内下降到每小时6.25美元。

同时，1980年Pac-Man（吃豆子游戏）发布时，今天的一美元可以买到一个信用币，可以玩几分钟或几十分钟——假设每小时六次游戏，即每小时6美元。这表明，LLM增强游戏体验将于2025年左右变得经济可行。

这些趋势是新的，只刚出现几年。但在未来几年内，几乎没有理由预计这一过程会放缓。即使我们可能用尽算法和数据集中的低垂果实，如超越“Chinchilla 比率”（约每个参数 20 个 token），但数据中心和硅层的深层次创新和投资有望补足这一不足。

这也许是最重要的战略事实：今天完全不可行的地板演示或研究论文将成为几年内的高级功能，然后迅速成为商品。我们应该以此为基础构建我们的系统和组织。

足够的0到1演示，该是1到N产品的时候了

我们已经感受到，构建LLM演示非常有趣。只需几行代码、一个向量数据库和精心制作的提示，我们就能创造✨魔法✨。在过去的一年中，这种魔法被比作互联网、智能手机，甚至印刷机。

不幸的是，任何从事实际软件发布工作的人都知道，在受控设置中工作的演示与在规模上可靠运行的产品之间存在巨大的差异。

有一类问题很容易想象并构建演示，但非常难以做成产品。例如，自动驾驶：演示一辆车自驾驶绕一个街区很容易；使其成为产品需要十年。- Andrej Karpathy[94]

以自动驾驶汽车为例。1988年，第一辆车由神经网络驾驶1988年[95]。二十五年后，Andrej Karpathy首次乘坐Waymo演示[96]。十年后，该公司获得了无人驾驶许可证[97]。从原型到商业产品，经历了三十五年的严格工程、测试、改进和监管导航。

在整个行业和学术界，我们观察了过去一年的起伏：LLM应用的第1年。我们希望我们学到的教训——从提示工程、评估和安全防护等策略[98]到运营[99]技术和构建团队到战略[100]视角，如内部构建哪些能力——在第2年及以后帮助你，一起推动这项令人兴奋的新技术。

如何系统的去学习大模型LLM ？

作为一名热心肠的互联网老兵，我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。

但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的 AI大模型资料 包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

😝有需要的小伙伴，可以V扫描下方二维码免费领取🆓

请添加图片描述

一、全套AGI大模型学习路线

AI大模型时代的学习之旅：从基础到前沿，掌握人工智能的核心技能！

二、640套AI大模型报告合集

这套包含640份报告的合集，涵盖了AI大模型的理论研究、技术实现、行业应用等多个方面。无论您是科研人员、工程师，还是对AI大模型感兴趣的爱好者，这套报告合集都将为您提供宝贵的信息和启示。

三、AI大模型经典PDF籍

随着人工智能技术的飞速发展，AI大模型已经成为了当今科技领域的一大热点。这些大型预训练模型，如GPT-3、BERT、XLNet等，以其强大的语言理解和生成能力，正在改变我们对人工智能的认识。那以下这些PDF籍就是非常不错的学习资源。

四、AI大模型商业化落地方案

阶段1：AI大模型时代的基础理解

目标：了解AI大模型的基本概念、发展历程和核心原理。
内容：
- L1.1 人工智能简述与大模型起源
- L1.2 大模型与通用人工智能
- L1.3 GPT模型的发展历程
- L1.4 模型工程
- L1.4.1 知识大模型
- L1.4.2 生产大模型
- L1.4.3 模型工程方法论
- L1.4.4 模型工程实践
- L1.5 GPT应用案例

阶段2：AI大模型API应用开发工程

目标：掌握AI大模型API的使用和开发，以及相关的编程技能。
内容：
- L2.1 API接口
- L2.1.1 OpenAI API接口
- L2.1.2 Python接口接入
- L2.1.3 BOT工具类框架
- L2.1.4 代码示例
- L2.2 Prompt框架
- L2.2.1 什么是Prompt
- L2.2.2 Prompt框架应用现状
- L2.2.3 基于GPTAS的Prompt框架
- L2.2.4 Prompt框架与Thought
- L2.2.5 Prompt框架与提示词
- L2.3 流水线工程
- L2.3.1 流水线工程的概念
- L2.3.2 流水线工程的优点
- L2.3.3 流水线工程的应用
- L2.4 总结与展望

阶段3：AI大模型应用架构实践

目标：深入理解AI大模型的应用架构，并能够进行私有化部署。
内容：
- L3.1 Agent模型框架
- L3.1.1 Agent模型框架的设计理念
- L3.1.2 Agent模型框架的核心组件
- L3.1.3 Agent模型框架的实现细节
- L3.2 MetaGPT
- L3.2.1 MetaGPT的基本概念
- L3.2.2 MetaGPT的工作原理
- L3.2.3 MetaGPT的应用场景
- L3.3 ChatGLM
- L3.3.1 ChatGLM的特点
- L3.3.2 ChatGLM的开发环境
- L3.3.3 ChatGLM的使用示例
- L3.4 LLAMA
- L3.4.1 LLAMA的特点
- L3.4.2 LLAMA的开发环境
- L3.4.3 LLAMA的使用示例
- L3.5 其他大模型介绍