当前，大型的语言模型与自主评估标准存在不足，这是我们需要紧急关注的问题。这些标准无法全面涵盖软件工程师日常工作中遇到的复杂任务。AI在预判用户需求上缺乏敏锐的直觉和灵活的适应力，没有人类的帮助，它很难做到精准把握。这种情况犹如一场不平衡的竞赛，令人忧虑。
评估基准与实际脱节
现在许多评估标准都比较简单。以Devin这款实验室自主研发的AI软件工程师为例，尽管视频里展示了它掌握了不少开发技巧，但仔细观察会发现，它的任务内容就像初级开发者的教程或面试题目。比如，修复编程竞赛中算法代码库的常见错误，这在大型语言模型的训练数据集中很普遍。这说明现有的评估标准难以全面反映软件工程的真实复杂性。实际上，软件工程师需要应对的问题远比这些简单的操作要多得多。
与此同时，真正的软件工程相当复杂多变。它并不像那些简单基准测试中的任务那样直观易懂。在实际的项目中，我们可能会遇到复杂的系统和先进技术，例如云服务，这些在简单的基准测试中很难完全体现出来。这种脱节问题相当严重。
有名测试的局限性
某知名测试要求通过编写164个函数并解决相应测试问题，以此检验大型语言模型的编程能力。尽管这种测试方法具有一定的意义，但其局限性也十分明显。它未能深入探讨软件工程的复杂性，未涉及诸如修改代码库以应对实际项目任务等更为复杂的情境。反观现实中的pull请求，其任务复杂程度更高，需应对众多实际问题。
那些表现较好的模型，面对具有挑战性的测试标准时，效果并不理想。比如在SWE-bench这个测试标准中，即便提供了文件修改的具体位置，模型也只能解决其中一小部分问题。从这个例子中，我们可以明显看出，常见的测试标准与实际复杂的任务环境之间的差距有多大。
SWE – bench测试的意义
SWE-bench是一项颇具难度的测试标准。它让AI助手应对开源项目中存在的实际问题，这样的要求更贴近现实中的软件工程任务。其中涉及许多类似真实议题和pull请求中的任务，需要AI对代码有更深入的理解和互动。例如，AI需要浏览并修改代码库，以解决实际问题。
这个测试的评判标准还算公允，它考察的是代码库中问题的处理。如果修补了问题后，代码能顺利通过测试，那就算作是完成了。这样的方法与实际软件开发的流程相吻合，因为在实际工作中，保证代码修改后仍能正常运作是至关重要的。
真实任务示例
实际操作中，软件工程领域存在众多繁杂的任务案例。比如，有针对数据导入的自定义命令任务。在具体的软件项目执行中，这类任务往往涉及众多层面。它可能需要处理多个系统间的交流，转换不同的数据格式，同时还要考虑数据安全等多重因素。这样的实际任务远非简单基准测试中的单一任务所能比拟。
网络调用失败后的异常处理等情形同样复杂。这要求我们不仅要深入理解代码的内在逻辑，还得全面考虑系统环境、用户使用场景等多种因素。
对AI发展的影响
这种评估标准与软件开发实际任务存在较大差异，这对人工智能的发展带来了一定影响。若持续以不全面的基准来衡量模型进步，容易产生误解，让人误以为AI已足够强大。然而，当AI面临软件工程师的实际挑战时，其表现并不理想。这可能导致AI研究方向出现偏差，使得研发资源未能得到合理分配和有效利用。
然而，若AI想在软件开发上实现实质性突破，必须致力于攻克复杂实际问题。不然，它将难以融入高端软件开发流程，也难以满足项目对软件性能和稳定性等多方面的实际需求。
软件未来发展思考
观察软件行业未来的发展趋势，这种状况亟需改进。测试的标准必须持续优化，以便更准确地反映软件工程师所面对的复杂实际问题。首先，应当模拟更多真实环境，引入更多种类的任务模式。其次，还需对不同级别工程师的任务类型进行全面评估。
这种差距若持续存在，可能会妨碍软件行业的整体发展。软件行业致力于追求高效稳定的自动化技术，但若AI无法准确处理实际任务，这一目标便难以达成。
你认为如何才能有效减少评估标准与实际工程任务之间的差异？欢迎点赞、转发和留言交流。
