来源：转载自OneFlow，杨婷、徐佳渝翻译

除了OpenAI，外界可能很少有人知道ChatGPT模型成功的真正原因，实际上，OpenAI也会对ChatGPT拥有的巨大影响力感到不可思议。这种困惑和惊喜就像工程师们解bug时获得的意外成功：We don't know why, but it works.

一种普遍的看法是，ChatGPT没有任何革命性技术，正如Meta 首席AI科学家Yann LeCun所说，“只是一些巧妙的技术组合而已”。当然，听到这话的围观群众不免调侃LeCun这种同行评议是“吃不到葡萄说葡萄酸”，不过，从ChatGPT的缔造者们后续的表态来看，恐怕也不会否认他的“酸话”。

早在2022年1月，OpenAI发布了另一款GPT-3.5微调版本【【微信】】，这是ChatGPT的“兄弟模型”，如果用标准基准来评估它们的原始技术能力，两个模型之间并没有实质性不同。根据OpenAI科学家们的说法，ChatGPT用的微调方法稍有不同，并且添加了一些对话数据，这让ChatGPT更易上手和易用，由此产生了很大的正面影响。

新增的对话数据固然重要，不过，让ChatGPT更容易推断出用户的意图，产生质变的根本原因是已在【【微信】】使用的“人类反馈的强化学习（RLHF）”技术，OpenAI联合创始人、研究科学家John Schulman认为，RLHF才是ChatGPT的秘密武器（secret sauce）。

简单来说，强化学习是让研究者像训练狗一样训练AI智能体，并为其做出的正确响应提供奖励，而RLHF的基本思路是，教会大型语言模型学习人类用户真正喜欢的回答偏好来进一步调整模型的响应。

RLHF技术背后的其中一个作者正是John Schulman，很多人不知道的是，他也是ChatGPT项目的主要负责人。

作为强化大学大牛，John在这一领域作出过许多重大贡献，例如发明了TRPO算法（信赖域策略优化，Trust Region Policy Optimization）、GAE（广义优势估计，Generalized Ad【【微信】】）以及TRPO的后代近端策略优化（ Proximal Policy Optimization），也称PPO算法。值得一提的是，其博士导师是强化学习领域的开拓者Pieter Abbeel，并且也在OpenAI创立初期工作过一段时间。

在ChatGPT发布前一个月，John Schulman在Robin Ranjit Singh Chauhan主持的TalkRL播客节目中，详细介绍了RLHF想法的产生源头，【【微信】】以WebGPT的主要思想，并阐述了AI对齐以及对AGI实现的看法。从中，我们也可以看到ChatGPT技术演进的脉络和不曾在论文中被描述的细节，以及OpenAI团队的下一步研究方向。

1

为什么要关注RLHF

【【淘密令】】：作为深度强化学习的早期开拓者之一，你为什么去关注“人类反馈的强化学习（RLHF）”？

John Schulman：GPT-3训练完成后，它的智能程度让我十分吃惊。我意识到AI领域的下一个前沿在于真正发挥语言模型的作用。我仍然对RL非常感兴趣，但解决RL基准测试并不是我们的最终目的。

要使用RL算法，必须通过奖励函数，但是奖励函数从何而来？在RL基准测试中，我们可以自己编写奖励函数，但这种方法必须要在模拟环境（simulator en【【微信】】）中才行得通。所以在现实世界用例中，我们必须要人工监督AI的行为，以分辨好坏。所以如何定义奖励是一件极具挑战性且至关重要的问题，尤其是在任务评估难度逐渐加深的情况下。

另一方面，虽然现在语言模型非常聪明，但却难以将它们用在有价值的事情上。因为它们不会按照我们的意愿去工作，只是在单纯地模仿训练语料库，但这也说明只要给语言模型一个正确的目标，它们就很有可能改进上述问题，也就是说，我们可以在语言模型中应用强化学习，使用人类反馈去定义奖励。

【【淘密令】】：相比合成奖励（synthetic reward），人工反馈是否更难，或者说这两者之间在一定程度上大有不同？

John Schulman：使用人工反馈会遇到很多新问题。现在，我们必须要动态收集数据集，所以要花很多时间去建立人类偏好的数据集，相比各种算法细节，数据集的质量更加重要。另外我们还要考虑如何将任务分配给人工训练师等问题，如果有程序化的奖励函数，这些问题我们本不用考虑。

【【淘密令】】：人工评分员之间的差异或奖励信号的噪音是否会造成问题？

John Schulman：实际上，噪音并不是我最担心的问题，比较而言，我更担心人们的惯有偏见。例如，在问题回答或模型编写文本等设置中，人们通常更偏向于较长的答案，这会导致模型给出的答案日渐冗长。所以我们要注意指导人工评分员，让他们奖励简洁的答案，如果对这一问题不加注意，可能会激励模型的错误行为。

2

用RLHF实现指令跟随模型【【微信】】

