ChatGPT-5到底有多强？Battle！咱貌似也不输呀！

Posted 2023-04-10 shshshhhhh

盘点今年的热点话题，ChatGPT是不可避免要被反复提及的一part。从去年的-3.0到今年的-3.5，再到上月刚发布-4.0。从用户体验和市场反馈来讲，这半年的时间，ChatGPT每一步都走得又稳又快！

回想起今年2月初ChatGPT全网爆火的时候，其实当时心里是有点紧迫感的，不知道各位的感觉是啥，我的感觉就是有一种无形的紧迫感。直至我们自己宣布不日也即将推出属于我们自己的AI产品，还感觉好了一点。

其实就是刻进DNA里面的意识了，是一种怕我们落后别人太多的恐惧。之前的阴影太大了，已经深入骨髓了，很多技术，我们可以不用，但是不能不会！！！！更何况是人工智能这种未来发展的主流技术呢？

不知道大家还记不记得我之前发过一篇《GPT-5 紧急叫停？千名专家联名呼吁，AI 技术的未来又该何去何从？》，在这篇文章中，有说到“上千名专家在该公开信中写道，大量研究表明，得到顶级 AI 实验室的认可、具有人类竞争智能的 AI 系统，可能对社会和人类构成深远的风险”，而且我认为这么一场所谓的“号召”，不可避免是掺杂了政治方面的因素，而且提议内容也贼搞笑，要全球研究室都暂停六个月的研究，对此我只能说，这很难评……

值得注意的是，OpenAI在3 月26 日公布了未来GPT-4.5 的细节，而现在OpenAI官方更证实了将在2023 Q4 将推出GPT-5 这个消息有着极大准确性。

那GPT-4.5又是什么呢？GPT-4.5 模型是GPT-4 和即将推出的GPT-5 之间的一个重要中间版本，据OpenAI 自身预测，GPT-4.5 模型将于2023 年9 月或10 月推出，未来的GPT-4.5 模型将解决GPT-4 的一些限制，GPT-4.5 的更新包括更精准的处理长文本输入、增强主题相关性、更准确的回答和改进的微调能力。正因为GPT-4.5 在各方面具备更好的能力，未来可以想象它更好地融入在其他应用程式，例如产品支援、内容创建和虚拟助手都可以看到它的身影。

回到我们的主题，如果GPT-4.5的功能如此强大的话，那么不出意外的话，GPT-5的功能只会更强，毕竟我们已经切身体验过GPT-3.0、GPT-3.5与GPT-4.0这三代之间的技术差距是断层的。

目前所有的目光都聚焦到了ChatGPT-5上，反倒对于国内相关产品并没有太多关注，像三月发布的文心一言，以及在4月7日开始进入测试阶段的通义千问，并没有获得太多的关注。

不管是文心一言还是通义千问，都是我们中国的大规模语言模型，它们在自然语言处理领域都有着很高的技术水平。

在这里呢，就不对这两个平台做啥测试对比了，论坛上相关的测试对比帖子有很多大佬都写得很好。总的来说，这两截至目前都代表着咱这较为先进的技术，甚至可以说就是目前的“标准”了。对于咱自己家里的技术发展，我还是持乐观态度的，相信我们是有能力追上目前世界的先进技术发展脚步的。

作为未来的主流技术之一，人工智能技术一直深受着人们的喜爱和期待。随着近些年来的技术发展和应用普及，人工智能已广泛地渗透和应用于诸多垂直领域，产品形式也趋向多样化。近年来，关注度较高的应用场景主要包括安防、金融、教育、医疗、交通、广告营销等。且目前国际上尚未出现拥有绝对主导权的垄断企业，在很多细分领域的市场竞争格局尚未定型。

人工智能的水平建立在机器学习的基础上，除了先进的算法和硬件运算能力，大数据是机器学习的关键。大数据可以帮助训练机器，提高机器的智能水平。数据越丰富完整，机器辨识精准度越高，因此大数据将是各企业竞争的真正资本。艾媒咨询分析师认为，大数据是人工智能进步的养料，是人工智能大厦构建的重要基础。通过对大量数据的学习，机器判断处理能力不断上升，智能水平也会不断提高。

