嵌入模型：文本“已死”，多模態(tài)尚有紅利，2025Q4科技觀察

2025年Q4，上市公司Elastic對JinaAI的收購，

在掌聲中落幕。

嵌入模型（Embedding）賽道的故事也降溫了。

JinaAI是LLM時代的新秀，

在嵌入模型領(lǐng)域擁有成熟技術(shù)棧。

嵌入模型不是新玩意，

在AI基礎(chǔ)設(shè)施領(lǐng)域，

是有一定歷史的“常用組件”。

或者說，在AI理解世界方式的演進(jìn)道路上，

“嵌入模型”這一組件不可或缺。

而Elastic公司，

則在荷蘭阿姆斯特丹成立，

紐交所上市，

尤其擅長檢索與日志分析軟件，

Elastic當(dāng)年雖然是搜索和AI基礎(chǔ)設(shè)施公司，

但選擇了更為傳統(tǒng)和嚴(yán)格的紐交所，

體現(xiàn)它作為企業(yè)級基礎(chǔ)設(shè)施廠商，

（比如Snowflake）的一種穩(wěn)重定位。

從純技術(shù)角度講，是一家中間件平臺，

Elastic收購的原因是啥？

看上去，中間件公司購買了AI新貴，

耳熟能詳?shù)拇鸢甘牵?/p>

Elastic補(bǔ)齊其在模型，

工具鏈和開發(fā)者體驗層面短板，

從而把產(chǎn)品鏈條做得更完整。

文本嵌入模型已趨于成熟，

成為AI基礎(chǔ)設(shè)施的一部分。

在AI基礎(chǔ)設(shè)施被云廠商通吃的周期里，

趕緊把"技術(shù)流量"轉(zhuǎn)成“被收購的價值”實屬正解。

在我看來，嵌入模型雖然不再是黃金極熱賽道，

但它依然在產(chǎn)業(yè)里是螺絲釘般的存在。

文本向量化

（embedding，

文本經(jīng)過嵌入模型后的向量表示過程），

正在演變成一種成熟的通用能力。

嵌入模型競品不少，且開源，

不難發(fā)現(xiàn)，OpenAI、阿里Qwen頭部公司幾家，

都有嵌入模型，

不過OpenAI發(fā)布的最早，

可以追溯到 2022 年 12 月；

除了提高性能之外，一直發(fā)力于降成本；

也就是檢索的成本越來越低。

嵌入模型越大，成本越高，

消耗更多的計算、內(nèi)存和存儲資源。

這里說嵌入模型大，

就是向量維度高的意思。

好比，

小是模糊照片，

看得快但細(xì)節(jié)少；

大是高清照片，

細(xì)節(jié)豐富但文件大。

要不要“開高清”，

取決于你想看多細(xì)。

我觀察到的情況是：

觀察一，

嵌入模型對大模型公司意味著什么呢？

頭部大模型團(tuán)隊會順手做一個，

簡單說，只是"順手禮包"，不是戰(zhàn)略高地。

那么嵌入模型還有什么玩頭？

觀察二，文本嵌入的門檻在被快速抹平。

幾年前，“誰能把語義檢索做順滑”還算差異化，

但到今天，跑出一個能用的嵌入模型并不難。

開源模型、現(xiàn)成的訓(xùn)練腳本、乃至商用API，

足夠讓大多數(shù)團(tuán)隊低成本起步。

有技術(shù)小哥哥告訴我：

“BAAI General Embedding和JinaAI，

打得有來有回，他們就在這兩款之間換著用，

哪個好用換哪個。”

我在智源有一個朋友，他告訴我，

BAAI General Embedding的主要技術(shù)骨干，

是一位低調(diào)大佬，

直接匯報給王仲遠(yuǎn)，

雖然我給他發(fā)了郵件，

但是為了不給獵頭送炮彈，

本文不實名大佬名諱。

技術(shù)小哥哥們常說，

誰的開源新版本好，

就用誰的，何必買單？

這句閑談的背后，

付費意愿隨之蒸發(fā)。

嵌入模型很容易做好嗎？

答案是否定的。

當(dāng)答案是否定的，

這就得到了我的第三個觀察，

嵌入模型：門檻雖低，做精不易。

現(xiàn)在的嵌入模型市場很清晰地分成兩種：

入門級和企業(yè)級；

做出一個能用的，并不困難：

經(jīng)驗有且豐富，

我?guī)啄昵皩戨娚掏扑]系統(tǒng)（阿里和京東）的時候，

就寫過類似組件。

我的理解是：

“嵌入模型就像是給語言拍‘X 光’——

它不生成句子，而是揭示“語義的形狀”。

有了這些語義坐標(biāo)，AI 才能真正知道，

哪兩句話‘意思差不多’，

哪兩篇文檔‘八竿子打不著’。”

現(xiàn)在有開源用起來更爽。

