文 / 阿里雲AI搜索產研團隊

在做搜索技術架構諮詢時，我們經常聽到一句話：“我也知道業務系統複雜，但不知道怎麼簡化架構部署?”

今天，我們想聊聊 “某知名互聯網泛娛樂視覺平台 A”（以下簡稱 A 公司）的搜索架構演進故事。他們的雲上遷移經歷，是無數正在為“技術棧碎片化”與"AI搜索架構改造"頭疼的企業的真實寫照。

第一階段：為了業務的“快”，他們建了三根煙囱

一年前，A 公司的技術架構負責人老李面臨着極大的壓力。隨着原先的檢索業務引入全量日誌審計的運維管理，再到接入大模型 RAG（檢索增強生成），他們的架構變成了典型的“拼湊型”：

通用搜索業務：素材中台、視頻/表情包關鍵詞檢索，涉及大規模用户、話題及活動信息。跑在開源ES集羣上。

日誌檢索業務：為了合規存儲海量 Access Log，採購了獨立的日誌服務。App行為日誌、服務端系統日誌，用於性能監控與運營決策。為了省錢又把部分老日誌導到了 對象存儲裏，查詢極其不便。

向量檢索業務：基於視覺特徵的相似圖片檢索、基於用户畫像的智能推薦（如相似濾鏡、模板推薦）。為了做 RAG 和猜你喜歡，又不得不單獨搭建了一套 開源Milvus。

老李的痛點非常具體：

“半夜燒錢”：A 公司的流量有明顯的潮汐效應。每天晚上 8 點到 12 點是日誌寫入洪峯，但凌晨 2 點到早上 8 點流量極低。為了抗住那 4 小時的峯值，他們必須按最高水位購買日誌資源。結果就是：每天有 16 個小時，昂貴的計算資源在空轉。突發流量導致的擴容壓力與存儲成本不成正比。

“膠水代碼”：在做 RAG 時，開發同學需要在代碼裏先查 Milvus 拿 ID，再回查 ES 拿文本。不僅代碼難維護，一旦出現數據不一致（比如文章刪了，向量還在），用户就會點進 404 頁面，投訴率飆升。

“三根煙囱”，多種搜索能力隔離分開，開發與運維成本極高，難以支持複雜的跨模態檢索。

“蝸行牛步”：全量同步耗時長，大數據量下的實時更新與索引重建效率低下。

第二階段：做減法，擁抱 All in ES

在與阿里雲AI搜索專家團隊深聊後，A 公司決定進行一次徹底技術“斷舍離”，將AI搜索所需的多種技術棧統一收斂到阿里雲 Elasticsearch 上。

1. 日誌場景：把“固定資產”變成“電費單” A 公司首先改造的是最燒錢的日誌系統。他們沒有繼續購買龐大的自建ES節點，而是接入了阿里雲 ES 的 高性能寫入托管服務Indexing Service 和 混合存儲服務OpenStore。

   變化前：為了抗峯值，常駐 20 台 8C32G 的機器。凌晨流量跌到谷底時，這 20 台機器依然在計費。

   變化後：徹底 Serverless 化。晚高峯流量來了，雲端自動擴容扛壓；凌晨流量沒了，計費幾乎歸零。存儲方面，數據自動沉降到 OpenStore（對象存儲介質），成本直接對其歸檔存儲。

   老李的反饋：“以前是養車，不管開不開都得付折舊和保險；現在是打車，跑多少付多少。單這一項，日誌賬單降了 60%。”

2. 向量場景：刪掉膠水代碼，迴歸原生 解決了日誌，A 公司開始動刀向量搜索。他們利用阿里雲 ES 內核級強化的混合向量引擎，替代了獨立的向量庫。

變化前：應用 -> 查向量庫 -> 拿 ID -> 查 ES -> 應用層排序。延遲 200ms+。

變化後：應用 -> 阿里雲 ES (混合檢索 API) -> 返回結果。

由於阿里雲 ES 全自研雲原生引擎FalconSeek在內核層引入了 SIMD 指令集加速和 HNSW 算法優化，在千萬級數據量下，性能完全滿足 A 公司的需求。更重要的是，他們終於可以用一個 DSL 語句同時搞定“語義搜索 + 關鍵詞匹配 + 邊時間過濾邊檢索”。

