用Rust編寫(xiě)核心組件！獨(dú)家揭露阿里云開(kāi)源GraphScope如何成為全球最快圖計(jì)算引擎

上個(gè)月，國(guó)際權(quán)威圖基準(zhǔn)測(cè)評(píng)“LDBC SNB Interactive”（社交網(wǎng)絡(luò) - 交互查詢(xún)）榜單更新中出現(xiàn)關(guān)鍵突破：阿里云開(kāi)源的圖計(jì)算引擎 GraphScope 登頂并打破榜單歷史紀(jì)錄，性能達(dá)此前紀(jì)錄保持者 2.45 倍。

LDBC 全稱(chēng) Linked Data Benchmark Council，是一個(gè)致力于發(fā)展圖數(shù)據(jù)管理的產(chǎn)業(yè)聯(lián)盟國(guó)際權(quán)威非盈利組織，其成員來(lái)自工業(yè)界和學(xué)術(shù)界，包括 Intel、AWS、Neo4j、TigerGraph 和 Oracle 等。

在此次基準(zhǔn)測(cè)評(píng)中，GraphScope 以超過(guò) 33,000 QPS 的吞吐量排名第一。GraphScope 是阿里云自研的一站式圖計(jì)算系統(tǒng)，于 2020 年 12 月開(kāi)源，在 GitHub 上已超過(guò) 2.6k star。

GitHub 地址：
https://github.com/alibaba/GraphScope

不可或缺的圖計(jì)算

在阿里巴巴的電商推薦、搜索、風(fēng)控等場(chǎng)景中，有很多地方會(huì)用到 GraphScope 圖計(jì)算引擎。

自 2020 年起的多年雙十一期間，阿里巴巴的搜索以及風(fēng)控團(tuán)隊(duì)采用 GraphScope 作為底部支撐實(shí)施了準(zhǔn)實(shí)時(shí)欺詐檢測(cè)，虛假訂單檢測(cè)能實(shí)現(xiàn)秒級(jí)識(shí)別，評(píng)測(cè)準(zhǔn)確度達(dá)到了 97%。在此之前虛假訂單一般需要等到第二天才能處理。

另外，在推薦場(chǎng)景中，常會(huì)用到鏈路預(yù)測(cè)，通過(guò)已知的網(wǎng)絡(luò)結(jié)構(gòu)預(yù)測(cè)尚未發(fā)生連邊的兩個(gè)節(jié)點(diǎn)之前產(chǎn)生連接的可能性。比如對(duì)社交網(wǎng)絡(luò)做關(guān)系分析時(shí)，共同鄰居是一個(gè)重要的特征，它標(biāo)記了兩個(gè)不直接關(guān)聯(lián)的點(diǎn)之間共同的好友關(guān)系。

這個(gè)應(yīng)用如果用傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)寫(xiě)查詢(xún)，會(huì)十分復(fù)雜，事實(shí)上，很多業(yè)務(wù)場(chǎng)景確實(shí)是通過(guò) SQL + 一些 UDF 的方式寫(xiě)的。但由于復(fù)雜度的問(wèn)題，要舍棄一些精度以及引入很多近似計(jì)算才能在一個(gè)很大規(guī)模的數(shù)據(jù)集上成功跑下來(lái)，但千億規(guī)模的數(shù)據(jù)上需要近 10 個(gè)小時(shí)。

這種情況采用圖建模的話(huà)，共同鄰居的查找就十分直觀(guān)，也很容易寫(xiě)。GraphScope 系統(tǒng)通過(guò)基于子圖模型、增量化計(jì)算等技術(shù)，能高效的支撐千億規(guī)模以上的圖計(jì)算，并且由于圖建?？梢詼?zhǔn)確計(jì)算共同鄰居，避免精度損失。這類(lèi)之前用時(shí) 10 小時(shí)的計(jì)算任務(wù)，用 GraphScope 只需要約 600 秒。

現(xiàn)在，在阿里巴巴內(nèi)部，已經(jīng)海量任務(wù)跑在 GraphScope 圖計(jì)算引擎上，GraphScope 每天要處理數(shù)萬(wàn)個(gè)圖計(jì)算任務(wù)。

