你的 AI 分析師能守住秘密嗎？——專訪 Bridgewater 的 Aaron Linsky 與 turbopuffer 的 Nikhil Benesch

turbopuffer 技術長 Nikhil Benesch 認為，許可權感知的向量搜尋（permission-aware vector search）是卡住企業 AI 分析師的硬工程問題，而把前過濾（pre-filtering）與後過濾（post-filtering）整合成單一的「原生過濾」（native filtering）策略，正是讓這件事在大規模下可行的關鍵。本集大部分內容都在技術層面拆解這個問題：為什麼一旦檔案帶有逐使用者許可權，樸素的向量搜尋就會崩潰；turbopuffer 的物件儲存架構如何壓低成本；以及橋水（Bridgewater）內部那份一億份檔案的語料庫，為何逼得他們整個重做。標題裡的「守住秘密」只是引子，真正貫穿全場的主題是許可權問題。

橋水產品工程主管 Aaron Linsky 補上客戶端視角：橋水五十年來的研究流程、把「人」換成「機器」成為流程核心的轉變，以及他們的非結構化檔案庫 Vault。兩位講者合起來描述了一套真實的生產系統——4.5 億個向量、P90 延遲 120 毫秒——以及背後的設計取捨。讀者讀完應該能理解：為什麼過濾與向量索引必須一起設計，以及各種樸素做法分別在什麼規模門檻上失效。

許可權感知檢索讓樸素向量搜尋兩頭都行不通

Benesch 用一張圖框出核心問題：使用者向 LLM 提問，模型用事實佐證答案，而這些事實有些來自公開網路，有些來自私有檔案。公開網路沒有許可權維度——每份檔案對所有人都可見，所以不論提問者是誰，都能直接餵給分析師。內部檔案恰好相反。「每一封 email、每一份會議紀錄、每一份報告，可能都掛著完全不同的許可權組合，」他說，有的屬於不同群組，有的只屬於個人。Benesch 稱這是「資訊檢索領域的經典難題」，並表示 turbopuffer 從一開始就是為了拆解這個難題而設計。

節目接著走過兩種失敗策略，才來到可行的那一種。這兩種失敗都值得理解，因為它們界定了整個設計空間。

Benesch 對後過濾失效的舉例很具體：某使用者只能存取向量空間右下角區域的檔案，卻拿查詢點 Q 去搜尋。後過濾從 Q 向外螺旋擴散，把無許可權的結果一一丟棄，可能取到前 100 筆合格結果中的 40 筆就放棄了。「使用者會很不爽，因為他可能知道有一份檔案講的是栗色涼鞋，而他搜的是紅鞋，你卻沒幫他找出來，」他說。

原生過濾的關鍵：在叢集層級索引許可權

解法是同時動用向量索引與許可權索引。turbopuffer 的向量索引會自動把相似的向量分群——Benesch 展示的分群標籤是 5、0、1——而許可權索引則記錄哪些叢集至少含有一份該使用者可見的檔案。假設 Aaron 有權存取叢集 5 與叢集 2 的檔案，但叢集 3 與叢集 0 完全沒有，那麼這兩個叢集就直接剔除、完全不列入考慮。引擎接著搜尋最接近的合格叢集，並在叢集內循序掃描。

目前每個叢集約容納 200 份檔案。Benesch 說這個數字「是我們一直在調的引數」，未來應該會往上調，以最大化吞吐量。他公佈的成果是：在 4.5 億個向量上——Vault 的 1 億份檔案展開後約為 4 億個向量——turbopuffer 在所有名稱空間下都能達到 P90 延遲 120 毫秒的搜尋速度。

flowchart TD
    Q["帶許可權的使用者查詢"] --> V["向量索引將相似檔案分群"]
    Q --> P["許可權索引標記合格叢集"]
    V --> C["剔除不含合格檔案的叢集"]
    P --> C
    C --> S["搜尋最接近的合格叢集"]
    S --> L["叢集內循序掃描，每叢集約 200 份檔案"]
    L --> R["P90 延遲 120 毫秒回傳前段結果"]

開發者看到的介面刻意保持簡單。Benesch 展示了一段過濾表示式，直接對應組織的許可權模型——viewers contains one、groups contains any BC——並說複雜的查詢規劃都在底層處理掉了。他也坦白點出一項限制：巢狀群組（nested groups）很棘手，歡迎有這類問題的人直接找 turbopuffer 談，他說團隊有處理過的經驗。

物件儲存是 TB 級搜尋得以便宜的關鍵

Benesch 對 turbopuffer 架構的描述，就是效能論述背後的成本論述。這套引擎「完全建構在物件儲存之上」——直接寫入 S3、GCS 或 Azure Blob，看客戶用哪家超大規模雲端業者，因此享有「S3 經濟學」。資料預設靜靜躺在冷儲存，只有被查詢時才拉進 SSD 或記憶體。一旦某個名稱空間或區域變熱，查詢就快；沒被碰過的資料則以極低價格留在物件儲存上。

