软件开发的整个流程涉及多个阶段，而如何在生产开发的过程中充分发挥大模型的作用是我们过去半年一直在努力解决的问题。
在大语言模型出现之前，我们过去认为这个世界只有三类实体，一类是人human，一类是物理世界physical world，包括动物、椅子、灯等。第三类是软件software，它是信息系统，既不属于物理世界，也不属于人类。
在过去的世界，这三类实体之间相互运作得相当好。比如，我可以打开或关闭灯，物理世界中的车辆可能会撞到我，也可以通过虚拟助手控制信息系统，实现对物理世界的影响。当然，信息系统还能提供大量的抖音视频和其他信息，形成相互交互的关系。
在人工智能出现后，若将其视为一个独立的物种，那它与人类、物理世界和软件之间存在怎样的关系？它们之间又是如何相互影响的呢？
刚出现时，大语言模型首先影响的只能是人类。这是因为大语言模型只能输出文字，而只有人类能够理解文字，软件和物理世界无法互相理解。因此，大语言模型的影响主要体现在与人类的直接互动上。大语言模型
大语言模型如何操作软件呢？这涉及到插件的概念，即在OpenAI的接口中加入一些功能。通过这些插件，大语言模型在某种程度上可以像虚拟助手一样直接调用接口和功能来操作软件。大语言模型尽管目前大语言模型不能直接操作物理事件，但已经有人在研发由大语言模型驱动的机器人，不再依赖指令，更像是模型自主驱动，类似人类的方式。可以预见，未来这两方面的发展将逐渐完善，使得大语言模型成为与世界其他元素完全互动的存在。
如果将大语言模型看作一种存在，我们可以将其比喻为什么呢？大预言模型显然不是物理世界的实体，那它更像人类，还是更像我们现有的软件（程序）呢？根据我的研究，我认为大语言模型更像人类。在日常工作中，我负责公司所有GPT的Prompt编写，因此经常与GPT进行深入交流。有一段时间，我每天都在深夜与GPT4进行交流，这种交流让我对它的本质有了更充分的认识。在我看来，大语言模型更像人类，而不是传统的程序。
另一个佐证是大语言模型无法完成算数题。如果问它"756乘以652等于多少"，它很可能算错。这与人类一样，没有一个人能够精确计算出这个结果，这表明大语言模型更像人类的思考方式和解决问题的能力。
因此，我们不能依赖大语言模型去处理需要高度准确性的任务，就像不能依赖一个票务员记住全国的订票信息和列车调度信息一样。理解了这一点，我坚信大语言模型的出现并不是为了取代软件，而是为了取代人类。但它并不会取代信息系统，我们仍然需要数据库、if else和大量的编程语言。在这个过程中，新的从业者——AI开发者出现了，因此我们需要做的是一个适用于人类和AI的IDE。在这个过程中，我们进行了许多面向大语言模型的尝试和思考。
复杂的LLM（Large Language Model）应用指的是那些不仅仅局限于聊天框的应用。如果我们只考虑信息在聊天框中的传递，大概率这样的应用都会被ChatGPT所替代。复杂的LLM应用必须具有两个核心特点，即隐式上下文和结构化输出。
隐式上下文指的是人类交流中存在很多言外之意和场外信息。例如，在商业交流中，一位高效的秘书能够根据一句话判断出许多信息，而不仅仅是字面上的意思。这包括对公司、领导和客户的了解，以及对场景的综合考虑。
而ChatGPT虽然具有插件功能，却无法解决现实世界问题，因为现实世界涉及很多不在语言中显性表达的场外信息。这也是为什么ChatGPT尽管有插件，却未能在实际应用中达到改变世界的程度。
举例来说，GitHub Copilot是目前唯一真正商业化并解决实际问题的大模型应用。尽管我们看到的是根据一行注释生成代码，但实际上GitHub Copilot提供的上下文信息不仅仅是这一行注释。还包括当前光标位置、文件中的其他信息以及文件间的依赖关系。这些都是人在编写代码时需要考虑的隐式上下文，而不仅仅是表面上的一行注释。
另一个复杂的LLM应用的特点是结构化输出。长时间以来，人们曾认为大模型是一个搜索引擎，但现在许多人将其看作是知识的来源。然而，这其实是对其最基本的应用。只有将大模型看作是智力的来源，它才能发挥其真正的能力。
将大模型当作知识来源时，它可能会回答一些简单的问题，但输出往往不能直接用于下一步程序。例如，你向ChatGPT询问明天晚上请朋友吃西餐，主菜是牛排，需要准备哪些食材和搭配餐酒的问题。尽管大模型可能会提供详细的回答，但这个输出无法直接用于下一步的买菜程序等。这是因为这种输出是为人类阅读而设计的，而非为程序。
因此，复杂的LLM应用与聊天应用的主要差异在于，它们需要处理大量信息，这些信息并不完全包含在聊天框中（隐式上下文），而且它们需要结构化的输出以供程序使用。在实际应用中，要使大模型发挥实际解决问题的作用，必须考虑这些隐式上下文，而不仅仅依赖于聊天框中的几行文字。
除了上面两个特点，当然发现大模型又有自己的三个弱点。
第一个弱点叫做答非所问unpredictable output。答非所问就是牛头不对马嘴，不知道在说什么。比如下图问的是一个软件工程的问题：什么叫HTTP，但AI回答的是一个宠物的问题。大模型的输出不可控，常常会输出一些完全出乎意料的内容。
第二个问题叫做胡说八道Hallucination。就像下图可乐饼的做法是全错的，但它编的像模像样。
第三个问题是长度限制 context window。超过解析长度，它就会报错。
这三个问题会严重影响大语言模型的企业应用。
学术界测评与工业场景下的鸿沟
市面上有很多大模型，国外有GPT 3、3.5、4， Anthropic做了Claude，有Cohere，有llama 2、Meta，国内也基本上每家都有。AI从业者主要分以下几层，最底层肯定是做大模型的，再往下是做GPU的。大部分创业者和开发者都跟这两层没有关系，因为它是个巨量的资本密集型行业。
创业者或者开发者要选到底在哪个大模型上做应用，是基基于OpenAI、 Anthropic做，还是基于国内的百度、阿里。现在大模型厂商都开始卷开发者，通过各种各种激励手段，让开发者在自己那儿造应用。这就面临一个问题，我们如何评估一个大模型能否胜任复杂应用？
我们做Babel的过程中也面临这个问题。于是我们索性把它做成开源项目，叫做LLMRGB，LLM reasoning and generationBenchmark。
为什么这个Benchmark跟现有的学术界很多Benchmark不一样？很多新的模型出来，说自己在哪个Benchmark比GPT 4还好，它并没有撒谎。但是学术界的很多Benchmark有一个问题，它们更多东西在做应用的时候实际并不需要，比如说内容生态数据认知、知识问答等都不太重要。
我们做了一个Benchmark，更希望偏向工业场景，而不是算数学题。评估一个大模型跟评估一个人特别像，你招一个人会让他算数学题吗。你更多考察他的理解能力、沟通能力，临时的应变能力，这是企业招聘员工很多时候要看的核心能力。对于大模型的考察也是一样的，我们更多考察的是复杂场景要关注上下文长度。
第二推理能力。就是你到底能不能够从这一步想到后面的第三步。很多的AI应用，对推理能力的需求是0。比如你给它发过去一篇文章，说帮我把这篇文章总结一下，这不需要推理能力。那什么场景需要推理能力？比如iPhone之父生日的最后一个数字是多少？iPhone之父生日是乔布斯的生日，这是需要推理的。
第三是结构化输出能力。
构建 LLM 评价体系
很多时候我们希望大模型不要跟我说废话，问它问题，它直接回答yes or no，对和不对就结束了，但很多大模型做不到。所以我们会评估它，这个指令遵循叫instruction-compliance。这套评价的标准不是搞学术，是做落地应用。
Babel制定的这套LLM评价体系，从做应用的角度来讲，更具实用性，而且我们也不评测LLM全方位的能力。我们把LLM RGB开源了出来，然后在一个论坛里面发了一下，论坛里就有人反驳我们说这个评测不对，为什么GPT 4一定强，而很多国内模型都不行。以GPT 4不能背诵《出师表》作为反驳理由。但是请问你在什么场景下需要GPT 4背诵《出师表》，你完全可以直接去数据库里面搜现成内容。企业招聘员工会让他背《出师表》吗。
以下是一个测试集中的案例，用于评估大型语言模型的性能。这个prompt非常简单，要求模型回答几个关于给定文章的问题。首先是文章是否有一个 happy ending，回答是或否。接着要求列出文章中引人注目的地方。GPT-4的回答非常完美，它回答是，同时指出了触动人心的地方，并编号为1234。百度没有输出结果，可能是因为处理长度时出现了问题。Llama2在逻辑推理方面表现不错，但整体格式多了一个空行，这对人类来说无关紧要，但对机器解析可能会产生麻烦。
这个案例突显了我们如何评估大型语言模型的能力，即使它们能够总结信息，但在特定方式下的总结可能仍然是一个挑战。
第二个测试用例涉及大型语言模型的越狱问题。这是指让模型输出一些它不应该说的内容，即使在调教阶段规定了一些规则。比如，通过Prompt的方式让它遵循一些规则，但用户可以通过某种方式越狱，让它输出被提前输入的系统指令。测试中，GPT-4会礼貌地拒绝透露规则。而百度的回答中有50%是正确的，即它也不回答。其他一些模型则泄露了核心代码，这被视为越狱。
最后一个测试案例是关于打麻将的内容。在这个案例中，模型需要理解麻将牌的规则，并根据当前的局面做出打牌的决定。这是一个非常困难的测试，因为麻将是一个非完全信息游戏，需要理解上下文和进行推理。目前看来，还没有一个模型能够正确回答这个问题，期待GPT-5的表现。
最后的测试结果考察了三个维度：上下文长度、推理深度和指令遵循。详细的测试分数可以在开源项目中查看。该项目有15个测试用例，每个大型模型都分别进行了评分。我们提供了在线版本供用户测试，当然需要提供自己的密钥。此外，开源项目本身是我们自己开发的Babel应用。
为什么要做Babel
我们为什么做Babel。大家现在对于Copilot已经比较熟悉了，但我觉得Copilot可能还不是一个大家最想要的最终极形态，现在很多人都讲agent。agent其实更像一个AIDeveloper。
它很好的表达了我认为AI将来跟人类的关系。AI跟人的关系不应该是左边的，应该是右边的。
以一个关于检查比特币价格，监控价格然后发邮件，如果价格低于多少发邮件，并且绘制一个比特币价格图表的应用为例。Babel能够通过一段自然语言的描述，自动生成一个完整的软件，而不仅仅是一些代码片段。它首先生成软件的结构，然后开始填充结构中的代码，类似于人类工程师先设计结构，再在其中编写代码的过程。不同之处在于，这个过程中主体从人类变成了人工智能。完成后，我们可以进行检查，需要配置一些关键信息如发邮件所需的用户密码。提交后，可以看到生成的软件有两个功能，一个是查看比特币的价格图表，另一个是触发价格检查，如果低于4万，系统将发送一封简单的邮件警告。尽管这是一个简单的应用，但它传达了我们的理念。
我们认为，未来的人工智能不仅仅是辅助编写代码片段和回答问题，更应该像人类一样能够直接从事工作，这正是Babel致力于实现的目标。
观众提问补充
Q1.整个软件开发流程中 debug 的这个过程未来会变成什么样？现在生成了一个复杂的应用上线之后会发生一些什么?
这是一个非常关键的问题。在软件工程中，从一个想法到需求澄清，再到需求的各种结构化过程中，存在多个阶段。
在上线之前，有两类主要问题，一种是编译错误（compile error），即在编写过程中就能指示编译错误；另一种是运行时错误（runtime error），即上线后的维护问题。尽管目前我们还没有这两个功能，但我们希望在明年的第一季度能够上线。这意味着，如果你的应用在Babel上，当运行时出现问题时，AI将自动帮助检查错误，并在可能的情况下修复。
想象一下，你早上起床后，打开电脑，看到AI给你提供的报告，详细说明昨天晚上发生了哪些故障以及它是如何修复的。这才是真正的人工智能。相较之下，Copilot是一种互动式的方式，只有在你在干活时它才参与，而我认为真正强大的是我在休息时它仍然在工作。这是可以实现的，问题不在于不能实现，而是现有的基础设施挑战极大。
许多工具过去都是为人类设计的，而人工智能虽然具有大脑思考的能力，但它没有眼睛，其感知方式是不同的。它没有手和脚，无法操作键盘，那么如何让它能够像人一样操作系统呢？我认为这对基础架构需要进行重构。
Q2.未来几个月甚至半年的时间，大语言模型会是怎么样的发展趋势？哪些才值得我们去关注的核心能力？
我对当前业界各种概念并不看好，一直以来我都以“3G时代造抖音”为例。在3G时代，你能否创建抖音？不可能，虽然你可以讲各种概念，但基础设施不支持。我认为解决各种工程化问题、采用工程化方式，都是在底层之上的一种试图，是一种无法规避的尝试。我是一个注重长远发展的人，但长链并不总是有用的。我认为大家在进行人工智能的研究时，只需要关注OpenAI的API即可。其中有一个名为“chat”的API，关注这个API中的参数变化才是真正的变化。如果这些参数没有变，其他的都是扯淡。我们所做的一切都是工程，因为参数的改变并非易事。
context length的增加非常困难，因为它是2的n次方的关系。从8K token增加到16Ktoken是一项艰巨的任务。因此，尽管OpenAI GBC支持32Ktoken，但如果真的使用这个模型，你会发现超长后其推理能力急剧下降。底部的部分可能没有取得突破，但在上面，它试图做各种尝试。这是一个工程问题，包括Claude的100K也是一样的。当你超过长度限制时，它不会报错，但其处理能力下降，注意力下降。因此，我认为底层的革新才能真正带来上层应用的巨大变革。但由于底层的革新实际上进展缓慢，我认为依赖大模型的进步才真正有价值。在此之前，我们所做的一切都是Prompt工程，而我认为上述问题并没有多大不同，都是先前软件工程中已经涉及的事务。因此，我仍然认为底层大模型的创新推动更为重要，值得更多关注。