本文作者:Tyler Glaiel;编译:Cointime Freya
自从ChatGPT问世以来,我看到很多人都在发帖讨论其编写代码的能力。人们已经发布了如何让ChatGPT设计和实现数字益智游戏(没有意识到它“发明”的游戏已经存在),以及如何让它克隆乒乓球,我甚至会用它来编写一些简单的python实用程序脚本。ChatGPT是一款的功能非常强大的实用工具。
但是,人们发布的所有这些示例都有一个共同点,那就是,它们都是以前已经解决过的问题,或是对那些问题进行了极其微小的修改。实际上,大部分编程就是将现有的解决方案合并在一起,并将现有的代码适合于特定用例。编程的“困难”部分在于解决以前从未解决过的问题。
所以我决定用几年前解决过的一个难度较大的“算法”问题来测试它。这是一个小型且独立的“算法”问题,我可以将这个问题放入ChatGPT的提示中,但我觉得它很难解决这个问题。
问题
让我们从描述实际用例问题开始。在Mewgenics中,移动能力通过使用寻路功能,将猫从起点带到目的地。
猫有一个最大的移动范围数据(在本示例中为6),砖块有一个成本(在本示例中,基本砖块为1,阻挡障碍物为9,999)。我们也有需要花费2美元才能通过的水砖。
到目前为止,对于基于网格的寻路功能来说,我所描述的问题并没有什么不同寻常之处。Dijkstra算法和A*算法都可以轻松处理具有不同成本的砖块,并且在一定距离后切断路径,处理最大移动范围是很简单的。
当我们在组合中添加火时(以及其他危险类型的图块),问题就变得复杂了。火焰不像水砖那样需要额外的寻路,但是猫真的想要避免穿过火焰。这里显示的是这个问题的解决方案。但还有存在很多更复杂的情况。如果有很多火焰,它应该尽可能少地穿过砖块,诸如此类。
现在,我们暂时无法完全弄清楚为什么说这是一个难题。或者至少,为什么解决方案要比简单的A*算法更复杂。因为它采用修改后的启发式算法,将“期望成本”视为火焰。这个问题与标准的A*算法寻路功能有着细微差别,虽然解决方案非常接近A*算法,但有一些非直观的变化,这是一个“难题”。早在2020年,当我第一次在游戏中添加砖块时,这个寻路功能就花了几天时间才得到真正解决。主要的复杂因素是“最大移动范围”的限制因素,以及它如何与穿过砖块的路径成本以及用于避免危险砖块的“期望成本”相互作用。通过以下动图可以发现,当你试图越过火焰时,路径会发生变化,并且你无法在6个移动范围内绕过火焰,所以你必须穿过它。
除了简单的情况之外,还有很多复杂的情况:
(14个总移动与10个相同级别的总移动)
在A*算法和Dijkstras算法中,有一种内置假设,即如果从A到C的最短路径经过砖块B,那么它也需要从A到B的最短路径。如果你已经找到了到B的最短路径,那么你可以从那里开始并继续到C。这些算法是高效的,因为你可以跳过那些你已经找到的更短路径的砖块。而在最后重建路径时,你可以依靠这一点,让每个砖块都存储在寻路算法中到达的砖块。
上述情况不会发生在“标准”寻路功能中!从A到B的最佳路径与从A到C的最佳路径不同,尽管从A到C的路径包含了砖块B。这使事情变得更加复杂,并打破了现有寻路所依赖的一些假设。
我的解决方法
那么,它是A*算法或Dijkstra算法的修改成本和启发式方法吗?并不完全是。你可以在下图中看到它的代码(以及一些用于最小化路径弯曲的额外内容)。你会注意到,它并不完全是A*算法或Dijkstra算法,并且其中还有很多内容还不够明显。事实上,这些代码是我在2020年所写的,我已经把它从我的脑海中清除了。为了使它发挥作用,我进行了大量的试验与调整,并对算法进行了少量的修改。在准备这篇博文时,我反复检查,试图重新运行它,并且再次修改A*算法,但每一次简化它的更改都会增加一堆寻路的错误。
为什么路径存储被添加到优先级队列的单元格中,而不是像A*的标准方式那样,节点存储是从哪个节点到达的?为什么它会在从队列中弹出时而不是推入队列时,检查路径是否为最佳路径?这两点都是对A*算法的巨大偏离,但显然这对于它的工作来说是绝对必要的。
让我们看看ChatGPT的表现如何
这是本文的重点——实际的实验。
GPT-4(通过ChatGPT Plus)能否真正解决这个问题?
我们可以在代码中编写一个函数来解决以下问题:
代理需要在10x10瓦的网格上找到从当前位置到目标位置的最佳路径。
他们的移动范围有限,只有5点。
穿过普通砖块的移动费用为1点,穿过水砖则需要2点。
穿过火焰的移动费用为1点,但玩家应该避免穿过火焰,即使这意味着要走更长的路才能到达目的地(前提是该路径仍然在其有限的移动范围内)。
出于实验目的,我明确地省略了算法的细节,而是给出了需要解决的“问题”的描述。实际上,我很好奇我是否错过了一个更明显或更琐碎的解决方案,所以我宁愿不用实现细节来污染它的思路。我也没有说要用什么语言编写代码,因为我认为如果它选择python而不是要求它编写C++,也许效果会更好。毕竟我只关心实际的算法。
ChatGPT回应说:
你可以使用A*寻路算法来寻找考虑成本和约束条件的最佳路径。这里有一个Python函数可以解决这个问题:
这就像,它“有点”理解这个问题,尽管它没有“避免”穿过火焰,而是永远不会穿过火焰。
所以我会问:
此代码拒绝穿过火焰,如果为了在其移动范围内到达目的地,那么它仍然应该穿过火焰。
然后它修复了a_star_search函数,如下所示:
它没有区分穿过火焰的惩罚成本和穿越砖块的物理成本,所以它仍然不会穿过火焰(因为+1,000的惩罚使火焰砖块远远超出了你的移动范围)。
总之,我又来回折腾了几次,让它生成了一个测试用例,并修复了一个在我实际尝试运行时出现的运行时错误。在此基础上,并将测试用例定制为一个简单的、但会失败的东西。它在测试用例中混淆了x和y,所以我需要处理这个问题(它重新生成的速度非常慢)。
在给定的测试用例中,由于它是在火焰上结束,所以它只是忽略了曾经试图避开火焰的尝试。
我要求它修复它,它给了我一个解决方案,然后又回到了根本无法通过火焰进行寻路的状态。
我要求它解决这个问题,但是它又回到了原来的状态。
在经历了类似的几次反复之后,我决定保持现状。它似乎理解了问题的所在,但它实际上却不能妥善解决这个问题。
这对2020年时的我有帮助吗?也许没有帮助。我试图采用它的解决方案,并思考把它调整为真正有效的东西,但它的路径并不完全正确,所以我无法挽救它。同样地,从基本的A*算法到实际解决方案的修改并不明显,所以从“它只是A*算法”的基础开始,其实并不能帮助。此外,GPT甚至没有真正意识到这个问题其实比“修改A*算法”更困难,在我最初编写这个算法时,这一见解本可以节省我的时间。
无论如何,也许这不是一个适用于GPT的问题。毕竟,A*算法是一种非常常见的算法,在它的训练数据中肯定有成千上万个示例,无论你如何尝试推动它并提供帮助,它都可能会受到限制,但不会偏离太远。
其他尝试
我用我编写的其他几个“困难的”算法再次尝试了这一点,而且几乎每次都是同样的事情。它往往只是针对类似的问题提出解决方案,而忽略了不同问题的细微之处,经过几次修改后,它往往会崩溃。
在这个示例中(这是Mew解决Knockback的方式),它只是忽略了所有问题细节,比如它需要阻止两个移动的物体同时移动。这个问题特别糟糕,因为当我问到GPT-3.5而非GPT-4时,GPT-3.5比GPT4更接近于真正的解决方案。
但其实根本不接近,甚至还差得很远。当我向GPT-3.5发出提问时,它得到了更接近的结果。这实际上是一个可行的解决方案,但存在一些错误和“边缘情况”。它无法处理物体在链条中相互移动的循环,但相比GPT-4无法给出解决方案来说,该方案似乎更为合适。
与此类问题相似的问题可能会出现在其训练集中。
它很难想出真正独特的问题,因为它以前从来没有见过类似的问题。让我们尝试一个奇怪的构造示例。我们可以让它在新月形状之间创建一个碰撞检测算法。(我无法快速地从谷歌中找到一个算法,而且它似乎并不简单,所以让我们试试这个方法。)
然后对算法进行编程。ChatGPT的用途在于,如果你试着去思考它,你会很难发现它为什么是错误的。但要找到一个相反的例子并不难。
我要求它再试一次。但依旧是同样的结果,实际上,它很难找到相反的例子,但这里有一个失败的例子(外圆碰撞,每个内圆与另一个外圆碰撞,但彼此不碰撞,而月牙却没有碰撞)。
我认为ChatGPT是在胡说八道。它没有答案,也不知道答案,所以此时它只是在胡编乱造。你可以很容易地在一本书中发布该算法,并让人们误以为他们在碰撞检测中出现了错误。因为它确实“听起来”像是一个能够解决这个问题的算法。
那么,GPT-4真的能够编程吗?
如果给定一个算法的描述或一个已知问题的描述,或是网络上大量的现有示例,那么GPT-4绝对可以进行编程。它主要是重新组合它所了解到的内容,但公平地说,许多编程都是这样。
然而,它无法“解决实际问题”。你在编程时可能遇到的以前从未解决过的新问题。此外,它喜欢“猜测”,如果这些猜测把你引向错误的解决问题的道路,那么这些猜测可能会浪费很多时间。
“新月型”的例子就很糟糕了。ChatGPT不知道答案,因为它的训练集里没有这类示例,它在其模型中也无法找到这类示例。有效的做法是直接说“我不知道有什么算法可以做到这一点”。但相反,它对自己的能力过于自信,并且它只会胡编乱造。它在很多其他领域也有同样的问题,尽管它在编写简单代码方面的奇怪能力掩盖了这一事实。
*本文由CoinTime整理编译,转载请注明来源。
所有评论