你的LLM提示词有200行。你真的知道智能体遵从了多少吗？

构建聊天产品或自主智能体与以往的任何事物都不同。传统产品具有清晰的指标：用户是否执行了某个操作？这些信息都在你的数据库里。而对于对话来说，*有用*的定义要困难得多。这是一次好的交互吗？用户到底想做什么？没有评估，你基本是在猜测。以下是大多数团队跳过的监控层。 **离线评估** 在新版本上线前，你需要智能体必须通过的测试用例。通过/失败可能不是二元的，通常你会定义可接受的成功率阈值。难点在于决定包含哪些内容。评估需要代表生产数据：不是你在网上找到的最相关的基准，不是产品需求文档中的少数几个例子，也不是合成生成的假设。如果你的评估与实际生产情况不符，你就没有在衡量正确的事情。 **提示工程** 在最初的惊艳感过后，你会发现智能体并没有按预期工作。于是你开始进行提示工程。随着时间的推移，提示词增长到几十甚至上百条语句，尽管你明确告诉智能体某个行为很重要，但在生产环境中你仍然看到它反其道而行。而且通常你是偶然发现的。这远远不够。 **可观测性工具** 大多数LLM可观测性工具给人的感觉更像是系统监控仪表盘，而不是专门用来捕捉智能体是否遵循指令的工具。评分器和LLM作为评判（LLM-as-a-Judge）能有所帮助，但基于模型的方法有其不准确性。你仍然需要人工审查数据。随机抽样只能做到一定程度。你需要优先考虑审查的内容。 **审查队列** 如果成百上千的对话询问同一个问题，重复审查同一件事就是浪费。你需要多样化的示例：嵌入距离、工具使用极端情况、回答长度、延迟或其他信号。某些问题可以自动标记：智能体没有遵循明确的提示指令，或者根据事实性检查器发现知识库中没有提到的声明。优先展示这些。 **标注** 当你审查对话时，对其进行注释： * 标记问题，附上问题描述以及为何重要。这些会作为测试用例纳入你的离线评估。 * 记录正确的行为。关于良好表现的详细说明可以用作训练数据。 为你的应用建立一个问题分类体系，不是泛泛的有用性或毒性，而是那些对你的用例真正重要的事情。 **大规模获取洞察** * **聚类：** 将相似对话分组，了解人们在谈论什么，然后深入分析特定集群 * **主题分类：** 按用例细分，从而了解你的工具实际上是如何被使用的；保持分类体系在你的控制之下 * **评分器：** 一个分类器或小型模型，为每个对话添加元数据（回答长度、使用的语言、是否输出了代码等） **成本** 人工审查不可替代但成本高昂。LLM作为评判更便宜，但成本会累积。基于人工标签训练的小型分类器可以低成本处理大部分数据。分层使用它们：对所有数据使用分类器，对子样本使用LLM作为评判，对最模糊或最高价值的示例使用人工审查。 你是如何追踪你的智能体会话的？很好奇大家使用了哪些技术和架构。