以前，相比于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)以及 SQL，圖數(shù)據(jù)庫(kù)的使用所占的比重很小。但近年來(lái)，隨著互聯(lián)網(wǎng)應(yīng)用的爆炸式增長(zhǎng)和對(duì)用戶(hù)需求的深度挖掘，大家開(kāi)始認(rèn)識(shí)到有些場(chǎng)景下，傳統(tǒng)的 SQL 處理方式已經(jīng)不能滿(mǎn)足高效的需求。而圖數(shù)據(jù)庫(kù)，與其他的文檔數(shù)據(jù)庫(kù)、KV 數(shù)據(jù)庫(kù)類(lèi)似，為復(fù)雜數(shù)據(jù)分析提供了全新的維度。特別是在需求深入挖掘關(guān)聯(lián)關(guān)系的場(chǎng)景下，圖幾乎成為了不二之選。這一趨勢(shì)的重要性在 ISO SQL 標(biāo)準(zhǔn)的 2023 版本中得到了體現(xiàn)，其中，SQL/PGQ（Property Graph Query）被納入，未來(lái)支持 SQL 的數(shù)據(jù)庫(kù)中也將支持圖的查詢(xún)。

不僅在數(shù)據(jù)庫(kù)中，圖計(jì)算已經(jīng)在大數(shù)據(jù)處理和分析中也開(kāi)始展現(xiàn)其獨(dú)特的價(jià)值和地位。根據(jù) 2022 年 8 月發(fā)布的 Gartner 報(bào)告，到 2025 年，圖計(jì)算技術(shù)將在 80% 的數(shù)據(jù)和分析創(chuàng)新中扮演核心角色。這與 2021 年的數(shù)據(jù)大相徑庭，當(dāng)時(shí)圖計(jì)算在數(shù)據(jù)和分析創(chuàng)新中的占比僅為 10%。這樣的飛速增長(zhǎng)無(wú)疑證明了圖計(jì)算在未來(lái)數(shù)據(jù)分析領(lǐng)域的至關(guān)重要性。

正因如此，該團(tuán)隊(duì)一直在持續(xù)精益求精地打磨 GraphScope。2018 年，GraphScope 團(tuán)隊(duì)的主要成員加入阿里巴巴，并將其自研圖計(jì)算技術(shù) GRAPE (GraphScope 核心引擎之一的前身) 逐漸應(yīng)用到阿里巴巴集團(tuán)和阿里云上。經(jīng)過(guò)幾年打磨和使用后，2020 年 11 月，GraphScope 在第二屆世界科技與發(fā)展論壇上重磅宣布開(kāi)源并發(fā)布了白皮書(shū)，同年 12 月代碼在 GitHub 開(kāi)源。

架構(gòu)演進(jìn)

在以往的圖計(jì)算系統(tǒng)中，由于針對(duì)不同類(lèi)型的圖計(jì)算任務(wù)設(shè)計(jì)了特定的特征，導(dǎo)致解決方案出現(xiàn)了嚴(yán)重的碎片化現(xiàn)象。這意味著每種不同類(lèi)型的圖計(jì)算任務(wù)都需要使用不同的系統(tǒng)或工具來(lái)進(jìn)行處理，導(dǎo)致系統(tǒng)架構(gòu)的復(fù)雜性急劇上升。

在處理現(xiàn)實(shí)業(yè)務(wù)時(shí)，一個(gè)復(fù)雜的工作流可能涉及多種不同類(lèi)型的圖計(jì)算任務(wù)，比如多模式的圖計(jì)算，以及需要跨越多個(gè)系統(tǒng)進(jìn)行協(xié)同的情況。舉例來(lái)說(shuō)，考慮一個(gè)包含交易圖和欺詐檢測(cè)的工作流，這可能需要在不同的系統(tǒng)中執(zhí)行不同的圖計(jì)算任務(wù)，這不僅會(huì)引入大量的 IO 開(kāi)銷(xiāo)，還會(huì)增加系統(tǒng)運(yùn)維的復(fù)雜性。

在以前的部署方式中，為了完成工作流中的不同圖計(jì)算任務(wù)，可能需要通過(guò)外部存儲(chǔ)來(lái)部署多套系統(tǒng)，增加了整個(gè)系統(tǒng)的維護(hù)難度。此外，不同系統(tǒng)之間的數(shù)據(jù)交互也變得復(fù)雜，可能需要額外的工作來(lái)確保數(shù)據(jù)一致性和有效的傳遞。

