大措辞模型（LLMs）的时期充满了让人愉快的机遇。在过去的一年里，LLMs的性能已经“足够好”以至于可以用于现实天下的运用，估量会在2025年前带动大约2000亿美元的人工智能投资。LLMs也广泛使得所有人，而不但是机器学习工程师和科学家，都能够将人工智能带入他们的产品中。虽然构建AI产品的门槛已经降落，但要创造出一个体验精良的产品仍旧是一个艰巨的寻衅。
在过去一年中，Eugene Yan、Bryan Bischof 、Charles Frye 等一贯在LLMs之上构建他们的运用程序。他们写这篇文章的目标是，以自己的履历为根本，创建一个关于环绕LLMs构建成功产品的实用指南，并列呈现实成功的例子，分享一些建媾和教训，供任何构建LLMs产品的人参考。
原文：
https://www.oreilly.com/radar/what-we-learned-from-a-year-of-building-with-llms-part-i/
01.提示工程（Prompting）
我们建议在开拓新运用时从提示工程（Prompting）开始。人们很随意马虎低估或者低估它的主要性。精确的提示技巧，若利用得当的情形下，可以让我们取得很大的进展，以是它每每被低估；但是，纵然是基于提示的运用程序也须要环绕提示进行大量工程开拓才能很好地事情，因此其主要性也随意马虎被高估。
1. 重视从基本的提示技巧中得到最大收益
有几种提示技巧在不同模型和任务中都能有助于提升性能：
n-shot 提示与高下文学习
利用n-shot 提示进行高下文中学习的思路是供应给LLM一些示例，这些示例展示了任务哀求，并使输出符合我们的期望。一些建议：
如果 n 过低，模型可能会过度依赖这些特定示例，影响其泛化能力。一样平常来说，n 该当不小于 5，乃至可以达到几十个。示例应能代表预期输入的分布。如果您正在构建一个电影择要天生器，请包含不同类型的样本，比例大致与实际情形符合。不一定要供应完全的输入输出对。在很多情形下，仅供应期望输出的示例就足够了。如果您利用支持工具的大措辞模型，您的 n-shot 示例也应包括您希望智能体利用的工具。思维链（CoT）提示
在思维链（CoT）提示中，我们鼓励LLM在返回终极答案之前阐明其思考过程。可以将其视为为LLM供应一个草稿本，这样它就不必全部在影象中完成。最初的方法是大略地在指示中添加“lets think step by step（让我们一步一步思考）”这句话。然而，我们创造使链式思维更详细，通过添加一两句额外的解释，可以显著降落幻觉率。
当哀求大措辞模型总结会议记录时，我们可以明确步骤，例如：
首先，在草稿本上列出关键决策、后续事变及干系任务人。
然后，检讨草稿本中的细节与会议记录事实上是否同等。
末了，将关键点综合成一份简洁的择要。
最近，人们开始疑惑这种技能是否像人们认为的那样强大。此外，关于在利用思维链时推理过程中究竟发生了什么，存在相称大的争议。无论如何，考试测验这种技能是值得的。
供应干系资源
供应干系资源是一种扩展模型知识库、减少幻觉并增加用户信赖的强有力机制。常日通过检索增强天生（RAG）实现，为模型供应它可以直接在回应中利用的文本片段是一种基本技巧。供应干系资源时，仅仅包括这些资源是不足的；别忘了见告模型优先利用这些资源，直接提及它们，有时还要提及当资源不敷时的情形。这些有助于让智能体的相应基于一组资源。
构造化你的输入和输出
构造化输入和输出可以帮助模型更好地理解输入，并返回能够可靠集成到下贱系统中的输出。为您的输入添加序列化格式可以为模型供应更多关于高下文中tokens之间关系的线索，为特定tokens供应额外的元数据（如类型），或将要求与模型演习数据中的类似示例联系起来。
例如，互联网上许多关于编写SQL的问题都是通过指定SQL模式开始的。因此，你可能期望有效的Text-to-SQL提示应包括构造化的模式定义。
构造化输出具有类似的目的，但它也简化了与系统下贱组件的集成。Instructor和Outlines适宜用于构造化输出。（如果你正在导入LLM API SDK，利用Instructor；如果您正在导入 Huggingface 进行自托管模型，请利用Outlines）。构造化输入清晰地表达任务，并且类似于演习数据的格式，增加了得到更好输出的可能性。
利用构造化输入时，请把稳每个大措辞模型都有自己的偏好。Claude偏好xml，而GPT偏好Markdown和JSON。利用XML，你乃至可以通过供应一个 response标签来预填Claude的相应，就像这样。
2. 编写短而精的提示词，专注做好一件事
在软件开拓中，有一个常见的反模式叫“万能工具”，即一个类或函数承担了所有的功能。提示词也有类似的问题。
提示常日开始很大略：几句指令，几个例子，就可以开始利用了。但是当我们试图提高性能和处理更多边缘情形时，繁芜性就会悄然而至。更多指令、多步推理、几十个例子。在我们意识到之前，最初大略的提示现在已经变成了一个2000个token的复合体。更糟的是，它在更常见和直接的输入上性能还低落了！
GoDaddy 把这个作为他们在利用大措辞模型时的紧张履历。
就像我们努力保持系统和代码的简约一样，我们的提示也该当如此。我们不应该拥有一个用于会议记录的全能型提示，我们可以将其分解为步骤：
将关键决策、行动项目和任务人提取成构造化格式检讨提取的详情与原始记录的同等性从构造化的细节天生简洁的择要因此，我们将单一的提示分解成了多个大略、专注且易于理解的提示。通过分解，我们可以分别迭代和评估每个提示词的效果。
3. 精心设计你的高下文信息
重新思考你的需求，然后反思实际须要向agent发送多少高下文。像米爽朗琪罗那样，不是不断堆砌石料——而是剔除多余的材料，直到雕塑显现出来。检索增强天生（RAG）是一个盛行的方法，用来搜集所有可能干系的信息块，但是你如何提取必要的内容呢？
我们创造，将终极发送给模型的提示词——包括所有的高下文构建、元提示词和 RAG 结果——放在一张空缺页上阅读，确实有助于重新思考高下文。通过这种方法，我们创造了冗余、自相抵牾的措辞和糟糕的格式。
另一个关键的优化是你的高下文构造。如果你的文档袋（bag-of-docs）表示法对人类不友好，不要假设它对agent有用。仔细考虑你如何构建高下文，强调其各部分之间的关系，并尽可能简化提取过程。
02.检索增强天生（RAG）
除了提示工程之外，还有一种有效的方法是在提示中供应知识。这种方法将使LLMs锚定在供应的高下文上，用于高下文学习，这被称为检索增强天生（RAG）。实践中创造，RAG在供应知识和改进输出方面有效，而且与微调比较须要的努力和本钱更少。RAG的好坏取决于检索文档的干系性、信息密度和详细程度。
1. RAG输出质量取决于检索文档的质量，而文档的质量又可以从几个成分考虑
第一个也是最明显的衡量指标是文档的干系性。干系性常日通过排名指标进行量化，例如均匀倒数排名（MRR）或归一化折扣累计增益（NDCG）。MRR评估系统在排名列表中将首个干系结果置于何处的能力，而NDCG则考虑所有结果的干系性及其位置。这些指标衡量系统将干系文档排在更高位置、不干系文档排在更低位置的。例如，如果我们检索用户评论来天生电影评论择要，我们希望将特定电影的评论排名更高，同时打消与其他电影有关的评论。
与传统推举系统类似，检索到的项目排名将对 LLM 不才游任务中的表现产生重大影响。为了衡量这种影响，可以运行一个基于 RAG 的任务，但将检索到的项目录序打乱，然后不雅观察 RAG 输出的表现如何。
其次，我们还想考虑信息密度。如果两份文档同样干系，我们该当更偏好那些更简洁且不必要细节较少的文档。回到我们的电影示例，从广义上讲，我们可能会认为电影剧本和所有用户评论都干系。然而，高评价的评论和编辑评论可能在信息上更为密集。
末了，考虑文档供应的细节水平。想象我们正在构建一个 RAG 系统，从自然措辞天生 SQL 查询。我们可以大略地供应表构造和列名作为高下文，但如果包括列描述和一些代表性值，额外的细节将帮助 LLM 更好地理解表的语义，从而天生更精确的 SQL。
2. 不要忘却关键词搜索：将其用于基准和稠浊搜索
鉴于基于嵌入（Embedding）的RAG如此普遍，很随意马虎让人忘却或忽略信息检索领域几十年的研究和解决方案。
只管嵌入式搜索无疑是一个强大的工具，但它们并非万能。首先，虽然它们善于捕捉高层次的语义相似性，但它们可能在处理更详细的基于关键词的查询时碰着困难，就像用户搜索名称（例如，Ilya）、缩写（例如，RAG）或ID（例如，claude-3-sonnet）时。基于关键词的搜索，如BM25，专门为此设计。而且，经由多年的基于关键词的搜索，用户很可能已经将其视为天经地义，并且如果他们希望检索的文档没有被返回，可能会感到沮丧。
向量嵌入并不是搜索的万能办理方案。事实上，在利用语义相似搜索进行重新排序之前的步骤才是最关键和费力的。要真正实现比 BM25 或全文搜索更好的效果是非常困难的。
— Aravind Srinivas, CEO Perplexity.ai
几个月来我们一贯向客户和互助伙伴反复强调：利用大略的嵌入进行相似检索会产生非常凌乱的结果，还不如从关键词搜索开始。
— Beyang Liu, CTO Sourcegraph
其次，利用关键词搜索检索到文档的缘故原由更直不雅观——我们可以查看与查询匹配的关键词。比较之下，基于嵌入的检索阐明性较差。末了，得益于像Lucene和OpenSearch这样经由数十年优化和实战考验的系统，关键词搜索常日在打算上更高效。
在大多数情形下，稠浊利用效果最佳：对付明显的匹配利用关键词匹配，对付同义词、上位词、拼写缺点以及多模态（例如，图片和文本）利用嵌入。Shortwave分享了他们如何构建他们的RAG流水线，包括查询重写、关键词+嵌入检索和排名。
在大多数情形下，稠浊搜索是最有效的：关键词匹配用于明显的匹配，而嵌入用于同义词、上位词和拼写缺点，以及多模态（如图像和文本）。Shortwave 分享了他们如何构建 RAG 管道，包括查询重写、关键词 + 嵌入检索和排序。
3. 对付新知识首选RAG，而不是微调
RAG和微调都可以用来将新信息纳入大措辞模型并提高特界说务上的性能。那么，我们该当首先考试测验哪个？
最近的研究表明RAG可能更具上风。一项研究将RAG与无监督微调（又称持续预演习）进行了比较，评估了它们在MMLU的一个子集和当前事宜上的表现。他们创造RAG在演习过程中碰着的知识以及完备新的知识方面，持续地优于微调。在另一篇论文中，他们将RAG与在农业数据集上的监督微调进行了比较。同样，RAG带来的性能提升大于微调，尤其是对GPT-4（拜会该论文的表20）。
除了性能提升，RAG还带来了几个实际上风。首先，与持续预演习或微调比较，保持检索索引更新更随意马虎——也更便宜！
其次，如果我们的检索索引含有包含有害或有偏见内容的问题文档，我们可以轻松地删除或修正这些问题文档。
此外，RAG中的R供应了更细致的掌握，以便我们检索文档。例如，如果我们为多个组织托管RAG系统，通过划分检索索引，我们可以确保每个组织只能从它们自己的索引中检索文档。这确保我们不会无意中将一个组织的信息暴露给另一个组织。
4. 长高下文窗口不会让RAG失落去浸染
Gemini 1.5供应了多达1000万个tokens的高下文窗口，一些人开始质疑RAG的未来。
我认为 Sora 对 Gemini 1.5 的宣扬大大浮夸了。一个 1000 万 tokens 的高下文窗口实际上使大多数现有的 RAG 框架变得不必要——你只需将你的数据放入高下文中，像往常一样与模型对话。想象一下，这对那些大部分工程努力都集中在 RAG 上的初创公司/智能体/LangChain 项目会产生若何的影响 😅 大略一句话：这个 1000 万的高下文杀去世了 RAG。干得好，Gemini。
— Yao Fu
虽然长高下文将会对用例如剖析多份文件等运用中是一个变革，但关于RAG即将过期的传言被大大夸年夜了。
首先，纵然有一个1000万tokens的高下文窗口，我们仍旧须要一种方法来选择信息来喂给模型。其次，除了狭义的“大海捞针”评估之外，我们还没看到有力的数据证明模型能有效地推理如此大的高下文。因此，如果没有好的检索和排序，我们有可能用滋扰信息使模型不堪重负，或者乃至可能用完备不干系的信息填满高下文窗口。
末了，是本钱问题。Transformer的推理本钱与高下文长度呈二次方（或在空间和韶光上呈线性）增长。仅仅由于存在一个模型在回答每个问题之前能读取你组织的全体Google Drive内容，并不虞味着这是个好主张。考虑到我们如何利用RAM的类比：纵然存在运行数十TB RAM的打算实例，我们还是会从磁盘进行读写。
以是，不要急着把你的RAG扔掉。纵然高下文窗口的大小增长，这种模式仍旧会很有用。
03.调度和优化事情流程
提示工程只是开始。为了最大限度地利用它们，我们须要思考超越单个提示的范围，并拥抱事情流程。例如，我们如何将一个单一繁芜任务分解为多个更大略的任务？微调或缓存在提高性能和减少延迟/本钱时何时有帮助？在本节中，我们将分享经由验证的策略和现实天下的例子，以帮助您优化和构建可靠的大措辞模型事情流程。
1. 逐步、多回合的流程可以提升效果
我们已经知道，将一大段提示词分解为多少个小段提示词可以取得更好的效果。一个例子是 AlphaCodium：他们从单个提示切换到多步骤事情流程，将GPT-4在CodeContests上的准确率（pass@5）从19％提高到44％。
这个事情流包括：
反思问题
在公共测试中进行推理天生可能的办理方案对可能的办理方案进行排序天生仿照测试在公共和仿照测试中迭代办理方案具有明确目标的小任务非常适宜作为agent或流程提示。虽然不是每个智能体提示都须要构造化输出，但构造化输出有助于与折衷智能体与环境互动的系统进行接口对接。
下面是一些值得考试测验的事情
制订尽可能详细的操持步骤。可以考虑从预定义的操持中进行选择 (参考 https://youtu.be/hGXhFa3gzBs?si=gNEGYzux6TuB1del)
将原始用户提示转化为智能体提示，但要把稳，这个过程可能会有信息丢失！
将智能体行为设计成线性链、DAG 和状态机的形式；不同的依赖关系和逻辑关系适用于不同的任务规模。能否通过不同的任务架构来优化性能？
操持验证；在你的操持中包含如何评估其他智能体相应的辅导，以确保终极组合效果良好。
通过固定的上游状态进行提示工程——确保你的智能体提示能够应对可能发生的各种情形。
2. 优先考虑确定性事情流
虽然AI agent可以动态地响运用户要乞降环境，但它们的非确定性特色使得支配它们成为一大寻衅。agent采纳的每一步都有失落败的可能性，而且从缺点中规复的可能性很小。因此，随着步骤数量的增加，agent成功完成多步骤任务的可能性呈指数级低落。结果是，构建agent的团队创造很难支配可靠的agent。
一种有效的方法是拥有能产生确定性操持的agent系统，然后以构造化、可复制的办法实行这些操持。在第一步，给定一个高等目标或提示，agent天生一个操持。然后，操持被确定性地实行。这使每一步都更可预测和可靠。
好处包括：
天生的操持可以作为少样本示例，用于提示或微调智能体。确定性实行使系统更加可靠，便于测试和调试，且可以精确定位失落败步骤。天生的操持可以表示为有向无环图 (DAG)，比起静态提示更随意马虎理解温柔应新情形。最成功的agent构建者可能是那些管理低级工程师履历丰富的人，由于天生操持的过程类似于我们如何辅导和管理低级职员。我们给低级职员明确的目标和详细的操持，而不是模糊的开放式辅导，我们也该当对我们的agent做同样的事情。
终极，可靠、有效的agent的关键可能在于采取更加构造化、确定性的方法，以及网络数据来精髓精辟提示和微调模型。如果没有这个，虽然智能体在某些情形下表现出色，但整体表现可能会让用户失落望，导致用户流失落
3. 调节temperature参数得到更多样性的输出
假设你的需求是关注LLM输出的多样性。例如，你正在设计一个 LLM 流程，根据用户之前购买的产品列表推举新产品。当你多次运行提示时，可能会创造结果推举过于相似，因此你可能会考虑增加 LLM 要求中的温度参数。
简而言之，增加温度参数使LLM相应更加多样化。在采样时，下一个tokens的概率分布变得更加平坦，这意味着常日较不可能的tokens被更频繁地选择。只管如此，当增加温度时，你可能会把稳到一些与输出多样性干系的失落败模式。例如，目录中一些非常适宜的产品可能从未被 LLM 推举，而某些产品由于在演习时被认为非常适宜而频繁涌现。如果温度过高，输出可能会包含不存在的产品或一些无意义的内容。
换句话说，增加温度并不担保LLM会从你期望的概率分布（例如，均匀随机）中抽样输出。只管如此，我们还有其他方法来增加输出的多样性。最大略的方法是调度提示中的内容。例如，如果提示模板包括一个项目列表，比如历史购买，每次将这些项目插入提示时随机排序，可以使差异显著。
此外，保留最近输出的简短列表可以帮助防止冗余。在我们推举产品的例子中，通过指示LLM避免建议来自这个最近列表的项目，或者谢绝和重新抽样与最近建议类似的输出，我们可以进一步多样化相应。另一种有效的策略是变革提示中利用的说话。例如，加入短语如“选择一个用户会常常利用并喜好的项目”或“选择一个用户可能会推举给朋友的产品”可以转移焦点，从而影响推举产品的多样性。
4. 缓存被低估了
缓存可以节省本钱，并肃清了天生延迟。此外，如果一个相应之前已经由安全审查，我们可以供应这些经由审核的相应，减少供应有害或不当内容的风险。
缓存的一种直接手法是为被处理的项目利用唯一ID，比如我们在总结***文章或产品评论时。当一个要求进来时，我们可以检讨缓存中是否已经存在一个择要。如果是，我们可以立即返回它；如果不是，我们天生它，进行安全审查，供应它，然后将它存储在缓存中以供未来的要求利用。
对付更开放式的查询，我们可以借鉴搜索领域的技能，搜索也利用缓存来处理开放式输入。如自动完成和拼写纠正等功能也有助于规范用户输入，从而提高缓存命中率。
5. 何时须要进行微调
我们可能有一些任务，纵然是设计最奥妙的提示也难以胜任。例如，纵然在进行了大量的提示工程之后，我们的系统可能仍旧离返回可靠、高质量输出有一段间隔。如果是这样，那么可能须要针对您的特界说务对模型进行微调。
成功的例子包括：
Honeycomb 的自然措辞查询助手：最初，“编程指南”与 n-shot 样例一起供应给提示以进行高下文理解。虽然这效果尚可，但微调模型后，在特定领域措辞的语法和规则上输出更好。ReChat 的 Lucy：LLM 须要以一种非常特定的格式天生相应，该格式结合了却构化和非构造化数据，以便前端正确呈现。微调对付让它同等运行至关主要。只管微调可以有效，但它伴随着显著的本钱增加。我们不得不标注微调数据、微调和评估模型，终极自行托管它们。因此，考虑较高的前期本钱是否值得。如果提示让你走了90%的路，那么微调可能不值得投资。然而，如果我们确实决定进行微调，为了降落网络人工注释数据的本钱，我们可以天生并在合成数据上进行微调，或者利用开源数据勾引。
04.评估与监控
评估大措辞模型 (LLMs) 是一个繁芜的过程。LLM的输入和输出都是任意文本，我们给它们设置的任务也多种多样。只管如此，严密而寻思熟虑的评估是至关主要的——OpenAI的技能领导在评估方面投入了大量事情并非无效。
评估 LLM 运用的办法多种多样：有些人认为它像单元测试，有些人以为它更类似于可不雅观察性，还有人认为它便是数据科学的一部分。我们创造这些不雅观点各有其代价。在接下来的部分中，我们将分享一些我们在构建评估和监控管道方面的主要履历教训。
1. 从真实输入/输出样本创建几个断言（Assertion）的单元测试
创建单元测试，包括来自生产的输入和输出样本，基于至少三个标准对输出设定期望。只管三个标准可能看起来是任意的，但这是一个实际开始的数字；更少可能表明您的任务定义不足充分或太开放，就像一个通用谈天机器人。无论是编辑提示、通过RAG添加新高下文还是其他修正，这些单元测试或断言该当被任何对管道的改动所触发。
这篇文章有一个基于断言测试（断言是在编程中用来考验程序的某个条件是否为真的一种语句。如果断言的条件为真，程序可以连续实行；如果条件为假，则程序会抛出错误或非常，常日会中断实行。在单元测试中，断言用来确保代码的某个详细行为或输出符合预期。）的实际用例示例。
可以考虑从指定包含或打消在所有相应中的短语或不雅观点的断言开始。还要考虑检讨以确保单词、项目或句子的数量在一个范围内。对付其他类型的天生，断言可能看起来不同。实行评估是评估代码天生的强大方法，在个中您运行天生的代码并确定运行时状态对付用户要求来说是足够的。
例如，如果用户要求一个名为foo的新功能；那么在实行agent天生的代码之后，foo该当是可调用的！
“实行 – 评估方法”的一个寻衅是，agent的代码常常会使运行时状态与目标代码略有不同。将断言“放宽”到任何可行答案都会知足的最弱假设是有效的。
末了，按照客户预期的办法利用您的产品（即“自用”，dogfooding）可以供应关于实际数据故障模式的测试。这种方法不仅有助于识别潜在的弱点，而且还供应了一个有用的生产样本来源，这些样本可以转换成评估。
2. LLM-as-Judge有用，但不是灵丹灵药
有些人对付利用强大的LLM来评估其他LLM的输出（LLM-as-Judge）抱有疑惑。（我们中的一些人最初也是巨大的疑惑者。）然而，当实行得当时，LLM-as-Judge与人类判断有相称的干系性，并且至少可以帮助构建关于新提示或技能可能如何表现的先验。特殊是，当进行成比拟较（例如，对照组与处理组）时，LLM-as-Judge常日能判断出精确的方向，只管胜/败的幅度可能会有噪声。
以下是一些建议，以充分利用LLM-as-Judge：
利用成比拟较：不要让大措辞模型在 Likert 量表上对单个输出进行评分，而是给它呈现两个选项并让它选择较好的一个。这每每能带来更稳定的结果掌握位置偏差：选项的呈现顺序会影响大措辞模型的决策。为了减少这种偏差，每次成比拟较时都交流选项的顺序进行两次。只要确保在交流后将胜利归因于精确的选项即可。许可平局：在某些情形下，两种选项可能同样好。因此，许可大措辞模型发布平局，以避免其不得不随意选择一个良好者。利用 Chain-of-Thought 方法：在给出终极选择前，哀求大措辞模型阐明其决策过程，这可以提高评估的可靠性。一个额外的好处是，你可以利用一个较弱但更快的大措辞模型，仍能达到类似的结果。由于这一部分常日是在批处理模式下进行的，Chain-of-Thought 增加的延迟并不是问题掌握回答长度：大措辞模型方向于倾向较长的回答。为了减少这种偏差，确保回答的长度相似。LLM-as-Judge 的一个特殊有用的运用是检讨新的提示策略是否会涌现退步。如果您已经有了一系列生产结果，有时您可以用新的提示策略重新运行这些生产示例，并利用LLM-as-Judge来快速评估新策略可能碰着的问题。
这有一个大略但有效的方法 ，以迭代LLM-as-Judge，我们记录大模型的回答、评判的阐明 (即 CoT) 和终极结果。然后与其他人一起检讨这些记录，以确定改进的领域。经由三次迭代，人类与大措辞模型的判断同等性从 68% 提高到了 94%！
LLM-as-Judge并非万能，在一些奇妙的措辞方面，纵然是最强大的模型也无法可靠评估。此外，我们创造传统的分类器和褒奖模型可以比LLM-as-Judge实现更高的准确性，而且本钱更低，延迟更短。对付代码天生，LLM-as-Judge可能比实行评估等更直接的评估策略更弱。
3. 用于评估天生的“演习生测试”
在评估天生时，我们喜好利用以下的“演习生测试”：如果你将完备相同的输入，包括高下文，交给一个干系专业的普通大学生作为任务，他们能否成功完成？须要多永劫光？
如果答案是否定的，由于LLM缺少所需的知识，考虑方法来丰富高下文。
如果答案是否定的，我们大略地无法改进高下文来办理它，那么我们可能碰着了对当代LLM来说过于困难的任务。
如果答案是肯定的，但须要一段韶光，我们可以考试测验减少任务的繁芜性。它能分解吗？是否有任务的某些方面可以更加模板化？
如果答案是肯定的，而且很快就能完成，那么就须要深入剖析数据。模型做错了什么？我们能找到失落败的模式吗？可以考试测验在模型相应前后让它阐明自己的思路，以帮助我们理解模型的事情事理
4. 过分强调某些评估可能会降落整体性能
“当一个衡量标准变成目标时，它就不再是一个好的衡量标准。”
— 古德哈特法则
这方面的一个例子是“针堆中的针 (NIAH)”评估。最初的评估是为了量化随着高下文规模的增加，模型的召回率及其受针的位置影响的程度。然而，这一评估被过分强调，以至于在 Gemini 1.5 的报告中成为图 1 的内容。该评估方法是在一个包含多篇 Paul Graham 文章的长文档中插入一个特定短语 (“The special magic number is:”)，然后哀求模型回顾出这个邪术术字。
虽然有些模型实现了靠近完美的召回，但值得疑惑的是NIAH是否真正反响了运用中所需的推理和召回能力。考虑一个更实际的场景：给定一个小时长会议的笔墨记录，LLM能否总结关键决策和下一步辇儿为，并精确将每个项目归属于干系人士？这一任务更加现实，不仅须要去世记硬背，还须要解析繁芜谈论、识别关键信息并进行综合总结的能力。
这是一个 实际运用中 NIAH 评估 的例子。利用 年夜夫与患者***通话的记录，大模型被讯问关于患者药物的信息。它还包括一个更具寻衅性的 NIAH 评估，插入了一个关于随机披萨配料的短语，例如“制作完美披萨所需的秘密配料是：浓咖啡浸泡的枣子、柠檬和山羊奶酪。”在药物任务上的召回率约为 80%，而在披萨任务上的召回率约为 30%。
此外，过分强调NIAH评估可能会导致大模型在提取和总结任务上的性能降落。由于这些大模型被微调到关注每一句话，它们可能开始将不干系的细节和分散把稳力的内容当作主要内容，因此在终极输出中包含它们（实际上不应该包含）！
这种情形也可能适用于其他评估和利用场景。例如，在天生择要时，过分强调事实同等性可能导致择要内容不足详细 (因此不太可能在事实上同等) 并且可能不足干系。反之，过分强调写作风格和文采可能导致措辞更加华美，但同时可能引入事实上的不一致。
5. 将标注任务简化为二元判断或者成比拟较
开放式反馈或用 李克特量表 对模型输出进行评分，认知包袱较大。结果，网络的数据更加喧华——由于人类评分员之间的变异性——因此不太有用。一种更有效的方法是简化任务，减少标注者的认知包袱。事情良好的两项任务是二元分类和成比拟较。
在二元分类中，哀求标注者对模型的输出做出大略的是或否的判断。他们可能会被讯问天生的摘假如否与源文档在事实上是同等的，或者提出的回应是否干系，或者是否包含有害内容。与Likert量表比较，二元决策更精确，评分员之间更同等，并且提高了吞吐量。Doordash便是通过一系列是或否的问题为菜单条款设置标签行列步队的办法。
在成比拟较中，向标注者供应一对模型相应，并讯问哪个更好。由于对付人类来说，说“A比B好”比单独为A或B分配一个分数更随意马虎，这导致更快和更可靠的标注（相对付Likert量表）。在Llama2聚会上，Llama2论文的作者之一Thomas Scialom确认，与网络监督衰落调数据（如书面回应）比较，成比拟较更快、更便宜。前者的本钱是每单位3.5美元，而后者的本钱是每单位25美元。
如果你正在开始编写标签指南，这里有一些来自谷歌和必应搜索的指南。
保护方法和评估可以互换利用
保护方法有助于捕捉不适当或有害的内容，而评估则有助于衡量模型输出的质量和准确性。对付无参考评估而言，它们可以被视为一体两面。无参考评估是指不依赖于“标准”参考（例如人类编写的答案）的评估，能够仅基于输入提示和模型的相应来评估输出的质量。
例如，择要评估 中，我们只需考虑输入文档即可评估择要在事实同等性和干系性方面的表现。如果择要在这些指标上得分较低，我们可以选择不向用户展示它，有效地将评估作为保护方法。类似地，无参考的翻译评估 可以在不须要人工翻译参考的情形下评估翻译质量，同样许可我们将其作为保护方法利用。
6. 大模型纵然不应该输出也会输出
与LLM互助的一个紧张寻衅是，它们常常会天生输出，纵然它们不应该这样做。这可能导致无害但毫无意义的回应，或者更严重的毛病，如有害或危险内容。例如，当被哀求从文档中提取特定属性或元数据时，LLM可能会自傲地返回值，纵然这些值实际上并不存在。或者，模型可能会用非英语回应，由于我们在高下文中供应了非英语文档。
虽然我们可以考试测验提示LLM返回一个“不适用”或“未知”的相应，但这并非万无一失。纵然有日志概率 (log probabilities) 可用，它们也无法准确指示输出质量。虽然日志概率显示了一个词元在输出中涌现的可能性，但它们不一定反响天生文本的精确性。相反，对付那些经由指令微调 (instruction-tuned) 的模型，即演习来相应查询并天生连贯回答的模型，日志概率可能校准得不足好。因此，高日志概率可能意味着输出流畅且连贯，但不代表其准确或干系。
虽然精心设计的提示工程可以在一定程度上有所帮助，我们该当用更强有力的保护方法来补充，以检测和过滤/重新天生不须要的输出。例如，OpenAI供应了一个内容审核 API，可以识别不屈安的相应，如仇恨辞吐、自伤或性输出。同样，有许多包用于检测个人身份信息 (PII) 。一个好处是保护方法大体上不受用例的影响，因此可以广泛地运用于给定措辞的所有输出。此外，通过精确检索，如果没有干系的文档的话，我们的系统可以确定地回应“我不知道”。
相应地，大措辞模型有时在该当天生内容时却未能天生。这可能是由于各种缘故原由，从 API 供应者的长尾延迟等大略问题到内容审核过滤器阻挡输出等繁芜问题。因此，持续记录输入和 (可能缺失落的) 输出对付调试和监控非常主要。
7. 大模型的幻觉是个执拗的问题
不同于内容安全或个人可识别信息（PII）毛病，事实上，不一致性问题更执拗，且更难以检测。它们更为常见，发生率在5 – 10%之间，而且根据我们从大模型（LLM）供应商那里学到的，即便是像择要这样的大略任务，将其降至2%以下也颇具寻衅。
为理解决这个问题，我们可以结合利用提示工程（天生前）和事实不一致性防护方法（天生后）。对付提示工程，如思维链（CoT）通过让LLM在终极返回输出之前阐明其推理过程来帮助减少幻觉。然后，我们可以运用事实不一致防护方法来评估择要的事实性，并过滤或重新天生幻觉。在某些情形下，可以确定性地检测到幻觉。当利用来自RAG检索的资源时，如果输出是构造化的并且标识了资源是什么，你该当能够手动验证它们来源于输入高下文。
本文由 @小布Bruce 原创发布于大家都是产品经理。未经作者容许，禁止转载
题图来自Pixabay，基于CC0协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事
