LLM

本文是 Anthropic 官方文档给出的一些 LLM 术语的解释，我这里将其翻译为了中文，并增加了 LLM 中一些常见的术语词。 LLM 大语言模型（LLM, Large Language Model）是一种具有大量参数的 AI 语言模型，能够执行多种复杂且实用的任务。这些模型通过大量文本数据进行训练，能够生成类人文本、回答问题、总结信息等。Claude 是基于大语言模型的对话助手，并通过人类反馈强化学习（RLHF, Reinforcement Learning from Human Feedback）进一步训练，以更有帮助、诚实且无害。 Pretraining 预训练（Pretraining）是语言模型在大规模无标注文本数据集上进行的初始训练过程。以 Claude 为例，自回归语言模型会根据文档中的上下文来预测下一个词。预训练模型本身并不擅长回答问题或遵循指令，通常需要复杂的提示工程来引导出预期的行为。通过微调（Fine-tuning）和人类反馈强化学习（RLHF），这些预训练模型可以进一步优化，从而在广泛任务中变得更加有用。 Fine-tuning 微调（Fine-tuning）是通过额外数据进一步训练预训练模型（Pretraining）的过程。这会使模型开始模仿微调数据集中的模式和特征。微调可以帮助模型适应特定领域、任务或写作风格，但需要仔细考虑微调数据的质量及其对模型性能和潜在偏见的影响。 SFT (Supervised Fine-Tuning) SFT 是一种用于语言模型优化的技术，它通过使用标注好的数据集对模型进行进一步训练。相比预训练过程中的无监督学习，SFT 专注于让模型在特定任务上表现更好。在监督微调中，模型根据人为标注的输入和输出对进行学习，从而提高其在回答问题、完成任务或遵循指令等特定场景中的表现。SFT 经常用于帮助模型理解更复杂的任务要求，使其生成的输出更加符合预期。 LORA（Low-Rank Adaptation） LORA 是一种微调大型预训练语言模型的技术。它通过在模型的某些权重矩阵上引入低秩分解来降低模型更新所需的参数数量。传统的微调需要更新模型的所有参数，而 LORA 只微调一部分参数，这大大减少了微调的计算成本和存储需求，同时保持了模型的性能。LORA 在特定任务或数据集上的微调表现良好，因为它可以灵活地适应新的任务要求，而不需要重新训练整个模型。 QLORA（Quantized Low-Rank Adaptation） QLORA（量化低秩适应）是一种用于大语言模型的微调技术，它通过对模型权重进行低秩分解和量化来减少微调的计算开销，同时保持性能。这种方法能够在保持模型准确性的同时，显著降低内存需求和计算复杂度，因此特别适用于在有限的资源下微调超大规模模型。 QLORA 的主要特点是： 低秩适应（Low-Rank Adaptation, LORA）：通过对模型权重的低秩分解，QLORA 可以仅对少量参数进行微调，这样可以在节省计算资源的同时仍能有效捕捉任务相关的模式。 量化（Quantization）：QLORA 使用 4-bit 或更低精度的量化技术来减少模型的存储和计算要求。量化技术通过缩减模型中存储和处理的参数位数，能够降低硬件负载，而不显著影响模型的性能。 高效微调：QLORA 可以在不完全重训练模型的情况下进行微调，尤其适用于资源受限的场景，例如边缘设备或中小型研究团队。 QLORA 技术的出现使得对大型预训练模型进行特定任务的微调变得更加可行。 RLHF（Reinforcement Learning from Human Feedback） 来自人类反馈的强化学习（RLHF, Reinforcement Learning from Human Feedback）是一种用于训练预训练语言模型的技术，使其行为更加符合人类的偏好。这种训练方式可以帮助模型更有效地执行指令，或表现得更像聊天机器人。人类反馈的过程包括对多个文本样本进行排序，强化学习会鼓励模型倾向于生成与高排名样本相似的输出。Claude 已通过 RLHF 进行训练，使其成为一个更加有用的助手。更多详情可以参考 Anthropic 的论文: Training a Helpful and Harmless Assistant with Reinforcement Learning from Human Feedback。...

