RAG 的最後一塊拼圖：為什麼找到了還不夠，還要「重新評分」？
整理版優先睇
RAG 最後一塊拼圖：檢索之後一定要做重排序，否則模型容易答非所問。
呢篇文章係 context-engineering 系列嘅第五篇，亦係收官篇。作者引用咗 h4vzz/awesome-ai-agent-skills 倉庫入面嘅 context-retrieval SKILL.md，想拆解一個普遍問題：好多 RAG 系統跳過重排序，搞到檢索到嘅內容表面相關但答非所問。佢嘅整體結論係：RAG 要穩定，唔可以只靠向量搜索，一定要加返重排序、混合檢索、合理切塊，同埋處理好邊緣情況。最終上限唔係技術，而係你對問題嘅理解。
作者指出，大部份人以為 RAG 得三步「儲存→檢索→生成」，但其實完整流程有六步，最常被省略嘅就係第三步「重排序」。呢個省略係 RAG 質量唔穩定嘅最大原因。向量相似度只係捕捉語義方向，唔等於直接回答問題，所以需要用 cross-encoder 做二次篩選。另外，混合檢索（BM25 + 向量搜索）喺生產環境係標準做法，因為兩者互補。切塊策略都要因應唔同場景揀，冇一招打天下。
文章仲提醒咗幾個邊緣情況：檢索分數低過 threshold 時要承認唔識答，而唔係亂答；文檔矛盾時要列出分歧，唔好靜默揀一個；文檔過期問題要靠時間戳元數據處理。總括嚟講，context-engineering 嘅五個 Skill 各有定位，缺一不可。
- 重排序係 RAG 穩定嘅關鍵，必須做：先向量搜索揾 top-20，再用 cross-encoder 篩出 top-5。
- 向量相似度只睇語義方向，容易誤判；cross-encoder 先真正比較查詢同文檔嘅相關性。
- 混合檢索（BM25 + 向量搜索）喺生產環境係標準，因為精確術語同語義查詢可以互補。
- 設定檢索分數下限，寧願唔答都唔好亂答；矛盾文檔要暴露分歧，等用戶判斷。
- 切塊策略要因應內容類型調整：法律合同用大塊加摘要，代碼庫用函數級切分，FAQ 幾乎唔使切。
內容片段
用戶提問 ↓① 嵌入查詢（Query Embedding） 把自然語言問題轉成向量 ↓② 向量搜索（ANN Search） 在向量數據庫裏找最相近的 top-k 候選，k = 10～20 ↓③ 重排序（Reranking）← 這一步最常被省掉 用 cross-encoder 對候選精細評分，保留 top-n，n = 3～5 ↓④ 組裝上下文（Context Assembly） 拼接成提示詞，加上來源元數據（文件路徑/URL/頁碼） ↓⑤ 生成回答（LLM Generation） 指示模型「只基於提供的上下文回答」 ↓⑥ 驗證與引用（Validate & Cite） 檢查答案是否真的來自檢索到的內容RAG 嘅完整流程：六步唔可以少
好多人以為 RAG 就係「存文檔、揾相似、塞畀模型」，但其實完整流程有六步。呢篇文章拆解嘅就係第三步 重排序，呢步最常被省略，卻係質素唔穩定嘅最大原因。
- 1 用戶提問 → 嵌入查詢（把問題轉成向量）
- 2 向量搜索（ANN Search）揾 top-k 候選，k = 10～20
- 3 重排序（Reranking）— 用 cross-encoder 精細評分，保留 top-n，n = 3～5
- 4 組裝上下文（Context Assembly）— 加埋來源元數據
- 5 生成回答（LLM Generation）— 指示模型只基於提供的上下文回答
- 6 驗證與引用（Validate & Cite）— 檢查答案係咪真係嚟自檢索內容
點解「揾到」唔等於「揾啱」？
向量相似度（cosine similarity）有個根本缺陷：查詢同文檔分開編碼，最後先比較，所以向量只反映 語義方向，唔係「呢段文字有冇直接回答問題」。例如查「退款政策」，候選 A（0.87）講「申請報銷」反而得分高過真正講退款嘅候選 B（0.82）。
常用嘅 cross-encoder 方案包括 Cohere Rerank API（商用穩定）、bge-reranker-large（開源中英文掂）同 ColBERT（低延遲）。
混合檢索：一加一大過二
SKILL.md 明確建議：Use hybrid retrieval in production——結合 BM25 關鍵詞搜索同向量搜索，表現 consistently 好過用任何一種。
向量搜索擅長理解語義，例如「點樣更新密碼」可以揾到「修改登錄憑據嘅步驟」；但遇到 JWT_SECRET 呢啲技術術語，BM25 反而更準。現實場景兩類查詢混合出現，所以要用加權融合（例如 0.7 向量分 + 0.3 BM25 分）。
切塊策略：基礎設施決定成敗
文檔切塊嘅方式直接影響檢索效果。SKILL.md 列出三種常見策略：
- 固定 token 窗口：256-512 token 切一塊，重疊 10-20%，簡單但可能切斷句子。
- 句子邊界切分：喺句號/段落位切，保證完整性，但塊大小唔均勻。
- 遞歸字符切分：按段落→句子→字符自適應，目前工程常用。
呢度有個 權衡：塊越細檢索精度越高，但上下文太碎；塊越大上下文完整，但相關性被稀釋。最優解視乎領域：法律合同用大塊加摘要，代碼庫用函數級切分，FAQ 幾乎唔使切。
邊緣情況處理：唔講你可能永遠唔知
當所有候選相關性分數低過某個 閾值（例如 0.5），SKILL 建議直接話揾唔到答案，而唔係硬塞最高分嗰條。唔設閾值係一個沉默嘅設計缺陷，用戶見模型答咗，但以為合理。
如果兩段文檔互相矛盾（退款期 7 日 vs 14 日），應該 同時呈現分歧，而唔係等模型自己揀。因為模型揀嘅理據係 token 順序同訓練偏差，唔係業務判斷。
文檔過期問題要靠 時間戳元數據：儲存 embedding 時記低創建時間同修改時間，檢索時優先揀更新嘅文檔。呢個做法基本但好多系統都冇做。
尾聲：context-engineering 嘅五個 Skill 分別處理 「揾啱未」「留精華未」「夠短未」「順序啱未」「塞入去未」。最終上限唔係算法，而係你對問題嘅理解。
你有冇遇過呢種情況——
幫 AI 駁咗公司嘅知識庫，滿心期待佢可以回答「我哋嘅退款政策係咩」，結果佢同你背咗段「點樣申請報銷」嘅流程。唔係亂講，係真嘅檢索到咗——只係檢索到睇落相關但其實答非所問嘅內容。
呢個唔係 LLM 嘅問題，亦都唔係知識庫入面冇答案。問題係出喺 RAG 管道嘅一個被嚴重低估嘅環節：檢索之後，揀邊幾條。
呢篇係 context-engineering 系列嘅第五篇，都係收官篇。我哋已經傾過點樣壓縮、點樣排序、點樣優化、點樣注入——今日傾最底層嗰一步：資訊係點樣被揾出嚟，又係點樣被錯過嘅。
素材來源：h4vzz/awesome-ai-agent-skills 倉庫，context-engineering/context-retrieval/SKILL.md（截至 2026 年 5 月）。
一次檢索背後發生咗啲咩
大多數人對 RAG 嘅理解係：「將文檔存入向量資料庫，查詢時揾最相似嘅幾條，塞畀模型。」
呢個理解冇錯，但係少咗兩個關鍵環節。
完整嘅 6 步流程係咁樣：
用戶提問
↓
① 嵌入查詢（Query Embedding）
把自然語言問題轉成向量
↓
② 向量搜索（ANN Search）
在向量數據庫裏找最相近的 top-k 候選，k = 10～20
↓
③ 重排序（Reranking）← 這一步最常被省掉
用 cross-encoder 對候選精細評分，保留 top-n，n = 3～5
↓
④ 組裝上下文（Context Assembly）
拼接成提示詞，加上來源元數據（文件路徑/URL/頁碼）
↓
⑤ 生成回答（LLM Generation）
指示模型「只基於提供的上下文回答」
↓
⑥ 驗證與引用（Validate & Cite）
檢查答案是否真的來自檢索到的內容
見到第③步未？大多數入門教程直接由②跳到④，將重排序成個慳咗。 呢個省略，係 RAG 質量唔穩定嘅最大原因之一。
點解「揾到咗」唔等於「揾啱咗」
向量相似度（cosine similarity）係一個非常好用但有根本性缺陷嘅評分方式。
佢嘅工作原理係：將查詢同文檔分別編碼成向量，計兩個向量之間嘅夾角餘弦值。呢個過程係獨立編碼——查詢同文檔各自為政，最後先比較。
呢個帶嚟一個隱患：向量表示嘅係語義嘅整體方向，而唔係「呢段文字係咪直接回答咗呢個問題」。
一個具體嘅例子：
“查詢：「我哋嘅退款政策係咩？」
候選 A（餘弦相似度 0.87）：「申請報銷時，需要附上原始發票……」 候選 B（餘弦相似度 0.82）：「根據服務協議第 7 條，付款後 14 天內可申請全額退款……」
候選 A 得分更高，因為「退款」「申請」呢啲詞同「報銷」「申請」嘅語義空間好接近。但係顯然候選 B 先至係真正嘅答案。
呢個就係點解 Skill 嘅 Best Practices 入面第一條就係：Always rerank。
重排序：第二次審判
重排序用嘅係 cross-encoder 模型，同嵌入模型嘅工作方式完全唔同。
嵌入模型（bi-encoder）：查詢同文檔分開編碼，速度快，適合喺百萬級文檔入面初篩。
Cross-encoder 模型：將查詢同候選文檔拼埋一齊輸入模型，讓 Transformer 嘅 attention 機制喺兩者之間充分交互，輸出一個精細嘅相關性分數。精度遠高過餘弦相似度，但計算量都大得多。
呢個就係點解要分兩步：先用向量搜索快速縮細範圍（20 條），再用 cross-encoder 精細評分（揀出 5 條）。
將 20 個候選全部用 cross-encoder 打一次分，係完全可以接受嘅計算量。將成個知識庫都過一次 cross-encoder？咁就太慢啦。
常用嘅 cross-encoder 方案：Cohere Rerank API（商用，效果穩定）、bge-reranker-large（開源，中英文都唔錯）、ColBERT（更複雜，但支援後期交互，延遲低）。
混合檢索：一加一點解大過二
除咗重排序，仲有一個同樣被低估嘅設計決策：唔好淨係用向量搜索。
Skill 入面講得好直接：
“Use hybrid retrieval in production — combining BM25 keyword search with semantic vector search consistently outperforms either approach alone.
呢條建議嘅背後邏輯好有意思：
向量搜索擅長理解語義。「點樣更新密碼」可以揾到「修改登錄憑據嘅步驟」——即使一個字都唔匹配。 BM25（關鍵詞搜索）擅長精確匹配。當用戶查「JWT_SECRET」「ON DELETE RESTRICT」呢類技術術語時，BM25 反而比向量搜索準好多——因為呢啲詞喺向量空間入面可能同好多無關內容距離好近。
現實場景往往係兩類查詢混合出現嘅。純向量搜索會喺精確術語查詢上翻車，純 BM25 會喺語義查詢上翻車。混合檢索用加權融合（例如 0.7 × 向量分 + 0.3 × BM25 分）將兩者結合，先至係生產環境嘅標準做法。
切塊策略：被忽視嘅基礎設施
喺向量搜索可以揾到正確內容之前，文檔要先被切好塊。
Skill 列出咗三種常見切塊策略：
固定 token 窗口：每 256～512 個 token 切一塊，相鄰塊有 10～20% 嘅重疊。優點係簡單可控；缺點係可能喺句子中間切斷，破壞上下文。
句子邊界切分：喺句號/段落處切，保證每塊內容完整。精度更高，但塊大小不均勻，對 token 預算唔友好。
遞歸字符切分：先按段落切，太長就按句子切，仲太長再按字符切。係一種自適應策略，目前喺工程實踐中用得最多。
呢度有個對立嘅權衡關係，值得專門諗一次：
“塊越細 → 檢索精度越高（因為每塊更聚焦），但上下文越碎，模型可能拎到嘅係一個冇前後文嘅「孤立事實」。 塊越大 → 上下文更完整，但相關性評分被稀釋，一塊入面夾雜住一堆無關內容。
最優解依賴你嘅領域同查詢類型。長文檔知識庫（例如法律合同、技術文檔）通常用大塊 + 摘要；代碼庫通常用函數級別嘅切分；FAQ 就幾乎唔需要切。冇放諸四海而皆準嘅答案。
Edge Cases：唔講你可能永遠唔知
檢索分數低過閾值：唔答好過亂答
當所有候選嘅相關性分數都低過某個閾值（例如 0.5）時，Skill 嘅建議係：讓 Agent 承認自己揾唔到答案，而唔係將最高分嗰條硬塞入去。
呢個聽落顯而易見，但默認實現往往唔係咁樣——大多數 RAG 管道會無條件取 top-k，唔理嗰個「最好嘅」結果有幾爛。結果係模型用自信嘅語氣將一段唔相關嘅內容「發揮」成咗看似合理嘅答案。
唔設閾值係一個沉默嘅設計缺陷。用戶見到嘅係「答咗」，唔會意識到答案係基於錯誤嘅檢索生成嘅。
矛盾來源：暴露分歧，唔好靜默揀一個
如果兩段檢索到嘅文檔互相矛盾——一個話退款期係 7 日，另一個話係 14 日——Skill 嘅建議係將兩種講法都呈現畀用戶，並標註分歧，而唔係讓模型自己決定信邊個。
因為模型「自己決定」嘅依據係 token 順序同訓練偏差，唔係你想要嗰個業務判斷。呢種分歧通常意味住文檔需要更新，將決策權還畀用戶先至係正確嘅處理方式。
過期內容：時間戳係元數據嘅一等公民
知識庫入面嘅文檔係有生命週期嘅。3 個月前嘅產品價格表、舊年嘅 API 文檔——如果冇時間戳元數據，檢索系統冇任何辦法知道呢啲內容可能已經過期。
Skill 嘅建議：喺存儲 embedding 時將文檔嘅創建時間同修改時間一併寫入元數據，檢索時優先揀分數相近但更新嘅文檔。
呢條建議睇落基礎，但真正做咗嘅 RAG 系統唔多。
context-engineering 系列橫向對比
呢篇係系列最後一篇，簡單回顧一下五個 Skill 喺完整 RAG 管道入面嘅位置：
原始文檔庫
↓
[context-retrieval] ← 本篇
嵌入 → 向量搜索 → 重排序 → 初步候選集
↓
[context-optimization]
去重 → 密度評分 → 覆蓋度驗證 → 精簡候選集
↓
[context-compression]
語義壓縮 → 減少 token 佔用
↓
[context-ranking]
最終排序 → 重要內容放首尾
↓
[context-injection]
token 預算分配 → 注入到 prompt → 分隔符設計
↓
LLM 生成回答
每個 Skill 解決嘅問題係唔同嘅。retrieval 關心「揾啱咗未」，optimization 關心「留低嘅係精華嗎」，compression 關心「可唔可以更短」，ranking 關心「讀嘅順序啱唔啱」，injection 關心「點樣塞入去」。
一個完整嘅 context-engineering 管道需要呢五個環節全部到位，缺任何一塊都會喺唔同場景下翻車。
尾聲：RAG 嘅上限唔係檢索，係你對問題嘅理解
做完呢五篇，我意識到一件事：context-engineering 嘅每一個 Skill，本質上都在回答同一個問題——「咩資訊值得佔用有限嘅 context window？」
呢個問題嘅答案，最終唔係靠算法畀出嚟嘅。
相關性分數可以話畀你知「餘弦距離最近嘅係邊條」，密度評分可以話畀你知「資訊量最大嘅係邊塊」，重排序可以畀你更精準嘅排名——但邊個問題值得問、知識庫入面應該有啲咩內容、咩場景下「揾唔到」比「亂揾」更安全，呢啲判斷需要真正理解業務嘅人嚟做。
所有嘅 Skill 都係喺幫你更有效地執行。但咩值得被檢索，仲係需要你先諗清楚。
你有沒有遇到過這種情況——
給 AI 接上了公司的知識庫，滿心期待它能回答「我們的退款政策是什麼」，結果它給你背了一段「如何申請報銷」的流程。不是亂說，是真的檢索到了——只是檢索到了看起來相關但其實答非所問的內容。
這不是 LLM 的問題，也不是知識庫裏沒有答案。問題出在 RAG 管道的一個被嚴重低估的環節：檢索之後，選哪幾條。
這是 context-engineering 系列的第五篇，也是收官篇。我們已經聊過怎麼壓縮、怎麼排序、怎麼優化、怎麼注入——今天聊最底層的那一步：信息是怎麼被找出來的，又是怎麼被錯過的。
素材來源：h4vzz/awesome-ai-agent-skills 倉庫，context-engineering/context-retrieval/SKILL.md（截至 2026 年 5 月）。
一次檢索背後發生了什麼
大多數人對 RAG 的理解是：「把文檔存進向量數據庫，查詢時找最相似的幾條，塞給模型。」
這個理解沒錯，但少了兩個關鍵環節。
完整的 6 步流程是這樣的：
用戶提問
↓
① 嵌入查詢（Query Embedding）
把自然語言問題轉成向量
↓
② 向量搜索（ANN Search）
在向量數據庫裏找最相近的 top-k 候選，k = 10～20
↓
③ 重排序（Reranking）← 這一步最常被省掉
用 cross-encoder 對候選精細評分，保留 top-n，n = 3～5
↓
④ 組裝上下文（Context Assembly）
拼接成提示詞，加上來源元數據（文件路徑/URL/頁碼）
↓
⑤ 生成回答（LLM Generation）
指示模型「只基於提供的上下文回答」
↓
⑥ 驗證與引用（Validate & Cite）
檢查答案是否真的來自檢索到的內容
看到第③步了嗎？大多數入門教程直接從②跳到④，把重排序整個省掉了。 這個省略，是 RAG 質量不穩定的最大原因之一。
為什麼「找到了」不等於「找對了」
向量相似度（cosine similarity）是一個非常好用但有根本性缺陷的評分方式。
它的工作原理是：把查詢和文檔分別編碼成向量，算兩個向量之間的夾角餘弦值。這個過程是獨立編碼——查詢和文檔各自為政，最後才比較。
這帶來一個隱患：向量表示的是語義的整體方向，而不是「這段文字是否直接回答了這個問題」。
一個具體的例子：
“查詢：「我們的退款政策是什麼？」
候選 A（餘弦相似度 0.87）：「申請報銷時，需要附上原始發票……」 候選 B（餘弦相似度 0.82）：「根據服務協議第 7 條，付款後 14 天內可申請全額退款……」
候選 A 得分更高，因為「退款」「申請」這些詞和「報銷」「申請」的語義空間很接近。但顯然候選 B 才是真正的答案。
這就是為什麼 Skill 的 Best Practices 裏第一條就是：Always rerank。
重排序：第二次審判
重排序用的是 cross-encoder 模型，和嵌入模型的工作方式完全不同。
嵌入模型（bi-encoder）：查詢和文檔分開編碼，速度快，適合在百萬級文檔裏初篩。
Cross-encoder 模型：把查詢和候選文檔拼在一起輸入模型，讓 Transformer 的 attention 機制在兩者之間充分交互，輸出一個精細的相關性分數。精度遠高於餘弦相似度，但計算量也大得多。
這就是為什麼要分兩步：先用向量搜索快速縮小範圍（20 條），再用 cross-encoder 精細評分（選出 5 條）。
把 20 個候選全部用 cross-encoder 打一遍分，是完全可以接受的計算量。把整個知識庫都過一遍 cross-encoder？那就太慢了。
常用的 cross-encoder 方案：Cohere Rerank API（商用，效果穩定）、bge-reranker-large（開源，中英文都不錯）、ColBERT（更復雜，但支持後期交互，延遲低）。
混合檢索：一加一為什麼大於二
除了重排序，還有一個同樣被低估的設計決策：不要只用向量搜索。
Skill 裏說得很直接：
“Use hybrid retrieval in production — combining BM25 keyword search with semantic vector search consistently outperforms either approach alone.
這條建議的背後邏輯很有意思：
向量搜索擅長理解語義。「怎麼更新密碼」能找到「修改登錄憑據的步驟」——即使一個字不匹配。 BM25（關鍵詞搜索）擅長精確匹配。當用戶查「JWT_SECRET」「ON DELETE RESTRICT」這類技術術語時，BM25 反而比向量搜索準得多——因為這些詞在向量空間裏可能和很多無關內容距離很近。
現實場景往往是兩類查詢混合出現的。純向量搜索會在精確術語查詢上翻車，純 BM25 會在語義查詢上翻車。混合檢索用加權融合（比如 0.7 × 向量分 + 0.3 × BM25 分）把兩者結合，才是生產環境的標準做法。
切塊策略：被忽視的基礎設施
在向量搜索能找到正確內容之前，文檔得先被切好塊。
Skill 列出了三種常見切塊策略：
固定 token 窗口：每 256～512 個 token 切一塊，相鄰塊有 10～20% 的重疊。優點是簡單可控；缺點是可能在句子中間切斷，破壞上下文。
句子邊界切分：在句號/段落處切，保證每塊內容完整。精度更高，但塊大小不均勻，對 token 預算不友好。
遞歸字符切分：先按段落切，太長則按句子切，還太長再按字符切。是一種自適應策略，目前在工程實踐中用得最多。
這裏有個對立的權衡關係，值得專門想一遍：
“塊越小 → 檢索精度越高（因為每塊更聚焦），但上下文越碎，模型可能拿到的是一個沒有前後文的「孤立事實」。 塊越大 → 上下文更完整，但相關性評分被稀釋，一塊裏夾雜着一堆無關內容。
最優解依賴你的領域和查詢類型。長文檔知識庫（比如法律合同、技術文檔）通常用大塊 + 摘要；代碼庫通常用函數級別的切分；FAQ 則幾乎不需要切。沒有放之四海而皆準的答案。
Edge Cases：不說你可能永遠不知道
檢索分數低於閾值：不答比亂答好
當所有候選的相關性分數都低於某個閾值（比如 0.5）時，Skill 的建議是：讓 Agent 承認自己找不到答案，而不是把最高分的那條硬塞進去。
這聽起來顯而易見，但默認實現往往不是這樣的——大多數 RAG 管道會無條件取 top-k，不管那個「最好的」結果有多爛。結果是模型用自信的語氣把一段不相關的內容「發揮」成了看似合理的答案。
不設閾值是一個沉默的設計缺陷。用戶看到的是「答了」，不會意識到答案是基於錯誤的檢索生成的。
矛盾來源：暴露分歧，不要靜默選一個
如果兩段檢索到的文檔互相矛盾——一個說退款期是 7 天，另一個說是 14 天——Skill 的建議是把兩種說法都呈現給用戶，並標註分歧，而不是讓模型自己決定信哪個。
因為模型「自己決定」的依據是token順序和訓練偏差，不是你想要的那個業務判斷。這種分歧通常意味着文檔需要更新，把決策權還給用戶才是正確的處理方式。
過期內容：時間戳是元數據的一等公民
知識庫裏的文檔是有生命週期的。3 個月前的產品價格表、去年的 API 文檔——如果沒有時間戳元數據，檢索系統沒有任何辦法知道這些內容可能已經過期。
Skill 的建議：在存儲 embedding 時把文檔的創建時間和修改時間一併寫入元數據，檢索時優先選擇分數相近但更新的文檔。
這條建議看起來基礎，但真正做了的 RAG 系統不多。
context-engineering 系列橫向對比
這是系列最後一篇，簡單回顧一下五個 Skill 在完整 RAG 管道里的位置：
原始文檔庫
↓
[context-retrieval] ← 本篇
嵌入 → 向量搜索 → 重排序 → 初步候選集
↓
[context-optimization]
去重 → 密度評分 → 覆蓋度驗證 → 精簡候選集
↓
[context-compression]
語義壓縮 → 減少 token 佔用
↓
[context-ranking]
最終排序 → 重要內容放首尾
↓
[context-injection]
token 預算分配 → 注入到 prompt → 分隔符設計
↓
LLM 生成回答
每個 Skill 解決的問題是不同的。retrieval 關心「找對了嗎」，optimization 關心「留下來的是精華嗎」，compression 關心「能不能更短」，ranking 關心「讀的順序對嗎」，injection 關心「怎麼塞進去」。
一個完整的 context-engineering 管道需要這五個環節全部到位，缺任何一塊都會在不同場景下翻車。
尾聲：RAG 的上限不是檢索，是你對問題的理解
做完這五篇，我意識到一件事：context-engineering 的每一個 Skill，本質上都在回答同一個問題——「什麼信息值得佔用有限的 context window？」
這個問題的答案，最終不是靠算法給出的。
相關性分數可以告訴你「餘弦距離最近的是哪條」，密度評分可以告訴你「信息量最大的是哪塊」，重排序可以給你更精準的排名——但哪個問題值得問、知識庫裏應該有什麼內容、什麼場景下「找不到」比「亂找」更安全，這些判斷需要真正理解業務的人來做。
所有的 Skill 都是在幫你更有效地執行。但什麼值得被檢索，還是需要你先想清楚。