Slack archive

cofacts

Month: 2019-03

2019-03-05

Relax 13:23:40
@healthya2776 has joined the channel

2019-03-06

2019-03-09

mrorz 10:29:00
今天 Cofacts 真的假的、我愛家我解惑的協作資訊在這裡唷：
https://beta.hackfoldr.org/cofacts/
bil 12:57:06
@jcjiang42
https://g0v.hackmd.io/c/B1iHBvVPQ/%2FmrsydmcAQkGasHYtWTLsGQ
https://g0v.hackmd.io/c/B1iHBvVPQ/%2F6j4BIcRSSdm7s-h9qS9_dg

HackMD

《我愛家我解惑》資料庫 - HackMD

這裡蒐集了近期網路上的反平權、反性平訊息，分析傳播熱度、拆解為爭議點，並且嘗試做出回應。

HackMD

《我愛家我解惑》資料庫 - HackMD

這裡蒐集了近期網路上的反平權、反性平訊息，分析傳播熱度、拆解為爭議點，並且嘗試做出回應。

leannechen 13:18:57
@lianchennnn has joined the channel
hyhsu 13:31:11
@hyhsu has joined the channel
CRW 13:59:33
@u01120033 has joined the channel
jc 15:16:56
https://www.patheos.com/blogs/crossexamined/2018/11/20-arguments-against-same-sex-marriage-rebutted/

http://gayagenda.net/marriage.html

Cross Examined

20 Arguments Against Same-Sex Marriage, Rebutted

Same-sex marriage is in place in America, but anti-gay arguments remain a siren song to many conservatives. Let’s critique their arguments.

gayagenda.net

The Canonical List of Rebuttals to Anti-gay Arguments Against Gay Marriage Rights

The canonical list of rebuttals to the tired and irrational arguments commonly made against gays securing the right to marry their partners by the anti-gay hate industry. Complete with convenient anchors for easy linking.

