2026 年 6 月 17 日，ResearchForge 出現一個方向很明確的重構：不要再把來源卡依序貼進報告。程式開始先讀大綱段落的用途，再挑選標記為研究背景、文獻探討、研究方法、數據分析或結論的 Evidence Card。[1]

但我沿著同一版程式往下看，馬上遇到更值得寫的細節：selectEvidenceForSection 先從原陣列篩出符合章節用途的卡，再取前四張。報告的外框不再由來源順序決定，同一章節實際拿到哪些材料，仍可能受輸入順序影響。

這就是 synthesis（跨來源綜合）最容易被低估的地方。把資料分進章節，只是停止逐篇貼摘要的第一步；真正的綜合還要回答：每段正在處理哪個研究問題、哪些材料可以比較、它們究竟一致還是衝突，以及缺口是否被保留下來。

從「來源順序」改成「章節任務」

重構前，草稿產生器會先把 Evidence Cards 分成幾個固定用途，再為背景、文獻、方法、資料與結論拼出預設段落。6 月 17 日的版本把這件事改成 ReportSynthesisContext 與 SectionPlan：大綱先定義段落目的，card 的 usableSections 再決定能否成為該段的材料。[1]

當時的核心選擇可以濃縮成這段原碼：

export function selectEvidenceForSection(
  evidenceCards: EvidenceCard[],
  sectionId: string,
): EvidenceCard[] {
  return cardsFor(evidenceCards, SECTION_EVIDENCE_MAP[sectionId] ?? []).slice(0, 4);
}

這段程式解決了「來源 A 一段、來源 B 一段」的表面結構。固定資料測試也確認：文獻段不再直接出現卡片的泛化 claim，資料段會依背景與數據面向組織，討論段會保留資料缺口。[1]

進步是真實的，範圍也要說清楚。usableSections 只表示一張卡適合放在哪類章節，不等於它已回答該章的具體問題；slice(0, 4) 也沒有比較研究設計、主張方向或證據強弱。這個版本建立了 section-aware selection，尚未完成 question-aware synthesis。

換句話說，章節先於來源，是必要的方向修正；問題先於材料，才是下一道真正的判斷。

把卡片分組，不等於建立論證

以「短影音與睡眠」為例，三張卡可能分別談使用時間、睡眠品質與年齡差異。若都被標成「文獻探討」，系統知道它們可以進同一章，仍不知道哪張回答現象、哪張處理可能機制、哪張只能補充限制。

因此，段落生成前至少還需要一個問題層：先把研究問題拆成可檢查的子問題，再把 card 對到它能支持的那一格。來源很多，只代表候選材料多；只有當重要子問題都有對應材料，coverage（問題覆蓋）才開始有意義。

這也改變了我對大綱的理解。大綱不只是標題清單，而是查詢證據的介面。「研究背景」太寬，幾乎什麼都能放；「使用時間與睡眠品質是否相關」才會迫使系統檢查族群、暴露、結果與研究設計是否對得上。

同一個 facet，不代表研究已有共識

6 月 18 日新增的 accepted-source synthesis helper 又往前一步。它只把非 weak 的 evidence snippet 放入主要主張；來源沒有可驗證片段時，不產生主要主張，而是留下限制。材料也會依成因、現況、數據背景、影響、政策與限制等 facet 分組。[2]

這個 helper 同時暴露了第二個風險：只要至少兩個不同來源落在同一 facet，程式就會產生「多筆來源共同支撐某面向」的句子。[2] 但同屬「影響分析」的研究，可能使用不同族群、不同 outcome，甚至得到相反方向的結果。共同覆蓋一個面向，不等於共同支持同一個結論。

更具體地說，當時的 facet patterns 明顯偏向氣候題目，例如溫室氣體、升溫、海平面與調適；無法命中的內容預設落入「數據背景」。[2] 這套規則適合當時的示範材料，不能直接被描述成可泛化到所有研究問題的 synthesis。

我在這裡學到的是：分桶是索引，論證才是綜合。要說「多篇一致」，至少要確認它們支持的是同一個可比較主張，而不只是共享一個寬泛標籤。

Coverage 要看問題格子，不看來源總數

若要避免把來源數量誤當完成度，我會把大綱改寫成一張簡單的 evidence matrix。橫向不是來源出現順序，而是研究問題；每一格只記錄能直接回答該問題的 card，以及目前狀態。

這張表是我根據早期實作缺口整理的設計方法，不是宣稱當時產品已經有完整 matrix。它的用途是把「蒐集了多少來源」換成「哪些問題已被什麼材料回答」。如果一個關鍵格子仍空著，再多同類摘要也不會自動補上答案。

Writer 能檢查 ID，仍未必理解支持關係

6 月 20 日，報告 Writer 服務進入 committed flow。它接收 accepted sources 與 Evidence Cards，要求各段回傳 evidence card IDs 與 citation IDs；回傳結果若引用未接受的來源或不存在的 card，程式會把那些 ID 過濾掉。[3]

這是一條必要的身分邊界，卻不是語意驗證。ID 合法只能證明段落指向輸入集合內的材料，不能證明句子真的由那張卡支持。當時主要依賴 prompt 要求模型不要捏造統計、作者、網址、DOI 或引用，也要求避免逐張貼卡；程式尚未逐句比較 prose 與 evidence 的支持關係。[3]

所以 synthesis 不能全交給 Writer 的流暢度。上游若把不同主張錯分成共識，或把背景材料塞進結果格，Writer 即使只引用合法 ID，仍可能寫出形式正確、研究意義錯位的段落。

一個可以帶到其他 RAG 專案的測試

我會用兩個問題檢查多文件生成系統。第一，把來源順序打亂後，核心子問題、材料選擇與結論方向是否維持一致？引用編號可以改變，但論證不應被陣列位置接管。第二，每一個「多篇一致」能否展開成相同主張、相容條件與各自的支持材料？若只能回到共同標籤，就應降回「共同涉及此面向」。

這兩個問題不是 6 月版本已通過的驗收項目，而是從它的進步與限制推導出的實作檢查。前者找 source-order stitching，後者找 facet-as-consensus。兩者都通過，才比較接近以研究問題為中心的 synthesis。

到這一步，ResearchForge 已把 Evidence Card、章節規劃與報告 Writer 接成一條可辨識的內容路徑；它還沒有證明跨研究判讀已成熟。接下來，問題會從內容如何組織轉向系統如何被真正執行：同一套程式在本地能跑，部署平台是否找得到正確入口，將是 Day 12 的主題。

參考資料

1. ResearchForge 2026 年 6 月 17 日 report synthesis 重構與同版本固定資料測試。
2. ResearchForge 2026 年 6 月 18 日 accepted-source synthesis helper、固定資料測試與架構盤點。
3. ResearchForge 2026 年 6 月 20 日 evidence-based report flow、Writer service 與測試紀錄。