Robin?Chauhan：2022年3月，你与Long Ouyang、Jeff Wu等人发表了论文《Training language models to follow instructions with human feedback》，你能简要介绍下【【微信】】的主要思想吗？

John Schulman：【【微信】】是一种经过微调以遵循指令的语言模型。OpenAI的官网上有一个大文本框，在文本框中输入内容后点击提交就可以完成一个指令。语言模型非常有用，只需输入提示词就可以使其来完成自己想做的事情。

比如你可以先在文本框中输入问答示例，然后你提出另外一个问题，【【微信】】就可以相同的方式予以回答，人们可以让语言模型通过提示来做一些很棒的事情。但“提示”本身也是一门艺术，很难做到准确无误，模型也不一定能完美识别提示的内涵。如果你只是采用原始模型与之对话，那么你得到的答案可能就有点不尽如人意了。

通过【【微信】】，我们发现要对语言模型进行一些小的改动，就可以使它们更容易使用。具体来说，我们要对它们进行训练，以便当你的一段文本包含指令时，模型可以尽力按照指令进行操作。几乎任何东西都可以作为指令。例如，指令可以是继续聊天，对这段文本进行总结，或者是提供一份销售某个小部件公司的名单。

这就是指令跟随模型（instruction following model），可以执行任何你给定的指令。不过我并不是这项工作的核心贡献者，我主要参与了强化学习基础设施和完成强化学习的训练细节。

在这个项目中我们所做的就是：在指令跟随设置中运行了RLHF中的整套方法论。所以我们进行了有监督微调（【【微信】】），收集偏好数据，训练了一个奖励模型（reward model），然后根据该奖励模型进行了强化学习。

在训练之初，我们使用的数据是由外包商收集的。但后来我们有了API和官网上的Playground（一个大文本框，可以在其中使用模型），我们就使用在Playground中收集到的指令来进行训练（用户在使用之时就会收到提示：你的指令可能会用于训练）。这样既可以收集偏好数据，又可以进行强化学习。同时需要注意：训练时不能存储prompt中的任何信息。我们有一套相当复杂的流程来确保没有私人信息泄露到模型中。

结果表明，这种方法非常有效。原始的语言模型通常很难按照指令执行。但是，通过强化学习训练后的指令跟随模型要好得多。如果仅从改进程度来看，那么几乎能媲美比这大100倍的模型。这是相当大的一个进步。

Robin?Chauhan：看来你想要得到可信任的模型，这是你的标准之一吗？

John Schulman：对于一个大型语言模型来说，真实性是重要标准之一。但是，这个模型是如何通过示例学习真实性的？难道真实性在模型内部被表示了吗？因为模型没有外部参考来确认某些东西是真实的还是虚假的，那么它如何知道什么是真实的？

某种程度上，模型内部是有真实性表示的。我们可以将语言模型看作是对整个互联网的模仿，而互联网是由许多不同的人编写的，包含各种类型的内容，从小说到非小说，到技术文献、笑话以及论坛帖子等。因此，该模型实际上是由所有这些编写内容的人组成的“合奏团”。

当我们输入一个prompt时，模型在内部必须要做的就是确定prompt是由谁编写的，并试图以该风格继续生成文本。比如，如果它认为正在阅读的内容是华尔街交易论坛上的东西，那么就继续以这种风格生成文本。但是如果它认为正在阅读纽约时报的内容，它又会以不同的方式写作。

因此，模型必须在某个地方进行计算，例如计算当前的风格是什么，或者正在模仿哪种较为小众的风格集合。至少，在进行监督微调或完全基于人类反馈的训练时，我们可以缩小模型生成的文本风格范围，尝试模仿训练集中最好的人或最好的风格。

当然，“最好”会有很大的差异，最终得到的内容将取决于我们的指令。如果我们要求模型生成内容时不要太过于有争议，又要“企业化（corporate）”一点，那么生成的内容也就是这样。因此，我们至少可以将模型限定到一个特定的风格，而不是互联网上所有的风格。

但我认为，这里面可能还有更多的内容。模型不仅仅是在学习文本风格，模型内部可能还在试图确定一些语句是否正确。当然，我上面所说的是关于原始预训练模型。我认为“预测下一个token”的目标会为我们提供很多信息，这将迫使模型确定语句是否正确。

对于强化学习微调而言，我认为还会赋予模型更多的潜力去生成可信任的东西，而不是仅仅模仿某种风格，但现在还很难确定模型是否在这样做。现在还是prompt在引导着模型去获取互联网上那些我们想要的东西，模仿我们想模仿的内容。而我们想使【【微信】】更多地关注互联网上那些更可信任的东西。

3

语言模型的泛化能力

Robin?Chauhan：无论如何，我们应该模仿出互联网上最真实的一面。你能否谈一下泛化，以及这种模型在分布外（out of distribution）的表现如何？

