Day 0８把重複紀錄整理成較穩定的研究單位後，搜尋清單看起來更可信了。但下一層問題更棘手：清單裡有資料，題名也看得到使用者輸入的字，整體卻沒有牢牢回答原來的研究問題。

2026 年 6 月 26 日的專案進度紀錄留下了這個未解風險：部分題目經過 topic expansion 再送進來源搜尋時，泛化敘述仍可能混入 query；同時，外部 provider 也可能 timeout、遭遇 rate limit 或直接失敗。[1] 這兩種問題會在同一張結果頁相遇，卻不能用同一種方式修。

完全搜不到通常會亮紅燈。最難除錯的反而是「有結果」：每筆單看都像相關，讓人很容易把候選數量誤認成搜尋品質。

四種失敗，不能都叫做「資料太少」

我後來先把症狀拆開。第一種是 query 沒有保留題目的核心概念，所以從一開始就搜歪。第二種是 query 沒問題，但某個 provider 沒有正常回來。第三種是確實取得候選，排序後卻只剩背景上沾邊的材料。第四種則是來源看似相關，品質或內容仍不足以交給後續流程。

這四種失敗可能都顯示成「結果不理想」，修法卻完全不同。第一種要回頭檢查題目理解與 query；第二種要處理 provider 狀態、重試或降級；第三種要查 relevance 判斷；第四種才是來源審查與後續證據整理的問題。

如果系統只回傳一個總數，這些差異會被抹平。同樣數量的候選，可能來自健康的學術來源，也可能是在部分服務失敗後由較寬鬆路徑補出的結果。兩者即使卡片數相同，也不是相同的搜尋狀態。

Fallback 最危險的時刻，是它看起來成功

當高品質來源不足時，加入 fallback 很合理。早期 ResearchForge 也把搜尋分成不同來源群組，並在較前面的結果不足時繼續嘗試其他路徑；6 月 22 日前後的修改持續處理 domain-aware grouping、fallback diagnostics 與結果合併。[2]

問題在於，fallback 會同時改變兩件事：它增加召回，也可能放寬語意範圍。若題目原本要求特定研究對象、情境與結果，較寬的 query 可能只保留其中一部分。標題裡仍有熟悉的字，文章也確實屬於相近領域，但研究問題已經悄悄換掉。

因此，fallback 不能只留下「最後有幾筆」。至少要知道哪一條 query、哪一類來源路徑產生這筆候選，前面的 provider 是否失敗，以及這次結果為什麼被保留。診斷不是開發者模式裡可有可無的雜訊，而是判斷結果能否被正確解讀的上下文。

這裡還有一個很容易混淆的界線。當時的進度紀錄寫的是：provider 失敗或高品質來源不足時，保留低信心候選供人審查，而不是讓畫面靜默歸零。[1] 「保留」只代表仍值得查看，不代表已經接受，更不代表可以直接寫進報告。Fallback 解決的是可觀察性與召回問題，不會替候選取得證據資格。

Relevance 需要理由，不只需要排名

相關性分數可以幫清單排序，但單一總分很難回答「為什麼這篇在這裡」。一篇來源可能因題名命中熱門字而排得很前面，卻缺少研究對象；另一篇題名較廣，摘要反而包含真正的 outcome。若只看最後分數，調整權重時很容易修好一個題目，又讓另一個領域失真。

我會把可檢查資訊分成三層。第一層是題目錨點：研究對象、情境、核心變項是否仍在。第二層是命中與缺口：哪些必要概念出現，哪些只出現在背景詞裡，是否碰到排除條件。第三層才是排序：在前兩層理由保留下來後，分數只負責決定審查順序。

這不是要求每個一般使用者閱讀完整 debug trace。介面可以只顯示簡短原因，但系統內部必須保留足以重建決定的資料。否則當結果離題時，我只能看到「分數不夠好」，卻不知道問題出在 query、provider、必要概念，還是某個過度寬鬆的 fallback。

固定筆數會製造錯誤的完成感

搜尋產品很容易訂一個目標：無論如何都要交出若干筆結果。這個目標對畫面完整度有幫助，對研究正確性卻可能有害。當候選不足時，系統若只為填滿清單而持續放寬條件，最後的每筆資料都可能「有一點相關」，合起來仍無法回答原題。

2026 年 7 月 6 日，專案提交開始明確收緊來源搜尋的時間與工作預算，並在整體時間不足時保留部分結果與降級訊息。[3] 這能支持的結論很有限：當時已經把搜尋成本與 fallback 當成工程問題；它還不是後來那種能逐次管住所有外部操作的完整權限機制。

即使如此，這一步仍改變了我的判準。搜尋的停止條件不能只有「湊滿」，還要包括時間已到、provider 已降級、剩餘 query 只會繼續放寬，以及目前結果只能交給人工複核。少而誠實的候選，比數量漂亮但來源狀態不明的清單更有用。

我現在先找第一個失真的位置

面對看似合理的離題結果，我不再先調一個全域門檻，而是按照可觀察症狀往回查：

這張表是我依歷史問題整理出的除錯方法，不是 2026 年 6 月已完成驗收的產品功能。它的價值在於先固定失真的位置，避免用增加 query、降低門檻或更換 Writer 去掩蓋前一層問題。

人工審查不是替演算法收拾殘局

保留低信心候選的目的，是讓人能看到系統不確定在哪裡，而不是把未整理的清單全部丟給使用者。機器仍應先完成可重複的工作：整理來源身分、標示查詢來歷、保留 provider 狀態、說明命中與缺口，並把明顯離題項目和待複核項目區分開。

人的工作則是判斷語意邊界。例如，一篇 review 可能很適合建立背景，卻不能回答特定介入的效果；一篇研究可能方法相近，研究對象卻不同。這種角色判斷無法由「題名出現幾個字」取代，也不能因人工按下接受，就假裝來源裡原本缺少的內容已經存在。

所以，一個好的 relevance 系統不只是把最好看的結果排到前面。它還要讓錯誤容易被看見：題目在哪裡漂移、哪個 provider 沒回來、哪條 fallback 擴大了範圍，以及為什麼這筆資料仍只是一個待審候選。

到這裡，ResearchForge 才得到一批身分較清楚、相關性也有理由可查的來源。但「這篇在談相近問題」仍不等於「我可以根據它寫出某個主張」。Day 10 會繼續處理這個落差：為什麼 Evidence Card 不能只是把摘要縮成兩句。

參考資料

[1] ResearchForge 專案進度紀錄，2026 年 6 月 26 日：搜尋 payload 對齊、低信心待審候選、provider degradation 與 query sanitation 的已知風險。

[2] ResearchForge 專案歷史，2026 年 6 月 22 日：domain-aware source grouping、fallback diagnostics、來源合併與 relevance 路徑的連續修訂。

[3] ResearchForge 專案歷史，2026 年 7 月 6 日：來源搜尋時間預算、部分結果與 deterministic fallback 訊息的收斂。