EP01 AI如何颠覆数据库讨论纪要
详细的讨论会分享背景请见我们上一篇文章《AI如何颠覆软件：你能为AI打工吗？》。
我们尽量每周都会组织不同领域的AI讨论会，覆盖软件行业的所有细分。为了保持一个活跃的讨论环境，对参与人群会有限制，请有意愿参与讨论会的直接私信后台“微信号，个人介绍，以及擅长讨论什么话题”，从业者/创业者优先。
本期讨论会参与者：
邰骋，墨奇科技创始人，向量数据库创业者，师从知名的应用数学领域科学家、中国科学院院士鄂维南。主要研究方向为大规模非结构化数据处理算法和系统，在SIAM、JMLR、ICML等国际期刊会议发表多篇论文，是国内人工智能、应用数学方面的领军学者。
Haowei，Snowflake早期员工，多年数据库内核开发经验，专注容器化和虚拟化技术。
Yujia，微软Copilot产品经理，正在尝试Copilot+各种场景。
以及资深数据架构师，数据库/BI创业者，投资人，参与讨论作出的贡献。
在OLAP的场景下，需要BI和数据仓库交互。以及看到基于GPT将自然语言转成SQL的技术，然后进行数据查询的产品、Prototype等，会大大降低非技术人员和数据仓库交互的门槛 以史为鉴，当对象的使用门槛降低的时候，普及性就会越来越高。例如当图形界面GUI问世的时候，个人电脑就普及了。同样，当LLM降低数据仓库的门槛时候，越来越多的公司（而不仅仅是科技公司），都会变成Data Driven导向，或者以数据来进行决策。公司中的每一个人都可以快速根据数据决策，做决策的效率和频率都会提高。
SQL是非常古老的语言，产生于1980年代。SQL有一个问题，简单的东西非常简单，一旦复杂化后，就会变得反人类。故如果没有经过专门的训练，一般人只能拿SQL 做简单的事情。现在大语言模型把它翻译成 SQL，最长的SQL 大概存成文本文件的话大概有 20 个Megabyte，这个就完全不是人能够读的东西了。今天为什么大家都用SQL，因为说白了可能是一种习惯，但这种习惯有没有被挑战？就算没有大模型其实也正在被挑战，比如spark，现在就很多人就觉得不管是 Python还是Java，通过spark API 去写比写 SQL其实更顺利一点。所以在很多 ETL 的场景下面，现在很也不单纯用 SQL ，很多的 ETL 现在都是用 Spark ，其中原因之一就是SQL 这个语言不够直观。 SQL也是更加精确的语言，在复杂的和机器场景下的准确性要高于自然语言。很难用自然语言去精准地表达一些复杂的接口、Query。虽然现在已经出现了自然语言转SQL的GPT工具，但因为自然语言的局限复杂度不够，复杂场景仍然做不了 未来更多是简单的查询用自然语言接口，复杂的场景还是需要SQL，或者Spark、Python，SQL有很强的韧性，可以适应各种复杂场景。
当追求极致的简易性，在效率和准确上就会有牺牲，就需要自然语言。就类似于过去编程情况，如果追求便捷就会用Python，但可能会牺牲效率；如果追求效率，用C++这样更接近于机器的语言，学习曲线就会更高。 自然语言不是针对数据库查询的最优选择，但会根据使用者的情况有Trade Off。
LLM很难对计算引擎、网络等产生影响，数据库内核的发展和LLM的演变也没什么关系。 但数据库可能未来会承担更多的模型训练任务，不再是单纯的数据层的数据库，这相当于数据库从数据层往训练工具演变。
在为LLM训练的场景，可能不会很普遍，大模型需要的训练数据主要是知识，和平时公司商业用途需要查询的数据，还是两种数据。 但对于中小规模的模型，会有这类的场景，很多公司都会有内部需求。 比如简单的情况，数仓一般是Column Format，再做一个Compression，这种情况非常常见。但做AI训练的时候，一般需要Row Format。如果传了两份到storage engine之后，这两份相关性不大。存完之后是存在一个地方，是两个表还是一个表，没有什么关系。应用A（比如说一般数仓）永远不会探索为应用B（基于AI训练的结果）存的那一份。应用B也永远不会探索为应用A存的那一份。除非应用A需要用到一份，应用B需要用到同样的一份，这个时候把这张表作为一张表看待，有比较大价值。 现在的实际情况是，两个应用永远不会碰到同一份。从某种程度上来说，这两个应用physically比较独立。如果硬要把这两份数据说是属于一样表，但就像很多OLTP的表，OLAP经过ETL之后形成OLAP的表。大家也知道这两张数据库表是同样一张表，但是基于数据库的应用就把它当作两张单独的表来看。因为做OLAP的时候，永远也不会访问OLTP的那个数据表。所以如果两个应用之间没有相互的mix和match的时候，把它当成两张不同的表，在两个不同引擎里面存储，还是当成一张表有两个format来看，实际没有本质的影响。
而一定要把这两个当成一张表的两个不同引擎来看的时候，事实上增加了系统的难度。在目前的情况下，机器学习的 training 的 format 和做OLAP查询的这两种format，本身天然是不会相互碰到，也就导致了目前还没有需求非得要把这两份数据当做同一张表格的两种形态。目前可以把它当成两个单独的表格来处理，并不影响使用。
不知道将来会不会有BI的应用导致现在这种假设不成立。这是有可能的，正如HTAP。往10年前看的时候，AP是AP，TP是TP。这两年HTAP出来了，因为有真实的需求，可能对于AI和AP在过个几年也会有这样需求，但是就目前为止还看不到。
LLM很难解决ACID问题，LLM的初衷就不是为了精准查询设计的，LLM的查询结果很难保证准确的Number，也很难保证Snapshot isolation。 长期来看，LLM也很难匹配数据库的性价比，数据库都有非常复杂的场景优化。 更可能的演化，还是LLM改变了数据库的交互，但LLM本身不会成为数据库。
传统数仓/数据湖之前是提供数据源，但未来可以作为训练平台，例如替代一部分Sagemaker的场景。 从客户角度，在数仓/数据湖中做训练，尤其是训练小模型场景，可以省去移到训练平台的数据迁移成本，省去中间Pipeline的维护，省去ETL的过程，也不需要把数据放在不同系统中减少了Replica。 同样，从安全性和隐私性角度出发，未来会看到更多类似GDPR的规范，多个数据存储系统会导致数据泄露的风险加大，也需要雇专门的人去审计不同系统中的数据合规性要求。 从产品完整性的角度，数仓本来做的就是做商业决策，成为ML/AI的训练平台后也可以完善商业决策，也属于本身的计划发展方向。
GPT或者大语言模型的技术革命，会让更多企业意识到AI的价值。在过去的很多年里，AI不是一个新技术，但用得好的都是很大的科技企业，在传统企业的渗透率仍然非常非常低。GPT更像是破圈的Trigger，迫使所有公司都去尝试ML/AI，不一定是直接接入LLM，还有很多垂直的企业场景。 从具体的带动关系来看，AI训练不是只训练一次，需要不断地训练，有不断的新数据进来。每隔一段时间就要去更新模型，上线新模型。也就需要不断地向数仓/数据湖去要数据。
数据仓库最本质的还是产品能力，AI不是决定性因素
Databricks随着Dolly的推出，有机会帮助他们的一些客户更好更容易地训练大模型。
但大多数企业还是负担不起大模型的训练。所以还是更加的倾向于训练小模型，或者训练一个 good enough 的模型，或者说是一些模型的 fine tuning。就fine tuning来说其实也有很多方法，然后有一种方法，我听说是可以先训练一个比较小的模型，然后和大模型在 merge 一下，调一下权重。
Databricks和 Snowflake 其实更多的还是赋能企业，他们提供了一个平台，能帮企业更好地去训练。至于说他们开源了这个模型， Dalle2 它只是一个开源模型，还要看开源生态能不能搭建起来。
Databricks选择开源这样一个模型，在对模型的支持上就可能有偏向性，不确定是否能保证对其他模型也有很好的支持。微软也有偏向性，包括选择OpenAI。
亚马逊和Snowflake目前没有偏向性。
目前Copilot/其他大模型的目标还是降低普通/简单任务的门槛：
不管是Copilot，还是其他的大模型，目前最擅长的东西肯定不在于非常高级和难的任务，而是在于能够降低一些普通和简单任务的门槛。
不管是在 Office 的处理还是数据库，都是在拓展易用性，以及能够大规模的让一些企业去进行操作上的升级，或者是让更多的人可以做更多的事情。
大模型能够解决的问题的复杂性还取决于成本：
对于成本的问题，如果我们降低承载大模型使用的大模型相关的产品或相关的体验的使用的成本，这里其实是一个目的导向的事情，即如果我们希望它以一个什么样价格收费是市场能够接受的，或者说我们能提供的价值是否能够cover成本。
这里面有很多工程加算法的问题，像刚才提到的我们到底什么样的情况下才需要大模型，不是所有的问题和所有的处理都必须要使用大模型。
实际上各家的大模型在实际解决问题的时候，已经在考虑成本的问题了：
那这里面前期需要做一个判断，从技术上其实在微软这方面做的背后的工程量和 OpenAI 做的都很多。
虽然用户感知到好像都是GPT/LLM在回答，但这里面可能会有一些筛选，有一些情况其实传统的搜索或者更早期的AI就能有一个非常好的结果的时候，就不会再去用高级的模型。
其实这上面会有，就包括数据库之后的应用，这方面也会有很多的方法可以降低这个成本。
邰博士之前主要做向量的算法、图的算法，也在北大教授人工智能课程。最早做向量数据库的时候还不叫向量数据库，但会用到很多向量和图。 在大模型之前主要是用作搜索/推荐，以前像Google做网页搜索的时候，有一些关键词特征，就是向量特征。除了搜索引擎外，还会用到例如微博中。 后来在计算机视觉中也有了向量表示，图像可以变成一个向量的表示，这些都是为了做向量搜索的。语音也是同样的，可以做声纹比较。在Bio-informatics里，也可以基于基因相似的序列、蛋白质的结构比例等等。
向量数据，同传统数据库里面有整型、字符串，比较新的比如地理信息的一些坐标等，也是一种数据类型。
LLM出现后，向量的这种数据类型将会变得更加重要。意味着不同的数据库往后都要需要支持向量。而专门为这种数据类型做一些Data Infrastructure的优化也变得更加必要。为了优化结构化数据的读写，产生了TP；为了优化海量数据的计算，产生了AP；为了优化非结构化数据，产生了文件数据库等。针对向量数据，怎么如何做存储，怎么如何做索引，怎么如何做高性能的查询、压缩等等进行专门的优化也是非常必要的，使之能够让其更好的面向 AI 应用。
除了向量，在这个场景，以后可能还会有更多其他的类型的数据。图也是很重要的类型（并不是现在见到的大图，可能是一些小的图等等，可能就几百节点，但是数量会很多，就跟向量一样，可能是多个向量组成的这些图），也是以后可能的演化。
现在很多情况向量是作为一个数据类型在做的，Workflow 里面的很多环节它都有关系。比如原始数据，ETL进分析型数据库，再向量化进向量数据库。
Huggingface 上很多这样的模型，可以把不同类型的语音文本、pdf等向量化。Metadata的结构化的特征，或者是模型预测的这种标签的特征，也会向量化。
从学习框架上来讲：在训练模型和推理过程中，现在都可以用到一些向量，当然不是所有的都用。现在的Transformer架构，加一个外置的Memory ，可以在参数不大的情况下，达到和大参数模型一样的效果。其实就是外挂的向量数据库加上一个中小模型，可以得到一个很好的效果。
然后在推理应用的层面上，如做搜索引擎，做行业应用等等。要把不同的类型整合在一起做一些分析，这更多是偏向于分析型的应用，如果最单纯的那种向量近似搜索的话，或者精确搜索的话，只是针对这种类型的分析。当然很多刚才讲的应用里面，像 flaw detection 推荐系统，要跟结构化的特征一起做联合的分析。先写一段SQL，用结构化的信息做一些过滤，做一个过滤，然后再用向量做一些查询找一些相似的例子等等。这反而是在应用中非常常见的，就是在这种实际应用中，都是要跟结构化的数据做结合的。单纯用向量这个我觉得可能看到的还少一点，可能只是作为召回这种情况或者更简单的使用，或者模型训练的使用。
联合应用的情况会更多，比如墨奇做的MyScale数据库，针对Clickhouse进行了二次开发，在这个基础上开发了一个新的引擎，它可以对向量、对图做一些联合的查询。可以分析向量，也可以分析原来结构化的数据。
这就是说从前到后，从数据源、数据的转化、包括跟机器去做大模型、到应用层等等，存在一个紧密的关系。把向量作为一个环节来看，让他跟其他的数据做一些紧密的结合，联合的分析会更有用。
分析型数据库也有必要与向量数据结合：
墨奇+Clickhouse已经在做这方面的工作了，Elastic和PG也有向量插件了。未来有必要专门为AI做一个新兴的数据库，支持AI Native应用，对数据的查询要求和过去可能会有差别。
未来单一的向量数据库可能是一个比较薄的产品，更多是和现有的分析型数据库结合。
例如一个很适合的向量数据库+Clickhouse场景就是大模型推理，比如 GPT 3，它context size是很有限的。现在GPT 到GPT3 token 的 size 从 8000 变成了这个 2 万多，提高3 倍的contact size, 需要的计算量~ 9 倍，是个平方的关系，所以 long-term memory 是大模型的问题。那现在有向量数据库，可以充当这个 long-term memory。很多人做一些算法上改善的尝试，目前都没有成功，包括用一些逼近的方法，包括用linear attention，但都失败了，那full attention 在一段时间内还是要长期要在的。这样的话，在一段时间内可能就需要有一个外置的memory，通过long-term memory 来解决大模型的问题，这就是大模型带起来的最大的一个需求。我觉得向量数据库充当这个long-term memory，就是非常合适。
还有比如相似人的查询，或图的搜索任务。或者再加一些别的限制，可能这个在“我的品类”者“商品推荐”，在这个类型中，我们找一个跟竞品比较像的，或者怎么样。就所有这些任务，推荐等等，都是有结构化的描述在这里，也很适合和向量数据库结合。
还有比如全文检索跟ES也可以结合，向量可以解决模糊搜索和语义搜索的需求。
例如Google的很多论文都在讲，中等规模模型+外界大数据库，那可以实现更大规模模型的效果。如果看OpenAI之前的论文的话，也将很多类似的。 如果有很好的、精标的数据集，然后有很好的人工干预，那么不用大模型，几百亿级别的模型也可以做到和千亿级别模型一样的效果。
针对向量的压缩、索引、查询的优化都还有很多空间。从向量算法来看，现在开源的库很多，像Pinecone、Milvus等等，开发者可能用ivf、hsw这些，做深入优化工作，可以使得性能、Density等提高很多，例如墨奇的压缩就做得很好，可以比过去存10数十倍以上的数据。
从AI应用的角度来看，向量数据库会成为LLM在性价比上的补充：
高质量性能的外部数据库，对训练和推理上都会有很大的助力，也就需要一个向量+分析都能支持很好的数据库。
未来会走向一个融合引擎的数据库，支持向量、图、全文检索、结构化数据等类型
分析性数据库（OLAP）做向量更加有意义，例如Elastic做得意义就大于MongoDB来做。 Elastic已经尝试添加了子向量模块，包括向量检索的功能，但是跟完整的向量数据库相比，功能差距还很大。 目前传统数据库厂家还没有根据向量这一特殊类型，去优化存储和计算引擎，更多是接入库和简单算法。想要做到向量数据库的能力，还要做到算法层面优化，不能只靠开源生态。 MongoDB结合得不紧密，分析型场景对于MongoDB也不是主要的。 Clickhouse非常适合做向量数据库，墨奇也给Clickhouse贡献了很多Feature。
第一，比较本质的，比如GPT 3，它使用到21年9月份的数据，那练完之后模型里面存的知识就是静态，不能被更新。然后它的 context size，需要实时的信息，比如说，这周华南地区的销售怎么样？可以问GPT，但它不能告诉你答案，即便给了答案也不是真实的。所以只能是跟数据库结合，有一个实时数据源，提供给它这种实时的信息。那么向量数据库它可以这种包括跟数据库的结合，这里不只是向量数据库，跟实时数据源的结合，可以解决这个实时性的问题。
第二，精确性的问题。在搜索里面用的很多。知识存在大模型的参数里面，也是有记忆的，但是很难精确的去取回一些信息。问大模型两次问题答案会不一样。希望有很精确的信息的时候，在数据库里面是可以有非常精确的东西，有这种可靠性。所以要很精确的信息的时候，可以在这里做企业搜索，文档搜索，这种数据库的查询就会非常有用。
第三，数据权限跟管理的问题。比如想问CTO薪酬是多少，类似这种信息不能够放在大模型里面，因为放进之后所有人都能 access 大模型，无意之间泄露重要信息。包括政府等客户的信息，不能把这些加入到训练语料当中去。这些信息还是要放到数据库里再来做，所以天然可能就形成一个模式：非实时的信息，不敏感的信息，但是又有系统性，规律性的东西，作为领域知识的、行业知识，或者更通用的一般的知识，放到大模型里面去，形成一个载体；另一个载体是承载实时的、精确的，有权限、隐私要求的信息，那么放到数据库。
LLM厂商都有尝试去解决，但目前进展一般：
OpenAI 有一些新的插件也是为了暂时的去解决这些问题，但在短期内不容易有很大优化。 到 GPT 5/6，也不会有太大的改进，还是需要依靠外部memory的这种结合来提高它的 effective context size。
ETL本身也是一个工程问题，会有一定的复杂性，但是从目前来看用大模型已经可以去解决一些ETL需求：
像大模型包括 GBT-4，做这类事情很多效果都远超预期。去年这个时候都不会觉得它有那么好。但特别从去年 10 月份之后到现在，performance好了很多。过去很难用规则表达的，或者一般小的模型难处理好的东西，就是或者不愿意去fine-tune一个小的模型的任务，现在变得很容易。
过去做这个事情：以最复杂的PDF为例（PDF内可能包含文字、图，尤其是PPT 转的PDF，里面内容很多）。过去做法是训练一个 Bert 或 fine-tune Bert， fine -tune 很多模型去解决不同的数据转化。这都导致在于是要么很高的训练模型的门槛，或者要么在一个场景需要做有很多模型。
然后现在的大模型，比如说让他去抽取简历，去抽取PDF格式的年报的信息，效果真的是都非常好。感觉实际效果跟人工标的那个准确率其实都差不多的，但是使用过程要快很多。
这带来一个更大的一个好处：过去要维护很多的中小模型，现在通过一个大模型，然后再加上prompt 和 Meta prompt engineering，就可以做很多事情。维护成本变得很低，效果也不差。
成本角度，如果都用大模型来做特征提取的工作的话，成本会很贵很高，因为chatgpt按 token来收费。但也有很多别的做法可以降低成本，比如Stanford，Databricks，还有国内的一些公司在做的事情。方法是用 GPT 4来产生很多的标签数据。比如说一天可以产生10 万个 GPT 4/100 万个 GPT 4 的样例，然后用它来 finetune 一个自己训练的百亿的模型，到时候就不用再调用 GPT 4 了。就直接用finetune好的这个模型，然后用来做ETL，会便宜一个数量级（vs 都调用GPT4）。
目前成本对于企业内的一些智能文档等场景，是可以承受的，但是就是就是它蒸馏之后，或者是根据 instruction tuning 之后，这个成本对于哪些场景目前是可以接受的？
如果是蒸馏之后，就是说 fine tune 之后，比方用一个百亿的模型再做一些整治，其实成本是比较低的。可能还有一些成本更低的，像大家开源的模型这块得也是挺大的一个力量。在很多ETL任务上已经到了一个很可用的程度了。
MyScale 是墨奇科技研发的一款用于向量计算的高性能数据库。一方面，MyScale基于ClickHouse内核开发，兼顾了极强的向量数据处理能力和极好的OLAP型数据库的复杂数据分析能力，同时完整支持SQL语言，极大降低了数据迁移和开发者学习成本；另一方面，MyScale在精确检索、结构化数据和非结构化数据联合查询、高密度索引存储等任务上实现了自研算法的核心突破，主要指标显著优于同类产品，处于世界领先地位。
随着大语言模型的技术突破，向量数据库+大语言模型这种新范式的重要价值也迅速凸显。通过对领域知识的海量数据进行向量化并存储在向量数据库中，可以很大程度上解决大语言模型的几个主要缺陷：无法有效覆盖时效性数据和领域数据；生成内容缺乏事实依据；输入/输出的内容长度显著。通过向量检索+大语言模型的结合，生成式AI的回复将更可控、可解释、可溯源。
目前MyScale的Cloud版本已经进入内测阶段，只需通过简单的注册，即可免费享有数百万规模向量数据的处理能力，欢迎访问https://myscale.com/进行体验！
【AI如何颠覆软件：你能为AI打工吗】