好的，让我们开始吧。欢迎大家参加我们关于使用 Langfuse 评估 AI 应用的研讨会。我叫 Annabelle，是 Langfuse 的 AI 解决方案工程师。今天我的同事 Donelli 也加入了我们，他负责 Langfuse 的 AI 解决方案架构工作。他与我们的最大客户合作，确保他们能够向生产环境部署可靠的智能体（Agents）。

我自己以前——我喜欢这么称呼它，因为感觉像是上辈子的事了——在一家公司从事医疗设备的合规性 AI 智能体开发工作。在这个行业中，确保运行稳定至关重要。我们要确保拥有由客户验证的地面真值数据集（ground truth dataset），并且运行了大量的人机回环系统。我花了很多时间在 Langfuse 上，后来我决定换个角色，帮助其他团队——特别是受监管行业的团队——部署智能体。大约七个月前我加入了 Langfuse 团队。

但在深入主题之前，我们想先了解一下在座的各位以及我们的共同背景。我们在思考：在座有多少人曾经将 AI 智能体部署到生产环境中？我指的是作为团队一员参与其中，而不仅仅是公司里有人做过。也就是说，你实际参与了将其推向生产的过程。好的，太棒了，看来有很多人参与过。我们还想知道有多少人之前使用过 Langfuse？相当多的人用过。还有其他可观测性或评估工具的使用经验吗？

是的，也有一些人使用过其他工具，这很好。最后，有多少人解决过 AI 应用的评估问题？如果是那些很有信心的人，我很希望你们能来到我们的展位向我们解释一下。因为实际上这相当困难。我想在座各位，无论是从事 AI 工作还是只是与 ChatGPT 或 Claude 聊天时都体验过，这确实很棘手。因为 AI 智能体可能会失败，而系统指标本身却显示正常（绿色）。

例如看这个例子：我们有一个用户支持智能体，用户询问“我能退款吗？”智能体接收请求，查询一些政策，然后回答说：“当然，我已经为您办理了退款。”用户说“谢谢”，但需要几天时间用户才能看到结果是否真的生效，此时状态显示为绿色。从传统可观测性的角度来看，没有任何错误发生，也没有延迟问题。

但如果我们深入挖掘实际发生了什么，会发现智能体从未真正办理退款。工具调用未被执行，也没有被运行。智能体对用户撒谎说它已经处理了。我们要几周后用户回来抱怨“嘿，顺便说一下，我从未收到退款”时才会知道这一点。这就是非确定性系统的问题所在：它们可能声称做了某事，但实际上并没有做。

因此，你需要找到一种方法，持续挖掘那些出错的信号，确保它们不再发生，或者最好从一开始就避免。这也是我们的创始人在三年前的 Y Combinator 训练营中遇到的问题。他们意识到，当时没有针对 AI 应用的单元测试这样的东西，我们需要一个解决方案。于是他们构建了 Langfuse——这是一个开源平台，用于持续追踪、监控和改进你的 AI 系统。

虽然我们要最初主要作为开发者工具起步，但现在我们的目标群体也包括领域专家。我们与 AI 工程师合作，确保系统确实按照预期运行。此外，在过去大约 8 到 12 个月里，我们还迎来了一组新的用户群体：编码智能体（coding agents）。它们帮助我们的工程师处理 AI 应用并对其进行改进。

如今，Langfuse 已被全球超过 150,000 名开发人员采用，这在很大程度上得益于我们的开源设置。当然，财富 50 强中有 21 家公司将我们纳入其核心技术栈以部署 AI 应用。每个月，有超过 900 亿次观测数据被摄入 Langfuse 实例中。随着智能体采取更多步骤并承担越来越多任务，这一趋势仍在增长。

Ramp、Canva、可汗学院和 Supabase 等公司与我们合作。在过去三年中，我们与这些公司花费了大量时间。我们意识到一个事实：那些成功部署可靠智能体并持续改进它们的公司，都遵循某种形式的“AI 工程闭环”。这是一套帮助你通过系统化方法持续改进系统的实践。

其基础始终是追踪（Tracing）。追踪旨在将你智能体执行的每一步都记录在一个相对紧凑的日志中，理想情况下还要以人类可检查的方式呈现。监控（Monitoring）旨在发现有趣的现象：什么出错了？什么成功了？我们应该深入调查哪里？同时也了解系统的平均表现。

构建数据集（Building datasets）旨在找到一组具有代表性的示例，这些是你希望应用能够处理的内容以及你希望它如何处理的方式。然后你要在上面运行实验：尝试系统的不同变体，以检查其表现和进展如何。当然，你还需要评估结果。这不是一次性的工作，而是持续闭合这个循环：改进这些 AI 智能体，从生产环境中学习，并将反馈带回数据集中。

