分布式 Data Warebase - 让数据涌现智能
ProtonBase 研究员
本文整理自 ProtonBase 研究员蒋晓伟在 DataFunCon 2024 北京站分享的演讲《分布式 Data Warebase - 让数据涌现智能》,点击查看完整演讲视频。
从数据、信息、知识和智慧(DIKW)的层次结构出发,探讨数据系统的发展历程,以及如何让数据涌现智能。
01 DIKW 模型
通过 Data(数据) - Information(信息) - Knowledge(知识) - Wisdom(智慧)四层金字塔结构,DIKW 模型提供了一个理解它们之间关系的框架。
以一个例子来解释 DIKW 模型中的概念:
- 数据是一些没有上下文的数和文字,比如“9.8”本身并不具备确切的物理含义。
- 当数据被赋予上下文,就成为了信息。“一个一千克的铁球以 9.8 米/秒2 的加速度下落”这句话中的“9.8”就传达了特定的信息,即铁球下降的加速度。
- 知识则是对信息的归纳和总结。比如,根据观察,一千克、五千克、十千克的铁球都以 9.8 米/秒2 的加速度下落,可以归纳出“所有的铁球都以 9.8 米/秒2 的加速度下落”这一知识。进一步,我们发现铜球和银球也以相同加速度下落,于是进一步归纳出“所有物体都以 9.8 米/秒2 的加速度下落”。这种归纳和抽象使信息转化为知识,从而能够预测未来,如推断八千克的铅球也将以 9.8 米/秒2 的加速度下落。
- 智慧则是在知识基础上通过复杂推理得出的洞见。例如,基于“所有物体都以 9.8 米/秒2 的加速度下落”这一知识,可以推断重力下加速度与落体本身的特性无关,而是时空的一种几何性质。这就是广义相对论的核心思想,体现了智慧。智慧是最高级的智能,它需要复杂的推理论证和深刻的洞察,目前仅人类具备这种能力。
从数据到信息到知识再到智慧,这是智能逐渐升级的过程。这个过程中对数据的理解越来越深入,提取的概念越来越抽象,体现的智能也越来越高级。接下来,本文将详细阐述如何让机器理解数据,从中挖掘智能。
02 数据
首先从数据层讲起,对机器而言,数据就是一堆 0 和 1。机器表达数据的语言是比特。机器虽然能够存储数据,但并不理解数据的意义。
03 信息
接下来是信息层,信息的语言是数据模型。通过一个例子来讲解机器如何将存储为比特的数据转化为信息:“小明预订了 2024 年 6 月 1 日的两个标间”。机器以比特的形式将这些文字存储为数据,但机器并不理解这个句子的含义。为了让机器理解它,需要引入表的抽象。可以创建一个“民宿预订”表,然后将刚才的文字分解成多个字段存为这个民宿预订表的一条记录。例如,预订人姓名是小明,预订日期是 2024 年 6 月 1 日,预订房间数是 2,预订房型是标间。
通过引入表结构,原本机器不理解的无结构的数据就转变为一条带结构的记录,机器可以理解和处理这些记录。这种给数据赋予结构的方式被称为数据模型。常见的数据模型有两种:
- 第一种是上面提到的关系模型,它通过引入表的抽象将数据划分为多个字段,并且通过外键这种方式表达表和表之间记录的关系。这些元数据信息也存储于系统中,它包含了表名、表中的各个字段名、字段的类型、表和表之间的关系等等。这些元数据给数据赋予了上下文,给数据带来了结构,结构化的数据就能够被机器理解和处理,从而变成了信息。作为一种描述信息的语言,关系模型对数据的要求比较严格,只有在所有数据结构完全一致的情况下才能用它来描述。
- 另一种数据模型是文档模型,和关系模型不同,它将数据组织成文档。不同文档的结构可以不完全一样。这种有一定结构但结构又不严格一致的数据被称为半结构化数据。文档模型将数据组织为一种树状结构,这种结构能够较好地表达实体间一对一以及一对多的关系。文档模型是让半结构化数据变成信息的语言。 概括一下,数据模型是表达信息的语言,有了这种语言后,数据就从比特升级为了表记录或者文档,这种语言和抽象帮我们完成了从数据到信息的一个跃迁。从此机器开始理解数据,并且可以从数据中提取一定的智能。
- 信息革命的基石 - 数据模型带来数据产品的兴起
在数据模型这种信息的语言之上发展出众多的数据产品,这些产品主要分为两大类:
- 第一类是数据库产品。根据数据模型可以进一步细分为关系型数据库和 NoSQL 数据库。关系型数据库基于关系模型,它使用表的抽象。NoSQL 数据库也有很多细分类型,当中最成功的一类是基于文档模型的文档型数据库。这些数据库产品的使命就是把数据转化为信息,并且高效地存储、检索和管理这些信息。
- 另一类产品就是数据仓库,简称数仓。数仓也是基于关系模型。数仓一般被用来对原始信息做汇总分析,从中发现规律,它的使命是高效地存储和分析各种信息。 这一系列产品为信息革命打下了坚实的基础。
- 信息革命的场景 - 一个民宿平台的数据架构
在这些基础之上,行业迎来了基于数据和信息的应用大爆发,特别是互联网时代的到来,极大地加速了进化过程。这里以一个民宿平台为例,剖析如何运用这些数据产品信息化业务数据实现业务价值。民宿的房东可以把自己的房子上架到这个民宿平台上,潜在的租客会在这个平台上去查寻自己感兴趣的民宿,并且在平台上完成预定、入住、离店、以及评价等操作。
为了实现这样一个应用,首先需要构建应用服务,一开始所有的数据都被存储在像 PostgreSQL 这样的关系型数据库之中。由于业务的需求足够简单,而且数据量不是很大,所以一个单机的 PostgreSQL 足以满足这个应用服务对数据的一切需求。 随着应用的用户越来越多,单机的关系型数据库很快就无法满足业务的性能需求,因此不得不引入 MongoDB 这样的 NoSQL 数据库。NoSQL 数据库的一个好处是可以通过增加机器这种水平扩容的方式提升性能,从而满足业务日益增长的性能需求。在解决了性能问题之后,用户数继续快速增长,用户对应用的需求也日益复杂。比如用户不再满足于通过全名去查找民宿,而是希望能够根据一些关键词找到自己感兴趣的民宿,MongoDB 并不能高效实现这一需求。因此,系统又引入了 ElasticSearch 这样的搜索引擎。为了让搜索引擎能够提供搜索服务,首先需要把数据导入到搜索引擎之中。数据的导入一般分为两种形式,第一种是全量的数据导入,关系型数据库和 NoSQL 数据库里面的数据会定期以全量的方式导入到搜索引擎。如果应用对数据的时效性有比较高的要求,还要再引入增量的数据同步链路,比如采用 Kafka 和 Flink 这样的技术把上游的增删改同步到搜索引擎之中。当搜索引擎有了这些数据后,就可以为应用提供高性能的关键词搜索了。
至此,通过利用各类数据库产品,系统具备了基础信息的存储和高效提取能力。此外,我们还希望对信息进行汇总分析。比如分析今年五一假期民宿营收和去年的同比情况、五一假期全国最热门的 10 个城市是哪些。为了高效获得这些汇总信息,系统又引入了像 Snowflake 或者 Hive 这类数仓产品。并且把数据从各个数据库同步到这个数仓之中,就可以使用数仓进行复杂的 BI 分析。可以看到:一个业务往往需要同时使用多个数据库和数仓产品,并且需要在它们之间进行复杂的数据同步。
04 知识
- 知识是信息的归纳 - 知识的语言是嵌入向量
如果说信息的语言是数据模型,知识的语言将会是嵌入向量,首先来解释一下什么是嵌入向量。 前面提到知识是相关信息的归纳和汇聚。所有物体都以 9.8 米/秒2 的加速度落地,这个就是对大量相关信息的归纳。除了这种归纳之外,相关信息的汇聚也是知识。比如说,一个民宿所有信息在一起就是一种知识。这个知识概括了民宿各方面的信息:价格信息、风格信息、设施信息等等。
我们希望用一种数学语言去表达这种知识,并且能通过这种数学表示去比较两个民宿,判断两个民宿是否相似。民宿的比较是多方位的,例如可以从经济型还是豪华型的维度去评判两个民宿是否相似。作为近似可以用民宿的价格来衡量一个民宿是经济型还是豪华型。两个民宿的价格越接近,它们的豪华程度也就越相近。但价格不是唯一的维度,还可以从民宿的装修风格来比较,是简约型的装修,还是华丽型的装修。按装修风格给每个民宿一个打分,得分越接近就说明它们的装修风格越相似。此外还可以从很多其他维度来比较民宿。如果要比较完整地从各个维度去描述这个民宿的各种特性,就必须使用高维空间中的向量。这个高维空间就是潜空间,知识对应于潜空间当中的一个高维向量,我们把它称为嵌入向量。
我们的另外一个期望是从两个民宿对应的高维向量判断它们的相似度。希望通过两个嵌入向量间的距离来衡量它们所代表的知识的相似程度。两个嵌入向量的距离越短,它们所对应的民宿就越相似。所以潜空间不仅仅是一个高维的向量空间,它还是一个度量空间,它定义了两个向量之间的距离。
简单地根据输入特征生成的高维向量在潜空间中的度量不一定能反应它们所代表的知识的相似度,所以我们需要通过模型来生成嵌入向量。这些模型可以是专门的嵌入模型,此外神经网络的每一层也是一个不断从输入信息中抽象更高级知识的过程,这些中间层产出的向量也代表了不同抽象程度的知识。嵌入向量可以被用来完成很多下游的任务,比如说分类、回归、重建等等。
接下来展开解释一下如何使用嵌入向量这种语言去表达和应用知识。我们分为两个阶段来讲述。第一个是传统 AI 阶段,第二个是生成式 AI 阶段。先举两个传统 AI 阶段的例子。
- 知识 - 传统 AI:离线洞察
民宿的房东希望更多的人来入住自家民宿,所以他决定通过折扣来做推广。为了提高推广的成功率,他希望只发送给对价格敏感的客户。为了做到这点,他需要理解用户,需要根据用户的基本信息、以及用户和平台交互的各种行为信息构建出描述用户的知识。如前文所述,这个知识可以表达为潜空间中的一个嵌入向量。为每个用户构建了相应的嵌入向量后,就可以对这些嵌入向量分类,决定一个用户是否对价格敏感。
为了实现这个功能,在刚才的架构之上需要引入一些新的流程。首先需要引入信息预处理的流程,把跟用户行为相关的信息做必要的清洗、补全和关联等操作。由于和用户行为相关的信息存储于数仓中,可以利用数仓来做这些预处理。接下来会使用这些信息去训练模型,通过模型产生代表用户知识的嵌入向量,并且把这些嵌入向量分类,筛选出那些对价格敏感的用户。数仓在这个过程中扮演了存储离线特征数据的角色。
- 知识 - 传统 AI:实时决策
第二个例子是自动决策的场景。民宿每天都挂同样的价格并不一定是最合理的。它可能会导致民宿在淡季租不出去,给房东带损失。所以房东为了提高淡季入住率,在总体的空置率比较高的时候,更倾向降低价格以吸引潜在的租客。但是究竟降多少合适,什么时候应该降,人工判断是一件很繁琐的事情,我们可以使用传统的 AI 去更高效地达成这个目标。
首先需要根据民宿的各种特性,比如装修风格、年份、房间数、地理位置等通过模型产生出一个代表民宿知识的嵌入向量。接下来还需要市场相关的信息,比如民宿所在地区当前的总入住率、相似民宿的价格、入住率等信息。AI 模型通过将这些信息和知识结合在一起实时推断出什么样的价格才是房东的最优选择,从而提供一个实时民宿自动定价功能。
为了实现这样一个功能,除了上文提到的数据预处理和模型训练之外,还需要引入在线模型服务,在用户查看民宿时展示民宿的实时价格。为了给这个在线模型服务提供高吞吐低延迟的特征输入,需要有个在线的特征存储。由于特征的数据量比较大,所以通常采用 MongoDB 或者 HBase 这类存储作为在线特征存储。由于训练时用到的一些特征也可能被当作模型服务的输入,这部分离线的特征必须同步到在线的特征存储中。除此之外,为了得到更好的效果,还可能需要实时计算一些特征,这进一步增加了系统的复杂度。
- 知识 - 生成式 AI:通用知识提取
接下来介绍在生成式 AI 时代如何提取和应用知识。过去几年我们见证了生成式 AI 的崛起,特别是基于 Transformer 架构的大语言模型在理解和生成文字,以及基于 Diffusion 的图像模型生成图像上取得了重大的突破。生成式 AI 能生成高质量的文本甚至代码,能够通过文生图、图生图的方式生成图像,能够通过文字生成音频甚至视频,这一系列能力极大地拓宽了 AI 的使用场景,也在重新定义什么是非结构化数据,它以一种全新的方式给传统的非结构化数据赋予结构,从中提取知识。
相比传统 AI,生成式 AI 训练的数据集要大几个数量级。最先进的大语言模型几乎使用了人类所有公开的高质量文本语料,因此它具备非常广泛的知识和智能。当你和 ChatGPT 这样一个先进的大语言模型交互时,它往往能够对很多问题给出很好的回答。这可能会带来错觉:数据不再重要,有这样一个大语言模型就可以解决一切业务问题。但事实恰恰相反,数据在生成式 AI 时代将会变得更为重要。
- 业务数据驱动的生成式 AI
举一个例子,九间堂民宿希望在江苏做一个广告,需要让 AI 为这个广告营销活动生成一个图片,下图左侧就是 AI 生成的图片。可以看到这个图片里有九间房子,房子位于地图上的江苏。因为通用的模型只有这些信息,所以能够生成这样的图片算是合格,但我们希望更好的效果。于是我们查找出了九间堂在江苏最受欢迎的一些民宿,并且让大模型学习了这些民宿的描述和图片等信息。在理解了业务的数据后,再让 AI 重新生成图像,就得到了下方右侧这张图片,相较而言它的广告效果会好很多。
可以看到,虽然大语言模型理解了大量公开的知识,但是缺少业务相关的私域知识。而这部分私域知识是数据在业务上发挥最大价值的关键。只有把生成式 AI 的能力和业务数据紧密结合在一起,才能最大化发挥生成式 AI 的智能,数据仍然是驱动智能的核心。接下来介绍将大语言模型能力和业务数据结合的三种方式。
- 业务数据驱动智能方式一:上下文学习(In Context Learnig)
第一种方式是上下文学习(也就是 In-context-learning)。这里举一个例子,用户对某个民宿感兴趣,但是他不确信这个民宿是否能够让家里的所有成员都住得比较舒适。当然他可以自己去详细地了解这个民宿的所有信息,然后再看是否能住下,但这无疑是件繁琐的事情。于是我们想利用大语言模型的能力来完成这样一个规划,把这个民宿的描述等信息给到大语言模型,然后再向大语言模型提问,请它安排一下家人的住宿。大家可以看到大语言模型在了解了这些信息之后,给出了一个非常合理的安排。这就是大语言模型一个核心的能力,它可以从上下文当中学习知识,并且把自己的智能应用在这些新学的知识上。
- 业务数据驱动智能方式二:向量搜索
第二种方式是基于嵌入向量的相似性搜索。比如基于 Transformer 的文本嵌入模型能够为民宿的描述和评论等文字生成嵌入向量。两个民宿越相似,它们对应的嵌入向量也就越接近。高效地查找和某个指定向量最相近的若干向量的搜索叫作向量搜索。
- 检索增强生成-RAG
把向量搜索技术和大模型上下文学习的能力相结合,就发展出了检索增强生成技术,也就是 RAG。当用户提交一个问题,比如“靠近西湖适合一家四口人居住并且简约风格的民宿”,我们先让大语言模型改写这个问题,然后用文本嵌入模型为改写好的问题生成嵌入向量。接下来再通过向量搜索找出跟这个问题对应的嵌入向量最近的一些嵌入向量所对应的民宿。然后再把这些民宿的描述以及用户的问题同时作为上下文输入给大语言模型,大语言模型就可以通过刚才所说的上下文学习(也就是 In-context-learning)的能力去理解这些信息,并且根据这些信息给出答案。
- 业务数据驱动智能方式三:模型微调
业务数据驱动智能的第三个方式是模型微调。检索增强生成技术通过文本嵌入模型把数据变成嵌入向量,也就是知识。而模型微调的基本想法是让通用模型去学习业务相关的领域知识,从而让这些领域知识成为模型的内在能力。微调的流程首先把业务数据做各种清洗加工,然后让大语言模型去学习这些高质量的数据集,从而成为一个理解业务数据的一个大语言模型。微调的方式一般会分为四种:无监督微调、蒸馏、监督微调、以及强化学习。
简单地介绍一下这些微调方式的原理:
- 无监督微调简单地说就是博览群书。比如想让大语言模型理解古文,需要先找到一些高质量的古文书,然后让大语言模型阅读这些书。通过这种泛读的方式,大语言模型就能总结出古文用字的一些内在规律,就有了一定的古文素养,从而有知识和能力做和古文相关的任务。
- 蒸馏这种方式可以理解为找一个老师,跟着老师学。跟着一个古文素养很高的老师学,借助老师能够更快更好地学到古文的精髓。
- 监督微调:除了上面提到的两个没有明确目的的素质教育之外,应试教育在某些场景也同样重要。即便大语言模型经过各种素质教育,有了比较好的古文素养,并不代表着它在考试中一定可以得到高分。比如说让大语言模型去参加科举考试,如果没有培训过八股文的写作,那它就可能因为写的文章不符合规范而得不到好的成绩。应试教育做的就是这种对齐工作,让大语言模型知道人类在完成某些任务时的一些偏好。最直接的对齐方式是监督微调。在这个例子里,就是让大语言模型学习历届八股文的考题和范文。通过这种方式,大语言模型就明白了八股文的规范,就学会了如何把古文能力用八股文这种方式表现出来。
- 另外一种对齐方式是强化学习。这种学习方式不会告诉模型什么是正确答案,但是会给模型写的文章进行打分,告诉模型这篇文章写得好还是不好。通过反复的试验模型就会找到获得高分的写作手法,从而按照人类的期望高质量地完成任务。
简单总结一下,生成式 AI 和业务数据结合有三种方式:第一个是上下文学习,也就是 In Context Learning;第二个是基于向量搜索和上下文学习的检索增强生成,也就是 RAG。第三种方式是各种模型微调。在实际的应用中,往往会把各种方式结合在一起,还可能使用外部的工具,这类智能的应用就叫做数据智能体,也就是 AI Agent。
- 数据智能体:AI Agent
在这个民宿的例子中,可以想象一个虚拟旅游顾问。用户可以向这个虚拟旅游顾问咨询任何关于旅游的问题。比如为一家四口人设计一个杭州三天的旅行计划,并且根据用户反馈进行修改,形成用户满意的方案后自动完成各种机票、民宿、以及景点的预定。为了完成这些功能,虚拟旅行顾问就需要利用大语言模型的能力去做规划,使用推荐系统找出用户可能喜欢的杭州的景点,找出这些景点附近用户可能喜欢的民宿,等等。这样一个 AI Agent 能够综合大语言模型的能力并且灵活使用外部的工具。
05 现有架构的弊端
再次审视业务架构,为了实现这些这样一个 AI Agent,需要一个极其复杂的数据架构。这种数据架构有很多弊端。这些弊端可以从三个不同的视角来看。
- 开发视角:构建这样复杂的架构有较高的开发门槛。开发人员需要学习和理解多个不同的数据产品,每个数据产品都有一些局限性,开发人员还需要去理解和绕开这些问题。对很多中小公司来说,招到这么多优秀的数据和 AI 工程师是个挑战,从而导致很多数据的业务价值并没有完全地挖掘出来。即使团队很幸运拥有这些工程师,他们也需要把大量的时间花在繁琐的数据同步上,这无疑极大地降低了开发效率,降低了业务的迭代速度,阻碍了业务的发展。
- 运维视角:要运维这么多产品,势必给运维带来复杂度。特别是数据同步,它往往是一个系统中最薄弱的环节,很容易导致系统的不稳定。同时因为一份数据需要在多个产品中重复存储,也带来了更大的成本。
- 业务视角:虽然我们刚才所看到架构是从业务需求倒逼出来的,但是从业务视角来看,它也不是完美的。因为我们需要做各个产品之间的数据同步,这就无法避免数据延迟的问题。数据延迟会导致业务看到数据可能不一致,从而导致业务的问题。
06 新一代数据系统:分布式 Data Warebase
为了能够让系统没有数据延迟,唯一的选择是让数据同步不再是一种必要而是一个选择。这就意味着我们需要用同一份数据支持刚才我们所说的各种场景。综合评估下来关系型数据库的功能最完备,离我们的最终目标最接近。所以我们决定以关系型数据库为出发点去吸取其他产品的一些核心技术。
先从语言层次来看这个问题,关系型数据库使用的语言是关系模型,它能够很好地表达结构化的数据。为了能够很好地表达半结构化的数据,可以引入 JSON 类型。这样我们就能够表达信息层的两种语言。知识层的语言是嵌入向量,通过引入高维向量这种类型,知识也就成为了系统的一等公民。这种做法允许我们在一个表里同时存储结构化数据、半结构化数据、以及表达知识的嵌入向量。
接下来从性能的角度来分析。示例中构建民宿平台需要使用这么多数据产品的一个重要的原因是性能。要彻底解决系统的性能瓶颈,需要做五个重大性能相关的改进:
- 首先为了能够通过增加更多的机器的方式提升系统的性能并且保持数据的一致性,就需要实现分布式事务,然后就能通过数据分片这种横向扩展方式提升系统的性能。
- 搜索的场景。之所以引入搜索引擎,是因为关系型数据库即使在单机的情况下搜索的效率也很差。为了提升单机搜索性能,可以引入像倒排索引这样的索引结构。同样为了提升向量搜索的性能,也可以引入向量索引。
- 为了支持高效的汇总分析,引入列式存储。它能够提升数据压缩率,避免大量不必要的 IO,提升系统的分析性能。
- 通过向量化的执行引擎提升复杂查询的执行效率。
- 通过物化视图这种预计算的方式去避免反复执行同样的查询,进一步提升系统的性能。
通过这些技术的变革,就可以构建出一类全新的数据产品:分布式 Data Warebase。Data Warebase 这个词是 Data Warehouse 和 Database 这两个词的组合,它意味着 Data Warebase 同时具有了 Data Warehouse 和 Database 的所有能力和优势。
分布式 Data Warebase 能够存储所有的数据、信息和知识:它通过关系模型存储结构化的数据;通过文档模型也就是 JSON 这种方式存储半结构化的数据;并且通过高维向量去存储从传统意义上的非结构化数据中提取的知识。它能够支持简单查询、关键词查询、以及汇总分析这类信息提取的需求,也能够通过向量搜索去提取知识。分布式 Data Warebase 在性能、正确性、和实时性上挑战可能的物理极限。分布式 Data Warebase 给用户提供极简的体验,它兼容已有的生态,减少学习成本,最大限度地发挥现有生态工具的能力。它通过隔离去保证不同场景之间互相不影响。通过自适应保证它不仅在最苛刻的业务场景达到性能、正确性、和实时性的最优,而且在用户的实际场景里也能够挑战极限,达到具体场景里性能、准确性、和实时性的最优。
分布式 Data Warebase 将开启数据智能的新范式。它将使业务的数据架构大大简化,工程师不再需要耗费大量的时间搭建系统,而是把重心放在业务需求的开发上。
07 数据系统新的使命 - 让数据涌现智能
总结一下,数据首先以比特的形式存储在数据系统之中。系统并不理解数据,数据在系统中还不具备任何智能。通过引入关系模型或文档模型这类表达信息的语言,这些元数据给数据提供了上下文,赋予了数据结构,就产生了信息。建立在这些数据模型之上的关系型数据库、NoSQL 数据库、以及数仓等产品为信息的存储、提取、管理、以及汇总分析提供了强大的工具,促进了互联网业务的快速发展。再往上是知识层的抽象,我们引入了嵌入向量这种强大的数学语言来表达知识。这种全新的语言为高效地表达和处理知识打开了大门,系统的智能也变得更加高级。再往上是智慧层,当奇点到来 ,AGI 实现之后,机器也会和人一样具有智慧,可以对知识做深刻的推理,并且做出战略性的决策。也许当那天到来我们将会发现表达智慧的新语言。
可以看到过去这些年数据系统的发展,已经从信息层逐渐转移到知识层。数据系统的使命也在悄然发生变化。它不再满足于存储、提取、管理、以及汇总分析信息。表达、理解和使用知识将会成为数据系统的一个重要部分。我们断言数据系统新的使命将会是:让数据涌现智能!
蒋晓伟
曾任阿里巴巴研究员,创建了阿里云 Flink 和 Hologres 团队和产品;曾任 Facebook 调度系统,时间轴和 Messenger 的技术主管;曾任微软 SQL Server 引擎架构师;美国西北大学理论物理硕士学位,中国科学技术大学理论物理学士学位。