都2026了，我們離低成本搭個(gè)本地多模態(tài)知識(shí)庫還有多遠(yuǎn)？

12月1號(hào)，杭州靈隱寺免費(fèi)那天我去了，

結(jié)果去了才知道要預(yù)約，現(xiàn)場(chǎng)可以臨時(shí)加名額但是要身份證，電子的都不行。

后面去的財(cái)神廟，結(jié)果抽簽沒趕上，抹黑下山。

我很好奇大家都是從哪獲取這些最新消息的，小某書搜索后點(diǎn)最新看看避雷貼？直接查公眾號(hào)？但更多時(shí)候直接搜是搜不出來的，要到對(duì)應(yīng)的文旅賬號(hào)翻半天。

所以我想做一個(gè)文旅助手，把真實(shí)景區(qū)文字描述、地理位置，開放時(shí)間，游玩的季節(jié)建議和門票等信息丟進(jìn)去。

這樣我跟朋友們出行的時(shí)候就可以不用單獨(dú)拉個(gè)群了，提前一周丟了一大堆某書，然后出發(fā)當(dāng)天所有人跟失憶一樣，又開始問又重新搜無限循環(huán)。（硬生生把我一個(gè)J人被逼成P人了）

OK，我腦子里過了一遍技術(shù)方案，頭有點(diǎn)大。

首先，圖片識(shí)別得用一套向量數(shù)據(jù)庫。景點(diǎn)的文字介紹，這些是非結(jié)構(gòu)化文本，得用全文檢索。然后，地理位置信息得有專門的空間數(shù)據(jù)庫來處理。最后，門票價(jià)格、開放時(shí)間這些，又是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的活。

要把這四五套系統(tǒng)捏合在一起的話，

查詢邏輯就得好幾步，

拿圖片去向量庫里比對(duì)，拿到ID，再去文本庫搜描述，最后再用業(yè)務(wù)數(shù)據(jù)庫里的價(jià)格和時(shí)間做過濾。

性能方面我包它是拉的。

遇事不決先看Github，說不定世界的某一處已經(jīng)有大神跟我的想法一樣，我就不需要重復(fù)造輪子了，然后發(fā)現(xiàn)了Langchain（老牌Agent構(gòu)建框架）跟一個(gè)叫OceanBase seekdb的數(shù)據(jù)庫合作了。

langchain-course-oceanbase.netlify.app

看了眼使用指南后，

seekdb竟然支持在一張表里，同時(shí)存儲(chǔ)和索引向量、文本、JSON、GIS這些亂七八糟的數(shù)據(jù)。而大多數(shù)其他數(shù)據(jù)庫要么只擅長(zhǎng)關(guān)系型事務(wù)，要么只擅長(zhǎng)向量，要么只擅長(zhǎng)全文，混合能力通常需要多系統(tǒng)拼裝。

LangChain解決的是把一個(gè) AI 應(yīng)用搭出來，有對(duì)話流程、工具調(diào)用、記憶、評(píng)估等，但它需要數(shù)據(jù)庫來解決檢索到底要落在哪個(gè)后端，怎么做混合過濾，怎么控制延遲和成本。

我這個(gè)文旅助手是RAG最難的檢索，圖片要相似（向量），描述要命中（全文），位置要限定（GIS），價(jià)格時(shí)間要過濾（結(jié)構(gòu)化）。如果后端是多套系統(tǒng)拼起來，LangChain只能把這些步驟串成一條鏈，跑是能跑，但很長(zhǎng)很慢，很容易報(bào)錯(cuò)。

seekdb負(fù)責(zé)把檢索+過濾+排序三板斧在底層一次性做完，中間少很多膠水代碼，也少很多不確定性。它把所有數(shù)據(jù)類型都拉到了同一個(gè)維度上。我可以像跟人說話一樣，用一條SQL指令告訴它，

河南安陽的距離市中心50公里以內(nèi)的，80分以上，適合春季旅行的人文景點(diǎn)

數(shù)據(jù)庫自己會(huì)在底層把圖片相似度、文本相關(guān)性、GIS空間關(guān)系和價(jià)格這些硬性指標(biāo)一次性算好，

然后直接把最精準(zhǔn)的結(jié)果吐給我。

這里我想稍微解釋一下混合搜索到底是在混什么，

我這條需求里其實(shí)有四類信號(hào)，這張照片“像不像”另一個(gè)景點(diǎn)（圖像），描述里有沒有幽靜古樸這類硬條件（全文檢索+倒排），只要我周圍 5 公里（GIS 距離+范圍查詢），票價(jià)<50、開放時(shí)間符合（關(guān)系型過濾）。

難的是把這些信號(hào)合并成一次可控的檢索執(zhí)行，

我還是用旅游類比一下，

我要在一堆目的地里選一個(gè)最適合跨年的。

常規(guī)做法是先撈一小撮候選，向量召回是按你想要的感覺找相似目的地，比如氛圍感，雪景，夜景，煙花，全文召回是按你搜的詞再撈一批，比如直飛，溫泉，跨年煙花，免簽，地理范圍再選一次，比如 飛行不超過6小時(shí)。

這時(shí)候你會(huì)先拿到一個(gè)候選清單TopK，還沒結(jié)束，要給每個(gè)候選算分，再加權(quán)合成總分排出優(yōu)先級(jí)（重排Rerank）。再加硬條件過濾：預(yù)算、請(qǐng)假天數(shù)、出發(fā)時(shí)間、是否直飛，最后才是按總分排序選出我心儀的。

