News – 香港編程學會

壓縮是唯一需要花錢應用的上下文技術，因此也是最需要用算術來合理化的技術。通常有兩種更便宜的方法勝過它，而知道何時它們不適用才是真正的技巧。

先談免費的勝利

在任何基於模型的技術之前，先移除那些不帶資訊的 tokens。這看起來不華麗、是無損的，而且在真實提示詞上通常能省下 30–60%：

去除標記。 提示詞中抓取的 HTML 大多是屬性、導航和腳本標籤。請提取純文字。
壓縮結構化資料。 美化過的 JSON 會為每個空格付費。對於表格資料，CSV 或每欄一個緊湊鍵值的形式，遠比在每一列重複鍵值的物件陣列便宜得多。
去除重複。 使用重疊區塊的檢索會傳回幾乎相同的段落。進行雜湊並丟棄。
丟棄無法被讀取的內容。 Base64 資料塊、長 ID、雜湊、壓縮過的 bundle。它們無法被 tokenizer 進一步壓縮，對模型也沒有用處。
修剪工具描述。 JSON Schema 描述中的每個字都會在迴圈的每次呼叫中被計費。

四種需要成本的類型

類型	描述
抽取式選取	為句子或段落根據與查詢的相關性進行評分，並保留最相關的。交叉編碼器 reranker 是標準工具。成本低，而且輸出是逐字的原始文字，這在答案必須可被引用時非常重要。
抽象式摘要	要求模型將上下文改寫得更短。壓縮率最高，風險也最高：摘要會遺漏具體數字、限定詞和否定詞，而這些常常是最終答案的關鍵。
token 剪枝	使用小型語言模型的 perplexity 作為訊號，刪除個別低資訊量的 token。這方面的已發表研究來自微軟研究院的 LLMLingua 和 LongLLMLingua（Jiang et al., EMNLP 2023 及其後續），在他們的評估任務上報告了高達約 20 倍的壓縮率，且性能損失有限。輸出不是人類可讀的，這對模型來說沒問題，但對記錄來說很麻煩。
改用檢索	根本不是壓縮 — 不要把它放進提示詞。幾乎總是最便宜的選項，也是考慮其他方法前要先排除的。

壓縮必須能回收成本

每種基於模型的技術都會花費 tokens 來節省 tokens。以下是算術，以您應該替換的示意費率為例：

original context T  = 20,000 tok      target model input   $3.00 / M
compressed T'       =  4,000 tok      compressor in/out    $0.15 / $0.60 per M

saving per use    (20,000 - 4,000) / 1e6 * $3.00       = $0.0480
compression cost  20,000/1e6*$0.15 + 4,000/1e6*$0.60   = $0.0054

net per use, if the compressed artefact is reused      = +$0.0426
net on a single use (compress then immediately send)   = +$0.0426 as well

BUT compare against caching the same 20,000 tokens:
  cache read at a 0.1x multiplier: 20,000/1e6 * $0.30  = $0.0060
  compressed prompt, uncompressed rate: 4,000/1e6*$3   = $0.0120

Enter fullscreen mode

Exit fullscreen mode

仔細閱讀最後兩行，因為它們才是真正重要的發現。當上下文是穩定的時，快取既比壓縮便宜，又是無損的 — 沒有理由去壓縮靜態的系統提示詞。壓縮只有在每次請求的上下文都不同、其大小大到無法經濟地快取，或是必須跨沒有共享快取的模型重複使用時，才有其價值。

因此完整的決策順序是：刪除無用的內容、改用檢索而非塞入、快取穩定的部分，然後壓縮剩下的。大多數團隊卻第一個就去抓第四個。

延遲值得在算術中單獨列一行，因為壓縮只是把成本移來移去，而非單純降低。一個壓縮呼叫是一次額外的網路來回和一次額外的生成，都在關鍵路徑上，而且壓縮器必須先讀完整個上下文才能開始輸出。對於互動功能，這很容易增加比縮短提示詞所節省的更多實際時間。因此壓縮最有道理的地方是它可以離線進行 — 在攝取時或按照排程進行 — 而在人類正在等待的請求中間進行是最沒有道理的。

每種方法會破壞什麼

壓縮本質上是有損的；問題在於你能容忍哪種損失。抽取式選取會失去段落之間的連接組織，因此會損害需要跨段落進行綜合的任務。抽象式摘要會失去精確性 — 精確數字、日期、名稱，以及眾所周知的否定詞，因為「該條款不適用於子公司」和「該條款適用於子公司」在嵌入空間中幾乎會被摘要成相鄰的向量。Token 剪枝會失去語法結構，這通常能被模型恢復，但偶爾不行，而且會讓你的提示詞對半夜兩點正在除錯的人類來說無法閱讀。

有一種損失是所有方法都共有的，值得明白指出：壓縮之後你就無法再引用原始來源。如果你的產品會顯示引用，壓縮後的文字必須保留指向原始段落的識別符，否則引用功能會悄悄開始捏造內容。

在長期執行的對話中還有一種複合效應需要注意。壓縮一個已經包含先前壓縮摘要的上下文，就會變成摘要的摘要，而損失不是加成而是相乘 — 具體細節最先消失，然後是限定詞，最後是已確認事實與假設之間的區別。在每個層級都保留指向未壓縮原始內容的指標，並盡可能從原始來源重新壓縮，而不是從先前的壓縮結果壓縮。

防止最壞結果的規則

