都2026了，我們離低成本搭個本地多模態知識庫還有多遠？

12月1號，杭州靈隱寺免費那天我去了，

結果去了才知道要預約，現場可以臨時加名額但是要身份證，電子的都不行。

后面去的財神廟，結果抽簽沒趕上，抹黑下山。

我很好奇大家都是從哪獲取這些最新消息的，小某書搜索后點最新看看避雷貼？直接查公眾號？但更多時候直接搜是搜不出來的，要到對應的文旅賬號翻半天。

所以我想做一個文旅助手，把真實景區文字描述、地理位置，開放時間，游玩的季節建議和門票等信息丟進去。

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

OK，我腦子里過了一遍技術方案，頭有點大。

首先，圖片識別得用一套向量數據庫。景點的文字介紹，這些是非結構化文本，得用全文檢索。然后，地理位置信息得有專門的空間數據庫來處理。最后，門票價格、開放時間這些，又是傳統的關系型數據庫的活。

要把這四五套系統捏合在一起的話，

查詢邏輯就得好幾步，

拿圖片去向量庫里比對，拿到ID，再去文本庫搜描述，最后再用業務數據庫里的價格和時間做過濾。

性能方面我包它是拉的。

遇事不決先看Github，說不定世界的某一處已經有大神跟我的想法一樣，我就不需要重復造輪子了，然后發現了Langchain（老牌Agent構建框架）跟一個叫OceanBase seekdb的數據庫合作了。

langchain-course-oceanbase.netlify.app

看了眼使用指南后，

seekdb竟然支持在一張表里，同時存儲和索引向量、文本、JSON、GIS這些亂七八糟的數據。而大多數其他數據庫要么只擅長關系型事務，要么只擅長向量，要么只擅長全文，混合能力通常需要多系統拼裝。

LangChain解決的是把一個 AI 應用搭出來，有對話流程、工具調用、記憶、評估等，但它需要數據庫來解決檢索到底要落在哪個后端，怎么做混合過濾，怎么控制延遲和成本。

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

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

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

數據庫自己會在底層把圖片相似度、文本相關性、GIS空間關系和價格這些硬性指標一次性算好，

然后直接把最精準的結果吐給我。

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

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

難的是把這些信號合并成一次可控的檢索執行，

我還是用旅游類比一下，

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

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

這時候你會先拿到一個候選清單TopK，還沒結束，要給每個候選算分，再加權合成總分排出優先級（重排Rerank）。再加硬條件過濾：預算、請假天數、出發時間、是否直飛，最后才是按總分排序選出我心儀的。

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

seekdb就是在同一條流水線里把語義找相似+關鍵詞匹配+距離計算+預算時間過濾一次性算完，少了跨系統搬運和多次回表速度也就上來了。

最低1核CPU、2GB內存就能跑起來。在現在人均模型起手就要24GB的節點，我都有點不適應了。seekdb還能當MCP Server用，直接接入Cursor，Trae啥的。

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

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

第一步，部署，非常簡單，

電腦有Docker環境，直接一行命令搞定了。

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

如果習慣用Python，那更簡單，pip install pyseekdb就行了。

接下來就是構建我想要的文旅小助手，

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

數據集我用的是Kaggle上一個公開的352個中國城市景點數據。

準備就緒后，就是三件套，

克隆項目代碼，安裝依賴，把申請的API密鑰和本地數據庫的連接信息填進去。（這命令這八步是真壓縮到沒得再壓了，直接看也行）

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

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

# 2. 將kaggle上數據集解壓到項目目錄
mv ./archive.zip ./citydata.zip
unzip ./citydata.zip

# 3. 安裝依賴
poetry install

# 4. 設置環境變量
vim .env
    ## 數據庫連接串中的主機地址
    OB_URL="******"  
    OB_USER="******"  
    OB_DB_NAME="******"  
    ## 數據庫連接串中的密碼
    OB_PWD="******"

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

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

# 7. 自動導入數據
python ./obmms/data/attraction_data_preprocessor.py

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

當瀏覽器里彈出那個簡潔的對話框時，

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

它能夠理解我問題里那種模糊的的描述，然后通過向量搜索找到語義上相似的景點，再結合地理位置和一些我預設的偏好進行過濾。

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

有了多模態知識庫和混合搜索，

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

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

到現在我還是有種想當然的荒謬的感覺，

作為程序員，這些環節我已經習慣性分開處理了，

但忘掉腦子憑直覺去想，

多模態的數據不就是應該放在一個數據庫里面嗎？

很合理吧！

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

再把數據庫打通，

我真的要說那句話了，

AI時代，

每個人都可以用五分鐘做個自己的應用，

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

@ 作者 / 還在琢磨知識庫的卡爾兒

最后，感謝你看到這里如果喜歡這篇文章，不妨順手給我們點贊｜在看｜轉發｜評論

如果想要第一時間收到推送，不妨給我個星標

如果你有更有趣的玩法，歡迎在評論區和我聊聊

更多的內容正在不斷填坑中……