devbox
IT小白
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

WEBCPM包含什么

作者：IT小白 | 2024-07-12 04:49:13

赞

踩

webcpm

webcpm

img

WebCPM其实是这三篇论文中最新的一篇，所以集成了webgpt和webglm的一些方案。构建了通过和搜索引擎进行多轮交互，来完成长文本开放问答(LFQA)的整体方案。它使用的搜索API是Bing。23名标注人员通过和搜索进行多轮交互，来获取回答问题所需的支撑性事实。

webCPM的问题来自Reddit上的英文QA转成中文。之所以使用Reddit而非知乎，百度知道，是因为后两者的答案往往经过很好的处理，直接搜索一轮就能获得很好的答案，降低了多轮搜索的交互难度。人工标注的搜索数据微调10B的CPM模型并在LFQA任务拿到了不错的效果。

WebCPM的整体框架就是上面提到的4个模块，下面我们来分别介绍。强烈建议和源码结合起来看，论文本身写的略简单，哈哈给读者留下了充分的想象空间。

Action：行为规划

首先是行为规划，也就是让模型学习人和搜索引擎交互生成的行为链路。webcpm针对交互式搜索问题，定义了包括搜索，页面加载，页面下滑等以下10个行为。不过个人感觉如果只从解决长文本问答出发，以下行为中的Scroll，load page等操作其实可能可以被优化掉，因为内容的遍历可以通过引入排序模块，和以上的摘要模块来筛选相关和不相关的内容，并不一定要通过Action来实现。这样可能可以进一步简化Action空间，提升效果。

img

针对行为序列的建模，被抽象为文本分类问题。把当前状态转化为文本表述，预测下一步Action是以上10分类中的哪一个。当前状态的描述包括以下内容

  • 最初的问题：question

  • 当前的搜索query：title

  • 历史Action序列拼接：last_few_actions，消融实验中证明历史Action序列是最重要的，哈哈所以可能可以简化成个HMM？

  • 历史全部摘要内容拼接：quotes

  • 上一步的搜索界面：past_view, 上一步页面中展示所有内容的标题和摘要拼接的文本

  • 当前搜索界面：text, 当前页面中展示所有内容的标题和摘要拼接的文本

  • 剩余Action步骤：actions_left

以下为指令样本的构建代码，就是把以上的状态拼接作为input，把下一步Action作为Output

def make_input(self, info_dict, type="action"):
    context_ids = ""
    def convert_nothing(info):
        return "无" if len(info) == 0 else info
​
    context_ids += "问题：\n" + info_dict["question"] + "\n"
    context_ids += "摘要：\n" + convert_nothing(info_dict["quotes"]) + "\n"
​
    last_few_actions = ""
    for past_action in info_dict["past_actions"]:
        if past_action != []:
            last_few_actions += past_action
​
    context_ids += "当前搜索：\n" + convert_nothing(info_dict["title"]) + "\n"
    context_ids += "上回界面：\n" + convert_nothing(info_dict["past_view"]) + "\n"
    context_ids += "当前界面：\n" + convert_nothing(info_dict["text"]) + "\n"
​
    context_ids += "剩余操作步数：" + str(info_dict["actions_left"]) + "\n"
​
    if type == "action":
        context_ids += "可选操作："
        for idx, k in enumerate(self.action2idx):
            context_ids += self.action2idx[k]
            if idx != len(self.action2idx) - 1:
                context_ids += "；"
        context_ids += "\n"
​
    context_ids += "历史操作：" + convert_nothing(last_few_actions) + "\n"
​
    if type == "action":
        context_ids += "下一步操作："
    elif type == "query":
        context_ids += "请生成新的合适的查询语句："
    elif type == "abstract":
        context_ids += "请对当前界面内容摘取和问题相关的内容："
​
    next_action = info_dict["next_action"]
    return context_ids, next_action

具体分类模型的微调就没啥好说的了。不过这里需要提一下，源码中其实给出了两种webcpm的实现方案。两种方案均开源了数据。

  • Interactive方案：对应当前的行为建模，每一步执行什么行为会由Action模型预测得到，同时以下query改写，摘要等模块，也会获得之前所有执行步骤已有的上文输出，进行条件文本生成任务

  • pipeline方案：整体行为链路固定依次是，query改写 -> 所有改写query搜索得到Top-K内容 -> 针对每个页面进行摘要抽取 -> 整合所有内容回答问题。 因此Pipeline方案并不需要Action模型，同时以下的摘要改写等模块，也会简化为不依赖上文的文本生成任务

