ToB企服应用市场:ToB评测及商务社交产业平台

标题: 构建大型语言模型（LLM）产品的实战指南 [打印本页]

---

作者: 宁睿    时间: 2024-6-19 22:11
标题: 构建大型语言模型（LLM）产品的实战指南
  每周跟踪AI热点新闻动向和震撼发展 想要探索生成式人工智能的前沿希望吗？订阅我们的简报，深入解析最新的技术突破、实际应用案例和未来的趋势。与举世数同行一同，从行业内部的深度分析和实用指南中受益。不要错过这个时机，成为AI领域的领跑者。点击订阅，与未来同行！ 订阅：https://rengongzhineng.io/

利用大型语言模型（LLM）举行开发的时代令人高兴。过去的一年中，LLM在实际应用中的表现已经达到“足够好”的水平，并且每年都在变得更好且更自制。再加上社交媒体上的一系列演示，到2025年，预计将有2000亿美元的投资进入人工智能领域。别的，提供者的API使LLM变得更加易于访问，使得不但是呆板学习工程师和科学家，任何人都可以将智能融入他们的产品。然而，尽管构建AI的门槛已经降低，但创建真正有用的产品和系统——不但仅是演示——仍然非常困难。

我们过去一年不绝在构建过程中，发现了许多棘手的题目。固然我们不敢说代表整个行业，但我们希望分享我们的经验，以帮助你避免我们犯过的错误，并加速你的迭代。这些经验分为三个部分：

战术层面：提示、RAG、流程工程、评估和监控的实践。不管你是构建LLM的从业者，照旧周末项目标爱好者，这部分内容都是为你而写。

操纵层面：产品发布的构造和一样平常关注点，以及怎样打造高效团队。针对希望可持续且可靠地摆设产品的产品/技术领导者。

战略层面：长远的宏观视角，带有明确观点，如“在产品市场契合前不利用GPU”和“关注系统而非模型”，以及怎样迭代。专为首创人和高管们撰写。

我们的目标是提供一份实际指南，帮助你成功构建LLM产品，基于我们的经验，并引用行业中的案例。

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

战术层面：利用LLM的具体操纵


在本部分中，我们分享了新兴LLM堆栈核心组件的一些最佳实践：进步质量和可靠性的提示技巧、评估策略、改进基础生成的检索加强生成（RAG）思绪等。我们还将探究怎样设计人机协作工作流。尽管技术仍在快速发展，但我们希望这些经验——我们通过无数实验获得的副产品——能够经受住时间的检验，帮助你构建和发布可靠的LLM应用。

提示


开发新应用时，我们建议从提示开始。提示的作用常常被低估和高估。低估是因为正确的提示技术，利用得当，可以取得非常好的结果。高估是因为纵然基于提示的应用，也必要围绕提示举行大量工程工作以取得良好结果。

充实利用基本提示技术


一些提示技术在各种模型和任务中一向有助于进步性能：n-shot提示+上下文学习、链式头脑（CoT）以及提供相干资源。

通过n-shot提示举行上下文学习的理念是向LLM提供几个示例，展示任务并对齐输出和我们的渴望。一些小建议：

• 假如n值太低，模型可能会过度依靠这些特定示例，减弱其泛化能力。经验法则是，n值≥5。不妨实验几打示例。
  
• 示例应代表预期的输入分布。假如你在构建一个电影摘要器，包罗差异类型的样本，与实际情况中看到的大致相同。
  
• 不一定要提供完整的输入-输出对。在许多情况下，渴望输出的示例就足够了。
  
• 假如利用支持工具利用的LLM，n-shot示例也应利用你希望署理利用的工具。
  

在链式头脑（CoT）提示中，我们鼓励LLM在返回终极答案之前解释其思考过程。可以将其视为提供给LLM的草图本，使其不必全在记忆中完成。原始方法是简单地将短语“让我们一步步思考”添加到指令中，但我们发现，通过添加一两句额外的句子使CoT更具体，通常可以明显减少幻觉率。比方，当要求LLM总结会议记录时，我们可以明确步骤，如：