絕對不要壓縮指令。 系統提示詞和使用者的問題要原封不動。它們很小，而且是規格說明。
絕對不要壓縮結構化數值。 識別符、金額、日期、數量。將它們提取成一個小的逐字區塊，只壓縮它們周圍的散文。
壓縮一次，快取結果。 如果同一份原始文件被重複使用，壓縮後的形式就是一個穩定的成品 — 應該儲存它，而不是每次請求都重新產生。
衡量端到端的結果，而非壓縮率。 以三個答案準確度點為代價換來的 10 倍壓縮率，在幾乎任何價格下都是糟糕的交易，而除非評估是在最終答案上執行，否則你不會看到這一點。
保留未壓縮的路徑。 當答案錯誤時，第一個診斷方法是用完整上下文重新執行。如果這樣就修好了，壓縮就是你的 bug；如果沒有，那它從來就不是問題。

上述損益平衡取決於壓縮器與目標模型之間的價格差距，這是兩個模型的比較而非單一查詢；把小型和大型模型的費率並排比較就足以判斷一個壓縮步驟在你開始建置前是否能回收成本。

為什麼兩者無法組合

B-tree 索引和 GIN 索引可以結合：Postgres 會從每個索引建立位元圖並進行 AND 運算。HNSW 索引無法參與其中，因為它不會產生一組符合的資料列——它產生的是有序串流，最接近的排在最前面，而這個排序正是它的全部價值。你無法將一個排序與位元圖進行交集運算後還保有排序。

因此規劃器必須做出選擇。它要嘛走訪圖形，之後再捨棄不符合過濾器的資料列（後置過濾），要嘛先找出通過過濾器的資料列，再為它們全部計算距離（前置過濾）。這兩種方式有不同的成本，更重要的是，會產生不同的結果。

Postgres 使用其成本模型在兩者之間選擇，而它對近似最近鄰居掃描的成本模型接近猜測。它沒有描述圖形在找到十個通過你過濾器的資料列之前會檢查多少資料列的統計資訊，因為這個數量取決於你的查詢落在向量空間的哪個位置。因此規劃器使用結構上缺乏資訊的估計值來選擇，有時會選到無法回答你查詢的執行計畫。這是在 Postgres 中唯一一種從應用程式覆寫規劃器是正常行為而非壞味道的情況。

後置過濾器及其運算

這是你對明顯查詢預設會得到的結果：

SELECT id, content
FROM chunks
WHERE tenant_id = 42
ORDER BY embedding <=> $1
LIMIT 10;

Enter fullscreen mode

Exit fullscreen mode

HNSW 掃描會讓 hnsw.ef_search 個候選保持存活，並依距離順序返回它們；過濾器會套用在這個串流上。令 s 為過濾器的選擇性——它通過資料表的分數。如果過濾器與向量空間中的位置無關，預期的倖存者數量為：

survivors ≈ ef_search × s

To get k results:   ef_search ≥ k / s

Assumptions: the filter is uncorrelated with the embedding
distribution; ef_search candidates are the only rows examined;
hnsw.ef_search has a hard maximum of 1000.

Enter fullscreen mode

Exit fullscreen mode

在預設 ef_search = 40 且過濾器通過資料表一半的情況下，你預期有二十個倖存者，而你要求十個。沒問題。在過濾器每千分之一列通過的情況下，你預期有 40 × 0.001 = 0.04 個倖存者，這在實務上代表查詢完全沒有返回任何結果，而索引運作完全符合設計。

在 pgvector 0.8.0 之前，在掃描內沒有補救方法：你只會得到倖存的資料列數量，無聲無息，且不會提示答案不足。0.8.0 加入了疊代掃描，它會使用較大的候選集合重新掃描，直到達到限制或耗盡預算為止：

SET LOCAL hnsw.iterative_scan = strict_order;   -- pgvector 0.8.0+
SET LOCAL hnsw.max_scan_tuples = 20000;        -- the budget it stops at

Enter fullscreen mode

Exit fullscreen mode

strict_order 保證結果會以真正的距離順序返回；relaxed_order 較快，可能會讓結果稍微偏離順序，如果之後無論如何都會執行重新排序器，這通常是可以接受的。兩者都無法消除底層成本——在高度選擇性過濾器上的疊代掃描需要做大量工作才能找到少數幾列。

以數字呈現的懸崖

將公式放入表格中，問題的形狀立刻顯現。對於 k = 10：

Filter passes	Description
50% of rows	ef_search of 20 is enough. The default of 40 has margin. Nothing to do.
10% of rows	ef_search ≥ 100. Query cost roughly 2.5× the unfiltered one. Still comfortable.
2% of rows	ef_search ≥ 500. Roughly 12× the work of the default, and latency you will notice.
1% of rows	ef_search ≥ 1000 — exactly the maximum pgvector allows. You are at the edge with no margin for an unlucky query.
0.1% of rows	ef_search would need to be 10,000. Not reachable. The post-filter plan cannot answer this query correctly, at any setting, ever.

這就是懸崖：它不是逐漸退化，而是在頂-10 查詢百分之一選擇性處的硬牆，一般而言位於 s = k / 1000。在它之下，索引不是變慢——而是無能為力，而疊代掃描會把這種無能從錯誤答案轉變成緩慢答案。

該推導中的一個假設值得一提，因為它經常是錯誤的。它假設過濾器與向量位置無關。租戶過濾器通常大致無關。語言、文件類型或日期的過濾器則有強烈相關性——所有德文區塊在嵌入空間中都彼此靠近——這時倖存者要嘛聚集在候選集合中（優於公式），要嘛完全不在其中（糟得多）。公式是正確的規劃工具；你自己的測量才是正確的決策工具。

前置過濾器，以及它何時更快

另一個執行計畫完全忽略向量索引：使用 B-tree 找出符合的資料列，為每個計算距離，排序，取十個。召回率精確為 100%，因為沒有任何近似。