让我们更深入地了解每一步的细节。对于追踪（Traces），最重要的目标是让你深入了解智能体实际在做什么。屏幕右侧显示的是 Langfuse 的截图，这是一个 IT 支持智能体的追踪记录——一个回答你父母问题从而让你不用操心的智能体。我们可以看到根追踪（root trace），以及该步骤的聚合时间和成本。

但我们还能看到智能体执行的每个单独步骤的详细分解。这包括生成部分（即 OpenAI 聊天接口调用）以及工具调用，我们可以看到它们前面带有小图标。因此，我们可以详细查看正在发生的事情。如果屏幕更宽一些，我们还能看到输入、输出以及所有涉及的元数据。这是追踪成本、延迟、令牌使用情况的基础，也是供人类检查的日志，以便真正深入挖掘发生了什么。

让智能体与之协作，并在大规模下审视它，从而拥有一个可检查的锁来了解实际发生的情况。监控则是在规模上理解这些数据，因为随着自动化水平的不断提高、追踪记录变长以及用例增多，人类手动完全查看这些日志已不再可行。但你确实需要一种方式来获取关于实际运行情况的聚合指标，并检测出事物出错时的信号。例如成本延迟等指标，或者质量信号如合规护栏是否保持有效，以及有多少用户对我们的系统感到沮丧。有多少人因为对智能体刚才的行为不满而使用全大写消息发送信息，当然还有所有这些聚合数据以及找到你想深入挖掘的有趣内容。

通过这种监控从生产环境中获得的信息，也是构建数据集的基础之一。数据集最终代表了你的智能体在生产环境中需要处理的内容。因此包括那些可能超出范围、希望你正确推迟处理的请求，确保智能体不会试图提供投资建议，或者在它是一个死掉的 IT 支持代理时回答纽约的天气情况。对于这些项目，你可以拥有输入以及你期望的输出，这可以是一个示例回复、你想要的预期行为或需要覆盖的关键词。

这些数据集可以作为稳定的基准，用于离线改进和迭代，也可以作为 CI/CD 的一部分。那些数据集随后被用来运行实验。如果你回顾一下大学里的统计学或任何你可能做过的事情，最终这就是改变你设置中的某些内容并观察发生什么的思路。例如更改提示词、模型、上下文或工具描述，看看它是否能更好地处理你真正想要处理的问题，并理想地隔离关注点。

因此如果你想检查同一模型是否在不同提示词下表现更好，你理想情况下只更改提示词而不是其他五件事，否则很难解释你实际看到的内容。最后你需要评估或评价方法以确保你能衡量这些实验中发生的事情，因为你不想自己查看所有内容——虽然你可能偶尔应该这样做。但你仍然需要可扩展的方法，例如“LLM 作为裁判”，即使用另一个 LLM 来检查该 LLM 做了什么，或者基于代码的评估用于分类任务等可以检查精确匹配的情况。

或者检查行为可以是确定性检查，如果你正在检查全大写类型的事情等。这就是 AI 工程闭环。我们观察到许多客户的情况是，根据你的用例，有几个不同的进入点。例如如果你处于低风险环境且仅构建内部聊天代理，你可能最初根本没有可观测性工具，然后你也许从追踪开始并添加一些监控器来检查人们在哪里感到沮丧，但你最初并不太关心评估部分。

你只是随着时间推移构建它并像添加测试用例那样逐步推进，但你可以直接进入生产环境。然而如果你正在构建面向客户的情况特别是如果是在受监管的环境中构建，你可能不想冒险让智能体做它不应该做的事情。因此对于这些受监管的行业我们看到了一些方法的涌现，基础始终是追踪。所以你总是想知道实际发生了什么、它采取了哪些步骤、看到了什么输入和输出以及调用了哪些工具。

在此基础上受监管行业的团队发现了一些如何构建这些真实数据集的方法，然后你可以循环改进它们。你可能都听说过自动改进这一切绝对需要真实数据集的基础而你确实有几种方法可以达到这一点。例如专家策展即与公司内的领域专家合作以确保你构建真实数据集。然后是影子运行，所以你手动连续运行过程但在并行中也有智能体在运行你可以始终比较如果由智能体会如何处理？它会怎么做然后衡量准确性并构建真实数据集。

最后像我在上一家公司所做的那样运行完全的人机回环系统，并随着时间的推移将数据分割为两部分：你可以自信地自动化的部分和始终需要人工回环的部分。关于介绍就这些了，我们现在想进入一个更实际的例子。为此我也欢迎 Donelli 再次上台我们将一起研究如何将你的智能体执行追踪到 Langfuse，如何评估和改进系统以及如何持续关闭这个闭环。大家好像 Annabelle 所说我是 Don，但你可以叫我 Don 以便对每个人来说更容易些。只有当我惹麻烦时我妈妈才叫我 Don，嗯是的那很好听到了几声咯咯笑所以这是个不错的破冰方式。