近两年与人工智能齐头并进的另一个就是低代码开发，随着技术的不断发展，各企业的数字化提上日程，低代码开发无疑为这些企业提供了现成的、低成本的、高效率的数字化转型方案，甚至可在短时间内为企业量身定制一套开发工具！

低代码开发在一定程度上简化了应用程序的开发过程，同时又不完全依赖于编写代码。简单来说，低代码平台提供了一个可视化界面、拖放组件以及模板等工具，使得开发人员能够快速构建应用程序，并且能够通过简单的配置、自定义和扩展等方式来满足业务需求。

就拿JNPF举例来讲，JNPF通过在线开发、流程引擎、代码生成等核心功能快速构建相关业务系统，可以帮助开发者实现5分钟配置一张业务表单、5小时搭建一个专属应用、5天落地一个管理方案，并且易于维护、易于扩展、安全稳定，助力企业打通数字化的“最后一公里”。

综合来看，合理并且有效地运用低代码，不仅可以令企业工作高效地运行，还能最大程度保证团队目标的达成。低代码开发平台且拥有在线搭建功能，可根据企业需求实现自主配置，是帮助企业开启数字化转型的重要引擎。

都说 NoSQL 比 SQL 强，一文揭密 NoSQL 到底有多强！

关系数据库经过几十年的发展后已经非常成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如下缺点。

• 关系数据库存储的是行记录，无法存储数据结构

  以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。

• 关系数据库的 schema 扩展很不方便

  关系数据库的表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行 DDL（data definition language，如 CREATE、ALTER、DROP 等）语句修改，而且修改时可能会长时间锁表（例如，MySQL 可能将表锁住 1 个小时）。

• 关系数据库在大数据场景下 I/O 较高

  如果对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高，因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。

• 关系数据库的全文搜索功能比较弱

  关系数据库的全文搜索只能使用 like 进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足业务要求。

针对上述问题，分别诞生了不同的 NoSQL 解决方案，这些方案与关系数据库相比，在某些应用场景下表现更好。但世上没有免费的午餐，NoSQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性，因此我们不能盲目地迷信 NoSQL 是银弹，而应该将 NoSQL 作为 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。

常见的 NoSQL 方案分为 4 类。

• K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。

• 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。

• 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。

• 全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

K-V 存储

K-V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含义一样，Value 就是具体的数据。

Redis 是 K-V 存储的典型代表，它是一款开源（基于 BSD 许可）的高性能 K-V 缓存和存储系统。Redis 的 Value 是具体的数据结构，包括 string、hash、list、set、sorted set、bitmap 和 hyperloglog，所以常常被称为数据结构服务器。

以 List 数据结构为例，Redis 提供了下面这些典型的操作：

• LPOP key 从队列的左边出队一个元素。

• LINDEX key index 获取一个元素，通过其索引列表。

• LLEN key 获得队列（List）的长度。

• RPOP key 从队列的右边出队一个元素。

以上这些功能，如果用关系数据库来实现，就会变得很复杂。例如，LPOP 操作是移除并返回 key 对应的 list 的第一个元素。如果用关系数据库来存储，为了达到同样目的，需要进行下面的操作：

• 每条数据除了数据编号（例如，行 ID），还要有位置编号，否则没有办法判断哪条数据是第一条。注意这里不能用行 ID 作为位置编号，因为我们会往列表头部插入数据。

• 查询出第一条数据。

• 删除第一条数据。

• 更新从第二条开始的所有数据的位置编号。

可以看出关系数据库的实现很麻烦，而且需要进行多次 SQL 操作，性能很低。

Redis 的缺点主要体现在并不支持完整的 ACID 事务，Redis 虽然提供事务功能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）。

虽然 Redis 并没有严格遵循 ACID 原则，但实际上大部分业务也不需要严格遵循 ACID 原则。以上面的微博关注操作为例，即使系统没有将 A 加入 B 的粉丝列表，其实业务影响也非常小，因此我们在设计方案时，需要根据业务特性和要求来确定是否可以用 Redis，而不能因为 Redis 不遵循 ACID 原则就直接放弃。

文档数据库

为了解决关系数据库 schema 带来的问题，文档数据库应运而生。文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是 JSON（或者 BSON），因为 JSON 数据是自描述的，无须在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。

