你们是如何在评估失败后，得到一个能在生产环境中保持稳定的提示修复的？

你发布了一个LLM应用，一次评估标记了一个错误答案，仪表盘上显示红色。很好。现在你仍然需要弄清楚到底要修改提示中的什么内容，发布那个修改，并证明同样的失败不会在下周悄然重现。这后半部分缓慢、手动且容易出错，而许多评估和可观测性工具都在这里止步，将工作交还给你。我们在审视现有工具时，有两件事很重要：工具是否能带你从捕获的错误到可信的修复？以及你是否能在自己的硬件上运行整个系统，而无需企业合同？你可以使用以下任何工具并获得实际价值，下面是对每个工具的诚实评价。你可以使用LangSmith进行强大的跟踪和评估。它的评分在响应发出后才运行，自托管需要企业计划。你可以使用Weights & Biases的Weave进行跟踪，它可以内联运行护栏评分器，在不良输出到达用户之前阻止它。自托管是企业的设置。你可以使用Arize的Phoenix进行OpenTelemetry原生跟踪和评估，拥有庞大的社区。它根据Elastic License发布，因此是源码可用。如果你专注于回归循环，可以选择Braintrust：将生产中的错误转化为测试，并在每次提示或模型更改后重新运行。它提供了Loop来帮助重写提示。它的生产评分在答案发出后读取，其网关路由模型但不治理工具。你可以使用Galileo通过Protect内联阻止，并将其Agent Control策略层以Apache-2.0开源。你要在这里比较的评估和可观测性核心仍属于企业计划。你可以使用Comet的Opik获取Apache-2.0、可自托管的栈，包括护栏和Agent Optimizer。它的网关仍处于测试阶段，尚未能治理每个运行时代理可以调用哪些工具或MCP服务器。总而言之，模式是一样的。你得到了一个清晰的信号，说明有问题，然后修复、提示更改以及证明不会再次发生的证据又回到了你手上，通常要手动拼凑两到三个工具。我们构建了开源平台来端到端地关闭这个循环，从捕获错误答案的评估到可以证明不会再次发布相同失败的提示修复。跟踪、评估答案的LLM评分、拒绝服务的护栏、以及提出修复的提示优化都在一个跟踪上运行，因此标记低基础性评分的同一检查可以阻止答案，并将该失败直接输入你的回归集。它是Apache-2.0的，可以在Docker Compose上运行，因此你的提示和输出都保存在你控制的硬件上，对许多团队来说，这决定了是发布还是通过安全审查。由于它是一个系统，它还可以在每个运行时治理代理可以调用哪些工具或MCP服务器，精确到单个调用。所以，对子版块的一个真正问题：当评估标记了一个错误答案时，对你来说，这是一个仪表盘加回归测试的时刻，还是你真的会在它发布之前阻止或修复它？如果你修复了，你如何证明同样的错误不会再次出现？