这么说有些抽象，让我们用Query改写来看下以上两种方案的差异，假设用户提问：网页布局都有哪种？一般都用什么布局？

  • Interactive：第一个改写query=网页布局种类, 然后搜索+摘要获得网页布局总结性的概述后，第二个query在已有摘要内容的基础上，改写query=网页布局最佳实践, 这样综合两个query的内容就可以回答上述问题

  • pipeline：在最初就调用query改写模型生成一堆改写query，例如网页布局种类，网页布局技巧，网页布局模式，网页布局优势。然后全部去调用搜索引擎，再对所有返回结果进行整合。

虽然看上去Interactive似乎能得到更优解，但其实只对明显串行的搜索任务有边际增益，整体没有pipeline模式更加简洁优雅。因为pipeline模型的无条件生成，使得每一步都可以并发处理，更容易落地。并且每个模块可以独立优化，可以相互解耦。因此以下三个模块的介绍，我们都以pipeline方案来进行介绍

Search：query改写

query改写模型，是一个seq2seq的文本生成模型。其实和Self-Ask通过自我提问，来对问题进行拆解的本质相似。改写核心是为了解决两个问题

  • Decompose：用户的问题由多个并联、串联的内容组合而成，因此需要对问题进行拆解，得到子query。例如Self-Ask那一章的例子，提问涨幅最高的板块成交量如何？需要拆解成涨幅最高的板块+XX板块成交量

  • Rephrase：用户的问题本身不适配搜索引擎，需要改写成更加简洁，关键词更明确的搜素query。例如"微软的new bing上线了，使用体验如何？"可以改写为"new bing使用体验"

以下为webcpm微调得到的query生成模型的效果，webcpm提供了这部分训练数据，包括一个query和改写得到的多个query

img

Retriever：摘要抽取

Retriever负责从网页正文中，抽取和Query相关的内容，也就是一个阅读理解/抽取式摘要问题。这样就不需要依赖搜索API直接提供的snippet摘要，可以针对你的场景来设计抽取的长度，以及是整段抽取，还是抽取多个段落组合。

为了降低推理延时，webcpm通过decoder实现了类似span抽取的方案，解码器只解码应当抽取的段落的第一个字和最后一个字。例如

Query = 麦田怪圈是什么？

Content= 麦田怪圈（Crop Circle），是指在麦田或其它田地上，通过某种未知力量（大多数怪圈是人类所为）把农作物压平而产生出来的几何图案。这个神秘现象有时被人们称之为“Crop Formation”。麦田怪圈的出现给了对支持外星人存在论的人们多种看法。

假设应该抽取段落中的第一句话

Fact=麦田怪圈（Crop Circle），是指在麦田或其它田地上，通过某种未知力量（大多数怪圈是人类所为）把农作物压平而产生出来的几何图案

则模型的解码器输出的结果是起始字符：麦-结束字符：案，如果首尾两字能匹配到多端文本，则取最长能匹配到的文本段落。刨了刨代码，发现pipeline和interactive在摘要部分的样本构建方式不同，只有以下互动式的样本构建中采用了以上类span抽取的方案

abstract = "起始字符：" + self.tokenizer.decode(decoded_abstract[: num_start_end_tokens]) + "-结束字符：" + self.tokenizer.decode(decoded_abstract[-num_start_end_tokens: ])

Synthesis：信息聚合

Synthesis负责整合以上search+Retriever得到的多个Fact，拼接作为上文，通过人工标注的答案，来让模型学习如何基于多段事实生成一致，流畅，基于上文内容的长回答。

为了解决模型本身在自动检索过程中会收集到无关信息，而[1]中提到，无关的上文输入会影响推理结果的问题。Webcpm在构建基于多段上文的QA问答指令集时，在人工收集的每个query对应的多个摘要fact的基础上，会从其他样本中随机采样同等量级的无关上文，和原始的事实进行shuffle之后，拼接作为输入，来进行Query+content -> Answer的模型微调。让模型学会区分相关事实和无关事实，并在推理时不去关注无关的信息输入。

同时论文对比了加入无关Fact，和只使用相关Fact微调后的模型效果差异，如下。只使用相关内容的Baseline模型的偏好率18%显著低于，加入随机无关内容微调后的43.7%。因此加入无关上文训练，确实可以提升模型对噪声上文的判别能力。

img

 在线教程

有需要的小伙伴，可以点击下方链接免费领取或者V扫描下方二维码免费领取 本文内容由网友自发贡献，转载请注明出处：https://www.wpsshop.cn/w/IT小白/article/detail/812684

推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。