【Datawhale-动手学大模型应用开发】验证迭代

大模型迭代思路

Step 1:
首先对项目进行初始化,简单的构造一些案例

Step 2:
1. 然后按照一些思路(如 。。。)找出Bad Case
2. 针对Bad Case做出Prompt优化(仍坚持Prompt设计原则和技巧),并保证优化后的Prompt不会在原先表现良好的样例上出现失误
3. 不断找到Bad Case进行优化,将这些Bad Case逐步加入验证集

Step 3:
验证集有一定规模后,需要构造一种自动评估方法,实现整体评估

Step 2:Bad Case的寻找和优化思路

初步测试时需要我们自己去寻找Bad case,后续开放给用户时,可以通过用户反馈来收集Bad Case,这里我们主要探讨自己寻找Bad Case的思路

1. 回答质量上直观的提升

直接评估回答的质量,判断哪方面不足,比如不够具体或者思路不清晰等

2. 标明知识来源,提高可信度

针对大模型的幻觉问题,为了保证模型回答来源于已有知识库内容,让模型标明知识来源,以保证真实性

3. 构造思维链

模型本身存在能力限制,通过构造思维链的方式来将Prompt构造成一系列步骤,从而减少复杂步骤对模型能力的限制,比如,可以构造一个两步的思维链,要求模型在第二部做出反思,来消除大模型的幻觉问题

4. 增加指令解析

针对用户的不同要求,比如:格式要求和回答问题的需求,在检索LLM之前,增加一层LLM来实现指令解析,从而将两个要求拆分开。这种思路也是Agent机制的雏形。

Step 3:大模型评估方法

1. 人工评估的一般思路

验证集体量较小时,可以直接进行人工评估,人工评估也有一些基本准则和思路

准则一:量化评估

对每个验证案例的回答都给出打分,最后计算所有验证案例的平局分得到本版本系统的得分,设定一定的评估标准,方便不同评估员的评估结果相对一致

准则二:多维评估

尽量从多个维度出发,设计每个维度的评估指标,在每个维度都进行打分,从而评估综合性能。

同时,多维评估应当和量化评估有效结合,对每个维度,设置的量纲可以适当不同以结合业务实际情况。比如相关性较大的设置较高量纲,相关性较小的可以设置较低量纲。

2. 简单自动评估

方法一:构造客观题

将主观题的评估转换为客观,比如将填空题转为选择题,可以是单选也可以是多选。

方法二:计算答案相似度

通过比如nltk库中的bleu来计算相似度,用于评估回答与人工标准答案的相似程度,不过这类方法存在一些问题,比如人工构造答案不一定简单,可能内容相似但方向相反等,或者说无法评估模型是否生成了更好的答案。

3. 使用大模型评估

人工评估准确度高,全面性强,但人力成本时间成本高;自动评估成本低,速度快,但存在准确性不足,评估不够全面等问题。大模型进行评估可以结合两者优点:

构造Prompt Engineering让大模型充当评估者角色,从而代替人工评估的评估员,同时大模型可以给出类似于人工评估的结果,因此可以采取多维度量化评估的方式,实现快速全面的评估。Prompt样例:

