@
Clannad0708 评估分为两个视角
首先是性能、成本方面,也就是你说的上下文处理效率,从用户发起一个请求,经过几个环节的 prompt 注入,最后得到一个结果,这中间每一个环节都需要有个留痕,通过 traceid 串起来;
有了这个基础设施之后,我基于目标的 userstory 所对应的场景,每个场景准备 n 个场景的用户 query ,保证 query 覆盖面在实际场景中能占到 70%左右;用这些 query 做端到端的观测,看上下文、skill 、思考过程中有没有什么多余的动作,这些多余的动作有没有额外的 token 消耗;
如果识别到了这种多余的动作或者异常的 token 消耗,就会走一套比较严谨的消融实验来论证要不要优化某个环节的设计;
其次是业务效果方面也会分两块,首先是客观效果,这块其实是关心业务目标,然后基于业务目标,拆解成一套可以刻画业务目标的评估维度,围绕着维度,mock 了一套测试集,定义好输入输出,因为我是销售 agent 场景,你可以理解为长得像这套 salesforce 定义的一套 benchmark,
https://huggingface.co/datasets/Salesforce/CRMArena/viewer通过这套 benchmark ,我们能够定义 agent 出厂的质量;
而主观的质量就要通过缓慢的灰度发布来一步步的和用户磨合了,每周多开一批用户,设定一个灰度预期,然后与用户泡在一起使用,看看有没有没想到的问题,直至推全;好的 agent 产品是规划不出来的;