我们在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第一部分)：战术篇》中分享了操作 LLM 应用程序时精炼的战术见解。战术是具体的行动，用于实现特定目标。在《我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第二部分)：运营篇》中，我们还探讨了支持战术工作的高级过程。 那么，这些目标从何而来？这就是战略的领域。战略回答了战术和运营背后的“是什么”和“为什么”问题。 我们提出了一些主张，如“在找到产品市场契合 (PMF) 之前不要使用 GPU”和“专注于系统而非模型”，以帮助团队更好地分配有限资源。我们还建议了一条迭代至优秀产品的路线图。最后一部分内容将回答以下问题： 构建 vs. 购买：何时应该训练自己的模型，何时应该利用现有 API？答案是“视情况而定”。我们会分享这些情况的具体影响因素。 迭代至优秀：如何打造持久的竞争优势，而不仅仅是使用最新的模型？我们将讨论构建强大系统和提供令人难忘体验的重要性。 以人为本的 AI：如何将 LLMs 有效地融入人类工作流，最大化生产力和幸福感？我们强调了构建支持和增强人类能力的 AI 工具的重要性，而不是完全取代人类。 入门指南：团队在开始构建 LLM 产品时的关键步骤是什么？我们会概述一个从提示工程、评估到数据收集的基本操作手册。 低成本认知的未来：快速降低的成本和不断增加的 LLM 能力将如何塑造 AI 应用的未来？我们将探讨历史趋势，并展示如何估算某些应用的经济可行性。 从演示到产品：从一个引人注目的演示到一个可靠的、可扩展的产品需要什么？我们强调了从原型到生产的严格工程、测试和改进的必要性。 要回答这些难题，让我们一步一步来思考…… 战略：在构建 LLM 产品时不被超越 成功的产品需要深思熟虑的规划和艰难的优先级排序，而不是无休止的原型制作或追随最新的模型发布。在最后一部分中，我们将展望未来，思考构建优秀 AI 产品的战略考量。我们还将探讨团队将面临的关键决策，例如何时构建和何时购买，并建议一个早期 LLM 应用开发的“操作手册”。 在找到产品市场契合 (PMF) 之前不要使用 GPU 要打造优秀的产品，你的产品需要不仅仅是依赖他人 API 的简单包装。但过于依赖自己训练模型的错误也可能更加昂贵。过去一年中，我们看到大量风险投资，包括令人震惊的 60 亿美元 A 轮融资，都用在了训练和定制模型上，却没有明确的产品愿景或目标市场。在本节中，我们将解释为什么立即跳到训练自己的模型是个错误，并探讨自托管的角色。 从头训练几乎永远没有意义 对于大多数组织来说，从头预训练一个大语言模型 (LLM) 是一个不可行的分散注意力的行为。 尽管这很诱人，而且看起来似乎每个人都在这么做，但开发和维护机器学习基础设施需要大量资源。这包括收集数据、训练和评估模型以及部署它们。如果你还在验证产品市场契合 (PMF)，这些努力将分散你开发核心产品的资源。即使你拥有计算能力、数据和技术能力，预训练的 LLM 可能会在几个月内过时。 例如，BloombergGPT 是一个专门为金融任务训练的 LLM。该模型在 3630 亿个 Token 上进行了预训练，花费了 9 名全职员工（4 名来自 AI 工程团队，5 名来自 ML 产品和研究团队）的大量努力。尽管如此，它在一年内在这些金融任务上被 gpt-3....

