#cofacts
2026-03-02
Alfred chen
12:28:47
我理解的我們系統的結構長這樣對不對?
mrorz
2026-03-05 09:46:57
差不多~ 一些小細節要微調
• Media manager 其實是 rumors-api 呼叫的 library 。我後來開發覺得 media manager 拆出去造成的問題比效益大,之後若要讓 media 改用 embedding,我會丟掉media manager 直接在 API 裡面管
• opendata 最後輸出到 hugging face 就是讓後面的人接去用。
• beta-ai 這個服務是直接接在 rumors-api 上的。
• dashboard 應該蠻久沒開發了,當時應該也是直接接到 rumors-api。
• ground-truth 是放之前做 BERT transformer 訓練資料集的地方,是手動標記的資料。LLM 時代這應該會作為 evaluation set。
• Media manager 其實是 rumors-api 呼叫的 library 。我後來開發覺得 media manager 拆出去造成的問題比效益大,之後若要讓 media 改用 embedding,我會丟掉media manager 直接在 API 裡面管
• opendata 最後輸出到 hugging face 就是讓後面的人接去用。
• beta-ai 這個服務是直接接在 rumors-api 上的。
• dashboard 應該蠻久沒開發了,當時應該也是直接接到 rumors-api。
• ground-truth 是放之前做 BERT transformer 訓練資料集的地方,是手動標記的資料。LLM 時代這應該會作為 evaluation set。
mrorz
2026-03-06 09:00:28
簡單來說,DB 不直接對外,服務類的東西全是接 rumors-api
mrorz
2026-03-06 09:01:20
Opendata 大概是唯一和 DB 有連結的
但他是從 weekly backup 產出 CSV 放上 hugging face,也不是直連 DB
但他是從 weekly backup 產出 CSV 放上 hugging face,也不是直連 DB
mrorz
2026-03-06 09:02:51
rumors-deploy 是存放 site, line-bot, api, db 的 docker-compose 的地方
雖然實際 deploy 其實和這個公開的 docker-compose 越差越多了,但 rumors-deploy 其實仍然保存著這些 component 之間的真正關聯,也能從 env file 看得出各個服務對外部的 dependency
雖然實際 deploy 其實和這個公開的 docker-compose 越差越多了,但 rumors-deploy 其實仍然保存著這些 component 之間的真正關聯,也能從 env file 看得出各個服務對外部的 dependency
2026-03-05
mrorz
09:46:57
差不多~ 一些小細節要微調
• Media manager 其實是 rumors-api 呼叫的 library 。我後來開發覺得 media manager 拆出去造成的問題比效益大,之後若要讓 media 改用 embedding,我會丟掉media manager 直接在 API 裡面管
• opendata 最後輸出到 hugging face 就是讓後面的人接去用。
• beta-ai 這個服務是直接接在 rumors-api 上的。
• dashboard 應該蠻久沒開發了,當時應該也是直接接到 rumors-api。
• ground-truth 是放之前做 BERT transformer 訓練資料集的地方,是手動標記的資料。LLM 時代這應該會作為 evaluation set。
• Media manager 其實是 rumors-api 呼叫的 library 。我後來開發覺得 media manager 拆出去造成的問題比效益大,之後若要讓 media 改用 embedding,我會丟掉media manager 直接在 API 裡面管
• opendata 最後輸出到 hugging face 就是讓後面的人接去用。
• beta-ai 這個服務是直接接在 rumors-api 上的。
• dashboard 應該蠻久沒開發了,當時應該也是直接接到 rumors-api。
• ground-truth 是放之前做 BERT transformer 訓練資料集的地方,是手動標記的資料。LLM 時代這應該會作為 evaluation set。
2026-03-06
mrorz
08:52:18
逐字稿 model 換成 gemini-3.1-flash-lite-preview 的 PR 請大家協助 review 唷 🙏
https://github.com/cofacts/rumors-api/pull/380/changes
https://github.com/cofacts/rumors-api/pull/380/changes
mrorz
08:52:18
逐字稿 model 換成 gemini-3.1-flash-lite-preview 的 PR 請大家協助 review 唷 :pray:
https://github.com/cofacts/rumors-api/pull/380/changes
https://github.com/cofacts/rumors-api/pull/380/changes
Google AI for Developers
Learn about Gemini 3 Flash Preview from Google![]()
- 💡1
mrorz
09:00:28
簡單來說,DB 不直接對外,服務類的東西全是接 rumors-api
mrorz
09:01:20
Opendata 大概是唯一和 DB 有連結的
但他是從 weekly backup 產出 CSV 放上 hugging face,也不是直連 DB
但他是從 weekly backup 產出 CSV 放上 hugging face,也不是直連 DB
mrorz
09:02:51
rumors-deploy 是存放 site, line-bot, api, db 的 docker-compose 的地方
雖然實際 deploy 其實和這個公開的 docker-compose 越差越多了,但 rumors-deploy 其實仍然保存著這些 component 之間的真正關聯,也能從 env file 看得出各個服務對外部的 dependency
雖然實際 deploy 其實和這個公開的 docker-compose 越差越多了,但 rumors-deploy 其實仍然保存著這些 component 之間的真正關聯,也能從 env file 看得出各個服務對外部的 dependency
2026-03-10
mrorz
10:00:45
HackMD
# Cofacts 會議記錄 - [搜尋](<https://cse.google.com/cse?cx=71f4f7ee215d54fe6>)[target=_blank] ## 2026 -
2026-03-12
mrorz
20:29:34
Cloudflare 有爬網頁的 API 惹
https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/
https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/
Cloudflare Docs
Browser Rendering's new /crawl endpoint lets you submit a starting URL and automatically discover, render, and return content from an entire website as HTML, Markdown, or structured JSON.![]()
- 👀1
mrorz
20:29:34
Cloudflare 有爬網頁的 API 惹
https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/
https://developers.cloudflare.com/changelog/post/2026-03-10-br-crawl-endpoint/
2026-03-15
mrorz
02:17:33
Cofacts 的 Linode 開了很久,Linux 與 docker engine 都卡在好久以前的版本。我想趁著接下來升級 Elasticsearch 的停機時間,直接把目前的老 Linode instance 換掉。
目前評估下來,放在台灣的 GCE with Container Optimized OS 好像是個滿好的選項,試算如下:
https://docs.google.com/document/d/1sZ4jOsrZPvbJv4QjlMxgbqFsh_pTZNBRs-NbG-HU0rM/edit?tab=t.8j5j4xlz2qmo#heading=h.c9s30vhbbc9t
RAM 開到 32GB 的話,或許網站也能從 cloudrun 搬回來。
大家可以協助評估一下這份報告裡的作法,我也會找時間開個小的 GCE with Container Optimized OS 看看是否用得順手。
目前評估下來,放在台灣的 GCE with Container Optimized OS 好像是個滿好的選項,試算如下:
https://docs.google.com/document/d/1sZ4jOsrZPvbJv4QjlMxgbqFsh_pTZNBRs-NbG-HU0rM/edit?tab=t.8j5j4xlz2qmo#heading=h.c9s30vhbbc9t
RAM 開到 32GB 的話,或許網站也能從 cloudrun 搬回來。
大家可以協助評估一下這份報告裡的作法,我也會找時間開個小的 GCE with Container Optimized OS 看看是否用得順手。