我找到一個理由說服大家不要採用

音找字的模型 ( 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/phras...
http://svn.openfoundry.org/openvanilla/trunk/Modules/OVKPPhraseTools/

還想不出捷徑來生 智能注音 ... ( 其實就是注音詞庫輸入法啦 )

奇怪, 沒辦法訂 openvanilla-developer-requ...@lists.openfoundry.org
有人能幫我轉進去嗎 ?

--
Pofeng "informer" Lee, 李柏鋒, pofeng at gmail dot com

old *.cin 跟 ljm 這篇 blog 講的應該是不同的事情？
我以為，ljm
在乎的是，有些音總是不齊全或不符合一般習慣。

酷音已經是了？

那句話的意思大概是說，因為 character-based
(以中文「字」為單位）n-gram 裡，
tri-gram 或 bi-gram 的效果必然比 uni-gram 好。
另一方面，如果先斷詞再做 word-based
(以中文「詞」為單位）n-gram，
uni-gram 的效果已經不錯了。畢竟，這裡的 uni-gram
其實已經有可能是
character-based 的 bi-gram 或 tri-gram 了。
（因為中文詞多半是二或三字詞）

我轉進去了。:)

2006/6/23, b6s <barab...@gmail.com>:

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 ( 躲起來 )
--
Pofeng "informer" Lee, 李柏鋒, pofeng at gmail dot com

「直接從注音 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
的意思，他要做的事情不是弄個「新的」模型，只是想把舊模型裡被省略掉（全部被當成機率為一）的東西補回去。

我想，邏輯上「單字詞問題」和「音轉字模型不好」並不是互斥的。好的機率模型並不會厚此薄彼，問題是我們餵進機率模型的東西是不是符合需求？

我想，您指的詞庫輸入法其實是 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，照著該文做一遍是可以的。:)

在 2006/6/28，b6s <barab...@gmail.com> 撰寫：

ㄚㄚㄚㄚ..... 我是騙人布啦 :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-S...

對呀, 不同的語境 (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/5df...

沒哪麼偉大啦 ...
看您是要說 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 中啦
( 我這句在講什麼 ? )

--
Pofeng "informer" Lee, 李柏鋒, pofeng at gmail dot com

Bi-gram 中文應用範例：以 C# 實作
(http://b6s.blogspot.com/2006/07/bi-gram-c.html)