入門級用于輕量級應(yīng)用；

企業(yè)級適合復(fù)雜語義檢索場景，

RAG 高質(zhì)量高要求場景。

紫東太初多模態(tài)檢索算法負(fù)責(zé)人，

高級算法經(jīng)理郭海云博士，

她告訴“親愛的數(shù)據(jù)”：

“嵌入模型更強(qiáng)調(diào)通用性，

而不是微調(diào)以契合特定業(yè)務(wù)域，

從創(chuàng)新研發(fā)技術(shù)上來說，

這個似乎不是難點了，

更多的是工程實現(xiàn)的巧妙權(quán)衡。”

類似技術(shù)重點包括，

如何在有限資源上保持泛化能力？

又如何將文本、表格、

圖像、代碼等多模態(tài)特征，

融合到一個穩(wěn)定向量空間。

看上去，能否在這些工程化難題上長期交付，

還是要看團(tuán)隊技術(shù)水平。

另外，別忘了另一類需求：

是快速試點和中小團(tuán)隊落地。

這個需求，

基本上被JinaAI的開源模型很好地解決了。

問題來了，

JinaAI靠什么上岸？

它家的優(yōu)勢更準(zhǔn)確地說是，

差異化，而非絕對領(lǐng)先。

具體來說：JinaAI在開源社區(qū)的傳播力、

對開發(fā)者友好的工具鏈、

以及易上手組件的能力，

確實讓它在快速試點和中小團(tuán)隊落地上具有優(yōu)勢。
這些特點是它的差異化，

也是Elastic有意收購或合作的邏輯所在。

相信大家也看出來了，

嵌入模型不是護(hù)城河，

是螺絲釘，

客戶需求不同，

螺絲釘?shù)男吞柧筒煌?/p>

還有的客戶關(guān)心：

成本能否壓到可用水平？

索引更新能否實時跟上？

表格、圖像、視頻等非文本數(shù)據(jù)，

能否被統(tǒng)一納入檢索？

我找到了一位原大廠嵌入模型資深研發(fā)，

我認(rèn)為，他來評價這件事足具資格，

原因是，

他是中國第一代大廠嵌入模型開源技術(shù)主力，

不僅如此，他的身份，

已經(jīng)從技術(shù)轉(zhuǎn)型為全棧產(chǎn)品經(jīng)理，

也有自己的收費AI產(chǎn)品。

很可惜，他不愿意實名，

不過我相信，一些投資人能猜出來，圈子很小。

他告訴我：

“Embedding都我自己弄的，再用ONNX，

“把PyTorch框架上的模型編譯成C++高速版”，

這樣就能讓BERT在CPU上飛起來。

他對比了在端上部署JinaAI的嵌入模型的情況，

對JinaAI的吐槽是：

JinaAI那些模型太大端上不適合。

其廠商官方還停留在“PyTorch”的原始時代，

自然被吐槽“又大又慢”。

他特意提到，他的方案，

比JinaAI（用Pytorch）推理效率高接近一倍。

嵌入模型有兩種技術(shù)路線，

Istari企業(yè)智能創(chuàng)始人，

楊薈博士告訴我：

“嵌入模型的結(jié)構(gòu)和LLM可以是一套

（比如LLM 架構(gòu)去掉中間幾層），

也可以不是一套的。”

一種是從 LLM 削出來的“Encoder子模型”。

另一種是專門為了相似度檢索優(yōu)化的模型，

或者說Encoder-only模型。

第二種技術(shù)路線的模型不依賴LLM，

而是獨立訓(xùn)練的語義編碼器，

結(jié)構(gòu)上依然是Transformer，

但細(xì)節(jié)上做了很多“工程強(qiáng)化”。

嵌入模型要被下游的RAG消費，

或者說和RAG配合使用。

RAG流程有這樣幾個步驟：

1.把企業(yè)已有數(shù)據(jù)（文檔、代碼、FAQ、圖像等）

預(yù)先做向量化，存進(jìn)向量數(shù)據(jù)庫。

2.查詢階段（實時）把用戶輸入的query轉(zhuǎn)換成embedding，

3.用戶問題和企業(yè)已有數(shù)據(jù)embedding在同一個向量空間里對齊。

4.把檢索到的上下文就是“專有數(shù)據(jù)”補(bǔ)充給LLM。

這樣一來，

大模型就能“理解”企業(yè)內(nèi)部數(shù)據(jù)，

即使它原本沒訓(xùn)練過這些文檔。

如果你仔細(xì)觀察，

會發(fā)現(xiàn)一個微妙的變化，

競爭已經(jīng)轉(zhuǎn)向多模態(tài)。

文本向量化的精度差異，

在很多場景里已經(jīng)不足以形成強(qiáng)壁壘。

行業(yè)敘事的重心已經(jīng)開始移動。

文本向量化的紅利期正在結(jié)束：

