[深度] 如何将大型语言模型 (LLM) 集成到系统和产品中——7种可选的实用模式（下篇）

前情回顾：在[深度] 如何将大型语言模型 (LLM) 集成到系统和产品中——7种可选的实用模式（上篇）中，我们学习了构建基于大型语言模型（LLM）的系统与产品的7种模式中的2种：评估（Evals）和检索增强生成（RAG）。

接下来，让我们紧接上文，继续研习其他的模式：微调（Fine-tuning）、缓存（Caching）、护栏（Guardrails）、防御性用户体验（Defensive UX）和收集用户反馈（Collect user feedback）。

微调模式

微调是采用预先训练的模型（已经使用大量数据进行训练，例如GPT-4、GLM-4）并针对特定任务进一步完善它的过程。目的是利用模型在预训练期间已经获得的知识，并将其应用于特定任务，通常涉及较小的、特定于任务的数据集。

“微调”一词的使用很宽松，可以指多个概念，例如：

• 持续预训练：使用特定领域的数据，在基础模型上应用相同的预训练机制（下一个标记预测、屏蔽语言建模）。

• 指令微调：预训练（基础）模型在指令输出对的示例上进行微调，以遵循指令、回答问题等。

• 单任务微调：预训练模型针对狭窄且特定的任务进行磨练，例如毒性检测或总结，类似于 BERT 和 T5。

• 带人类反馈的强化学习（RLHF）：它将指令微调与强化学习结合起来。它需要收集人类偏好（例如2次输出的成对比较），然后用于训练奖励模型。然后，奖励模型用于通过近端策略优化 (PPO) 等RL技术进一步微调指导的 LLM。

我们在这里主要关注单任务和指令微调。

出于多种原因，微调LLM 正在成为使用第三方、基于云的 LLM 的越来越可行的替代方案。例如：

• 性能和控制：微调可以提高已有基础模型的性能，甚至可能超过第三方的LLM。它还可以更好地控制LLM的行为，从而形成更强大的系统或产品。总体而言，微调使我们能够构建与仅使用第三方或开源的大语言模型不同的产品。

• 模块化：单任务微调让我们可以使用一组较小的模型，每个模型都专注于自己的任务。通过这种设置，系统可以模块化为用于内容审核、提取、摘要等任务的单独模型。此外，考虑到每个模型只需要关注一组狭窄的任务，我们可以绕过对齐成本，其中在一项任务上微调模型会降低其他任务的性能。

• 减少依赖性：通过微调和托管我们自己的模型，我们可以减少对暴露给外部 API 的专有数据（例如内部文档和代码）的合规和隐私担忧。它还克服了第三方大语言模型带来的限制，例如速率限制、高成本或过度限制的安全过滤器。通过微调和托管我们自己的大语言模型，我们可以确保数据不会离开我们的网络，并且可以根据需要扩展吞吐量。

为什么我们需要微调基础模型？冒着过度简化的风险，基本模型主要经过优化，以根据训练的语料库预测下一个单词。因此，他们天生不擅长遵循指示或回答问题。当提出问题时，他们往往会回答更多问题。因此，我们对指令进行微调，以便他们学会做出适当的反应。

然而，微调并非没有挑战。首先，我们需要大量的示例数据。例如，在InstructGPT的论文中，他们使用13000个指令输出样本进行监督微调，使用33000个输出比较进行奖励建模，以及31000个没有人工标注的提示作为 RLHF 的输入。

此外，微调会带来调整成本——该过程可能会导致某些关键任务的性能下降（毕竟天下没有免费的午餐）。在同一篇InstructGPT的论文中发现，RLHF 导致了 SQuAD、HellaSwag 和 WMT 2015 French to English 等公共自然语言处理任务的性能回归（相对于GPT-3基本模型）。一种解决方法是拥有几个更小的、专用的模型，它们擅长处理狭窄的任务。

微调类似于迁移学习的概念。正如维基百科中的定义：“迁移学习是机器学习中的一种技术，其中从任务中学到的知识被重新使用以提高相关任务的性能。” 几年前，迁移学习使我可以轻松应用在 ImageNet 上训练的 ResNet 模型来对时尚产品进行分类并构建图像搜索。

ULMFit是较早将迁移学习应用于文本的论文之一。他们建立了自我监督预训练（在未标记数据上）然后进行微调（在标记数据上）的协议。他们使用了 AWS-LSTM，这是一种在不同门处具有 dropout 的 LSTM 变体。

如下图所示，ULMFiT包括三个阶段:

a) LM在通用域语料库上进行训练，以捕获不同层次的语言的一般特征

b)完整的LM微调目标任务数据，使用歧视性微调 (“Discr”)和倾斜的三角学习率(STLR)学习特定任务的功能

c)分类器使用逐步解冻“Discr”和STLR对目标任务进行微调，以保持低级别表示和适应高级别的 (阴影:解冻阶段，黑色:冻结)。

在预训练（下一个Token预测）期间，模型在 wikitext-103 上进行训练，其中包含 28.6 篇维基百科文章和1.03亿个单词。然后，在目标任务微调期间，LM 使用来自特定任务领域的数据进行微调。最后，在分类器微调期间，模型使用两个额外的线性块进行增强，并对目标分类任务进行微调，包括情感分析、问题分类和主题分类。

