20260818 會議記錄

:::info

所有會議記錄編輯當週文件準備總結
NPO Hub 出席：bil, mrorz
線上出席：nonumpa, ggm
https://meet.google.com/mrz-dgrd-pri :::

Cofacts 網站搜尋回應問題

看這則訊息的時候發現使用者搭配身分證一起傳，但是身分證那則訊息沒有回應，所以我想到身分證的 article 引用該回應

發現搜尋預設「全部訊息」，不確定改成「全部回應會不會比較好？」
- 想說如果是比較有經驗的編輯，引用回應時應該是比較常搜尋回應，而不是訊息？
- 針對新手查核編輯，如果他們會比較需要搜尋全部訊息的話，就預設拿 article.text 直接幫忙搜尋? 如 next point 所述
目前會預設列出一些可以引用的回應，但不確定邏輯為何？如果大家也很常用「全部訊息」搜尋的話，也許預設列出訊息可以直接幫忙拿 article.text，用「全部訊息」搜尋
- 邏輯：已經回應過的相似可疑訊息的回應 [name=mrorz]
- 忘記有沒有考慮搭配訊息（可能因為覺得要和相似可疑訊息的回應混排很複雜） [name=mrorz]
  - 工程面可以考慮先加上搭配訊息的回應
- 子龍也會整理這塊

[!Note] TODO 先分析 rumors-site 現狀後開票：「使用現有回應」列表應該要加入「搭配訊息」的回應排序：全部放在「相似可疑訊息」的回應前面需開 issue 到 site

Log retention

在想 log 要不要保留久一點、收集更多面向的 log(sys log, command log)，cloudflare 撈 spammer log 時發現可以在 server 端 (google cloud logging) 用 CF-Connecting-IP 就可以拿到真實來源 ip，不用再到 cloudflare 撈 log

debug mode 好像有 log CF-Connecting-IP?
- 好像有個變數讓 log 比較多，但現在沒有開所以沒紀錄 [name=nonumpa]
- 不確定應該放在哪裡（deploy repo？）[name=nonumpa]
- cloudflared log 有沒有 header?
  - 以前 nginx 有 log，因為 cloudflared 取代 nginx 所以優先看這個
- 如果沒有，就要靠個別對外 application 來 log（site, API）
目前 business plan cf log 只能存一個月
enterprise plan 才能另外自動接到別的地方存
GCP log retention? [name=nonumpa]
- 好像也沒有很久 [name=nonumpa]
- 需要更久的 log 來查資料 for auditing / forensics purposes
- 要多留 GCE 機器 log
- GCP logging 好像可以設定 sink 到 GCS or BigQuery

[!Note] TODO

分析 cloudflared 的 logging 是否會記錄 IP

搜尋過往會議紀錄看 cf-connecting-ip 相關討論

讓 GCP log 收得到 cf-connecting-ip 需開 issue 到 devops

[!Note] TODO 研究 GCP log retention 與 log sink 機制，包含費用（之前是否有討論過？）需開 issue 到 devops

cofacts.ai

dev

@yutin：把 CI 的 code 拉出來，並把 ES 改成 9.3.2（rumors-api#395）

@mrorz：rumors-db#78 DB PR，DB mapping 感覺要先修好然後上線

@mrorz：有人幫改 trace input/output（cofacts/ai#110），請 ggm 確認是否影響工具

會影響 [name=ggm]

轉交 GGM 審 PR

collab

@mrorz：歡迎新成員加入，歡迎來這裡反應 cofacts.ai 使用問題 E：要求改用某些媒體後，AI 附的 url 正確了

老鶴：偶爾查核到一半就停下來、標題取得怪；很喜歡這個工具，但有時太糾結數據小錯誤而忽略作者引用意圖，會請 AI 重寫聚焦在引用是否恰當 @mrorz：停下來的 case 很偶發，超難捕捉與修復

[!Note] GGM: 用 AI + Langfuse skill 找找看使用者敘述的 session 是什麼 bil: 提供兩位的 Cofacts User ID (= Langfuse User ID)

cofacts/cofacts-ai-eval（private repo，eval dashboard 快速迭代，共 7 個 PR 皆已合併）