这就是第一个评估它完美通过了，嗯所以现在我要展示的是我们为一个几家金融机构构建的示例我们正在与他们合作因为他们正处于这样一个过程中：他们构建了第一个原型，然后是第一演示版但随后来自领导层或团队的问题是如何评估我们正在构建的这些面向客户的智能体解决方案？在座的有多少人从事金融服务或金融行业？是的我们在纽约所以当然你们都是。除了金融服务之外还有其他行业吗比如医疗保健等受监管的行业？好的酷太棒了，我认为这会非常引起你们的共鸣。基本上我在这里有一个典型的银行助手每个人、任何人

像拥有银行服务这样的机构，你们可能都在各自的银行见过这种情况。然而，幕后发生的一切对于银行或金融机构本身至关重要，因为它们必须提供非常准确的信息，这涉及到财务责任和法律风险。对于银行来说，推出由大语言模型驱动的这些解决方案存在诸多风险，因为我们都知道这些模型本质上是非确定性的。因此，我们要确保减少不可预测性，尽可能复现结果，并找出故障模式以及代理给出我们不希望看到的结果的地方，从而加以改进。

在这个例子中，我想展示几件事。首先，我可以模拟不同类型的客户，因为银行当然既有像我这样的普通大众账户余额很少的客户，也有超高净值人群。我们可以进行不同身份的模拟，这很重要，因为我们希望知道代理是否能够遵守我们为这些特定角色设置的安全护栏。

另外请注意这里（让我放大一点），我们还启用了个人身份信息识别功能，任何被视为PII的数据在持久化到Langfuse之前都会被自动掩码。这对金融机构来说是一个非常重要的要求，他们不希望将信用卡信息、社会安全号码或客户隐私数据持久化在可观测性系统中，而是希望将其保留在记录系统或由他们拥有的系统中。

我稍后会展示几个例子来说明它是如何工作的。我们还将查看代理本身是否遵守了我们设置的某些控制措施，它的评分情况以及定义的质量门控是否得到执行。我们将测量所有这些内容。我会展示几个例子，然后带大家深入产品内部，展示如何设置这些功能以及端到端流程的样子。

假设我作为Anna进入系统，询问国际电汇费用。这是一个非常简单的问题，仅基于知识库。几秒钟后，它会返回来自我们知识库的结果。在这里，我展示了显然不会向客户公开的信息，但这只是为了演示目的。我还指出了被调用的工具、数据源以及构成该代理配置的一些细节，以便给出这个答案。

如果我说：“我的卡丢了，这是我的号码，被阻止了吗？”我直接以明文输入信用卡号。这显然不太好。因此，虽然用户无法控制用户在系统中输入的什么内容，但你要确保在仪器化构建评估时能捕获这种情况。现在我们将看到，在我的Langfuse追踪中信用卡确实被删除了：当我打开追踪时，问题中的卡号显示为“我的卡号是”，然后完全被掩码。

这是因为我有一个掩码函数，会自动将我定义的任何PII信息立即进行掩码处理，并且不会以明文形式持久化到我的系统中。为了展示典型交互的样子，我可以看到顶部用户发送的提示词，但众所周知，幕后发生了很多我们不一定向最终用户展示但对平台团队和开发人员理解代理行为、性能及输出质量至关重要的事情。

我可以看到他所采取的所有步骤的完整树状结构，包括他调用的Anthropic LLM调用、可用的工具。这里列出了被调用的工具和账户列表等输出。但更重要的是，在顶部我可以看到为此特定用例定义的所有评分指标。你可以看到它们是在系统捕获新交互或追踪时自动计算的，我可以捕捉到诸如提供给客户的信息是否符合银行信息规范等内容。

例如，如果客户询问天气，我不会提供该信息，因为它不符合规范；或者是否存在任何故障模式、我们是否阻止了某些答案返回给客户。一个例子是，有人可能会问：“我可以把储蓄存入比特币吗？”这是银行本身不应提供信息的领域，因为这具有某些后果。代理正确地处理了这一点，但同时将其标记为投资建议，这需要客户咨询顾问或其他人员，我们使用评分来实现这一功能。

如果我再次查看我的追踪记录，这就是我看到的情况：这里有输入安全护栏告诉我主要风险是投资建议。在评分中，我可以看到客户在此评分中的意图确实是投资建议。这样我可以很容易地筛选出这些特定情况。无论如何，我想展示一个简单流程。在进入如何构建数据集和评估流的端到端介绍之前，最后一个要点是我们还支持多模态功能。

