Ask AI 怎麼找到文章：Planner、Hybrid Retrieval 與 Retry

TL;DR Ask AI 先由 Planner 抽出 intent、complexity 與 1–4 個搜尋詞，再依查詢型態走 metadata、BM25、Vectorize 與 RRF；第二輪搜尋會加入 Critic gaps，並關閉第一次才允許的 BM25 short circuit。

#rag #retrieval #hybrid-search #bm25 #vector-search #rrf #langgraph

Planner 先把對話句整理成搜尋計畫
Research 組出一組真的不重複的 query variants
Post search 不是每次都跑完整 hybrid
Normalize Results 再判斷這批證據夠不夠用
跑 targeted tests，而不是猜路由
證據邊界
為什麼不直接把所有文章塞進 Long Context
更新紀錄
參考資料

系列: Ask AI 實戰 (2 / 10)

Ask AI 的文章怎麼進知識庫：Chunk、D1 FTS5 與 Vectorize Ask AI 怎麼把證據寫成答案：Writer Context 與 Citation Contract

🌏 English version

搭配閱讀（選讀）：零基礎可以直接讀本文。想先補概念，可搭配〈Hybrid Search：用 BM25 + 向量搜尋彌補彼此的盲區〉、〈RRF：RAG 系統裡多路結果怎麼合併〉與〈CRAG：檢索失敗時，自動放寬條件重試〉。

索引準備好之後，下一個問題才是「要拿什麼去查」。使用者輸入的是口語問題，BM25 想要辨識度高的詞，向量搜尋需要能表達語意的 query。列文章清單和查一個技術錯誤，也不該共用完全相同的 top-k 與 context 策略。

Ask AI 的做法不是讓一個 Agent 自由決定所有工具呼叫。它把責任拆成 Planner、Research、post search 與 result normalization。這篇沿著這四層追一次，重點是各層如何改變 query 與候選集合，不重講 BM25、embedding 或 RRF 的數學原理。

Planner 先把對話句整理成搜尋計畫

planner.ts 要模型回傳一個 JSON plan，其中包含：

intent：factual、summary、comparison、recommendation 等類型。
complexity：simple、medium 或 complex。
language：zh-TW 或 en。
needs_clarification、subtasks 與 specialists。
1–4 個去掉口語填充詞的 search_keywords。

這個 plan 會改變後面的資源配置。Recommendation 預設可以取更多文章；complex query 才可能啟用 Multi-query 或 PageIndex；simple query 不查 abstract index。若 Planner 輸出不是合法 JSON，程式會回到 factual、medium、zh-TW 的預設值，而不是讓整個請求直接失敗。

Recommendation 還會再經過 query-strategy.ts。像「幫我找」「有哪些」「文章」這些詞會被移除，讓「有哪些 RAG 評估文章」盡量用 RAG 評估 去查。Broad catalog query 則另外標記，後續可以採 metadata-only 路徑。

Research 組出一組真的不重複的 query variants

research.ts 先以原問題與 subtasks 建立 base query，再視 plan 與功能旗標加入其他版本：

一般查詢可加入 Planner 抽出的 keyword query。
retry 時若 Critic 留下 gaps，會把缺口加入新的 query。
HyDE 開啟且問題不是 simple 時，可加入假想答案。
Multi-query 開啟且問題是 complex 時，可加入多組替代問法。

最後用 Set 去重，再平行查 posts、docs 與必要的 abstract index。外部搜尋只有在 search tools 開啟，而且不是 metadata-only catalog query 時才會執行。

這裡有一個很重要的 retry 契約：第二輪不能只重播第一次的檢索。 程式會加入 Critic gaps；BM25 short circuit 也只允許在 iteration === 0。否則第一次的弱候選集很容易原封不動地回來，Writer 只是換一種講法再失敗一次。

Post search 不是每次都跑完整 hybrid

search-posts.ts 會先查文章 metadata，再查 D1 FTS5 的 BM25 結果。接著依 query 型態選路：

metadata-only catalog
  → metadata results → 依 slug 去重

precision query + BM25 至少 5 筆
  → metadata + BM25 → RRF → 依 slug 去重

其他查詢
  → metadata + BM25 + Vectorize → RRF → 依 slug 去重