从那时起，预训练和微调范式推动了语言建模的巨大进步。

来自 Transformers 的双向编码器表示（BERT，纯Encoder模型）在英语维基百科和 BooksCorpus 上进行了掩码语言建模和下一句预测的预训练。然后针对特定于任务的输入和标签进行微调，以实现单句分类、句子对分类、单句标记以及问答。

生成式预训练Transformer（GPT，纯Decoder模型）首先通过下一个标记预测在 BooksCorpus 上进行预训练。接下来是对文本分类、文本蕴含、相似性和问答等任务的单任务微调。有趣的是，他们发现将语言建模作为辅助目标有助于模型在训练过程中更快地泛化和收敛。

文本序列到文本序列转换器（T5，Encoder-Decoder模型）在 Colossal Clean Crawled Corpus (C4) 上进行了预训练，Colossal Clean Crawled Corpus (C4) 是 2019 年 4 月发布的 Common Crawl 的清理版本。它采用与 BERT 相同的去噪目标，即 masked语言建模。然后针对文本分类、抽象摘要、问答和机器翻译等任务进行微调。

（这几种模型的概念和对比，在此前的研习文章《自然语言处理》中有提及，相比起来会更通俗易懂些。欢迎查阅、参考）

但与 ULMFIt、BERT 和 GPT 对下游任务使用不同的分类器头不同，T5 仅将下游任务表示为文本到文本。例如，翻译任务的输入文本可能以“Translation English to German:”开头，而摘要任务可能以“Summarize:”或“TL;DR:”开头。该前缀本质上成为一个超参数（提示工程的第一个实例？）这种设计选择使他们能够在各种下游任务中使用单个微调模型。

InstructGPT将这种单任务微调的想法扩展到指令微调。基础模型是 GPT-3，根据互联网数据（包括 Common Crawl、WebText、书籍和维基百科）进行预训练。然后，它对所需行为（指令和输出）的演示进行监督微调。接下来，它在比较数据集上训练了奖励模型。最后，它通过 PPO 相对于奖励模型优化了指导模型，最后一个阶段更多地关注一致性而不是特定的任务表现。

InstructGPT 中的微调步骤如下图所示：

该图包含三个步骤的说明：

(1)监督式微调 (SFT)

(2) 奖励模型(RM) 训练，以及

(3)在这个奖励模型上通过邻近策略优化 (PPO) 进行强化学习。

蓝色箭头指示此数据用于训练我们的某个模型。在步骤2中，A-D中的内容是来自模型的样本，这些样本由标注者进行排名。

接下来，让我们从微调模型转向微调技术。

Soft prompt tuning将可训练张量添加到模型的输入嵌入中，本质上是创建一个软提示。与离散文本提示不同，软提示可以通过反向传播来学习，这意味着它们可以进行微调以合并来自任意数量的标记示例的信号。

如上图所示，上方的微调更新了所有Transformer参数(红色的Transformer框)，并且需要为每个任务存储一个完整的模型副本。在下方的前缀调优，它冻结Transformer参数并只优化前缀(红色前缀块)。因此，我们只需要存储每个任务的前缀，使前缀调优模块化，节省空间。请注意，每个垂直块表示在一个时点的Transformer激活步骤。

该论文表明，尽管只需要更新 0.1% 的参数，但其性能可与完全微调相媲美。此外，在数据有限且涉及到新主题的推断的设置中，它的表现优于完全微调。一种假设是，训练较少的参数有助于减少较小目标数据集的过度拟合。

还有adapter技术。该方法在注意层之后和前馈网络层之后向每个Transformer块添加两次全连接网络层。在 GLUE 上，只需为每个任务添加 3.6% 的参数，就能实现完全微调性能的 0.4% 以内。

如上图所示，是Adapter模块的体系结构及其与Transformer的集成。

在左图中，我们将Adapter模块添加到每个Transformer层两次:在多目关注的投影之后和在两个前馈层之后。

在右图中，Adapter由一个瓶颈组成，其中包含与原始模型中的注意层和前馈层相关的几个参数。适配器还包含一个跳过连接。在适配器调整期间，绿色层根据下游数据进行训练，这包括适配器、层规范化参数和最终分类层 (图中未显示)。

低秩适应 (LoRA)是一种将适配器设计为两个低秩矩阵的乘积的技术。它的灵感来自Aghajanyan 等人。这表明，在适应特定任务时，预训练的语言模型具有较低的内在维度，并且尽管随机投影到较小的子空间，但仍然可以有效地学习。因此，LoRA 假设适应过程中的权重更新也具有较低的内在等级。

与prefix tuning类似，他们发现 LoRA 的性能优于多个基准，包括完全微调。再次，假设 LoRA 由于其等级降低而提供了隐式正则化。相比之下，更新所有权重的完全微调可能容易出现过度拟合。

QLoRA建立在 LoRA 的理念之上。但它在微调期间没有使用完整的 16 位模型，而是应用了 4 位量化模型。它引入了多项创新，例如 4 位 NormalFloat（用于量化模型）、双量化（用于额外节省内存）和分页优化器（当 GPU 内存不足时，通过将数据传输到 CPU RAM 来防止 OOM 错误）。