假设客户不是通过聊天机器人写信而是致电客服中心，我们可以说我想处理这个呼叫，这将进行语音转文本，然后评估文本来查看是否有任何违规情况。在这里它显示客户询问阻止他的卡的情况

我确实可以在这里看到追踪记录，甚至能看到发送给客户的媒体实际链接，或者客户发出的音频或通话录音，以及转录内容和助手返回的信息。这就是关于追踪方面：我如何捕捉所有这些活动？现在，当我试图思考如何将框架建立起来以评估我的客户通过系统发送的交互时——因为正如我们所知，客户是不可预测的。我们可能会设计一个具有特定意图的系统或解决方案，但我们的客户总是会发现非常巧妙的方式以不同的方式使用系统。而且我们也不能预见每一个结果，特别是当我们将基于大语言模型（LLM）的解决方案发布到野外供客户使用时。

因此，我们开始依赖于建立评估标准，而对我们来说，其核心是构建数据集。那么什么是数据集呢？这是一个通用的例子：数据集基本上是一组问题和预期输出，用于衡量你的大语言模型或人工智能解决方案的输出质量。如果你来自软件开发背景，我喜欢这样看待这一点：这些就是你的测试用例。我认为在座任何将软件发布到生产环境中的人，都不会在不通过质量保证（QA）的情况下发布任何东西——除非你合并到主分支或生产环境，我相信大多数人都做过这件事。

但这并不是最佳实践。嗯，我知道我做过，但无所谓了。同时，这也是你拥有证据的方式：证明代理（Agent）通过了一系列衡量你想要捕捉的所有内容的步骤或要求。这里需要注意的是，预期输出并不一定是代理给出的答案。你也可以测量代理的意图；你想衡量代理应该做什么的行为。如果你想衡量行为，有多种方法可以衡量输出的质量。这就是为什么你通常会得到不同的数据集集合来测量代理集群中特定事物或特定领域的质量。

在这里你可以看到，我有一个基本上是对我的代理进行红队测试（red teaming），寻找提示注入攻击以及任何允许某人绕过我们设置的护栏以获取他们不应获得的信息的攻击。我这里的另一个则是专门针对一个用例，我想了解哪些案例已被争议且该争议尚未解决。这里的关键在于：我可以策划非常特定的数据集，不仅针对用例，还针对我对该代理的技术要求。

不幸的是（或者说幸运的是），我认为人类仍然非常重要。因此，你仍然需要领域专家参与进来与开发团队一起定义这些内容。基本上有两种主要方式可以创建你的黄金数据集（Golden Datasets）。一种是你们团队已经有一个电子表格，里面列出了所有你想在代理上测试的内容，然后直接上传即可，这非常简单。你可以来这里说：“好的，完美，我想创建一个测试数据集”，然后导入 CSV 文件即可，它会精确地显示你之前拥有的所有内容。

我想在这里提到的另一件事是：我展示给你的所有操作，也可以通过我们的命令行界面（CLI）、NCP 或 API 完全相同地执行。只是我觉得通过 UI 展示比告诉 Claude 端到端地完成要好得多。别误会我的意思，好吧？嗯，所以这就是关于那部分的内容。但我也可以在这里说我想向数据集中添加项目，例如已经作为我生产追踪一部分的项目。假设你看到我已经从我的应用程序中收集了大量活动，我可以来这里说我想将所有这些添加到数据集中，然后选择我要选定的数据集。

这样你就可以通过查看代理产生的生产追踪来“吃自己的狗粮”（dog food，即内部使用），从而构建你将使用的数据集——前提是你已经确定这些确实是未来输出或追踪应该呈现的良好示例。这里要做的一件重要事情是我总是喜欢指出的一个流程，那就是错误分析（Error Analysis）。

嗯，错误分析基本上是这个想法：我想查看我的追踪记录。安内利（Annabelle）在作为 Langfuse 用户站在另一边时，也讲得非常精彩。我们今天早些时候交谈过，她花了整整几天时间—— literally（字面意思）——查看追踪记录。那是她的本职工作：查看追踪结构、输出内容等等。这仍然是一个非常重要的过程，因为当你查看追踪时，你首先开始理解代理的行为方式：它是否采取了所有必要的步骤？它是否调用了所有需要调用的工具？以及它是否给出了你想要的输出。这非常关键，但你知道的……

那么如何简化这个过程呢？因为显然对于我这样一个人类来说，在系统投入生产后去查看成千上万条追踪记录是不可行的。所以我们通常的做法是策划一个代表性的样本，来自生产系统的追踪数据，供人类专家查看并给出反馈。这就像说：“嘿，我有所有这些活动，我只是取 10% 或 20%，我只想专注于客户谈论的那些内容——比如争议、信用卡信息，或者你想要的任何过滤器。”然后你可以为他们构建我们所谓的“标注队列”（Annotation Queue）。