-- Force it, to see what it costs:
SET LOCAL enable_indexscan = off;   -- disables the HNSW ordered scan
SET LOCAL enable_bitmapscan = on;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM chunks WHERE tenant_id = 42
ORDER BY embedding <=> $1 LIMIT 10;

 Limit
   ->  Sort
         Sort Key: ((embedding <=> '[...]'::vector))
         Sort Method: top-N heapsort  Memory: 27kB
         ->  Bitmap Heap Scan on chunks
               Recheck Cond: (tenant_id = 42)
               ->  Bitmap Index Scan on chunks_tenant_idx
                     Index Cond: (tenant_id = 42)

Enter fullscreen mode

Exit fullscreen mode

這個執行計畫的成本是 s × N 次各有 d 個維度的距離計算，加上堆積提取。在 N = 10,000,000、s = 0.001 且 d = 1536 時：一萬列、一千五百萬次乘加，個位數毫秒的運算。一萬個分散資料列的堆積提取才是真正的成本，而且在暖機狀態下仍可能低於一百毫秒。

因此後置過濾器完全無法回答的執行計畫，是前置過濾器能精確且快速回答的計畫。懸崖和交叉點是同一個地方，這是個方便的巧合，也是本頁最有用的資訊。

交叉點位於何處

將兩種成本設為相等並求解。精確計畫的成本約為 sNd。後置過濾計畫需要 ef_search ≈ k/s，且每個候選會展開約 m 個鄰居，因此成本約為 (k/s)md：

s N d  =  (k / s) m d

s²     =  k m / N

s*     =  sqrt(k m / N)

k = 10, m = 16, N = 10,000,000:
  s* = sqrt(160 / 10,000,000) = sqrt(1.6e-5) = 0.0040  →  0.40%

k = 10, m = 16, N = 1,000,000:
  s* = sqrt(160 / 1,000,000)  = 0.0126        →  1.26%

Assumptions: distance computation dominates both plans; heap access
costs are ignored, which flatters the exact plan; graph traversal
cost is linear in ef_search and m.

Enter fullscreen mode

Exit fullscreen mode

在 s* 之下，不要使用向量索引。在它之上，才使用。這個數字會隨著你的資料表大小移動，而平方根意味著它移動緩慢——從一百萬列成長到一千萬列只會讓它從約 1.3% 移動到約 0.4%。

這代表實務規則是：選擇超過資料表百分之幾的過濾器應該透過提高 ef_search 的向量索引；選擇低於百分之一的過濾器應該跳過它。規劃器不會可靠地為你做出這個選擇，因為它對 ANN 掃描的成本模型只是個佔位符，所以你應該明確地做出選擇。

四種解決方法

提高 ef_search 並測量。 對於高於百分之幾的選擇性，這就是完整解答。根據預期的選擇性為每個查詢設定它——你通常大致知道一個租戶有多少列——而不是全域設定。
依過濾欄位進行分割。 如果你的過濾器幾乎總是同一個欄位，將它設為分割鍵並為每個分割區建立一個 HNSW 索引。每個分割區的索引只包含符合的資料列，因此對它的掃描是未過濾的，上面的運算完全不適用。這是最乾淨的修正，也是具有真正運作成本的修正，因為它會讓你的索引數量倍增。
```
CREATE TABLE chunks (
  id bigint GENERATED ALWAYS AS IDENTITY,
  tenant_id int NOT NULL,
  embedding vector(1536) NOT NULL,
  content text NOT NULL
) PARTITION BY LIST (tenant_id);

CREATE TABLE chunks_t42 PARTITION OF chunks FOR VALUES IN (42);
CREATE INDEX ON chunks_t42 USING hnsw (embedding vector_cosine_ops);
```
部分索引，用於少數熱門值。 索引本身的 WHERE 子句。適合兩三個大型租戶或單一 status = 'active' 述詞；超過幾十個就無法實用，因為每個都需要完整的 HNSW 建置。
```
CREATE INDEX chunks_active_hnsw ON chunks
  USING hnsw (embedding vector_cosine_ops)
  WHERE deleted_at IS NULL;
```
在交叉點之下強制使用精確計畫。 在 (tenant_id) 上建立複合 B-tree，並為該查詢停用索引掃描，或是撰寫查詢讓 ANN 索引無法套用——例如對計算出的運算式排序。在小的已過濾集合上進行精確搜尋不是後備方案；在 s* 之下，它才是正確的計畫。

不在清單中的一件事：將過濾欄位加入 HNSW 索引。pgvector 不支援多欄位 HNSW 索引，也沒有任何運算子類別能讓它有意義。如果某個教學建議這麼做，那個教學是在描述不同的引擎。

無論你採取哪種路線，你首先需要的數字是實際的選擇性，而它是一個查詢而非假設。過濾器很少是均勻的：少數租戶持有大部分語料，而長尾幾乎沒有，因此平均選擇性為百分之五可能隱藏著一千個坐在 0.01% 的客戶，他們看到空的結果而其他人都沒問題。

-- The distribution of selectivity across the filter values you
-- actually use. Look at the bottom decile, not the mean.
WITH n AS (SELECT count(*)::numeric AS total FROM chunks)
SELECT tenant_id,
       count(*) AS rows,
       round(100.0 * count(*) / (SELECT total FROM n), 4) AS pct_of_table,
       -- ef_search needed for a top-10 query, from k/s:
       ceil(10.0 * (SELECT total FROM n) / count(*)) AS ef_search_needed
FROM chunks
GROUP BY tenant_id
ORDER BY ef_search_needed DESC
LIMIT 20;