John Schulman：总的来说，语言模型整体上具有惊人的泛化能力。我认为，像这些在互联网上受过多元化数据训练的预训练模型，它们通常泛化得相当好。至少对于那些在机器学习早期就接触过这些技术的人来说，这很令人惊讶。例如，即使是用其他语言，甚至是一种相对罕见的语言提供指令，模型通常也能够很好地遵循，即使整个训练过程中没有任何数据是用该语言编写的指令。这就是从预训练中延续下来的能力。

这实际是一个关于奖励模型的问题，举个例子：如果问题有点不同于它所接受的训练，比如在奖励模型的训练数据中稍微偏离一点，那么会发生什么呢？

我认为，RLHF的一个棘手问题是：对奖励模型进行训练时，也就是在训练policy以获得高奖励，意味着这会利用奖励模型中的错误。它最终会找到针对奖励模型的对抗示例，但这比正常的分布外行为（out of distribution behavior）更糟糕。因此，在将奖励模型尽可能地泛化到训练集之外确实存在一些挑战。

当这些类型的Agent遇到某些难题时会提醒它不知道吗？我认为，如果你问一个模型知识核心的问题，它会知道答案，而且它也知道自己知道答案（这里指的是Instruct类的模型）。但如果你问它关于其知识边缘的问题，那可能回答起来会有困难，必然会出现不准确的情况。有几篇论文还讨论过这个问题，比如Anthropic发表的Language Models, mostly know what they know，OpenAI发表的Teaching Models to Express Their Uncertainty in Words。这些语言模型以及机器学习中许多其他模型都是为了最大化可能性而进行训练的。

鉴于已经训练过Agent始终预测输出的分布（distribution of outputs），因此，对于语言模型，只要给定前缀，它就会预测下一个token的分布，而且通常预测的相当准确。如果它在预测某项任务有80%的概率，而且每次都是80%，那么它的正确率就为80%。

这只是训练目标的结果。训练目标鼓励对模型进行校准，这是因为模型校准可以提高不确定性估计的准确性。

因此，对于单个token级别，模型肯定经过校准。问题是，模型校准是否准确？校准后的模型是否能应用于多个token输出的情境中？又或是它们是否可以判断多个token语句的正确性？

因为模型通过单个token级别进行校准，所以我认为它们在不同环境中需要校准的信息确实不同。这就是我认为模型不难准确表达出校准信息的原因，或者至少让模型像人一样很好地表达不确定信息，这个问题也并非无法解决，但在实践中，需要解决一些实际的困难。

4

AI对齐工作进入第二阶段

【【淘密令】】：人们对于“AI对齐（ AI alignment）”有不同的理解方式，你如何看待RLHF方面的对齐工作？

John Schulman：在我看来，AI对齐的主要目标是让模型通过训练知道人类的意图，并在执行任务时做出符合人类期望的行为。因此，我们需要分辨模型的能力。例如，当我们给一个原始语言模型提出一个问题时，它可能并不知道我们希望它给出一个完美的答案。相反，它可能会假设我们只是希望得到一个符合语法和语义规则的回答。

【【淘密令】】：OpenAI的一篇博客讨论了对齐序列（se【【微信】】），一共包括三个阶段：第一阶段是使用人类反馈训练AI系统，第二阶段是训练AI系统协助人类反馈，第三阶段是训练AI系统进行对齐研究。所以你目前的工作主要是使用人类反馈训练AI系统，那何时以及如何才能进入其他阶段？

John Schulman：我现在正在做第二阶段的工作，即训练AI系统以协助人类反馈。当我们开始尝试让系统解决更具挑战性的问题时，第二阶段的工作就变得越来越重要。当模型的性能远低于人类水平或在某些任务上达到人类水平时，监督它们非常容易。但是，当模型处理的任务非常困难，需要大量不同的技术知识时，就很难提供有效的监督信号。

为了解决这个问题，我们可以采取一些措施，比如利用两个模型：针对某个问题，一个模型给出相应的答案，然后另一个模型对该答案提出批评意见，指出不足之处。这样，人们在看完批评意见后，就只需要判断答案是否正确，批评有助于人类更准确地评估答案。这一想法十分重要，我和同事们正在探索。此外，OpenAI也正在做一些工作来协助对齐研究，不过完成这项工作任重而道远。

【【淘密令】】：Stuart Russell是OpenAI博士委员会的成员之一，我非常喜欢他的《人类兼容性（Human Compatible）》一书。他指出，标准强化学习框架通常是基于固定奖励信号的，而这种框架存在一定的问题。针对该问题，我们需要培养强大的Agent，使其尝试做我们想做的事情，同时对我们的意图保持一种怀疑态度，因为确定的Agent会存在一定问题。你如何看待这一观点？

John Schulman：我完全赞同Stuart Russell的观点。首先，编写一个简单的奖励函数来捕捉我们的意图是非常困难的。我们希望Agent能够理解我们的意图，并以最好的方式来实现这些意图，而不是盲目地追求某些极端的结果。