在这个标注队列中，你实际上是在告诉领域专家——在这种情况下假设是我，“嘿，你是风险专家。我需要你看看代理给我们的客户提供的这个输出，并给出你的意见。”这里的关键是要让领域专家的操作非常简单，因为显然他们有本职工作。他们不能花几个小时只看这个内容。所以我通常建议给他们几个评分选项，比如“是”或“否”，

真、假，或者1到10的量表，随你怎么定义。接着他们还可以在这里提供评论。比方说这里标记为“故障模式”，我们就假设在这种情况下是缺少引用来源。然后我会添加一条评论：“此处没有引用，所有此类情况都必须包含。”对吧？你会经历这个过程并查看结果。对我来说这很简单，大概花了10秒钟。假设我有上百条这样的记录，每条耗时30秒，那就是50分钟？不，甚至不到。好吧，我今天的数学不太好。但总之你明白了吧？你可以告诉领域专家：“给我一小时时间，我来整理一堆活动供你处理。只需提供反馈和几条评论即可。”现在借助Whisper Flow之类的工具，他们甚至不需要打字，直接口述就行。对吧？让操作变得极其简单。

第二件事是标记为完成。现在这些人工标注作为证据与追踪记录绑定在一起。但我接下来要做的第二步是，利用所有这些信息——即他们提供的所有标注数据，使用大语言模型找出贯穿所有这些评论的故障模式或类别中的共同规律。注意，你并不是要求主题去发明新的分类，而是让他们提供对这些追踪记录的未经过滤的原始评论，然后利用大语言模型来归纳出类别。因为这是它们的强项：擅长模式匹配、从文本中提取信息。这样既让领域专家的操作保持简单，又充分发挥大语言模型的优势。

一旦确定了这些类别，我们就可以进入故障模式的设定环节。如果我在这里查看我的实验数据，当你运行评估时就会看到所有这些衡量指标。让我把它调出来看看。现在，在领域专家提供输入后，我根据数据语料库中基于专家意见出现的最高频类别，定义了衡量输出质量的向量或维度。我们可以称之为“分数”，虽然我喜欢用更专业的词汇来表述，但意思是一样的。

比如其中一项是“领域专家期望的来源准确性”以及“正式语体”。这意味着在某些语言中，你需要以更正式的语气称呼客户；如果客户的输入语言与系统匹配，则必须包含非 solicited 内容等。现在有了这些衡量输出质量的基础类别后，我可以决定如何对这些内容进行评分：这是什么类型的分数？使用什么样的评估器？为此，我可以在这里构建我的评估器库。

随着追踪记录进入系统，这些分数会自动为我计算；同时，我也能让客户端应用程序在实时在线发生时直接计算分数，从而将结果反馈回系统。基本上，我希望拥有一种方法，既能通过“大语言模型作为裁判”的分数或评估器来衡量智能体的输出，也能结合确定性评估器。在与这些客户合作的过程中我们学到的另一课是：根据识别出的类别类型，在“大语言模型作为裁判”和确定性评估器之间保持混合平衡越好。

因为如果100%依赖大语言模型作为裁判，由于大语言模型的固有特性，部分输出的准确性存在非零风险。但如果加入一些确定性检查——对于相同的输入无论发生什么，结果始终完全一致——你就可以对智能体的质量进行混合评分或综合评估。这是我们通常希望看到的结果。

在这里，当我尝试定义新的评估器时，我可以选择它是“大语言模型作为裁判”的评估器还是代码评估器。我可以定义所有细节，说明如何评估特定的智能体活动。如果是代码评估器，你看这只是一段代码、一个函数。非常简单，只是一个正则表达式匹配。但这会给我100%一致的输出结果（而非95%或80%）。对于相同的输入，它始终产生完全相同的结果。

因此这里的教训是：你需要混合使用两者。这就是评估方面的工作。现在，正如Annabelle所说，让我们回到AI工程闭环。我们讨论了构建数据集；也简要提及了如何操作化衡量智能体质量、运行实验的方法。让我回到这里：基本上，实验是锚定在数据集上的。这是我的测试用例，也是我要针对智能体运行的任务。

现在我会思考：如果今天这个智能体使用当前的系统提示词、模型和工具运行，如果我更换了模型会怎样？如果修改了系统提示词会怎样？或者突然赋予它访问新工具或新数据的权限又会发生什么？在将变更推广到生产环境之前，你需要能够进行这种原型测试。而不是仅仅凭感觉（running on vibes）——这基本上是我们所有人过去都在做的事：觉得“看起来还不错”，就直接推送到生产环境。

