前言

幾十年來，從報(bào)表系統(tǒng)到財(cái)務(wù)分析，再到用戶行為查詢，我們早已習(xí)慣了通過 SELECT–FROM–WHERE 的方式與數(shù)據(jù)庫對話。而在這一過程中，SQL 也逐漸成為人們對‘?dāng)?shù)據(jù)庫查詢’的默認(rèn)理解方式。甚至，當(dāng)年標(biāo)榜“反 SQL 革命”的 NoSQL，有無一例外，引入了 SQL 支持。

但歷來如此，就代表永遠(yuǎn)正確嗎？

根據(jù) Gartner 預(yù)測，到 2026 年，大多數(shù)企業(yè)將優(yōu)先采用自然語言作為查詢接口，SQL 將從“必選項(xiàng)”變成“可選項(xiàng)”。

而隨著大模型與向量數(shù)據(jù)庫的落地速度加快，我們需要重新審視：SQL是否還是數(shù)據(jù)庫查詢的最優(yōu)解？

01

自然語言交互，數(shù)據(jù)庫查詢的另一種解法

想象一下，不再需要寫復(fù)雜 SQL 查詢，而是直接說一句：“幫我找出最近購買行為和我最像的用戶最喜歡的商品?！?/span>

后臺就聽懂了你的意圖，然后迅速?zèng)Q定：

• 是查結(jié)構(gòu)化表？

• 還是做一次向量相似度搜索？

• 要不要調(diào)用外部服務(wù)補(bǔ)充數(shù)據(jù)？

做完這些決策，數(shù)據(jù)庫就能自行搞定所有執(zhí)行細(xì)節(jié)，返回你想要的結(jié)果。

而這樣做帶來的用戶升級主要包括：

? 零語法門檻，我們不需要記字段名、不怕括號亂套，表達(dá)需求更自然。

? 對非結(jié)構(gòu)化數(shù)據(jù)查詢更友好，圖像、音頻、文本都能作為查詢對象。

? 這套系統(tǒng)會的受眾會更加廣泛：不僅是工程師能用，運(yùn)營、產(chǎn)品甚至市場部也都能對數(shù)據(jù)進(jìn)行交互。

02

自然語言交互背后是Agent調(diào)度

那么實(shí)現(xiàn)基于自然語言的交互？業(yè)內(nèi)通常的做法是自然語言解析 + 向量檢索 + Agent 調(diào)度。

自然，這其中最重要的一環(huán)就是Agent 調(diào)度，它主要可以完成四大功能

• 解析意圖：判斷你到底是要查什么字段、查哪個(gè)庫、查哪個(gè)索引。

• 選擇策略：是做結(jié)構(gòu)化過濾，還是走向量檢索，還是兩者混合？

• 調(diào)用能力：直接執(zhí)行 API、觸發(fā) SDK，甚至跨服務(wù)聯(lián)合執(zhí)行。

• 結(jié)果包裝：不返回一堆亂七八糟的 JSON，而是你能立刻看懂的結(jié)果。

舉個(gè)例子：  在向量數(shù)據(jù)庫 Milvus 中，一行代碼就能完成一次復(fù)雜的相似度檢索：

results = collection.search(query_vector, top_k=10, filter="is_active == true")

這種“API-first” 的思路，天然適配大模型的 Function Calling、MCP 能力，執(zhí)行更快，出錯(cuò)更少，也更容易標(biāo)準(zhǔn)化和集成。

03

SQL為什么不適合做向量檢索？

一個(gè)共識是，非結(jié)構(gòu)化數(shù)據(jù)占據(jù)了全世界數(shù)據(jù)總量的80%，而向量數(shù)據(jù)庫，相比傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，天生適配自然語言查詢也更適配大模型。