本文探讨了构建和管理“生成式 AI 产品”应用的运营方面，涵盖了数据、模型、产品和人员四个关键领域。作者强调了数据质量对模型性能的重要性，并介绍了如何检测和减少开发环境与生产环境之间的差异。文章还讨论了模型版本控制、选择合适模型大小以及设计以人为中心的“用户体验”的重要性。最后，作者强调了团队合作和实验文化的重要性，并建议将重点放在流程而非工具上。 ➡️ 数据 输入数据质量对模型性能至关重要，需要定期审查输入和输出数据，以了解数据分布、边缘情况和模型的局限性。 开发环境与生产环境之间的差异会导致模型性能下降，需要进行结构性和内容性的偏差检测。 定期审查模型输出可以帮助识别和适应新的模式或失败模式，并通过代码和断言将这些模式转化为可操作的指标。 ➡️ 模型 为了方便下游集成，需要生成结构化的输出，例如 JSON 或 YAML 格式。 不同模型之间迁移提示可能很困难，需要进行测试和评估，以确保性能不会下降。 版本控制和固定模型版本可以避免模型行为的意外变化，并确保模型的稳定性。 选择最小的模型来完成任务，可以降低延迟和成本，并通过提示工程和上下文学习提高模型性能。 ➡️ 产品 在产品开发过程中尽早并经常地引入设计，可以帮助理解用户需求并改善用户体验。 设计以人为中心的“用户体验”，可以收集用户反馈并改进模型。 优先考虑产品的关键需求，例如可靠性、安全性、准确性和可扩展性，并根据用例调整风险承受能力。 ➡️ 人员 团队合作和实验文化是成功的关键，需要鼓励团队成员进行实验并分享经验。 将重点放在流程而非工具上，可以避免不必要的技术债务，并提高团队的长期生产力。 团队需要包括 AI 工程师、平台工程师、数据工程师和机器学习工程师等不同角色，以确保产品的成功。 避免过度依赖 AI 工程师，需要根据产品开发阶段的不同需求，组建相应的团队。 原文 有句可能是传闻的名言，被许多领导者引用：“业余者谈策略和战术，专业人士谈操作。” 在战术层面看到的是各种独特的问题，而在操作层面看到的却是需要修复的组织失调模式。在战略层面看到的是机会，而在操作层面看到的是值得迎接的挑战。 在本文的第一部分中，我们介绍了战术性地与大语言模型 (LLMs) 一起工作的具体细节。在下一部分中，我们将放大视角，探讨长期战略考虑。在这一部分，我们讨论了介于战略和战术之间的操作方面，把理论转化为实践。 运营 LLM 应用程序提出了一些在运营传统软件系统中经常出现的问题，但往往带有新颖的变化，使其更具挑战性。同时，LLM 应用程序还引发了全新的问题。我们将这些问题及其答案分为四个部分：数据、模型、产品和人员。 关于数据，我们回答了：应该如何以及多频繁地审查 LLM 的输入和输出？如何测量和减少测试-生产偏差？ 关于模型，我们回答了：如何将语言模型集成到整个技术栈中？如何管理模型的版本和迁移？ 关于产品，我们回答了：设计应该在何时介入应用程序开发过程，为什么是“越早越好”？如何设计具有丰富人类反馈的用户体验？如何在众多冲突需求中进行优先排序？如何校准产品风险？ 最后，关于人员，我们回答了：应该雇佣谁来构建成功的 LLM 应用程序，以及何时雇佣他们？如何培养实验文化？如何利用新兴的 LLM 应用程序来构建自己的 LLM 应用程序？哪个更重要：过程还是工具？ 作为一个 AI 语言模型，我没有意见，因此无法告诉你你提供的引言是否“最佳”。不过，我可以说这段引言为接下来的内容定下了合适的基调。 操作：开发和管理 LLM 应用程序及其团队 数据 正如食材的质量决定了菜肴的味道，输入数据的质量决定了机器学习系统的性能。此外，输出数据是判断产品是否工作的唯一标准。所有作者都密切关注数据，每周花费数小时查看输入和输出数据，以更好地了解数据分布、模式、边缘情况及其模型的局限性。 检查开发-生产偏差 传统机器学习管道中一个常见的错误来源是训练-服务偏差。当训练使用的数据与模型在生产中遇到的数据不一致时，就会发生这种情况。虽然我们可以在不训练或微调的情况下使用 LLM，但开发-生产数据偏差依然存在。基本上，我们在开发过程中测试系统的数据应与系统在生产中面临的数据相符。如果不这样做，我们可能会发现生产环境中的准确性下降。 LLM 的开发-生产偏差可以分为两种类型：结构性偏差和内容性偏差。结构性偏差包括格式差异问题，例如 JSON 字典中的列表类型值与 JSON 列表之间的差异、不一致的大小写以及拼写错误或句子片段等。这些错误可能导致模型性能不可预测，因为不同的 LLM 是在特定数据格式上训练的，对细微变化非常敏感。内容性或语义偏差指的是数据意义或上下文的差异。...

