杨成虎：存储&计算是过去，记忆&推理才是未来

导读 在 Fabarta 产品和用户大会 2023  上，Fabarta 联合创始人兼 CTO 杨成虎为大家带来了主题为“AI 时代的数据基础设施，企业智能发展的新引擎”的演讲。他详细阐述了 Fabarta 技术的创新之处，并结合真实应用场景展现其在业务中的实际价值。本文和大家深入探讨 Fabarta 是如何为企业构建智能发展的新引擎。全文目录：1. 企业智能中的 Large Model 与 Knowledge2. 多模态智能引擎 ArcNeural3. ArcNeural 2.1 版本核心特征4.『一体两翼』产品矩阵5. 企业智能 IT —— Arc426. 演示 1 ：图+向量解决模型幻觉问题7.  演示 2：图+多路召回帮助答案更精准分享嘉宾｜杨成虎 Fabarta CTO出品社区｜DataFun

---

杨成虎 ｜ Fabarta 联合创始人兼 CTO

企业智能中的 Large Model 与 Knowledge

目前在企业数据智能领域，我们不仅拥有了知识图谱，也逐渐开始普及大语言模型技术。但它们都有鲜明的优缺点。

通常对于大模型的技术落地，首先需要大量的公有数据进行训练，其次要针对企业内部数据进行一定程度的 finetune。大模型给企业带来了智能交互界面，并且通过智能生成显著提高工作效率，但我们也发现了一些挑战性难题难以解决：首先，大模型知识难以更新。企业内部数据往往是在持续更新，无论是根据外部政策法规的要求还是企业内部发展，都会引起数据更新变化，但每次的更新都要进行 finetune的成本巨大，时效性与效果也得不到保证，稍有不慎还会引起原有模型的效果倒退，甚至崩溃。其次，大模型缺乏企业级的严谨性。例如大模型的幻觉问题不可避免的情况下，如何确保输出严谨可靠，避免对人产生误导性，仍然是难以解决的问题。其次，在数据安全上，缺乏分类分级的办法。

那么传统以数据库为中心的企业知识图谱架构下，相关的缺点却变成了优势。数据库经历了多年发展，不仅服务成本降低到了非常低的水平，且数据管理效率高，尤其是数据处理精准可靠。然而，面对现代的智能化业务场景，传统数据库也存在局限性。缺乏智能化的数据处理模式，难以实现数据“洞察”。对不同的数据内容难以自动化的产生关联。由此可见大模型和知识图谱之间存在很强的互补性。

所以，我们提出了一个新的架构，即以数据为中心的概念去构建我们一体两翼，深度整合大模型与知识图谱数据库，构建新数据智能范式。

Data Centric LLM

这张图自下向上来看，对应我们的数据生产、数据管理、数据消费。最底层，是 ArcFabric 多模态数据编织平台，负责组织和管理企业数据，提取企业数据关系与元数据。ArcFabric 将企业的私有数据整合处理后传递给 ArcNeural 智能多模态引擎来数据管理。最顶层，我们利用 ArcPilot 企业智能分析平台来展现业务属性，基于此之上来构建企业智能应用。

在数据生产、管理、消费层，我们均与大模型深度结合在一起。在数据生产层，利用大模型技术进行知识生成和补充，大幅度降低传统知识图谱构建门槛。在数据消费层，大模型赋能平台产品，使其具备自然语言理解能力，结合企业垂直业务，提高效能。在数据管理层 ArcNeural，是数据智能体。打破传统数据库计算加存储的本质，引入记忆加逻辑体系。其中，记忆部分为多模态智能引擎，支持图模型和向量引擎，分别负责显式和隐式关系管理。逻辑部分则利用图算法或 LLM 资源来进行逻辑推理。

在 ArcNeural 架构下，天然的具备了三大优势：

1. 数据的私有性、安全性和可控性：数据存储于多模态数据库中，数据库具有完备的数据管理安全能力。而不是存储于大模型中，数据读取不受控。
2. 自然语言识别能力：数据洞察能力具备智能化， 不仅实现了自然语言查询与查询生成， 还可以作为数据补充的辅助；
3. 结果可解释性和追溯性：数据结果并不直接来自大模型，而是通过大模型构建中间查询计划，再通过数据库执行对应的查询计划与一定的数据整合能力而产生数据结果。在整个过程中，查询计划可固化、可追溯、可调优。

多模态智能引擎 ArcNeural

接下来我们进一步的介绍 ArcNeural 的记忆和逻辑部分。

记忆部分我们称作 ArcNeural 多模态数据库。这个数据库有三大核心特点：