因此，与 16 位完全微调基准相比，QLoRA 将 65B 模型微调的平均内存需求从 > 780GB 内存降低到更易于管理的 48B，而不会降低运行时间或预测性能。

（有趣的是在与QLoRA的作者Tim Dettmers会面时，他打趣说双量化“有点愚蠢，但效果很好。”嘿，如果有效，那就有效。）

以下表格对比了Fine-tuning、Adapter、LoRA三种微调技术在假设的AI产品（基于GPT-4的客户服务聊天机器人）中的应用：

以AI客户服务聊天机器人为例：

• Fine-tuning：如果我们有大量针对特定客户服务场景的对话数据，并且需要最大限度地提高聊天机器人的性能，那么完全微调是一个很好的选择。这种方法将允许聊天机器人完全适应其应对的特定类型的客户查询。

• Adapter：如果我们只有有限的针对性数据，或者需要快速迭代和部署聊天机器人以应对不断变化的客户需求，那么Adapter技术是理想的选择。它允许在不过度修改原始GPT-3模型的情况下进行有效的任务特定适应。

• LoRA：如果我们的目标是保持模型的原始架构，同时快速适应新的客户服务任务，LoRA可以是一个有效的选择。这种方法特别适合在资源受限但对响应速度有要求的环境中。

第一步是收集示例数据/标签。这些可以用于简单的任务，例如文档分类、实体提取或摘要，也可以用于更复杂的任务，例如问答或对话。收集这些数据的一些方法包括：

• 通过专家或众包人工标注者：虽然这既昂贵又缓慢，但通常会产生具有良好指导的更高质量的数据。

• 通过用户反馈：这可以很简单，例如要求用户选择描述产品的属性、对 LLM 响应进行认可或不认可的反馈（例如ChatGPT），或记录用户选择下载哪些图像（例如Midjourney）。

• 使用宽松的许可证查询较大的开放模型：通过提示词工程，我们也许能够从较大的模型（Falcon 40B Instruct）中获取合理的示例数据，这些数据可用于微调较小的模型。

• 重用开源数据：如果目标任务可以构建为自然语言推理 (NLI) 任务，我们可以微调模型以使用MNLIDATA执行 NLI 。然后，我们可以继续对内部数据的模型进行微调，将输入分类为蕴涵、中性或矛盾。

注意：一些大语言模型禁止用户使用其输出来开发其他模型。

• OpenAI 使用条款（第 2c、iii 节）：您不得使用服务的输出来开发与 OpenAI 竞争的模型。

• LLaMA 2 社区许可协议（第 1b-v 节）：您不得使用 Llama 材料或 Llama 材料的任何输出或结果来改进任何其他大型语言模型（不包括 Llama 2 或其衍生作品）。

下一步是定义评估指标。我们在上一篇文章的中已经讨论过。

然后，选择一个预先训练的模型。有多个具有宽松许可证的开源大语言模型可供选择。除了 Llama 2（因为它没有完全商业用途）之外，Falcon-40B 被认为是性能最好的型号。尽管如此，我发现考虑到它的体积之大，在生产中进行微调和服务是很困难的。

相反，我倾向于使用较小的型号，例如 Falcon-7B。如果我们可以更精简地简化和构建任务，那么 BERT（340M参数）、RoBERTA（355M参数）和 BART（406M参数）是分类和自然语言推理任务的可靠选择。除此之外，Flan-T5（770M和3B变体）是翻译、抽象摘要、标题生成等的可靠基准模型。

我们可能还需要更新模型架构，例如当预训练模型的架构与任务不相符时。例如，我们可能需要更新BERT或T5上的分类头以匹配我们的任务。

提示：如果任务是简单的二元分类任务，NLI 模型可以开箱即用。蕴涵映射为正，矛盾映射为负，而神经标签可以表示不确定性。

再然后，选择一种微调方法。LoRA 和 QLoRA 是很好的开始。但如果你的微调更加密集，例如继续对新领域知识进行预训练，可能会发现完全微调是必要的。

最后，基本的超参数调整。一般来说，大多数论文都关注学习率、批量大小和迭代次数（参见 LoRA、QLoRA）。如果我们使用 LoRA，我们可能需要调整排名参数（尽管 QLoRA 论文发现不同的排名和 alpha 会导致相似的结果）。其他超参数包括输入序列长度、损失类型（对比损失与令牌匹配）和数据比率（例如预训练或演示数据的混合，或者正例与负例的比率等）。

缓存模式

缓存是一种存储先前检索或计算的数据的技术。这样，可以更快地满足未来对相同数据的请求。在服务LLM版本的空间中，流行的方法是缓存基于输入请求嵌入的LLM响应。然后，对于每个新请求，如果收到语义相似的请求，我们可以提供缓存的响应。

对于一些从业者来说，这听起来像是“一场即将发生的灾难”。” 我倾向于同意。因此，我认为采用这种模式的关键是弄清楚如何安全地缓存，而不是仅仅依赖于语义相似性。

