Artifact 內容摘要：維基來源評級命中評估（資料期間 2026-05-13～10-13）</summary>

原始 HTML 存檔：artifacts/20261020-MkCyx4YhkfD8Y28Qu14qWT.html（Mermaid 圖需連線 runtime，離線只會顯示原始碼）

結論： 中文維基《來源評級/列表》（363 筆）約命中四成的 cofacts.ai 出處；英文 WP:RSP 只再多 2–3 個百分點。影響最大的是維基百科本身（23% 草稿引用維基，而兩個列表都評為「通常不可靠」）；約一半命中落在「依主題分評級」的條目，分歧點多是政治報導，所以工具不能只回傳基準評級，要回傳摘要讓模型依主題判斷。writer 已會避開「應停用」來源（入選率 5%），評級對這類的邊際效果不大。

第一部分：研究（資料取自 Langfuse TOOL observation）

• 命中度：草稿 references 3,252 個 URL 中 41.2% 命中中文列表、英文列表 13.2%、合計 44.0%；765 份草稿中 588 份至少一個出處命中。investigator 搜尋結果命中 39.8%（合計 41.9%）、verifier 讀過的頁面 44.4%（合計 46.2%）。
• 維基引用：176/765 份草稿（23%）引用維基；193 個 claim_sources 以維基頁為佐證；239 筆 references 指向 zh/en/ja 維基。WP:CIRCULAR：維基評級「通常不可靠」，應引條目背後的原始出處。
• 依主題評級（363 筆中 86 筆）：聯合報系基準半可靠（政治半可靠、其他通常可靠、udn 部落格通常不可靠；草稿引用 103）；旺旺中時基準半可靠（政治通常不可靠；58）；自由時報基準半可靠（報導自家事務通常不可靠；159）；精鏡傳媒（48）；三立電視基準「應替代」（27）；Google/YouTube 屬用戶生成內容（35）；中央社通常可靠、留意親執政黨傾向（70）；公視通常可靠（84）。
• 候選到入選草稿的比例：英文獨有通常可靠 35.3%、中文通常可靠 26.5%、未列政府網站 26.5%、查核組織 23.2%、學術 19.5%、中文半可靠 18.4%、通常不可靠 16.9%（多為維基、FB、YouTube）、應替代 12.0%、轉載平台 6.3%、應停用 5.0%。評級真正的增量在：維基（239）、中時/聯合/三立政治報導（188）、Facebook/YouTube（71）、中國官媒與大紀元系（17）。
• 未被列表涵蓋的約 56%：政府網站 18.9%、查核組織 4.7%、學術 2.8%、轉載平台 1.8%、其他未列 27.9%（Taipei Times、Focus Taiwan、上報等）。WP:RSP 沒列代表沒被討論過，不代表不可靠；政府/查核/學術需另訂規則（如比照 WP:MEDRS），轉載平台要先追到原始媒體。
• 英文 WP:RSP（497 筆）：獨有命中僅 2.8%（通常可靠 1.8%：Guardian、Reuters、SCMP、海峽時報、Al Jazeera、JAMA），優先順序可放後面。
• 研究面待決：維基出處怎麼處理（提示／要求改引原始出處／送出時擋下）、如何區分「佐證」與「說法的出處」（FB、YouTube、官媒常是被查核對象）、未列來源備援規則、要不要接英文列表。

第二部分：技術討論（ADK 1.26.0）

