19-6 LLM之野望 6 - LLM 监控和可观察性

似乎一夜之间，每一份 CEO 待办事项清单、招聘启事和简历都包含了生成式人工智能 (genAI)。这是理所当然的。基于基础模型的应用程序已经改变了数百万人的工作、学习、写作、设计、编码、旅行和购物方式。包括我在内的大多数人都觉得这只是冰山一角。

在本文中，我总结了对现有大型语言模型 (LLM) 监控方法的研究。我花了很多时间阅读文档、观看视频，以及阅读专门从事 LLM 监控和可观察性的软件供应商和开源库的博客。结果是一个用于监控和观察 LLM 的实用分类法。希望您觉得它有用。在不久的将来，我计划对学术论文进行文献检索，以增加前瞻性的视角。

研究的软件*：Aporia、Arize、Arthur、Censius、Databricks/MLFlow、Datadog、DeepChecks、Evidently、Fiddler、Galileo、Giskard、Honeycomb、Hugging Face、LangSmith、New Relic、OpenAI、Parea、Trubrics、Truera、Weights & Biases、Why Labs

• *本文介绍了一种累积分类法，没有对软件选项进行分级或比较。

文章提纲

• 评估大语言模型 (LLM) — 如何评估大语言模型 (LLM) 并判定其是否已准备好投入生产？
• 跟踪 LLM — 跟踪 LLM 意味着什么以及需要包括哪些部分？
• 监控 LLM — LLM 投入生产后如何进行监控？

LLM 生命周期

将 LLM 纳入生产工作流程的竞赛已经拉开帷幕，但技术社区正在争相开发最佳实践，以确保这些强大的模型能够随着时间的推移按预期运行。

评估大语言模型

评估传统机器学习 (ML) 模型涉及检查其输出或预测的准确性。这通常通过众所周知的指标来衡量，例如准确度、RMSE、AUC、精确度、召回率等。评估 LLM 要复杂得多。如今，数据科学家使用了几种方法。

（1）分类和回归指标

LLM 可以生成数字预测或分类标签，在这种情况下评估很容易。这与传统的 ML 模型相同。虽然这在某些情况下很有用，但我们通常关注的是评估生成文本的 LLM。

（2）基于文本的独立指标

当您没有基本事实来源时，这些指标对于评估 LLM 的文本输出非常有用。您可以根据过去的经验、学术建议或比较其他模型的分数来确定什么是可接受的。

困惑度就是一个例子。它衡量模型生成输入文本序列的可能性，可以被认为是评估模型学习所训练文本的能力。其他示例包括阅读水平和非字母字符。

一种更复杂的独立方法涉及从模型输出中提取嵌入并分析这些嵌入是否存在不寻常的模式。这可以通过在 3D 图中检查嵌入的图形来手动完成。通过按性别、预测类别或困惑度分数等关键字段进行着色或比较可以揭示 LLM 应用程序中的潜在问题，并提供偏差和可解释性的衡量标准。有几种软件工具可让您以这种方式可视化嵌入。它们对嵌入进行聚类并将它们映射到 3 个维度中。这通常使用HDBSCAN 和 UMAP完成，但有些利用基于 K 均值的方法。

除了视觉评估之外，还可以运行异常检测算法来寻找异常值。

（3）评估数据集

具有基本事实标签的数据集可以将文本输出与批准响应的基线进行比较。

一个众所周知的例子是ROUGE指标。在语言翻译任务中，ROUGE 依赖于参考数据集，该数据集的答案与正在评估的 LLM 进行比较。可以根据参考数据集计算相关性、准确性和许多其他指标。嵌入起着关键作用。标准距离指标（如 JS Distance、Hellinger Distance、KS Distance 和 PSI）将您的 LLM 输出嵌入与基本事实嵌入进行比较。

最后，大语言模型 (LLM) 有许多被广泛接受的基准测试。斯坦福的HELM 页面是了解这些测试的好地方。