在构建Agent时，我们应该确保它们保持一种怀疑态度，以便更好地理解我们的意图和目标。这也可以帮助Agent更加谨慎地采取行动，以确保它们在实现目标的同时也考虑到其他重要的因素。

Stuart Russell提出了一个很好的问题定义，即让AI与人类共同玩一个游戏，该游戏的目标是让AI尝试理解人类的意图，并采取行动尝试满足这一意图，同时保持一定的怀疑态度。

我认为，如果我们开始思考如何将Russell所描述的目标应用到实践中，就会发现实际上这与OpenAI以及其他组织正在进行的RLHF研究非常相似。我们正在努力实现这一目标。

5

WebGPT的想法从何而来

【【淘密令】】：2021年，你和Nakano等人共同发表论文《WebGPT：基于人类反馈的浏览器辅助问答》，能解释下WebGPT主要想解决的问题吗？

John Schulman：在WebGPT中，我们将语言模型与网络浏览器相连，以便从网络中检索信息。这些语言模型可以通过总结网络上的相关信息来写答案，这样一来，如果你对时事热点提问，或者询问一些需要详细科学或技术知识的问题，AI就可以在网络上查找答案，并详细引用其来源。

在文中，我们主要探讨了两个问题。首先，我们曾试图将语言模型变成一种Agent，人们在网络上编写了很多不同类型的文本数据，但关于如何实际执行多步骤过程的数据却很少，因此，我们不确定语言模型是否可以实际执行某些迭代过程，我们有很多数据，但这些数据基本上都和写论文、聊天等相关，这是我们在论文中探讨的第一个问题。

对于这个问题，我认为答案是肯定的。在这种情况下，我们可以让Agent使用我们提供的工具，比如说搜索、滚动、单击链接等浏览命令。

其次，我们还探讨了信息的真实性问题，这是语言模型面临的一大难题。虽然语言模型掌握着海量知识，但如果我们向模型中输入错误的提示

chatgpt能回答专业领域的问题吗 chatgpt开放api后怎么用

chatgpt,chatgpt怎么下载,chatgpt国内能用吗,chatgpt怎么读

作者单位：东南大学 知识科学与工程实验室

论文地址：

https://arxiv.org/abs/2303.07992

【【微信】】是一种强大的大型语言模型（LLM），在自然语言理解方面取得了显著进展。然而，该模型的性能和限制仍需要广泛评估。由于【【微信】】覆盖了Wikipedia等资源并支持自然语言问答，因此它已引起关注，作为传统基于知识的问答（KBQA）模型的潜在替代品。

复杂问答是KBQA的一个具有挑战性的任务，它全面测试了模型在语*析和推理方面的能力。为了评估【【微信】】作为问答系统（QAS）利用其自身知识的表现，我们提出了一个框架，评估其回答复杂问题的能力。我们的方法涉及将复杂问题的潜在特征分类，并使用多个标签描述每个测试问题，以识别组合推理。

按照Ribeiro等人[1]提出的CheckList的黑盒测试规范，我们开发了一种评估方法，以衡量【【微信】】在推理回答复杂问题方面的功能和可靠性。我们使用所提出的框架评估【【微信】】在8个【【微信】】数据集上的问答表现，包括6个英文和2个多语言数据集，共约190,000个测试案例。我们比较了【【微信】】、GPT3.5、GPT3和FLAN-T5的评估结果，以挖掘LLMs长期存在的历史问题。我们收集的数据集和代码公开在：

【【微信】】 在人机交互测试中展现了强大的自然语言理解能力。研究者对这种大型语言模型在现有自然语言处理任务中的表现和局限性很感兴趣。Petroni等人[2]的研究表明，语言模型可以被视为知识库（KB），以支持下游任务。作为一个大型语言模型，【【微信】】通过利用自身的知识展现出强大的问答能力。因此，考虑到其对维基百科的广泛覆盖和卓越的自然语言理解能力，【【微信】】是否能够取代传统的KBQA模型已成为一个热门话题。

在各种类型的KBQA任务中，复杂问答（基于知识库的复杂问答，【【微信】】）是一个具有挑战性的任务，要求问答模型具有组合推理的能力，以回答需要多跳推理、属性比较、集合操作和其他复杂推理的问题。我们认为，评估【【微信】】利用自身知识回答复杂问题的能力可以帮助我们回答【【微信】】是否能够取代传统的KBQA模型的问题。此评估从两个方面评估【【微信】】：1）分析其对于复杂问题的语*析能力；2）测试其通过组合推理过程使用自身知识回答问题的可靠性。

经过对【【微信】】相关论文的仔细审查，我们发现许多评估工作，Omar等人[3]在手动评估了约200个测试用例后指出，与传统的KBQA模型相比，【【微信】】的稳定性较低。Bang等人[4]分析了30个样本后指出，【【微信】】是一个懒惰的推理器，在归纳推理面表现很差。