我看文字就呼吸不過來了，肉眼可見的慢。

seekdb就是在同一條流水線里把語義找相似+關(guān)鍵詞匹配+距離計(jì)算+預(yù)算時(shí)間過濾一次性算完，少了跨系統(tǒng)搬運(yùn)和多次回表速度也就上來了。

最低1核CPU、2GB內(nèi)存就能跑起來。在現(xiàn)在人均模型起手就要24GB的節(jié)點(diǎn)，我都有點(diǎn)不適應(yīng)了。seekdb還能當(dāng)MCP Server用，直接接入Cursor，Trae啥的。

還跟Dify打通了，可以直接做Dify的知識(shí)庫。

那我就把這兩天折騰的過程復(fù)盤一下。

第一步，部署，非常簡(jiǎn)單，

電腦有Docker環(huán)境，直接一行命令搞定了。

docker run -d --name seekdb -p 2881:2881 oceanbase/seekdb:latest

如果習(xí)慣用Python，那更簡(jiǎn)單，pip install pyseekdb就行了。

接下來就是構(gòu)建我想要的文旅小助手，

我需要一個(gè)大模型的API key，把文本轉(zhuǎn)成向量和后續(xù)問答。還需要一個(gè)地圖服務(wù)的API key，用來處理地理位置，這里我用的是千問和高德。

數(shù)據(jù)集我用的是Kaggle上一個(gè)公開的352個(gè)中國(guó)城市景點(diǎn)數(shù)據(jù)。

準(zhǔn)備就緒后，就是三件套，

克隆項(xiàng)目代碼，安裝依賴，把申請(qǐng)的API密鑰和本地?cái)?shù)據(jù)庫的連接信息填進(jìn)去。（這命令這八步是真壓縮到?jīng)]得再壓了，直接看也行）

www.oceanbase.ai/docs/zh-CN/build-multi-model-application-based-on-oceanbase/

# 1. 克隆項(xiàng)目
git clone https://github.com/oceanbase-devhub/ob-multi-model-search-demo.git
cd ob-multi-model-search-demo

# 2. 將kaggle上數(shù)據(jù)集解壓到項(xiàng)目目錄
mv ./archive.zip ./citydata.zip
unzip ./citydata.zip

# 3. 安裝依賴
poetry install

# 4. 設(shè)置環(huán)境變量
vim .env
    ## 數(shù)據(jù)庫連接串中的主機(jī)地址
    OB_URL="******"  
    OB_USER="******"  
    OB_DB_NAME="******"  
    ## 數(shù)據(jù)庫連接串中的密碼
    OB_PWD="******"

# 5. 大模型 API Key
DASHSCOPE_API_KEY="******"

# 6. 高德地圖 API Key
AMAP_API_KEY="******"

# 7. 自動(dòng)導(dǎo)入數(shù)據(jù)
python ./obmms/data/attraction_data_preprocessor.py

# 8. 最后一步就是啟動(dòng)UI界面
poetry run streamlit run ./ui.py

當(dāng)瀏覽器里彈出那個(gè)簡(jiǎn)潔的對(duì)話框時(shí)，

我感覺這幾天的折騰都值了。

它能夠理解我問題里那種模糊的的描述，然后通過向量搜索找到語義上相似的景點(diǎn)，再結(jié)合地理位置和一些我預(yù)設(shè)的偏好進(jìn)行過濾。

這在一年多以前，是很難想象的。

有了多模態(tài)知識(shí)庫和混合搜索，

工程師拍下故障機(jī)器的照片，用語音描述刺耳的異響，系統(tǒng)就能瞬間從海量的維修手冊(cè)，歷史工單和實(shí)時(shí)傳感器數(shù)據(jù)里，找出最可能的解決方案。

你也可以上傳在街上看到的衣服照片，然后說，我想要類似風(fēng)格，但材質(zhì)是純棉的，價(jià)格在三百塊以內(nèi)的。系統(tǒng)不再是簡(jiǎn)單推薦一堆長(zhǎng)得像的圖片，而是真正理解了你所有維度的需求。

到現(xiàn)在我還是有種想當(dāng)然的荒謬的感覺，

作為程序員，這些環(huán)節(jié)我已經(jīng)習(xí)慣性分開處理了，

但忘掉腦子憑直覺去想，

多模態(tài)的數(shù)據(jù)不就是應(yīng)該放在一個(gè)數(shù)據(jù)庫里面嗎？

很合理吧！

目前模型的前端都可以vibe出那么多效果了，

再把數(shù)據(jù)庫打通，

我真的要說那句話了，

AI時(shí)代，

每個(gè)人都可以用五分鐘做個(gè)自己的應(yīng)用，

到時(shí)候AI人奇妙夜是不是可以辦起來了。

@ 作者 / 還在琢磨知識(shí)庫的卡爾兒

最后，感謝你看到這里如果喜歡這篇文章，不妨順手給我們點(diǎn)贊｜在看｜轉(zhuǎn)發(fā)｜評(píng)論

如果想要第一時(shí)間收到推送，不妨給我個(gè)星標(biāo)

如果你有更有趣的玩法，歡迎在評(píng)論區(qū)和我聊聊

更多的內(nèi)容正在不斷填坑中……