（4）评估大语言模型

乍一看，你可能会认为用 LLM 来评估 LLM 是在欺骗系统，但许多人认为这是最好的前进道路，研究也表明了前景。在不久的将来，使用我所说的 Evaluator LLM 很有可能成为 LLM 评估的主要方法。

一个被广泛接受的例子是毒性指标。它依赖于评估器 LLM（Hugging Face 推荐roberta-hate-speech-dynabench-r4）来确定您的模型的输出是否有毒。评估数据集下上述所有指标都适用于此处，因为我们将评估器 LLM 的输出视为参考。

Arize 的研究人员表示，Evaluator LLM 应配置为为其测试的指标提供二元分类标签。他们解释说，数字分数和排名需要做更多工作，而且性能不如二元标记。

（5）人工反馈

虽然这篇文章、软件文档和营销材料都强调了可衡量的指标，但您不应忘记手动的人工反馈。数据科学家和工程师通常在构建 LLM 应用程序的早期阶段考虑这一点。LLM 可观察性软件通常有一个界面来帮助完成这项任务。除了早期的开发反馈外，在最终评估过程中（以及持续监控）也包括人工反馈是一种最佳实践。抓取 50 到 100 个输入提示并手动分析输出可以让您了解很多有关最终产品的信息。

追踪大语言模型

跟踪是监控的先决条件。在我的研究中，我发现跟踪 LLM 的细节中存在足够多的细微差别，值得单独列出一个部分。跟踪的简单成果包括捕获请求数量、响应时间、令牌使用情况、成本和错误率。标准系统监控工具在这里与 LLM 特定选项一起发挥作用（那些传统监控公司的营销团队很快就根据简单的功能指标跟踪声称拥有 LLM 可观察性和监控功能）。

通过捕获输入提示和输出响应以供将来分析，可以获得深刻的见解。这听起来很简单，但事实并非如此。复杂性来自我迄今为止忽略的东西（大多数数据科学家在谈论或撰写 LLM 时也会这样做）。我们不是在评估、跟踪和监控 LLM。我们正在处理一个应用程序；一个或多个 LLM、预设指令提示和代理的集合，它们共同产生输出。一些 LLM 应用程序并不复杂，但很多都是，而且趋势是更加复杂。即使在稍微复杂的 LLM 应用程序中，也很难确定最终的提示调用。如果我们正在调试，我们需要知道沿途每一步的调用状态以及这些步骤的顺序。从业者将希望利用有助于解开这些复杂性的软件。

监控大语言模型

虽然大多数 LLM 和 LLM 申请至少会接受某种形式的评估，但实施持续监控的却很少。我们将分解监控的组成部分，以帮助您构建一个保护用户和品牌的监控程序。

（1）功能监测

首先，应该持续监控上面跟踪部分中提到的容易实现的目标。这包括请求数量、响应时间、令牌使用情况、成本和错误率。

（2）监控提示

您的下一个任务应该是监控用户提供的提示或输入。可读性等独立指标可能会提供有用信息。应使用评估器 LLM 检查毒性等。嵌入距离参考提示是明智的指标。即使您的应用程序可以处理与您预期有很大不同的提示，您也需要知道客户与您的应用程序的交互是新的还是会随着时间的推移而发生变化。

此时，我们需要引入一个新的评估类别：对抗性尝试或恶意提示注入。这在初始评估中并不总是被考虑到。与已知对抗性提示的参考集进行比较可以标记出不良行为者。评估器 LLM 还可以将提示分类为恶意或非恶意。

（3）监测响应

在将你的 LLM 申请材料与你的预期进行比较时，你可以进行各种有用的检查。考虑相关性。你的 LLM 申请材料是否提供了相关内容，还是内容不着边际（幻觉）？你是否看到了与预期主题的差异？情绪如何？你的 LLM 申请材料是否以正确的语气回复，并且这种情况会随着时间的推移而改变吗？

