COSCUP 2024 分享：生成式 AI 於 WIKIDATA 中的寫作應用

今年 COSCUP 分享題目「生成式 AI 於 Wikidata 中的寫作應用 -- 從資料完整性到資料協作品質」探討使用生成式 AI 在維基數據中的應用，包括從文本辨識屬性、分析屬性間關係、檢查來源可靠性，以及改善屬性完整性，透過人與 AI 協作，增加 Wikidata 內容可靠與準確性。

Made with DALL-E. Inspired by Direct Media on StockSnap

什麼是維基數據 (Wikidata)？

維基數據 (Wikidata) 是「一個開放的、多種語言的線上資料庫，收集各種資訊並以易於理解和使用的方式組織，供網路百科全書和其他網站使用，也讓任何人都能免費取用這些資料。」(詳見維基數據的簡介)

維基數據至 2012 年 10 月開站，至今年 3 月已經累積 21 億次編輯。

如何判斷是善意貢獻或惡意破壞？

一個開放的的線上資料庫每天面對可能來自大量匿名的編輯。如何判斷是善意貢獻或惡意破壞？

一、由工人智慧 (人工) 方式巡邏內容：例如其他人加入撲克牌網站連結，肉眼可以很快速地察覺與復原。好的內容也可以依照維基百科「頁面評級」或維基數據「項目品質」檢核表，人工評比頁面。

二、採用規則協助識別破壞內容：例如當大量被破壞內容都與撲克牌、賭場有關，就可以寫成規則，由電腦識別破壞內容。

三、使用機器學習協助識別破壞內容：採用規則方式的缺點是可能誤刪善意編輯的內容，例如與撲克牌主題有關的條目，需要額外增加其他規則時，就會連動地造成多組規則間可能衝突、更難維護。採用機器學習方式，例如 2013/12 前的「客觀文章修訂評估服務」 (Objective Revision Evaluation Service，簡稱 ORES) 或之後的 Lift Wing 更通用的模型託管平臺。粹取文章中的特徵，例如「預測編輯是否可能最終被回退」壞詞偵測使用到 TF-IDF 統計方法，計算文章中重要詞彙的權重、「預測一篇條目或草稿的的評估等級」則從文章結構特徵進行預測，例如：有多少章節？有資訊框麼？多少個參考資料？使用 cite 模板？但不評估寫作品質，或是否有語氣、觀點問題。

使用生成式 AI 協作

分享中提出四種協作方式：(1) 從文本辨識「屬性」、(2) 從文本辨識「屬性」間的關係、(3) 檢查可靠來源、(4) 改善「屬性」完整性。

Wikidata 的「屬性」(property) 可以理解是 Excel 的欄位名稱，詳細說明：

屬性描述了敘述中的資料值，可以被視為一種資料的類別，例如，資料值「藍色」的屬性為「顏色」。屬性與值配對後，在 Wikidata 中形成一個敘述 (statement)。屬性也用於修飾符。屬性在 Wikidata 上有自己的頁面，並與項目連接，形成一個連結的資料結構。(資料來源：Wikidata)

(1) 從文本辨識「屬性」

以前「自然語言處理」 (NLP, Natural Language Processing) 要粹取「屬性」可以透過「命名實體識別」(NER, Named Entity Recognition) 技術。例如我要從「4所大專校院明天退場明道大學生安置到輔大、逢甲」新聞中，找出被廢校的學校名稱。

使用中研院 CKIP CoreNLP 實體辨識的結果：

CKIP CoreNLP 網站截圖

畫面上可以看到 CoreNLP 將特定詞彙標記上顏色與詞性，包含 CARDINAL (數詞) 、ORG (機構)、DATE (日期) 等詞性 (完整詞性清單可參考這份簡報)。想要找出被廢校的學校名稱就歸類在 ORG (機構) 詞性。但是同時間被標示成 ORG 的詞彙有：

i. 行政機關：教育部

ii. 正式退場的學校：明道大學、環球科技大學（環球科大）、大同技術學院、東方設計大學

iii. 安置學生的學校：亞洲、淡江、輔仁、大葉、逢甲等學校，部份還被歸類到 PERSON 的靜宜、東海。

還需要額外處理，才能真正找到正式退場的學校清單。

💡 改成使用生成式 AI 下的提示：

根據我提供的新聞
列出廢校的學校名稱，以列點格式輸出
如果沒有則直接回答無

🤖 使用不同大型語言模型 ChatGPT-4o、Claude-3-Sonnet (POE)、Llama-3.1-405B-T (POE) 和 Google Gemini，都可以順利完成這項任務。

(2) 從文本辨識「屬性」間的關係

目的是將上一步驟得到的正式退場的學校清單，找出相關的屬性，以利建立「敘述」(statement)。

一個陳述是一項關於某個條目的資料，記錄在該條目的頁面上。陳述由一個主張（屬性-數值對，例如“位置：德國”，以及可選的限定符）組成，並通過參考資料（提供主張的來源）和排名（用於區分包含相同屬性的多個主張；默認為“正常”）來加以補充。Wikidata 不對陳述的正確性做任何假設，而僅僅是收集並將其與來源一起報告。“陳述”這個術語經常與“主張”互換使用，但技術上它只有在至少添加了一個參考資料後才成為陳述。(資料來源：Wikidata)