文档数据库的 no-schema 特性，给业务开发带来了几个明显的优势。

1. 新增字段简单

   业务上增加新的字段，无须再像关系数据库一样要先执行 DDL 语句修改表结构，程序代码直接读写即可。

2. 历史数据不会出错

   对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。

3. 可以很容易存储复杂数据

{  "id": 10000,  "name": "James",  "sex": "male",  "hobbies": [  "football",  "playing",  "singing" ],  "email": "[e-mail]",  "address": {  "province": "GuangDong",  "city": "GuangZhou",  "district": "Tianhe",  "detail": "PingYun Road 163" },  "education": [  {  "begin": "2000-09-01",  "end": "2004-07-01",  "school": "UESTC",  "major": "Computer Science & Technology" },  {  "begin": "2004-09-01",  "end": "2007-07-01",  "school": "SCUT",  "major": "Computer Science & Technology" } ]}

通过这个样例我们看到，使用 JSON 来描述数据，比使用关系型数据库表来描述数据方便和容易得多，而且更加容易理解。

文档数据库的这个特点，特别适合电商和游戏这类的业务场景。以电商为例，不同商品的属性差异很大。例如，冰箱的属性和笔记本电脑的属性差异非常大。

即使是同类商品也有不同的属性。例如，LCD 和 LED 显示器，两者有不同的参数指标。这种业务场景如果使用关系数据库来存储数据，就会很麻烦，而使用文档数据库，会简单、方便许多，扩展新的属性也更加容易。

文档数据库 no-schema 的特性带来的这些优势也是有代价的，最主要的代价就是不支持事务。例如，使用 MongoDB 来存储商品库存，系统创建订单的时候首先需要减扣库存，然后再创建订单。这是一个事务操作，用关系数据库来实现就很简单，但如果用 MongoDB 来实现，就无法做到事务性。异常情况下可能出现库存被扣减了，但订单没有创建的情况。因此某些对事务要求严格的业务场景是不能使用文档数据库的。

文档数据库另外一个缺点就是无法实现关系数据库的 join 操作。例如，我们有一个用户信息表和一个订单表，订单表中有买家用户 id。如果要查询“购买了苹果笔记本用户中的女性用户”，用关系数据库来实现，一个简单的 join 操作就搞定了；而用文档数据库是无法进行 join 查询的，需要查两次：一次查询订单表中购买了苹果笔记本的用户，然后再查询这些用户哪些是女性用户。

列式数据库

顾名思义，列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，因为关系数据库是按照行来存储数据的。

关系数据库按照行式来存储数据，主要有以下几个优势：

• 业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中。

• 能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性；否则如果采用列存储，可能会出现某次写操作，有的列成功了，有的列失败了，导致数据不一致。

我们可以看到，行式存储的优势是在特定的业务场景下才能体现，如果不存在这样的业务场景，那么行式存储的优势也将不复存在，甚至成为劣势，典型的场景就是海量数据进行统计。例如，计算某个城市体重超重的人员数据，实际上只需要读取每个人的体重这一列并进行统计即可，而行式存储即使最终只使用一列，也会将所有行数据都读取出来。如果单行用户信息有 1KB，其中体重只有 4 个字节，行式存储还是会将整行 1KB 数据全部读取到内存中，这是明显的浪费。而如果采用列式存储，每个用户只需要读取 4 字节的体重数据即可，I/O 将大大减少。

除了节省 I/O，列式存储还具备更高的存储压缩比，能够节省更多的存储空间。普通的行式数据库一般压缩率在 3:1 到 5:1 左右，而列式数据库的压缩率一般在 8:1 到 30:1 左右，因为单个列的数据相似度相比行来说更高，能够达到更高的压缩率。

同样，如果场景发生变化，列式存储的优势又会变成劣势。典型的场景是需要频繁地更新多个列。因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作；而行式存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成，列式存储的随机写效率要远远低于行式存储的写效率。此外，列式存储高压缩率在更新场景下也会成为劣势，因为更新时需要将存储数据解压后更新，然后再压缩，最后写入磁盘。

基于上述列式存储的优缺点，一般将列式存储应用在离线的大数据分析和统计场景中，因为这种场景主要是针对部分列单列进行操作，且数据写入后就无须再更新删除。

