过去一年建设AI产品实战经验（运营篇）

运营

运营一个LLM应用程序会引发一些熟悉的问题，这些问题通常与运营传统软件类似，但往往也有一些新颖的变化让事情变得有趣，所以LLM应用程序也会引发全新的问题。我们将这些问题及答案分为四个部分：数据、模型、产品和人员。

关于数据，我们建议抛出的问题：

• 你应该如何以及多久审查LLM的输入和输出？
• 如何衡量和减少测试-生产偏差？

关于模型，我们建议抛出的问题：

• 如何将语言模型整合到堆栈的其余部分？
• 你应该如何考虑模型的版本控制以及在模型和版本之间进行迁移？

关于产品，我们建议抛出的问题：

• 设计应该在应用开发过程中何时参与，为什么要“尽早参与”？
• 如何设计具有丰富人机反馈的用户体验？
• 如何优先考虑众多冲突的需求？
• 如何校准产品风险？

关于人员，我们建议抛出的问题：

• 你应该雇佣谁来构建一个成功的LLM应用程序，以及何时雇佣他们？
• 你如何培养正确的文化，即实验文化？
• 你应该如何利用新兴的LLM应用程序来构建自己的LLM应用程序？
• 流程和工具哪个更关键？

我们抛出的这些问题为接下来的内容铺平了道路。

运营：开发和管理LLM应用程序及打造团队

数据

正如食材的质量决定了菜肴的口味一样，输入数据的质量限制了机器学习系统的性能，输出数据是判断产品是否有效的唯一方法。所有创业者都紧密关注数据，每周花费数小时查看输入和输出，以更好地了解数据分布：其模式、边缘情况以及模型的局限性。

检查开发 —— 生产偏差

传统机器学习流程中常见的错误来源是训练-服务偏差，当训练中使用的数据与模型在生产中遇到的数据不同时，就会发生这种情况。尽管我们可以在没有训练或微调的情况下使用LLMs，因此没有训练集，但开发-生产数据偏差也会出现类似问题。基本上，在开发过程中测试系统的数据应该反映系统在生产中将面对的情况。如果不是这样，我们可能会发现生产准确性受到影响。

LLM开发-生产偏差可以分为两种类型：结构性偏差和基于内容

• 结构性偏差：包括格式不一致等问题，例如 JSON 字典与列表类型值之间的差异，大小写不一致，拼写错误或句子片段等。这些错误可能导致模型性能不稳定，因为不同的LLMs是根据特定数据格式进行训练的，提示可能对细微变化非常敏感。
• 基于内容：或称为“语义”偏差指的是数据的含义或上下文的差异。

与传统的机器学习一样，定期测量LLM输入/输出对之间的偏差是很有用的。像输入和输出的长度或特定格式要求（例如，JSON 或 XML）这样的简单指标是跟踪变化的直接方式。对于更“高级”的漂移检测，考虑对输入/输出对的嵌入进行聚类，以检测语义漂移，比如用户讨论主题的变化，这可能表明他们正在探索模型之前未曝光的领域。

在测试更改时，例如Prompt工程，确保保留数据集是最新的，并反映最近类型的用户交互。例如:如果在生产输入中常见拼写错误，则保留数据中也应存在这些错误。除了仅仅进行数值偏差测量之外，对输出进行定性评估也是有益的。定期审查模型的输出 —— 一种俗称为“氛围检查”的做法是确保结果符合预期并与用户需求保持相关。最后，将不确定性纳入偏差检查也是有用的，通过为我们的测试数据集中的每个输入多次运行管道并分析所有输出，我们增加了捕捉偶尔发生的异常的可能性。

每天查看LLM个输入和输出的样本

LLMs是动态的且不断发展的，尽管它们具有令人印象深刻的零射击能力和常常令人愉悦的输出，但它们的失败模式可能非常难以预测。对于定制任务，定期审查数据样本对于发展对 LLMs 执行情况的直观理解至关重要。

生产中的输入输出对是LLM应用的“真实事物、真实地点”无法替代。最近的研究强调，开发人员对于什么构成“好”和“坏”输出的看法会随着与更多数据的互动而发生变化（即：标准漂移）。虽然开发人员可以事先制定一些用于评估LLM输出的标准，但这些预定义的标准通常是不完整的。例如：在开发过程中，我们可能会更新提示，以增加良好响应的概率并降低不良响应的概率。

评估、重新评估和标准更新的迭代过程是必要的，因为很难在没有直接观察输出的情况下预测LLM行为或人类偏好。为了有效地管理这一点，我们应该记录LLM个输入和输出，通过每天检查这些日志的样本，可以快速识别和适应新的模式或故障模式。当我们发现一个新问题时，可以立即围绕它编写一个断言或评估，同时对故障模式定义的任何更新都应反映在评估标准中。这些“氛围检查”是坏输出的信号，代码和断言将它们标准化操作。最后，这种工作方式必须全员操作，例如通过将输入和输出的审查或注释添加到团队值班轮换中。

工作中的模型

基于LLM的API可以依赖少数供应商的能力，虽然这是一个福音，但这些依赖也涉及性能、延迟、吞吐量和成本方面的权衡。随着更好的迭代模型发布，我们应该准备更新产品，需要淘汰旧模型并迁移到新模型。这里我们分享了无法完全控制技术合作的经验教训，其中模型无法自行托管和管理。

生成结构化输出以便于下游集成

对于大多数实际应用场景，LLM的输出将通过某种机器可读格式被下游应用程序使用，例如：房地产 CRM-ReChat需要结构化响应以便前端呈现小部件，用于生成产品战略想法的工具 Boba 需要具有标题、摘要、可信度评分和时间范围字段的结构化输出。LinkedIn 分享了关于限制 LLM 生成 YAML 的信息，然后用于决定使用哪种技能，以及提供调用技能所需的参数。

这种应用模式是 Postel 法则的极端版本：在接受内容时要宽容（任意自然语言），在发送内容时要保守（类型化、机器可读对象）。因此，我们期望它具有极高的耐久性。

目前，Instructor 和 Outlines 是从 LLMs 中获取结构化输出的事实标准。如果你正在使用 LLM API（例如：Anthropic、OpenAI），请使用 Instructor。如果你正在使用自托管模型（例如：Hugging Face），请使用 Outlines。

迁移Prompt跨模型是一件让人头疼的事情

我们有时候精心设计的Prompt在一个模型上效果非常好，但在另一个模型上却不起作用。当在不同的模型提供商之间切换时，或者在升级到同一模型的不同版本时，这种情况可能会发生。 例如：Voiceflow 发现从 gpt-3.5-turbo-03