生成式 AI 促進(jìn)了向量數(shù)據(jù)庫的火爆，但如今的技術(shù)風(fēng)向變化似乎也挺快。作為全球最著名的 AI 項目之一，AutoGPT 宣布不再使用向量數(shù)據(jù)庫，這一決定可能讓不少人感到驚訝。畢竟從一開始，向量數(shù)據(jù)庫就一直協(xié)助管理著 AI 智能體的長期記憶。
那么這個基本設(shè)計思路怎么就變了？又該由哪種新方案代替？對于大模型應(yīng)用來說，向量數(shù)據(jù)庫是必要的嗎？
事情發(fā)展
AutoGPT 是今年 3 月 30 日發(fā)布的一種“AI agent（AI 智能體）”，類似的還有 LlamaIndex 和 LangChain。AutoGPT 一發(fā)布就名聲大噪，上線僅 7 天就在 Github 上獲得了 44,000 顆星。相較于之前一遍又一遍向模型輸入提示詞的用法，它能夠自行工作、規(guī)劃任務(wù)、將問題拆分成多個較小的部分、再逐個加以執(zhí)行。毫無疑問，這是個雄心勃勃的計劃。
AutoGPT 的設(shè)計思路還涉及一種以嵌入形式管理智能體記憶的方法，外加一套用于存儲記憶并在必要時檢索的向量數(shù)據(jù)庫。從當(dāng)時的角度看，向量數(shù)據(jù)庫被認(rèn)為是整個解決方案當(dāng)中最重要的組成部分。而且其他通用人工智能（AGI）項目也紛紛采取同樣的方法，例如 BabyAGI。
之前在默認(rèn)情況下，AutoGPT 支持五種存儲模式：
- LocalCache (will be renamed to JSONFileMemory)
- redis
- Milvus
- Pinecone
- Weaviate
但現(xiàn)在查看 AutoGPT 的說明文檔，我們會發(fā)現(xiàn)一條令人驚訝的警告消息：
AutoGPT 最近剛剛經(jīng)歷了“向量記憶改造”，其刪除了所有向量數(shù)據(jù)庫實現(xiàn)，包括 Milvus、Pinecone、Weaviate，僅保留幾個負(fù)責(zé)記憶管理的類。如今，JSON 文件成為存儲記憶 / 嵌入的默認(rèn)方式。
原因是向量數(shù)據(jù)庫沒有附加價值？
其實，AutoGPT 的維護(hù)者 Reinier van der Leer 于今年 5 月份就在 GitHub 上詢問大家對“增加不同存儲方式的價值”的看法，因為他們想進(jìn)行重構(gòu)，并打算放棄除“本地”內(nèi)存提供程序（現(xiàn)在稱為 json_file）之外的所有東西，同時努力實現(xiàn) Redis VectorMemoryProvider。
有開發(fā)者對此表示贊同，認(rèn)為如果后端足夠好，那么沒有理由保留這些向量數(shù)據(jù)庫。“但我建議將 pinecone（如果有優(yōu)勢的話，那也可以是 redis）集成到自定義 JSONFileMemory 中。”
當(dāng)然也會有反對者，他們認(rèn)為“向量數(shù)據(jù)庫比當(dāng)前的 JSON 文件內(nèi)存系統(tǒng)更高效。它們是為此類任務(wù)而構(gòu)建的，可以簡化開發(fā)并減少 token 消耗。”Reinier 對此進(jìn)行了反駁，“這說法太籠統(tǒng)了，是否有例子或假設(shè)案例來證明這一點是正確的？”
至于以后要不要恢復(fù)向量數(shù)據(jù)庫，該開發(fā)團(tuán)隊表示這肯定不是當(dāng)前的首要任務(wù)，況且他們也沒發(fā)現(xiàn)向量數(shù)據(jù)庫能帶來什么特別的附加價值。
在開發(fā)內(nèi)存系統(tǒng)時，我們要關(guān)注數(shù)據(jù)結(jié)構(gòu)，而不是存儲機(jī)制。使用具有 JSON 持久性是最簡單的實現(xiàn)方法，為實驗留出了空間。
為什么 AutoGPT 一開始采用但現(xiàn)在又放棄向量數(shù)據(jù)庫？是向量數(shù)據(jù)庫的價值問題還是架構(gòu)設(shè)計問題？InfoQ 詢問了流數(shù)據(jù)庫公司 RisingWave（risingwave.com）創(chuàng)始人 &CEO 吳英駿，他認(rèn)為更多的是設(shè)計決策上的事情：
AutoGPT 最開始采用矢量數(shù)據(jù)庫進(jìn)行矢量存儲與查詢，相信單純是為了快速打造產(chǎn)品原型，縮短開發(fā)周期。選用矢量數(shù)據(jù)庫進(jìn)行初代產(chǎn)品的開發(fā)可以更快得到高效可靠的矢量存儲查詢功能。而如今，AutoGPT 選擇“放棄”矢量數(shù)據(jù)庫，多半也是發(fā)現(xiàn)運維與使用矢量數(shù)據(jù)庫的代價已經(jīng)超過了其帶來的好處。在這種情況下，重新自己造輪子更符合項目發(fā)展的長遠(yuǎn)收益。畢竟，在軟件開發(fā)過程中，過早優(yōu)化會帶來極高開發(fā)成本與風(fēng)險，導(dǎo)致軟件復(fù)雜度不可控。
這也正如 AutoGPT 項目維護(hù)者 Reinier 所言，AutoGPT 支持多個向量數(shù)據(jù)庫，確實會拖慢開發(fā)速度。那么像 AutoGPT 這樣的大模型應(yīng)采用向量數(shù)據(jù)庫并不是必要的嗎？對于長期記憶，我們還有其他選擇？
該如何選型？
早在 4 月份，就有網(wǎng)友對 AutoGPT 最初的選擇提出批評，認(rèn)為向量數(shù)據(jù)庫是種“小題大做的解決方案”。他的論證過程也很簡單：
假設(shè)大語言模型需要 10 秒鐘才能生成一條結(jié)果，即需要存儲的單條新記憶。那么我們獲得 10 萬條記憶的時間周期將為： 100000 x 10 秒 = 1000000 秒——約等于 11.57 天。而即使我們用最簡單的暴力算法（Numpy 的點查詢），整個過程也只需要幾秒鐘時間，完全不值得進(jìn)行優(yōu)化！ 也就是說，我們就連近似最近鄰搜索都不需要，更不用說向量數(shù)據(jù)庫了。
那么我們應(yīng)該如何為自己的項目選型？吳英駿老師認(rèn)為，對于任何大模型應(yīng)用，是否需要選用矢量數(shù)據(jù)庫，完全取決于該應(yīng)用對于矢量存儲與查詢的依賴程度。
“對于需要存儲大量矢量的場景，如海量圖像檢索、音視頻檢索等，很顯然使用矢量數(shù)據(jù)庫可以獲得更加強(qiáng)大、專業(yè)的功能，而對于數(shù)據(jù)量并沒有那么大的場景來說，還不如使用 Numpy 等 Python/ target=_blank class=infotextkey>Python 庫計算來的高效、便捷。實際上，在矢量數(shù)據(jù)庫這個賽道上，也分為輕量級矢量數(shù)據(jù)庫以及重量級矢量數(shù)據(jù)庫等，到底是選擇 PostgreSQL 上的 pgvector 插件還是選擇一個專用的分布式矢量數(shù)據(jù)庫，也是需要對于特定應(yīng)用做出具體分析之后再做出決策。”
這個說法也符合如今 AutoGPT 項目的真實選擇，使用 np.dot 進(jìn)行嵌入比較：
Andrej Karpathy 也曾在 Twitter 上表達(dá)過此類觀點。之前他利用 OpenAI 的 API 建了一個大模型應(yīng)用，有網(wǎng)友問使用了什么向量數(shù)據(jù)庫，Karpathy 表示，不用追風(fēng)一些“奇特的東西”，使用 Python 庫中的 np.array 已經(jīng)足夠了。推文底下當(dāng)即有人評論說，這種務(wù)實的觀點應(yīng)該傳播到學(xué)術(shù)界和整個機(jī)器學(xué)習(xí)社區(qū)！
寫在最后
目前據(jù)我們所知，不采用向量數(shù)據(jù)庫的也不止 AutoGPT：比如 GPT Engineer、GPT Pilot 甚至是 GitHub Copilot 等都不使用向量數(shù)據(jù)庫——相反，它們通過最近文件、文件系統(tǒng)內(nèi)的鄰近度或查找對特定類 / 函數(shù)的引用來獲取相關(guān)上下文。
是否選擇使用向量數(shù)據(jù)庫要看情況，而 AutoGPT 放棄向量數(shù)據(jù)庫，是朝著正確方向邁出的重要一步，即專注于提供價值、而非深陷技術(shù)泥潭。
會不會有一天，向量數(shù)據(jù)庫又將重返 AutoGPT？向量數(shù)據(jù)庫到底算不算是 AI 技術(shù)革命中的重要組成部分？或者說，向量數(shù)據(jù)庫 Pinecone 成為 AI 長期記憶方案的愿景，只是一句空洞的口號？或許也有人認(rèn)為，真正的問題是像 AutoGPT 這樣的項目并沒能帶來任何價值。也許目前我們能夠論證的就只有這些，余下的只有靠時間來證明......