• 首先，列出关键决策、跟进事项及相干负责人。
  
• 然后，检查草图本中的细节是否与记录同等。
  
• 最后，将关键点综合成简洁的摘要。
  

请注意，最近一些人对这一技术的实际结果提出了质疑。别的，关于利用链式头脑举行推理时具体发生了什么，也存在大量争论。不管怎样，当有可能时，这一技术值得实验。

提供相干资源是一种强大的机制，可以扩展模型的知识库，减少幻觉，并增长用户的信托。通常通过检索加强生成（RAG）实现，向模型提供可以直接在相应中利用的文本片段是一种基本技术。在提供相干资源时，不但仅是包罗它们；还要告诉模型优先利用它们，直接引用它们，有时还要提到当资源不敷时。这些有助于将署理相应“定位”到资源库。

结构化输入和输出


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

比方，许多互联网上关于编写SQL的题目都会先指定SQL模式。因此，你可能渴望有用的文本到SQL提示应包罗结构化模式界说；确实云云。

结构化输出也有类似的目标，但它还简化了与系统下游组件的集成。Instructor和Outlines在结构化输出方面表现良好。（假如你正在导入LLM API SDK，请利用Instructor；假如你正在导入Huggingface用于自托管模型，请利用Outlines。）结构化输入清晰表达任务，类似于训练数据的格式，增长了更好输出的可能性。

在利用结构化输入时，注意每个LLM家属有其自己的偏好。Claude偏好，而GPT偏好Markdown和JSON。利用XML时，你甚至可以通过提供标签来预填充Claude的相应，如下所示：

1. {
2.     "messages": [
3.         {
4.             "role": "user",
5.             "content": "从这个产品描述中提取<name>, <size>, <price>和<color>并放入<response>标签中。\n<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>"
6.         },
7.         {
8.             "role": "assistant",
9.             "content": "<response><name>"
10.         }
11.     ]
12. }

复制代码

保持简洁的小提示


软件中的“神对象”是一个常见的反模式，同样实用于提示。

提示通常从简单开始：几句指令，加上几个示例，就可以开始了。但是，当我们试图进步性能并处置惩罚更多的边缘情况时，复杂性会逐渐增长。更多的指令。多步推理。几十个示例。不知不觉中，我们最初简单的提示变成了一个2000个标记的怪物。而且更糟糕的是，它在更常见和简单的输入上表现更差！GoDaddy分享了他们构建LLM的第一大教训，正是这个题目。

就像我们努力（艰难）保持系统和代码简单一样，我们也应该对提示保持简单。不要将全部任务放在一个提示中，而是将其分解成多个步骤。比方，对于会议记录摘要器，我们可以将其分解为：

• 将关键决策、举措项和负责人提取成结构化格式
  
• 将提取的细节与原始记录举行同等性检查
  
• 根据结构化细节生成简洁摘要
  

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

设计上下文标记


重新思考并挑衅你关于必要多少上下文才气发送给署理的假设。像米开朗基罗一样，不要堆砌你的上下文雕塑——削减多余的质料，直到雕塑显现。RAG是一种汇集全部可能相干信息的流行方法，但你做了什么来提取必要的内容？

我们发现，将发送给模型的终极提示——包罗全部上下文构建、元提示和RAG结果——放在一个空缺页面上阅读，真的有助于重新思考你的上下文。我们发现冗余、自相抵牾的语言和糟糕的格式。

另一个关键优化是上下文的结构。你的文档袋表示对人类没有帮助，不要假设它对署理有用。仔细思量怎样结构化你的上下文，以突出其各部分之间的关系，并尽可能简化提取过程。

信息检索 / RAG


除了提示，另一种有用引导LL