Enter fullscreen mode

Exit fullscreen mode

該輸出中任何 ef_search_needed 高於 1000 的項目，都是後置過濾計畫無法服務的過濾值，而此類資料列的計數會告訴你答案是每個查詢的 ef_search、分割策略，還是將小型租戶送到精確路徑、大型租戶透過索引的路由規則。最後這個選項值得考慮：兩個計畫都是正確的，因此依每個請求在它們之間選擇是一種合理的優化，而不是駭客行為。

最後，讓團隊驚訝的互動是：Postgres 列層級安全性原則會變成 WHERE 子句，這意味著啟用 RLS 會在一夜之間把應用程式中每個向量查詢都變成後置過濾的查詢，具有單一租戶的選擇性。這在多租戶檢索的列層級安全性中有涵蓋，並包含洩漏測試。

從命令列佈建

從 CLI 拉出 Stripe Projects 目錄，會顯示 Render 在網路中提供的項目：Postgres、Web 服務或靜態網站。輸入 stripe projects add render 會直接顯示該目錄，接著相同的指令可以交給像 Claude 這樣的程式碼代理，它會連接公開的 GitHub 儲存庫，並直接從命令列透過 Render 進行部署。同樣的模式也能擴展到加入其他供應商，包括 OpenRouter、Exa、Clerk 和 PostHog 等，只要用自然語言詢問代理它需要什麼；它會使用相同的底層指令，將所有東西整合到一個專案中，並共用一組環境變數。

https://render.com/blog/stripe-an-orchestration-layer-not-a-platform

https://www.worldprogramming.org/posts/stripe-an-orchestration-layer-not-a-platform-av4nrm

在原本運作良好的向量查詢中加入 WHERE tenant_id = 42，會發生兩種情況之一：查詢變慢，或是返回的資料列比你要求的還少。這兩種現象背後是相同的事實——近似索引與過濾器無法同時套用——而導致致命問題的選擇性是可以事先計算出來的。

為什麼兩者無法組合

B-tree 索引和 GIN 索引可以結合：Postgres 會從每個索引建立位元圖並進行 AND 運算。HNSW 索引無法參與其中，因為它不會產生一組符合的資料列——它產生的是有序串流，最接近的排在最前面，而這個排序正是它的全部價值。你無法將一個排序與位元圖進行交集運算後還保有排序。

因此規劃器必須做出選擇。它要嘛走訪圖形，之後再捨棄不符合過濾器的資料列（後置過濾），要嘛先找出通過過濾器的資料列，再為它們全部計算距離（前置過濾）。這兩種方式有不同的成本，更重要的是，會產生不同的結果。

Postgres 使用其成本模型在兩者之間選擇，而它對近似最近鄰居掃描的成本模型接近猜測。它沒有描述圖形在找到十個通過你過濾器的資料列之前會檢查多少資料列的統計資訊，因為這個數量取決於你的查詢落在向量空間的哪個位置。因此規劃器使用結構上缺乏資訊的估計值來選擇，有時會選到無法回答你查詢的執行計畫。這是在 Postgres 中唯一一種從應用程式覆寫規劃器是正常行為而非壞味道的情況。

後置過濾器及其運算

這是你對明顯查詢預設會得到的結果：

SELECT id, content
FROM chunks
WHERE tenant_id = 42
ORDER BY embedding <=> $1
LIMIT 10;

Enter fullscreen mode

Exit fullscreen mode

HNSW 掃描會讓 hnsw.ef_search 個候選保持存活，並依距離順序返回它們；過濾器會套用在這個串流上。令 s 為過濾器的選擇性——它通過資料表的分數。如果過濾器與向量空間中的位置無關，預期的倖存者數量為：

survivors ≈ ef_search × s

To get k results:   ef_search ≥ k / s

Assumptions: the filter is uncorrelated with the embedding
distribution; ef_search candidates are the only rows examined;
hnsw.ef_search has a hard maximum of 1000.

Enter fullscreen mode

Exit fullscreen mode

在預設 ef_search = 40 且過濾器通過資料表一半的情況下，你預期有二十個倖存者，而你要求十個。沒問題。在過濾器每千分之一列通過的情況下，你預期有 40 × 0.001 = 0.04 個倖存者，這在實務上代表查詢完全沒有返回任何結果，而索引運作完全符合設計。

在 pgvector 0.8.0 之前，在掃描內沒有補救方法：你只會得到倖存的資料列數量，無聲無息，且不會提示答案不足。0.8.0 加入了疊代掃描，它會使用較大的候選集合重新掃描，直到達到限制或耗盡預算為止：

SET LOCAL hnsw.iterative_scan = strict_order;   -- pgvector 0.8.0+
SET LOCAL hnsw.max_scan_tuples = 20000;        -- the budget it stops at

Enter fullscreen mode

Exit fullscreen mode

strict_order 保證結果會以真正的距離順序返回；relaxed_order 較快，可能會讓結果稍微偏離順序，如果之後無論如何都會執行重新排序器，這通常是可以接受的。兩者都無法消除底層成本——在高度選擇性過濾器上的疊代掃描需要做大量工作才能找到少數幾列。

以數字呈現的懸崖

將公式放入表格中，問題的形狀立刻顯現。對於 k = 10：

Filter passes	Description
50% of rows	ef_search of 20 is enough. The default of 40 has margin. Nothing to do.
10% of rows	ef_search ≥ 100. Query cost roughly 2.5× the unfiltered one. Still comfortable.
2% of rows	ef_search ≥ 500. Roughly 12× the work of the default, and latency you will notice.
1% of rows	ef_search ≥ 1000 — exactly the maximum pgvector allows. You are at the edge with no margin for an unlucky query.
0.1% of rows	ef_search would need to be 10,000. Not reachable. The post-filter plan cannot answer this query correctly, at any setting, ever.