现有的工作通常依靠小规模采样测试和人工评估相结合的方法来完成对【【微信】】性能的评估，因为API的限制和通过Exact Match (EM)评估生成答案的困难。因此，往往得到的是粗略的和经验性的发现，而不是可量化的结果。因此，需要进一步的验证以确保这些结论的普适性。

在这项工作中，我们利用【【微信】】自身的知识作为知识库，在基于知识的问答（CQA）方面对其进行全面评估，并将其优点和限制与其他类似的大型语言模型（LLMs）和现有的基于知识的问答（KBQA）模型进行比较。我们的评估框架由两个主要步骤组成：首先，受HELM[21]的场景驱动评估策略的启发，我们设计了一种基于特征的多标签注释方法来标记测试问题中涉及的答案类型、推理操作和语言。这些标签不仅有助于我们逐个分析【【微信】】的推理能力，而且它们的组合也可以帮助我们发现许多【【微信】】擅长或不擅长的潜在QA场景。然后，遵循CheckList[22]的测试规范，测试目标分为三个部分：最小功能测试(MFT)、不变性测试(INV)和方向性期望测试(DIR)。第一个反映了模型执行各种推理任务的准确性，而第二个和第三个反映了推理的可靠性。为了在INV和DIR测试中获得更多可分析的结果，我们采用了Chain-of-Thought(CoT)[5]方法，设计提示模板以建立其他测试用例。

要建立这样的评估框架，需要解决两个主要的挑战。

第一：是多源数据集的统一注释。由于数据集发布时间的差异，现有的【【微信】】数据集使用了不同形式的答案，并且只提供了(问题,答案)对或其他推理路径如【【微信】】等。为了实现统一的注释，我们选择了带有【【微信】】的KBQA数据集作为这项工作的测试数据集，使用【【微信】】的关键字来识别测试问题所包括的潜在推理操作。利用测试问题文本中的句法结构和问题关键词语，我们实现了答案类型的自动识别，并且多语言数据集中的语言标签直接由数据集提供。

第二：评估任务涉及将生成式文本答案与答案短语进行匹配。【【微信】】等LLMs通常生成的是包含相关信息的文本形式的答案，而【【微信】】数据集提供的是具体的答案短语(Golden Answers)。两者之间的差距使得直接使用传统的精确匹配（EA）难以实现较高的准确度。因此，我们采用了基于短语的答案匹配策略。利用成分句法解析树[6]的方法，我们将LLMs的输出处理成一组名词短语，然后通过Wikidata获得答案短语(Golden Answers)的多语言别名集合。此外，我们还设置了短语向量相似度的阈值。当短语集合之间没有精确匹配，但有相似度高于阈值的短语对时，我们通过人工评估来补充对样本的最终判断。

最后，我们收集了6个单语英语数据集和2个多语言数据集作为本次评估实验的测试数据，规模约为19万个问题，其中包括约12,000个涵盖13种语言的多语言问题。作为对比的LLMs包括GPT3[7]、GPT3.5[8]和FLAN-T5[9]。我们还引入了所测数据集的当前SOTA作为比较，以补充【【微信】】在相关任务上与监督模型和无监督模型的表现对比。

我们的主要发现和见解如下：

1. 在单语言的问答测试中，【【微信】】的大多数表现优于类似模型，但在回答数字或基于时间的问题时表现并不是最佳的。此外，在涉及多跳或星型事实推理的问题时，其表现也不如GPT3.5 V3。在多语言测试中，【【微信】】对于回答低资源语言问题表现更为优秀。
2. 在CheckList测试中，我们发现【【微信】】在知识库问答方面存在一些限制，包括：1. MTF测试结果显示，它不擅长回答只涉及一种类型推理的问题。2. INV测试结果表明，与传统的KBQA相比，【【微信】】在处理相似或几乎相同的输入时不够稳定。3. DIR测试显示，【【微信】】并不总是对正确提示提供积极反馈。当面对修改后的测试样本时，其输出的变化并不总是符合我们的预期。
3. 使用CoT（思路链）提示来引导【【微信】】逐步回答问题是有用的，特别是在增强需要使用计数获取答案的问题的解决能力方面表现出特别的功效。

1. 大语言模型和prompt自然语言处理领域的研究表明，语言模型可以通过文本指令执行各种下游NLP任务。指示学习(Prompt Learning)和LLM的研究已经取得了显著进展，其中改进提示(Prompt)可以使LLM中包含的信息更准确地应用于目标任务。随着更强大的LLM的出现，它们显著增强的自然语言交互能力使得指示设计不再需要以任务为中心，而是通过建立一个Chain-of-Thought来引导LLM生成中间的推理步骤。同时，LLM的自然语言理解能力是指示学习的有效性的关键因素。为了改进LLM，许多工作[10,11]都致力于扩展LLM。其中，【【微信】】是目前受到最多关注的模型之一，它具有高质量的输入响应、通过对话进行自我纠正的能力以及拒绝不适当问题的能力。
2. 大语言模型的评估最近出现了许多旨在评估LLM的作品，它们使用现有的NLP数据集构建大规模基准，包括BIG-Bench、AILMHarness和SuperGLUE等大规模基准[12,13,14]，以HELM[15]等全面评估LLM在各种任务场景下表现的方法。受到这个想法的启发，本文建立了一个以特征为驱动的评估系统，以全面评估LLM面对各种复杂问题特征时的问题理解和答案生成能力。其他一些作品也通过基于人类的输入作为案例分析，评估了【【微信】】的具体能力，如数学能力和推理能力[16]。
3. NLP模型的黑盒测试