M的方法是提供知识作为提示的一部分。这使LLM能够在提供的上下文中举行在上下文学习。这被称为检索加强生成（RAG）。实践者发现，RAG在提供知识和改进输出方面有用，同时所需的精神和成本远低于微调。RAG的结果取决于检索到的文档的相干性、密度和详细程度。

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

• 首先是相干性。通常通过排名指标如平均倒数排名（MRR）或归一化折扣累计增益（NDCG）来量化。MRR评估系统在排名列表中第一个相干结果的表现，而NDCG则思量全部结果的相干性及其位置。
  
• 其次是信息密度。假如两个文档同样相干，我们应该选择更简洁、没有多余细节的那个。
  
• 最后是文档的详细程度。想象我们在构建一个RAG系统，用于从自然语言生成SQL查询。我们可以简单地提供表模式及列名作为上下文。但假如我们包罗列描述和一些代表性值呢？额外的详细信息可以帮助LLM更好地理解表的语义，从而生成更正确的SQL。
  

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


在嵌入式RAG演示云云流行的情况下，很轻易忽略或忘记信息检索领域的几十年研究息争决方案。

固然嵌入无疑是强大的工具，但它们并不是万能的。首先，它们在捕捉高级语义相似性方面表现出色，但在更具体的基于关键词的查询（如用户搜索名字、首字母缩略词或ID）时可能表现较差。基于关键词的搜索（如BM25）就是专门为此设计的。并且经过多年的关键词搜索，用户可能已经风俗了它，假如未能返回他们渴望检索到的文档，可能会感到沮丧。

矢量嵌入并没有神奇地解决搜索题目。究竟上，繁重的工作在于你用语义相似性搜索重新排序之前的步骤。要在BM25或全文搜索基础上取得实质性改进是很难的。——Aravind Srinivas，Perplexity.ai CEO

我们不绝在向客户和互助伙伴传达这一信息。利用简单嵌入的最近邻搜索会产生非常嘈杂的结果，你可能更适合从关键词搜索开始。——Beyang Liu，Sourcegraph CTO

其次，用关键词搜索更轻易理解为什么某个文档会被检索到——我们可以检察与查询匹配的关键词。相比之下，基于嵌入的检索则不那么可解释。最后，感谢像Lucene和OpenSearch这样的系统经过几十年的优化和实战测试，关键词搜索通常在计算效率上更高。

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

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


RAG和微调都可以用于将新信息纳入LLM，并进步特定任务的性能。那么，应该先实验哪个呢？

最近的研究表明，RAG可能占有优势。一项研究比较了RAG和无监督微调（又称一连预训练），在MMLU子集和当前事件上举行评估。他们发现，RAG在处置惩罚训练中遇到的知识和完全新知识方面， consistently outperformed fine-tuning for knowledge encountered during training as well as entirely new knowledge。另一篇论文中，他们比较了RAG和有监督微调在农业数据集上的表现。同样，RAG的性能提拔大于微调，特别是对于GPT-4。

除了改进的性能外，RAG还具有一些实际优势。首先，与一连预训练或微调相比，保持检索索引的最新状态更轻易——也更自制！其次，假如我们的检索索引中包罗有毒或私见内容的题目文档，我们可以轻松删除或修改这些文档。

别的，RAG提供了更细粒度的控制。比方，假如我们为多个构造托管一个RAG系统，通太过区检索索引，可以确保每个构造只能检索其自己的索引文档，防止无意中将一个构造的信息暴露给另一个构造。

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


随着Gemini 1.5提供长达10M标记的上下文窗口，一些人开始质疑RAG的未来。

我倾向于认为Sora对Gemini 1.5的宣传过头了。10M标记的上下文窗口实际上使现有的大多数RAG框架变得不必要——你只需将你的数据放入上下文中，然后像平常一样与模型对话。想象一下，这对全部初创公司/署理/语言链项目标影响，其中大部分工程工作都是RAG

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4