這就是懸崖：它不是逐漸退化，而是在頂-10 查詢百分之一選擇性處的硬牆，一般而言位於 s = k / 1000。在它之下，索引不是變慢——而是無能為力，而疊代掃描會把這種無能從錯誤答案轉變成緩慢答案。

該推導中的一個假設值得一提，因為它經常是錯誤的。它假設過濾器與向量位置無關。租戶過濾器通常大致無關。語言、文件類型或日期的過濾器則有強烈相關性——所有德文區塊在嵌入空間中都彼此靠近——這時倖存者要嘛聚集在候選集合中（優於公式），要嘛完全不在其中（糟得多）。公式是正確的規劃工具；你自己的測量才是正確的決策工具。

前置過濾器，以及它何時更快

另一個執行計畫完全忽略向量索引：使用 B-tree 找出符合的資料列，為每個計算距離，排序，取十個。召回率精確為 100%，因為沒有任何近似。

-- Force it, to see what it costs:
SET LOCAL enable_indexscan = off;   -- disables the HNSW ordered scan
SET LOCAL enable_bitmapscan = on;

EXPLAIN (ANALYZE, BUFFERS)
SELECT id FROM chunks WHERE tenant_id = 42
ORDER BY embedding <=> $1 LIMIT 10;

 Limit
   ->  Sort
         Sort Key: ((embedding <=> '[...]'::vector))
         Sort Method: top-N heapsort  Memory: 27kB
         ->  Bitmap Heap Scan on chunks
               Recheck Cond: (tenant_id = 42)
               ->  Bitmap Index Scan on chunks_tenant_idx
                     Index Cond: (tenant_id = 42)

Enter fullscreen mode

Exit fullscreen mode

這個執行計畫的成本是 s × N 次各有 d 個維度的距離計算，加上堆積提取。在 N = 10,000,000、s = 0.001 且 d = 1536 時：一萬列、一千五百萬次乘加，個位數毫秒的運算。一萬個分散資料列的堆積提取才是真正的成本，而且在暖機狀態下仍可能低於一百毫秒。

因此後置過濾器完全無法回答的執行計畫，是前置過濾器能精確且快速回答的計畫。懸崖和交叉點是同一個地方，這是個方便的巧合，也是本頁最有用的資訊。

交叉點位於何處

將兩種成本設為相等並求解。精確計畫的成本約為 sNd。後置過濾計畫需要 ef_search ≈ k/s，且每個候選會展開約 m 個鄰居，因此成本約為 (k/s)md：

s N d  =  (k / s) m d

s²     =  k m / N

s*     =  sqrt(k m / N)

k = 10, m = 16, N = 10,000,000:
  s* = sqrt(160 / 10,000,000) = sqrt(1.6e-5) = 0.0040  →  0.40%

k = 10, m = 16, N = 1,000,000:
  s* = sqrt(160 / 1,000,000)  = 0.0126        →  1.26%

Assumptions: distance computation dominates both plans; heap access
costs are ignored, which flatters the exact plan; graph traversal
cost is linear in ef_search and m.

Enter fullscreen mode

Exit fullscreen mode

在 s* 之下，不要使用向量索引。在它之上，才使用。這個數字會隨著你的資料表大小移動，而平方根意味著它移動緩慢——從一百萬列成長到一千萬列只會讓它從約 1.3% 移動到約 0.4%。

這代表實務規則是：選擇超過資料表百分之幾的過濾器應該透過提高 ef_search 的向量索引；選擇低於百分之一的過濾器應該跳過它。規劃器不會可靠地為你做出這個選擇，因為它對 ANN 掃描的成本模型只是個佔位符，所以你應該明確地做出選擇。

四種解決方法

提高 ef_search 並測量。 對於高於百分之幾的選擇性，這就是完整解答。根據預期的選擇性為每個查詢設定它——你通常大致知道一個租戶有多少列——而不是全域設定。
依過濾欄位進行分割。 如果你的過濾器幾乎總是同一個欄位，將它設為分割鍵並為每個分割區建立一個 HNSW 索引。每個分割區的索引只包含符合的資料列，因此對它的掃描是未過濾的，上面的運算完全不適用。這是最乾淨的修正，也是具有真正運作成本的修正，因為它會讓你的索引數量倍增。
```
CREATE TABLE chunks (
  id bigint GENERATED ALWAYS AS IDENTITY,
  tenant_id int NOT NULL,
  embedding vector(1536) NOT NULL,
  content text NOT NULL
) PARTITION BY LIST (tenant_id);

CREATE TABLE chunks_t42 PARTITION OF chunks FOR VALUES IN (42);
CREATE INDEX ON chunks_t42 USING hnsw (embedding vector_cosine_ops);
```
部分索引，用於少數熱門值。 索引本身的 WHERE 子句。適合兩三個大型租戶或單一 status = 'active' 述詞；超過幾十個就無法實用，因為每個都需要完整的 HNSW 建置。
```
CREATE INDEX chunks_active_hnsw ON chunks
  USING hnsw (embedding vector_cosine_ops)
  WHERE deleted_at IS NULL;
```
在交叉點之下強制使用精確計畫。 在 (tenant_id) 上建立複合 B-tree，並為該查詢停用索引掃描，或是撰寫查詢讓 ANN 索引無法套用——例如對計算出的運算式排序。在小的已過濾集合上進行精確搜尋不是後備方案；在 s* 之下，它才是正確的計畫。

