演算法缺陷導致s2twp「正則表達式=>正規表示式」無作用

[danny0838]

如題，雖然 TWPhrases* 有定義「正則表達式=>正規表示式」，但實際使用會把「正则表达式」轉成「正則表示式」。

我看不太懂C的程式碼，但就目前s2twp的配置檔看起來，程式似乎是先根據 STPhrases.ocd2 分詞，然後再對分詞後的片段做簡繁轉換和地區字詞轉換。由於 STPhrases 已經有「表达式=>表達式」一詞，原文會被切成「正则 表达式」，之後簡轉繁成為「正則 表達式」，由於已被切開，因此TWPhrases* 定義的「正則表達式=>正規表示式」無法匹配。

演算法可能需要改進，否則只有在STPhrases加入「正则表达式=>正則表達式」才能解決此問題。

[sgalal]

目前程式的分詞和轉換都是正向最長匹配。

我目前使用的解決方法是將轉換拆成兩個步驟，類似於將

opencc -c s2twp

改為

opencc -c s2t | opencc -c t2twp

這樣兩個步驟分別使用兩個詞典分詞，就不會出現這個問題。

[danny0838]

如果是這樣，那直接把 s2twp 裡面的 segmentation 拿掉就可以了。

但我猜原來加入這個分詞機制是有原因的，應該是為了避免 s2t 以後 t2twp 在不適當的地方分詞。比如 s2t 詞表有「万用字元=>萬用字元」、「数据=>數據」，t2twp 詞表有「數據=>資料」「元數據=>後設資料」，那麼「万用字元数据有问题」就會在轉成「萬用字元數據有問題」之後被轉成「萬用字後設資料有問題」。

所以才會先用 s2t 詞典切詞，讓原句變成「万用字元 数据 有问题」，簡轉繁後變成「萬用字元 數據 有問題」，以避免「元數據」被轉成「後設資料」的問題，結果輸出為「萬用字元資料有問題」。

[BYVoid]

更好的辦法應該是改進分詞算法，使之不再依賴單獨的詞典分詞。可以依據整個詞典鏈來。

[danny0838]

更好的辦法應該是改進分詞算法，使之不再依賴單獨的詞典分詞。可以依據整個詞典鏈來。

魔鬼藏在細節，問題在於怎麼實做。

我想到的做法是先把詞典鏈裡的所有詞典合併成單一詞典，轉換時就用該合併詞典做轉換。

因為合併時是把各組的詞典串聯生成更大的詞典，因此可以避免不適當的斷句，也可以說就是「根據整個詞典鏈」分詞。

舉例來說，本來有 A 詞典組和 B 詞典組，首先先把各詞典組中的詞典「並聯」（全部載入及去重，類似目前的 merge.py 腳本）成 A 詞典和 B 詞典。

然後再把 A 詞典和 B 詞典「串聯」，具體做法是合併以下兩組運算結果，即可生成合併詞典：

• A 後聯 B：把 A 詞典的每個轉換結果用 B 轉換。例如 A 詞典有「为=>爲」，B 詞典有「爲=>為」，則轉換成「为=>為」。當然還要加上 B 本身的「爲=>為」。這主要處理 A 詞典輸出比 B 詞典輸入長的情況。
• B 前聯 A：對於 B 的每組 x => y1, y2, ..., yn，透過 A 詞典的轉換表列舉出「所有經過 A 詞典轉換後會形成 x 的詞 x1, x2, ..., xm」，個別生成 x1 => y1, y2, ..., yn; x2 => y1, y2, ..., yn; ...; xm => y1, y2, ..., yn 的轉換組合。比如 A 詞典有「数=>數」「据=>據据」，B 詞典有「元數據=>後設資料」，則生成「元數據=>後設資料」「元数据=>後設資料」「元数據=>後設資料」「元數据=>後設資料」。這主要處理 A 詞典輸出比 B 詞典輸入短的情況。

因為這個合併詞典是對「万用字元」「元数据」等詞直接做一次轉換，因此遇到像「万用字元数据…」的句子便不會像做兩次轉換的做法那樣把「万用字元」轉成「萬用字元」後又把「萬用字元數據」轉成「萬用字後設資料」。同理，也不會在遇到像「字符数据」這種句子時在轉成「字元數據」後又把「字元數據」轉成「字後設資料」。

除此之外，這樣做還有其他好處：

1. 合併詞典可以預先儲存起來，轉換時只需載入一個詞典、做一次轉換，可以提高載入速度和轉換速度。
2. 由於實際上只需要一次轉換，因此很容易處理一對多或對轉換過的內容加標記。

至於缺點……由於詞典串聯需要比較多運算，生成合併詞典速度會比較慢，而由於生成的詞組眾多，合併詞典檔案也會比較大，再加上每個轉換方案都要個別生成一個合併詞典，就會需要更多空間（如果即時組合，載入速度可能會慢到不能接受）。另外是這做法目前綁定「最大正向分詞」演算法，如果要改分詞演算法，則合併詞典的分詞演算法也會不同，則不能使用相同詞典，必須另外生成不同的合併詞典。

實做方面，我寫的 Python 程式已經做出來了，可以參考。不過用 Python 寫的速度畢竟會比較慢，目前實測轉換文本大約需要 OpenCC 3 倍左右的時間。

[frankslin]

试了一下，改用「结巴」分词后，这个就可以正确处理了： https://opencc.js.org/compare?t=%E6%AD%A3%E5%88%99%E8%A1%A8%E8%BE%BE%E5%BC%8F

[frankslin]