這種復(fù)雜性還使得開(kāi)發(fā)人員需要具備對(duì)多個(gè)系統(tǒng)的熟悉度，增加了開(kāi)發(fā)和維護(hù)圖計(jì)算任務(wù)的技術(shù)門(mén)檻。這對(duì)于數(shù)據(jù)科學(xué)家、算法用戶(hù)和應(yīng)用開(kāi)發(fā)方來(lái)說(shuō)，都帶來(lái)了極大的挑戰(zhàn)，限制了圖計(jì)算在業(yè)務(wù)中的應(yīng)用和發(fā)展。

在 2020 年，基于收集到的用戶(hù)需求，GraphScope 團(tuán)隊(duì)提出了一種創(chuàng)新的概念——一站式圖計(jì)算，通過(guò)一個(gè)系統(tǒng)整合了當(dāng)時(shí)的多個(gè)圖計(jì)算引擎（即當(dāng)時(shí) GRAPE、MaxGraph 和 GraphLearn）的能力，覆蓋了圖分析、圖遍歷、圖學(xué)習(xí)等多種任務(wù)。

為了實(shí)現(xiàn)這一概念，他們進(jìn)行了大量的研究和開(kāi)發(fā)工作。例如，開(kāi)展了自研的子項(xiàng)目 vineyard，這個(gè)項(xiàng)目解決了跨不同引擎之間數(shù)據(jù)交互與共享的挑戰(zhàn)。值得一提的是，vineyard 項(xiàng)目開(kāi)源后被捐贈(zèng)給了云原生大數(shù)據(jù)社區(qū)，進(jìn)入了 CNCF Sandbox。

經(jīng)過(guò)這些改進(jìn)，最終形成了 GraphScope 一站式圖計(jì)算，可以在一個(gè)平臺(tái)完成多類(lèi)圖計(jì)算任務(wù)，這也是業(yè)界首個(gè)一站式圖計(jì)算系統(tǒng)。GraphScope 的用戶(hù)們從一站式得到的好處，“從體驗(yàn)側(cè)的價(jià)值來(lái)說(shuō)，最主要的是極大程度降低了圖計(jì)算門(mén)檻，極度簡(jiǎn)化了數(shù)據(jù)科學(xué)家、算法用戶(hù)以及應(yīng)用方開(kāi)發(fā)、部署和運(yùn)維圖計(jì)算的成本，可將圖計(jì)算研發(fā)上線(xiàn)的周期從以數(shù)周計(jì)，提效為一兩天即可完成。”

組件化架構(gòu)

在此基礎(chǔ)上，為了進(jìn)一步滿(mǎn)足圖業(yè)務(wù)的多樣化和碎片化需求，GraphScope 正在推進(jìn)下一代組件化架構(gòu) GraphScope Flex，以像樂(lè)高一樣的組件化形式為各種具體的圖計(jì)算場(chǎng)景提供方便的部署、服務(wù)和計(jì)算的能力。

在這一架構(gòu)下，用戶(hù)可以根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景，靈活地選用 GraphScope 中的若干組件，從而得到最合適其業(yè)務(wù)場(chǎng)景的部署形態(tài)，形成定制化的圖計(jì)算環(huán)境。

與此對(duì)應(yīng)，本次提交的 LDBC 基準(zhǔn)測(cè)試就是基于 GraphScope Flex 架構(gòu)的高吞吐圖查詢(xún)部署方案。在這個(gè)部署模式中，他們利用自研的多層級(jí) Actor 框架 Hiactor 作為底層執(zhí)行引擎，并結(jié)合了 GraphScope 在圖存儲(chǔ)和圖分析引擎方面的積累。這種方案能夠在保障事務(wù)性要求的前提下，為用戶(hù)提供超高吞吐的圖查詢(xún)能力。

在開(kāi)源之后，GraphScope 團(tuán)隊(duì)也在不斷優(yōu)化與創(chuàng)新。比如在高效圖分析引擎上拓展了 GPU 加速，性能較之其他系統(tǒng)快 5 倍有余；通過(guò)引入新的 FLASH 高效模型，將內(nèi)置圖算法種類(lèi)擴(kuò)增到近 100 種。

Rust 編程語(yǔ)言的應(yīng)用

此外，GraphScope 還利用近期備受關(guān)注的系統(tǒng)編程語(yǔ)言 Rust 編寫(xiě)了交互式查詢(xún)的核心組件，分布式引擎 GAIA。相較于適用于高吞吐場(chǎng)景下的 hiactor 系統(tǒng)，GAIA 更著重于系統(tǒng)的擴(kuò)展性和利用并行技術(shù)優(yōu)化查詢(xún)延遲。為了構(gòu)建一個(gè)更加高效、穩(wěn)健且安全的并行系統(tǒng)，從 GAIA 的原型系統(tǒng)（發(fā)表于 NSDI 2021）起，便選用 Rust 語(yǔ)言進(jìn)行開(kāi)發(fā)。

