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

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

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

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

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

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

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

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

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

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

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

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

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

不僅在數(shù)據(jù)庫中，圖計(jì)算已經(jīng)在大數(shù)據(jù)處理和分析中也開始展現(xiàn)其獨(dú)特的價值和地位。根據(jù) 2022 年 8 月發(fā)布的 Gartner 報告，到 2025 年，圖計(jì)算技術(shù)將在 80% 的數(shù)據(jù)和分析創(chuàng)新中扮演核心角色。這與 2021 年的數(shù)據(jù)大相徑庭，當(dāng)時圖計(jì)算在數(shù)據(jù)和分析創(chuàng)新中的占比僅為 10%。這樣的飛速增長無疑證明了圖計(jì)算在未來數(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)過幾年打磨和使用后，2020 年 11 月，GraphScope 在第二屆世界科技與發(fā)展論壇上重磅宣布開源并發(fā)布了白皮書，同年 12 月代碼在 GitHub 開源。

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

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

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

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

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

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

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

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

組件化架構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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