Langfuse project scope 修正、judge.py 未設定 key 時的錯誤處理、.DS_Store 忽略
Add local judge and Git-connected dashboard pipeline
Deploy dashboard with Workers Static Assets
Add static session detail pages to the evaluation dashboard
Record judge models and publish 120-day evaluation dashboard

目標：可以重複執行、打分數的 LLM as judge，讓我們在改完 prompt or 改完 model 之後可以知道是否有改善 or 是否有 regression

單輪 judge OK
多輪要想一下
- 如果把前面的 turn 當 fixture?
  1. 例如前面的 turn 是 tool call，我們測 writer 是不是可以知道還缺哪些 tool call 去 call
  2. 使用 [新的模型 + prompt] 讓他靠現有的 context 去處理來產生結果，跟原本的 config 相比是不是有比較好

@mrorz：小聚後兩個新想法，想討論： 一、讓 cofacts.ai 的 session 可被公開瀏覽 —— 參與者反應對別人與 AI 查證的過程有興趣；提議在訊息頁列出對應的 cofacts.ai 對話串供協作者參考/延伸；好處：(1) 想私下查詢者可用自己的助理 (2) 花的是 cofacts token，公開最大化效益、可重複利用查證內容 (3) 回報問題時可直接貼對話網址方便 debug

public 與否的 flag (ADK session state)
- 預設 true
- 偵測到 PII 或 spam –> 用某種方法設成 false
- 過去的 session –> maybe false
使用者造訪 cofacts.ai/session/<session-id> 若為 public 則可以顯示
- 從 ADK session ID 找 user id 才能從 adk SessionStorage load adk session
- 如果此 session 的 user = current user –> 目前的 UI
- 如果此 session 的 user != current user –> 唯讀
新增 tool 讓 agent 可以參考其他 public session 的內容 –> 讓 writer 可以接關

不想公開自己的對話

直說會公開 –> 使用者自己會克制 / alternative：用自己的 AI tool

[!Note] 開 issue 來做，加到 cofacts.ai project roadmap (phase 2)

二、AI 是否該在生成查核回應前先詢問使用者方向（比重、篇幅側重等），參考 Claude Plan mode 的問答模式，超時未答則 AI 自行選預設繼續

memory 是另一題
- 觀察 session 裡面使用者是不是會一直重複某些 prompt [name=mrorz]
- OpenCode 有 memory plugin 會自動偵測，不確定 ADK 是否有 [name=nonumpa]
- ADK user-level session 可以記錄 memory & 可以用在 prompt，只要設計一個 tool 就行 [name=mrorz]
- 第一層：當下偵測 / 第二層：每週 retrospect 看要不要更新 memory
問卷：增加互動感，效果不確定
- 使用者會不期待他問問題，需要定期回來看 [name=nonumpa]
  - 可以 auto-proceed with recommended option [name=mrorz]
  - 偵測 tab 是否 active (= 有機會看到 option，若否就自動 proceed)
- 直接給個 dropdown 問是 plan mode 還是 auto mode

[!Note] 開 issue 作為 enhancement item，加到 cofacts.ai project roadmap (phase 2)

Please review cofacts.ai 回報訊息入口的 design https://github.com/cofacts/kb/pull/16/changes

cofacts.ai session 週報

claude routine
每週開會前貼到 discord #collab
(Discord 支援 markdown)
先手動貼

[!Note] TODO

GGM: reporting routine 先手動貼到 #collab

MrOrz: 準備 DC bot 之後在自動化

AI 使用者爬蟲政策

追蹤 devops#12：開放 user-driven 爬蟲存取政策

小聚檢討

小聚已順利結束（板橋中心）
小松果：https://g0v.hackmd.io/abknsfWxQXur2rqM09LPXg
桌子延長線配置
- 從教室後方往前拉，避免絆到
- 9 張 3 人桌（中間前面 2 人，因為夾著投影機）
- 門旁邊有 4 個連桌椅 –> 最擠
- 門外有接待桌子
教室內可以吃東西、但要整理乾淨ㄎ
麥克風只能有一支
網路穩定
- 有一個人連不到 –> 最後 wifi router 只給 5 個 device
大多數人很準時

Spam

Add takedown skill for investigating spam and drafting takedown PRs（merged 08-14）＋後續 bugfix PR #14（merged 08-13）
summary –> article path –> IP