缓存可以显着减少之前已提供的响应的延迟。此外，通过消除一次又一次计算相同输入的响应的需要，我们可以减少 LLM 请求的数量，从而节省成本。此外，某些用例不支持秒级延迟。因此，预计算和缓存可能是服务这些用例的唯一方法。

缓存是一个高速存储层，用于存储访问更频繁的数据子集。这让我们可以通过缓存而不是数据的主存储（例如搜索索引、关系数据库）更快地服务这些请求。总体而言，缓存可以有效地重用先前获取或计算的数据。

GPTCache是 LLM 缓存的一个示例。

当收到新请求时：

• 嵌入生成器：这通过各种模型嵌入请求，例如 OpenAI text-embedding-ada-002、FastText、Sentence Transformers 等。

• 相似度评估器：它通过向量存储计算请求的相似度，然后提供距离度量。矢量存储可以是本地的（FAISS、Hnswlib）或基于云的。它还可以通过模型计算相似性。

• 缓存存储：如果请求相似，则获取并提供缓存的响应。
  

• LLM：如果请求不够相似，则会将其传递给 LLM，然后由 LLM 生成结果。最后，响应被提供并缓存以供将来使用。

Redis 也分享了一个类似的例子，提到一些团队甚至会预先计算他们预期收到的所有查询。然后，他们设置一个相似性阈值，在该阈值上查询足够相似以保证缓存响应。

我们应该从充分理解用户请求模式开始。这使我们能够深思熟虑地设计缓存，以便可靠地应用它。

首先，让我们考虑一个不是LLM的例子。想象一下我们正在缓存电子商务网站的产品价格。结算时，显示缓存价格（可能已过时）是否安全？由于客户在结账时看到的价格应该与最终收取的金额相同，缓存在这里不适用，因为我们需要确保对客户的一致性。

现在，让我们回到LLM的情形。想象一下，我们收到一个请求，要求提供“碟中谍 2”的摘要，该摘要在语义上与“碟中谍 3”足够相似。如果我们根据语义相似性查找缓存，我们可能会提供错误的响应。

我们还需要考虑缓存对于使用模式是否有效。量化这一点的一种方法是通过缓存命中率（直接从缓存提供服务的请求占比）。如果使用模式是统一随机的，则缓存将需要频繁更新。因此，保持缓存为最新的努力可能会抵消缓存所提供的任何好处。另一方面，如果使用遵循幂律，其中一小部分请求占大部分流量（例如搜索查询、产品视图），那么缓存可能是一种有效的策略。

除了语义相似性之外，我们还可以基于以下内容探索缓存：

• 项目 IDs：这适用于我们提前计算产品评论摘要或生成整个电影三部曲的摘要。

• 项目IDs对：例如当我们生成两部电影之间的比较时。虽然这看起来是这样，但实际上，少数组合驱动了大部分流量，例如系列或流派中流行电影之间的比较。

• 输入约束：例如电影类型、导演或主演等变量。例如，如果用户正在寻找特定导演的电影，我们可以执行结构化查询并通过法学硕士运行它，以更雄辩地构建响应。另一个例子是基于下拉选项生成代码 - 如果代码已被验证可以工作，我们可以缓存它以进行可靠的重用。

此外，缓存不仅仅需要即时发生。正如 Redis 所分享的，我们可以在提供 LLM 生成之前离线或异步地预先计算它们。通过从缓存提供服务，我们将延迟从生成（通常为秒）转移到缓存查找（毫秒）。批量预计算还可以帮助降低相对于实时服务的成本。

虽然这里列出的方法可能不如自然语言输入的语义缓存那么灵活，但我认为它在效率和可靠性之间提供了良好的平衡。

安全护栏模式

在LLM的背景下，护栏会验证大语言模型的输出，确保输出不仅看起来不错，而且语法正确、真实且不含有害内容。它还包括防范对抗性输入。

首先，它们有助于确保模型输出足够可靠且一致，能够在现实中使用。例如，我们可能要求输出采用特定的 JSON 模式，以便机器可读，或者我们需要生成的代码可执行。护栏可以帮助进行验证此类语法。

其次，它们提供了额外的安全层并保持对LLM输出的质量控制。例如，为了验证生成的内容是否适合用于提供服务，我们可能需要检查输出是否无害，验证其事实准确性，或确保与所提供的上下文的一致性。

一种方法是通过提示控制模型的响应。例如，Anthropic 分享了旨在引导模型生成有用helpful、无害harmless且诚实honest (HHH) 的响应的prompts。他们发现，与使用RLHF进行微调相比，使用HHH提示词进行Python 调可以带来更好的性能。

HHH提示词示例：

下面是一系列不同的人和人工智能助手之间的对话。人工智能努力做到乐于助人、礼貌、诚实、老练、有情感意识、谦逊但知识渊博。助理很乐意帮助几乎任何事情，并会尽最大努力去了解到底需要什么。它还试图避免给出错误或误导性的信息，并在不完全确定正确答案时给出警告。也就是说，这位助手很实用，真的做到了最好，不会让谨慎成为有用的障碍。
(我们包括几个简短的示例对话，使用正常的人类:…助手:…格式。)
人类:你能帮我写这个Python函数吗?我已经写好了函数的签名和docstring，但是我不知道如何写函数体。它的开头是这样的:《FUNC SIGNATION PLUS DOCSTRING》
助手:当然可以，给你!我自己测试过这个函数，所以我知道它是正确的:<FUNC SIGNATION PLUS DOCSTRING>