您可能不需要每天监控所有这些指标。对于某些人来说，每月或每季度就足够了。另一方面，毒性和有害输出始终是部署 LLM 时最令人担忧的问题。这些是您希望更定期跟踪的指标示例。请记住，前面讨论的嵌入可视化技术可能有助于根本原因分析。

提示泄漏是我们尚未引入的一种对抗方法。当有人欺骗您的应用程序泄露您存储的提示时，就会发生提示泄漏。您可能花了很多时间来确定哪些预设的提示指令产生了最佳结果。这是敏感的 IP。可以通过监控响应并将其与您的提示指令数据库进行比较来发现提示泄漏。嵌入距离指标效果很好。

如果您有评估或参考数据集，您可能需要定期根据这些数据集测试您的 LLM 申请，并比较以前测试的结果。这可以让您随着时间的推移了解准确性，并可以提醒您注意偏差。如果您发现问题，一些管理嵌入的工具允许您导出表现不佳的输出数据集，以便您可以针对这些麻烦的提示微调您的 LLM。

（4）警报和阈值

应注意确保您的阈值和警报不会引起太多误报。多变量漂移检测和警报可以提供帮助。我对如何做到这一点有一些想法，但会把它们留到另一篇文章中。顺便说一句，在我为本文所做的任何研究中，我都没有看到任何关于误报率或阈值最佳实践的提及。真遗憾。

您可能希望将一些与警报相关的出色功能列入必备清单。许多监控系统提供与 Slack 和 Pager Duty 等信息源的集成。如果输入提示触发警报，某些监控系统允许自动阻止响应。在将响应发送给用户之前，相同的功能可用于筛选 PII 泄漏、毒性和其他质量指标。

我在这里再补充一点观察，因为我不知道该把它放在哪里。自定义指标对于您的监控方案非常重要。您的 LLM 应用程序可能是独一无二的，或者您团队中一位敏锐的数据科学家想到了一种可以为您的方法增加重要价值的指标。这个领域可能会取得进展。您将需要自定义指标的灵活性。

（5）监控界面

如果系统具有监控功能，它将具有显示指标时间序列图的 UI。这是相当标准的。当 UI 允许以指向某种程度的根本原因分析的方式深入研究警报趋势时，它们开始有所区别。其他 UI 则基于集群和投影促进嵌入空间的可视化（我希望看到或开展一项关于这些嵌入可视化在野外的实用性的研究）。

更成熟的产品将按用户、项目和团队对监控进行分组。它们将具有 RBAC，并假设所有用户都是需要知道的。工具中的任何人都可以看到所有人的数据，而这在当今的许多组织中是行不通的。

我强调的警报容易产生不可接受的误报率这一问题的一个原因是，用户界面不利于对警报进行适当的分析。软件系统很少尝试在这方面进行任何形式的优化，但有些系统会这样做。同样，关于这个话题，后面还会有更多内容要讲。

对从业者和领导者的最后思考

领导者们，如果不将 LLM 监控和可观察性放在组织计划的首位，那么风险太大了。我这样说不仅仅是为了防止对用户造成伤害或失去品牌声誉。这些显然都在你的考虑范围内。你可能没有意识到的是，你的公司快速而可持续地采用人工智能可能意味着成功与失败之间的区别，而一个成熟、负责任的人工智能框架以及用于监控和观察 LLM 应用程序的详细技术路线图将为你提供基础，使你能够比竞争对手更快、更好、更安全地扩展。

从业者，本文介绍的概念提供了 LLM 可观察性和监控实施中应包含的工具、技术和指标列表。您可以将其用作指南，以确保您的监控系统能够胜任这项任务。您可以将其用作深入研究我们讨论的每个概念的基础。

这是一个令人兴奋的新领域。精通该领域的领导者和从业者将有能力帮助他们的团队和公司在人工智能时代取得成功。