上週重點整理（2026-08-11 ～ 2026-08-17）

GitHub 活動

cofacts/rumors-api

CI test stability（merged 08-16）
fix: count article replies from all apps toward user level（merged 08-13，修正上次會議提到的等級=0問題，拿掉 app ID 判斷）
- @mrorz：昨天開會發現用 API 送回應的使用者等級為 0，查出是 App ID 作祟；已改為拿掉 app ID 判斷，統一和其他 query 看齊，PR #396 待 review
Handle URL resolve failures when creating replies（merged 08-16）
Remove Twitter login（merged 08-17）
release/20260813（released 08-13）

cofacts/rumors-site

Remove Twitter login button（merged 08-17）

cofacts/rumors-db

[draft] feat: add embeddings field for hybrid search（open，mrorz 提醒 DB mapping 需先修好才能上線）

cofacts/devops

開放 user-driven 爬蟲（AI 使用者查詢用途）存取政策（opened 08-12，上次會議 action item）

cofacts/takedowns

11 篇 spam 帳號下架 PR（#323–#333，其中 3 篇新上線的 /takedown skill 自動產出）
- 可以選擇用 takedown bot 的身份發 PR
- 這樣就沒辦法自己 merge，不需要在 prompt 寫

[!Note] MrOrz 看 claude routine 是否能設定 env 放 github token

cofacts/kb

docs(wiki): add spam/fraud takedown project page（open）

Discord 重點討論

general

@mrorz：菱角查核訊息的影片被 LLM 誤加了 summary（cofacts.tw/article/…）

下次開會

8/25 無法開會，取消一次
9/1 改線上
9/8 –> 9/10 (四)

[!Note] TODO 要改小松果

Cofacts production 狀態報告（2026-08-11 ~ 2026-08-17）

1. Cloud Run 服務狀態

共 11 個服務，全部健康（✔）。近期部署：site-staging-en／site-staging-ja／site-staging-tw 於 2026-08-17 重新部署。

2. GCE (`cofacts-prod`) 每日資源使用（min | avg | p95 | max，單位 %）

日期	CPU	Mem	Swap
08-11	6.70 \| 13.27 \| 19.01 \| 25.37	62.81 \| 65.77 \| 68.28 \| 78.99	39.75 \| 41.71 \| 44.89 \| 49.02
08-12	6.71 \| 12.68 \| 18.15 \| 21.73	62.74 \| 65.82 \| 68.22 \| 69.41	40.38 \| 41.67 \| 43.71 \| 44.15
08-13	5.46 \| 12.82 \| 18.83 \| 65.09	62.78 \| 65.88 \| 68.03 \| 80.75	35.44 \| 39.59 \| 42.76 \| 43.52
08-14	7.31 \| 12.78 \| 18.30 \| 21.01	62.76 \| 65.45 \| 67.55 \| 68.79	38.54 \| 40.12 \| 42.83 \| 43.74
08-15	7.61 \| 14.06 \| 20.54 \| 23.83	62.10 \| 65.44 \| 67.88 \| 74.62	39.35 \| 42.81 \| 47.21 \| 49.54
08-16	6.52 \| 13.40 \| 19.18 \| 22.08	62.62 \| 65.80 \| 68.23 \| 69.84	38.76 \| 42.84 \| 46.63 \| 48.49
08-17	8.02 \| 14.50 \| 20.44 \| 24.30	63.29 \| 66.06 \| 68.19 \| 83.86	38.49 \| 43.11 \| 46.58 \| 47.65

目前即時狀態：uptime 103 天、load avg 0.05/0.18/0.32；記憶體 31Gi 總量、已用 21Gi、可用 10Gi；Swap 4.0Gi 總量、已用 1.9Gi；磁碟 67G 總量、已用 56G（83%）。

3. GCE 進程級資源排行（Top 5，依 peak 排序）