不在清單中的一件事：將過濾欄位加入 HNSW 索引。pgvector 不支援多欄位 HNSW 索引，也沒有任何運算子類別能讓它有意義。如果某個教學建議這麼做，那個教學是在描述不同的引擎。

無論你採取哪種路線，你首先需要的數字是實際的選擇性，而它是一個查詢而非假設。過濾器很少是均勻的：少數租戶持有大部分語料，而長尾幾乎沒有，因此平均選擇性為百分之五可能隱藏著一千個坐在 0.01% 的客戶，他們看到空的結果而其他人都沒問題。

-- The distribution of selectivity across the filter values you
-- actually use. Look at the bottom decile, not the mean.
WITH n AS (SELECT count(*)::numeric AS total FROM chunks)
SELECT tenant_id,
       count(*) AS rows,
       round(100.0 * count(*) / (SELECT total FROM n), 4) AS pct_of_table,
       -- ef_search needed for a top-10 query, from k/s:
       ceil(10.0 * (SELECT total FROM n) / count(*)) AS ef_search_needed
FROM chunks
GROUP BY tenant_id
ORDER BY ef_search_needed DESC
LIMIT 20;

Enter fullscreen mode

Exit fullscreen mode

該輸出中任何 ef_search_needed 高於 1000 的項目，都是後置過濾計畫無法服務的過濾值，而此類資料列的計數會告訴你答案是每個查詢的 ef_search、分割策略，還是將小型租戶送到精確路徑、大型租戶透過索引的路由規則。最後這個選項值得考慮：兩個計畫都是正確的，因此依每個請求在它們之間選擇是一種合理的優化，而不是駭客行為。

最後，讓團隊驚訝的互動是：Postgres 列層級安全性原則會變成 WHERE 子句，這意味著啟用 RLS 會在一夜之間把應用程式中每個向量查詢都變成後置過濾的查詢，具有單一租戶的選擇性。這在多租戶檢索的列層級安全性中有涵蓋，並包含洩漏測試。

問題不在於 API，而在於差異性

在 iOS 上，你只需針對單一廠商的少數幾代晶片。而在 Android 上，你必須面對多家晶片廠商、各自多個世代，以及由裝置製造商按照自己的時程所出貨的驅動程式堆疊。兩支搭載相同旗艦晶片的手機，可能因為其中一支使用較舊的 GPU 驅動程式而表現不同。

由此導出的規則是：永遠不要依據裝置型號字串來決定是否加速。依裝置名稱建立的白名單會在一個版本週期內過期，無法涵蓋你出貨後才推出的裝置，而且它們是在有實際測量可用的情況下仍做出的猜測。應該在裝置上實際嘗試一次，並快取結果。

你所選擇的各層抽象

大致上有三種可用的抽象層級，選擇正確的層級主要取決於你需要多少控制權：

由平台提供的受管理裝置端模型。 Google 提供系統層級的生成式 AI 功能，應用程式可以呼叫，模型由平台管理並在應用程式外部更新。這能讓你的 bundle 大小為零，但完全沒有控制權：可用性取決於裝置與系統元件版本，因此你的功能在缺少這些條件時必須降級。請以程式方式檢查目前可用性，而不是假設最低 API 等級。
你自行打包的執行環境，搭配 delegate。 LiteRT（先前稱為 TensorFlow Lite）或 ONNX Runtime，在載入時選擇加速 delegate 或執行提供者。這是主流選擇。你可以控制模型、版本與後備機制。
直接針對單一晶片家族的廠商 SDK。 晶片廠商會發布自己的神經網路 SDK，通常能從自家 NPU 榨取出比通用 delegate 更多的效能，但代價是需要額外的整合工作，並且每個廠商都要準備獨立的模型成品。當推論本身就是產品時值得這麼做；若推論只是其中一項功能則很少值得。

哪些加速路徑目前有效、哪些已被棄用而改用廠商 SDK，已改變過多次且仍持續變化。請將你選擇的 delegate 視為建置的參數，而非 Android 的既定事實，並在每次主要平台版本發布時重新檢查。以下的探測程式碼設計成只需修改一行就能更換 delegate。

能力探測器

無論你選擇哪種執行環境，模式都相同：嘗試建構加速的直譯器、執行固定的輸入、與 CPU 參考值比對，並計時兩者。如果建構拋出例外、數值差異超過容忍範圍，或加速路徑實際上並未更快，則使用 CPU。

enum Accel { NNAPI_OR_VENDOR, GPU, CPU }

data class ProbeResult(val accel: Accel, val medianMs: Double, val valid: Boolean)

fun probe(context: Context, modelBytes: ByteBuffer): Accel {
    val golden = loadGoldenInputOutput(context)   // fixed input + expected output
    val results = mutableListOf<ProbeResult>()

    // Always establish the CPU reference first: it is the tie-breaker
    // for both correctness and speed.
    val cpu = timeRun(modelBytes, Accel.CPU, golden)
    results += cpu

    for (accel in listOf(Accel.NNAPI_OR_VENDOR, Accel.GPU)) {
        val r = try {
            timeRun(modelBytes, accel, golden)
        } catch (t: Throwable) {
            // Delegate construction failing is normal, not exceptional.
            ProbeResult(accel, Double.MAX_VALUE, valid = false)
        }
        results += r
    }

    val best = results
        .filter { it.valid }
        .minByOrNull { it.medianMs } ?: cpu

    // Require a real margin. A 5% win is not worth a second code path.
    return if (best.medianMs < cpu.medianMs * 0.8) best.accel else Accel.CPU
}

Enter fullscreen mode

Exit fullscreen mode