但这是一种系统化的方法。稍后我将展示如何将其集成到CI/CD流水线中，这样你就不必全程参与。每当智能体发生变更时，CI任务就会自动启动，针对数据集运行实验。它将以新的配置评估你的智能体，并根据我之前提到的所有分数和评估器给出通过或失败的关卡判定。这样你就有了一致的方法来评估和衡量这些智能体的输出，明白了吗？

好的，完美。这就是实验部分，很棒。我们讨论了实验、数据集以及通过人工标注将人类专业知识引入闭环的方法。那么接下来，我该如何……

把它们整合在一起？对吧？如果我来到这里，我有我的提示词，也就是我在这里 Langfuse 中进行版本控制的那个系统提示。你可以在 Langfuse 中完成这个操作，或者在其他地方也可以。你知道的，我们并不强制要求这样做，这没关系。我们甚至不为此收费，所以没问题。我们的许多客户会在系统内部维护一个版本，同时在 GitHub、GitLab 或其他代码托管平台上也保留一个版本。

但你应该将其视为触发自动化以完全自动执行评估的开关。实现这一点的流程是，我已经在这里定义了一个自动化规则。如果你查看配置，它会触发任何提示词更改的操作。然后动作是启动我在 GitHub 中的 CI（持续集成）作业，就是这里显示的这个。希望我没有被 GitHub 的独角兽图标误导……好吧，就是这个。我已经设置好 CI，等待我的代理配置中的任何更改发生。让我把它拉近一点。

然后我可以查看我的提示词，让我们看看这个版本。我有五个版本的提示词，你可以看到它是如何随着时间演变的。第一个版本包含这些内容；第二个版本做了细微调整；第三个版本我们尝试了不同的方法，这是用于开发的；第四个版本增加了更多细节，并向代理配置传递了不同参数。

现在我可以指定当前生产环境的系统提示词是哪一个，我想再次测试第四个版本，因为我看到了一些回归问题。所以我可以来到这里并执行“推广到生产”的操作。再次强调，我这里是作为人类用户手动点击演示的。所有这些操作都可以通过 API 或 CLI（命令行界面）完成，你甚至不需要手动执行这些步骤。

你可以直接调用 API，指定将该提示词版本标记为生产环境并推广它，系统就会自动为你启动流程。我拥有生产标签，我将保存并将其推广到新的配置中。几秒钟后，我们应该会看到一个新的 CI 作业在这里启动，进而触发实验以运行我的评估流程。好了，成功了。感谢 GitHub，非常感谢。

现在这个作业正在自动运行。因此，每当我推送对代理配置的任何更改时，它都会触发 CI 流程，并运行评估门控（eval gates），告诉我是否通过或失败了我们之前定义的任何评估器。

以这种方式，我可以获得证据和保障，确认我是否可以安全地将此新配置部署到生产环境。如果代理的质量实际上在退化或改善，或者甚至违反了我设置的任何护栏（guard rails），这些情况都会被检测出来。这可能需要运行几分钟，但让我展示一个我稍早运行的例子来显示结果。

我可以来到这里查看输出内容。它告诉我发送了哪个提示词、版本标签是什么，然后显示它们都通过了测试。完美。这些是我用来衡量代理表现的评估器：包括包含度（include）、来源召回率、语言匹配度、正确性以及非 solicited upsell（未请求的追加销售）。

我还可以定义最低阈值。我可以为这个特定分数设定最小门槛，如果未达到该标准，它就不会被视为通过生产环境部署的测试。当然，在这种情况下，我还没有疯狂到仅仅因为“通过了”就直接说合并代码并推送到主分支。我只是让它暂时停留在那里，但诚然，你可以建立一个完整的端到端流程：它会自动为你创建 PR（拉取请求），并等待有人审查该 PR。

或者，就像现在大家普遍做的那样，如果达到了标准，就直接将 PR 推送到主分支。但至少你拥有证据链（paper trail），也就是证明你为什么决定采用此新代理配置的依据和理由。你并不是凭感觉（vibes）或仅凭你认为代理擅长什么来推送代码，而是有实实在在的证据支持你的决策。

现在我想再展示几个实际用例方面的内容，因为我们一直在讨论 Langfuse 的技术方面……更多组织现在非常关注“代币经济学”（tokenomics）。我认为在 2025 年初到 2026 年，大家都在追求“代币最大化”（token maxing），而现在大家更像是关注“代币价值化”，无论他们怎么称呼它。每个人都在试图从他们的代币中提取尽可能多的价值。

因此，现在让我展示几种方法，你可以向老板、领导或利益相关者证明你正在构建的代理解决方案确实为业务带来了好处，而不仅仅是一个“很酷的技术玩具”。这样他们会对你的工作感到更加放心。

