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

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

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

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

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

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

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

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

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

查詢邏輯就得好幾步，

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

性能方面我包它是拉的。

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

langchain-course-oceanbase.netlify.app

看了眼使用指南后，

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

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

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

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

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

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

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

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

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

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

我還是用旅游類比一下，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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上數(shù)據(jù)集解壓到項目目錄
mv ./archive.zip ./citydata.zip
unzip ./citydata.zip

# 3. 安裝依賴
poetry install

# 4. 設(shè)置環(huán)境變量
vim .env
    ## 數(shù)據(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ǎo)入數(shù)據(jù)
python ./obmms/data/attraction_data_preprocessor.py

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

當(dāng)瀏覽器里彈出那個簡潔的對話框時，

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

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

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

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

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

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

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

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

但忘掉腦子憑直覺去想，

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

很合理吧！

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

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

我真的要說那句話了，

AI時代，

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

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

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

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

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

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

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