在功能首次被使用時，於背景執行緒執行此探測一次——不要在應用程式啟動時執行，因為那時它會與其他所有工作競爭啟動預算。將判斷結果以你的應用程式版本、模型版本與 OS build number 為鍵值持久化儲存，並在這三者任一改變時重新探測。系統更新可能會新增或移除可用的驅動程式，而你的快取答案不能比它活得更久。

與黃金參考值進行驗證

探測中正確性這一半是最常被整合忽略的部分，卻也是能抓住最嚴重 bug 類型的那一部分：一個能執行、速度快、但結果錯誤的 delegate。

選擇一個能有效測試模型的固定輸入——不要用全零，因為許多有問題的 kernel 會意外地正確處理全零。
使用你信任的參考實作，在離線狀態下計算一次預期輸出，並以 asset 形式出貨。
在裝置上，以適合精確度的容忍值進行元素逐一比對。使用 fp16 進行計算的 delegate 不會與 fp32 參考值完全相符，因此在正規化後的輸出上使用約 1e-2 的絕對容忍值通常是正確的；完全匹配測試會在每一台正常的裝置上失敗。
對於分類器，還要斷言 top-1 標籤是否相符。數值容忍可能會掩蓋類別翻轉，而類別翻轉才是使用者實際看到的結果。

使用 SoC 識別碼與 OS build 來記錄探測結果。幾週後，這些記錄會成為你自己安裝基礎唯一準確的地圖，其價值遠超過任何公開的相容性矩陣。

針對等級而非裝置進行設計

與其設計一個必須在所有地方都能運作的體驗，不如定義兩到三個等級，讓探測來為裝置指派等級：

等級	描述
accelerated	探測找到有效且明顯更快的路徑。完整功能：更大的模型、更長的上下文、即時處理。
cpu-capable	沒有加速，但 CPU 推論能在互動預算內完成。較小的模型、批次處理或依需求執行而非即時。
unsupported	CPU 推論太慢，或記憶體不允許載入模型。功能被隱藏或改由遠端提供。隱藏它是誠實的做法；一個需要九秒的功能比沒有功能更糟糕。

透過實際測量來決定，意味著隨著你的安裝基礎變化，等級指派仍能保持正確，也意味著在你推出後才發布的新手機能自動獲得良好的體驗。這也為你提供了一個乾淨的地方來放置緊急停止開關：如果某個 delegate 在部分使用者群上被發現有問題，你可以透過遠端旗標將該群組降級到 CPU，而不是推出緊急版本。此模式與模型與提示的機能旗標中描述的模式相同。

你實際會遇到的失敗情況

無聲的 CPU 退回。 Delegate 成功建構、未回報錯誤，卻因為某些運算子不支援而將大部分運算圖在 CPU 上執行。只有計時能揭露這一點。這也是為什麼探測要與 CPU 比較，而非僅檢查建構是否成功。
Delegate 初始化成本。 建構一個加速的直譯器可能需要數百毫秒甚至更久，因為驅動程式需要編譯運算圖。必須加以分攤：讓直譯器在整個 session 中保持存活，而非每次推論都重新建構，且永遠不要在主執行緒上建構。
量化不匹配。 許多 NPU 只能執行整數模型。浮點模型會被 delegate 拒絕，或是無聲地在其他地方執行。如果你很在意 NPU 路徑，請出貨量化後的成品，並針對黃金參考值進行驗證——量化是一種數值變更，而且哪些層能容忍它並不一致。
背景執行限制。 Android 不會讓你在背景應用程式中無限使用 NPU。長時間的工作應該放在前景服務並顯示通知，或是放在可延遲的背景工作佇列，由系統在裝置閒置且充電時排程執行。
入門級裝置的記憶體壓力。 透過釋放直譯器並在需要時延遲載入來處理 onTrimMemory。在背景 session 中持續保留模型是導致應用程式被殺掉、然後被怪罪冷啟動變慢的常見原因。

如果 unsupported 等級退回至託管模型，則這兩條路徑在呼叫端必須可以互換——Multigrid 在各提供者之間暴露單一 API，並提供每次請求的成本與延遲，這讓遠端分支保持為單一實作，而非針對每個可能路由到的廠商各有一個。

選擇就是全部的工作

日誌傾印不是資料集。百分之九十的生產流量是模型已經在正確執行的事，訓練這些內容不會教會你任何原本沒有的知識。值得納入的範例，是那些攜帶目前模型所缺乏資訊的案例。

人類編輯過輸出的請求。 任何有審核步驟的產品中最高訊號的來源。編輯本身就是標籤：輸入加上修正後的輸出就是完美的訓練配對，而差異告訴你正在修正哪一種失敗模式。
未通過驗證器的請求。 結構違規、JSON 解析失敗、破壞下游合約的輸出。將輸入與手寫或修復後的正確輸出配對。
被重試的請求。 使用者重新產生是一個未標記的負面範例。它告訴你該去看哪裡，即使它沒有告訴你使用者真正想要什麼。
被路由到更昂貴模型的請求。 如果存在後備或升級路徑，所有走過該路徑的內容都是微調最適合的候選：教導廉價模型學會昂貴模型擁有的行為。
普通流量的分層抽樣。 不是因為它能教導，而是因為一個完全由失敗案例組成的資料集會讓模型認為一切都是失敗案例。百分之十到三十的普通流量能讓分布保持真實。

正確輸出從哪裡來

選擇給了你輸入。目標則是另一個問題，而且只有三種來源，依品質與成本由高到低排序。

