維基百科來源評級，能幫 Cofacts.ai 挑出處嗎？

草稿只計成功送出的 draft_factcheck_response。investigator 另有 321 筆未解析的 Vertex 轉址網址不計入。命中率以 URL 筆數計，熱門媒體權重較高。

維基條目通常附有原始出處。回傳評級後，writer 比較可能改引條目背後的報導或文件，這是這次評估中最直接、量也最大的改變。

中文列表 363 筆中有 86 筆在摘要裡依主題給出不同評級。Cofacts.ai 的命中有一半落在這類條目（investigator 52%、verifier 54%、草稿 45%）。台灣主流媒體的分歧點幾乎都是政治報導，也就是 Cofacts 訊息的大宗。

「應替代」與「通常不可靠」同色是因為兩者都表示不宜作為主要佐證。自由時報草稿引用數含 news / def / health 等子網域。

所以工具不能只回傳 sr 這類代碼。需要把整段摘要交給模型，並請它依這則訊息的主題判斷適用哪一條。

在同一個 trace 裡，investigator 找到的候選出處有多少比例最後被寫進草稿：

只計有成功草稿的 trace。滑鼠移到長條上可看筆數。

可靠來源與政府網站的入選率本來就最高，「應停用」只有 5%。評級真正的增量集中在三類：

中時、聯合、三立一列是這三家所有草稿引用的總數，沒有逐篇判斷是否為政治議題。

WP:RSP 自己也說明，沒列在表上只代表沒被反覆討論過，不代表不可靠。政府、查核組織、學術期刊需要另訂規則，例如比照維基的醫學來源準則（WP:MEDRS）處理健康類訊息。LINE Today 這類轉載平台則要先追到原始媒體才能判斷。

英文列表 497 筆。它的 13% 命中大多和中文列表重疊，主要也是維基、Facebook、YouTube。只有英文列表才命中的出處，在草稿中佔 2.8%，其中「通常可靠」1.8%，包括 Guardian、Reuters、SCMP、海峽時報、Al Jazeera、JAMA。

它的優點是結構整齊：依主題分評級時直接拆成多列，例如 Fox News 的政治與非政治分開，不用解析內文。適合當國際媒體的補充，優先順序可以放後面。

1. 維基百科出處怎麼處理？

   只提示、要求改引原始出處，或由 draft_factcheck_response 驗證時擋下。

2. 如何區分「佐證」和「說法的出處」？

   FB、YouTube、官媒在 Cofacts 常是被查核的對象，提示內容需要能表達這個差別。

3. 未列來源的備援規則

   政府網站、查核組織、學術期刊、轉載平台各自怎麼處理。

4. 要不要接英文列表？

   增量約 2.8 個百分點，以國際媒體為主。

flowchart LR
  W["writer"] -->|"request"| INV
  subgraph INV["AgentTool: investigator"]
    direction LR
    I1["LlmAgent investigator<br/>google_search"] --> C1["after_model_callback<br/>append_grounding_sources"]
  end
  C1 -->|"{content, sources: [title, url]}"| N["writer after_tool<br/>_normalized_response"]
  N --> W
  W -->|"claims + URLs"| VER
  subgraph VER["AgentTool: verifier"]
    direction LR
    V1["LlmAgent verifier<br/>url_context"] --> C2["after_model_callback<br/>append_url_context_sources"]
  end
  C2 -->|"{content, sources: [title, url]}"| N

writer 可以在同一輪平行呼叫多個 investigator。每次 AgentTool 呼叫都是獨立的 in-memory session。

flowchart LR
  SYNC["每週同步工作<br/>MediaWiki API"] --> DB[("評級資料<br/>363 筆 + 摘要全文")]
  W["writer"] -->|"request"| SEQ
  subgraph SEQ["AgentTool: investigator（SequentialAgent，沿用原名）"]
    direction LR
    I1["LlmAgent investigator_search<br/>google_search<br/>output_key"] --> R0{"before_agent_callback<br/>網域比對"}
    R0 -->|"沒命中或只有單一評級"| P["直接輸出<br/>不呼叫模型"]
    R0 -->|"命中依主題分評級的條目"| R1["LlmAgent source_rater<br/>便宜模型"]
    R1 --> M["merge<br/>寫回 sources[].rating_hint"]
  end
  DB -.-> R0
  P -->|"{content, sources: [title, url, rating_hint]}"| N["writer after_tool<br/>_normalized_response"]
  M --> N
  N --> W

verifier 用同樣的結構包裝。rater 的輸入有三樣：上一個 agent 的 sources、這些來源在維基的評級全文，以及 request 原文（用來判斷主題）。輸出則是要替哪幾個來源加上提示。合併後的 sources 長這樣：

{
  "title": "中時新聞網",
  "url": "https://www.chinatimes.com/realtimenews/...",
  "rating_hint": {
    "source": "旺旺中時媒體集團",
    "wiki_url": "https://zh.wikipedia.org/wiki/Wikipedia:來源評級/列表/旺旺中時媒體集團",
    "hint": "這則是兩岸政治議題，維基社群認定旺中的政治報導通常不可靠。請改用中央社或官方文件佐證，或只用來說明某方的說法。"
  }
}

verifier 的對應比例為 52% 需要 rater、48% 可略過，摘要中位數約 270 字。依歷史 trace 估算。

「state 會流回 writer」這一列中，temp: 前綴在 AgentTool 之間的轉發行為還沒實測。其餘各列已對照 google-adk 1.26.0 原始碼（tools/agent_tool.py、agents/base_agent.py、agents/llm_agent.py）。

1. 評級在哪一段加入？

   A 包裝成 SequentialAgent、B 在現有 callback 查表、C 在 writer callback 呼叫 rater，或分階段進行。

2. 依主題的判斷由誰做？

   rater 小模型、writer，或 verifier。

3. rater 用哪個模型？

   Haiku 5.5（需接 Vertex 上的 Anthropic 與 Langfuse 計價），或 stack 內的輕量 Gemini 模型。

4. 評級資料放哪裡、怎麼同步？

   打包進容器、放 GCS，或寫進資料庫；由哪台機器每週同步，以符合 Wikimedia 的流量規範。

5. 怎麼驗證效果？

   用這次的歷史 trace 建 Langfuse dataset，比較改動前後的引用分布。

這屬於 agent 協作流程（adk/）的變動。決定後依專案慣例另寫一份決策紀錄（docs/decisions/）。