選擇 Rust 主要是因?yàn)樗峁┑摹熬幾g時(shí)生命周期檢查”、"卓越的并發(fā)控制"，以及“媲美 C/C++ 的執(zhí)行效率”，具體來(lái)說(shuō)：

編譯時(shí)生命周期檢查：Rust 在編譯過(guò)程中提供的變量生命周期檢查功能，使我們能夠在編程的初始階段盡可能地確保程序的正確性。相比其他語(yǔ)言，這為 GAIA 這樣復(fù)雜的系統(tǒng)的實(shí)現(xiàn)提供了極高的可靠性保障，解決在分布式服務(wù)化的部署中的內(nèi)存管理問(wèn)題。

卓越的并發(fā)控制：并發(fā)編程中最常見(jiàn)的問(wèn)題包括競(jìng)態(tài)條件和死鎖。Rust 提供了各種機(jī)制來(lái)避免這些問(wèn)題的發(fā)生，包括但不限于原生的互斥鎖和讀寫(xiě)鎖，以及通過(guò) Send 和 Sync 兩個(gè)原生 trait 來(lái)保證線(xiàn)程安全。該并發(fā)控制是 GAIA 分布式系統(tǒng)實(shí)現(xiàn)的基礎(chǔ)。

媲美 C/C++ 的執(zhí)行效率：Rust 憑借零開(kāi)銷(xiāo)的抽象和底層優(yōu)化，以及優(yōu)質(zhì)的標(biāo)準(zhǔn)庫(kù)實(shí)現(xiàn)，使得其編寫(xiě)的程序能達(dá)到傳統(tǒng)面向性能的編程語(yǔ)言 C/C++ 的水準(zhǔn)。同時(shí)，通過(guò)生命周期檢查和并發(fā)控制，Rust 很大程度地避免了 C/C++ 實(shí)現(xiàn)的系統(tǒng)常遇到的內(nèi)存溢出和死鎖等難以定位和修復(fù)的問(wèn)題。

基于 GraphScope Flex 提供的組件化能力，GraphScope 可以通過(guò) GAIA 來(lái)支持更多的復(fù)雜查詢(xún)，實(shí)現(xiàn)對(duì)圖數(shù)據(jù)更為復(fù)雜和深刻的洞察與分析，未來(lái)也可以為支持 LDBC 的 SNB BI 的工作負(fù)載奠定基礎(chǔ)。

GraphScope 是如何打破紀(jì)錄的

這次，GraphScope 登頂并打破榜單歷史紀(jì)錄的基準(zhǔn)測(cè)評(píng)是 LDBC SNB Interactive ，也是業(yè)界最受認(rèn)可的圖數(shù)據(jù)庫(kù)基準(zhǔn)評(píng)測(cè)。

近年來(lái)參與 SNB Interactive 評(píng)測(cè)并在榜中領(lǐng)先的圖數(shù)據(jù)庫(kù)產(chǎn)品是螞蟻集團(tuán)開(kāi)源的圖數(shù)據(jù)庫(kù)產(chǎn)品 TuGraph，最近成績(jī)?yōu)?2023 年 1 月做的測(cè)試；另外，國(guó)內(nèi)知名圖廠(chǎng)商創(chuàng)鄰科技的 Galaxybase 也在 2022 年 5 月提交過(guò)成績(jī)。

在 LDBC SNB Interactive 評(píng)測(cè)中，為了全面評(píng)估圖數(shù)據(jù)庫(kù)，引入了復(fù)雜的數(shù)據(jù)表和多樣化的讀寫(xiě)混合查詢(xún)。背后通過(guò)一個(gè)驅(qū)動(dòng)器向待測(cè)系統(tǒng)快速、持續(xù)地發(fā)送這些查詢(xún)請(qǐng)求，主要以系統(tǒng)處理查詢(xún)的吞吐率（QPS）來(lái)衡量其性能。

其中涉及到處理技術(shù)難點(diǎn)，包括：