全文搜索引擎

传统的关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，主要体现在：

• 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。

• 全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低。

我举一个具体的例子来看看关系型数据库为何无法满足全文搜索的要求。假设我们做一个婚恋网站，其主要目的是帮助程序员找朋友，但模式与传统婚恋网站不同，是“程序员发布自己的信息，用户来搜索程序员”。程序员的信息表设计如下：

我们来看一下这个简单业务的搜索场景：

• 美女 1：听说 PHP 是世界上最好的语言，那么 PHP 的程序员肯定是钱最多的，而且我妈一定要我找一个上海的。

美女 1 的搜索条件是“性别 + PHP + 上海”，其中“PHP”要用模糊匹配查询“语言”列，“上海”要查询“地点”列，如果用索引支撑，则需要建立“地点”这个索引。

• 美女 2：我好崇拜这些技术哥哥啊，要是能找一个鹅厂技术哥哥陪我旅游就更好了。
  
  

美女 2 的搜索条件是“性别 + 鹅厂 + 旅游”，其中“旅游”要用模糊匹配查询“爱好”列，“鹅厂”需要查询“单位”列，如果要用索引支撑，则需要建立“单位”索引。

• 美女 3：我是一个“女程序员”，想在北京找一个猫厂的 Java 技术专家。

美女 3 的搜索条件是“性别 + 猫厂 + 北京 + Java + 技术专家”，其中“猫厂 + 北京”可以通过索引来查询，但“Java”“技术专家”都只能通过模糊匹配来查询。

• 帅哥 4：程序员妹子有没有漂亮的呢？试试看看。

帅哥 4 的搜索条件是“性别 + 美丽 + 美女”，只能通过模糊匹配搜索“自我介绍”列。

以上只是简单举个例子，实际上搜索条件是无法列举完全的，各种排列组合非常多，通过这个简单的样例我们就可以看出关系数据库在支撑全文搜索时的不足。

1. 全文搜索基本原理
   
   

全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。之所以被称为“倒排”索引，是和“正排“索引相对的，“正排索引”的基本原理是建立文档到单词的索引。我们通过一个简单的样例来说明这两种索引的差异。

假设我们有一个技术文章的网站，里面收集了各种技术文章，用户可以在网站浏览或者搜索文章。

正排索引示例：

正排索引适用于根据文档名称来查询文档内容。例如，用户在网站上单击了“面向对象葵花宝典是什么”，网站根据文章标题查询文章的内容展示给用户。

倒排索引示例：

倒排索引适用于根据关键词来查询文档内容。例如，用户只是想看“设计”相关的文章，网站需要将文章内容中包含“设计”一词的文章都搜索出来展示给用户。

1. 全文搜索的使用方式
   
   

全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行，两者的术语差异很大，不能简单地等同起来。因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。

目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜索引擎进行索引。我同样以程序员的基本信息表为例，看看如何转换。

将前面样例中的程序员表格转换为 JSON 文档，可以得到 3 个程序员信息相关的文档，我以程序员 1 为例：

{ "id": 1, " 姓名 ": " 多隆 ", " 性别 ": " 男 ", " 地点 ": " 北京 ", " 单位 ": " 猫厂 ", " 爱好 ": " 写代码，旅游，马拉松 ", " 语言 ": "Java、C++、PHP", " 自我介绍 ": " 技术专家，简单，为人热情 "}

全文搜索引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜索。以 Elasticsearch 为例，其索引基本原理如下：

Elastcisearch 是分布式的文档存储方式。它能存储和检索复杂的数据结构——序列化成为 JSON 文档——以实时的方式。

在 Elasticsearch 中，每个字段的所有数据都是默认被索引的。即每个字段都有为了快速检索设置的专用倒排索引。而且，不像其他多数的数据库，它能在相同的查询中使用所有倒排索引，并以惊人的速度返回结果。

来源：小马过河
原文：http://t.cn/EKRR01N
题图：来自谷歌图片搜索 
版权：本文版权归原作者所有
投稿：欢迎投稿，投稿邮箱: [e-mail]

推荐阅读

• 
  

• 
  

• 
  
  

图说生活

这里将分享一些记录生活的日常随拍。

拍攝于：海洋探索中心，重庆，2018