2023 年可以說是大模型元年，藉著大模型的東風，向量資料庫也迎來了大爆發，被帶到了更高的關注度上。
一方面，向量資料庫和 RAG 得到廣泛的關注和認可，是因為他們的確可以解決一些短期內大模型無法攻克的難題，比如模型幻覺問題等。同時，在嘗試用向量資料庫和 RAG 做場景落地的時候，效果也還不錯。
不過另一方面，我們也無法迴避對他們普遍的困惑與爭議，比如向量資料庫是否已經涼了，以及如今勢頭正盛的 RAG 是否會被長文字殺死等等。
那此刻距離 ChatGPT 的釋出已經有一年多的時間，站在當下的這個時間點上來看，向量資料庫和 RAG 究竟發展到了什麼階段，他們的現狀如何，未來又將走向哪裡呢？行業專家是如何看待向量資料庫和 RAG 所面對的爭議和質疑呢？從業者又將以何種技術視野來進行工作安排和職業規劃呢？所以有了我們這次的對談。
本次對談的嘉賓是：
蘇鵬：向量檢索實驗室的主理人，Datawhale 上海負責人 湯林鵬：MyScale AI 資料庫的聯合創始人兼 CTO
兩位對談嘉賓都曾經是機器之心 AI 技術論壇「大模型時代的向量資料庫」的特邀嘉賓，也再次感謝機器之心策劃了這麼一場直播。
同時，湯林鵬老師的團隊近期開源了 SQL 向量資料庫 MyScaleDB，它究竟是什麼、解決了哪些問題、為什麼聚焦在 SQL 方向，未來又將如何發展呢？讓我們也在這次對談中一探究竟。
本篇文章在直播內容的基礎上進行了系統化的整理和補充，也補充了直播中幾乎所有使用者的提問，希望能給大家帶來些啟發與收穫。
一、前置知識
為了方便大家能順利進入兩位老師的對話，這裡插入一段前置知識：
1. 向量資料庫
向量資料庫最核心的，其實是非結構化資料搜尋的問題。什麼是非結構化資料呢？比如像文字、圖片和影片等形式的資料集都叫做非結構化資料。那非結構化資料如何實現搜尋呢？我們拿以圖搜圖來說。
把一張圖片丟進一個模型裡，它就會生成一堆數字，那這堆數字本身就是向量。多張圖片經過相同的模型，都會生成相對應的一堆向量。向量本身是數字，所以就天然支援這種算數的運算。
來看個具體的例子。有一個查詢的圖片進來，我們可以透過模型將它轉化為一堆數字。然後直接拿這堆轉出來的數字和資料庫中原有的數字挨個相減，哪個結果最接近於 0，那我們就認為他們是最相似的。
反推回來，我們就知道了哪兩張圖片是最相似的，這就實現了一個簡單的以圖搜圖的功能。對應到上面的示意圖中，我們輸入進去的查詢圖片（query），經過向量化後，和資料庫中第三張圖片的向量相減，最終結果更接近於 0，所以我們可以認定這兩張圖片是最相似的。
向量資料庫需要解決什麼問題呢？假使你有 100 億個向量資料，那系統架構應該怎樣設計？如何實現快速檢索？資料如何分片？它的索引又該如何建立呢…… 諸如這些工程挑戰，其實都是向量資料庫本身要解決的一些問題。
向量資料庫對比：https://superlinked.com/vector-db-comparison
2. RAG
Retrieval Augmented Generation（即 RAG）的提出最早可追溯到 2020 年發表的一篇論文，論文題目為《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，中文翻譯成檢索增強生成。
論文連結：https://arxiv.org/abs/2005.11401
那向量檢索就是其中的一種，除了向量檢索外，還有比如關鍵詞檢索、基於圖的檢索（知識圖譜的檢索）等等其實都是檢索的方法。
圖片來源：https://www.rungalileo.io/blog/announcing-rag-and-agent-analytics
典型的 RAG 系統具有三個關鍵過程：檢索、增強和生成。檢索對輸出質量、延遲和成本的影響最大。
RAG 的出現重點解決了現有大模型的三個挑戰：
幻覺問題：生成內容不正確，與事實不符，甚至荒謬 實時問題：無法給出時效性較強問題的答案，或者給出錯誤答案 私域資料問題：企業私域資料因為合規等問題無法在公網作為大模型的訓練資料，所以大模型無法回答針對企業的專有問題
不過 RAG 解決上述問題的時候，也同樣帶來了如下挑戰：
引入其他元件，系統複雜性較高 有較多工程性問題亟待解決 知識庫需要不斷更新維護 依賴 Embedding 質量以及檢索效果
我們上面說的向量資料庫，其實就是 RAG 的一種關鍵架構元素。所以大家現在談到向量資料庫，就一定會想到 RAG。我們這次的對談也是兩者融合來討論。
大模型出現之後，大家都是基於文字來互動，那語言、文字這種非結構化資料，它最適合的就是向量檢索，所以現在向量檢索、向量資料庫和 RAG 結合得這麼深，或者當大家聊到 RAG 時，就會說我需要個向量資料庫，需要個大模型才能做。
二、對談
1. 向量資料庫歷史及發展現狀
圖源：https://myscale.com/blog/what-is-sql-vector-databases/
蘇鵬：向量資料庫包括向量檢索的技術，其實它的歷史很長，並不是在大模型之後誕生的。那為什麼在大模型誕生之後，向量資料庫才迎來了如此多的關注呢？它的發展現狀又如何呢？
湯林鵬：我先簡單介紹一下向量資料庫的歷史和演變過程。大模型出來之前，其實向量資料庫在很多垂直場景上已經有應用了，比如以圖搜圖、語義檢索、網際網路上的常用的推薦、工業場景中的異常檢測等等，核心都是將非結構化資料對映到向量空間中，完成向量檢索後，來實現上面的各種功能。
當然在大模型出來之前，這些技術可能還只是應用在一些區域性的領域，不過也已經非常重要了。我們在開發 MyScale AI 資料庫之前，也在一些垂類的生物識別場景中構建過千億級別的向量系統，當時就已經開始了相關技術的積累。後來大家就把這種垂類系統也逐漸地做成了相對通用化的系統。比如：
Pinecone：矽谷知名的閉源向量資料庫 SaaS 產品 Milvus：開源的向量資料庫產品 當然還有其他像 Qdrant、Weaviate 等等
這些產品基本上都是為向量檢索而設計的，基於向量檢索庫做一些封裝、分散式的系統設計等等。不過他們也有一些缺點，比如在較為通用的資料管理和查詢方面沒有得到足夠多的錘鍊，導致很多功能上是有一些缺失的。
從大模型普及之後，向量的重要性一下得到了認可，於是又出現了很多整合向量資料庫，比如原來文字做的最好的 Elasticsearch，以及後來改了協議的 OpenSearch 也都加上了向量的功能。
PostgreSQL 是一個開源的事務型資料庫，也是用得最廣的事務型資料庫，因為它的外掛系統設計得比較好，也被加上了向量的功能。但這些系統我們其實做過非常多評測，我個人認為，它的架構本身的一些侷限性，還有包括對向量理解最佳化的不夠，導致了它們的效能和精度在稍微複雜一點的場景上會有些問題，比如資源佔用高，複雜查詢速度慢、精度低等。
蘇鵬：其實如果大模型沒有出現，向量檢索也一定會在某個時間，比如今年或是明年，還是會被大家所關注和重視到。因為整個非結構化資料本身就是增長的趨勢，大家也在逐漸意識到，處理非結構化資料大機率會是一個單獨的課題，會變成一種很重要的檢索方法。這一天到來的話，向量檢索的發展就能得到顯著加速了。
2. 長文字 vs. RAG
圖源：https://www.vellum.ai/blog/rag-vs-long-context
蘇鵬：向量資料庫也經歷了所謂的“黃金時代”，比如國外做向量資料庫的 Chroma 也融到過大筆資金。但是現階段，很多做向量資料庫的廠商也在擔憂，國內的模型廠商會不會下場做向量檢索的產品，或是某些垂類應用。尤其最近長文字的出現，比如支援 200K 文字的 Kimi，那這種長文字會不會衝擊 RAG 場景，未來 RAG 還存在嗎？是不是模型本身就已經解決了類似需求呢？
湯林鵬：我覺得長文字的出現的確讓某些場景的 RAG 變得沒那麼重要了，比如原先也可以透過一些技術把長文件用 RAG 的方法來做一些問答和總結。但是現在對於單篇文件的體量，比較先進的支援長視窗的大模型在大多數的情況下都是能支援的，所以原先這些比較小的應用場景就變得沒有那麼重要了。雖然長視窗比較貴，有時候也比較慢，但是應付單個文件是沒有太大問題的。
不過另一方面，企業、行業或是整個社會的資料量還是非常龐大且繁雜的。比如一箇中大型企業，它可能有數十萬的文件或是各種異構資料，文件之間還會有不同的版本關係等等，那在這種複雜和海量的資料下，視窗再大還是沒辦法都放進去。這個時候就需要透過檢索的方法，精準定位到相關段落，然後排除掉不相干的資訊。對於這種知識的快速理解、問答等場景，RAG 還是一個必要的手段。
另一方面，我們和一些合作伙伴正在做的工作中，也看到了 RAG 和 LM 有更深入的融合，比如最近 Cohere 釋出的 Command R+ 就是專門為 RAG 最佳化的；還有 Contextual AI ，也提出了 RAG 2.0 的技術。我認為之後 RAG 可能不僅僅是一個外掛，而是會和知識庫、大模型有更加深度的融合。當然有時候也可能會以 Agent 複雜的 workflow 形式來融合，來降低成本提升效果，這些技術也都會有一個融合發展的趨勢。
蘇鵬：像湯總剛剛說的，我個人也認為長文字確實會殺死掉一部分場景。比如說你有一兩篇文件的話，其實根本不需要 RAG 技術，你直接丟給現存的任何一個模型，它應該都能處理得很好。但這裡邊可能存在一個問題，當你給模型更多不相關的內容時，其實它的回答效果是存疑的，雖然你把文件都放進長文字 200K 的視窗裡了。
但是當你問某一個問題，它會把不相關的東西也獲取到，那它回答的效果其實也是難以保證的，所以這可能也導致了 RAG 和長文字的爭議會長期存在，我們這裡也保留個可能，長文字與 RAG 一起向前走的可能。
3. 向量資料庫產品現狀、變化及商業化思考
蘇鵬：站在2024年的時間節點上，我們回頭看，剛剛我們提到的資料庫的廠商乃至產品，他們目前的發展有哪些進展/變化，商業化的腳步又如何呢？
湯林鵬：這裡我們先不提不適合公開場合分享的內部資料。不過整體來看，我認為有些產品的增長還是非常好的，甚至有些產品已經預期今年會提前完成原定目標。但是另一方面，大家都能感受到競爭依然非常激烈，這兩年 AI 是大家的關注點，所以無論是大模型還是向量資料庫的賽道都很卷。
哪幾個廠商能堅持在賽道上長跑並贏得最終的市場，可能還是要看對技術以及市場的把握，還有是否能抓住機會把技術、產品和市場做一個好的結合。
從 MyScale 的策略上來說，對於我們剛剛提到的長文字的發展，一些資料量比較小的場景可選擇的產品的確太多了，也就顯得不那麼重要。所以 MyScale 還是更聚焦在資料量比較大、資料模態比較複雜、企業需要做綜合管理的場景上。
MyScale 所支援的 SQL + Vector 功能，在效能、資料密度和價效比上的最佳化會比較有優勢，所以我們還是更加傾向於中大型企業/行業的場景。當然我們也認為大模型 + 大資料的模式會是一種新時代的發展趨勢，希望 MyScale 能夠成為這種新正規化下一個重要的資料底座。
蘇鵬：從國內的視角來看，由於經濟形勢等原因，在大模型這塊，大家大部分還是雷聲大雨點小，向量資料庫更是如此，大家在選型階段更偏向於開源、易用、生態等。但是一些 SaaS 場景還是有一定需求的，尤其國內做出海的一些企業，也會更偏向於採用 SaaS 的模式。
4. 專有向量資料庫 vs. 傳統資料庫擴充
圖源：https://mp.weixin.qq.com/s/JvyKnEbdOSb1fTwhiQTO5A
蘇鵬：剛剛湯總提到 MyScaleDB 是基於 ClickHouse 做的，那現在也有個問題想探討一下，比如現在有像 Pinecone、Milvus 這種的專有向量資料庫，也有像 pgvector、Oracle 和 TiDB 這種支援了向量檢索的傳統資料庫。
那這種傳統的資料庫廠商，他們相容了一部分向量檢索的能力，是不是意味著未來向量檢索的技術，可能會變成資料庫的標準功能呢？如果是這樣的話，它對於未來向量資料庫的整個市場空間和商業格局有什麼影響呢？
因為我們買了一個關係型資料庫或是分散式資料庫，它本身支援了向量檢索功能，我就不太會再單獨買一個專用向量資料庫了。
湯林鵬：我認為這個肯定會對市場格局有很大影響的。
首先開源的向量資料庫已經有很多，那現在大家普遍看到了向量資料庫的重要性，做一些整合也很正常。所以技術演進到後面，當向量資料的量沒有那麼大，查詢的需求也沒有那麼高的時候，使用者會有很多選擇，一般也會考慮原有的廠商加個整合，這樣系統很簡單，也能夠滿足基本使用要求。這部分市場，可能佔比較大的市場比例，的確會被吃掉。不過另一方面，向量作為一種新的資料模態，它的重要性得到了大家的認可，而且會越來越受重視，所以向量的資料量一定是越來越大的。再者，向量本身處理起來是非常吃資源的，因為一個向量可能至少是 512 維，現在高的可能已經到了 3000 多維，從處理難度上來說，它其實是比傳統的資料庫，甚至大資料系統處理起來更難。所以傳統的廠商加上向量的功能並不難，難的是真正把它做好，做得有競爭力。
從我們團隊的角度看，我們認為這兩種向量資料庫會長期存在。但是從我們目前的研發結果和對工程的細節來看，我們認為列式的資料庫和向量是沒有本質衝突的，兩者融合好是能夠達到基本沒有效能損失的，同時也獲得了很多新的優勢，包括資料統一管理查詢帶來的優勢，節省掉一些工程開發的代價等。當然這個融合也需要做大量工作，我們只是剛剛開始。我們認為這條路是能滿足很大一部分資料量大且要求複雜的場景。
蘇鵬：我的個人想法，也是個粗淺的理解和預測，未來向量檢索的能力很有可能是所有資料庫的標配，甚至也會具備一定的 AI 能力，例如 AIOps，Text2SQL 等。所以在一些場景下使用者可以直接拿傳統資料庫擴充向量檢索來解決問題，這個“一些場景”能做到多大，還要取決於資料庫擴充的方式能夠處理的向量資料規模以及效能等等，現階段看來還沒有定論。
5. 向量會是未來世界統一的資料表示方式嗎？
圖源：https://unsplash.com/
蘇鵬：您剛剛說當向量資料比較少的時候，其實使用者選擇是比較多的，因為資料量小基本上總能解決問題。但是當資料量逐漸變大的時候，其實我們更需要一些最佳化手段，或者一些專業的方法。
我最近看到一種觀點，說向量的表示未來有沒有可能成為世界統一的資料表示方式？那如果是這樣的話，其實相當於向量規模會爆發式的增長，或者它很有想象空間，您對這種說法怎麼看？
湯林鵬：這個問題我們已經思考了快 10 年了。我們之前做的生物識別，它也是用向量表徵，而且是多個向量，你可以認為是一個 Tree / Graph of Vectors。現在來看的話，大模型肯定是個很好的契機，而且歷史本身也是迴旋上升的。
在大模型之前，其實我們接到最多的需求是影像影片類的需求，大模型興起之後更多的需求是語言類的。現在有一些比較大型的場景，比如金融、科研等重知識類的行業，它的資料量其實非常大，所以我們的產品會有比較大的優勢。現在大模型又在往跨模態的方向演化，之後可能文字、影像和影片又會做融合，比如自動駕駛現在可能也在往 Transformer 大模型的技術路徑上走、具身智慧有了大模型的加持，它的想象空間和落地的可能性也一下子變大了。所以總體來講，非常感謝 OpenAI，因為是他們的堅持把 Scaling Law 走出來，我們才能看到 AI 從去年開始到今天依然有著加速爆發式增長的勢頭。我們對這個領域是非常看好的，也在和我們的合作伙伴以及客戶，積極探索麵向未來的大模型加大資料的新正規化。
蘇鵬：其實萬物皆可 Embedding 的共識在 ChatGPT 沒出現之前大家就已經達成了，確實是任何資料都可以用向量來表示，而且產生了一個很大的想象空間，例如一張圖片 + <藍色背景、紅色背景> 的文字描述就可以產生兩張圖片，這個如果從原始資料是沒辦法直接操作的，如果不依靠模型，而是看作兩個向量的算術運算，能夠實現這樣的效果是很有想象力的一件事。向量是否會是未來世界統一的資料表示方式，這個還要看技術的演進究竟達到了如何程度。
6. MyScaleDB 為什麼選擇從 SQL 的角度切入
圖源：https://myscale.com/blog/why-sql-for-rag/
湯林鵬：MyScaleDB 是我們結合列式的 SQL 資料庫 ClickHouse 來做的，更多結合了 SQL + Vector 的儲存查詢聯合的最佳化，同時也在向量演算法上做了很多最佳化。
像 ClickHouse 這種列式的資料庫，它對於結構化資料、向量、JSON、空間、時序，以及各類的資料型別都有比較好的支援和最佳化，而且在 trillion 級別的資料上有過非常多的打磨。我們當時做選型的時候，的確也考慮過直接包 Faiss 來做個系統，這個肯定也是最快的。但是另一方面，我們還是想做一些長遠來看比較有影響力的東西，所以就想要做個 AI 資料庫。而 AI 資料庫就不能只支援向量了，還是得把其他模態的資料都包進去。當然我們並不想重複造輪子，因為開發一個資料庫需要各種場景的打磨，投入還是比較大的。
MyScale 的技術路徑是在高效能的列存 SQL 資料庫 ClickHouse 上做了深入改造，把 SQL 和向量的執行、儲存引擎融合在一起，同時在向量演算法上也結合整個執行、儲存做了很多最佳化。
ClickHouse 自己也有向量的功能，但一直到現在還是實驗性的功能。MyScale 會聚焦於 AI 的場景，把向量和 SQL 聯合查詢，還有相關的一些 AI 周邊生態工具做好，這也是基於我們對這個行業有足夠深的理解和 know-how，同時也是一個團隊長期的優勢。因為對一個行業沒有足夠的瞭解，是無法比客戶想得更長遠的。那又怎麼能開發出領先的功能，又怎麼能贏得市場呢？這些都需要長久的積累和思考。
我們的出發點還是想給這個世界帶來些獨特的創造和貢獻，所以就儘量地去利用已有的 SQL 資料庫。因為的確 SQL 資料庫的歷史也有 50 年了，中間經歷了大資料、NoSQL 等等，現在反而又回到了 SQL 架構上，所以也可以說 SQL 資料庫越來越有生機了。
MyScale 其實是第一個，據我所知也是世界上唯一一個支援 SQL，而且效能和綜合價效比大幅超越專有資料庫的產品。SQL + 向量的優勢比較突出，因為它相容了很多傳統資料庫、大資料處理的模式。但是 SQL 怎麼和向量聯合在一起，如何把結構化和非結構化的資料管理好，以及與大模型更好地結合，這當中也有很多沒有解決的問題。我相信在大家的努力下，未來幾年這個領域一定能往前走。
儘管挑戰非常大，我們還是把程式碼迭代了 4-5 個版本，當中也涉及到了非常多的技術挑戰，現在大家看到的是我們打磨出來的比較滿意的版本了。大部分功能都已經在開源版本推出，開源版完全可以滿足資料量不太大時候的需求，歡迎大家去使用。
GitHub: https://github.com/myscale/myscaledb
當然如果大家有更大需求量（比如數千萬甚至更多），以及其他商業化的需求，歡迎聯絡我們或者使用我們 SaaS 版本（myscale.com）。
7. 相容 SQL 會帶來哪些變化？
圖源：https://myscale.com/blog/why-sql-for-rag/
蘇鵬：您覺得對於向量資料庫來說，兼不相容 SQL 語句，或者是介面的方式，從現在或是未來來看，您覺得會有什麼差距？您當時做這種選擇的背後是基於什麼思考呢？
湯林鵬：全球知名的資料庫專家 Andy Pavlo 教授有這麼一個觀點，他認為向量資料庫未來可能會存在兩種形式：一種是整合式的資料庫，而 SQL 加向量肯定是其中非常重要的一個品類，因為 SQL 是結構化資料庫查詢的最主要語言，不過把兩個系統融合起來最佳化好，還是很有挑戰的。另外一種存在的形態，是像 Pinecone 這種專用向量資料庫，它會有自己的空間。不過這類專用向量資料庫要想長期生存的話，最好是要和 SQL 這種更加主流的資料系統來整合並做好配合，也就是做好外掛，並在易用性和價效比上有極致的最佳化。
蘇鵬：那為什麼選擇在 2024 年 4 月這個節點推出呢？包括開源版本的出來。
湯林鵬：倒是沒有什麼特別的考慮，因為程式碼迭代了4-5個版本，我們才覺得可以推出了。不過很可能大家也會想，我們做得挺早，大約 2020 年前就開始設計和開發了，現在市場已經很熱鬧了，是不是推出得有點晚呢？很多朋友和投資人也會這麼問。不過這個在我看來並不擔心，因為大模型的深化落地，以及大模型和大資料的正規化可能才剛剛開始。
去年整個市場可能噱頭和炒作多一些，今年我們看到了更多的落地，也算是個比較好的時機吧。當然我認為大模型的技術也需要再向前發展，我也希望我們的這套正規化之後可以和大模型有更深度的結合，或是有更好的 AI 系統的呈現。
8. SQL 語句規則是自己設計的嗎？
蘇鵬：那咱們 SQL 語句的規則相當於是咱們自己設計的嗎？
湯林鵬：我們是給 index 加了一個特殊的型別，也就是一個 Vector index。當然我們有一些預設的推薦型別，儘量把配置、引數等等給大家簡化掉，所以大家基本不需要指定太多引數。
另外在檢索的時候，我們有一個 UDF 叫 distance function，它能根據索引返回最近的一些向量。當然這個可能之後還要擴充，比如我們最近已經把倒排表加進去，之後可能還要把向量和倒排表的聯合查詢加進去，再之後可能還有 multi-vector 多向量表徵和檢索。
除了上面說到的，我們還會對更多的行業做整合和擴充。現在很像資訊化系統的早期，當時像 Oracle 這種公司就是賦能各行各業的，我們現在其實也希望能夠透過這種 SQL 向量資料庫的形式去賦能千行百業，所以也是需要不同行業的需求去做各種最佳化，或者說加各種運算元，這些我們都在跟客戶合作，一起打磨中。
蘇鵬：我感覺現在確實有好多廠商也在考慮透過 SQL 的方式來實現向量的檢索。各家廠商也都在做自己的，可能未來會反過來，推著 SQL 的規範再擴充呢？
湯林鵬：我覺得不會大變，SQL 本來也是有 UDF 和各種 dialect。SQL 發明 50 年沒有大變過了，所以我覺得問題不大，有些擴充而已。
9. 為什麼選擇開源？
圖源：https://kinsta.com/knowledgebase/open-source-vs-closed-source/
蘇鵬：MyScaleDB 為什麼會考慮開源出來，而不是直接推出個商業版本呢？
湯林鵬：其實我們是有商業版本的。我們最先進的 SQL 向量的引擎還是在商業版來提供的，畢竟公司還是得生存下去。不過我們的開源版本處理 500 萬以下的向量是完全夠用的，我們也提供了完整的 SQL 加向量的支援以及倒排表功能。相較於其他產品，我們認為 MyScaleDB 是有足夠大的差異化和優勢的。開源出來也是希望大家可以先去嘗試一下，畢竟商務週期也是挺長的，先用開源產品體驗一下我們的技術實力，增進一下對 MyScaleDB 的技術理解和信任。所以釋出開源版本一方面是希望為社會做點貢獻，另一方面也希望擴大一下公司和產品的影響力。
蘇鵬：目前國內做 Infra 的團隊，選擇開源這條路還是挺多的。從 PingCAP 開始開源後，很多做 Infra 的創業公司都會先開源出來，然後再做商業化的探索。其實開源並不是我們說的商業模式，粗暴來說它更可能是一種市場手段，來獲取使用者的信任。試用開源功能的同時，另有一些功能是收費的，是有商業版本的支援的。
另一方面，開源是把技術開放出來，讓更多人看到，以此來獲得更多反饋，再回過頭助推技術的進步，也是種對技術的貢獻，這個層面來講就不單純是商業行為了。
湯林鵬：是的，這個我很認可。同時，我也覺得開源是公司行為，但其實也不單純是個商業行為，如果純粹是為了賺錢而去做公司的話，肯定有更多更輕鬆的方式。但是既然選擇了 infra 和技術，肯定是希望透過技術去賦能行業，並且實踐在商業上的可行度。
不過我們的確承載了一些技術理想和社會責任感的，開源可以增加互信，這對於 Infra 來說還是很重要的特性，可以幫助使用者更低成本，甚至零成本來試用，後面其實也會更願意為我們的產品買單。包括 Infra 產品，也需要廣泛培養各行各業的生態合作伙伴，很多時候先讓大家用開源版本來試會更容易一些，所以我認為開源和商業是可以很好結合的。
10. MyScaleDB 的下一步規劃
圖源：https://mp.weixin.qq.com/s/JvyKnEbdOSb1fTwhiQTO5A
湯林鵬：近期我們上線了倒排表功能，這個對很多客戶來說還是比較關鍵的。現在像 Pinecone、Qdrant、 Weaviate 應該都有了這個功能，不過我們發現功能還是比較弱的，和 Elasticsearch 是沒法比的。當然我們也不可能從周邊功能上全面超越 Elasticsearch，他們畢竟也積累了 20 年，是個國際知名的大公司。我們現在至少在基本的使用場景上可以滿足使用者的需求，後面再根據客戶的需求去迭代。我們在向量方面比 Elasticsearch 有很大優勢，也包括 SQL 介面也比 Elasticsearch 有一定的獨特性和優勢，我們希望不會用太長時間，就能成為 Elasticsearch 的替代，也能有一定的市場空間。
另一方面，我們也看到了很多行業的機會，也和不同行業的公司去合作，比如金融、工業、科研、教育、醫藥等領域的公司，根據他們的需求去最佳化，整個 SQL + 向量領域是有很多工作可以做的。我們根據客戶的需求去最佳化查詢、增加更多的功能，包括分散式的向量查詢在海量資料下也有很大的最佳化空間等等，這些都是我們希望和客戶、合作伙伴一起合作推進。
在 SQL 資料庫的時代，很多廠商也會把精力投入在周邊的生態工具開發中，來增加產品的易用性。那 AI 時代的周邊工具，其實就是資料的解析、向量化，包括 RAG/Agent 的 Workflow 等。
我們其實也會沉澱自己的工具和方法論，後面也可能會考慮部分開源出來。不過我們對待開源是比較謹慎的，還是希望做得足夠好再開源。其實能做的事情很多，還是要面向未來，從真正能夠服務客戶和合作夥伴的角度去做。
11. AI 資料庫的未來如何？
蘇鵬：我們回到向量資料庫。MyScaleDB 定位是 AI 資料庫，不是一個單純的向量資料庫。那從向量資料庫到 AI 資料庫的這個階段，湯總覺得未來的發展方向，或是可能的演進趨勢是什麼樣的？
湯林鵬：如果定位在 AI 資料庫，那就需要把 AI 相關的資料都管理起來。當然它不是 one size fits all，但是我覺得是 one size fits most。比如說我們的技術選型，那註定了它對於事務的處理不夠高效。如果你的業務場景中事務很多，那可能還是得去選 pgvector 或是 TiDB。TiDB 和 MySQL 是相容的，它也加了向量檢索，當然這種系統的向量功能是有本質缺陷的，比如行存在複雜查詢和資料分析中就會比較難最佳化。
而如果你有海量的資料做分析、查詢等等，而且資料還是不同型別和不同模態的，那這個都算在我們定位的 AI 資料庫的範疇內，我們都會根據客戶市場的需求，把這些功能做打磨。為什麼做倒排表，也是因為語言模型市場的需求最旺盛，這是客戶需要的功能，所以我們就安排加上。
那說到其他的模態，後面如果我們想服務一個生物蛋白質 DNA，或者自動駕駛、具身智慧的資料庫，我們肯定得把他們相關的一些模態和相關函式做個匹配。還有剛才說到的非結構化資料的匯入（Unstructured Data Pipeline），或者整個 RAG 相關的 workflow 的支援需求等。我們認為還是要帶一點技術的前瞻性，參考市場中比較前沿的客戶需求來迭代產品。
12. 技術理想主義者
圖源：利用 OpenAI DALL-E 創作
蘇鵬：從剛才和湯總的對話中，我感覺您對於技術還是有相當高追求的，包括我們前段時間看到的像楊植麟、王小川和朱嘯虎他們所引發的關於技術理想主義的討論，受到了大家廣泛的關注。那您覺得，您自己是技術理想主義者嗎？
湯林鵬：我認為我是帶有一定的技術理想主義色彩的。比如我們之前做的生物識別領域，其實當時對整個行業都有著顛覆式的提升，我們把原有的系統做到自動化，效能上也是有幾百到一千倍的提升，破獲了數萬起重大案件。不過後面很有意思的是，這個市場需求本身就有限，所以我們其實從技術角度把市場給做小了。從商業角度上來說，這肯定不是個特別成功的嘗試。但從公共安全方面，我們的努力還是比較顯著地改善了社會的執行方式。儘管商業上不算成功，但是對我個人而言，相關的成就感都是長久以來印象都非常深刻的，這可能就是理想主義的部分。
AGI 會更加複雜一些，也帶來了很多爭議。比方說 Sam Altman 可能從市場的角度上來宣傳，他認為 AGI 很快就會來到，AI 也會從根本上改變社會執行的方式，大家要考慮 Universal Basic Income （UBI）等。某種意義上講，我認為他提出的這個 UBI 機制是需要被好好設計的，我的確認同 AI 很大意義上會改變社會，但是從什麼方面去改變社會，好的方面還是不那麼好的方面，我認為我們還是有一定的影響力和發言權的。說到底我們需要的一個大模型，它是相對靜態的虛擬存在，在很多方面與人競爭，也會被用在一些產品上，讓大家沉浸在不良嗜好當中。那我們會希望之後生活在這種社會中嗎？或者會希望我們的子女生活在這種社會中嗎？至少我是不太能接受的。
我們的出發點還是更看重資料這塊兒，我們認為資料其實是連結大模型和世界、也是連結大模型和使用者的紐帶，如果我們能把大模型和資料結合起來，無論是產品角度，還是系統角度，或是更深層次的大模型內在執行機理，把資料很好地結合進來，也會更加高效。這幾項工作我們已經在做，或是和合作夥伴一起在做。我認為我們是有機會去打造更加專業、實時、和人協作更加高效的 AI。而且這種協同協作起來也能更加感受到價值和成就感，也包括讓社會文明不趨向於收斂或是崩塌，而是爆發出更大的生機出來，向外擴充。在這些層面上我們正在努力，也會非常希望能促成上述這種圖景。
這些其實也是需要和我們的合作伙伴和客戶共同打造的，而且這個過程我認為是有機會創造更大價值的，因為這個系統本質上更加符合人性，和商業並不違背，或者講也是一種向善的商業模式，所以我認為兩者是可以結合的。因為之前的確走過一些彎路，所以商業上我們還是比較小心的。
蘇鵬：是的，良性的商業模式還是會存在的。那我理解技術理想主義可以從兩方面解讀，第一個是 Don't be evil。我們需要用技術來改變世界，但是不能從惡的角度出發，要用技術創造社會價值。第二個是堅信技術的創新性和引領性，哪怕現在不被大多數人所理解。
對談的內容就告一段落了，下面是直播時使用者的提問，湯總集中做了解答，蘇鵬老師也做了補充，供各位參考。
三、Q&A
向量就是近似計算嗎
向量並不是近似計算的同義詞。近似計算是與向量有關的機器學習的過程中會用到的方法。比如，在推薦系統或文件檢索中，可以使用近似最近鄰搜尋（Approximate Nearest Neighbor，ANN）演算法來加速搜尋過程。
向量資料庫可否部署在端側，在端側的應用前景如何？
向量資料庫可以部署在資源比較多的端側，比如車端，邊緣端伺服器等，就像 MyScale 也支援 ARM 編譯。端側的能力越來越強，之後也會更多地與雲端結合，所以前景不錯。
如何看待在像 RAG這類場景中似乎向量檢索的效率並不是目前的瓶頸問題相反準確率才是瓶頸問題
RAG 場景中，向量檢索的效率和準確率都是非常關鍵的因素，向量資料庫在其中則扮演著至關重要的作用。透過最佳化搜尋策略（如前過濾和後過濾），向量資料庫可以幫助提高檢索效率；而結合結構化資料過濾以及向量和關鍵字檢索可以綜合提高準確率。
這個準確率也不完全體現在anns的召回率而是原始資料的相關度，對於向量資料庫來說效率和精度不再是一個重要的資料庫衡量指標了嗎
召回結果跟原始資料的相關度與文件解析、分塊、向量化的演算法相關，單就向量資料庫來說，還是主要衡量效率和精度。另一方面，隨著客戶資料量的增長，支撐同樣數量的向量，需要的成本也是一個比較重要的指標。
現線上上 ANN 推薦的單元是多少個向量，多少維的？（一臺機器/例項是一個單元 ）
一般來說，單機能夠放的下，就不要上分散式。以 MyScale Cloud 為例，目前單機最大能存放 3.2 億 768 維向量。
是否可以認為 SQL 就是向量資料庫的一個 web 前端？
大部分向量資料庫提供自己定義的 RESTful 介面。MyScaleDB 採用 SQL 作為介面，SQL 作為通用的資料庫語言，允許 MyScaleDB 實現更豐富的功能。
MyScaleDB 支援哪些索引，都開源了麼
MyScaleDB 開源版本支援 ScaNN、HNSW(SQ)、IVF(SQ/PQ) 索引，我們比較推薦 ScaNN，考慮向量檢索效能和向量索引的構建時間等，ScaNN 是綜合表現最好的。在企業版本中，MyScaleDB 推薦 MSTG（Multi-Scale Tree Graph, MSTG）向量引擎，在數千萬或者更大資料量上資料密度有 10x 提升，效能也有近一個數量級的提升。
MyScaleDB 有做知識庫相關的計劃嗎，知識庫和向量庫的差異在哪
MyScaleDB 本身是 SQL 向量資料庫，而知識庫需要提供更加完整的介面，比如文件的入庫、解析、向量化，還有語義檢索等。我們會考慮在其他產品模組或開源專案中提供這些功能。
事務的邏輯對於向量是否有必要呢？還是說主要是為了向量表裡的其他標量欄位
向量資料庫名為資料庫，使用上用法更接近於搜尋引擎；因此事務在這裡並不關鍵，一般的向量資料庫也只保證最終一致性，而沒有事務的機制。
多模態的資料如何做到向量的統一對齊，是透過模型做了編碼對齊在儲存到向量資料庫嗎？
這個一般是向量化模型考慮的。比如 CLIP 模型可以將圖片和文字統一到一個向量空間。
向量資料庫還有什麼值得探索的科研方向嗎？
異構硬體實現更大的向量加速 非結構化資料的多向量表徵（multi-vector），實現更精準的匹配 混合查詢 動態資料查詢 資料安全與隱私
針對不是很大的場景（如：50w * 128dim 類似常規場景），向量庫和向量資料庫之間，應該如何選擇和取捨？
如果只是實驗性質的需求，而且如果沒有其他的後設資料，對於帶過濾條件的向量搜尋沒有什麼需求，可以考慮只用向量庫的。 如果是生產級別的需求，或者需要結構化、向量、關鍵字等聯合查詢，還是推薦用資料庫。