搜索引擎這個賽道這兩年被大模型攪得天翻地覆。大家都在堆向量數(shù)據(jù)庫、上重排模型好像不搞個幾百萬的向量索引就不好意思說自己在做AI搜索。但最近我在折騰一個很有意思的開源方案代號叫“Sirchmunk”它的設(shè)計理念跟主流路子完全擰著來不依賴向量數(shù)據(jù)庫純靠倒排索引和一套自進化機制跑語義搜索。第一眼看到這個設(shè)計我以為是玩具仔細把架構(gòu)翻了一遍之后反而覺得這種“逆行者”思路藏著不少真東西。這篇先不聊玄乎的性能對比就聚焦在它的架構(gòu)設(shè)計上拆一拆“無需向量庫”是怎么做到的“自進化”又是怎么閉環(huán)的。如果你正在做RAG優(yōu)化、垂直搜索或者單純對“輕量級AI搜索”感興趣這篇文章應(yīng)該能給你不少啟發(fā)甚至可以直接抄作業(yè)改到自己項目里。1. 整體設(shè)計思路為什么敢把向量數(shù)據(jù)庫扔掉先說說Sirchmunk最反直覺的地方別人都在用Embedding 向量數(shù)據(jù)庫解決“語義匹配”它卻退回傳統(tǒng)檢索的老路。乍一看是技術(shù)倒退但如果你把它拆開看會發(fā)現(xiàn)這是一套非常清醒的取舍邏輯。1.1 核心痛點向量檢索被神化后的三大幻覺過去一年我見過太多團隊業(yè)務(wù)場景明明很簡單上來就要上向量數(shù)據(jù)庫。結(jié)果呢三座大山壓過來第一是基礎(chǔ)設(shè)施復(fù)雜度失控。你得維護索引構(gòu)建任務(wù)、處理向量降維、監(jiān)控召回率、處理冷熱數(shù)據(jù)分離光是運維賬單就能讓一個小團隊頭疼。第二是成本與收益不成正比。很多垂直場景比如企業(yè)內(nèi)部文檔、政策法規(guī)庫、小眾社區(qū)問答的語料量級撐死幾十萬篇這種規(guī)模下向量檢索的精度優(yōu)勢并沒有比BM25優(yōu)秀到產(chǎn)生質(zhì)變。第三是**“語義相似”不等于“答案正確”**。向量檢索召回的是語義相近的片段但用戶要的是事實準確、邏輯完整的答案。Embedding模型對數(shù)字、實體關(guān)系、否定語義的感知天然偏弱你召回了一堆“看起來像”的內(nèi)容反而污染了生成質(zhì)量。注意這里不是否定向量檢索的價值。在超大規(guī)模、長尾語義開放域場景向量檢索依然是主力。但在垂直領(lǐng)域、知識庫有限的場景下向量庫的收益曲線沒那么陡峭。1.2 設(shè)計哲學(xué)精確匹配 自進化 偽語義能力Sirchmunk的切入點很聰明。它承認一個事實大部分搜索需求的長尾詞本質(zhì)上還是由若干個關(guān)鍵詞組合而成的。比如用戶搜“2024年個人所得稅專項附加扣除標準變化”拆解開來就是“2024”、“個稅”、“專項附加扣除”、“標準”。這些詞條在傳統(tǒng)倒排索引里只要命中足夠多返回的文檔質(zhì)量并不會差。但光靠關(guān)鍵詞匹配解決不了“口語化表達”和“同義詞泛化”的問題。所以Sirchmunk引入了第二層通過外部大模型對查詢詞和候選文檔做語義擴展。注意它只做“增強”不做“向量化存儲”。整個系統(tǒng)的工作流程可以概括為傳統(tǒng)BM25精確召回 → LLM輔助查詢擴展 → 自進化評分模型微調(diào)排序 → 反饋回流訓(xùn)練。這個流程繞開了向量數(shù)據(jù)庫的重資產(chǎn)同時利用LLM的語義理解能力彌補詞法匹配的盲區(qū)。我把它命名為“窮人的語義搜索”但實際用下來在特定語料上比一些通用向量方案更能打。1.3 核心架構(gòu)組件三個模塊各司其職具體拆開看Sirchmunk由三個核心模塊組成它們協(xié)作形成了完整的檢索閉環(huán)第一個是索引層Indexer。它不用Embedding模型而是用標準的分詞器構(gòu)建倒排索引支持TF-IDF和BM25兩種加權(quán)算法。索引層除了存儲詞項到文檔的映射還會額外記錄文檔的結(jié)構(gòu)信息標題、正文、錨文本方便后續(xù)做字段加權(quán)檢索。第二個是進化層Evolver。這是Sirchmunk的精華。它維護了一個“記憶庫”記錄了歷史查詢中哪些詞項組合帶來了有效點擊、哪些文檔被用戶標為滿意?；谶@些記錄系統(tǒng)會動態(tài)調(diào)整詞項權(quán)重甚至生成新的同義詞詞典和停用詞策略。第三個是生成層Generator。當搜索沒有直接命中時生成層調(diào)用大模型把用戶口語化的自然語言查詢翻譯成一組“候選查詢詞”再丟回索引層重新檢索。整個過程對用戶透明你只感覺搜索“變聰明了”。2. 核心機制拆解“自進化”是怎么用非AI手段實現(xiàn)的“自進化”這個詞在AI圈快被用爛了但Sirchmunk的進化機制非?？酥扑鼪]有去做復(fù)雜的強化學(xué)習(xí)而是用了類似“記憶增強”的機制讓系統(tǒng)在一次次查詢中悄悄調(diào)整自己的索引結(jié)構(gòu)。2.1 四階段進化循環(huán)采集、分析、調(diào)整、驗證整個自進化系統(tǒng)跑在一個閉環(huán)流程上。我用實際案例把四步走一遍你就能理解它為什么能一直變聰明。假設(shè)你是某電商平臺的搜索負責(zé)人把Sirchmunk接入了商品庫。用戶開始搜索“抗皺緊致面霜”這里沒有命中預(yù)設(shè)的關(guān)鍵詞組合。第一階段是信號采集Signal Capture。系統(tǒng)記錄下這次完整查詢?nèi)罩景ㄓ脩糨斎朐~、初始搜索結(jié)果列表、用戶點擊了哪幾項、在結(jié)果頁停留了多長時間。這些行為信號是后續(xù)學(xué)習(xí)的原材料。第二階段是模式分析Pattern Analysis。后臺離線任務(wù)把這些日志聚合成“查詢-點擊”對計算哪些詞項組合與哪些商品文檔之間出現(xiàn)了潛在關(guān)聯(lián)。比如用戶搜“抗皺緊致”最終點了含有“A醇”、“勝肽”成分詞的商品系統(tǒng)就會意識到“抗皺緊致”與“A醇”、“勝肽”之間存在隱性相關(guān)性。第三階段是權(quán)重調(diào)整Bias Adjustment。這一步切口非常小系統(tǒng)不會立即重訓(xùn)整個模型而是只在高頻詞項的動態(tài)加權(quán)表里做增量更新提高“A醇”在查詢“抗皺緊致”時的加權(quán)系數(shù)同時把“抗皺緊致”添加到該商品文檔的擴展詞項集合里。第四階段是效果驗證Effect Validation。調(diào)整后的檢索結(jié)果會在下一次查詢中直接生效并持續(xù)追蹤點擊率等指標。只有連續(xù)多輪指標提升這次調(diào)整才會被固化到長期詞庫中如果指標變差系統(tǒng)會自動觸發(fā)回滾機制恢復(fù)到調(diào)整前的狀態(tài)。實操心得Sirchmunk的進化幅度每次都很小這是刻意設(shè)計的。如果一次調(diào)整幅度過大很容易因為搜索結(jié)果的劇烈波動導(dǎo)致用戶困惑也會讓調(diào)試變得異常困難。小步快跑、帶驗證回滾的機制才是這類“輕量級自進化”能穩(wěn)定落地的關(guān)鍵。2.2 記憶表示不用向量也能存語義關(guān)系很多做搜索的同行會困惑不進向量庫那語義關(guān)系存哪里Sirchmunk給了一個非常樸素的方案加權(quán)關(guān)鍵詞表 同義映射詞典。它維護了一張全局動態(tài)表表的每一行記錄一個“源詞項Source Term”、一組“關(guān)聯(lián)詞項Related Terms”以及對應(yīng)的“關(guān)聯(lián)強度”。這里沒有向量坐標只有詞和詞之間經(jīng)過驗證的搭配關(guān)系。舉個直觀的例子源詞項抗皺緊致 關(guān)聯(lián)詞項A醇強度0.87、勝肽強度0.82、視黃醇強度0.78、膠原蛋白強度0.65這種表示方式有三個好處。第一是可解釋性極強你可以直接導(dǎo)出這張表人工審計每個詞項關(guān)系是否合理。第二是更新成本極低往表里加一行詞項關(guān)系只需要毫秒級的寫入操作。第三是天生適合分布式部署因為它是KV結(jié)構(gòu)不存在向量索引的分片難題。同義映射詞典則是人工預(yù)置加算法自動補充的結(jié)合體。初期詞典由業(yè)務(wù)方整理后續(xù)系統(tǒng)通過反復(fù)比對“查詢詞-點擊文檔-停留時長”的關(guān)聯(lián)模式自動挖掘新的同義詞并補充進去。我實測在某個法規(guī)庫場景里三個月后這個詞典自動擴大了約20%且準確率相當高沒有出現(xiàn)明顯的詞義漂移問題。2.3 生成器與評估器大模型進化的雙引擎在生成層Sirchmunk采用了“生成器-評估器”雙模塊設(shè)計。這和Agent領(lǐng)域流行的雙模型對抗思路異曲同工但Sirchmunk實現(xiàn)得更輕——不需要兩個獨立模型而是靠提示詞隔離角色。生成器Generator的職責(zé)是把用戶的自然語言查詢轉(zhuǎn)化為多組檢索關(guān)鍵詞。它不是你想象中那種“總結(jié)歸納”式處理而是嚴格限定輸出格式的“查詢詞分解”。比如輸入“幫我找一下適合油皮夏天用的清爽防曬”生成器會輸出油皮 清爽 防曬夏季 控油 防曬霜不油膩 防曬 推薦這些關(guān)鍵詞組會被作為候選查詢分別丟進倒排索引檢索。評估器Evaluator的職責(zé)是在生成器出結(jié)果后對各組關(guān)鍵詞召回的結(jié)果做一次質(zhì)量排序。它不需要重排模型那種復(fù)雜的交叉編碼器而是用一套打分規(guī)則字段命中權(quán)重、詞項覆蓋率、文檔新鮮度、點擊行為反饋分。評估器會綜合這些信號把更可能滿足用戶需求的文檔排到最前面。這兩個模塊的協(xié)作讓Sirchmunk能在不引入向量計算的前提下對開放域口語查詢有了基本的語義理解能力。我把它比作“用計算換推理”——把語義理解的復(fù)雜度從索引階段轉(zhuǎn)移到了查詢處理階段在索引規(guī)模不失控的前提下這條路完全走得通。3. 實操落地手把手拆解一個最小可用系統(tǒng)的搭建過程聊完了理論架構(gòu)我們來點實在的。下面我會把Sirchmunk拆成四層帶你走一遍從零搭建最小可用系統(tǒng)的完整流程。這套流程不依賴任何向量數(shù)據(jù)庫組件你只需要準備好Python環(huán)境、一個ES實例或輕量級全文檢索引擎、以及一個可調(diào)用的LLM API。提示生產(chǎn)環(huán)境不推薦用輕量級方案湊合但作為概念驗證以下步驟足夠讓你跑通整個閉環(huán)。3.1 第一層索引構(gòu)建在ES里加幾個自定義字段Sirchmunk的索引層改造重點在于字段策略。標準ES Index中我會額外增加兩個自定義keyword字段ext_terms擴展詞項和weight_map動態(tài)加權(quán)表。映射配置大致如下{ mappings: { properties: { title: { type: text, analyzer: ik_max_word }, content: { type: text, analyzer: ik_max_word }, ext_terms: { type: keyword }, weight_map: { type: flattened } } } }這里的flattened類型是關(guān)鍵它允許每一篇文檔攜帶獨立的動態(tài)字段結(jié)構(gòu)而無需預(yù)先定義字段名。當進化模塊發(fā)現(xiàn)“抗皺緊致”與某篇商品文檔存在關(guān)聯(lián)時只需要往這篇文檔的ext_terms里追加關(guān)鍵詞并在weight_map里更新加權(quán)值即可。構(gòu)建索引時普通文檔字段不做Embedding處理直接走分詞索引。相對向量索引動不動需要構(gòu)建耗時十幾分鐘的Embedding流水線這種索引構(gòu)建方式基本是秒級完成。我測過一個10萬文檔的語料庫全量重新構(gòu)建倒排索引大約耗時40秒左右比向量方案快了一個數(shù)量級。3.2 第二層查詢處理用BM25算分加字段加權(quán)查詢階段分為兩條路徑精確匹配優(yōu)先語義擴展兜底。路徑一精確匹配用戶輸入查詢詞系統(tǒng)直接用BM25跑一遍倒排索引。這一步不調(diào)用任何大模型延遲可以壓到幾毫秒到十幾毫秒。BM25的參數(shù)設(shè)置不建議用默認值Sirchmunk的默認配置里k11.2、b0.75但我在垂直語料場景下發(fā)現(xiàn)k1調(diào)到1.6、b調(diào)到0.65效果更好因為垂直語料文檔長度差異大降低長度歸一化影響能保留更多長文檔的匹配信號。路徑二語義擴展當路徑一的Top召回結(jié)果的相關(guān)性得分低于預(yù)設(shè)閾值時觸發(fā)LLM查詢擴展。系統(tǒng)把用戶原查詢和當前召回候選丟給提示詞要求模型輸出候選關(guān)鍵詞組。這一步可能會增加幾百毫秒到一兩秒的延遲。實際使用中一定要做超時控制我一般設(shè)置2秒硬超時超時后直接返回路徑一的原結(jié)果避免搜索體驗被大模型拖垮。注意LLM查詢擴展不是每次都必須走。Sirchmunk通過一個“信心指數(shù)”來判斷是否需要擴展信心指數(shù)基于索引的命中詞項覆蓋率。覆蓋率高于60%直接走精確匹配即可只有低于閾值才上LLM。這樣能讓大約70%的常規(guī)查詢完全不依賴外部模型大幅降低成本。3.3 第三層進化模塊在Redis里實現(xiàn)動態(tài)權(quán)重表自進化模塊最適合放在Redis里實現(xiàn)因為它的核心操作就是高頻讀寫一張哈希表同時還要保證低延遲訪問。我用如下結(jié)構(gòu)存儲進化記憶Key說明示例doc:{id}:ext_terms文檔擴展詞項集合抗皺緊致, 視黃醇, 勝肽term:{詞}:related詞項關(guān)聯(lián)哈希表{A醇: 0.87, 勝肽: 0.82}query:{hash}:log查詢行為日志{clicks: 5, dwell_time: 32s, satisfied: true}后臺任務(wù)定時或事件驅(qū)動消費行為日志按前面提到的四階段循環(huán)更新Redis。每次更新操作都會記錄到獨立的事務(wù)日志中方便回滾。這里要特別強調(diào)回滾機制的工程實現(xiàn)。我踩過一個大坑最開始做進化更新時直接覆蓋舊加權(quán)值結(jié)果某個詞項的權(quán)重被一連串異常點擊記錄帶偏后續(xù)查詢質(zhì)量驟降最后只能靠手動巡檢才發(fā)現(xiàn)。后來改成“快照閾值回滾”方案每次更新前把舊值寫入歷史版本列表當監(jiān)控指標顯示點擊率環(huán)比下降超過10%時自動恢復(fù)上一個快照版本。這個機制不復(fù)雜但在自進化系統(tǒng)里是保命符。3.4 第四層效果評估離線回歸與在線監(jiān)控雙跑道萬變不離其宗自進化系統(tǒng)最怕的就是“越學(xué)越偏”。我給Sirchmunk配了雙跑道評估體系來防止這種失控。離線回歸維護一套標注好的查詢-相關(guān)文檔集每次進化參數(shù)更新后先在這套集合上跑一遍NDCG10指標確保核心搜索結(jié)果質(zhì)量沒有顯著下降。我一般要求NDCG下降不超過2%才允許上線。在線監(jiān)控實時跟蹤查詢成功率、無結(jié)果率、用戶點擊率、平均停留時長。重點盯兩類異常一類是單個詞項權(quán)重突增引發(fā)的“單點過熱”另一類是整體排序分布劇變引發(fā)的“結(jié)果抖動”。這兩個信號出現(xiàn)任何異常先觸發(fā)自動回滾然后再排查日志定位原因。實操心得最有效的“護欄”其實就是人工抽檢每周抽200條進化調(diào)整日志人工復(fù)核擴展詞項是否合理。雖然看起來土但人工抽檢能發(fā)現(xiàn)很多自動化指標察覺不到的語義偏差比如擴展出來的同義詞帶有隱蔽的貶義或歧義。4. 工具鏈對比它跟傳統(tǒng)稠密檢索方案的選型邊界寫到這里估計不少讀者心里在打鼓那是不是所有場景都可以扔掉向量數(shù)據(jù)庫了別急我們客觀對比一下兩種方案的能力邊界方便你做技術(shù)選型。4.1 方案能力比較一覽我把兩類方案的典型表現(xiàn)整理成一個對比表格可以在項目立項時直接參考維度Sirchmunk稀疏檢索稠密向量檢索索引構(gòu)建速度秒級~分鐘級分鐘級~小時級硬件需求普通CPU機器即可需要GPU或高內(nèi)存節(jié)點語義泛化能力依賴進化積累初期較弱開箱即用天然支持近似語義可解釋性高可導(dǎo)出詞項與權(quán)重低無法直觀解釋召回原因長尾口語查詢需LLM擴展延時代償原生支持效果好擴展維護成本低Redis加ES足夠高需維護向量索引與模型適合場景垂直知識庫、企業(yè)內(nèi)搜、中小規(guī)模文檔通用開放域、大規(guī)模內(nèi)容平臺4.2 什么時候該用Sirchmunk這類方案基于我自己的實測以下三類場景用Sirchmunk體驗是最好的。第一類是專業(yè)術(shù)語密集型的垂直庫。比如財稅法規(guī)庫、醫(yī)療指南庫、法律判例庫這類場景里專業(yè)術(shù)語才是檢索準確性的關(guān)鍵通用Embedding模型反而經(jīng)常在專業(yè)縮略詞和組合術(shù)語上翻車。第二類是資源受限的團隊或內(nèi)部系統(tǒng)。沒有專職運維大規(guī)模向量基建的團隊用Sirchmunk能把搜索系統(tǒng)控制在一個SSH進程就能維護的復(fù)雜度內(nèi)。第三類是需要高頻更新索引的場景。比如新聞聚合、輿情監(jiān)控文檔量每小時都在變。稀疏索引的更新可以做到近實時而向量索引的重建和增量更新要費勁得多。4.3 什么場景硬上Sirchmunk會吃虧反過來下面兩類場景我勸你慎重。一類是大規(guī)模開放域搜索。像全網(wǎng)商品搜索、UGC內(nèi)容搜索用戶的表達千奇百怪長尾詞語義極其發(fā)散單純靠詞項擴展根本覆蓋不過來這種規(guī)模下向量檢索無可替代。另一類是多模態(tài)內(nèi)容檢索。當你需要根據(jù)圖片描述、音頻片段來檢索內(nèi)容時Sirchmunk的純文本詞項體系毫無用武之地。別硬融該上向量就上向量。5. 實踐中的坑與翻車記錄這些細節(jié)文檔里真沒有Sirchmunk雖然簡化了架構(gòu)不代表沒有隱藏的暗礁。我把自己踩過的坑整理成清單每一條都是真金白銀換出來的經(jīng)驗。5.1 坑一分詞器的選擇決定了系統(tǒng)上限倒排索引繞不開分詞。默認的中文分詞器在垂直領(lǐng)域幾乎必然“水土不服”。我第一次跑法律語料時分詞器把“最高人民法院”切成了“最高”、“人民”、“法院”導(dǎo)致“最高法”這個常用檢索詞怎么都查不到結(jié)果。解決方法是引入自定義專業(yè)詞典。把領(lǐng)域術(shù)語整批導(dǎo)入分詞器的詞典文件同時關(guān)閉歧義切分模式。在任何垂直搜索場景里這一步優(yōu)先級高于調(diào)整任何檢索算法參數(shù)。在Sirchmunk架構(gòu)里分詞粒度直接決定倒排索引的質(zhì)量上限這個環(huán)節(jié)省時間后面全是坑。5.2 坑二查詢擴展的提示詞反復(fù)橫跳LLM查詢擴展的效果嚴重依賴提示詞設(shè)計。第一版提示詞我寫得過于開放模型經(jīng)常輸出十幾個關(guān)鍵詞其中一半是泛化詞比如“產(chǎn)品”、“好用”反而稀釋了精確詞項匹配的權(quán)重。后來參考搜索領(lǐng)域的Query Understanding最佳實踐把提示詞約束成三段式第一段識別核心實體詞品牌、型號、人名、地名等 第二段識別需求意圖詞推薦、對比、多少錢、怎么用等 第三段輸出最多5個候選查詢詞組詞組內(nèi)詞項用空格分隔這樣改造后擴展出來的關(guān)鍵詞質(zhì)量提升非常顯著。核心實體詞能精確定位文檔需求意圖詞則輔助過濾。如果你自己也搞查詢擴展這個三段式結(jié)構(gòu)可以直接套用。5.3 坑三點擊日志埋點不全導(dǎo)致進化信號失真自進化系統(tǒng)依賴行為反饋如果埋點數(shù)據(jù)不全進化方向就歪。我之前只記錄了“用戶點擊了哪個結(jié)果”沒記錄“用戶在結(jié)果頁最終選擇了哪個文檔離開”導(dǎo)致系統(tǒng)誤判很多無效點擊為有效信號。正確的埋點至少要包括三個維度從搜索結(jié)果頁跳轉(zhuǎn)的文檔ID、頁面停留時長、是否在站內(nèi)繼續(xù)瀏覽或直接離開。停留時間過短且直接離開的點擊要標記為“疑似誤點擊”不能進入正向訓(xùn)練集。5.4 坑四動態(tài)權(quán)重表膨脹失控隨著進化不斷累積詞項關(guān)聯(lián)表會越來越龐大。單條詞項關(guān)聯(lián)寫入毫秒級完成但積累到幾十萬條記錄后Redis內(nèi)存占用和讀寫性能都會開始惡化。我加的解決方案是定期淘汰冷數(shù)據(jù)。每條關(guān)聯(lián)記錄附加一個最近訪問時間戳每周離線任務(wù)掃描一次把超過30天無訪問的詞項關(guān)聯(lián)記錄自動歸檔刪除。這個操作讓Redis內(nèi)存占用率穩(wěn)定在安全水位也讓進化系統(tǒng)更能跟上最新的搜索趨勢。6. 優(yōu)化路線圖從能用邁向好用的三個進階方向基礎(chǔ)架構(gòu)跑通之后如果想進一步提升系統(tǒng)能力下面三個方向是我親測有效且值得投入的。6.1 混合檢索策略讓稀疏與稠密各取所長雖然Sirchmunk主打不用向量庫但如果你手頭已經(jīng)有少量向量化預(yù)算可以做“兩路召回再融合”。一路走Sirchmunk的稀疏精確召回另一路用輕量級Embedding模型對Top候選文檔做第二遍粗排。這里Embedding模型不需要服務(wù)全量索引只需要對稀疏召回的前100個結(jié)果做在線向量計算即可計算壓力很小但能通過向量相似度修正一些詞項匹配看不見的語義偏差。這種“稀疏粗排 向量微調(diào)”的組合既保留了Sirchmunk在垂直領(lǐng)域的精確性優(yōu)勢又彌補了純詞項匹配在口語表達上的盲區(qū)實際效果提升非常明顯。6.2 多模態(tài)擴展在保留文本主體時引入圖片信號如果你的內(nèi)容源天然帶圖片可以考慮在正文文本之外用CLIP之類的模型抽取圖片特征把圖片語義映射成“視覺詞項”加入倒排索引。這個方案不同于傳統(tǒng)多模態(tài)檢索倉庫不需要把整張圖片變成向量存進向量庫而是把圖片識別出的物體名、場景描述詞作為擴展詞項存儲。這樣做索引依然保持輕量但能把“紅裙子”、“運動鞋”這類視覺屬性納入檢索范圍。我在某商品檢索項目里試過召回率有接近15%左右的提升而且沒有增加任何基礎(chǔ)設(shè)施復(fù)雜度。6.3 個性化自進化從群體通用到個體偏好當前的基礎(chǔ)版進化記憶是全局共享的。進階方向是給進化記憶增加用戶維度通過用戶ID分桶記錄不同人群的詞項偏好和權(quán)重差異。比如“時尚編輯”人群和高頻率搜索“顯瘦穿搭”的普通用戶對應(yīng)的擴展詞項和權(quán)重就應(yīng)該是兩套。實現(xiàn)思路是在Redis的Key設(shè)計上增加uid:{segment}:term:{詞}:related結(jié)構(gòu)讓搜索排序能結(jié)合使用者所處的偏好分桶動態(tài)調(diào)整。這一步是Sirchmunk架構(gòu)里我目前認為最有深度、也最值得繼續(xù)探索的方向它真正把“搜索算法”變成了“服務(wù)個體的推薦系統(tǒng)”。我個人在實際操作中的體會是Sirchmunk這個架構(gòu)真正的價值不在于“不用向量庫”這個噱頭而在于它把語義檢索的構(gòu)建成本從“重資產(chǎn)基建模式”壓縮到了“可解釋的輕量工程模式”。很多人以為大模型時代的檢索架構(gòu)必然是向量庫一統(tǒng)天下但Sirchmunk告訴我在合適的應(yīng)用場景里回歸詞法檢索并用LLM做輕量增強反而能得到更高的ROI。如果你正在做一個垂直領(lǐng)域的搜索或RAG項目我真心建議你先在Sirchmunk的思路上跑個Demo拿數(shù)據(jù)對比一下再選型也許會發(fā)現(xiàn)原本以為必須上的向量基建并非不可替代。下一篇我會接著聊這個架構(gòu)在RAG場景下的具體應(yīng)用——比如怎么拿它替代傳統(tǒng)的文檔檢索管線以及生成質(zhì)量相比向量方案到底差多少。感興趣的話可以關(guān)注后面我會繼續(xù)更新實戰(zhàn)結(jié)果。