1. Graph HTAP：我们为用户提供了统一支持的高性能实时查询，并同时具备弹性的 AP 和 TP。不同于传统企业采购 Graph 时需要分别购买 TP 和 AP 两套系统，我们为您提供了一个一体化的 TP/AP 一体解决方案；
2. 多引擎支持：我们不仅支持图数据引擎，还支持向量化引擎。通过插拔式引擎设计让我们能同时处理多种数据模态；
3. 云原生架构：新一代数据库的显著特点，实现了存储和计算的分离。其中，蓝色主体部分代表我们的计算节点，而数据则存储在分布式共享存储上。这种存储方式既可以基于 OSS 存储，也可以采用其他分布式块存储，确保了存储与计算的分离弹性；

ArcNeural 多模态数据库为企业提供了一个高效、弹性和现代化的数据库解决方案。我们从存储、查询和计算的细节上进行介绍技术细节。

• 多模态智能引擎 ArcNeural：存储层的架构

我们根据不同的存储介质分了三层存储架构。首先是内存层。内存提供了最高效的数据访问性能，使得数据访问速度极快，但相对昂贵，容量也有限。我们根据内存特点设计了完全基于内存的图拓扑结构，以提升图随机查找和多跳查询的性能。而属性（字段）是标准格式化的，我们采用 LRU 缓存管理。向量索引部分的索引也是常驻在内存中。此外，在内存引擎上还有实现脏页管理，MVCC、Cache 优化及无锁等技术手段，内存引擎是 ArcNeural 作为高性能数据库的基础。

第二层是基于 SSD 等固态存储介质的本地存储，在云环境下一般是单盘或者系统盘，顺序写入性能较好。因此它只做一件事情，即持久化日志（Log）。日志作为数据库的核心，日志的安全意味着数据安全可靠、不丢失。所以这里辅助 Raft 协议，多机副本，保证多份可靠。同时，日志的顺序写入，也对应着固态存储最佳实践。

最后是远端存储。它的主要职责是异步的日志刷写。我们提供三种远端存储交付模式以满足不同客户的需求：首先，我们支持分布式 K/V 存储，适应有 K/V 系统需求的客户，ArcNeural 可直接部署并将数据配置转换为 K/V 形式。其次，为满足边缘部署或小规模验证的需求，我们提供本地部署方案，通过单块磁盘迅速启动。最后，为了确保最优性能和弹性，我们支持分布式存储，确保高效率和低成本的同时也具有高可靠性。整体的远端存储都是异步化写入，所以对其性能要求并不高。根据不同的场景，按需交付。既可以做到敏捷交付，也可以面向云环境大规模部署。

总结一下：通过内存引擎实现高性能，本地存储配合 Raft 协议负责核心的日志数据，远端存储形态与产品内核解耦，按需交付。

• 多模态智能引擎 ArcNeural：HTAP Graph 技术

在存储层之上，我们集成了强大的 HTAP（Hybrid Transactional and Analytical Processing）计算能力，它专为低延迟、高并发和复杂的实时计算设计。对于更为复杂的离线的 T+1 需求，我们的系统也提供完善的支持。

当执行 TP（Transaction Processing）请求时，系统首先进行语义识别并对查询语句进行分析，分别执行对应的TP和AP部分。TP场景的高性能查询由TP引擎进行并发拆解算子，之后进行并发并行查询，从而实现在图数据模型下的低延迟。当遇到AP请求或Call命令调用的图算法请求时，则由HTAP引擎负责执行处理，HTAP引擎首先获得查询子图，再传递给AP计算引擎，AP经过负责的计算处理返回结果。此外，AP引擎也支持从数据库外部加载数据，例如从Hadoop或者对象存储上加载大数据。

由此即支持了HTAP处理，也支持离线图计算分析。此外，我们统一了图查询语言，一套语言，一个系统即可完成图业务的全场景使用。因为我们的图数据是从TP引擎中动态加载的，因此保证了计算分析数据的新鲜度，做到了实时更新。不同于传统TP和AP分离结构，避免了数据同步链路的不稳定和数据延迟问题。

AP计算节点也实现了Serverless能力，根据用户请求负载差异，动态扩缩容。我们将进一步介绍 AP 的 Serverless 计算。

• 多模态智能引擎 ArcNeural：Serverless 技术

针对AP业务特点，ArcNeural实现了弹性云原生，按需使用资源，即Serverless化。在线交易TP类请求，往往需要稳定的服务能力以保障高吞吐下的延迟确定性，并能够承载一定程度的流量波峰。而在线分析AP类请求，通常的业务负载并发不高，调用频次相对低，延迟要求不高，但单次请求的计算需求差异很大。因此，需要提供Serverless能力来优化成本使用，且具备弹性能力。