• 現況：investigator（google_search + append_grounding_sources）與 verifier（url_context + append_url_context_sources）都以 AgentTool 回傳 {content, sources:[title,url]}，經 writer 的 _normalized_response。
• 提案 A：包成 SequentialAgent，後接便宜模型 source_rater，替 sources 補 rating_hint。before_agent_callback 先做網域比對：investigator 呼叫 69% 命中依主題評級條目需要 rater，31% 可略過（13% 沒命中、18% 單一評級）；verifier 為 52%／48%；評級摘要中位數約 700 字（p90 約 1,700 字，verifier 約 270 字）。ADK 注意事項：AgentTool 取最後有內容的 event，故最後一步必須輸出完整 {content, sources}（含 _search_widget_html）；rater 不能設 output_schema（會沿 sub_agents[-1] 驗證），改用提示要求 JSON 並寬鬆解析；before_agent_callback 回傳 Content 可略過該 agent；子 session 的 state_delta 會流回 writer session，中間 key 加 temp: 前綴（AgentTool 間轉發行為尚未實測）；SequentialAgent 要沿用 investigator/verifier 名稱，內層 LlmAgent 改名；investigator 的 [SYSTEM] 重試字串與 verifier 無 grounding 的原始文字，rater 原樣放行；若用 Haiku 5.5 要加 anthropic[vertex] 依賴、Model Garden 啟用，且 instrumentation.py 的 usage 對應是依 Gemini 寫的，Langfuse 計價要另確認；rater 失敗或逾時退回不加提示。
• 其他做法：B 離線把每個條目摘要壓成「主題→評級→一句提示」，由現有兩個 callback 查表附上（延遲零、最好測，但 writer 要自己對照主題、context 變長）；C 在 writer after_tool_callback 呼叫 rater（結構不動，但 Langfuse 要手動加 span）；D 由 verifier 在報告中依主張判斷評級（不增加模型呼叫，verifier 手上有主張原文與頁面內容；但須把「是否支持」與「來源可信度」分開輸出，否則有支持但來源弱的主張會被打 ✗；investigator 階段沒提示；覆蓋率取決於 writer 是否真的呼叫 verifier）；E check_source_reliability(urls) 工具由 writer 決定何時查；F draft_factcheck_response 送出時硬性檢查（例如 claim_sources 指向維基就退回）。
• 建議路線：先做 B + F（B 的離線提示也是 A/C 需要的資料，F 直接處理量最大的維基引用），上線後用 Langfuse 觀察「草稿引用維基比例」與「政治類主張只靠政治報導通常不可靠來源佐證的比例」；若 writer 常套錯主題再升級 A 或 C。另一條路線是 D + F（investigator 階段可用 B 的查表附簡短提示）。
• 技術面待決：評級在哪一段加入（A/B/C/分階段）、依主題判斷由誰做（rater／writer／verifier）、rater 用哪個模型（Haiku 5.5 或輕量 Gemini）、評級資料放哪裡與如何每週同步（Wikimedia 對雲端 IP 的 MediaWiki API 會回 429，這次改用 action=raw 慢速抓取，正式同步需固定主機與帶聯絡資訊的 User-Agent）、怎麼驗證效果（用歷史 trace 建 Langfuse dataset）。決定後依專案慣例寫決策紀錄（docs/decisions/）。
• 方法限制：中文列表只缺「看中國」（被限流）；網址比對採網域或子網域；入選率以同 trace 內 URL 完全比對，換網址形式會被算成未入選。

</details>

• 原委： writer 挑出處目前只靠模型自己判斷。中文維基《來源評級/列表》有 363 個來源的社群共識評級，想評估能否用它提示 writer 哪些出處適合作為佐證。
• 研究： 比對近五個月的 Langfuse trace，結果如下：
  • 命中度： 中文列表涵蓋約 41% 的草稿出處，英文 WP:RSP 只再多約 3 個百分點。
  • 維基引用： 影響最大的是 23% 的草稿引用了維基百科本身，而維基把自己評為「通常不可靠」。
  • 依主題分評級： 約一半的命中是「依主題分評級」的媒體（中時、聯合、自由等），差異集中在政治報導，所以不能只看基準評級。
• 提案： 有三個方向待討論：
  • A： 在 investigator / verifier 後接便宜模型（rater），補上評級提示；
  • B + F： 離線寫好提示、用現有 callback 查表附上，再加上草稿送出時擋下維基引用；
  • D + F： 由 verifier 依主張判斷評級，並把「是否支持」和「來源可信度」分開輸出。

  會議要決定的是採用哪個方向、主題判斷交給誰做，以及評級資料怎麼同步。

[!Note] 先放 ai 的 issue 放進 ndx 追蹤

MrOrz’s TODOs

1. url resolution: make https://github.com/cofacts/ai/pull/118 and 123 ready for review
2. storybook: review and merge https://github.com/cofacts/ai/pull/126
3. /report: make https://github.com/cofacts/ai/pull/138 and 139 ready for review
4. plan for 分工, create foundation PRs

MozFest & next meeting

• 2026/10/28~2026/10/31
• 10/27（二）8pm (TPE) 線上 (tentative)

上週重點整理（2026-10-13 ～ 2026-10-20）

GitHub 活動

cofacts/ai

• #118 Pre-fetch verifier URLs via url-resolver to stop source hallucination（open，10/14 多輪 review，等大家 review）
• #149 Collapse the verifier’s no-signal fetch outcomes; restructure the pre-fetch ADR（opened / closed 2026-10-14）
• #150 ci(adk): pin Python 3.12 so uv stops picking 3.15（opened / closed 2026-10-14）
• #151 Carry Cofacts’ archived copies to the verifier inside its request（opened / closed 2026-10-14）
• #152 List the checked URL in sources; keep storage and config failures local（opened / closed 2026-10-14）
• #153 Pre-fetch only URLs the writer wrote; move the URL cap into the callback（opened / closed 2026-10-14）
• #154 Storybook on the official @storybook/tanstack-react framework（opened 2026-10-14）
• #155 Stop telling the verifier [RESOLVED PAGE] is always the body text（opened & closed 2026-10-14）

cofacts/rumors-api

• #407 fix(search): make hybrid kNN search work against Elasticsearch（closed 2026-10-13）
• #411 Hybrid search follow-up: union instead of filter, versioned embedding cache, task prefixes（closed 後 reopened 2026-10-13）
• #410 Add hyperlink validity dataset & decision experiment for #409（討論中，10/13–10/14）
• #406 fix(ListArticles): guard attachmentHash scripts against docs without a value（closed 2026-10-14）