不过正如 OP 所说，不改 mmseg 的分词算法，只需在 STPhrases.txt 里面加一条「正则表达式 -> 正則表示式」也应该可以解决这一问题了。词典里已经有「正则参数」的先例了：
https://github.com/BYVoid/OpenCC/blob/733a9fe6bcd6a1dfaf0fd2b9dacbc2a52e7a65f6/data/dictionary/STPhrases.txt#L31070C1-L31070C5

以后可要求 TWPhrases / TWPhrasesRev 中引入新词组时，添加 s2twp / tw2sp 测试；如果测试通不过，就需要再加 STPhrases 词组。

[danny0838]

結巴分詞不能真正解決問題，「正则表达式」之所以能正確處理，只是因為結巴的詞庫恰好有「正则表达式」這個詞，換成其他詞庫沒有的詞還是會出錯，比如，輸入反向的「正規表示式」，tw2sp_jieba 輸出的是「正规表示式」而非「正则表达式」。

再如，TWPhrases 有個詞是「元數据↔後設資料」，但如果輸入「元数据」，s2twp 和 s2twp_jieba 都是輸出「元資料」，因為 STPhrases 有「数据→數據」，結巴詞庫也有「数据」，導致「元数据」被切成「元 數據」之後就無法順利轉換成「後設資料」。要避開此問題恐怕得額外把「元数据」加到 STPhrases 和結巴詞庫。

此外，如果 輸入「後設資料」，tw2sp 會輸出「元数据」（正確），而 tw2sp_jieba 卻會輸出「后设数据」（錯誤）。結巴詞庫沒有「後設資料」這個詞，但輸入「後設資料」會切成「後 設資料」，導致「後設資料→元數据」的轉換失效。結巴詞庫並沒有「設資料」這個詞，為什麼這樣切我也不清楚，這又印證了之前說過的，分詞系統可預測性不佳的問題。

---

在 STPhrases/TSPhrases 加詞並不是好方法，因為這兩個詞典本來就不是用於台灣地區詞轉換，把台灣地區詞專用的詞加進去會造成汙染，根本上就破壞了一開始分詞典的初衷，還可能導致其他使用同一詞典的轉換方案（例如 s2hk）發生非預期的錯誤。

真要走這條路線，不如擴充 segmentation.dict 使之像 conversion_chain.dict 一樣接受多重詞典，然後把「元数据」之類需要額外加入的詞加到另一個檔案 STPhrasesTW.txt，並且把 s2twp 的 segmentation 改為用多個詞典分詞：

  ...
  "segmentation": {
    "type": "mmseg",
    "dict": {
      "type": "group",
      "dicts": [{
        "type": "ocd2",
        "file": "STPhrasesTW.ocd2"
      }, {
        "type": "ocd2",
        "file": "STPhrases.ocd2"
      }]
    }
  },
  ...

這樣至少可以做到確實分離，但人工維護 STPhrasesTW, TSPhrasesTW 等詞典終究還是比較麻煩且易遺漏，最好還是能像我前面說的，直接改進演算法確實做到用整個詞典鏈分詞。

[frankslin]

理解你的意思了。config 中的 segmentation 现在就是支持 group 的，用法可如下述 diff。但是让它支持按「转换链中的最长匹配分词」，具体是怎么修改，语义上不太明确。根据我对算法的理解，分词和转换是两个步骤，分词阶段确立转换的边界。如果分词时没能把「元数据」当成一个词，就算后续词典链里有「元數據」，也匹配不上。假设真的能够把「链式转换」压缩成一次转换，不如直接把词表变成一个固定的、自动生成的一次转换对照表，最长匹配同时用于分词和转换。这会比修改算法把链式转换中某一层的「元數據 / ...」应用到输入字符串里的「元数据」容易得多。（当然之所以没有这样做，应该是因为这样做不可行。）

这就是为什么现有机制下，一定需要给 STPhrases 里面加词才可以修好「元数据」的 s2twp 转换，而换用分词算法，有可能能解决一些未知词的问题（同时也可能因词表不同带来新的问题，这就要靠 regression test 来保证了）。

diff --git a/data/config/tw2sp.json b/data/config/tw2sp.json
index 64eb9d9..b66aed6 100644
--- a/data/config/tw2sp.json
+++ b/data/config/tw2sp.json
@@ -3,8 +3,14 @@
   "segmentation": {
     "type": "mmseg",
     "dict": {
-      "type": "ocd2",
-      "file": "TSPhrases.ocd2"
+      "type": "group",
+      "dicts": [{
+        "type": "ocd2",
+        "file": "TSPhrases.ocd2"
+      }, {
+        "type": "ocd2",
+        "file": "TWPhrasesRev.ocd2"
+      }]
     }
   },
   "conversion_chain": [{

[danny0838]

前面的範例給錯了(已修改)，應該是 STPhrases 等詞表才對，這裡不能直接把 TWPhrases.ocd2 加入，因為要加進詞表的是「元数据」而非「元數據」，甚至還要加上「元數据」、「元数據」等經過 STPhrases 轉換會恰好成為「元數據」的詞。

換成 TSPhrases 同理，不能只是把 TWPhrasesRev 加入，這樣做雖然對「後設資料」的例子有效，但遇到 TSPhrases 詞較長的例子仍會失敗，要增加獨立的檔案才行。

如前所述，我說的演算法已經用 Python 實現了，這裡也有線上版可測試（轉換方案選擇 oc/* 即是使用 OpenCC 1.1.9 的詞表），對於前述的「正则表达式」、「元数据」等例子目前都能正確處理。不否認可能還有我尚未想到的潛在問題使得本方案實際上不可行，不過目前為止還未有人提出過理由證明不可行，我就姑且當作只是還未實測過。