💡為了避免生成式 AI 瞎掰，所以先說明「屬性」、「敘述」的定義，並提供全部「屬性」清單，要求生成式 AI 根據我提供的知識檔案，從新聞內容辨識「屬性」間的關係。下的提示是：

步驟1: 從新聞粹取廢校的校名
(新聞略 ...)

步驟2:
廢校的校名作為 <label>

請詳細閱讀我提供的 Property, Statement 定義，以及上傳的檔案
Property 的 ID, label, description, Data type
- Property: Property describes the data value of a statement ...
完整 Property 清單請看附檔
- Statement: A Statement is a piece of data about an item ...

提供 <label> 的 Property, Statement 關連 (可能多值)
輸出格式：
- <label>
- Property 的 ID (例如: P6), Property 的 label (例如: head of government)
- Property 對應的欄位值 (需遵守 Property 的 Data type)

🤖 測試結果可以看到不同大型語言模型的差異。順利辨識屬性間關係的模型有 ChatGPT-4o 和 Llama-3.1-405B-T (POE)。

而 Claude-3-Sonnet (POE) 和 Gemini-1.5-Flash (POE) 出現因為支援檔案大小限制，導致檔案截斷或者顯示超過 context window 的長度限制。

(3) 檢查可靠來源

根據中文維基百科的內容指引，來檢查新聞內容是否是可靠來源？

💡如果模型支援上傳知識檔案，下的提示是：

根據知識檔案建立內容品質的檢核表，並根據檢核表檢查網路文章內容的品質
以及是否可信

輸出格式：根據檢核項目做成表格
欄位分別是檢核項目、參照的新聞片段、評價、詳細解釋
(如果部份檢核項目無法評估，則直接回答無法評估)
最後並給予綜合評價

使用台灣常用的繁體中文回答

💡如果模型不支援上傳知識檔案，提示方式則分成兩次：

第一步驟：

將文章內容改成可執行稽核的檢核表
'''
(手動貼上文章)
'''

第二步驟：

依據網路文章稽核綜合檢核表，檢查我等一下提供給你的新聞文章
輸出格式：根據檢核項目做成表格
欄位分別是檢核項目、參照的新聞片段、評價、詳細解釋
(如果部份檢核項目無法評估，則直接回答無法評估)
最後並給予綜合評價

使用台灣常用的繁體中文回答

🤖 以批高虹安自己要檢討！館長轟「低級錯誤」：妳丟的是所有人的臉這篇新聞為例，不同模型表現有明顯差異：(1) 有提到單一觀點，建議增加更多不同來源的意見和證據引用的 ChatGPT-4o、Claude-3-Haiku (POE)、(2) 沒有提到單一觀點 Llama-3.1-405B-T (POE) 和 perplexity、(3) 有趣的是拒絕評論選舉和政治人物的 Google Gemini。

(4) 改善「屬性」完整性

前三個步驟都是根據我給予的新聞內文，找到屬性、屬性間關係，會不會有哪些屬性不在新聞內文，但是觀眾對這個主題其他屬性有興趣，而我忽略了。

💡 提示文字：

對於新聞有興趣的使用者，查找資料時，根據 Property 清單，還需要哪些
Property 但是新聞內容沒有提到？

輸出表格格式
欄位：
1. Property 的 ID (例如: P6)
2. Property 的 label (例如: head of government)
3. 推薦程度，用 1~5 顆星排序
4. 解釋原因

🤖 下圖示 ChatGPT-4o 的推薦結果：可以找到先前新聞沒提到，但讀者可能有興趣的利害關係人屬性。

盤點上述與生成式 AI 協作的工作流程：(1) 從文本辨識「屬性」、(2) 從文本辨識「屬性」間的關係、(3) 檢查可靠來源、(4) 改善「屬性」完整性。需要手動來來回回複製好幾次，如果改用「代理人工作流程」 (agentic workflow)，可以大幅增加資料處理速度。

coze 網站截圖

儘管採用同樣的大型語言模型，有些問題在 coze 的問題回覆品質會參差不齊，還需要人工檢核。

結語

同樣的語言任務，使用不同大型語言模型試驗，可以發現生成式 AI 大型語言模型的侷限。除了部份無法直接上網瀏覽資料，其次是可以處理文章的長度限制。另外關鍵的限制是驗證來源可靠性，需要該來源也是數位化資源。

然而真實世界的資料可能是更惡意的，例如「《刺客教條：暗影者》成國際問題？彌助維基被爆故事史實化、作者把黑奴買賣推給日本人」當原以為是可靠來源的紙本出版物，其實是偽造的故事呢？除非日後人形機器人，可以直接到圖書館查找資料，交叉驗證來源的可靠，也許才能解決這類來源可靠性被污染的問題。

當編輯的條目本身就很缺少資料，更需要實地踏查、查找早期文本。在目前使用生成式 AI 快速生成資料的時間點，也是更需要人們生產原創資料的時候。

簡報檔案

📃 簡報檔 (簡報中會交叉使用「實體」與「屬性」詞彙，都是指 Wikidata 的「屬性」)

planetoid's blog

搜尋此網誌

馬車時代的產品開發挑戰：使用者需求背後的真實訴求