LLM

本文探讨了构建和管理“生成式 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 产品的人都有用的建议和经验。...