我这里有一个仪表板，我正在尝试整合一些指标，以便基于从代理收集的数据向业务部门报告。首先是一个可能引起你逻辑争议的点……但你知道，每个组织的情况都不同。我想展示的是：在过去七天里，有 1,400 次代理交互不需要转接给人工客服。这很棒，意味着我节省了人力资本去与客户交谈的时间并处理后续工作。

让我们算一下账：这花费了我不到 7 美元，在过去七天里。如果你回想一下我过去曾是呼叫中心员工（20年前），你知道你需要支付那个人每小时 15 到 20 美元。一个人不可能在一小时内处理 1,400 通电话。因此，仅凭这一点，你就已经展示了部署此解决方案所带来的方向性业务收益。

第二点是你还可以 pinpoint（精准定位）代理出现问题的领域。如果你还记得，我们在行业中定义了类别或称为“故障模式”（failure modes），即代理未能给出我想要的结果或答案的情况。这些是我在过去七天中按发生频率捕获的数据。

你可以看到，目前“超出范围”、“非正式语域”和“争议未解决”是我的前三大故障模式，并且它们一直在随时间上升。因此，我不需要去翻阅成千上万条追踪记录（traces）来找出导致最多错误或问题的代理活动是什么。

遇到麻烦时，我可以在此缩小范围。我已经知道这个故障模式是我的首要问题：自动缩放、已注册的首要争议未解决。因此，我现在可以在追踪中进行一个简单的筛选，输入“争议未解决”。我可以将其保存为视图，这样我就不需要每次都进行筛选。你可以看到顶部正在为我过滤内容。即使在侧面，我也可以在此处设置“争议未解决等于零”。这显示了所有客户有争议或要求对产品进行争议的实例，但代理未能解决的情况。这意味着要么转给了人工客服，要么只是悬而未决直到会话关闭且什么都没发生。

但现在我可以将时间花在缩小范围上，而不是浏览数千条记录，我将其缩减到几十或几百条。现在我可以进行更有针对性的调查。我现在还可以找到代理实际绊倒自己的领域。这是第一点。第二点是，如果我想在仪表板中操作，我希望能够查看客户给出点赞或点踩的次数。我可以很容易地将此捕获为分数。你可以看到，每次我都可以在此处点赞或点踩，并轻松地在仪表板中显示出来。

任何业务人员、用户甚至普通人都能轻易查看并说：“好吧，大部分是点赞，这很好。但点踩的情况呢？让我们重点关注那18%发生了什么。”另一个方面是关于安全混合，好消息是代理与客户的交互中大部分没有捕获到任何风险。但我们看到在过去七天中有89起案例，客户实际上是在寻求投资建议，而代理可能给出或试图提供投资建议。

因此我们可以专注于这些案例。同样地，我可以回到默认视图，然后说除了数值分数外，我还可以添加分类分数的条件。接着指定意图或安全风险，例如投资风险（投资建议）。现在我可以查看具体示例，其中投资建议被确定为标记原因，表明代理不应与客户就此进行互动。你可以看到甚至在我之前展示的示例中也是如此。

这就是我想展示的内容，首先是端到端解决方案的性质，首先面向客户。这显然具有许多关键影响，包括责任、财务影响以及声誉风险，因为你不想向客户展示不准确或幻觉的信息。你可以遵循系统化流程以提供证据并验证这些代理的输出是否确实遵循了你设置的护栏和控制措施。

借此机会，我想再次将时间交给Annabelle以结束演讲，最后也许我们可以回答几个问题。谢谢。>> 我们看到一些公司或团队试图这样做：“请修复我的代理，不要犯任何错误。”对此我们能给出的建议可能比这少得多。即使你的代理通过MCP或CLI连接到Lenfuse中的数据或使用其他工具，我们通常看到这产生的更多是垃圾而非真正有帮助的内容。

当然，我们也非常支持与编码代理合作以持续改进应用程序。我们分享这张图是为了让你记住这种模式：横轴是投入的时间（大量时间或很少时间），纵轴是系统质量（低质量或高质量）。你不想处于左下角。如果你完全自动化并让代理自行处理，想着“修复一切、替我做完”，这不会有好结果。

你最终会得到低质量的结果，虽然你不用做任何事，但客户也不会非常满意。同时，你也不想再走完全手动路线。你不应该自己为应用添加仪器（instrumenting），这可以自动化；你也不应亲自捕获所有故障模式并重新审查数据，这些也可以自动化。但在某些方面，你需要介入。

你应该让领域专家参与进来构建数据集，策划应用程序实际要解决的问题以及发展方向。因此，你希望达到理想的平衡点：既审查数据、注入品味和领域专业知识，又利用编码代理自动化所有可自动化的事务（如添加仪器、发现故障模式、运行评估，甚至进行20次实验而不是一次）。