復(fù)雜查詢(xún)優(yōu)化：圖查詢(xún)等價(jià)于多表關(guān)聯(lián)的查詢(xún)，而此類(lèi)優(yōu)化一直是數(shù)據(jù)庫(kù)的傳統(tǒng)難題。同時(shí)，查詢(xún)中涉及復(fù)雜算子如點(diǎn)對(duì)間最短路徑，這本身就難以高效實(shí)現(xiàn)。復(fù)雜的 SNB 數(shù)據(jù)表結(jié)構(gòu)，不同類(lèi)型的數(shù)據(jù)量差異很大，不當(dāng)?shù)牟樵?xún)順序可能導(dǎo)致大量中間結(jié)果，嚴(yán)重影響執(zhí)行性能。

讀寫(xiě)并發(fā)和事務(wù)：高并發(fā)的讀寫(xiě)需要加鎖，但在高吞吐情況下，鎖開(kāi)銷(xiāo)會(huì)顯著影響性能。圖存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)需要兼顧讀寫(xiě)性能，傳統(tǒng)的結(jié)構(gòu)往往在寫(xiě)或讀性能上存在不足。同時(shí)，在高并發(fā)情況下，保證事務(wù)的一致性和效率更加困難。

高并發(fā)查詢(xún)：高并發(fā)場(chǎng)景下，物理線(xiàn)程切換會(huì)引入大量的開(kāi)銷(xiāo)。查詢(xún)涵蓋了復(fù)雜和簡(jiǎn)單查詢(xún)，復(fù)雜查詢(xún)可能長(zhǎng)時(shí)間占用資源，導(dǎo)致系統(tǒng)吞吐大幅下降。

這些技術(shù)難點(diǎn)涉及圖數(shù)據(jù)庫(kù)的查詢(xún)優(yōu)化、讀寫(xiě)并發(fā)、事務(wù)保證以及高并發(fā)查詢(xún)等方面，對(duì)于系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)提出了嚴(yán)峻挑戰(zhàn)。為了克服前述技術(shù)難題，GraphScope 主要從以下三個(gè)方面實(shí)現(xiàn)突破：

在圖查詢(xún)優(yōu)化方面，通過(guò)引入“高維圖數(shù)據(jù)的無(wú)偏估計(jì)”技術(shù)，子圖采樣可以準(zhǔn)確估計(jì)基數(shù)，從而優(yōu)化查詢(xún)?cè)L問(wèn)順序，提高了特定查詢(xún)性能。同時(shí)，采用了“雙向路徑搜索”算法，在包含最短路徑的負(fù)載下，性能提升近 3000 倍。

在高性能讀寫(xiě)圖存儲(chǔ)設(shè)計(jì)方面，通過(guò)采用“細(xì)粒度的鎖控制”策略，將圖數(shù)據(jù)寫(xiě)操作細(xì)分為修改（如屬性更新）和插入（點(diǎn) / 邊），采用不同級(jí)別的鎖以提高讀寫(xiě)并發(fā)效率（對(duì)于修改操作使用常規(guī)讀寫(xiě)鎖，對(duì)于插入操作用細(xì)粒度或者無(wú)鎖技術(shù)）。引入了“高效的版本控制”技術(shù)，通過(guò)原子操作降低鎖開(kāi)銷(xiāo)，改進(jìn)了事務(wù)同步。此外，改進(jìn)了原有的 CSR 圖數(shù)據(jù)結(jié)構(gòu)，通過(guò)預(yù)留空間和自旋鎖應(yīng)用，在保證讀效率的同時(shí)，有效支持插入操作。

為支持超高吞吐的計(jì)算引擎，引入了“輕量級(jí)用戶(hù)態(tài)線(xiàn)程”技術(shù)，極大地減少了高并發(fā)場(chǎng)景下線(xiàn)程切換的開(kāi)銷(xiāo)。同時(shí)，采用了“異步協(xié)同式調(diào)度”策略，使得用戶(hù)態(tài)線(xiàn)程在異步操作時(shí)能主動(dòng)釋放時(shí)間片，避免了復(fù)雜查詢(xún)阻塞其他并發(fā)查詢(xún)的情況。

這些關(guān)鍵技術(shù)的整合使得 GraphScope 在性能和效率方面都取得了顯著突破。

圖計(jì)算在大語(yǔ)言模型中的應(yīng)用前景