進程	記憶體 (Daily Avg/Max, MB)	Stability (Std)	備註
Elasticsearch (java)	avg ~19,100 / max ~19,200-20,537	低（60-157）	穩定佔用，與上週（peak 19,574MB）相近
`node /srv/www/server.js`	avg ~263-296 / max 736-774，08-13 突增至 2,860	高（08-13 std 大幅偏離）	08-13 有明顯記憶體 + CPU 尖峰（同日 CPU peak 496,186，遠高於平日 ~13-19 萬），上週同進程 peak 僅 845MB，本週異常突增值得留意
`node /srv/www/build/index.js`	avg ~144-150 / max 430-596	低	穩定，與上週相近（peak 644MB）
`node index.js`	avg ~106-110 / max 131-526（08-16 尖峰）	中	與上週相近（peak 529MB）
`python main.py` (cofacts-ai)	avg 47-138 / max 122-312（08-16 尖峰）	中～高	08-16 CPU 也同步尖峰至 26,744（平日 ~3,000）

4. Cloud Run CPU / 記憶體使用率（p50 = 正常範圍，p95/p99 = 穩定度）

服務	CPU 正常範圍 (p50)	CPU 穩定度 (p95/p99)	Mem 正常範圍 (p50)	Mem 穩定度 (p95/p99)	觀察
site-tw	3.5-6.5%	67-95% / 98-101%	60-94%	77-101% / 101%	記憶體長期逼近配額上限（與上週相同，屬既有模式非新增）
site-staging-ja	0.5-0.7%	6-12% / 11-27%	58-94%	up to 101% / 101%	記憶體同樣長期偏高
site-staging-tw	0.5-0.7%	2-27% / 10-35%	60-89%	77-95% / 95%	偏高但略優於 tw/ja
site-staging-en	0.6-0.8%	9-23% / 15-50%	72-85%	85-95% / 95%	偏高
cofacts-ai	恆定 1.5%	11-15% / 29-35%	恆定 5.6%	7.1% / 7.1%	最穩定，資源餘裕大
line-bot-ja	0.5-0.7%	2-27% / 15-30%	37-42%	39-44% / 44%	穩定
line-bot-en	0.5-0.6%	9-18% / 11-58%	40%	42% / 44%	穩定

5. 重點觀察與建議

site-tw／site-staging-* 記憶體使用率長期逼近 100%：與上一週（08-04~08-11）資料比對，peak_p99 皆為 ~1.01（超過配額），屬於長期既有現象而非本週新增異常，但仍建議評估是否應提高 Cloud Run 記憶體配額以降低 OOM 風險。
node /srv/www/server.js 於 08-13 出現異常尖峰：記憶體從平時 ~290MB 暴增至 2,860MB，CPU 同日也飆升至平日的 3 倍以上。建議查看該時段 log 是否有特定請求或批次任務觸發。
python main.py（cofacts-ai GCE 進程）於 08-16 出現尖峰：記憶體與 CPU 同步升高，可留意是否為排程任務所致。
磁碟使用率 83%，較日常監控範圍略高，建議留意成長趨勢，必要時清理或擴充。
Elasticsearch／CPU／Swap 整體維持穩定，與過去週期相近，無明顯惡化。

日期	CPU	Mem	Swap
08-11	6.70 \| 13.27 \| 19.01 \| 25.37	62.81 \| 65.77 \| 68.28 \| 78.99	39.75 \| 41.71 \| 44.89 \| 49.02
08-12	6.71 \| 12.68 \| 18.15 \| 21.73	62.74 \| 65.82 \| 68.22 \| 69.41	40.38 \| 41.67 \| 43.71 \| 44.15
08-13	5.46 \| 12.82 \| 18.83 \| 65.09	62.78 \| 65.88 \| 68.03 \| 80.75	35.44 \| 39.59 \| 42.76 \| 43.52
08-14	7.31 \| 12.78 \| 18.30 \| 21.01	62.76 \| 65.45 \| 67.55 \| 68.79	38.54 \| 40.12 \| 42.83 \| 43.74
08-15	7.61 \| 14.06 \| 20.54 \| 23.83	62.10 \| 65.44 \| 67.88 \| 74.62	39.35 \| 42.81 \| 47.21 \| 49.54
08-16	6.52 \| 13.40 \| 19.18 \| 22.08	62.62 \| 65.80 \| 68.23 \| 69.84	38.76 \| 42.84 \| 46.63 \| 48.49
08-17	8.02 \| 14.50 \| 20.44 \| 24.30	63.29 \| 66.06 \| 68.19 \| 83.86	38.49 \| 43.11 \| 46.58 \| 47.65