跳至內容

維基百科:機械人/申請/Antigng-bot/30/2

維基百科,自由的百科全書
批准測試運作(50次編輯) --百無一用是書生 () 2021年2月20日 (六) 06:31 (UTC)[回覆]
  • 測試已完成
  • 測試範圍:所有條目列表前20頁(共100,000個條目),涵蓋各種類型的條目;
  • 結果:第一次嘗試:185筆編輯、第二次嘗試:105筆編輯
  • 發現的問題:該任務利用啟發式算法嘗試修正不正確的日期,其描述能力超過一般正則表達式(即:III型文法),可以比較好地應對各種不正確使用的情況,但如早前的申請所述,可能會導致一些意料之外的錯誤處理;經人工複查,測試編輯存在下列問題
      1. 修正後的日期格式一律為ISO格式,這可能不符合英文站MOSDATE指引關於日期格式應「先到先得」、「全條目統一」的要求;然而本站MOSDATE指引無此「先到先得」之要求,且本站絕大多數條目選用ISO格式的日期,更正為ISO格式導致條目格式統一的概率遠大於破壞條目格式統一的概率;過往討論和引用模板的提示亦傾向於使用ISO標準格式。考慮到兩站共識的差異,本次任務若批准,仍將維持修正目標為ISO標準格式,不考慮修改;
      2. 修正後可能會刪去一些不相關的字串,如Special:Diff/64406914,該等修改並無害處(因人工處理結果也是直接刪去這些字串),不考慮改進;
      3. 下列七個條目存在因出版物編號而導致的錯誤修正,已全數回退:7次回退
  • 補救方式:在修正不合規範的日期串之前,強制排除具有出版物編號意味的字符(版、卷、期、印、刷、稿、編、第):若待處理日期串含有上列任何一個字符,則直接跳過不送入上述啟發式算法處理;
  • 修正結果:工作範圍與第一次嘗試相同的第二次嘗試沒有導致類似的錯誤編輯
  • 結論:本次測試分兩個階段,工作範圍是條目列表前100,000條,涵蓋各種類型的條目中各種類型的日期錯誤,經修正後可認為連續編輯270次無明顯錯誤,按此比例推算,全部處理完產生的錯誤編輯總數不超過25筆。日後會加強人工抽查,若發現其它意料之外的錯誤模式會及時修正。望予以批准。--Antigng留言2021年2月20日 (六) 17:53 (UTC)[回覆]
    其實就是選擇寧可漏掉也不出錯,還是寧肯出錯也不漏掉。我認為,正則似乎更不容易出錯,但可能漏掉?你的算法似乎會出錯,但不會漏掉?不知道我的理解對不對?--百無一用是書生 () 2021年2月21日 (日) 11:58 (UTC)[回覆]
    • 可以這樣理解。過去Liangent-bot採用正則表達式去匹配特定的錯誤模式(如匹配"yyyy/mm/dd"、"yyyy年0m月dd日"這兩種特定的錯誤格式,將其分別修正為"yyyy-mm-dd"和"yyyy年m月dd日"),假陽性率較低、但假陰性率較高;本人則是試圖讀入待修正的日期字串,去猜測其中數字的含義(比如,一個四位數後跟着一個「年」字,就猜測這是一個年份)從而提取出年月日參數,以標準格式輸出,理論上可能有較高的假陽性率(猜錯),但同時也能應對諸如這類事先難以預料的誤用。--Antigng留言2021年2月21日 (日) 12:29 (UTC)[回覆]
      我總覺得在需要修改的時候,我會選擇寧可漏掉也不出錯--百無一用是書生 () 2021年2月22日 (一) 02:26 (UTC)[回覆]
      上面分析的是理論情況。實際上無論選擇何種策略都要保證儘可能低的假陽性率和假陰性率,根據測試結果將事先沒有考慮到的意外情形納入考量。例如,採取第一種策略的時候,需根據測試結果補充冷門的錯誤日期格式,以降低假陰性率。採取第二種策略的時候,需根據測試結果排除意料之外的假陽性案例。
      具體就這個任務而言,按上述補救方法排除特定字符以後在整個主名字空間空運行產生的所有待修正的日期字串如該頁面所示,共1.6萬條。經人工檢查未發現明顯的錯誤修正,因而可以認為其在處理存量任務上是不會因為確保不漏掉而導致出錯的。至於增量方面,早期獲批的Wikipedia:機械人/申請/Antigng-bot/30也使用完全相同的算法處理格式錯誤的日期字串,近若干月的正式運行結果經人工檢查後亦無明顯錯誤處理,故可以認為增量任務導致意料之外的錯誤模式的可能性很小。何況這類錯誤即使發生,也很容易通過定期的人工抽查而排除。--Antigng留言2021年2月22日 (一) 13:44 (UTC)[回覆]
 正式批准運作 --百無一用是書生 () 2021年2月23日 (二) 03:03 (UTC)[回覆]