万字经验 | 使用大模型（LLMs）构建产品一年后，我们有些经验想告诉你_如何利用大模型做会议摘要

在接下来的文章里，我们将分享一些关于大语言模型（LLM）技术核心组件的最佳实践，包括：提升质量和可靠性的提示技巧、评估输出的策略、改进检索增强生成、调整和优化工作流程等四部分。我们还将探讨如何设计人类参与的工作流程。尽管这项技术仍在迅速发展，但我们希望这些经验教训——我们一起进行的无数实验的成果——能够经受时间的考验，并帮助您构建并交付强大的LLM应用程序。

大语言模型（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）开始。人们很容易低估或者低估它的重要性。正确的提示技巧，若使用得当的情况下，可以让我们取得很大的进展，所以它往往被低估；但是，即使是基于提示的应用程序也需要围绕提示进行大量工程开发才能很好地工作，因此其重要性也容易被高估。

【一一AGI大模型学习 所有资源获取处一一】

①人工智能/大模型学习路线

②AI产品经理入门指南

③大模型方向必读书籍PDF版

④超详细海量大模型实战项目

⑤LLM大模型系统学习教程

⑥640套-AI大模型报告合集

⑦从0-1入门大模型教程视频

⑧AGI大模型技术公开课名额

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 把这个作为他们在使用大语言模型时的首要经验。

就像我们努力保持系统和代码的简约一样，我们的提示也应该如此。我们不应该拥有一个用于会议记录的全能型提示，我们可以将其分解为步骤：

1. 将关键决策、行动项目和责任人提取成结构化格式
2. 检查提取的详情与原始记录的一致性
3. 从结构化的细节生成简洁的摘要

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

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 项目会产生怎样的影响 声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】