由于训练LLM的高昂成本，目前LLM的评估工作主要集中在黑盒测试上。有许多有价值的方法可以作为参考，例如用于评估鲁棒性的方法[17]、用于对抗性变化的方法[18]、关于注意力和可解释性的工作[19]等。目前最全面的方法是CheckList协议，将评估目标分为MFT、INV和DIR三个部分。在本工作中，我们遵循这个评估计划，并使用CoT提示生成INV和DIR的测试用例。

我们的评估框架由两个阶段组成。第一阶段旨在通过使用多个标签来描述测试问题，包括问题类型、组合推理类型和语言特征；第二阶段根据CheckList框架评估LLM对测试问题的每个标签的功能性、QA的鲁棒性和输出内容的可控性。接下来将详细解释这些阶段的设计，其过程如图1所示。

1. 特征驱动的多标签问题分类由于现有数据集通常使用不同的标签来识别答案类型或推理类型等，为了在评估中进行统一分析，我们需要标准化这些特征类型的标签。我们设计了三种类别的标签，包括“答案类型”、“推理类型”和“语言类型”，用于描述复杂问题中包含的特征。这些特征反映了问题中提到的主题类型、获取答案的方式和问题的语言形式。通常，这些特征对应于QA系统的子功能。每个问题通常只包含一个“答案类型”标签。基于使用命名实体识别（NER）定义事实类型的类型定义、基于英语疑问词分类的问题类型分类以及从现有KBQA数据集中归纳出答案类型，我们将答案类型设置为以下八种类型：日期/时间（DATE）、地点（LOC）、人名（PER）、原因（WHY）、是/否（Boolean）、其他事实（MISC）、数字（NUM）或无法回答（UNA）。基于KBQA数据集提供的【【微信】】查询，我们还归纳出了八个“推理类型”标签，包括集合操作（SetOperation）、条件过滤（CondFilter）、计数（COUNT）、极值/排序（Comparative）、单跳推理（Single-hop）、多跳推理（Multi-hop）和星型事实推理（Star-shape）。而“语言类型”标签则反映了用于编写问题的语言。图2展示了本文收集的数据的标签分布情况。

1. 衡量方法

通常有两种策略来评估基于知识的问答系统（KBQA）的输出：【【微信】】匹配和答案匹配。然而，【【微信】】在生成具有统一实体和关系ID的【【微信】】查询方面存在困难，使得【【微信】】匹配难以自动化。因此，在我们主要实验的QA评估部分中，我们采用了答案匹配策略。作为补充，我们在DIR部分设置了带有【【微信】】输出的测试用例，以手动评估【【微信】】识别问题中包含的推理操作的能力。

与现有的KBQA模型不同，【【微信】】在问答场景下的输出一般是一段包含了答案的文本，难以直接与数据集提供的答案做精确匹配从而得到模型的精准率。而由于采样的数据规模较小，已有的【【微信】】评估工作一般通过人工评价来计算模型的性能。因此，我们需要建立一套大部分自动化的答案评测方法。

我们采用了一个朴素的通过扩充匹配范围的思路来强化答案匹配的泛化性，具体包括以下两个操作，如图3所示：

1. 通过成分句法解析树提供的子树标签，可以提取文本答案中的所有名词短语。如图3中所示，我们按照粒度的升序（从单词到名词短语，甚至短句）获得了名词短语列表。
2. 通过利用Wikidata和WordNet，我们收集了Golden Answer的其他答案列表，包括多语言的别名和同义词。名词短语列表与答案列表之间的精确匹配显著提高了答案匹配的概括性。对于未能匹配的样本，我们基于短语向量之间的余弦相似度设置了一个阈值，以获取潜在匹配项。超过此阈值的部分随后将进行手动判断其正确性。对于具有“DATE”、“Boolean”和“NUM”类型答案的QA，我们已基于其Golden Answer的特征建立了特殊的判断程序。由于我们的度量方法本质上仍然是精确匹配，因此在实验部分，我们使用准确率（Acc）作为模型之间性能比较的指标。

