用户到底需要什么样的AI应用？

2024年，从需求侧基本可以确定两件事：

• 一是用户对AI生成这件事不再稀奇，更关注有用、准确、可控。

• 二是不要期待用户自己去配置复杂的提示词、外部工具、或者整理RAG知识库，对于用户来说，最好是拿来即用。

这驱动着开发者从浅水尝试区进入深水实验区：

• 在浅水区，开发者只要利用dify、langchain的工具，配上RAG(记忆），配上工具（函数调用）就能搭建出一个完整的Agent，但至于这个Agent 具体干活质量如何，并没有考虑清楚。

• 在深水区，Agent的行为需要被量化评估，从而驱动Agent的诞生和自我进化，也就是：由评估结果决定Agent是否可以发布，以保证在第一天使用就能被用户接受；由评估结果也驱动Agent持续进化以保证不断超出用户预期。

我把这种基于评估推动Agent开发的方式称为：Evaluation-driven development。可以说2024年下半年我们一直在做这件事情。

如何用评估促进产品迭代？

深水区的第一件事情是构建自己场景的评估测试集，测试集很大意义上代表需求，决定着提示词应该如何调整、模型应该怎么选择、知识库应该如何检索。

比如日期推理这件事情，用户会有N多种表述日期的方法：

• 直接的历法日期（阴历、阳历）

• 类似今天、明天、明年此时这种相对说法

• 节气、节日这种别称

• 事件描述，比如xx成立的那天、暑假、寒假等

我们需要首先为每一种描述构建自然语言描述与绝对日期的映射关系，然后才开始进行提示词调优，直到整体表现达到最优为止。

理想情况下，这些评估测试集应该是从用户反馈来收集，但这个思路会让我们陷入蛋生鸡还是鸡生蛋的悖论：

• 我们期待的是：越多使用，越多反馈，越好产品。

• 而实际中是：一次使用，效果不好，不再使用，没有数据[惨~]

  
  

作为开发者，不要期待用户给我们太多机会“贡献”出他的数据。也就是说，从开始开发者自己就要有能力构建出大量、合理的冷启动测试数据集，然后在此基础上逐渐迭代完善测试数据。

深水区的Agent开发更像是一门实验科学，且这个实验一开始效果就不能太差。

关于如何做好这个实验，Langchain家族的AI度量观测工具LangSmith官方文档给出一张图，高度概括了LLM AI 应用的实验方法。在这个图的基础上，我用考试来类比实验体系中的各个要素（如图）。

实际上，这套实验评估方法和非AI产品的评估方法是一致的，比如我们做A/B test的时候：

1. 出的题目是某按钮的位置位于A，B；

2. 打分标准是看哪个位置的点击率(或者转化率)更高；

3. 参与考试的考生是一个应用；

4. 最终分数就是对A/B test的置信率的解读等。

只是在LLM AI应用中，打分标准不像点击率(或者转化率)那样确定。简单来说，LLM中的题目更像是陈述题，你可以参考像高考历史论述题那样建立标准：

不过，Agent的评估可不止这些，Langsmith还给出了一整套的方法（下图），这些内容能让我们学会：

• 如何做出好的评估数据（手动、收集或者合成），比如用合成数据构建冷启动的第一组评估数据集，也就是给出例句让大语言模型仿照你的案例来写，最后再来人工辅助修改。

• 如何构建打分标准。

• 如何给出分数结果。

在这里不做一一列举，图中讲得比较明白。

只有当你的评估体系构建之后，才会有向最高标准演进的方向，这些演进方法包括：

• 选择不同的大语言模型。

• 调整提示词。

• 调整知识检索的方法（如果有RAG）。

• 切换不同用户群体。

• 甚至还有自动调整提示词的开源项目Dspy，它可以让你在每次修改 LLM、检索器、评估标准或其他任何东西时，都可以重新优化一组新的提示和示例，以最大限度地满足你的评估标准。

所以你看，评估标准的建立可以说是Agent 优化的最强驱动力， Evaluation-driven development是Agent开发的必然趋势。

在Agent开发的深水区，Evaluation是一项系统工程。应该既有针对Agent整体输出的评估，也有针对Agent工作流每个节点的评估。

比如在下面这个例子中，我们定义Agent首先从文档库中检索到相关问题的解决方案，然后基于解决方法决定是否要调用工具（函数调用），综合使用到RAG和函数调用。为了让Agent的回答准确率达到最高，我们除了要对比最终结果，还需要在各个节点中制定相应的评估方案（红色表示，大家仔细看图，这里就不会文字罗列了）。

可见，要系统地做好这一套评估，更多的是脏活累活。但也只有评估体系，才能随着用户的使用让Agent变得越来越好。

为此，市面上出现了不少的评估工具（比如下表），这些工具的使用、博客文档能让你对Evaluation了解得更加清楚。

能不能让评估变得更加简单？

不过在仔细看过这些工具后，你会发现：工具只是提供了一个框架，这个框架里提供了dataSet,Evaluator,task,和score的位置，里面的具体内容仍然需要开发者自己构建。

此时我们发现在工具使用能力评估方面，可以有标准化的流程让评估变得更为简单，比如上图中对工具使用能力的评估有两个地方：

• 一是：Agent是否能从众多工具中选择到正确工具，比如需要查询用户地址应该调用searchUser， 而不是updateUser。对应于下面这样一组数据集：

  

  
  

• 二是：Agent需要将自然语言转换为正确的函数调用格式。比如需要从自然语言指令中提取出正确的参数值，对应下图这样的语言关系。

这两个过程中，选择工具相对简单；而如何对第二项评估就稍显繁重，比如首先要构建大量的对话数据，其次这些对话数据要和函数调用对应起来，然后在评估的时候，需要对函数语言进行解析，提取出相应的参数内容，再和对话里的数据进行比对...

不过，好消息是：我们为此而开发的Chat2API正是为了解决这类问题而生，在下一篇，我们来详细讲讲Chat2API的诞生和方法。