避免陷入左下角的困境，努力成为有品味的AI工程师：注入品味、确保邮件等细节出色，然后随着时间的推移可以越来越自动化这个循环。如果我们是你且必须从明天开始行动，我们会这样做：安装Langfuse技能（agent skill）。

这是一种帮助编码代理理解如何与Langfuse协作及实施最佳实践的Markdown文件集。它链接了我们的文档、所有集成页面，以及我们的学院（Academy），在其中灌输关于数据集、添加仪器和编写评估器的最佳实践。这是一个很好的起点，可以自动执行那些本应自动化的事务，并策划需要人工查看的数据集。

然后你应该开始收集基准真相（ground truth），以便根据历史数据、生产环境或领域专家运行的样本对代理进行评估。如果你处于受监管的领域，请以确保这些绝对不应发生的方式定义硬性限制（hard limits），例如涉及金融内容时。

服务方面，例如它绝不应提供投资建议。因此请确保将这些规则也植入您的评估集中。理想情况下，这种情况永远不会发生；但至少当它发生时，您会知道。我们为您准备了一些资源。Donelli 向您展示并使用的代码库也可在线获取，您可以自行查看，从中选取任何您想要的部分用于您的用例。当然，这是虚构数据，并非来自我们的真实客户。我想本次会议也会被录制下来，您可以回头再看。

我们推荐 Langfuse Academy（Langfuse 学院），这是一份关于如何进行 AI 工程的大篇幅指南，重新描述了所有步骤。我们还提供自助式研讨会（self-serve workshop），基本会引导您完成所有步骤，让您理解后就能继续开发自己的应用。未来几天有一些机会可以与我们接触：Donelli 将在周三发表关于为 AI Agent 构建部署门禁（deployment gates）的演讲，如果您想了解如何确保进入生产环境的 AI 模型确实通过了质量门禁，不妨去看看。

我们还有一个展位（9号）。我不确定具体位置在哪，但我相信您能找到。您可以在那里见到团队，还能获得定制贴纸：拍一张您的脸，AI 会生成带有 Langfuse Logo 和您头像的贴纸，可能还会包含一些笑话。您可以把它们带回家，贴在您拥有的任何东西上。

最后，我们还有社区跑步活动（community run）。如果您想走出会议中心并结识团队，我们有两位创始人和几位团队成员都在。我们都是跑步爱好者，所以也想邀请大家加入。请务必参加。我们非常乐意利用剩余时间回答任何问题。这里还有一些非定制贴纸，虽然只是普通的 Langfuse 长条贴纸，但我觉得还是很酷的。如果您想要，可以上来领取。我们乐意解答任何问题，请来找我们要别见外。现在我把时间交给 Donelli（Delli）。

Langfuse 本身对 ClickHouse 存储有硬性依赖。这是因为在产品演进过程中，它最初使用 PostgreSQL；但随后 PostgreSQL 无法处理我们达到的规模——即每天数十亿甚至上百亿的事件。因此，我们迁移到了 ClickHouse。就数据平面而言，是的，使用 ClickHouse。但也许接下来的问题是：您在数据存储方面有什么具体需求？因为我们还提供数据导出功能，您可以将数据导出到 S3。

是的，您可以通过 API、CLI 或 MCP（Model Context Protocol）从 Langfuse 消费数据。这完全由您决定。“我想把它托管在……”“是的，您可以完全在 Amazon 上托管。我们也有自托管部署方案。”

您既可以使用我们的云产品，那是完全 SaaS 化的开箱即用服务（运行在 Amazon 上），您无需做任何操作；或者如果您想自己运行基础设施，比如手头有一些 EC2 实例想用，我们也提供相应的部署模型，并预打包了所有组件。“这是一个非常重要的问题。问题是关于迭代器的可靠性……”

以及作为评判者的 LLM 的一致性，以确保它确实能捕捉到您希望它捕捉的内容。Langfuse Skill（语言技能）也处理了这方面的问题，帮助您……这里有个术语，我一时想不起来了。归根结底，这是确保 LLM 像人类一样进行评判的过程。基本上，您亲自对样本（理想情况下是具有代表性的样本）进行标注，然后运行您的 LLM 作为评判者。接着优化该 LLM 的评判结果，使其与您的人类标注员保持一致。理想情况下，您会有几位人类标注员，这是学术上的做法。

因此，实际的做法可能是：由一个人标记一些数据，然后针对这个“地面真值”（ground truth）进行优化。随后理想情况下，您只需定期检查以确保您的数据集保持代表性。特别是如果您将其用于生产数据运行时，最终理想的做法是初期设置稍多的误报（false positives），以便捕捉到比必要更多的内容，但不要遗漏任何事项。然后随着时间的推移再逐渐调整收紧。