以一个具体的HTAP查询为例：假设我们想通过一条查询语句来了解公司中哪位员工更喜欢哪位员工，并通过这种关系来确定公司中的意见领袖。首先，系统会执行 TP 处理，在 TP 引擎中查询谁喜欢谁，并得到一个子图，这是一个经典的 TP 多跳查询。查询完成后，会调用 AP 系统。当 AP 系统收到这个命令后，它知道需要执行一个 PageRank 计算，就会自动从资源池中申请 AP 节点，组成一个小型的 AP 集群，然后将查询得到的子图发送过去进行计算。计算完成后，相关资源会被回收，实现AP请求粒度Serverless 。

• 多模态智能引擎 ArcNeural：混合多模态存储（Vector Column Type）

像刚才大家讲多模态，我们对于向量是怎么去做的呢，我们把整个向量和图进行深度融合，我们将它统一到图的模式里。为了达到这一目标，我们为图属性字段提供了向量类型的字段支持，实现了图结构中的向量能力。

以电影知识图谱为例：影片与制作人作为顶点，形成图拓扑关系，每部电影都有其独特的 ID 和其他信息（如标题、年份等），这些信息我们可以使用 JSON 进行表达。此外，我们将电影的内容或简介的文本描述进行向量化处理，并将这些向量数据作为电影顶点的属性字段存储在图数据中。

针对向量字段的索引部分，通过 HNSW 索引来加速向量数据的检索。这种索引与图数据的处理结构非常相似，因为它也采用了类似多层图的数据结构。并且使用 HNSW 索引的优点是其检索效率高且召回率较高。为了进一步实现图与向量数据的整合处理，我们在系统中加入了以下三个特性：

1. 使用 SIMD 进行距离计算加速，与传统方式相比，我们的方法可以提高 4 倍的性能。
2. 支持属性过滤的向量检索功能，同类系统只能进行纯向量检索，而不能进行其他字段（标量）的联合检索。
3. 通过原有图技术沉淀，我们在向量数据模型上也实现了完整的 CRUD 和 ACID 功能。

• 多模态智能引擎 ArcNeural：混合多模态查询（One Query）

我们的系统采用了 “One Query” 的设计哲学，意在为用户提供一个统一的查询接口。这不仅仅体现在数据模型的统一，更进一步在于查询语言的统一。通过一条查询语句，用户可以同时检索向量数据和图数据。

延续前面电影知识图谱的例子：我们首先创建了一个电影相关的图谱。在这个图谱中，我们想找到 2023 年上映的一部反欺诈题材的电影，并进一步查询该电影的导演还拍过哪些其他电影。这个查询任务听起来比较复杂，但在我们的系统中，用户可以使用一条简单的查询语句来完成。具体的查询语句如下所示。其中，黄色的部分是 WHERE 条件，用于筛选 2023 年上映且与反欺诈相关的电影。

这条查询语句首先会进行一个向量索引扫描，在查询计划里是一个带 FILTER 的向量 INDEX SCAN，筛选出满足条件的电影，然后继续向上传递，使用图算子对结果进行进一步的一跳、两跳查询，例如查询导演和他/她的其他作品。这种设计确保了一条语句可以同时扫描向量数据和图数据，大大简化了用户的业务研发复杂度。

ArcNeural 2.1 版本核心特征

经过一段时间积累，我们正式发布了 ArcNeural 2.1 版本。该版本主要包括以下功能特性：

1. 多模态：我们的引擎支持多种数据格式，包括图数据、向量数据、JSON 以及传统的 Table 数据结构；
2. 企业级数据管理：ArcNeural 提供完整且严谨的数据 ACID 处理能力，技术特色还包括内存引擎技术和多跳并行化处理；
3. 企业级交付方面：除了支持云原生的弹性部署，我们的解决方案还适应于分布式系统、银行的多地多中心等高级要求，并且支持模块化部署，可以根据需要进行个性部署；
4. 国产化：我们深感自豪地宣布，ArcNeural 完全满足国内的生产要求。从代码的完全可控性到对国产硬件的完美适配。在系统内核研发方面，我们使用现代编程语言 Rust 编写。最后，ArcNeural 支持面向合作企业和伙伴开源。

『一体两翼』产品矩阵

ArcNeural 为提供了数据智能体，具备完整的数据存、查、算处理能力，同时集成大模型的智能能力。但在严肃的企业2B业务场景中落地，还需要关注数据的生产端与业务数据消费端，为此，我们采用了“一体两翼”的策略。

1. 左翼 - ArcFabric：关注数据的生产
1. 数据治理和数据资产：这两个模块主要对企业数据进行管理、元信息抽取，甚至补充；
2. 产生的显式关系：例如结构化数据的血缘关系，这部分数据会存储在我们的图引擎中；
3. 产生的隐式关系：例如非结构数据的内容关联，这类数据则会存入向量引擎表达；
2. 右翼 - ArcPilot：关注数据的消费
1. 低代码平台和用户交付：使得数据的消费变得更为便捷；
2. 数据智能平台和知识中心：为企业提供强大的数据分析能力和知识存储；