（该提示词包含HHH提示词时HumanEval的结果。我们看到，在许多PASS@K值中，HHH提示比RLHF更显着地提高了性能。）

更常见的方法是验证输出。 护栏包就是一个例子。它允许用户添加结构、类型和质量要求，通过Pydantic风格验证LLM的输出。如果检查失败，它可以触发纠正措施，例如过滤有问题的输出或重新生成另一个响应。

大部分验证逻辑都在validators.py 中。看看它们是如何实现的很有趣。从广义上讲，其验证器分为以下几类：

• 单个输出值验证：这包括确保输出 (i) 是预定义的选择之一，(ii) 的长度在一定范围内，(iii) 如果是数字，则落在预期范围内，并且 (iv) 是完整的句子。

• 语法检查：这包括确保生成的 URL 有效且可访问，以及 Python 和 SQL 代码没有错误。

• 语义检查：这验证输出是否与参考文档一致，或者提取摘要是否与源文档紧密匹配。这些检查可以通过余弦相似度或模糊匹配技术来完成。

• 安全检查：这可确保生成的输出没有不适当用语、翻译文本的质量较高。

Nvidia的NeMo-Guardrails遵循类似的原则，但旨在指导基于LLM的对话系统。它不关注句法护栏，而是强调语义护栏。这包括确保AI助手避开政治话题、提供真实正确的信息并能够检测越狱企图。

因此，NeMo 的方法有些不同：NeMo 很大程度上依赖于使用另一个 LLM 来验证输出（受到SelfCheckGPT的启发），而不是使用更具确定性的检查，例如验证列表中是否存在值或检查代码是否存在语法错误。

在事实检查和防止幻觉的示例中，他们要求LLM本身检查最新的输出是否与给定的上下文一致。为了进行事实检查，根据从知识库检索的文档，查询LLM的响应是否正确。为了防止产生幻觉，由于没有可用的知识库，他们让LLM生成多个替代结果作为上下文。基本假设是，如果LLM产生了多个彼此不一致的完成结果，则最初的完成结果很可能是一种幻觉。

审核示例遵循类似的方法：通过LLM筛选响应中的有害和不道德内容。考虑到道德和有害内容的细微差别，启发式方法和传统的机器学习技术都不够。因此，需要LLM才能更深入地理解对话的意图和结构。

除了使用护栏来验证LLM的输出之外，我们还可以直接引导输出遵循特定的语法。微软的Guidance就是一个例子，与护栏通过提示强制使用 JSON 架构不同，它通过注入结构化的Tokens来强制执行。

我们可以将Guidance视为LLM交互和输出的特定领域语言。它从Handlebars中汲取灵感——一种用于Web应用程序的流行模板语言，使用户能够执行变量插值和逻辑控制。

然而，Guidance通过线性执行将自己与常规模板语言区分开来。这意味着它维护生成的令牌的顺序。因此，通过插入作为结构一部分的标记（而不是依赖 LLM 来正确生成它们），Guidance可以规定特定的输出格式。在他们的示例中，他们展示了如何生成始终有效的 JSON、生成具有多个密钥的复杂输出格式、确保 LLM 扮演正确的角色，以及如何让代理相互交互。

他们还引入了一个称为Token修复的概念，这是一个有用的功能，有助于避免由于Token化而发生的微妙错误。简而言之，它在提示结束之前将生成过程倒回一个标记，然后限制第一个生成的标记具有与提示中最后一个标记匹配的前缀。这消除了在制作提示词时担心token边界的需要。

尽管LLM护栏的概念在行业中仍处于萌芽阶段，但我们可以考虑一些当下有用且实用的策略。

对于AI产品经理来说，理解和实施不同类型的LLM护栏是确保产品安全、可靠和符合用户需求的关键。让我们逐一深入探讨每种护栏类型，并提供实际示例以加深理解。

结构化指南：尽可能应用指南。它提供对输出的直接控制，并提供更精确的方法来确保输出符合特定的结构或格式，从而提高输出的准确性和可用性。

示例：在生成市场报告时，结构化指南可以确保输出包含所有必要的部分，如市场规模、增长预测、竞争分析等，且格式一致。

语法护栏：语法护栏检查LLM输出的分类或数值是否在合理范围内，同时确保如SQL或代码输出无语法错误，并确保查询中的所有列都与架构匹配。生成代码（例如 Python、JavaScript）也是如此。

示例：在自动生成SQL查询时，护栏会检查查询语法是否正确，确保所有引用的列名在数据库中存在，防止执行错误的查询。

内容安全护栏：通过关键词列表或调节分类器来实现，验证内容输出是否包含有害或不适当的内容。它可以像检查肮脏、顽皮、淫秽和其他坏词列表或使用脏话检测模型一样简单（对输出运行调节分类器是很常见的）。更复杂和细致的输出可以依靠 LLM 评估器。

