音找字 vs 音找詞
Pofeng Lee
音找字的模型 ( old *.cin ) ( http://ljmid.blogspot.com/2006/05/blog-post.html )
應該採用 音找詞 的模型
"从操作心理学上看，操作人员倾向于按有一定意义的短语或句子为单位进行短时记忆、持续输入。
从信息论角度讲，汉字的多维熵要少于一维熵，语句输入法比字词输入法需要较少的输入信息。"
( http://www.insun.hit.edu.cn/news/view_cn.asp?id=297 )
夏農的資訊理論我有聽過, 但是那個就多维熵就不知道了
我猜, 用 OV Phrase 應該就可以作智能拼音了
( 只是詞庫可能要加個 weight or freq )
( 如果可以, 我可以幫忙生 sql , 但沒有機器可以測 :p , I use cygwin )
ci 詞
ci 慈
ciyin 詞音
ciyin[ 詞 ( 表面上字根變多了, 但是節省選字的時間 )
( 以詞定字: 使用「[」和「]」進行以詞定字。 如：你要輸入一 個「技」字，你可以使用「技術」這個詞來定「技」
這個字，你只需輸入「jishu」後再鍵入「[」，然後 再輸入「技術」一詞，即可以得到編碼為「技術」的
第一個字，這樣速度可以明顯加快。同理，若鍵入的 是「]」，那麼你就可以得到「技術」的第二個字。)
( from http://www.opencjk.org/~yumj/chinput/tricks.html )
http://osxchat.blogspot.com/2006/01/openvanilla_20.html
http://svn.openfoundry.org/openvanilla/trunk/Modules/SharedData/phrasedb-example.sql
http://svn.openfoundry.org/openvanilla/trunk/Modules/OVKPPhraseTools/
還想不出捷徑來生 智能注音 ... ( 其實就是注音詞庫輸入法啦 )
奇怪, 沒辦法訂 openvanilla-de...@lists.openfoundry.org
有人能幫我轉進去嗎 ?
--
Pofeng "informer" Lee, 李柏鋒, pofeng at gmail dot com
b6s
Pofeng Lee wrote:
> 我找到一個理由說服大家不要採用
>
> 音找字的模型 ( old *.cin ) ( http://ljmid.blogspot.com/2006/05/blog-post.html )
old *.cin 跟 ljm 這篇 blog 講的應該是不同的事情？
我以為，ljm
在乎的是，有些音總是不齊全或不符合一般習慣。
> 應該採用 音找詞 的模型
酷音已經是了？
> "从操作心理学上看，操作人员倾向于按有一定意义的短语或句子为单位进行短时记忆、持续输入。
> 从信息论角度讲，汉字的多维熵要少于一维熵，语句输入法比字词输入法需要较少的输入信息。"
> ( http://www.insun.hit.edu.cn/news/view_cn.asp?id=297 )
>
> 夏農的資訊理論我有聽過, 但是那個就多维熵就不知道了
那句話的意思大概是說，因為 character-based
(以中文「字」為單位）n-gram 裡，
tri-gram 或 bi-gram 的效果必然比 uni-gram 好。
另一方面，如果先斷詞再做 word-based
(以中文「詞」為單位）n-gram，
uni-gram 的效果已經不錯了。畢竟，這裡的 uni-gram
其實已經有可能是
character-based 的 bi-gram 或 tri-gram 了。
（因為中文詞多半是二或三字詞）
Tian-Jian "Barabbas" Jiang@Gmail
Pofeng Lee
> old *.cin 跟 ljm 這篇 blog 講的應該是不同的事情？
> 我以為，ljm
> 在乎的是，有些音總是不齊全或不符合一般習慣。
ljm> 簡言之，如果我們建立一個直接從注音 map 到漢字的
ljm> language model (HMM 或其他辦法)，應該可以改善現行的詞庫、頻率等等方法
我以為 ljm 是要找出新的音轉字的模型來改善酷音 ?
chewing 比不上 going 的原因, 我直覺是因為
單字詞的問題, 並不是音轉字的模型不好
eg:
扳機, 扳機指
磁性, 雌性, 詞性
三隻貓, 三枝筆, 三芝貓空
要解決詞和詞之間的關係, 方法很多
( eg: 機率 or 詞頻 or 詞性 or 模板 )
但是在 tsi.src 的格式未變之下, 改變演算法應該幫助不大
( sorry kcwu, 潑您冷水 )
( 或者讓 google 輸入法去作也是可以啦 )
scim-pinyin 好像開始加入詞性了
所以, 我才會覺得, 在輸入法的層次, 加入詞庫輸入法比較重要
( like: gcin 的 *.cin table )
http://www.csie.nctu.edu.tw/~cp76/gcin/gtab-phrase.png
而且在 chewing 的層次上, 我並不是很在乎斷詞, 猜詞 是否正確
因為我只要看到對詞就會趕快送出去 ( 選詞比較花時間 )
> > 應該採用 音找詞 的模型
> 酷音已經是了？
是呀, 但是, 因為有四聲, 所以其實是先轉成字音再查詞音
所以會有 "總統" 兩個三聲的問題
無調漢語拼音反而避過了這個問題
但缺點:
xian 先 仙 線
xi'an 西安 錫安 西岸
再舉例:
拼音 ㄆㄧㄣ<space>ㄧㄣ<space> 7 個 key ( 但不用選詞 )
拼音 piny1 ( 1 是選詞 ) pinyin ( 六個 key, 不選詞 )
聘用 piny2 pinyong
聘約 piny3 pinyue
--
還是詞庫輸入法比較簡單啦, 嘴砲完畢, 還是沒有 patch ( 躲起來 )
b6s
> 2006/6/23, b6s <bara...@gmail.com>:
>
> > old *.cin 跟 ljm 這篇 blog 講的應該是不同的事情？
> > 我以為，ljm
> > 在乎的是，有些音總是不齊全或不符合一般習慣。
>
> ljm> 簡言之，如果我們建立一個直接從注音 map 到漢字的
> ljm> language model (HMM 或其他辦法)，應該可以改善現行的詞庫、頻率等等方法
>
> 我以為 ljm 是要找出新的音轉字的模型來改善酷音 ?
「直接從注音 map
到漢字」的意思是，目前用來做輸入法的模型，在（當年）缺乏資料且記憶體不足的情況下，音和字之間的關聯是齊頭式平等，破音字的各種發音之間沒有機率關係，頂多
只有 .cin 檔裡的先後順序而已。
缺乏資料的原因是，除了國語日報之外，很少有完整音節和漢字並列的語料庫可供統計；另一方面，就算拿國語日報來統計，書面語的用詞及其音標，和口語有一定程度的差異。而
ljm
想做的，主要是改善後面這個問題，補足日常用語的音標，特別是在使用者通常不會乖乖打破音字發音的情況下。反過來說，「總統」的問題也一樣，有些使用者可能不會照著標準的聲調輸入。
為什麼要有音->字的統計關聯呢？這要從 (n-gram) language
model 與 HMM 的差異說起。又為什麼要提 n-gram
呢？因為酷音的原理是簡化過的
uni-gram。所謂「簡化」，在於酷音裡評分的標準是字詞的「頻」率，而不是「機」率。這樣做有兩個問題：第一，直接用詞頻時，僅出現一次和出現過十次的字詞，在評分時會造成相當大的落差，然而這完全是語料的
bias，無法代表現實生活中的傾向；第二，「新詞」或「未知詞」在原始語料中的出現次數為零，但新詞或未知詞之所以成詞，表示它在現實生活中出現的「機率」並不是零。然而，若想要替這些妾身未明的詞加上某個次數，便破壞了原始模型裡的分布，恐怕會在某些地方引發連鎖反應。
真正的
n-gram，首先要用次數除以語料中詞彙的總數而得到機率，接著要用某些方法替「未知事件」分配一個很小很小的機率。而這個小小機率畢竟是無中生有，原始模型中所有的機率都要重新
normalize 來符合所有事件機率相加等於一的基本要求。
那麼，為什麼 n-gram 是簡化過的 HMM
呢？先轉個方向，想想語音辨識的流程。從聲音訊號轉換成某些音節單位，從某些音節單位再轉換成字詞，這樣基本上是兩個階段。輸入法其實可以視為比較容易的語音辨識問題（即使是字根式輸入法也可以這麼看），因為系統不必做訊號處理，我們已經直接輸入音節單位的符號了。但
HMM
無論在那一個階段，內部流程用到的機率也不只一種：某音節
Sa 和某音節 Sb 相鄰的機率、某音節 Sa 轉換成某字詞 La
的機率、某音節 Sb 轉換成某字詞 Lb 的機率、某字詞 La
與某字詞 Lb
相鄰的機率。目前採用機率模型的輸入法，就我所知全部都只用了最後一種。
小結一下，如果我沒誤會 ljm
的意思，他要做的事情不是弄個「新的」模型，只是想把舊模型裡被省略掉（全部被當成機率為一）的東西補回去。
> chewing 比不上 going 的原因, 我直覺是因為
> 單字詞的問題, 並不是音轉字的模型不好
> eg:
> 扳機, 扳機指
> 磁性, 雌性, 詞性
> 三隻貓, 三枝筆, 三芝貓空
我想，邏輯上「單字詞問題」和「音轉字模型不好」並不是互斥的。好的機率模型並不會厚此薄彼，問題是我們餵進機率模型的東西是不是符合需求？
> 還是詞庫輸入法比較簡單啦, 嘴砲完畢, 還是沒有 patch ( 躲起來 )
我想，您指的詞庫輸入法其實是 uni-gram
的一種特例，採用資訊檢索常見的 "pattern"
而不那麼在乎斷詞問題。這基本上是可行的，但輸入法與資訊檢索的需求有一處不同：此時這些「詞」的詞頻必須互斥。舉例來說，「扳機指」若出現了
n 次，「扳機」出現的次數就不可包含那 n
次。對資訊檢索來說則不必如此。這樣的方式在某些單字詞問題上的好處是，把以前需要做
bi-gram 或 tri-gram
的東西直接黏在一起，像「週休二日」這種
pattern，斷詞標準不同，可能會被切分成不同的單位，但實務上直接視為一個單位比較方便。而這種方式的缺點是破壞了語言本身的自然現象帶來的預測能力。舉例來說，中文裡絕大多數的字都是自由詞素，常用的單字總是有機會被拿來跟別的字詞搭配成新詞；然而，當我們採用「互斥」詞頻時，詞長愈短的詞愈容易被孤立。要是不採用「互斥」詞頻，那麼就跟
uni-gram
沒有太大差異（只有斷詞標準不同），於是我們就回到原點了。上述說法，請參考
"The Properties and Further Applications of Chinese Frequent Strings"
(http://www.aclclp.org.tw/clclp/v9n1/v9n1a7.pdf)
一文。所以如果要 patch，照著該文做一遍是可以的。:)
Pofeng Lee
ㄚㄚㄚㄚ..... 我是騙人布啦 :p
所以我們現在是 the red pill or the blue pill 之爭 ?
The Great Divide in NLP: the red pill or the blue pill?
http://ocw.mit.edu/NR/rdonlyres/Electrical-Engineering-and-Computer-Science/6-863JSpring2003/D286AE00-A87D-4F7D-8D37-C893FDDA6904/0/lecture4bw_03.pdf
> 我想，邏輯上「單字詞問題」和「音轉字模型不好」並不是互斥的。好的機率模型並不會厚此薄彼，問題是我們餵進機率模型的東西是不是符合需求？
對呀, 不同的語境 (context, corpus, lexicon, domain knowledge)
就會應該會得到不同機率 (模型) 吧 ?
那我們要訓練一個超級宇宙完美終極解答 (42 !?) , 還是一邊一(國)模型 ? (笑)
不懂 HMM ( hmmmm 倒是很厲害 )
所以只好用笨方法, 讓 user 讀入所有自己的文章, 創造自己的詞庫
( tsiguess -d mytsi.db < *.txt )
或許我們可以寫個 HMM_train < *.txt
想法 (according Shawn's analysis )
一. 如果有完全符合單一使用者使用習慣的詞庫 (userspace lexicon, 亂發明的)
那麼, 詞性, 詞頻都不重要
(對我來說,96%[2]~95.7%[1] 跟 91%~93%[2] 實在是差不多 )
二. 因為我們無法完美的自動產生 userspace lexicon
所以需要在 userspace 輔以 詞性, 詞頻, HMM
1.http://www.iis.sinica.edu.tw/IASL/cnews.htm
2.http://groups.google.com/group/chewing-devel/browse_thread/thread/5dfb6c955b19d1dd/7991e2e4cabd3cea
> > 還是詞庫輸入法比較簡單啦, 嘴砲完畢, 還是沒有 patch ( 躲起來 )
>
> 我想，您指的詞庫輸入法其實是 uni-gram
> 的一種特例，採用資訊檢索常見的 "pattern"
沒哪麼偉大啦 ...
看您是要說 key-value, hash, ( 或是 grep 都可以啦 :p )
的確應該還是要再念一下 n-gram & pat-tree
( pat-tree + plone 真的有人做出來了嗎 ? )
看了一些資料, 不知道, 還要再想一下 morpheme,root,prefix,suffix
看完之前先虎爛一下:
如果英文有 19782(?) 多個字母 (big5 可定義總字數), 而其中有 13060+ 個字母,
只要單獨一個就可以成為單字, n-gram 還有意義嗎 ?
( 難怪 Dr 簡立峰 要去 google (笑) PC 就是力量呀 !! )
其實也有點像把中文 prefix, suffix, par-of-speech 壓縮在一個 HMM 中啦
( 我這句在講什麼 ? )