老李的反饋：“架構圖上少了一個框，代碼裏少了幾百行膠水邏輯，開發同學終於不用在兩個庫之間修數據一致性的 Bug 了。”

為什麼選擇 All in ES？因為“統一”本身就是生產力

A 公司的故事並非孤例。當他們將日誌、搜索、向量收斂到阿里雲 Elasticsearch 這一套技術棧上時，發生的不僅僅是成本的降低：

系統架構優化：

1. 極致的計算資源彈性（Serverless）： 對於日誌這種具有明顯“峯谷效應”的數據，傳統的預置機器模式註定是浪費。阿里雲 ES 的 Indexing Service 讓算力像水一樣流動，“用時付費，不用免費”，這才是雲原生該有的樣子。
2. 運維標準的統一： 現在，A 公司的運維團隊只需要精通 ES 這一門手藝。無論是查業務慢查詢，還是做日誌分析，亦或是管理向量索引，都在同一個控制枱，遵循同一套安全標準（RBAC/VPC），看同一套監控大盤。
3. 數據價值的閉環： 日誌數據進來，清洗後直接可以用於業務分析；業務數據進來，直接生成向量用於推薦。數據在同一個生態內流轉，沒有中間商賺差價。

日誌檢索增強：

在A公司中廣泛使用的日誌檢索，採用阿里雲Elasticsearch企業版以下方面進行全面優化。

極致寫入優化 - Indexing service讀寫分離，綜合寫入成本降低60%

• 高性能：專業級寫入優化，多自研特性加持(物理複製,定向路由等)
• 高穩定：多集羣冗餘備份，秒級切換
• 低成本：寫入資源，存儲大小及介質等優化
• 彈性擴展：寫入資源由雲端後台調配和管理，以應對流量波動
• 免運維：無須關注寫入資源和寫入壓力, 極大降低集羣運維成本

存算分離優化 - OpenStore混合存儲架構，存儲成本降低60%以上

• 採用存算分離架構，降低數據冗餘存儲
• 採用對象存儲降低存儲成本
• 多級緩存及併發查詢保證查詢性能

專業級查詢優化:

• 針對日誌場景的典型查詢case進行深度優化，提高用户查詢性能， 如bkd查詢優化等

• 貼近用户業務，針對用户使用過程中的查詢問題進行定製優化，如在支持A客户中遇到的cardinality開源缺陷導致的查詢性能問題等。

向量索引調優：

向量索引在AI搜索場景中越來越重要，A公司為提高性能，降低整體成本，充分採用了阿里雲ES的若干優化手段。成功的將成本降低一倍以上，查詢性能提升數倍以上：

• 自研FalconSeek雲原生索引應用：阿里雲最新發布全自研雲原生C++內核引擎, 對文本檢索與向量檢索性能提升，向量性能進一步提升40%以上。 使用FalconSeek的Filter-Knn特性，性能提升最多4倍。
• 執行Force Merge：存量數據定期執行Force Merge，性能提升5倍以上。
• 原文排除向量字段：在寫入的source中排除向量字段，存儲空間節約1倍以上。
• 混合搜索： 採用RRF（Reciprocal Rank Fusion） 算法或自定義線性權重，將向量相似度得分與BM25文本得分進行加權融合，以兼顧檢索的精確性與泛化性。

成本效能對比與選型建議

根據A公司遷移阿里雲的測算分析，企業在構建多場景AI搜索時，可重點關注以下成本指標：

總結：One Stack一站式搜索, 簡單架構是最好的架構

回看 A 公司的搜索技術演進之路，其實就是一條從“做加法”到“做減法”的路。

對於架構師：你的系統拓撲圖變清晰了，數據鏈路變短了，系統穩定性變強了。

對於運維：只要精通 ES 一門產品技術手藝，就能搞定全公司的核心數據檢索全鏈路。

對於老闆：TCO（總擁有成本）顯著下降，同時獲得了企業級的安全合規保障。

不要讓複雜的工具鏈拖累你的業務創新的速度。

從今天開始，參考 A 公司的路徑，重新審視你的架構。嘗試阿里雲 Elasticsearch企業版，體驗“All in ES”帶來的極簡與高效。