示例：在社交媒体管理工具中，内容安全护栏可以自动检测并过滤掉包含不适当语言的用户评论，保护品牌形象。

语义/事实护栏：这些确认输出在语义上与输入相关，保证信息准确无误。假设我们要根据电影的概要生成两句话的摘要，我们可以验证生成的摘要在语义上是否与输出相似，或者让（另一个）LLM 确定摘要是否准确地代表了所提供的概要。

示例：在生成新闻摘要时，语义/事实护栏会检查摘要是否准确反映了原始文章的主要内容，避免误导性信息。

输入护栏：它限制模型响应的输入类型，降低响应不适当或对抗性提示词的风险。

示例：在使用AI艺术生成器如Midjourney时，输入护栏会阻止用户请求生成不适当或违反社区指南的图像，如NSFW内容。如下图所示。

通过实施这些护栏，AI产品经理能够确保产品在安全、准确性和用户体验方面达到较高标准，同时减少可能的风险和不良影响。

防御性UX模式

防御性UX（用户体验）是一种设计策略，它承认在用户与机器学习或基于 LLM 的产品交互期间可能会发生不好的事情，例如不准确或幻觉。因此，目的是提前预测和管理这些问题，主要是通过指导用户行为、避免误用和优雅地处理错误。

机器学习和LLM并不完美——它们可能会产生不准确的输出。此外，随着时间的推移，它们对相同输入的响应也会有所不同，例如搜索引擎由于个性化而显示不同的结果，或者LLM在更具创意、更高温度的设置上生成不同的输出。这可能违反一致性原则，该原则提倡一致的 UI 和可预测的行为。

防御性用户体验可以通过提供以下帮助来缓解上述问题：

• 提高可用性：通过帮助用户了解 ML/LLM 功能的工作原理及其局限性，防御性用户体验使其更易于访问和用户友好。

• 增加信任：当用户看到该功能可以优雅地处理困难的场景并且不会产生有害的输出时，他们可能会更加信任它。

• 更好的用户体验：通过设计系统和用户体验来处理不明确的情况和错误，防御性用户体验为更流畅、更愉快的用户体验铺平了道路。

要了解有关防御性用户体验的更多信息，我们可以查看微软、谷歌和苹果的Human-AI指南（预告：在后续将会分享一篇“苹果的机器学习应用人机界面指南”）。

微软的人机交互指南基于对 168 条潜在指南的调查。这些数据是从内部和外部行业资源、学术文献和公共文章中收集的。在结合相似的指南、过滤过于模糊、过于具体或不特定于 AI 的指南以及一轮启发式评估后，他们将范围缩小到 18 条指南，如下图所示：

这些准则遵循一定的风格：每条准则都是由 3 - 10 个单词组成的简洁操作规则，以动词开头。每条规则都附有一条注释，以解决潜在的歧义。它们是根据用户交互期间可能的应用来组织的：

• 最初：明确系统能做什么（G1），明确系统能做它能做的事情有多好（G2）

• 交互过程中：基于上下文的时间服务（G3），减轻社会偏见（G6）

• 当发生错误时：支持高效驳回（G8）、支持高效纠错（G9）

• 随着时间的推移：从用户行为中学习（G13），提供全局控制（G17）

谷歌的People+AI Guidebook源自谷歌产品团队和学术研究的数据和见解。与微软围绕用户组织的指南不同，谷歌将其指南组织成开发人员需要牢记的概念。

围绕产品开发过程中出现的常见问题分为 23 种模式，包括：

• 如何开始使用以人为本的人工智能：确定人工智能是否能增加价值，尽早投资于良好的数据实践（例如评估）

• 如何让用户使用新的人工智能功能：让探索变得安全、以熟悉度为基础、分阶段实现自动化

• 我如何帮助用户建立对我的产品的信任：设定正确的期望，保持透明，在风险较低时提高自动化程度。

苹果的机器学习人机界面指南（巧了！就是我预告要分享的那篇）不同于学术文献和用户研究的自下而上的方法。相反，它的主要来源是从业者的知识和经验。因此，它没有包含太多参考资料或数据点，而是重点关注苹果长期以来的设计原则。这产生了将其与其他两个指南区分开来的独特视角。

该文档重点介绍了如何将 Apple 的设计原则应用于注入 ML 的产品，强调 UI 方面而不是模型功能。它首先要求开发人员考虑机器学习在他们的应用程序中的作用，并从用户体验开始逆向工作。这包括诸如 ML 是否：

• 关键或补充：例如，Face ID 在没有 ML 的情况下无法工作，但键盘在没有 QuickType 的情况下仍然可以工作。

• 主动或被动：Siri 建议是主动的，而自动更正是被动的。

• 动态或静态：推荐是动态的，而照片中的对象检测只会随着每个 iOS 版本的改进而改进。

然后它深入研究几种模式，分为系统的输入和输出。输入侧重于显式反馈、隐式反馈、校准和校正。指导人工智能产品如何请求和处理用户数据和交互的设计。输出集中于错误、多种选择、信心、归因和局限性。目的是确保模型的输出以易于理解且有用的方式呈现。