1. 基于prompt的CheckList策略参照CheckList 框架的的思路，我们也设置了三个评估目标来评估【【微信】】：
1. 通过最小功能测试（MFT）评估LLM在【【微信】】场景下处理每个特征的能力；
2. 通过不变性测试（INV）评估LLM处理【【微信】】场景中各种特征的能力的稳健性；
3. 通过有向期望测试（DIR）评估LLM是否能产生符合人类期望的经过修改的输入输出，即【【微信】】的可控性。

图4中给出的一个INV和DIR的测试实例。

MFT是一组简单的示例，以及它们各自的标签，旨在验证给定能力中的特定行为。在这项工作中，我们使用标签选择仅包含单一推理类型的样本，并将它们形成MFT测试用例，以检查【【微信】】在执行基本函数（例如“多跳推理”、“计数”、“排序”等）方面的性能。表5提供了测试用例的示例。

INV是指对模型的输入施加微小的扰动，同时期望模型的输出正确性保持不变。不同的扰动函数需要针对不同的能力，例如修改命名实体识别（NER）能力中的地名或引入错别字以评估鲁棒性能力。

在本文中，我们设计了两种方法来生成INV测试用例：

1. 在测试的问题句子中随机引入拼写错误；
2. 对测试的问题生成一个语义等效的同义复述的问题。

随后，我们通过检查【【微信】】在三个输入（原始测试用例、添加拼写错误的版本和同义复述版本）时产生的输出的一致性来评估【【微信】】的不变性。

DIR是类似于INV的方法，其不同之处在于期望标签以某种方式改变。在本研究中，我们探索了三种创建DIR测试用例的方法：

1. 我们替换问题中与推理相关的短语，要求模型生成带有【【微信】】查询的答案，以观察【【微信】】的输出逻辑操作是否与我们的修改相对应。
2. 我们在输入中添加包含答案类型的提示，以检查【【微信】】是否能够根据提示控制输出答案类型。
3. 受到CoT的启发，我们使用通用的多轮提示来重写测试用例，允许【【微信】】通过“逐步”过程获取答案，以观察【【微信】】对不同类型问题的CoT提示的敏感性。

1. 数据集在这项工作中，我们将【【微信】】和对比语言模型视为带有知识库的无监督问答模型。模型接受自然语言问题作为输入，并生成包含其自身知识覆盖的答案的文本段落。鉴于【【微信】】（以及对比LLM）的训练数据广泛涵盖Wikipedia，我们采用流行的大规模、多语言、开放领域的复杂问答数据集来评估模型，这些数据集与Wikipedia相关。具体来说，我们收集了6个单语言数据集和2个多语言数据集，如下表所示：

1. 对比模型我们对比了目前主流的LLM，包括GPT3(Da【【微信】】),GPT3.5(Davinci-002,Da【【微信】】)以及开源的FLAN-T5模型(FLAN-T5-xxl).
2. 实验结果
3. 主要结果各个模型在数据集上的准确率以及SOTA的对比：我们比较了 【【微信】】 与类似 LLM 的性能，包括 FLAN-T5、GPT3.0 和 GPT3.5 变体，并评估了它们与当前最佳微调 (FT) 和零样本 (ZS) 模型的偏差.

主要实验结果见表2。结果表明，【【微信】】在7个测试数据集上显著优于其他参与的LLM，并在WQSP和【【微信】】数据集上超越当前的SOTA (Fine-tune)。然而，在其他数据集上，【【微信】】的表现仍然显著劣于传统模型的SOTA，特别是在实体丰富的测试集中，比如KQApro、【【微信】】.0和GrailQA。各个模型在不同答案类型和推理类型问题上的表现：

从答案类型的角度来看：依赖自身训练数据作为知识库的大型语言模型无法准确回答各种基于事实的问题。这在需要数值、因果和时间答案的测试集中尤为明显，所有 LLM 都表现不佳。性能对比上，【【微信】】在大部分问题类型上都优于比较模型，但是在回答答案类型为DATE和WHY的问题时，【【微信】】落后于GPT-3.5 V3。另外在涉及多跳和Star-shape的问题上，【【微信】】也没有展现出突出的优势。从推理类型的角度来看： 参与测试的 LLM 都在 COUNT 类型的问题上表现不佳，这与他们在 NUM 答案类型上的表现是一致的。综上所述，【【微信】】 在某些类型的推理方面的进步几乎是具有突破性的贡献，其在涉及集合运算和比较的问题中的显着卓越准确性 (Acc) 证明了这一点，与其他竞争对手相比，差距超过 20%。原因可能是代码训练的引入显着提高了 【【微信】】 的逻辑推理能力。[20]但是，【【微信】】 在链式多跳推理或星形事实推理方面实际上落后于 GPT-3.5 V3，造成这种现象的原因在于 【【微信】】 无法充分区分它所学的混淆实体。各个模型在各种语言精度上的对比：

多语言测试集上的实验结果表明，【【微信】】在所有语言的测试上都优于对比模型，尤其在低资源语言上的性能领先更为明显。值得注意的是，“fa”和“hi IN”等低资源语言的显著改进反映了 【【微信】】 利用资源丰富的训练数据来增强低资源模型性能的有效性。然而，中文测试中得分较低的情况让我们感到不解，我们无法确定这种情况是由于“中文资源不足”还是“资源质量不佳”造成的。

