大模型上下文協議與Spring開發集成篇——mcp-spring-webmvc原理
( 表格自上而下是檢索記憶的頻率提高 )
最早出現的記憶方案是 Retrieval Augmentation，通過外部儲存來增強模型記憶。當模型需要記憶大量的聊天記錄甚至一整個行業知識庫時，將其儲存在向量數據庫中，后續按需去獲取最相關的信息。每次用戶輸入 prompt 時，從外部記憶中找到最相關的內容和 prompt 一起輸入給模型，得到的生成內容會更有針對性且減少了 hallucination 的問題。
這一能力在我們之前對 Langchain 的介紹中，已經有過相關的介紹。后續 OpenAI 官方 Retrieval plugin 也支持了這一能力。
例如在下圖的 demo 中，當用戶想要從聯合國的數據庫中獲取最近聯合國的信息時，ChatGPT 會從聯合國過往文檔中檢索到和問題最相關的信息，并將其信息組織起來。在 Greg 最新的 Ted Talk 中，這一功能已經支持搜索用戶的歷史聊天記錄。，時長00:42
這一能力的實現中，Pinecone 是 OpenAI 的下游，由于大模型的訓練和推理不依賴這一能力，因此 Pinecone 等 vector DB 提供這向量存儲和語義搜索的服務，暫時不會受到 OpenAI 的沖擊。
單次的記憶增強很好的發揮了 ChatGPT 的信息整合能力，通過領域知識避免了 Hallucination。但這種方式沒有充分挖掘其高階的邏輯鏈（Chain of Thought）能力，因此最近的學術論文 ReAct、Reflexion，和開源項目 AutoGPT、BabyAGI 就在這個能力和記憶的結合下功夫。
以 AutoGPT 為例，其對 prompt 的使用是之前論文與項目的集大成者，這一點的實現與記憶系統密切相關。在 prompt 的一開始就跟 GPT-4 聲明了“好記性不如爛筆頭”：你輸入 prompt 的空間限制只有 4000 token，因此發生重要的事情一定要記錄到向量數據庫中。記錄之后，AutoGPT 定期會記憶進行復盤，即通過對歷史行為的反思形成經驗，來決定接下來的執行計劃。這個記憶系統使黑盒的大模型把自己行為和推理的中間步驟說出來，一定程度實現模型記錄經驗的可解釋性。
而 25 Agents 小鎮在此基礎上，加入了多 Agent 之間的交互，也就是說每個 Agent 的記憶系統是包含彼此的信息交織。其一作 Park 在采訪中提到，最開始設計小鎮時有很多環環相扣的設計，而實現過程中刪繁就簡保留下來最核心的內容，就是每個 Agent 的記憶系統和圍繞其的使用與優化。這一套記憶系統同時實現了感知的記錄、記憶重要性的召回和定期的更新 Agent 人設。通過簡單的人設規則和記憶能力，AI 小鎮展現出了一些人類社區的特質。沿著這條路走下去，群體智慧一定會涌現出更多令人吃驚的效果，如果 AI 們能被設計做一些對抗，甚至可能有 Game of Thrones 的效果。
類似思路在開發者社區引發了很多思考和實驗，AutoGPT 也成為了史上項目初期增長速度最快的項目之一。僅一個月的時間，其 star 數就超越了 Stable Diffusion ；最近其 star 數已經超越了 10萬大關，接近? Stable Diffusion 的兩倍。
而在 AutoGPT 的早期發布中，主要就使用了 OpenAI api 來提供基礎語言能力，Pinecone 來提供記憶能力。后續由于 Pinecone 免費服務需求量暴增有所限制，其他向量數據庫才作為候備選項加入。在這一波 LLM 的熱潮中，根據 Google Trend 的關鍵詞搜索，Pinecone 在開發者中的心智優勢進一步擴大了優勢。
第一部分討論了向量數據庫當前最主要的使用場景和火熱原因——為大模型提供記憶。但其實向量 embedding 這一數據結構，和向量搜索的需求都是隨著 ML/AI 模型逐漸發展到今天的，接下來就介紹下這一領域的演進。
當我們見到一個熟悉的人的時候，大腦是這樣思考的：首先，眼睛中的視桿細胞和視錐細胞記錄下光的強度。這些信號傳遞到位于你大腦后方的視覺皮層，在皮層中數以百萬計的神經元以不同的強度被激活。激活信號傳輸到你的顳葉，你的大腦解釋為：我看到了某某。
也就是說，當我的大腦試圖理解和解釋看到的信息時，大腦解讀的是視覺皮層輸出的神經表示，而非進入眼睛的原始圖像。
深度學習模型也是如此。
盡管大模型呈現出的形式是端到端、文本輸入輸出的，但實際模型接觸和學習的數據并不是文本本身，而是向量化的文本，因為文本本身直接作為數據維度太高、學習起來太低效（稀疏）了。所謂向量化的文本，就是模型對自然語言的壓縮和總結。早年的 NLP 教材有一個很經典的例子：如果我們把每一個單詞看作向量，king 減 queen 之差與 man 與 woman 之差是相等的，都代表著性別的差異。
以 Pinecone 的使用為例，我們常用會設置 dimension 為 1536，也就是說向量 embedding 是一個由 1536個浮點數組成的列表。當我們從向量庫中查詢這一列表的時候，就可以像下圖中一樣，看到其中的浮點數數值，和對應的原始文字內容。
做一個類比，評價一個人有非常多的維度，我們見人的時候會根據自己的經驗總結出一些關鍵維度的信息，這些關鍵信息就是人腦加工的 embedding。基于這些維度，我們評價的時候會圍繞這些維度說出文本。但如果面試后要對一些候選人做篩選，我們不會拿文本評價，而是用內心的各個維度去比較、排序，然后找到最合適的那個人。這個比較并給出答案的過程，就是向量搜索。
向量搜索就是在海量存儲的向量中找到最符合要求的 k 個目標。當我想從海外獨角獸的文本庫中找出與“硅谷最新動態”最相關的 5 段文本時，首先會使用 OpenAI Embedding api 將海外獨角獸的所有文章加工成向量，存入向量數據庫中；然后把“硅谷最新動態”的向量與數據庫中所有向量進行語義相似度的對比；比對后，對相似度排名返回 top 5 的文本，很可能來自去年團隊去硅谷的所見所聞。
理解了這個過程，我們會發現向量搜索和傳統數據庫的查找最大區別在于：傳統數據庫是精確的索引，查找到的內容是有正確答案的。也就是說，數據庫中的數據只有兩類，一類是符合查詢要求、返回給用戶的數據，另一類就是不符合要求。而向量搜索則是模糊的匹配，找到的是相對最符合需求的數據，并沒有精確的標準答案。
將這個過程和互聯網業務聯系起來，會發現向量搜索和之前我們研究過的 Feature Store 一樣，是一個已經存在的需求。互聯網中的搜索、推薦業務，安保系統的人臉識別、對比，都有很多使用場景。在這些場景下，系統需要根據多個維度進行數據關聯計算，因為實際業務場景中數據量非常大，很容易形成類似“笛卡爾積”這種變態的結果，即使減少維度數量，進行循環遍歷，來獲取某幾個向量的相似度計算，在海量數據的場景下也是不現實的。
笛卡爾積：序偶可以簡單理解為帶順序的集合，而笛卡爾積就是 X 和 Y 兩個集合內，包含的所有有序對組成的集合（序偶集合），又稱為“直積”，在數學上記為 f={<x, y>｜x∈X, y∈Y}。
因此之前向量搜索算法就已經出現，Facebook 開源的 FAISS 是其中的翹楚，只是在大模型現之前，這個需求只在大廠中存在，主要通過自研產品滿足。
向量數據庫是一種高效存儲和搜索向量的數據庫產品，傳統數據庫無法很好的滿足這一需求。傳統數據庫只能部分滿足向量數據的存儲，而且在搜索上技術有明顯差異。
在存儲上，向量數據規模超過傳統的關系型數據庫，傳統的關系型數據庫管理 1 億條數據已經不算小的量級。而在向量數據庫需求中，一張表千億數據是底線，并且原始的向量通常比較大，例如 512 個 float = 2k，千億數據需要保存的向量就需要 200T 的存儲空間。因此對向量數據的存儲需求量是很大的，如果不做數據庫只做向量搜索算法，很大一部分需求還需要用戶自己研發。
而查詢方式的差異更大。前面提到，傳統的數據庫查詢通常是點查和范圍查，都是一種精確查找，即查詢得到的結果只有符合條件和不符合條件。而向量數據庫的向量查詢往往是近似查找，即查找與查詢條件相近的結果，即查詢得到的結果是與輸入條件最相似的。近似的查找對算力要求更高。
在大模型場景下，向量搜索的需求真正開始爆發式增長：如果有大量信息或語料需要給 LLM 作為參考，把大量文本一股腦的作為 Prompt 顯然很不經濟，而且過多不相干信息還可能誤導模型輸出。因此大部分創業者的方式是，提前把語料庫向量化，再查詢跟問題 embedding 相似的語料，最終一同送入 GPT 模型。這是一種典型的創業項目整合 OpenAI api 的路徑，是現階段比較靈活且經濟的方式。向量搜索在這里扮演了擇優選擇 prompt 的角色。而 AutoGPT 更是把需求量推到了更高的水平。根據近期主流向量數據庫 Python 包的下載量，幾款頭部產品都在近兩個月有需求量的暴漲：
Pinecone、Weaviate、Chroma 下載量統計
盡管 AutoGPT 的項目創新帶動了 Pinecone 用戶數的大熱，但這個使用場景對 Pinecone 等數據庫的使用是略有浪費的。當前 AutoGPT 的思維鏈長度很難超過四位數的情形下，對最近鄰進行窮舉搜索（也就是 256 維向量與 10000 x 256 矩陣之間的點積）用時僅需不到一秒鐘。
與 GPT 3.5/4 動輒 10 秒鐘的調用速度比起來，對向量搜索這 1 秒的一步，優化到上限也只有加速 10%。也難怪 Andrej Karpathy 會在 Twitter 上表示自己存儲和檢索向量，使用的是 Python Numpy 庫中的 array 函數，并吐槽人們會過度追求新鮮的事物。
但從另一個角度說，當前的使用形式存在那么明顯的過度使用問題，卻能成為那么多獨立開發者調用的首選（AutoGPT 使用了 Pinecone，基本沒有使用 Langchain），恰恰說明對記憶模塊的計算和存儲需求的剛性：開發者們更樂意把時間花在 prompt engineering 上，而不是自己操心向量搜索、存儲相關的能力。
進一步從動態的視角來看，當多模態大模型技術成熟之后，上文中提到的過度使用問題都不再存在。模型推理速度會加快，向量數據的復雜度提升，檢索速度會變慢，屆時向量搜索的性能是產品可用性至關重要的因素。而且向量數據庫在多模態領域會有更顯著的檢索能力，畢竟人類和傳統數據庫對多媒體數據的檢索能力是很弱的。多媒體數據也能大幅增加其存儲量和遷移成本，使其成為更加剛性的需求。
MongoDB 的重要性一部分來自于 JSON 的靈活性，其覆蓋多個場景，使用單個數據庫完成了多種數據庫的任務。而向量 embedding 也有這一潛質，文本、圖片、音頻、視頻等多媒體數據，未來都可以用通用大模型壓縮成向量化的數據。
因此如果我們認為 AI 應用 = LLM + 交互 + 記憶 + 多模態，那么在后二者的實現中向量數據庫都將扮演非常重要的角色。
在 AI 應用的開發者中，OP Stack 的心智已經慢慢傳開：OpenAI + Pinecone。Pinecone 作為目前向量數據庫的領先者，大模型記憶的第一選擇，接下來就來介紹下這家公司的發展之路。
AWS 重要 Leader 帶隊
CEO Edo Liberty，出生在以色列，在特拉維夫大學完成本科之后，來到耶魯大學完成了 CS Phd 的學習。3 年博士后生涯讓他厭倦了學術生活，和朋友創業成為 CTO。在公司賣掉之后，來到了 Yahoo 成為 ML Scientist 。在雅虎工作了 7 年后，他來到亞馬遜 AWS 帶領 Sagemaker 的工作，之后成為了亞馬遜 AI Lab 的 Reasearch Head。
和其他專注 CV/ NLP / Robotics 的科學家不同，Edo 更在乎的是計算機數據系統與 AI 的結合，并且有著敏銳的產品嗅覺。在亞馬遜期間，他觀察到了 embedding 這一業務需求的增長，便離開 Amazon 出來創業。創業之初公司叫做 Hypercube.ai，當時做的是基于深度學習的多媒體搜索解決方案，盡管不是做向量搜索，但基于 embedding 的 retrieval 確實是核心技術之一。在 21 年初正式 pivot 成為 Pinecone 這家公司。
團隊總人數在 50 人+，大部分的團隊在工程方向，小部分負責產品與銷售。工程團隊的背景實力很強，不少來自 Google/Databricks/Splunk 類似背景的工程師，其中 21 年底從 Splunk 加入的工程 VP Ram Sriharsha，他是整個團隊的工程核心，在向量存儲、產品 Scaling 相關的架構創新上做了很多工作。而產品與銷售團隊主要來自于創業公司，少有大公司背景。
清晰的產品優化節奏
2021 年 1 月，Pinecone 正式宣布公開測試版產品。在宣布中，CEO Edo Liberty 提到，他在亞馬遜領導 Sagemaker 的期間意識到，很多公司運用 ML 的難點不在于訓練或部署模型，而在于實時處理海量的向量數據：
? 向量需要被存儲和索引；
? 索引需要隨著數據的變化實時更新，其實時性對分布式計算的要求很高；
? 這個產品需要很好的運維和監控。
2021 年 9 月，Pinecone 2.0 發布，其中提供了元數據篩選的能力，使向量數據能被打上標簽，使搜索兼具精準和模糊搜索的能力。例如，當我們想要搜索“金融”領域的數據時，數據庫就可以高效的從 Industry = Finance 的向量數據中進行語義檢索。同時 Pinecone 2.0 正式將產品定價與硬件使用量綁定，并將產品分為免費、標準和個性化三類價格梯度。
2021 年 12 月前 Snowflake CEO Bob Muglia 和前 Couchbase CEO Bob Wiederhold 宣布成為 Pinecone 的投資人和顧問。后者在 22年底成為了 Pinecone 的總裁和 COO，他此前是連續創業者，做過 Couchbase、Transitive 和 Tality 的 CEO。
從 2021 年下半年起，Pinecone 的工程團隊意識到原本基于 C++ 和 Python 的架構不夠高效，開始用 Rust 開始整體推倒重寫。對于一款沒有開發者社區支持的產品來說，這樣的決定是很有魄力也很危險的，CEO Edo 一度也反對這樣的想法。到 22 年 3 月，重寫工作基本完成，完成后 Edo 事后總結這樣的轉變對公司后面的工程維護有著很大的優化。
22 年下半年開始，產品的更新速度顯著加快：為向量索引提供快照記錄的 Collections 功能上線、兼具語義搜索和關鍵詞搜索優點的混合搜索能力加入，并且 Pinecone 在 GCP 和 AWS Marketplace 都上架了產品。
可以看到，Pinecone 從產品發布第一天就以閉源 Saas 的思路在運營整個產品，對整個產品的優化方向有著很清晰的規劃，技術革新有著很強的魄力。其他精品如 Milvus、Weaviate 的產品思路都有與 Pinecone 亦步亦趨的跡象。清晰的優化路徑才能帶來今天的優勢：當 LLM 爆發點到來的時候 Pinecone 成為開發者最擁護的產品。
收入尚有限，但出色的產品體驗使其成為中小型創新團隊的首選
Pinecone 當前的定價是同時基于數據存儲量和計算資源使用時長一起決定的，其中存儲量每個月每 GB 定價在 0.025 美元，而計算使用量則是每小時 0.1 – 1 美元不等，根據算力等級有所差異。
向量數據庫的商業化模式是 MLOps 中最接近 DataOps 的，有大量基于模型處理的數據留存，且遷移成本比其他 MLOps 工具來得顯著要高；當然由于當前客戶大多在早期使用階段，還沒有達到數據庫那樣特別高的遷移門檻。根據 Pinecone 的重要客戶 Gong 的計算，如果他們持續使用這一服務，未來每年的成本將達到數十萬美元。
而對數據進行向量化的成本在每1000 tokens 0.0004 美元，比最便宜的 GPT 3.5-turbo api 要便宜一個數量級。因此即使是向量數據庫比較貴，考慮到其語義搜索能夠以精準的搜索內容達到不錯的效果，加上向量數據的可復用性，其價值也是非常高的。
2022 年 Pinecone 商業化的主要難點在于：新型公司使用向量搜索的功能大多是實驗性的，不夠核心，因此客戶對向量數據庫的付費意愿會相對弱；而向量搜索占據核心功能的頂級大廠，自己有著自研和部署向量數據庫的能力。例如 Atlassian 在調研發現 Pinecone 最為好用之后，仍然沒有付費，很可能是實現這一功能并不那么重要。因此，2022 年的 Pinecone 的 ARR 只有百萬美元的水平。我們通過用戶調研深挖了這一現象背后的因素。
在對用戶的調研中，我發現對 Pinecone 優點的稱贊主要來自于以下兩點：
1. 產品實現好，使用門檻低：
使用 Pinecone 完全不需要 infra 工程師的介入，就可以很快的完成開發投入生產。雖然是一個數據庫產品，但其使用難度和把一個 Python Library 用起來一樣低。這個優勢幫助他們在早期和 Milvus、Weaviate 等產品的競爭中贏得了很多用戶，其他兩個競品在推出云托管服務之前，都需要比較大的力氣來讓其穩定運行；
2. Scaling 性能好，支持強實時性、高并發量：
很多用戶在使用中前期使用過 FAISS 算法和 Elastic 的類似功能，當數據量一旦增加后有明顯不穩定的情況。尤其在一些網絡安全的場景下，要求文本一旦被向量化，立馬可以比對其異常情況，并且要有 500 以上的 QPS，在 2022 年上半年 Pinecone 是能最好滿足這一要求的解決方案。
看到這里會發現，向量搜索的效果本身并不是決勝的關鍵，因為模糊的匹配沒有 100% 正確的標準答案，快速穩定地返回答案比精準來得更重要。換言之，從 Elastic 的關鍵詞搜索切換至 Pinecone 的語義搜索的提升很重要，但語義搜索精度的優化邊際收益就沒那么高了。
這里有一個前提：搜索的結果不會直接影響產品的收入，例如 Tik Tok 的視頻召回準確率會直接影響產品的留存和收入，那么客戶就會更傾向于 self-host 算法進行調優，而不是交給第三方去實現。這就引出了用戶選擇 Pinecone 的顧慮：
1. 如果向量搜索是他們產品收入的核心，那么他們可能會使用開源方案自研并部署，這樣可以對核心功能有更多的定制和調優的空間；
2. 如果客戶的數據是高度機密受監管的，不愿意放到公有云上部署，他們可能會選擇開源模型 + 數據庫自己部署。
根據這些調研，Pinecone 在 2023 年新增的用戶肖像就很明確了：精簡的 LLM 時代開發團隊 LLM， Prompt 的調試比記憶檢索更接近他們產品的核心，想要一個開箱即用的向量數據庫服務。在未來這樣的團隊很可能不會成長為一個有很多工程師的大公司，也不會選擇自研和 host 向量數據庫的相關服務。
這類團隊很可能大規模，且 LLM 和向量數據庫是其最主要的成本項。因此，我認為在 LLM 時代的新型開發需求帶有巨大的市場空間，盡管以前的需求沒有給 Pinecone 掙到大規模的收入，但為其做好了產品打磨和需求理解的基礎，而在未來有了很強的競爭力。說到這里，就讓我們來看看 Pinecone 現在和潛在的競爭對手有哪些。
競爭對手云集，傳統數據庫和公有云廠商是更大的對手
1. OpenAI 是否會做向量數據庫：不做 Retrieval Plugin 中需要外接 Pinecone 等數據庫
Retrival 召回插件被 Greg 稱為 Plugin 中最特殊的一個。在最近的 TED Talk 中，Greg 的展示中也對 Retrieval 的進階功能進行了展示，可以記憶用戶的聊天歷史，并基于個性化歷史進行對話。有了 Retrieval Plugin，ChatGPT 離個人能力近了一步。
在 Plugin 的項目代碼中，官方推薦了使用 Pinecone 等作為插件搜索和存儲向量數據用的數據庫。考慮到大模型的訓練和推理本身并不需要向量數據庫，是基本解耦的，這一領域大概率不會直接受 OpenAI 的產品影響。
2. 創業團隊
? Weaviate
來自荷蘭的 SeMI 團隊打造的開源數據庫 Weaviate 也獲得過 OpenAI 官方的推薦，推薦語中其實就清晰地解釋了 Weaviate 和 Pinecone 的差異：Pinecone 的服務是完全交給他們和 AWS/GCP 托管的，包括數據存儲和資源管理；而 Weaviate 則把這項任務交給用戶 self-host，自己提供支持性的運營和服務。
對于不想自己花精力和成本 host 服務的客戶來說，Pinecone 的服務更加一體化和開箱即用；對于不愿意將數據完全交出去、希望有自主控制權的用戶來說，Weaviate 的方式更加靈活，但也需要相對大的時間成本。
Weaviate 希望通過好的運營和產品體驗獲勝，認為 MongoDB 是贏在流暢的產品體驗。2022 年付費量不大，ARR 在 5 萬美元左右。最近他們也已經推出了自己的云服務。
? Chroma
Chroma 是由在舊金山的連續創業者 Jeff Huber 和 Anton Troynikov 創立的。他們倆分別來自 3D 視覺和機器人領域，對 AI 領域的需求很熟悉。他們的產品比 Pinecone 和 Weaviate 更加輕量級，目前還是一個開源項目的形態，正在開發自己的托管產品中。當前整個產品還在比較早期的階段開放使用，暫時沒有商業化收入，Pinecone 的免費服務受到限制之后，很多用戶遷移到了 Chroma 進行開發，很好的積累了早期用戶。
? Zilliz
Zilliz 是一支來自中國的團隊，他們打造的 Milvus 是最早發布的向量數據庫。在 Milvus 1.0 階段，產品形態比較接近 Weaviate，是一個封裝了近鄰搜索算法的向量搜索產品；而到了 Milvus 2.0 階段，產品形態就更接近 Pinecone，提供了 Zilliz Cloud 這一完全托管的服務，同樣是在 AWS 和 GCP 上提供。產品定價上，在存儲端價格與 Pinecone 基本一致，計算端的小時單價是 Pinecone P2 Pod 的兩倍、V1 Pod 的三倍。
? Vespa，Yahoo 開源產品
Vespa 是來自 Yahoo 的開源產品，有些類似 OLAP 屆的 Clickhouse：很多企業基于這一產品 self-host 向量數據庫，但少有用戶為產品付費。
3. 傳統數據庫：Elastic Search / Redis / Snowflake
從一個角度來說， 這類公司有著很大量級的 ARR、很多客戶在使用他們的服務。對于 vector search 的需求，他們對速度和規模的支持都比較弱。由于這當前不是個大市場的需求，可能還沒有進入他們主要重視的階段。而當這一市場成長到足夠大以后，未來模型對輸入的 token 數可能會達到無限長，那時候 Elastic 關鍵詞搜索和 vector DB 語義搜索的性能差異可能會被縮小：搜索召回的精度沒那么重要，模型都能大規模的輸入并理解。
但從另一個角度說，如果他們選擇進入這一市場并將性能優化好，考慮到很多客戶的數據都在他們的數據庫上，一體化的解決方案對開發者的吸引力是很強的，不用新簽合同，只需要提高對正在使用產品的預算也是流程上更友好的。主要的問題是他們相對傳統的工程架構，是否能適應這一新的需求。目前 Redis 已經在積極的進入這個市場了。
在這三者中，盡管 Snowflake 和 Redis 比起 ES 離這一領域更遠，但是我們認為同樣也是 Pinecone 值得畏懼的對手，因為這兩家公司使用的技術架構更新、計算速度更快，不像 Elastic Search 天生在語義搜索的能力有一定的 scaling 缺陷。
4. 公有云廠商：AWS/GCP/Azure
和 10 年代的競爭一樣，公有云廠商永遠是現代數據庫的競爭對手：盡管 MongoDB 在開發者領域有著很好的生態，AWS 的 DynamoDB 在收入上并不顯著遜色。
GCP 在 Vertex AI 上有自己的向量數據庫 Matching Engine。作為同時擁有很強搜索和 AI 能力的谷歌，有這樣的能力并不讓人吃驚，如果他們把 Bard 的 embedding 能力和向量數據庫做好整合，是一個很大的競爭對手。畢竟 Pinecone 本身只負責加工和存儲來自別的 api 的能力。
同理，Azure 和 AWS 盡管目前沒有向量數據庫產品，也有相應的能力建設，在各自的云平臺上搭建一套 LLM + 向量數據庫的整合能力是他們潛在的目標之一。尤其是 OpenAI api 是 Azure 主要的服務之一，他們目前沒有也沒有和 Pinecone 產生合作，微軟很有可能推出向量搜索的能力，直接將 GPT3.5 Embedding 存在 Azure 上提供搜索服務。
剛剛列舉了 Pinecone 眾多的競爭對手，想必能感知到整個向量數據庫市場現在還在早期階段，未來的變化值得我們一起持續關注。除了市場本身的格局之外，有兩個問題值得深入討論與思考，也會對向量數據庫的位置產生重要影響。
Pinecone 在官網把自己定義為 Long-term Memory for AI，我認為這是有待商榷的。回到開篇對人類智能的討論，我們提到大模型是記憶缺失的大腦，而向量數據庫是補足這一能力的海馬體。其實調用 Pinecone 的過程，比較像人類死記硬背使用短期記憶的方式。因為當我們進入某一領域時，會首先根據一些知識與過來人的經驗依葫蘆畫瓢，然后隨著自己的試錯和經驗積累慢慢形成自己的直覺、風格和行為習慣，直到那時我們才成為這一領域的專家。而 Pinecone，只實現了依葫蘆畫瓢的那一步。
換言之，從人類智能的角度看，Pinecone 是短期記憶，LLM 是長期記憶，但目前他們之間的交互還是單向的，缺少了短期記憶累積沉淀，形成長期記憶的過程。但直接去調整大模型的參數是不太可行的。因此這一過程可能需要一些新的組件來彌補，例如一個基于 Lora 進行微調的小模型，來幫助大模型做一些領域專業知識的記憶；也或者是由多個 LLM 交互形成群體記憶，來達到更新長期記憶的效果。
無論是哪一種方式，都有可能對向量數據庫產生依賴或替代的關系，甚至有可能 Pinecone 會根據客戶需求提供這樣的能力。因此未來的架構變化對向量數據庫的重要性至關重要。
同時，還有一種觀點認為，當 LLM 能夠讀入無限 token 時，向量數據庫的必要性就不大了。理論上這是完全可行的，但這忽略了經濟成本和工程復用性的問題。當每一次執行都要將相關語料庫不經檢索地作為 prompt 輸入時，其中大部分的內容信息增益和 ROI 是很低的，可能帶來很多不必要的商業成本和資源浪費。尤其是當大模型允許多模態輸入之后，這一問題會更加顯著。而且模型使用向量化的記憶，再將輸出向量化存入記憶中是很好的記憶回路，能夠一定程度上 LLM 對過往經驗知識的總結和復用。
隨著 LLM 能力越來越強，還會有很多這樣的討論。其背后隱藏的主線邏輯是：當 AI 能有這么強的信息提取和組織能力之后，傳統數據庫的很多能力是受到沖擊的。
向量搜索的普及過程中，很多之前用 SQL 和結構化數據比較難解鎖的產品功能自然得到了實現，長期用戶的使用范式肯定慢慢會從傳統數據庫轉移到 LLM + Vector DB。那么數據倉庫未來會如何面對這一沖擊，屆時的 Vector DB 又比今天的形態復雜多少呢？這是值得我們一起持續思考和關注的重要問題。
文章轉自微信公眾號@海外獨角獸
