经过数月紧张的评测、红队测试以及对你LLM应用程序数百条提示的反复迭代，发布日终于到来。然而，随着最后倒计时的滴答声，那些熟悉的疑虑依然挥之不去：你真的考虑周全了吗？会有人发现漏洞吗？你的模型真的准备好面对现实世界了吗？不，说真的，它真的准备好了吗？
事实是，无论准备多么充分，都无法测试部署后可能出现的每一个潜在问题。但好消息是——你并不孤单。借助正确的LLM监控、监督和可观测性工具，你可以有效管理和降低这些风险，确保前路更加顺畅，这也引出了LLM可观测性。
阅读完本文后，你将掌握所有必要的知识，为你的LLM应用赋予可观测性能力。让我们开始吧。
什么是LLM可观测性？
LLM可观测性为团队提供强大的洞察力，确保LLMs保持在正轨上，准确执行、与业务目标保持一致并有效服务用户。借助合适的可观测性工具，你可以实时监控LLM行为，在生产环境中进行不同LLMs的 A/B 测试，轻松检测性能变化，并在问题影响业务或用户体验之前主动解决。这是一种主动管理LLM应用的方法，让你能更快地排查问题、保持LLM可靠性，并自信地扩展由 GenAI 驱动的计划。
虽然LLM监控指的是实时追踪和评测你LLM应用的各个方面，如用户输入、模型响应、延迟和成本，但LLM可观测性则通过提供系统所有动态部分的完整可见性，使工程师能够调试问题并高效安全地运行应用，从而提供更深入的洞察。这种对LLM流水线所有组件拥有完全可见性的概念，通常由LLM追踪技术实现。
简而言之，以下是你需要了解的三个关键术语：
- LLM监控：这涉及持续追踪LLMs在生产环境中的表现。监控通常关注响应时间、错误率和使用模式等关键指标，以确保LLM按预期运行，并识别需要关注的性能下降或服务问题。
- LLM可观测性：这超越了监控，提供了关于LLM为何及如何以特定方式运行的深入洞察。可观测性工具收集并关联日志、实时评测指标和追踪数据，以实时理解意外输出或错误的上下文。
- LLM 追踪：追踪技术捕捉请求与响应在LLM管道中的流动过程，提供从输入到输出的事件时间线。这一细致视角使开发者能够追踪特定输入、中间处理阶段及最终输出，从而更易于诊断问题、优化性能，并将错误溯源至根本原因。
我将在后续章节中逐一展示示例，但首先我们要探讨为何LLM可观测性对于将LLM应用投入生产环境至关重要。
为什么LLM可观测性是必要的？
LLM 可观测性有助于解决许多关键问题。以下是其中几个问题，以及选择正确的可观测性工具为何如此重要。
LLM 应用需要实验
没有人第一次就能做对，这就是为什么即使你已经部署到生产环境，也会想要进行 A/B 测试不同的LLMs，看看哪个最适合你的用例，使用不同的提示模板，甚至使用完全不同的知识库作为额外上下文，观察响应如何变化。因此，你肯定需要一种方法来轻松“重放”或重现生成响应的场景。
LLM 应用难以调试
你可能听说过根因分析，但不幸的是，这对LLM应用来说极其困难。LLM应用由各种动态组件构成——检索器、API、嵌入器、链、模型等等——随着这些系统功能日益强大，其复杂性只会不断增加。监控这些组件是理解一系列问题的关键：是什么拖慢了你的应用，什么可能导致幻觉现象，以及哪些部分可能是多余的。面对如此多可能出错的地方，获取这些领域的可见性对于保持系统高效、有效且无缺陷至关重要。
解锁LLM生成回复的无限可能
你可以花费数月时间精心策划最全面的评测数据集，以彻底测试你的LLM应用，但现实是：真实用户总会以意想不到的方式给你惊喜。可能的查询范围无穷无尽，完全自信地覆盖一切是不可能的。LLM可观测性让你能自动检测这些不可预测的查询，并解决它们可能引发的任何问题。
警惕LLMs 性能漂移现象
LLM 应用本质上是非确定性的，这意味着相同的输入不总会产生相同的输出。它们不仅多变，而且最先进的模型也在不断进化，尤其是在与 OpenAI 或 Anthropic 等第三方提供商合作时。这可能导致即使在部署后也会出现不希望出现的幻觉和意外响应。虽然在开发过程中测试LLMs很重要，但这远远不够——只要LLMs仍不可预测且持续改进，持续监控就至关重要。
LLMs 倾向于产生幻觉
在LLM应用中，当系统生成错误或误导性信息时，尤其是面对无法准确处理的查询时，会出现幻觉现象。这些模型非但不表明知识空白，反而经常生成听起来自信但根本错误的答案。这种倾向引发了关于传播虚假信息风险的担忧，在需要高事实准确性的LLMs应用中尤为关键。
你需要什么样的LLM可观测性解决方案？
任何LLM可观测性工具必须具备五个不可妥协的特性。LLM可观测性的五大核心支柱是：
- 响应监控 — 实时跟踪用户查询、LLM 响应及成本和延迟等关键指标。
- 自动化评测 — 自动评测受监控的LLM响应。
- 高级筛选 — 筛选失败或不理想的响应，将其标记以供进一步检查。
- 应用追踪 — 追踪LLM应用各组件间的连接，以识别错误和性能瓶颈。
- 人工介入机制（Human-in-the-Loop）——为标记输出提供人工反馈及预期响应。
依托这五大支柱，LLM可观测性工具能帮助任何利益相关者理解应用性能表现并识别需改进之处——无论你是软件工程师、数据科学家、人工审核员、领域专家，甚至是 CEO。
LLM 可观测性概述
响应监控
响应监控是LLM可观测性的基石。它涉及追踪与每次用户交互相关的关键属性和指标，可分为五大主要领域：
- 追踪用户输入-LLM响应配对：这些是最关键的追踪参数，不仅用于评测，还代表了用户所见内容，将成为领域专家和评审者的主要关注点。在 RAG 应用中，这包括检索上下文。
- 跟踪关键指标：跟踪完成时间（延迟）、令牌使用量和成本等指标有助于确保系统保持高效。
- 追踪用户 ID 与对话 ID：将响应与用户及对话 ID 关联，便于手动检查单个用户交互和对话线程。
- 追踪超参数：记录模型、提示模板和温度等超参数，可比较不同版本模型的性能表现。
- 追踪自定义数据：根据需要监控额外数据的能力，对于满足特定用例需求同样至关重要。
一个LLM可观测性解决方案应该监控什么
最终，追踪用户输入-LLM响应对和关键指标构成了有效响应监控的基础。监控用户和会话 ID 使审核者能够检查特定的交互，而跟踪超参数和自定义数据则提供了关于你的调整是否产生积极影响的洞察。
高级过滤
高级筛选功能对于高效识别和分析LLM响应至关重要。虽然筛选失败评测对优先处理需要进一步检查的响应非常关键，但还有其他筛选选项可以极大增强你的分析能力。以以下 RAG 聊天机器人示例为例，你能够重现由"gpt-4-turbo-preview"模型生成LLM响应的场景，该模型温度为 0.7，针对特定会话 ID，且检索上下文来自"Development DB"数据库：
Confident AI 上的过滤机制如何运作
这一点极为重要，因为它能让你深入了解不同生产设置下生成响应的质量，非常适合进行 A/B 测试和捕捉回归问题。具体深入探讨如下：
- 按用户 ID 或会话线程筛选：通过筛选特定用户或会话线程的互动，你可以评测模型对该用户多次响应的表现。这对于识别恶意行为、问题互动及会话或特定主题内重复出现的故障尤为有用。
- 按超参数筛选：如果你正在管理LLM应用的多个版本，通过这些设置（如模型、提示模板）进行筛选，使你能够比较不同配置下的响应。这有助于评测哪些调整有效，哪些可能需要进一步优化。
- 按自定义数据筛选：这与超参数类似，但由于并非所有内容都是超参数（例如你的LLM应用程序正在使用哪个知识库），额外的信息可以放在这里。
- 按人工反馈筛选：有时，单次审查并不足够——你可能希望对失败的指标获取第二意见，或者作为利益相关者，你可能想评测人工审查的质量。在这些情况下，按人工评分、反馈及预期输出进行筛选非常有价值，能够提供更深入的洞察和质量控制。
- 按失败指标筛选：如前所述，此筛选功能让你专注于那些未达到基于评测指标性能要求的响应，为人工审核提供了切入点。
能够从数千甚至数百万条响应中进行筛选的功能极其强大。它使你能集中关注最重要的响应——那些引发问题的响应——并利用这些洞察推动进一步开发。
自动化评测
虽然跟踪每个用户输入和LLM响应配对至关重要，但让人工评测员或领域专家检查并提供对每一个响应的反馈是不现实的。实际上，平均每次聊天机器人对话包含约 10 条消息。按每天 2000 名活跃用户计算，这意味着每天需要监控 20,000 条响应！
自动化评测的作用就在于此。它们能迅速识别出失败的响应，让人工审核员专注于真正需要关注的部分，从而节省时间和精力。
生产环境 vs 开发环境 LLM 评测
在开发过程中，评测测试用例可以包含可选的人工预填充参数，如预期输出和预期检索上下文，从而支持依赖于这些已知参考的指标，例如答案正确性。
然而，在后处理阶段，评测是在没有预期输出和预期检索上下文的情况下实时进行的，这意味着像答案正确性这样依赖参考的指标在实时环境中不可行。尽管如此，RAG 指标如答案相关性、上下文精确度、上下文召回率、上下文相关性及忠实度并不严格依赖真实参考，对于实时评测仍然极具价值。此外，像 G-Eval 这样可自定义的指标允许定义自定义评测标准，对于超越 RAG 的自动化评测至关重要。
当你使用 Confident AI 作为LLM可观测性解决方案时，你将获得最先进的LLM评测功能，以准确标记失败的LLM响应。无论如何，拥有一个高级过滤工具来捕获这些标记的响应至关重要，我们将在下一节讨论这一点。
LLM 应用追踪
应用追踪对于LLM可观测性至关重要，它使你能够跟踪输入在系统各组件中的流转过程，类似于 Python 调试中的追踪功能。这种可见性让你能够观察到输入如何被转化为输出，从而清晰地展示从初始请求到最终LLM生成的每一步。
端到端 LLM 追踪是什么样子的
LLM 应用程序依赖于多个组件，如嵌入模型和检索器。追踪对于揭示这些组件是否拖慢LLM或影响其准确性至关重要。它能确保检索器等功能正常运行，并帮助识别性能瓶颈或准确性问题。追踪还允许你测试不同模型，比如切换到更具成本效益的重新排序器，以观察任何性能影响。检查失败测试案例的追踪记录对于诊断其失败原因极为关键。
如果你需要一些术语，上图所示的每个小药丸被称为一个“span”（代表诸如嵌入器、检索器等独立组件），多个 span 则构成一个 trace（追踪）。最终，追踪技术为系统组件间的交互提供了关键的可视性，有助于故障排查、性能优化及理解它们对LLM性能和准确性的影响。缺乏这一机制，你将无法洞察系统的核心动态。
人工介入机制
我们已在自动化评测与筛选的背景下深入探讨了人类反馈。首先，让我们明确人类反馈的类型。人类反馈主要分为两种形式：
- 用户提供的反馈：这类反馈来源于用户与你的LLM应用程序的互动。虽然这类反馈因成本较低而数量庞大，但可能包含噪音，如无关或主观的意见。采用简单的机制，如点赞或点踩评分，有助于过滤这些噪音，使用户能高效地提供直接反馈。
- 审核提供的反馈：另一方面，来源于领域专家、工程师或参与应用程序开发和管理的人员。这类反馈更具针对性和洞察力，专注于具体问题，如未达标的评测指标或有问题的用户或会话 ID。然而，审阅者提供的反馈也更为昂贵且耗时。
生产环境中LLM响应的人工介入
人类反馈的主要目标是准确识别失败的测试用例，以便将其纳入未来的评测数据集。虽然自动化评测提供了有用的筛选机制，但人类反馈仍是精确度的黄金标准。
这最后一步有助于精确定位你的LLM中哪些方面需要改进，无论是通过提示调整还是模型微调。为了更清晰地诊断改进领域，请重新查看追踪部分以识别导致问题的具体组件。
如何设置LLM可观测性？
信不信由你，设置可观测性极其简单，特别是当你使用 Confident AI 时。只需每个响应调用 1 次 API，它就会在后台异步运行，不会增加延迟。示例如下：
import deepeval
# At the end of your LLM call,
# usually in your backend API handler
# A RAG LLM Observability example
deepeval.monitor(
event_name="CS Chatbot",
model="gpt-4",
input="What are your return policies",
response="Our return policy is...",
retrieval_context=["A list of retrieved text chunks for RAG"],
conversation_id="your-conversation-id",
hyperparameters={"temperature": 1},
additional_data={"Knowledge Base": "Production File Sources"}
...
)
在此示例中，我们通过一次 API 调用记录所有内容，包括你可能设置的任何自定义超参数及附加数据。本例中，我们记录了生成响应时使用的温度为 1，且知识库为"Production File Sources"。坦白说，我不确定人们是否真的会为知识库命名，但关键在于只需几行简单代码，你就能在 Confident AI 上搜索并筛选这些信息，重现生成这些响应的场景和上下文。这对于 A/B 测试不同配置而言堪称完美。
结论
今天，我们探讨了LLM可观测性的核心要素，聚焦于五大支柱：响应监控、自动化评测、高级筛选、追踪及人工反馈。我们深入剖析了这些支柱如何相互关联——从监控响应到识别并诊断失败的测试用例，再到将其加入评测数据集以实现LLM持续改进。
Confident AI 将整个流程简化为几行代码，并提供了一套全面的工具，用于端到端的LLM监控和可观测性。它还允许你将失败的测试用例添加到数据集中，并提供单元测试功能以增强模型开发。这种全方位的方法确保你对LLM应用程序拥有完全的可见性，现在即可免费试用。
