真正好的搜尋有多難？ —— Index：專為AI 智能體設計的毫秒動態文件檢索系統 @opennote 創辦人Abhi 這篇完整技術分享，核心內容是他們內部自研的搜尋系統Index。這個系統不是給人用的搜尋引擎，而是專為AI 智能體在使用者個人知識庫上實現極快且極準的檢索而設計。 為什麼現有搜尋系統無法滿足智能體需求傳統搜尋引擎是為人類設計的。人會逐漸摸清系統的脾氣，學會換詞、補詞、跳過缺陷。而智能體完全沒有這種能力，它每次查詢都是從零開始，沒有記憶，也沒有對知識庫的「感覺」。更嚴重的是： · 智能體極易產生幻覺，只要給它的上下文稍微錯一點，整條回答就崩了。 · Opennote 的典型場景只有幾千份（而不是幾億份）文檔，容錯率幾乎為零，必須一次就把最正確的片段找出來。 · 產品面向一般消費者，不能像研究工具等幾秒鐘，端對端延遲必須穩定在幾百毫秒以內。 五大硬約束作者一再強調Index 必須同時滿足以下幾乎互相打架的要求： 1. 極低延遲：P99 < 300ms（全球任何地方都一樣快） 2. 高精度：在同一個概念出現在不同文件時，也要找出上下文最正確的那份 3. 多租戶與動態範圍：支援同時搜尋「僅我自己」「我和朋友分享」「整個社區」「加上公開網頁」等任意組合，效能不能下降 4. 全球低延遲：使用者和智能體可能在地球兩端 5. 資料永不靜止：使用者隨時編輯、分享、刪除、改變權限 關鍵技術選型（很多都反直覺） 1. 儲存與核心檢索引擎選擇了Postgres（pgvector + pg_trgm + tsvector），託管在PlanetScale，而不是主流的Pinecone、Weaviate、Qdrant、Chroma 等專用向量資料庫。 原因在於： · 元資料過濾極快，能在做向量計算前就把候選集砍到最小· 原生支援真正的混合檢索（全文+ 模糊匹配+ 語意） · 多租戶邊界、動態濾波、UPSERT/DELETE 都天然高效· 實測把P99 延遲從475ms 壓到209ms 2. 全球分散式運行時全部架構跑在Cloudflare 生態：Workers + Hyperdrive + R2 + Workers AI + Vectorize + KV。 好處是程式碼天然在全球數十個邊緣節點運行，在訪問資料庫時透過Hyperdrive 加速後感覺像本地一樣快。 3. 文檔處理管線（Ingestion） 採用完全無狀態的Worker + R2 物件儲存設計，嚴格適配Worker 128MB 記憶體限制。流程如下： 1. 遞歸分塊（對各種亂七八糟的文檔都足夠魯棒） 2. 用hash 精準對比新舊chunk，只對真正變動的部分重新計算 3. 只對變動的chunk 重新embedding（省錢又省時） 4. 為文件和重要段落產生摘要，給智能體額外的「這是整篇在講什麼」的上下文 5. UPSERT 新chunk 6. 刪除舊chunk，同時觸發快取失效 4. 搜尋流程（Search） 1. 收到智能體查詢後先做參數清洗與過濾條件拼接 2. 在Postgres 裡用元資料把搜尋空間預先砍到最小（租戶、來源、標籤、時間、明確排除等） 3. 在過濾後的集合上並行跑全文檢索和向量檢索 4. 把兩套分數歸一化到0-1，用一個叫alpha 的參數動態融合（0=純關鍵字，1=純語意） 5. 資料庫內完成去重、排序、取top-K 6. 可選再用Workers AI 做一次輕量級重排序，最後返回 5. 快取系統（最巧妙的部分） 普通快取會在文件更新後變髒，作者設計了三層機制徹底解決： · 精確緩存：相同query + 相同過濾條件直接命中KV · 語意快取：用Vectorize 存query 的embedding，相似問題也能命中· 反向索引失效：每個chunk 都會記錄自己出現在哪些查詢的快取裡，一旦chunk 失效，就主動把所有相關快取刪掉 這樣既極大降低資料庫壓力，又保證永遠不會回傳已過時的內容。 實測結果以標準資料集MSMARCO 10,000 個問答對+ BGE-M3 模型，和ChromaDB 做了嚴格比較。 在Recall@10、MRR@10、MAP@10、NDCG@10 四個指標上，Index 與Chroma 基本持平或略高，同時還額外具備混合檢索、多租戶隔離、動態過濾等能力，真實生產環境P99 延遲穩定在300ms 以內。 目前Index 已經正式承載Opennote 社群功能的全部檢索負載。 未來演進方向作者認為現在的Index 只是“檢索”，下一步要進化成“理解”： · 在chunk 之間加上時間、因果、演化關係· 引入重要性/流行度訊號· 繼續蒸餾更小、更快、更專用的embedding 模型· 讓智能體可以自訂多步驟檢索策略 最終目標是讓智能體真正擁有對使用者知識庫的“心智模型”，而不是每次都從零開始瞎猜。