目標來源	描述
人類編輯的輸出	如果你的產品已經有審核步驟則免費，若沒有則極為昂貴。品質最高，也是唯一能反映使用者真正想要什麼、而非模型認為他們想要什麼的來源。
更強模型（已過濾）	前沿模型的回答，僅在通過驗證器或評分標準時保留。便宜且可擴展。會繼承教師的盲點，並受限於教師的使用條款——見 /learn/fine-tuning-licenses。
你自己模型的輸出	免費，但未經過濾幾乎總是錯誤的。你無法透過模仿自己來學習原本沒有的行為。只有在有嚴格外部過濾器時才合理——例如通過的單元測試、已對帳的交易。

清理而不壓扁分布

直覺是把一切都正規化：去除空白、統一大小寫、統一日期格式、將樣板內容模板化。大部分都要抵抗。推論時的輸入會以日誌中同樣混亂的方式呈現，而只在乾淨輸入上訓練的模型，處理混亂輸入時會表現更差。

真正需要做的事：

遮蔽而非刪除。 個人資料必須移除，但把名字替換成空字串會改變句子的結構。請替換成同類型且長度類別合理且一致的替代值。
以兩個門檻進行去重。 基於雜湊的完全匹配去重能捕捉重放。但無法捕捉僅一個識別碼不同的模板化請求，而日誌資料充滿這類內容。以 Jaccard 門檻約 0.8 進行 MinHash 近似去重則可以，在來自日誌的語料上通常能移除遠多於完全去重的資料。
限制每個來源的貢獻比例。 單一企業客戶若產生 60% 的流量，就會產生 60% 的資料集，你會針對他們特別微調模型。請對任何單一租戶、模板或端點設定固定的比例上限。
丟棄被截斷的內容。 任何在 max_tokens 而非結束序列 token 停止的完成，都是在教導模型在中途句子停止。請根據結束原因而非長度來過濾。

兩個洩漏陷阱

分割後的近似重複洩漏

以隨機抽樣分割後，出現 400 次的模板化請求會同時出現在訓練集與測試集。你的評估會因此測量到記憶而誤報為泛化，數字會非常漂亮，直到生產環境與其不符為止。

請在分割之前先去重，並根據分組鍵而非單列來分割——依租戶、文件、工作階段、模板 ID 來分割。如果兩個範例有可能來自同一個底層事物，它們就應該屬於分割的同一側。

時間洩漏

隨機分割也會讓模型在下個月資料上訓練，卻在上個月資料上測試。對於任何輸入分布會漂移的情況——而產品流量總是會漂移——請依時間分割：在截止時間之前的所有資料用於訓練，之後的所有資料用於測試。得到的數字會較低，但才是能預測生產環境的那一個。

沒人注意到的回饋迴路

這是專屬於日誌衍生資料的陷阱，而且它很安靜。你的日誌包含目前模型的輸出。如果你拿來訓練並部署，下個月的日誌就會包含新模型的輸出，然後你又拿來訓練。每一個世代都是在擬合前一個世代，而不是擬合使用者真正想要的內容。

可見的症狀是收窄：輸出變得更一致、避險消失、模型發展出語言上的抽搐，而稀有但有效的回應形式則完全消失。這與 Shumailov 等人在 2024 年《Nature》論文中描述的合成資料動態相同，只是透過日誌管線的後門進入。

防禦方式是硬性規則而非警覺：只有當目標來自模型外部——人類編輯、通過的測試、已對帳的交易、不同的模型——時，範例才能進入資料集。將來源記錄為一個欄位，並讓訓練作業拒絕沒有來源的列。

格式化與損失遮罩

最後一步是機械性的，也是許多執行在無聲中失敗的地方。有兩個規則。

使用基礎模型自己的聊天模板。 不是看起來像的那個。特殊 token、角色標記與空白字元都很重要，如果訓練時使用的模板與服務堆疊套用的模板不同，適配器就會被要求在格式偏移中進行無謂的泛化。在啟動執行前，請渲染一個範例並印出可見的特殊 token。

在提示上遮罩損失。 許多訓練腳本預設會計算整個序列的損失，因此模型同時被訓練去預測你的指令以及它的答案。對於指令微調，你幾乎總是想要僅完成部分的損失：

tokens   <|system|> You are ... <|user|> Summarise ... <|assistant|> The report ... <|eot|>
labels   -100 -100 -100 ... -100 -100 -100 ...        The report ... <|eot|>
         ________________ masked ________________/  ____ supervised ____/

Enter fullscreen mode

Exit fullscreen mode

結束回合的 token 必須位於受監督的區域內。如果遮罩它，模型就永遠不會被訓練如何停止，這會產生最常見的「微調搞壞了一切」報告：一個正確回答後卻不斷持續下去的模型。

上下文壓縮：讓 10 萬 Tokens 塞進 1 萬

先談免費的勝利

四種需要成本的類型

壓縮必須能回收成本

每種方法會破壞什麼

防止最壞結果的規則

相關文章

為什麼兩者無法組合

後置過濾器及其運算

以數字呈現的懸崖

前置過濾器，以及它何時更快

交叉點位於何處

四種解決方法

相關文章

從命令列佈建

為什麼兩者無法組合

後置過濾器及其運算

以數字呈現的懸崖

前置過濾器，以及它何時更快

交叉點位於何處

四種解決方法

相關文章

問題不在於 API，而在於差異性

你所選擇的各層抽象

能力探測器

與黃金參考值進行驗證

針對等級而非裝置進行設計

你實際會遇到的失敗情況

相關文章

選擇就是全部的工作

正確輸出從哪裡來

清理而不壓扁分布

兩個洩漏陷阱

分割後的近似重複洩漏

時間洩漏

沒人注意到的回饋迴路

格式化與損失遮罩

相關文章