1. MFT结果我们选择仅包含单个推理标签或多个标签的测试用例相同类型（例如SetOperation+比较、SetOperation+过滤），并汇总其结果以获得MFT:

值得注意的是，与之前表3的数据做对比，可以发现SetOperation 和 Comparison 任务的性能大幅下降。这一结果表明 【【微信】】 在复合推理中的集合运算或比较中的表现优于单一推理。我们假设这是由于复合推理过程为 【【微信】】 提供了更多的中间信息，从而缩小了其搜索范围。

1. INV结果 下表显示了【【微信】】在抽样测试用例上的三次运行中的性能，评估了每种答案类型和每种推理类型。其中三次的运行结果分别代表原始问题、添加拼写错误和改写句子以后的运行结果。结果的符号解释为：C表示问题是正确回答，而W表示问题没有正确回答或者没有返回任何有用的答案。这个判断过程涉及人工监督，只有当三轮测试的输出一致时，才认为模型在其对应的功能类别中是稳定的。总体而言，这两个表显示 【【微信】】 在复杂的问答任务中表现出大约 79.0% 的可靠性。

1. DIR结果

我们设计了三种形式的定向期望测试，分别考察【【微信】】在答案类型识别、推理、CoT提示响应方面的能力。首先，对于侧重于答案类型的 DIR 测试，我们使用了一个简单的提示来告知 【【微信】】 当前问题的答案类型，期望它利用此信息将候选答案范围限制为特定类型。如图8所示，结果表明告知答案类型对于具有布尔值和 NUM 答案的问题特别有用。但是，总体而言，我们的提示对大多数问题类型都无效，甚至导致答案类型识别错误较多。

在针对推理功能的DIR测试中，我们先向【【微信】】输入一对（问题，【【微信】】查询），然后修改问题中与推理操作相关的短语，肯定变否定，否定变肯定，在同一个对话轮次中输入到【【微信】】，请求它返回相应的 【【微信】】。随后，我们将返回的 【【微信】】 与预期的 【【微信】】 进行比较。 【【微信】】 的匹配过程是手动进行的。为了评估其性能，我们进行了一项测试实验，其中包含针对四种推理类型中的每一种的二十个样本问题：集合运算、条件过滤、计数和比较。评估指标是失败率，它反映了 【【微信】】 中输出错误的比例。表 9 中显示的结果表明，在大部分情况下【【微信】】 会对我们的修改提供积极反馈，但是，将此过程用作复杂问答任务的中间步骤可能会导致严重的错误累计。

在这项研究中，我们建立了一个简单的 CoT 提示来指导 【【微信】】 在回答复杂问题之前收集与复杂问题相关的信息和概念，也就是句子当中名词。我们认为，这个过程与人类收集信息以回答问题的方式有些相似。表 10 中的结果表明，即使是最简单的 CoT 也可以对大多数类型的问题产生积极影响。特别的是，CoT 导致了 Acc在NUM 类问题的提升超过了 30%，这也体现在 【【微信】】 表现不佳的 COUNT 类问题中。

本文介绍了对【【微信】】在回答复杂问题时使用自己的知识库的性能进行大规模实验分析，与类似的大语言模型和当前最先进的模型（SOTA）进行了比较。分析突出了【【微信】】的优点、局限性和不足之处。同时，我们也使用Checklist框架对【【微信】】在处理各种答案类型和推理要求时的基本性能、稳定性和可控性进行了详细的测试和分析。我们相信这些发现将为以【【微信】】为代表的大规模语言模型的开发和下游研究提供有价值的见解和参考。

1.Ribeiro, M.T., Wu, T., Guestrin, C., Singh, S.: Beyond accuracy: Beha【【微信】】dels with checklist. In: Proceedings of the 58th Annual Meeting of the Association for Computational Linguistics. pp. 4902C4912 (2020)

2.Petroni, F., Rockt?schel, T., Riedel, S., Lewis, P., Bakhtin, A., Wu, Y., Miller, A.: Language models as knowledge bases? In: Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing and the 9th International Joint Conference on Natural Language Processing (EMNLP-IJCNLP). pp. 2463C2473 (2019)

3.Omar, R., Mangukiya, O., Kalnis, P., Mansour, E.: Chatgpt 【【微信】】stion answering for knowledge graphs: Current status and future directions towards knowledge graph chatbots. arXi【【微信】】. arXivC2302 (2023)

4.Bang, Y., Cahyawijaya, S., Lee, N., Dai, W., Su, D., Wilie, B., Lovenia, H., Ji,Z., Yu, T., Chung, W., et al.: A multitask, multilingual, multimodal e【【微信】】 reasoning, hallucination, and interactivity. arXi【【微信】】. arXivC