I’m curious about the domain name “gay agenda.net”. It’s said that “gay agenda” is actually a term invented by anti-gay conspiracy theorists. (the first time i read this term is here: https://www.thenewslens.com/article/65203 )

Is the website owner just being sarcastic on the term?
❤️ 3
jc 15:32:06
https://www.tandfonline.com/doi/abs/10.1080/14681811.2015.1042573 study on increased perception of safety and lowered bullying when LGBTQ issues are included in education
added to https://g0v.hackmd.io/c/B1iHBvVPQ/%2FFySWZdlKTZyrLnHaL8a7KQ. This info come in handy just in time! anti-gay parent groups are protesting tomorrow.
❤️ 3

2019-03-11

2019-03-12

carol 10:58:08
@shesee has joined the channel

2019-03-13

2019-03-14

carol 09:59:57
美玉姨是可以算群組的，只要收集一下群組 id 至少曾經有在講話的群組我會知道有哪些 XD <- 只是這樣就超過了不儲存任何資料的聲明了
也分享一下另外一種可以預測可能是假新聞的論文（非常的中國，就是計算那些偏見媒體和偏見轉傳者的分數來當作文章的偏見…假指數）https://www.public.asu.edu/~skai2/files/wsdm_2019_fake_news.pdf
其實西方也搞這一套呢 orz

看網域來源的有 Adblock 的 https://trusted-news.com/ ，學術研究可以參考這裡：

[2018-3-3] Facebook的假新聞問題……已經病入膏肓／Frederic Filloux
https://medium.com/@smokingtuna/facebook-reliability-problem-51456eafbfa3

他們的 methodology 是看一個網域過去的 fact check 紀錄，來計算「某個網域」的可信度分數。也就是說，他們論文裡面嫌那種單篇單篇查核速度太慢，但他們的看網域這件事情其實還是仰賴過去累積的內容查核這樣。

研究謊言在 social media connection 的傳播模式這件事情，過去也有上過 nature
https://www.nature.com/articles/d41586-018-02934-x

用一則訊息在社群網站上的傳播模式，來偵測這個訊息是不是很有可能是假的，這件事情其實好像滿有趣的——只要它不要涉及「懲罰轉傳的人」，而只是標出「這則傳播模式跟過去的謠言很像」、讓有需要的人去看看是否需要另外澄清，那我就覺得是個不錯的系統。

（當然在中國的話應該是另一種玩法囧）
> 「懲罰轉傳的人」
對，這才是真的中國風的部分哈哈哈哈
https://arxiv.org/abs/1810.11663 日本好像單純用 NLP 硬幹，似乎沒考量到傳播的模型。但用來偵測、減少人工判讀，是有一些幫助的
（ 日本 work 的介紹：https://www.feja.org.tw/44289 ）
mrorz 11:07:25
嗯嗯開會的時候就有說如果記了的話有隱私疑慮，所以 @bil 的意思是指計算直接傳給美玉姨的部分～
👍 1
carol 11:17:00
也可以不用加特別的 endpoint, 就我多埋一點特殊的 headers 之類的會比較輕鬆（嗎）
mrorz 11:18:16
我自己本身是比較希望自己的 analytics 自己埋，互相分享～

例如美玉姨這裏自己有個 google analytics，然後 cofacts 與美玉咦的 google analytics 上互相加對方為協作者，這樣就能在 google data studio
mrorz 11:18:54
一起繪製
carol 11:19:11
我其實有寫了一個埋 analytics 的 PR, 但是因為隱私的問題遲遲沒有 merge
carol 11:19:22
不過不是 google analytics 好像是 chatbase 之類的
carol 11:20:08
因為美玉姨不真的有網站，也沒有 db
mrorz 11:20:32
其實我覺得如果是個人私訊給美玉姨的話應該還好～
mrorz 11:22:25
不過如果美玉姨在群組裡面回傳了內容，那如果紀錄「這個文章在這個時間點裡、於某個群組裡面被搜到了」這件事情，到底會不會有隱私疑慮，其實我也不太清楚
mrorz 11:22:38
我覺得因為是 cofacts content，理論上應該還好？
carol 11:24:40
我也是覺得還好所以寫了，但是又覺得這樣有點那個所以還沒有下定決心 merge 進去（主要是還沒有想好怎麼做）
不過我認為那個評分機制有助於減少人工判讀 <- 或是 highlight 哪些應該優先人工判讀
mrorz 11:25:11
嗯嗯，其實主要是希望知道「這則訊息有在被查詢」這樣
mrorz 11:25:30
Cofacts 的困境是分不出哪些訊息是「某人一時興起，拿一則訊息來問」
bil 11:25:37
如果有隱私疑慮的話，可能還是先不做比較好。想以盡量嚴格的標準避免carol收到隱私疑慮的質疑。
mrorz 11:25:37
還是「真的有在被轉傳」
mrorz 11:26:32
對於 Cofacts 與美玉姨來說，要分辨這兩者的方式是得知「到底一則訊息有沒有被傳進來 2 次以上」
carol 11:27:16
我先要去忙一下，晚一點再進來回覆 👋
mrorz 11:28:27
以 cofacts 為例，我們在 LINE 使用者選擇某個查詢結果的時候，會傳送一個 google analytics 的 article select event，以及被選擇的 article id

所以可以畫出像是這樣的圖，一看就知道這則訊息很常被轉傳（然後 cofacts 各個使用者很常來問）：
https://datastudio.google.com/reporting/18J8jZYumsoaCPBk9bdRd97GKvi_W5v-r/page/NrUQ?config=%7B%22df7%22:%22include%25EE%2580%25800%25EE%2580%2580IN%25EE%2580%25805479897696031-rumor%22%7D

Google Data Studio

Cofacts analytics

Google Data Studio turns your data into informative dashboards and reports that are easy to read, easy to share, and fully customizable.

mrorz 11:29:59
要畫出這樣的圖，不用紀錄使用者實際上傳了什麼文字，而是紀錄哪篇（已經被公開上網了的）cofacts 文章被選擇了，這樣應該可以把隱私疑慮降到最少
mrorz 11:31:01
當然這麼做的 trade-off 就會是，如果一則訊息在 cofacts 裡面還沒建檔（zero-day rumor?）是無法偵測到的

還是得仰賴 Cofacts 使用者熱心回報訊息～
我在 chatbase 裡面做差不多的事情，但是打算看看使用者的行為所以裡面會把 line user id 跟 article_id mapping 起來
然後預測哪一些使用者傾向於轉傳可能的假訊息
這樣等到有新回報出現的時候可以 highlight 出可能是高度被轉傳的假訊息的可能性高低
但是因為這就覺得微有疑慮，還沒有心理準備好 merge 它 😅
喔喔喔這確實就有點像前面那篇論文 XD”
Cofacts 也有紀錄哪個 userId 轉傳了訊息給 Cofacts，但這是為了避免訊息被轉傳兩次，Cofacts user 應該都不是傳遞謠言之人。而且 Cofacts user 都是有意識地私訊 Cofacts，所以比較沒有疑慮。
mrorz 18:10:24
@lucien 關於 ui lib 我覺得我跟 material-ui 越來越熟了，就用它吧 XDDD

CSS 方面我最近滿喜歡 emotion
https://material-ui.com/guides/interoperability/#emotion

material-ui.com

Style Library Interoperability - Material-UI

While it is simple to use the JSS based styling solution provided by Material-UI to style your application, it is possible to use any styling solution you prefer, from plain CSS to any number of CSS-in-JS libraries.

lucien 19:16:12
不換一個嗎哈哈，覺得很無趣
對 material-ui 厭煩嗎
有比 bootstrap 厭煩嗎
只好來魔改他惹
就設計的時候用 material component 就好了吧 XD

2019-03-15

chyuaner 21:45:58
@chyuaner has joined the channel

2019-03-20

2019-03-23

mrorz 14:57:44
http://mol.mcu.edu.tw/%E9%98%B2%E6%AD%A2%E5%81%87%E8%A8%8A%E6%81%AF%E8%BD%89%E5%82%B3-%E5%B9%B4%E9%95%B7%E8%80%85%E5%AD%B8%E7%BF%92%E6%9F%A5%E8%AD%89/

銘報即時新聞

防止假訊息轉傳 年長者學習查證 - 銘報即時新聞

「臺北市立圖書館樂齡中心」邀請台灣媒體觀察教育基金會擔任2019年春季巡迴講座講師，15日於大同分館舉行「假新聞大揭密」講座，帶領近30位年長者學習辨別訊息的真假，並透過互動教學的方式，實際操作社群軟體LINE的查證工具。

2019-03-24

jimhorng 14:08:08
@jimhorng has joined the channel
jimhorng 14:15:03
各位大大，想請教用LINE帳號查詢假訊息後出現的相似度分數是用什麼技術判斷的（e.g. elasticsearch）？

剛好我最近在研究NLP相關，想知道對於被部分改寫的假訊息 能辨識的程度

感謝 ：）
Screenshot_20190324-141255~2.png
LINE bot 回傳的部分分 2 個 pass
1. retrieval (決定要顯示哪些)
2. 以及相似度評分 (0%~100%)

前面 retrieval 是 elasticsearch 決定的，只有被 elasticsearch 找到的訊息，會列出來，然後由 LINE bot 這裡計算相似度
具體來說，elasticsearch retrieval 這裡使用的是 `more_like_this` query
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-mlt-query.html

他會先從 query 的句子（`like`）挑出幾個具有分辨力的 term（預設 25 個，就是 `max_query_terms` 參數的預設值），然後去查哪些 document 有 match 這個 term
然後 LINE bot 這裡設定 retrieval「有中」的門檻（也就是 `minimim_should_match` 參數）預設是：
若 document 在 10 個 term 以內，那必須全中；否則，需要 match 70% 的 term （也就是 document 裡必須要有 25 * 70% ~= 18 個具有分辨力的 term）
這是個滿高的門檻，確實可以討論。
elasticsearch 這裏的斷詞是，中文為 bigram，英文就是 by word ～
再來，有關 LINE bot 的相似度評分

雖然 elasticsearch 其實會給一個分數，但那個分數其實是各個 matching item 的總分，是從各個 matching term 的 tf-idf 等數值算出來的，沒有一個「滿分」，所以無法直接轉換為百分比。

使用者比較能理解「百分比」分數，所以變成是我們在 LINE bot 端來把 elasticsearch 列出的 item，跟使用者轉傳的實際訊息相比，再計算一個相似度分數。

具體來說，計算分數時我們用的是 string-similarity 這個套件，他背後用的是 Dice’s Coefficient。
https://www.npmjs.com/package/string-similarity
（我也不知道那是啥，但感覺很厲害）
@jimhorng 以上就是 retrieval 與相似度的定義～
感謝大大，我來好好消化一下...XD
其實我覺得我們跟 NLP 的關聯性好像蠻低的 哈哈
沒有 NLP，只有 web information retrieval
而且通通都是 elasticsearch 做掉了，完全不假我們手
@mrorz 本來要問 _score 但剛好發現有這篇 _score 應該就是 elastic search 的 score
嗯, sort option 裡的 _score 確實就是 elasticsearch 的 _score
從 bot source 我有找到 string-similarity 但我沒看到 `minimim_should_match` 的相關邏輯
bot 是使用 cofacts-api 預設的 minimum_should_match
ok 所以 `minimim_should_match` 的確是 API 的邏輯？
Background: 我們正在想辦法盡量貼近 Line bot 的邏輯所以原本誤用 sort by _score 現在我照抄 bot 邏輯搞定 similarity 了但我剛好看到這串想確定一下 `minimim_should_match` 是不是 bot 有處理還是其實比較算是 API internal
I see 那應該跟我想的一樣 thanks!
`minimumShouldMatch` 確實是要 expose 出去給 API user 來調控相似度 threshold 的唷
例如說 cofacts site 的 search box 其實就是給一個比較鬆的 minimumShouldMatch
但如果沒給的時候有個預設值 & line-bot 是沒給的情況（嗎）
對，預設就是 API server 裡的剛才貼的那裡
Nice!
jimhorng 14:19:42
另外發現opendata中有一些格式問題，先開成issue。
https://github.com/cofacts/opendata/issues/13

請教用來產生這些csv的script放哪邊？或許我可幫忙看一下 ：）

GitHub

some fields are not properly double-quoted in csv · Issue #13 · cofacts/opendata

e.g. in <https://github.com/cofacts/opendata/blob/master/data/articles.csv.zip> text field not double-quoted but contain newline char was: AV6yLoz4yCdS-nWhuglc,LINE,dd6282f4a3d6da926bd62131faf6886284...

我回在票裡了
感謝感謝
感謝大大~

2019-03-26

jimhorng 19:40:14
請教大大是否有user查詢假新聞用的query log與是否有match到假新聞資料庫的紀錄？ 想了解一般user遇到的假新聞相似度與主題分群的狀況，感謝 ：）
1. 查詢假新聞的 query log 是有，不過目前沒有公開，想說轉傳進來的訊息，使用者還沒有答應要公開
2. 如果是 match 到之後、使用者有選擇說「這是我傳的」那種的訊息就有，因為 cofacts 使用者送出的時候有答應要公開。

目前是放在 https://cofacts.g0v.tw/analytics 的 message search trend
滑鼠移到表格上右鍵，可以 download csv 或 export to sheets
感謝大大!
意思是說沒有match到的 query 就不會有了?
剛看了一下message search trend, 似乎是哪些文章被搜尋到的列表, 但沒有user search本身用哪些字/文章? 這包含user在網站 搜尋 跟chatbot的嗎? 感謝~
1. 嗯對，目前沒有公開 user search 本身用哪些字 / 文章
2. Message search trend 是只有在 LINE bot 上的。網站另外有 Message pageview trend 報表，但那也是 pageview
不過話說回來
其實我們本來就希望使用者「整篇轉傳」而不是「打關鍵字」找東西呢
了解, 只是好奇user拿到的訊息片段有可能是變形過的, 但或許相似度很高可以直接歸類在資料庫某篇文章, 這樣可以多了解 每篇文章可能的變形有哪些 🙂
Danny 21:26:11
@danny77515 has joined the channel

2019-03-27

mrorz 01:57:01
本日會議記錄 https://g0v.hackmd.io/s/rJdASkduE

HackMD

20190327 會議記錄 - HackMD

20190327 會議記錄 ===== &gt; 上次開會紀錄：<https://g0v.hackmd.io/s/Byl-9PkdE> ## 四月小聚！！ - 4/20 * Most vote - B

nsbh 09:12:04
@nsbh4357 has joined the channel

2019-03-28

2019-03-29

hoisee 03:14:49
@hoisee has joined the channel
CRW 13:59:43
大家好，我要登入愛家解惑的時候跳出警告，想問該怎麼辦
received_2341823596063569.png
請問是用 google 登入嗎？
我 code 寫錯惹，改用 facebook 登入看看？
沒有跳出選擇以臉書還是Google登入的選項就進入這個畫面了
我有試過cofacts，可以選擇Facebook帳號登入。但在answerfamily只要按下登入就會直接出現錯誤訊息
他有提供error detail：
看來 auth0 把你的選擇記起來了 GG
用無痕試試看呢
@u01120033 我終於知道了囧

因為你用 http orz
我開一下 https only 好了，不然大家都誤入 http ＱＱ

2019-03-30