Launch HN：Laminar（YC S24）——我们训练了一个模型来捕捉无声的智能体故障

大家好，HN，我们是 Laminar 的 Robert 和 Din（https://laminar.sh）。自 2024 年以来，我们一直在为 AI 智能体构建开源可观测性工具。最近，我们发布了 flow-1，这是一个通过 RL 训练、用于发现智能体追踪记录中错误的模型。在我们的基准测试（https://laminar.sh/blog/flow-1）中，它的检测质量与 GPT-6-sol 相当，但成本低 23 倍。这使得分析生产环境中的每一条智能体追踪记录成为可能，而无需抽样。这里有一个一分钟的演示：https://youtu.be/KJa3h6ZJNLQ 我们还发布了一篇文章，展示 flow-1 和其他模型的示例追踪记录与分析结果：https://laminar.sh/blog/flow-1-in-action 智能体可观测性领域竞争激烈，因此我们不会列出 Laminar 与 X 的逐条差异，而是从第一性原理出发，解释我们如何解决智能体可观测性问题。如今，智能体会运行许多步骤，并以隐式方式失败。智能体可能点击错误的按钮，或引用错误的文档，但每次调用都成功完成。这些错误最值得被发现和理解。要找到它们，你需要理解智能体试图完成什么，并检查它的 LLM 调用和工具结果。仅仅查看智能体的最终输出是不够的。 单独收集追踪记录并不能解决问题。许多智能体可观测性平台的核心仍然只是数据收集器。最终，你可能花钱存储了大量追踪记录，却没有人有时间阅读或从中提取价值。使用另一个 LLM 检查追踪记录是解决这一问题的关键，但能力强的模型大规模运行成本高，而更便宜的模型往往会漏掉错误，或标记出无关内容。 因此，我们构建了专门解决这一问题的模型。我们对一个小型 OSS 模型进行了微调，随后使用数千个针对软件、法律、客户支持等领域真实智能体工作流的合成调查案例，通过 RL 对其进行后训练。最终得到的模型既擅长分析智能体追踪记录，运行成本也非常低。 flow-1 运行在我们称为 Signals 的执行框架中。它表现得像一个编码智能体，把智能体追踪记录当作代码仓库，其中每个 span（LLM 调用、工具调用等）都相当于一个文件。它从完整智能体追踪记录和用户提示词的压缩字符串表示开始，然后在各个 span 中进行 grep，并完整读取相关 span。 Signals 的优势在于，它能够响应通用提示词。你可以让它识别用户的挫败情绪，检查浏览器智能体是否完成了结账，等等。它并不局限于原始错误检测。它会以 JSON 形式返回发现结果，其 schema 可以由用户自由定义。我们称这些结果为 signal events。 当你分析每一条追踪记录后，单独的事件数量也会多到无法逐一阅读。因此，我们会自动将相似的 signal events 分组成集群。你可以看到反复出现的问题及其发生频率，然后深入查看单个事件以及其背后的追踪记录。你还可以使用某个集群中的追踪记录，为该类故障构建评估数据集。接着，你可以使用自己喜欢的编码智能体，在这些评估上进行 hillclimb，并在将修复发布到生产环境之前，检查它是否适用于这些案例。 追踪记录 → 分析 → 捕捉错误并形成集群 → 修复 → 发布。我们构建 Laminar，就是为了让这个循环变得简单。 我们也以同样的思路打磨了 Laminar 的其他部分。我们的博客（https://laminar.sh/blog）介绍了我们如何通过深入观察智能体的实际工作方式，构建出 20 倍追踪记录压缩、自定义 SQL 查询引擎和自动任务提取功能。 Laminar 采用 Apache 2.0 许可并支持自托管（https://github.com/lmnr-ai/lmnr）。我们的收入来自托管云服务。 我们很想了解你们目前是如何跟踪智能体性能的。你们从用户反馈中获得的信息，与通过自有监控获得的信息相比，各有多少？当你修复某个问题后，如何确认没有因此引入另一种故障？ 评论链接：https://news.ycombinator.com/item?id=50154029 积分：6 # 评论数：0