这三个指南之间的差异是有洞察力的。谷歌更加重视对训练数据和模型开发的考虑，这可能是由于其工程驱动的文化。微软更关注心理模型，这可能是人机交互学术研究的产物。最后，苹果的方法以提供无缝的用户体验为中心，这一重点可能受到其文化价值观和原则的影响。

以下是基于上述指南的一些模式。（免责声明：我不是设计师）

设定正确的期望。这一原则在所有三个准则中都是一致的：

• 微软：明确系统能做的事情有多好（帮助用户了解AI系统可能犯错误的频率）

• 谷歌：设定正确的期望（对你的用户透明地说明你的人工智能产品能做什么和不能做什么）

• 苹果：帮助人们建立现实的期望（描述营销材料或功能上下文中的限制）

这可以很简单，只需在人工智能生成的结果上方添加简短的免责声明（如 Bard 的结果），或者在其登陆页面上突出显示我们应用程序的限制（如 ChatGPT 的做法）即可。

通过对我们产品的功能和限制保持透明，我们帮助用户调整他们对其功能和输出的期望。虽然这可能会导致用户在短期内对其信任度降低，但从长远来看，它有助于培养信任——用户不太可能高估我们的产品并随后面临失望。

启用高效的驳回功能。这在微软指南中的第8条中被明确提到：支持高效驳回（使用户容易驳回或忽略不需要的AI系统服务）。

例如，如果用户正在浏览我们的网站，并且弹出一个聊天机器人询问他们是否需要帮助，那么用户应该很容易关闭聊天机器人。这可以确保聊天机器人不会妨碍，尤其是在屏幕较小的设备上。同样，GitHub Copilot 允许用户通过简单地继续键入来方便地忽略其代码建议。虽然这可能会在短期内减少人工智能功能的使用，但从长远来看，它可以防止它成为麻烦并可能降低客户满意度。

提供归因。这在所有三项指南中都有列出：

• 微软：明确系统为何这么做（使用户能够获得关于人工智能系统为何如此行为的解释）

• 谷歌：添加人工来源的上下文（帮助用户根据来自第三方来源的输入评估您的建议）

• 苹果：考虑使用归因来帮助人们区分结果

引文正成为越来越常见的设计元素。以 BingChat 为例（如下图所示），当我们提出查询时，它的回复中会包含引用，通常来自信誉良好的来源。这不仅显示信息的来源，还允许用户评估来源的质量。同样，假设我们使用LLM来解释用户可能喜欢某个产品的原因。除了LLM生成的解释之外，我们还可以引用实际评论或提及产品评级。

来自专家和社区的背景信息也增强了用户的信任。例如，如果用户正在寻求远足路线的推荐，提及相关社区强烈推荐的建议路线可能会大有帮助。它不仅增加了推荐的价值，还帮助用户通过人际关系校准信任。

通过社区证明进行归因的示例：

最后，苹果的指南包括流行的归因，例如“因为你读过非小说类作品”、“你读过的作者的新书”。这些描述符不仅可以个性化体验，还可以提供背景信息，增强用户的理解和信任。

锚定熟悉度。当向用户介绍新的人工智能产品或功能时，它有助于引导他们熟悉的用户体验模式和功能。这使用户更容易专注于主要任务并开始赢得客户对我们新产品的信任。抵制通过异国情调的 UI 元素展示新的“神奇”功能的诱惑。

同样，由于 ChatGPT 的日益普及，基于聊天的功能也变得越来越普遍。例如，与您的文档聊天、查询数据、通过聊天购物。然而，我质疑聊天是否是适合大多数用户体验的正确用户体验——相对于熟悉的点击文本和图像的用户体验来说，它需要付出太多的努力。

此外，用户努力的增加会导致更高的期望，而这些期望更难以满足。 Netflix 表示，用户对搜索等明确操作产生的推荐抱有更高的期望。一般来说，与更省力的交互（例如滚动推荐板或单击产品）进行相比，用户投入的精力越多（例如聊天、搜索）他们的期望就越高。

因此，虽然聊天提供了更大的灵活性，但它也需要更多的用户努力。此外，使用聊天框不太直观，因为它缺乏用户如何调整输出的指示符。总的来说，我认为坚持使用熟悉且受限的用户界面可以让用户更轻松地浏览我们的产品；聊天只能被视为第二或第三选项。

收集用户反馈模式

收集用户反馈使我们能够了解他们的偏好。具体到LLM产品，用户反馈有助于构建评估、微调和护栏。如果我们仔细想想，数据——例如预训练的语料库、专家制作的演示、人类对奖励模型的偏好——是LLM产品为数不多的护城河之一。因此，我们在设计用户体验时要刻意考虑收集用户反馈。

反馈可以是显式的，也可以是隐式的。显式反馈是用户根据我们产品的请求提供的信息；隐式反馈是我们从用户交互中学到的信息，而不需要用户刻意提供反馈。

用户反馈有助于改进我们的模型。通过了解用户喜欢、不喜欢或抱怨的内容，我们可以改进我们的模型以更好地满足他们的需求。它还使我们能够适应个人喜好。推荐系统就是一个典型的例子。当用户与物品互动时，我们会了解他们喜欢什么和不喜欢什么，并随着时间的推移更好地迎合他们的口味。