prompt = ''' 
你是一个模型回答评估员。
接下来,我将给你一个问题、对应的知识片段以及模型根据知识片段对问题的回答。
请你依次评估以下维度模型回答的表现,分别给出打分:
① 知识查找正确性。评估系统给定的知识片段是否能够对问题做出回答。如果知识片段不能做出回答,打分为0;如果知识片段可以做出回答,打分为1。
② 回答一致性。评估系统的回答是否针对用户问题展开,是否有偏题、错误理解题意的情况,打分分值在0~1之间,0为完全偏题,1为完全切题。
③ 回答幻觉比例。该维度需要综合系统回答与查找到的知识片段,评估系统的回答是否出现幻觉,打分分值在0~1之间,0为全部是模型幻觉,1为没有任何幻觉。
④ 回答正确性。该维度评估系统回答是否正确,是否充分解答了用户问题,打分分值在0~1之间,0为完全不正确,1为完全正确。
⑤ 逻辑性。该维度评估系统回答是否逻辑连贯,是否出现前后冲突、逻辑混乱的情况。打分分值在0~1之间,0为逻辑完全混乱,1为完全没有逻辑问题。
⑥ 通顺性。该维度评估系统回答是否通顺、合乎语法。打分分值在0~1之间,0为语句完全不通顺,1为语句完全通顺没有任何语法问题。
⑦ 智能性。该维度评估系统回答是否拟人化、智能化,是否能充分让用户混淆人工回答与智能回答。打分分值在0~1之间,0为非常明显的模型回答,1为与人工回答高度一致。
你应该是比较严苛的评估员,很少给出满分的高评估。

用户问题:
{}
待评估的回答:
{}
给定的知识片段:
{}
你应该返回给我一个可直接解析的 Python 字典,字典的键是如上维度,值是每一个维度对应的评估打分。 不要输出任何其他内容。

大模型评估仍然存在问题:

  1. 我们目标是迭代改进Prompt以提升大模型表现,所以我们所选用的评估大模型需要有由于我们的大模型基座的性能。
  2. 大模型虽然有强大的能力,但也存在能力的边界,如果问题与回答太复杂、只是片段太长或是要评估的维度太多,即便是GPT-4也会出现错误评估、错误格式、无法理解指令等情况,我们建议考虑一下方案来提升大模型表现:
    1. 改进 Prompt Engineering。以类似于系统本身 Prompt Engineering 改进的方式,迭代优化评估 Prompt Engineering,尤其是注意是否遵守了 Prompt Engineering 的基本准则、核心建议等;

    2. 拆分评估维度。如果评估维度太多,模型可能会出现错误格式导致返回无法解析,可以考虑将待评估的多个维度拆分,每个维度调用一次大模型进行评估,最后得到统一结果;

    3. 合并评估维度。如果评估维度太细,模型可能无法正确理解以至于评估不正确,可以考虑将待评估的多个维度合并,例如,将逻辑性、通顺性、智能性合并为智能性等;

    4. 提供详细的评估规范。如果没有评估规范,模型很难给出理想的评估结果。可以考虑给出详细、具体的评估规范,从而提升模型的评估能力;

    5. 提供少量示例。模型可能难以理解评估规范,此时可以给出少量评估的示例,供模型参考以实现正确评估。

4. 混合评估

多种评估方法混合,从而兼顾高效,全面和准确。
针对大模型的回答,可以评估:客观正确,主观正确和智能性
前两者通过大模型,后者通过人工评估,
最后针对知识查找的正确性,可以通过大模型进行评估,同时通过该项与主观正确进行结合判断是否有【幻觉】情况。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
软件开发模型是一种有序的方法论,用于规划、设计和构建软件系统。它是指导开发团队在整个软件生命周期中的工作流程和策略。常见的软件开发模型有瀑布模型、原型模型、增量模型、敏捷开发模型等。 瀑布模型是最经典的软件开发模型之一。它基于线性顺序,将软件开发过程划分为需求分析、设计、编码、测试和维护等连续阶段。这种模型适用于需求较为明确、稳定的项目,且团队中的人员具备较高的专业技能。 原型模型强调快速原型的开发迭代。它特别适合在项目前期迅速了解用户需求,并通过原型验证解决方案的可行性。原型模型在需求不明确或变动频繁的项目中具有较大优势。 增量模型将软件开发划分为多个可交付的功能模块,每次增量都包含一部分功能。这种模型适用于较大规模的项目,能够进行持续集成和快速交付。它可确保早期软件功能的可用性,并通过用户的实际使用反馈来指导后续开发工作。 敏捷开发模型是一种迭代、增量的开发模型。它通过团队合作、开发者交付和持续改进等实践,以满足不断变化的需求。敏捷开发模型强调快速响应和高效交付,适用于市场竞争激烈、需求频繁变动的项目。 对于系统分析师来说,了解不同的软件开发模型及其应用十分重要。他们必须根据项目的特点和需求,选择合适的开发模型,并与团队合作制定开发计划和实施策略。同时,系统分析师还需要不断跟进技术的发展,熟悉新的开发模型,并将其灵活应用于项目中,以提高软件开发的效率和质量。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值