今年以來(lái)，以 ChatGPT 為代表的大語(yǔ)言模型（LLM）迎來(lái)爆發(fā)式增長(zhǎng)，雖然 LLM“涌現(xiàn)”出的智能令人興奮不已，但其訓(xùn)練方式和特有的自然語(yǔ)言交互模式，使得將 LLM 應(yīng)用于生產(chǎn)依然面臨諸多挑戰(zhàn)，例如：在訓(xùn)練數(shù)據(jù)滯后的情況下，如何提升 LLM 回答的實(shí)時(shí)性？在大部分 LLM 都具有“幻覺(jué)”（Hallucination）的情況下，如何確保回答的準(zhǔn)確性？雖然 LLM 具有智能，但其大語(yǔ)言模型的本質(zhì)決定了 LLM 在特定領(lǐng)域能力的限制，例如數(shù)學(xué)計(jì)算、網(wǎng)頁(yè)搜索等。同時(shí)，在處理復(fù)雜任務(wù)時(shí)，往往需要對(duì)任務(wù)進(jìn)行拆解和編排，利用工具逐個(gè)解決，如何才能端到端完成復(fù)雜任務(wù)？

為解決上述 LLM 原生問(wèn)題，業(yè)界已經(jīng)涌現(xiàn)出大量實(shí)踐，舉例來(lái)說(shuō)：

當(dāng) LLM 充當(dāng) QA 助手時(shí)，回答的實(shí)時(shí)性問(wèn)題可以通過(guò)在提示詞（prompt）中加入實(shí)時(shí)信息得以解決。但這也引出另一個(gè)問(wèn)題，如何找出和問(wèn)題相關(guān)的實(shí)時(shí)信息呢？網(wǎng)絡(luò)上的公開(kāi)數(shù)據(jù)，尚且可以使用例如 serpapi 之類(lèi)的搜索工具得到，那么特定領(lǐng)域數(shù)據(jù)或者私有數(shù)據(jù)如何處理呢？在提示詞長(zhǎng)度限制下，如何選出最相關(guān)的數(shù)據(jù)加入其中呢？

當(dāng) LLM 出現(xiàn)“幻覺(jué)”時(shí)，用戶(hù)往往基于“常識(shí)”作出了判斷，并通過(guò)降低活躍度（temperature）和細(xì)化提示詞來(lái)降低“幻覺(jué)”。然而在處理特定領(lǐng)域（例如醫(yī)療、法律）任務(wù)時(shí)，即使用戶(hù)具有該領(lǐng)域的“常識(shí)”，“幻覺(jué)”往往難以被識(shí)別，因?yàn)橐话阌脩?hù)難以全面掌握領(lǐng)域知識(shí)。那么，有沒(méi)有什么方法可以有效利用領(lǐng)域知識(shí)來(lái)識(shí)別 LLM 的“幻覺(jué)”呢？

針對(duì)復(fù)雜任務(wù)，將 LLM 與現(xiàn)有成熟生產(chǎn)工具結(jié)合，充分利用 LLM 的智能作為編排復(fù)雜工作流程的“大腦”，并調(diào)動(dòng)生產(chǎn)工具完成端到端執(zhí)行，是業(yè)界給出的方案。其中代表，包括閉源的 ChatGPT-Plugin 和開(kāi)源的 Langchain。然而，在 LLM 單一自然語(yǔ)言交互模式下，如何才能實(shí)現(xiàn)工作流可視化、實(shí)時(shí)交互等，以提升系統(tǒng)整體的透明度，避免成為黑盒子呢？如何才能完成數(shù)據(jù)沉淀、統(tǒng)計(jì)分析、快速迭代等，從而提升工作流效率和可持續(xù)性呢？

得益于圖抽象的語(yǔ)意表達(dá)能力和可解釋性，圖計(jì)算可以很好的解決上述業(yè)界正在面臨的問(wèn)題。