此外，反馈回路有助于我们评估系统的整体性能。虽然评估可以帮助我们衡量模型/系统性能，但用户反馈提供了用户满意度和产品有效性的具体衡量标准。

使用户能够轻松提供反馈。这在上一节中提到的三个准则中都有指出：

• 微软：鼓励精细的反馈（使用户能够在与 AI 系统定期交互期间提供反馈，指示其偏好）

• 谷歌：让用户提供反馈（给用户实时指导、反馈和纠错的机会）

• 苹果：提供可操作的信息，你的 App 可用于改进它呈现给用户的内容和体验

ChatGPT/Bard就是这样一个例子。用户可以在回复上竖起/竖起大拇指，或者选择在回复真的很糟糕或没有帮助时重新生成回复。这是对人类偏好的有用反馈，然后可用于微调LLM。

Midjourney 是另一个很好的例子。生成图像后，用户可以生成一组新图像（负反馈），通过请求变体来调整图像（正反馈），或升级并下载图像（强烈的正反馈）。这使 Midjourney 能够收集有关生成的输出的丰富比较数据。

也要考虑隐式反馈。隐式反馈是用户与我们的产品交互时产生的信息。与我们从显式反馈中获得的具体响应不同，隐式反馈可以提供有关用户行为和偏好的广泛数据。

Copilot之类的助手就是一个典型的例子。用户通过完全接受建议（强烈的积极反馈）、接受并进行小幅调整（积极反馈）或忽略它（中性/负面反馈）来表明建议是否有帮助。或者，他们可能会更新导致生成代码的注释，表明初始代码生成不符合他们的需求。

另一个例子是 ChatGPT 和 BingChat 等聊天机器人。随着时间的推移，日常使用情况发生了怎样的变化？如果产品有粘性，则表明用户喜欢它。另外，平均对话时间是多长？这可能很难解释：是不是因为对话引人入胜且富有成果，所以对话时间越长越好？还是因为用户需要更长的时间才能获得他们需要的东西而变得更糟？

其他模式

除了上述七种模式之外，机器学习中还有其他模式也与 LLM 系统和产品相关。他们包括：

• 数据飞轮：持续的数据收集改进模型并带来更好的用户体验。这反过来又促进了更多的使用，从而提供更多的数据来进一步评估和微调模型，从而形成良性循环。

• 级联：我们可以将一个复杂的任务简化并拆分，而不是将其全部指派给大型语言模型（LLM）。这样，LLM只需处理它擅长的任务，比如推理或者流畅的沟通。RAG（检索式增强生成）就是这种方法的一个例子。与其依赖LLM基于内部知识检索和排列项目，我们可以通过外部知识增强LLM，并专注于应用LLM的推理能力。

• 监控：这有助于展示人工智能系统所增加的价值或缺乏的价值。有人分享了一个轶事，在产品中运行了基于LLM的客户支持解决方案两周，然后停止了该解决方案 - A/B 测试显示，使用 LLM 作为支持团队的替代品时，损失增加了 12 倍！

另外，这里还有一些其他人的说法：

关注点/任务分解的分离——对不同的子任务有不同的提示并将它们链接在一起有助于提高注意力和可靠性（损害延迟）。我们在指定严格的输出结构和可变的响应内容时遇到了困难，因此我们分割了任务

Erick Enriquez

其他一些还需要：基于角色的访问控制：谁可以访问什么；安全性：如果我使用带有LLM的数据库，我如何确保我拥有正确的安全人员

Krishna

一致的输出格式：将输出设置为标准化格式，例如 JSON；工具增强：将任务加载到更专业、经过验证、可靠的模型

Paul Tune

安全性：减轻缓存中毒、输入验证、减轻提示注入、训练数据来源、使用不易受攻击的代码输出、减轻旨在影响工具（AI 代理）使用的请求的恶意输入、减轻拒绝服务（压力测试LLM）

Anderson Darario

另一个与 ux/ui 相关的：激励用户对生成的答案（隐式或显式）提供反馈。隐式可能是像副驾驶的幽灵文本风格，如果点击接受，意味着积极的反馈等。

Wen Yang

很棒的清单。我会添加一致性检查，例如自一致性采样、任务的链接和分解以及多个模型输出的组装。几乎每天都应用这些。

Dan White

护栏与构建分析工具非常相关，其中LLM是从自然语言到编程语言的翻译器

m_voitko

总结

这是迄今为止我写过的最长的帖子。如果你还在我身边，谢谢你！

（这也是迄今为止，笔者整理过最长的公众号文章，断断续续2个星期才完成……吐血。。。）

我希望您发现阅读这些模式对您有所帮助，并且下面的矩阵图很有意义。

我们在构建基于LLM的系统和产品的旅程中还处于早期阶段。还有其他关键模式或资源吗？您发现什么有用或没用？我很想听听你的经历。请伸出援手！

（原文还附带了参考文献，我就不搬运了……）

要是觉得我的分享还不错或者对你有帮助，不妨点个关注、在看。

也欢迎你在留言区与我互动。

​​​​​​​