D1、版本號、路徑或帶特殊符號的 identifier 會被視為 precision query。只有這類查詢在 BM25 至少回五筆且 short circuit 開啟時，才會跳過 Vectorize。一般口語查詢即使 BM25 有結果，仍會走向量 lane。

hybrid-search.ts 用 RRF 合併排名，而不是直接比較 BM25 與 cosine 的原始分數。每個 active list 依名次貢獻 1 / (60 + rank)，最後再正規化到 0–1。這個 relevance_score 是融合後的相對排名訊號，不應寫成「模型判定有 0.8 的事實相關性」。

Normalize Results 再判斷這批證據夠不夠用

Research 會把 posts、docs、abstract 與可能的外部結果合併。Recommendation 以文章為單位去重並依 postLimit 截斷；一般 factual query 則保留 chunk 粒度。

normalize-results.ts 接著統一排序分數，並用最高可比較分數是否低於 0.4 判斷 weak retrieval。若 reranker 功能開啟，它還會混合 query token overlap，並用 MMR 調整多樣性。

目前預設設定中 HyDE、Multi-query 與 reranker 都是關閉，BM25 short circuit 開啟。Repo 能支持的說法是：這些 lane 已有實作與測試。功能旗標存在，不足以證明 production 每次查詢都在使用。

跑 targeted tests，而不是猜路由

pnpm exec vitest run \
  src/lib/retrieval/agents/planner.parity.test.ts \
  src/lib/retrieval/agents/research.parity.test.ts \
  src/lib/retrieval/query-strategy.test.ts \
  src/lib/retrieval/tools/hybrid-search.test.ts

這組測試覆蓋 Planner 的輸出契約、recommendation query 清理、retry 改變檢索、article-level dedupe、result cap 與 RRF/short-circuit helper。它沒有查 production D1 或 Vectorize，也不會產生真實 ranked list。

如果要看目前預設旗標，不要從文章敘述反推，直接查程式碼：

rg -n "hydeEnabled|multiQueryEnabled|rerankerEnabled|bm25ShortCircuitEnabled" \
  src/lib/retrieval/settings.ts src/lib/retrieval/state.ts

證據邊界

這篇能證明目前程式如何組 query、何時跳過 Vectorize、如何融合與 retry。它不能從靜態程式碼推得 production 索引內容、每條 lane 的實際召回率或延遲。

更重要的是，search_results 是 Writer 的候選證據，不是「網站所有相關文章」。top-k、去重與 context window 都會讓完整母群縮小。下一篇會接著看 Writer 實際拿到多少來源，以及它為什麼只能引用候選集合裡的 URL。

為什麼不直接把所有文章塞進 Long Context

Ask AI 選擇 hybrid retrieval 而不是把全站內容塞進 long context window，這個決策背後有學術支持。Self-Route（Zhao et al., EMNLP 2024）提出按查詢類型路由：事實查找型查詢用 RAG 較精準，需要跨段落推理的查詢才值得用 long context。Ask AI 的 Planner 已經在做類似的事——intent 和 complexity 決定要走哪些 lane。

NVIDIA 的 OP-RAG（Wu et al., 2024）進一步證明，即使 context window 足夠容納所有文件，RAG 在 token 效率上仍有優勢——不需要為每次查詢付出處理整個語料庫的推理成本。Xu et al.（2024）的系統性比較則得出結論：兩者是互補而非替代關係，混合架構（小量文件塞 context + 大量文件走 retrieval）往往表現最好。

對 Ask AI 來說，目前 1,600+ 篇文章的規模即使塞得進去，每次查詢的 token 消耗也不合理。Hybrid retrieval 讓大多數查詢只需處理 top-k 的 chunk，成本與延遲都可控。

更新紀錄

2026-09-03：新增「為什麼不直接把所有文章塞進 Long Context」段落，補充 Self-Route、OP-RAG、Long Context vs RAG 三篇參考文獻

參考資料

Ask AI Planner
Research agent
Recommendation query strategy
Post search implementation
Hybrid search and RRF helpers
Result normalization
Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach (Self-Route) — Zhao et al., EMNLP 2024
In Defense of RAG in the Era of Long-Context Language Models (OP-RAG) — Wu et al., NVIDIA, 2024
Long Context vs. RAG for LLMs: An Evaluation and Revisits — Xu et al., 2024