首先，將領(lǐng)域數(shù)據(jù)或私有數(shù)據(jù)存儲(chǔ)于圖數(shù)據(jù)庫(kù)中，并通過(guò)邊來(lái)表示數(shù)據(jù)點(diǎn)之間的關(guān)系，可以實(shí)現(xiàn)更精準(zhǔn)的相關(guān)數(shù)據(jù)查找。常見(jiàn)的向量數(shù)據(jù)庫(kù)通過(guò)比較查詢(xún)和文檔分片 embeding 之間的相似度來(lái)查找相關(guān)數(shù)據(jù)，然而對(duì)于稍顯復(fù)雜的查詢(xún)，其相似性并不體現(xiàn)在單個(gè)文檔分片上。例如，用戶(hù)的查詢(xún)是“OpenAI 的前核心員工有沒(méi)有自己創(chuàng)業(yè)的？”，這里其實(shí)包含兩條信息，一是“誰(shuí)是 OpenAI 的前核心員工”，二是“這些人有沒(méi)有自己創(chuàng)業(yè)的”，相關(guān)信息可能出現(xiàn)在多個(gè)文檔分片中，故使用向量數(shù)據(jù)庫(kù)難以為 LLM 提供最相關(guān)信息。然而，若使用圖數(shù)據(jù)庫(kù)，便可以從 Company 節(jié)點(diǎn)出發(fā)，通過(guò) Empolyment 邊遍歷核心員工，再將這些員工的 Profile 和 Company 一起構(gòu)建 embeding，來(lái)與查詢(xún)匹配，從而為 LLM 提供更為精準(zhǔn)的相關(guān)數(shù)據(jù)。

其次，知識(shí)圖譜作為一種高效領(lǐng)域知識(shí)表示，可以為識(shí)別 LLM 的“幻覺(jué)”提供事實(shí)支撐。例如：LLM 回答包含某公司董事會(huì)成員 A。如果通過(guò)向量數(shù)據(jù)庫(kù)進(jìn)行驗(yàn)證，可能某監(jiān)事 A 總是出現(xiàn)在董事會(huì)會(huì)議中，其高頻出現(xiàn)會(huì)被識(shí)別為董事會(huì)成員；而通過(guò)圖數(shù)據(jù)庫(kù)，可以查找到姓名為 A 的 Person 節(jié)點(diǎn)的職位是監(jiān)事，從而識(shí)別出 LLM 的“幻覺(jué)”。

再者，將 LLM 作為“大腦”解決復(fù)雜問(wèn)題，其核心思路是將可供選擇的工具（例如網(wǎng)頁(yè)搜索、數(shù)值計(jì)算、本地?cái)?shù)據(jù)庫(kù)訪(fǎng)問(wèn)等）的“說(shuō)明書(shū)”加入提示詞，和問(wèn)題一起交由 LLM 來(lái)決定下一步使用哪種工具，以及應(yīng)該為其提供什么樣的輸入。對(duì)于復(fù)雜問(wèn)題，往往不是一步就能得到結(jié)果，所以 LLM 還要和用戶(hù)一起完成工作流的編排，一般稱(chēng)為 Chain-of-Thought。實(shí)際上，由于 LLM 的返回具有選擇性（即 LLM 會(huì)依據(jù)輸入做出不同的選擇，例如判斷為是的情況下調(diào)用 A 工具，否則為 B 工具），用 Graph-of-Thought 來(lái)抽象這一工作流是更為通用的方法。不難看出，基于圖抽象的圖計(jì)算系統(tǒng)，可以更好的管理這一工作流，其對(duì)圖數(shù)據(jù)的高效查詢(xún)、分析和展示能力，可以實(shí)現(xiàn)更透明的觀(guān)察、更易用的 UI 和更有效的數(shù)據(jù)管理。

LLM 的特點(diǎn)，決定了它須與私有數(shù)據(jù)、領(lǐng)域知識(shí)和工作流框架充分結(jié)合，才能在實(shí)際生產(chǎn)中產(chǎn)生價(jià)值，而圖計(jì)算系統(tǒng)可以很好的解決目前 LLM 在這三方面遇到的問(wèn)題。所以大家堅(jiān)信圖計(jì)算作為一項(xiàng)基礎(chǔ)技術(shù)，將助力 LLM 走向生產(chǎn)，發(fā)揮價(jià)值。

此外，GraphScope 正在 Text2GQL 領(lǐng)域作出嘗試，不僅考慮通過(guò)提示詞工程來(lái)提升準(zhǔn)確率，還會(huì)嘗試通過(guò)對(duì)開(kāi)源模型的調(diào)優(yōu)（finetune）來(lái)定制更專(zhuān)注的 Text2GQL 模型，進(jìn)一步提升準(zhǔn)確率和查詢(xún)效率。在 GQL（無(wú)論是 Gremlin 還是 Cypher）學(xué)習(xí)門(mén)檻較 SQL 都更高的今天，期待 Text2GQL 的實(shí)踐，能夠讓更多的用戶(hù)連接圖數(shù)據(jù)庫(kù)，享受圖計(jì)算帶來(lái)的價(jià)值。