右翼通过不断实现业务，通过数据积累，不断对数据知识体系进行修正，正向反馈给左翼，以帮助左翼更智能的管理企业数据，不断强化企业知识图谱。

企业智能 IT —— Arc42

基于一体两翼的理论范式，我们首先在自己企业内部去落地实践，Fabarta 作为一家企业，也有很复杂的代码，或者是文档，CRM等多样性的数据，同样需要智能化的实现内部数据管理。

带着这样的初衷我们构建了企业智能 Arc42 这套系统，这套系统中我们打通了数据的生产、管理到消费。

数据生产端将我们企业内部的，企业的组织，甚至代码通过我们 ArcFabric 的平台建了企业智能图，我们首先把显式关系抽取出来（比如文档结构在哪个目录下，大标题小标题，文档引用关系），然后进一步抽取其中隐式的关系（比如文档中心思想和哪篇相似，代码片段和哪些相似），最后通过大模型或者迭代构建完整的企业知识图谱，给我们的 ArcNeural。

数据消费端通过知识问答形式提供知识的呈现，用户提供一些传统自然语言的提问，由我们 ArcNeural 中大模型的控制器来与整个大模型交互生成相应的查询计划，生成相关多模态查询计划交给我们 ArcNeural 执行，最终得到相应的答案。

演示 1 ：图+向量解决模型幻觉问题

我们首先展示了一个采用传统大模型+向量的方案，也是大家最为熟悉的形式。在这个演示中，我们提出了一个问题：Fabarta 2.0 数据库产品是否具备区块链的功能？这里用到的大模型是业内领先的。不过，它给出的答案表明我们有相关的代码，但实际上，我们并没有开发过此类技术或产品。

这种答案背后的原因是什么呢？通过查询计划，我们可以进一步追溯。具体来说，这个误解的原因是区块链有两个核心技术：区块（Block）和交易（Transaction）。而这两个术语在数据库技术中也经常出现。例如，我们在写数据库代码时，底层存储的数据块我们会使用 Block，而数据库事务也称为 Transaction。这使得大模型在处理这类问题时往往只关注局部信息。比如，仅凭三四行代码中的 Block 和 Transaction，它确实很像区块链技术。但如果我们放大视角，会发现我们的专长是数据库技术，并非区块链。

为了提高答案的准确性，我们引入了多模态技术。请看下面这个演示，对于相同的问题，这次我们得到了一个正确的答案。通过大模型，我们制定了更为复杂的查询计划，并在查询后利用图谱进行验证。这样，我们可以更全面地验证答案的准确性。虽然确实找到了一些相关的代码，但从文章的内容、组织关系和标题来看，这些代码与区块链技术并不相关。经过交叉验证，得出的结论是：我们并不具备相关的技术。这是一个准确的答案。

演示 2：图+多路召回帮助答案更精准

接下来，我们想向大家展示，当使用传统大模型配合单维度数据时，它可能给出的答案是正确的，但并不是最准确的。

考虑这样一个场景：当我有一个关于编译器设计的技术问题，我应该去咨询谁？这并不是关于设计的具体问题，而是关于应该找谁去讨论。大模型给出了一个答案：一个叫做“小可”的同事，并附带他的代码提交记录。这些信息的确与编译器设计有关，但这并不意味着他就是最了解这个领域的人。因为真正的专家不仅仅是能够写代码，还需要深入了解架构设计。通过查看它的查询计划，我们可以看到它只考虑了代码的部分，这恰恰是单维度数据配合大模型的局限性。

那么，让我们再次看一个使用 Arc42 高精准回答的例子。这次，答案已经指向了另一位同事。从他的答案摘要中，我们可以看出，答案不仅仅基于代码，还基于文档以及谁是文档的作者，这是一个更全面的多维度数据处理。在 Arc42 中，最核心的部分是生成查询计划。这样的查询计划反映了我们与大模型交互时的数据访问步骤。我们可以将这些步骤总结为数据库查询计划，并在数据库中进行处理、总结和提取。遇到问题或疑惑，我们都可以回头查看这个查询计划，追溯大模型背后的逻辑。

看这个例子，这次的查询计划相对复杂：它先寻找相关文档，然后找到文档的作者，并进一步查看相关的组织结构。它最终形成了一个包含代码、组织和文档的复杂子图。我们使用图算法在这个子图上寻找中心点，得到了最终的答案。我对这个答案感到很兴奋，因为它与我对团队的理解高度一致。

此外，我们还可以通过大模型对这些答案进行总结，帮助大家更好地理解内容。

我今天展示的都是真实的企业数据和场景。这就是我今天想与大家分享的，谢谢大家的聆听。

往期优质文章推荐

往期推荐