MIT学者独家撰文：ChatGPT的瓶颈与解药( 三 ) _ChatGPT

遗憾的是， ChatGPT 的用户很难验证答案的正确性。事实上，重复问最新的（2023 年 11 月 13 日）、搜索引擎加持的 GPT-4 同样的问题，它还会生成各种不同的回答:

回答 a：“奥密克戎变异 – 占用了高达 30.4% 的 ICU 病床。”
回答 b：“虽然感染了德尔塔变异的病人最多占用了 31% 的 ICU 病床，但奥密克戎病人占用了更多。”
回答 c：“好像不是奥密克戎变异，好像是德尔塔变异。”

虽然在不同尝试中 GPT-4 的回答自相矛盾，但是每一次回答生成的文本看起来都很正式、客观、有说服力、甚至附带搜索引擎给出的参考文献。未经多次验证答案的读者很容易受到误导。
语言模型的这种能力非常适合于创作和想象：给一个标题，写三个小故事之类的任务对于 ChatGPT 而言恰到好处。但遗憾的是，这种不可控的行为模式，在回答需要严谨推理的问题时应该被尽量避免。
更遗憾的是，虽然给了 GPT-4 多次尝试的机会甚至搜索引擎的加持，上述新老 GPT-4 猜测的答案中没有一个是正确的。
根据权威统计机构数据看世界（Our World in Data）信息，美国因新冠病毒导致的 ICU 病床日占用量峰值应发生在 2020 年冬天阿尔法变异流行期间。GPT-4 基于必应搜索引擎提供的大量“比较德尔塔与奥密克戎变种病毒”的文章得出“德尔塔或奥密克戎变异造成了最高的 ICU 病床占用量”是不准确的。

文章插图
那么，GPT-4 在知识、推理、计算的哪一步出现了错误？是搜索的数据出了问题，还是对于三个峰值比较大小的运算出了问题？用户并不了解。
在上述例子中， GPT-4 的可解释性和可靠性都会受到质疑。为了改进语言模型的事实性、可解释性、可控性和可靠性，OpenAI、Meta、麻省理工学院、香港中文大学（CUHK）、卡耐基梅隆大学、滑铁卢大学等机构的研究人员分别提出了不同的基于编程语言以及程序解释器增强的技术方案。
其中，比较广为人知的方案是 OpenAI 开发的 ChatGPT 代码解释器和 Meta 提出的 Toolformer 模型。它们在文本生成的过程中将一部分内容“外包”给程序或 API，例如数学运算。
代码解释器或者可靠 API 能够保证在输入正确的情况下永远计算出一致、正确的结果，并将结果返回到语言模型生成的内容里，比如：

文章插图
最后的总分是由一段 Python/ target=_blank class=infotextkey>Python 代码计算得到：

文章插图
虽然“外包”了一部分推理任务给可靠的代码解释器，ChatGPT 的主干仍然是自然语言。上述例子只在最后一步计算总分时调用了代码解释器，而步骤 3 中 “30 分” 的中间结果仍然是由自然语言完成的推理。
最新的研究表明，在很多任务上 ChatGPT 负责调用代码解释器的数据分析(Data Analysis) Agent 仍不能取得准确的推理效果。比如，它拒绝用代码解决一些非结构化问题中的结构化推理任务，因此得到错误的结果：

文章插图
在这个例子中，我们的问题是“有几位联合国秘书长不是来自欧洲？”虽然使用了 ChatGPT 的数据分析 agent，但它拒绝使用代码分析，而是使用自然语言“敷衍了事” 。这也就造成了，虽然 GPT-4 生成了正确的人物列表及国籍，最后的计数却漏了来自亚洲的潘基文秘书长。
这里正确答案应为 5 位联合国秘书长来自欧洲，而 ChatGPT 数据分析 Agent 偷工减料推理得到的结果是 4 位。
03 NLEP方案：符号主义AI的极致尝试
NLEP 是一种同时提高自然语言、符号推理能力的神经符号 (neuro-symbolic) 方法。
针对 ChatGPT 代码解释器的种种痛点，麻省理工学院（MIT）和香港中文大学（CUHK）的研究人员提出了一个大胆的假设：“哪里有自然语言，哪里就有不严谨的思维。”
基于这种假设，我们提出了一种独特的语言生成方案：natural language embedded program (NLEP ，自然语言嵌入式程序) 。
OpenAI 采取了“文本补全+代码解释器插件”的范式，在自然语言中必要处添加代码和插件的调用。NLEP 则通过生成可一键运行的程序解决一切自然语言、数学、符号推理、编程问题，只在程序中必要的地方嵌入自然语言。