他把效益量化：這套架構讓 turbopuffer 能便宜地擴充套件到 TB 級資料，「同樣的資料量放在其他系統要花上千萬美元」，成本往往只有十分之一；資料變熱後，效能可與傳統磁碟式搜尋比肩。turbopuffer 支援關鍵字、正規表示式與向量搜尋，「對你怎麼搜資料真的沒什麼意見」——這場演講只聚焦向量搜尋，是為了把單一情境講深。

Benesch 用來論證「索引非做不可」的粗略估算，是全場最清楚的數字。保守假設每份檔案 1 KB——1,024 維、每維一個位元組的 embedding 就已經佔滿。以現代硬體最快約 20 GB/s 的記憶體頻寬計算，1 億份檔案要掃五秒。多數搜尋工作負載希望大約 100 毫秒內拿到結果。如果資料是冷的、放在 S3 而非記憶體，同樣的掃描要一分鐘以上。1 萬份檔案時，暴力掃描只要半毫秒，「turbopuffer 幾乎愛怎麼做都行，反正一定夠快」——但到了 1,000 萬或 1 億份，資料表示方式（data representation）就成了非做不可的事。

橋水 Vault：1 億份檔案、135 個授權來源

Linsky 對橋水研究流程的說明，解釋了這份語料庫為何存在、許可權又為何如此盤根錯節。五十年來，這家公司試圖理解市場與經濟的運作方式，把這份理解編碼成邏輯，並隨時間反覆壓力測試。他追溯這條技術血脈：從 1980 年寫在黃色便條紙上的 if-then 規則債券系統，到 Excel，到 Scala，再到今天的 Python。研究迴圈有五步：感知（看見外部世界正在發生什麼）、假設（為什麼可能是真的）、調查（驗證是否為真）、系統化並整合進交易系統，以及工業化（每天執行、據以交易）。Linsky 在橋水待了大約 20 年，他說這套以人為核心的迴圈跑了二十年，如今正把機器移到同一個迴圈的中心。

這需要兩套資料儲存。DeLorean 是累積數十年的雙時態總體時間序列資料庫。Vault 則是較新的非結構化儲存：約 1 億份檔案，完成索引、組織與許可權控管。它結合了 135 個外部來源——Linsky 說光是談判與授權這些來源，就「對法務和資料團隊都是天大的工程」——再加上內部文稿、會議錄音與內部報告。人類投資者和 AI 代理都會從 Vault 讀取，也會把新內容寫回去，所以它持續變好。每個外部來源都帶著未必對橋水所有人開放的許可權，而這正是當初拖垮第一版實作的異質性所在。

「我們一開始沒用 turbopuffer 就實作了這套，當時覺得運作得還不錯。但很快地，隨著我們往 Vault 裡加進越來越多檔案，它就徹底垮了。」——Aaron Linsky

Linsky 說他於是去找其他供應商，測試了 turbopuffer，找到解法。他勾勒的許可權模型刻意簡化：一個使用者有 ID、隸屬於群組 B 與 C，而檔案集的存取權可能透過群組授予，也可能直接授予個人。

隔離的範圍遠不止逐檔案許可權

Benesch 最後把視野拉大：許可權過濾「真的只是冰山一角」。turbopuffer 想打造的是他所謂的「隔離原生」（isolation-native）搜尋引擎，涵蓋名稱空間內的細粒度許可權、出於安全與法規遵循的區域資料鎖定、把資料留在客戶自家 VPC 內，以及加密——而且可能是由客戶的客戶、而非 turbopuffer 自己持有金鑰。他把許可權過濾定位成這套更大的隔離故事中的一塊，而非產品的全部。

對企業買家的策略解讀是：許可權感知檢索不是能事後加裝到通用向量資料庫上的功能。它要求索引結構本身就懂存取許可權，這也是為什麼叢集層級的許可權索引，比任何單一延遲數字都更重要。Benesch 主動邀請討論巢狀群組，等於暗示最難的組織情境——繼承式群組階層、間接成員身分——仍有部分是客製工程，而非已解決的預設功能。

本集留下的未解問題

有兩件事值得持續關注。第一，每叢集約 200 份檔案這個數字，Benesch 明說是持續調校的引數，預期會再往上加；這個數字一動，延遲與召回之間的平衡就跟著變，120 毫秒的 P90 只是當下配置的快照，不是固定屬性。第二，巢狀群組的限制，正是「把許可權寫成過濾條件」這套乾淨說法唯一破功的地方，而 Benesch 並沒有提出通用解法——只說 turbopuffer 處理過這類案例。對存取模型是深層群組階層、而非扁平群組成員資格的組織來說，這個缺口就是採用這套做法前該問的第一個問題。