當(dāng)然，為了解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫無法對非結(jié)構(gòu)化數(shù)據(jù)做查詢的這一弊病，很多傳統(tǒng)關(guān)系型數(shù)據(jù)庫也推出了“SQL 風(fēng)格的向量檢索”功能，比如PostgreSQL + PGVector 提供了 <-> 運(yùn)算符，下面這樣的語句看起來“挺高級”的：

SELECT *  FROM items ORDER BY embedding <-> query_vector LIMIT 10;

但表面上的“兼容”，又帶來了新的問題：這種SQL并未形成標(biāo)準(zhǔn)，從而給開發(fā)者帶來了更高的學(xué)習(xí)成本。不僅如此，將向量數(shù)據(jù)存儲在關(guān)系型數(shù)據(jù)庫中還存在嚴(yán)重的性能問題：

問題一，執(zhí)行路徑復(fù)雜：但傳統(tǒng)數(shù)據(jù)庫會強(qiáng)制走解析器、優(yōu)化器、事務(wù)等重邏輯路徑，導(dǎo)致消耗了大量額外的資源

問題二，I/O 壓力大：向量存成 BLOB，每次檢索都要解碼；圖索引場景還可能頻繁跳轉(zhuǎn)磁盤，極度消耗性能。

我們做過一個(gè)測試，在相同檢索條件下，Milvus 查詢延遲是 pgvector 的 40%，吞吐量提升了 4.5 倍。換句話說，傳統(tǒng)關(guān)系型數(shù)據(jù)庫套殼向量檢索，其實(shí)反而帶來了更大的系統(tǒng)復(fù)雜度。

整體來說，關(guān)系型數(shù)據(jù)庫和向量數(shù)據(jù)庫在設(shè)計(jì)哲學(xué)、數(shù)據(jù)結(jié)構(gòu)和查詢邏輯上，思路天差地別：

尾聲

總結(jié)來說，應(yīng)對AI時(shí)代，向量數(shù)據(jù)庫的優(yōu)勢有四：

1. 支持多樣化模型結(jié)構(gòu)

現(xiàn)實(shí)世界的數(shù)據(jù)遠(yuǎn)比表格復(fù)雜。向量數(shù)據(jù)庫能靈活支持嵌套文檔、時(shí)間序列向量，以及 ColBERT、CoLPAL 等多向量結(jié)構(gòu)，以適配不同模型生成的豐富語義表示。

2. Agent 友好的原生 API

大模型更擅長調(diào)用函數(shù)而不是寫 SQL。向量數(shù)據(jù)庫具備 Python-first 的 API 設(shè)計(jì)，原生支持 Function Calling，一行代碼即可完成嵌入檢索、過濾、重排序和語義高亮，極大降低開發(fā)和運(yùn)維成本。

3. 深度語義理解能力

向量數(shù)據(jù)庫不只是執(zhí)行命令，更能理解意圖。它與 AI Agent 協(xié)作，可以跳出“字面匹配”的束縛，實(shí)現(xiàn)語義層面的智能檢索，讓未來的數(shù)據(jù)庫不只要知道“怎么查”，更要知道“你真正想查什么”。

4. 召回率的極致優(yōu)化

通過結(jié)構(gòu)化過濾、混合檢索、Rerank 等手段，向量數(shù)據(jù)庫可以不斷優(yōu)化搜索結(jié)果的相關(guān)性，把更多真正有價(jià)值的內(nèi)容找回來，達(dá)成性能與召回的平衡。

一句話總結(jié)，向量數(shù)據(jù)庫并不是為了替代關(guān)系型數(shù)據(jù)庫，它更多情況下，是一種專門與 AI 場景相伴生的新型基礎(chǔ)設(shè)施，能更好的響應(yīng)你的自然語言查詢，也能夠?qū)φZ義信息進(jìn)行檢索。最終讓數(shù)據(jù)庫從死板的執(zhí)行者，轉(zhuǎn)變?yōu)檎嬲斫馍舷挛摹⒅鲃?dòng)幫你決策的數(shù)據(jù)智能體。

閱讀原文：原文鏈接