cofacts/rumors-line-bot

• release/20261013（released 2026-10-13）

cofacts/url-resolver

• #74 Improve Facebook URL resolution and Threads metadata handling（review 中，2026-10-13）

cofacts/cofacts-ai-eval

• #21 Publish October 13 weekly usage review（opened / closed 2026-10-13）

cofacts/takedowns

• #366 Takedown spam user 咖喱 外送茶TG：funy62（opened 10/13，closed 10/14）
• #348 Takedown spam user 高風亮節的五股山迪（closed 2026-10-14）

cofacts/kb

• #36 summarize artifact contents in 20261006 meeting notes（opened / closed 2026-10-13）
• #37 publish kb with GitHub Pages（opened / closed 2026-10-13）
• #38 add 20261013 meeting notes（opened / closed 2026-10-14）

Discord 重點討論

general

@mrorz：10/7 開始好像有幾台 site-tw 卡在 CPU 100% 一直關不掉，直到我重新 deploy 才釋放 @Alfred chen：有其他的 logs 嗎？

dev

@mrorz（10/13）：（對 Yutin）我看到你的新 PR 了，目前我的方向會是關掉我的，但把測試方式移植到你的 PR。今晚有機會上線討論嗎～ @yutin：晚上 8pm 會上線

@mrorz（10/14）：幫 10/13 會議的 “Vector search：MrOrz 提供生出 staging 實測 artifact 的 prompt 給 Yutin” 開個討論串 @mrorz（10/19）：明晚 8pm 會議會講 cofacts.ai 整體架構（https://github.com/cofacts/kb/pull/31/changes，已與最新設計稿 in sync，技術細節還在調整）。文件中 Track 0 基礎建設已開 PR stack：ready for review 的可以開始看；draft 的方向正確、可進 preview 環境看感覺，但技術細節尚未細雕。明天先看範圍、問問題，並喬 10 月最後一週的會議時間，下週討論分工。

Cofacts 正式環境狀態報告（2026-10-13 ～ 2026-10-20）

1. GCE（cofacts-prod）整機指標

格式為 min | avg | p95 | max，單位 %。

*10/20 為部分資料。

目前即時狀態：

• 主機已連續運行 166 天，load 為 0.38 / 1.06 / 1.09。
• 記憶體 31Gi，已用 20Gi，可用 11Gi。
• Swap 4Gi，已用 1.7Gi。
• 磁碟 53%（35G / 67G）。

整體很平穩。CPU 平均約 15–20%，Mem 約 64–65%，Swap 約 35–37%。10/17 Swap 的 p95 和 max 稍高，分別是 42% 和 45%，之後回落。

2. GCE 主要 process

Normal Range 取每日平均，Stddev 當作穩定度指標。

CPU 欄位的絕對數值單位不直觀，所以我只比較相對變化。

3. Cloud Run

11 個服務狀態都是 ✔（正常）。近期部署：

• cofacts-ai：10/19 18:30（UTC）。
• line-bot-tw、line-bot-en、line-bot-ja：10/13。
• site-tw：10/13。
• dev-line-bot：10/07。
• site-en、site-ja：4/09 後未再更新。
• site-staging-*：8/17。

「Normal Range」取 p50，穩定度看 p95 / p99。CPU 單位為 vCPU，Mem 單位為 GiB。

輸出流量（GB/天）：

• site-tw：4.9、4.76、4.61、4.51、4.44、3.84、4.02，10/20 為 1.35（部分資料）。
• 其他服務全部低於 0.1 GB/天。

重點觀察與建議

1. site-tw 的 CPU 和記憶體 p50 比上週明顯下降。 CPU p50 從 0.137 降到 0.033，Mem p50 從 0.80 降到 0.50 GiB。輸出流量也從 4.9 GB 逐日降到約 4.0 GB。這可能和 10/13 的 site-tw 重新部署有關。10/13 的 CPU p95 為 0.87，是這週最高，推測是部署當天的暖機。建議確認這是否為預期的改善。
2. cofacts-ai 的 CPU p50 較上週上升，從 0.016 到 0.040，10/14 的輸出流量也有一次 62 MB 的尖峰，10/19 18:30（UTC）又有新部署。整體用量仍很低，沒有風險，但可以留意部署後的趨勢。
3. site-tw 的 Mem p95 / p99 接近 1 GiB，與 staging 站相近，建議確認 Cloud Run 的記憶體上限是否仍有餘裕。
4. Elasticsearch 佔記憶體約 19 GB，Swap 長期維持在 35% 左右，這屬於穩定的基線，不是新問題。如果之後要降低 Swap，要從 ES heap 或 chromium 的數量著手。
5. 其他尖峰：10/19 的 ES CPU 和 rumors-api RSS 尖峰，以及 10/17 的 Swap 尖峰，都已自行回落。若想查原因，可以對照當日 log。
6. 本週沒有任何服務出現持續性異常，磁碟使用率 53% 也還很充裕。