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