日常见到的电商领域的智能客服、金融领域的投资顾问、法律行业的卷宗库、医疗领域的智慧问诊…这些产品的背后其实都是同一类系统:基于AI大模型的知识库问答系统。
在众多AI大模型应用场景中,知识库问答算是AI大模型应用比较成熟,广泛的场景之一。
但大模型与生俱来的”天性“:幻觉,带给实际应用场景中各种各样的上层问题,比如偏见、歧视等。所以如何评估这类系统就显得尤为重要。
阅读本篇,你将收获:
-
知识库问答系统的评估构建思路是什么? -
如何设计知识库问答系统评估指标? -
如何设计知识库问答系统评估方案? -
知识库问答系统Badcase如何分析、归因、迭代? -
如何搭建大模型系统线上运行监控看板?
一、评估体系构建思路
1.1 多维评测体系
一般来讲,搭建评测有这么几个目的,评估大模型的基本性能表现;评测系统在业务方面的实际表现;根据评测的结论,指导产品的优化与技术的迭代方向。
所以评估体系可以从业务、技术、安全三大方向进行构建。
业务类:用户直接根据系统的回答反馈,给到一手的主观反馈。
技术类:从专业的角度评估回答结果的准确、完整、简洁。
安全类:从安全或者稳定的角度测试(对抗型测试)系统在错误、边缘、复杂场景下的表现。
以下作者梳理出一个多维的评测体系:
|
|
|
|
|
|---|---|---|---|
|
|
问答准确性 |
|
|
|
|
答案完整性 |
|
|
|
|
答案简洁性 |
|
|
|
|
语义相关性 |
|
|
|
|
用户体验 |
|
|
|
|
稳健性 |
|
|
1.2 常见关键指标解读
Top-1准确率:用于判断模型最自信的答案是否正确,依赖于人工判断(标注)。
BLEU(Bilingual Evaluation Understudy):是一种基于n-gram重合度的评估方法,就是将模型回答和标准答案进行逐词对比,计算n-gram值。一般会引入BP(Brevity penalty)防止回答内容过短。一般 BLEU > 0.6 视为“合理回答”。
ROUGE(Recall-Oriented Understudy for Gisting Evaluation):判断生成文本是否覆盖了参考答案中的关键信息,适用于摘要任务。一般 ROUGE-L > 0.7 视为“合理回答”。
Embedding 相似度:使用词向量表示文本的语义,然后用余弦相似度判断语义是否接近。
**EM (Exact Match)**:完全匹配,是指回答和标准回答在词粒度上的匹配。
AUC(Area Under the Curve):是指ROC(Receiver Operating Characteristic)曲线下的面积,这个曲线横坐标是假阳性率,纵坐标是真阳率。AUC值越大,说明随机抽取一个正负样本,抽中正样本比负样本更大的概率。当值为0.5时,说明模型基本没作用,大于0.7时说明比较好。
响应时延:判断大模型给到用户的反馈时效,系统可自助记录。
二、构建评测数据集
企业环境下,构建评测体系的第一步便是测试数据集(Benchmark)的搭建,通常情况下数据来源于这几类渠道:
-
真实业务数据:从客服日志、知识库搜索日志。 -
专家数据:通常是公司的运营或市场部门的经验和知识文档总结。 -
扩展数据:通过同义表达、拼写错误、长尾问题等方式构造一些对抗型测试数据。
构建完数据集时候,往往还会对以上样本进行分类,不同分类下的问题,依赖于大模型的能力也不尽相同。
-
高频常见问题:这类问题通常都有相对标准的问答,依赖通用大模型生成能力。 -
长尾复杂问题:比较依赖大模型的推理能力。 -
歧义/模糊问题:比较考验大模型语义理解能力。
此外,多轮对话场景下,比较依赖的是大模型的上下文记忆能力。
有了对问题类型的基本分类之后,也就有了针对不同类问题需要的大模型能力有侧重,特别在问题归因环节,会有针对性的定位问题点。
三、评测方案设计
通常情况下,知识库问答系统的测试方案主要分为三类”自动化、人工、ABTest。
自动化测试:这是最经常使用的方式,工作流是先benchmark数据集加载、模型调用、自动打分(BLEU、F1、Embeding等)、评测日志(记录每条样本的预测结果、得分、时间等信息)
人工评测:通常一些比较复杂的问题或者badcase,完全通过技术指标不足以评判,这个时候就需要人工介入。这一环节的关键点是要定义好什么算“正确”、“合理”。
AB Test:这是数据科学领域比较成熟和常用的方式,按照控制变量法,在准确率、用户满意度等指标上对比不同模型或者相同模型不同版本间的差异。
以下作者梳理了评测指标常见的评测方法
|
|
|
|
|---|---|---|
| Top-1准确率 |
|
|
| EM (Exact Match) |
|
|
| F1 Score |
|
|
| BLEU/ROUGE |
|
|
| Embedding相似度 |
|
|
| 响应时间 |
|
|
| 用户满意度 |
|
|
四、Badcase分析、归因、迭代
4.1 Badcase的一般分析思路
企业环境下,常见的问题归因方案大约如下:
-
检查数据集版本、大模型版本、Embeding模型版本等基础信息是否存在变动。 -
Prompt调试:分析提示语是否存在歧义。 -
知识缺失:知识库本身是否缺乏支持内容。 -
日志分析:查看请求是否检索到正确知识片段。 -
Token分析:生成过程中是否发生截断。
4.2常见问题总结
对于评测出来的badcase,常见的问题有回答缺失、回答错误、信息冗余、答非所问等等。
这里作者梳理出常见问题类别及可能归因:
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.3常见问题的优化迭代建议
在找到问题之后,对应的优化迭代放下整理如下:
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
四、评估结果可视化与输出报告
以上内容主要用户产品研发阶段的评估测试,待系统上线生产环境之后,一般会同步构建一个在线系统运营的可视化分析看板(Dashboard)。
这个环节一般侧重在业务指标的跟踪和分析,在发现问题的时候,会结合业务指标、技术指标等进行综合的问题归因处理。
以问题解决率业务指标为例,Dashboard的看板分析模型如下:
-
当前线上模型每日表现趋势 -
多模型/版本表现趋势对比 -
不同问题类型得分对比 -
Badcase示例采样展示
最后,大模型强大的上下文理解和推理能力,使得基于传统语义解析方法构建知识库类问答项目有了全新的解决方案,但大模型自身的弊端特性和用户输入的不可控性给这类项目带来了不小的变量。
如何构建好一个系统化的大模型项目评估体系,很大程度上决定了AI 产品成功的关键因素之一。一个成体系化的评估系统,能够在充分发挥大模型优势的同时最大限度降低项目的不确定因素,最终实现打造智能、稳定、高效的AI 产品。