模型趨同，生態(tài)成熟，增量創(chuàng)新有限。

嵌入模型是“找資料”的工具，

長上下文是“讀資料”的范圍。

多模態(tài)嵌入模型，

正在成為新的機(jī)會窗口。

又或者是不得不踢的加時賽。

把圖像、音頻、

視頻、代碼等復(fù)雜數(shù)據(jù)，

壓縮進(jìn)一個可用的語義空間，

并能被下游——RAG（檢索增強(qiáng)生成）有效消費，

這才是2025年之后的真正戰(zhàn)場。

誰能解決多模態(tài)的“粒度對齊”與“上下文整合”，

誰就能在下一個周期里拔得頭籌。

整個行業(yè)往多模態(tài)方向上的加速被推動了。

RAG是業(yè)界當(dāng)紅解決方案，

也是嵌入模型消費的大頭，

若RAG沒前途，嵌入模型也沒有前途了，

我觀察到有如下行業(yè)觀點的碰撞：

正方觀點：

“模型長上下文能力的增長，

正在降低RAG的必要性。”

此方觀點認(rèn)為：

過去，大模型的上下文窗口有限，

RAG必須非常精準(zhǔn)，

把“最有價值的（文檔片段）”，

向量化后送給模型，

否則就放不下。

而如今，2M級上下文窗口已成為現(xiàn)實，

用戶可以直接把長文輸入模型，

繞過embedding，

也能獲得不錯的效果。

換句話說，embedding不再是“必須”，

而只是“可選”。

只要大模型能力一直增長，

只要OpenAI這樣的企業(yè)一直投錢，

只要這場競賽一直持續(xù)，

大于2M的上下文窗口需要用embedding嗎？

或者換一種專業(yè)技術(shù)表達(dá)，

當(dāng)上下文窗口超過 2M tokens 時，

模型是否仍需要通過嵌入模型生成語義向量，

以支持RAG？

當(dāng)然，2M tokens≈3本《紅樓夢》

當(dāng)然embedding依然可以用。

原來就是很重要，

現(xiàn)在一些場景非必需了。

也就是說，

以前塞不下，

需要嵌入模型精準(zhǔn)地“挑出”。

而現(xiàn)在上下文變長（2M+ token），

——可以塞更多候選資料進(jìn)去，

對“精確召回”的要求沒那么高，

嵌入模型的存在價值，

從“必需”變成“輔助”。

長上下文解決的是“能放多少信息”；

RAG解決的是，

“如何找到最相關(guān)的信息”。

也就是說，

長上下文削弱了對“高精度embedding檢索”的剛需，在文本場景的“剛需屬性”正在消解。

文本檢索與大模型結(jié)合的護(hù)城河在坍塌。

坐擁1500+企業(yè)客戶的Elastic，

其客戶仍然有大數(shù)據(jù)量需求，

用嵌入模型作為一個工具沒問題，

但它已經(jīng)不是必備條件。

甚至部分產(chǎn)品已經(jīng)完全繞開嵌入模型，

效果還要好。

嵌入模型在文本這里的紅利期走到盡頭，

但多模態(tài)數(shù)據(jù)還沒有。

尤其是多種模態(tài)的數(shù)據(jù)，

無法直接用長上下文“硬塞”，

必須依賴這種手段，

文本的向量化正在成為成熟組件，

而多模態(tài)的向量化仍是行業(yè)必爭之地。

反方觀點上，

紫東太初多模態(tài)檢索算法負(fù)責(zé)人，

高級算法經(jīng)理郭海云博士，

告訴“親愛的數(shù)據(jù)”：

“我不贊同上述說法。”

郭海云博士參與了，

紫東太初Taichu-mRAG框架的研發(fā)，

（通過統(tǒng)一多模態(tài)細(xì)粒度檢索引擎，

與紫東太初多模態(tài)大模型協(xié)同，

實現(xiàn)了檢索召回率，

和端到端問答準(zhǔn)確率的雙重提升）

她談到，當(dāng)前AGI有兩大趨勢，

會導(dǎo)致模型的長上下文需求越來越高，

RAG的需求并沒有降低。

一個趨勢是很多場景需要模型進(jìn)行多模態(tài)推理，

推理中，思維鏈的生成，

會加劇模型輸入上下文的長度增長，

另一個趨勢是multi-agent技術(shù)的發(fā)展，

Agent的memory也會增加上下文的長度，

因為交互上下文就是memory的一部分。

尤其當(dāng)前Agent落地的一大瓶頸就是上下文工程；

上下文太長，信息冗余，

長上下文也還沒建模好，

上下文太短又信息不足，

所以需要檢索技術(shù)精準(zhǔn)找到最相關(guān)的上下文。

雙方觀點有分歧主要存在于，

RAG是否會因為大模型能力上漲而重要性下降，

但是，對于“多模態(tài)尚有紅利”，

雙方都沒有爭議。