本文探讨了使用大型语言模型（LLM）构建产品的关键经验教训，并分享了作者团队在过去一年中从实际应用中总结出的宝贵经验。文章分为三个部分：战术、运营和战略，本篇是第一部分，重点介绍了LLM的战术技巧，包括提示、检索增强生成、流程工程以及评估和监控。 ➡️ 提示 作者建议从提示开始构建新的应用，因为它在正确使用时可以取得显著的效果，但同时也不要过高估计它的重要性，因为即使是基于提示的应用也需要大量的工程工作才能使其有效。 作者推荐了一些经过验证的提示技巧，包括： N-shot 提示 + 上下文学习：提供几个示例来演示任务，并使输出与预期相符。 思维链提示：鼓励LLM在返回最终答案之前解释其思考过程。 提供相关资源：通过检索增强生成（RAG）提供模型可以直接利用的文本片段，帮助模型更好地理解上下文。 作者强调了结构化输入和输出的重要性，并举例说明了如何使用结构化输入来帮助模型更好地理解输入，以及如何使用结构化输出来简化与下游系统的集成。 作者建议将大型提示分解成多个小型提示，每个提示只做一件事，并专注于做好这件事。 作者还建议仔细思考模型需要的上下文信息，并优化上下文结构，以突出上下文各个部分之间的关系。 ➡️ 信息检索/RAG 作者指出，RAG的有效性取决于检索到的文档的相关性、密度和细节。 作者建议不要忽视关键词搜索，将其作为基线并将其用于混合搜索。 作者认为，在大多数情况下，混合搜索效果最好，即使用关键词匹配来查找明显的匹配项，并使用嵌入来查找同义词、上位词和拼写错误，以及多模态（例如图像和文本）。 作者建议在新的知识方面优先考虑RAG而不是微调。 作者认为，即使出现了长上下文模型，RAG也不会过时。 ➡️ 调整和优化工作流程 作者建议使用分步、多轮“流程”来提高性能。 作者建议优先考虑确定性工作流程，因为它们更容易部署和调试。 作者建议使用缓存来降低成本和消除生成延迟。 作者建议在必要时进行微调，但要权衡其成本和收益。 ➡️ 评估和监控 作者建议创建一些基于断言的单元测试，这些测试基于真实的输入/输出样本，并根据至少三个标准来预期输出。 作者建议使用LLM作为评判者来评估其他LLM的输出，但要意识到它不是万能的。 作者建议使用“实习生测试”来评估生成，即如果将相同的输入和上下文提供给相关专业的普通大学生，他们是否能够成功完成任务？ 作者警告说，过度强调某些评估指标可能会损害整体性能。 作者建议将标注简化为二元任务或成对比较。 作者认为，无参考评估和护栏可以互换使用。 作者指出，LLM即使不应该生成输出也会生成输出，因此需要使用护栏来检测和过滤/重新生成不希望的输出。 作者认为，幻觉是一个顽固的问题，需要结合提示工程和事实不一致护栏来解决。 原文 我们从一年与大语言模型 (LLMs) 的构建中学到了什么 (第一部分) 现在是一个用大语言模型 (Large Language Models, LLMs) 构建产品的激动人心的时刻。在过去的一年里，LLMs 已经达到了“足够好”可以应用于实际场景的水平。LLMs 的进步速度加上社交媒体上的众多演示，预计将推动到 2025 年对人工智能的 2000 亿美元投资。LLMs 也广泛开放，使得不仅仅是机器学习工程师和科学家，所有人都可以将智能融入到他们的产品中。虽然构建 AI 产品的门槛已经降低，但要创建那些在演示之外也能有效的产品仍然是一个复杂的任务。 我们已经发现了一些开发基于 LLMs 产品的关键但常常被忽视的教训和方法。了解这些概念可以让你在无需机器学习专业知识的情况下，比大多数同行更具竞争力！在过去的一年里，我们六个人一直在构建基于 LLMs 的实际应用。我们意识到有必要将这些经验汇集在一起，造福社区。 我们来自不同的背景，担任不同的角色，但我们都亲身经历了使用这项新技术的挑战。我们中的两人是独立顾问，帮助众多客户将 LLM 项目从初始概念转化为成功的产品，看到了成功与失败的模式。我们中有一人是研究人员，研究机器学习/人工智能团队的工作方式及其工作流程的改进。我们中的两人在应用 AI 团队中担任领导职务：一人在科技巨头公司，另一人在初创公司。最后，我们中的一人教授过数千人学习深度学习课程，现在致力于使 AI 工具和基础设施更易于使用。尽管我们的经历不同，但我们惊讶地发现我们学到的经验有着一致的主题，这些见解没有被广泛讨论。 我们的目标是制作一个实用指南，帮助大家围绕 LLMs 构建成功的产品，从我们的经验中汲取教训，并指出行业中的一些例子。我们在过去的一年里亲自动手，获取了宝贵的经验，往往是通过艰难的方式。虽然我们不敢说代表整个行业，但我们在这里分享了一些对任何构建 LLM 产品的人都有用的建议和经验。...