dict加入一个词条，就会使其它词条无法显示

[xiaoqun2016]

用的是最新brise中的朙月拼音。正常输入时是这样：

若在词典中加入一个中英混合的词条，比如K歌：

---  
name: luna_pinyin  
version: "2015.06.15"  
sort: by_weight  
use_preset_vocabulary: true  
...  

K歌    k ge  
〇 ling  
ㄓ zhi  
ㄔ chi  
ㄕ shi  
ㄖ ri  
ㄗ zi  

仅改动这一处，重新部署后，输入kge，原先可以正常显示的词条都不见了，只能显示「K歌」一词：

更严重的是，单独输入k时显示的是空码，k的简拼都没了：

以k开头的词条必须输入全拼才能显示：

词典中只要混入了这样的有单个声母做编码的词条，就都会这样

暂时的解法：

• 中英混合词条编码不留空格。比如用kge代替k ge
  缺点是中英混合词条无法用简拼kg来打
• 先用拼写运算xform/^([b-df-np-z])$/$1_/处理，再取首码简拼。（贴吧@imy0823的做法）

请问：以上rime「单独输入k，就只返回空码」的现象是不是bug？

[xiaoqun2016]

从各种现象来看，rime应该是有这样一个内部逻辑：_如果可以检索到全拼词条，就忽略简拼。_
出现空码的原因可能是这样：

按照拼音的编码方式给「Kk歌ge」编码，应该是：

K歌    k ge  

正常情况下由这个词组拼音反推，理应有个单字「K」的全拼是k。rime可能由此默认k存在全拼词条，所以当输入k时，会忽略简拼。但实际上这种中英混合的词条是独立存在的，并没有词条「K」与之对应。于是输入k时，显示的是空码。

这应该是一个意外事件，也许可以定义为bug，但可以通过技巧规避。

---

抛开这个问题，再来审视一下这无意中发现的「rime的内部逻辑」。
由于还没看懂源码，只能从侧面观察一下：

在词典中加入这个词条

CD  cd  

那么，rime会不会把简拼为cd的词条隐去？
打打看！
原先输入cd时的候选是这样：

加入词条「CD」后变成这样：

虽然还有空间来呈现更多候选，但由于找到了全拼的匹配词条，「程度」「成都」这些词都被隐去了。
不仅仅这样，再看
局部含有cd的词条也受到影响了
原先输入cdqu有很多简拼词组：

现在都没了

原以为简拼的优先级比较低，仅仅是排位比较靠后，没想到的是简拼与全拼相遇时，简拼完全不显示，即使词库中有这个词，即使全拼的词很少乃至为零，rime宁可生造一个符合全拼规范的坏词，也不让正确的简拼有丝毫出场的机会。

由于拼音编码比较规范，这种矛盾并不容易出现。像上面这样由中英混合词条所带来的问题也可以通过技巧规避。但是在各种复杂的方言方案中，就很难避免了。

想起去年贴吧里就有一个类似问题：rime能否优先显示词库中已有的词
这是一个中古拼音方案

引用部分原帖<
有以下几个字的编码：
好：hao
吧：paa
呵：ha
鞥：op
庵：om
吗：maa
我想打“好吧（haopaa）”，当输入完“haop”就想让它显示出来，可是显示的却是“呵鞥”，我想打“你好吗（nerhaomaa）”，当输入完“nerhaom”就想让它显示出来，可是显示的却是“你呵庵”，词库中明明有“好吧”、有”你好吗“而无“呵鞥”、无”你呵庵“，rime却先显示自造词。
不知道怎么设置才能输入编码时优先显示词库中已有的词。如果词库中没有这个词时才显示字造词。

后来在那个中古拼音方案中，首字母简拼的拼写运算改用模糊替代了缩略。改过之后，不知道这还算不算简拼？由于简拼与全拼优先级变成一样，由于词频的作用，全拼词条有可能会被简拼挤到后面去。这样对整句输入的效果必然会有影响。现在有点怀疑，这是不是好办法？

所以，现在新的问题是rime的内部逻辑合理吗？rime的简拼能不能做得更好点？

[lotem]

這是由配置（輸入方案）指定的行爲。
我現在來解釋一下，這項配置是用來解決拼音輸入法裏的什麼問題的。

實現音節首字母簡拼的配置爲 abbrev/^([a-z]).+$/$1/，含義是可將多於一個字母的音節簡寫爲其首字母。
此處的音節來自於音節表，即所有出現在詞典中的音節。
簡寫，與音節表中原有的音節一起用於切分，但兩者的作用不完全等同。

乍一看，既然簡拼也是編碼中的一種，他用來擴大索引的範圍，新增的英文詞也只不過添加了一種新的編碼，用於索引這個新加入的英文詞，那麼增加新詞應該只增加新結果對嘛。可是簡拼不能簡單地與全拼等同，視爲問題的一個解；他其實只是「可能存在」的一個解。

簡拼之所以好用，是因爲大多數簡拼並不存在於拼音的音節表中，他是利用了閒置的編碼來縮短輸入。
但在拼音裏面，的確存在少量單字母的音節，即 a, o, e 等。他們既可看作完整的音節，也可作爲 ai, an, ang, ao, ou 等音節的簡拼。那麼問題來了：

一、輸入 aqing，期望的結果爲「阿慶，阿晴」等等，將 a 作爲全拼解讀，而不是「愛情，安慶，案情」之類，將 a 當作簡拼檢索。是否存在「阿慶，阿晴」這些詞組，我們不能做任何假定，即使詞典中缺少這些詞組，用戶應該可以手動選擇該讀音下的單字造出想要的詞組。並且我假定用戶此時需要輸入法幫助他完成這一造詞動作，而非模糊查詢詞典中列於其他讀音下的詞語。——理由是用戶的精確輸入應當被輸入法無誤的解讀。
這就涉及到對「簡寫」（或者在拼音輸入法裏叫做簡拼）地位的認定，他是對精確輸入的補充，意在利用空閒資源（編碼空間）簡化部分輸入。因爲是附加價值，他無須保證完整性，即並無必要給出與其匹配的 全部 字詞——因爲簡拼理論上可對應衆多選項，很多輸入法只給出最常用的部分選項。但對於「全拼」而言，完整性是一項要求，其標準是：只要輸入了完整的拼音，即便是詞典裏沒有的隨機組合，也要有辦法通過輸入法打出。

二、若輸入爲 aq，此輸入在本方案裏只能解讀爲簡拼，因此他可以對應「安全、愛情」等詞語，當然也包括首音節爲 a 的詞語。

三、輸入爲 xierqi，解作「西二旗」（地名）而非「寫日期」，雖音節切分不同，當以全拼優先。

四、輸入爲 tang，解作單字「湯」及其同音字，候選列表中不應有「貪官」、「他能夠」等包含簡拼的切分。

綜合以上數例，得出與本題相關的一條規則。
相對於全拼，簡拼的使用場合是有限制的。簡述爲：
可以構成精確編碼的輸入碼，不應將其另作解讀爲簡寫，以免由不契合輸入碼本意的選項造成干擾。

再來代入原題：

「K歌」註音爲 k ge，這裏引入了一個不存在於拼音音節表中的 k 編碼。
姑且假設 K 及相容於漢語拼音系統，其音碼爲 k 。這些屬於人類認知的範疇，對於輸入法是不相關的信息。
在加入了該詞語的詞典中，「K歌」k ge 可類比「阿哥」a ge，兩者的編碼具有完全相同的結構，因此音節切分及詞典檢索過程也將是一致的。

輸入 age，所得爲 1. 阿哥 2. 啊 3. 阿 ... 锕，分別是讀音爲 a ge 的詞語，以及讀音爲 a 的單字。
這裏面不包括任何以 a 爲首字母的其他音節產生的選項，如「挨個、安、昂」等。這很好，且符合以上「精確輸入不另作解讀」的規則。
如果對此無異議，則可推出輸入 kge 所得爲 k ge 所對應的詞語「K歌」及 k 所對應的單字（無）。
——這裏還有一個問題，之前假設「K歌」這個詞可融入漢語拼音這一音系，如果認爲 k ge 分爲兩個音節，又知「歌」拼音爲 ge，那麼「K」應當被認作 k 音所轄的單字。按理詞典中應該設置單字「K」。

「CD」註音爲 cd，他沒有音節結構，於是引入了一個新的編碼 cd。
「朙月拼音」詞典中原有內容沒有與其結構完全一致的，姑且拿較爲相似的「擦」ca 來對比。
輸入 ca，結果只有「擦」及其同音字，不切分爲簡拼 c a 「長安、草案」等。
輸入 ca qu，結果爲詞語「擦去」及單字「擦」等。不切分爲 c a qu。
於是有：
輸入 cd，結果爲整體認讀詞語「CD」。他沒有同音字詞。
輸入 cdqu，結果爲「CD區」，無「城東區」。

對於一部機器，相同的輸入應當產生相同的輸出。如今看來原先的設定都有其道理——本方案之所以如此設定，（僅）是爲保證出廠產品按照設計工作。那只能說，後來出問題的部分不該代入原先設定的規則。

對於一部機器，不同的輸入產生不同的輸出是很常見的。所以修改方案和詞典後，得到與修改前不同的結果，不應感到過分意外。

論「內部邏輯」。專門的「漢語拼音」輸入法才把規則做成內部邏輯，因爲已知只須支持一種「漢語拼音」。而 Rime 是數據驅動的，輸入法的行爲大多取決於輸入方案和詞典。

如果把拼音輸入法僅僅看作純粹的字符串匹配，當然也能寫出「詞庫中已有的詞永遠優先」的輸入方案。
但我十分懷疑這種做法，如果該方案當真屬於拼音輸入法卻完全無視音節結構，那他可能會經常給你吃驚。

回到原題。

包含英文字母的中文詞，這個輸入需求與「中文夾雜英文單詞」不盡相同。
事實上人們在意識裏，雖然不認英文字母爲漢字，卻也把一個字母當一個字來看。
但是把字母本身作爲編碼加入拼音詞典，我看邏輯上也有問題。
k 畢竟不是一個拼音呀，「K」也不讀作 k。
把「K」編碼爲 k，和把「啊」按漢語拼音編碼爲 a，這是兩種不同的編碼方式。
如果共存於一個詞典，這種差別就不能在詞典裏抹去，因爲以上討論說明了，他們性質的不同會影響到輸入法的期望行爲，所以詞典需要包含這部分信息量，以求能區別於「原來的」那個系統。

試舉一例說明。
前文已說明，詞典應包含用於構詞的單字母。
有了這些與漢字相當的元素，就可以通過輸入法構造包含字母的中文詞。
不然，有了「CD」只能造出「CD機」，無法造出「C盤」「D盤」。

A a'
B b'
C c'

這裏 a', b', c' 只是信手拈來，原則是，不想用 a, b, c 以致與拼音（簡拼）混同。
然後，讓簡拼 a, b, c 涵蓋這些字母的編碼： "abbrev/^([abc])'$/$1/"

如此，輸入 cpan，將切分爲 c pan。其中 c 是 c' 的簡拼，同時也是 cai, ci 等音節的簡拼，所以結果爲「裁判、磁盤、C盤」等。

[xiaoqun2016]

细想一下，确实单从拼音音节的划分规律来看，cd这个编码很明显不可能是全拼，它更接近简拼的形态。既然要把这个词「CD cd」融入拼音的词库，就理应按照拼音的规律将它当作简拼来用，标准统一才会有条不紊。
所以，把「CD」编码成「cd'」或者「c' d'」，再用拼写运算abbrev去掉辅助符号，这样做是合理的。「K歌」也同理，通常编码k不可能是某个词条的全拼，没必要为了一个词而破坏了拼音规则的整体性。特殊词条在融入主词库时，都有必要做这样的处理。

从这个方向来看，就比较容易接受对中英混合词的特殊处理了。

---

空码的问题已经解决了，但对rime规则的疑惑仍在。姑且听听我说的有没有道理：
（以下对规则的讨论不局限于某个拼音方案）

先看两个例子：
1、要打出「我在堆雪人」：
输入wzaiduixuer，可以正常打出：

输入wozaiduixuer，结果是「我在堆需而」？

我只是想把「我」的拼音补充完整，从而确保「我」被正确解读出来，结果「我」没变，后面的「堆雪人」反倒被打散了，变成意思不通的句子。

我知道这是由于rime的规则是全拼优先，简拼为辅，无需保证简拼的完整性。

再看
2、要打出「写日期的时候要注意格式」：
词库中已有「写日期的时候」和「注意格式」，且已经重复输入多次，具有较高词频
输入过程是这样的：

识别ok

然后：

简拼的优先级很低，很容易就被打散了

接着：

虽然对「西二旗」和「写日期」来说，xierq都不是全拼，而且「西二旗」只输入过一次，词频很低。但前者匹配了两个全拼xi er，所以总是占据绝对优先的地位。
这也在rime的规则控制之中，并不是意外。

（我了解rime具有很高的定制性，这里讨论的是默认方案的规则。之所以举这两个例子，是想捕捉出rime的规则特征，从而分析其合理性。平时不一定会这么打）

为什么这个规则看起来总是在搞破坏？

在例1中，rime把句子拆成了四个部分“我在+堆+需+而”，这合理吗？ （问题一）

通常我们造词造句是渐进的，是从小到大的：人→雪人→堆雪人→我在堆雪人。

我们应该优先假定词库中的基础词汇已经完备，因为对普通用户来说，他不会只挂一个单字库就要打整句的。只有极少数的方案初创者，或者有某种特殊需求的人，才会从零开始积累词库。所以，在这种条件下，我们更常做的是对现有的词做修饰或串连：

• 修饰：
  • 字+词 （擦玻璃）
  • 词+字 （明天去）
  • 字+词+字 （在哪里呢）
• 串连：
  • 词+字+词 （明天去郊游）
  • 词+词 （打酱油回来）

我们不太可能一下子就要造像 “词+字+字+字” 这类结构的词，因为这不但违背了造词的渐进原则，也不符合我们的假定。在现有的语言模型下，rime固然无法得知切分出的音节能够组成通顺句子的概率有多大，但rime可以检索词库得知切分出的音节是不是单字。对于「3个单字连续出现在句中」这种明显不可能的结果，应该果断降级，完全没必要死守着全拼优先这个规则。
我认同在某些情况下，「全拼的优先级应该比较高」。我觉得合理的理由是：拼音的单字和词组重码过多，若简拼的优先级与全拼相等，那势必会带来非常多的干扰项，使字/词的输入变得异常困难。 所以，单输入tang时，理应全拼优先，不能解读成简拼ta n g。但是随着句子越输越长，我们的目的就不再是打出一个单字了，我们是要拼出一个完整的意思，这时候就不能拘泥于「全拼优先」的规则了。

对于您说的这点：

但對於「全拼」而言，完整性是一項要求，其標準是：只要輸入了完整的拼音，即便是詞典裏沒有的隨機組合，也要有辦法通過輸入法打出。

我觉得，rime不能把造词当成用户的默认行为，用户应该是很讨厌造词的，除非输入法非常难用，他才会时时想着要造词。rime应该更优先地把用户的行为解读成要「串词成句」。
所以，像这样的结构：“词+字+字+字” 或者“词+字+字+词”或者“词+词+词+词” ，从汉语的语感来看是很少见的，就都不应该做为解读的首选。把它放在次选，给用户造这样的词增加一点点难度，但又不至于无法造出，把首选的位置让给更可能的组合。

**当我们使用rime一段时间之后，用户词典中就会生成许多比较长的复合词和短语。rime应该顺应这种变化，在这些长词的基础上再继续造词成句。但rime并没有给用户造的长词足够的优先级，为了适配局部的全拼，轻易地就把这些用户词放弃了（如例2）。**当然，如果没有这些局部全拼的存在，在简拼中，用户造的长句还是有优先权的，但光这样还不够。

对于rime，简拼好像只有三种写法，但都不理想：

• abbrev/^([a-z]).+$/$1/ #标准写法，全拼优先，简拼为辅
• fuzz/^([a-z]).+$/$1/ #简拼优先级在局部提高了，但只适用于完全匹配简拼时，一旦简拼参与组句，还是会优先解读成全拼
• derive/^([a-z]).+$/$1/ #同上

为什么简拼只能作为全拼的附属品，为什么不需要保证简拼的完整性？
我们换个视角看看： 在拼写一个句子时，声母（简拼）是主干，是必不可少的，而韵母是枝叶，用来修饰声母，当相同的主干有歧义时，再用韵母来区分。
一个句子就算全部用全拼，也未必都能精确拼写出来。简拼同样也不能，但是他能快速地勾画出主干，越是长句越高效。在例2的长句中，用户既然有自信一次打出这么长的句子，那他对所打的内容应该相当熟悉（相应地，用户词典也积累了与之相关的足够长的词组），那么他在长句的局部打全拼，是不是可以解读成是对简拼的补充？也许他的真正意图是想区分「xie写r日q期d的sh时h候」和「xiu秀r人q气d的sh时h候」。他打的全拼越多，如果每个全拼都能补全「写日期的时候」这个长词，应该越能确定这个长词的地位。 但rime在简拼全拼混输时，全拼越多，句子越长，就越容易打散长词。

不是“正确的全拼+正确的全拼”就能组出通顺的句子，也不是“高频的词汇+高频的词汇”就能组出通顺的句子。在考虑词频和全拼时，也应该兼顾句子的结构，输入法应该最大化地解读句中的意群，因为2+3比2+1+1+1更稳妥，6+1+4也比3+3+1+4稳妥。句子拆得越散就越容易出错。
再回过头看一下：


选两次就完成了，rime其实已经比其它输入法做得更好了，只差一点点就能一步到位了。只可惜我们没有途径可以配置，为这一点点的优先权的差别做微调。

综上，rime应该对句子切分出来的结构有所判断，不能唯全拼是从，rime应该引导用户渐进造词（让输入法最大化地解读句中的意群，不要拆得过于零散），使其养成正确的输入习惯（在输入过程中适时地敲空格确认前面已有的内容，逐渐丰富词库中有用的内容，形成良性循环）。在此基础上，进而对经过用户确认过的词组以及用户积累的长词，给予足够的优先权，而不论它是以简拼还是全拼的形式出现。

感谢您能耐心看完，以上仅是一位普通用户从k歌引发的一连串思考，也许有不对的地方，欢迎指正。

---

2016-03-05更正
这两天偶然看到《数学之美》，才对自然语言处理和统计语言模型稍有一点了解。身为门外汉，以上的一些观点还停留在比较原始阶段，基本没有什么可取之处。目前，统计语言模型应该是更有效更主流的做法。

[lotem]

是有這些問題。
得好好考慮一下。

wzaiduixuer 這一例反映的問題是，在輸入全拼的過程中會出現最末音節拼寫不完整的狀態（不限於簡拼）。如果這個輸入恰好可以切分爲另一個全拼串，按目前的算法會抑制簡拼以及尾音節補全（在無法完成切分時起作用，如禁用簡拼後，so -> (sou, song)）。也許這樣做過於保守，是在無法保證不引入干擾項情況下的無奈之舉（要兼顧其他輸入方案）。

這就引出下一個問題：如何支持在輸入方案裏配置算法裏用到的的規則和常數。現在已經出現了一些輸入方案必須通過定製參數保證輸入效果。看來這個是有必要做的。不過大多數方案應該不會定製這些參數，默認還是用保守的策略。

xierq 這一例，兩種切分都是簡拼，應該沒有優先級的差別，結果排序由計算出的概率決定。所以屬於整句結果的質量問題。句子越長，計算量越大，事實上用戶的反應時間不允許輸入法窮盡所有的計算，期望的結果有可能在中間某一步捨掉了。特別是長詞，如果本身詞頻較低，把他檢索出來的代價高，就很難入選。調參數未必能解決這類問題。還得靠改進語言模型。

[xiaoqun2016]

看了您的回复，从词频入手，又发现新的问题。我再举几个例子吧，希望能更准确地抓到问题所在。

这次不用全拼

1、要打出「希望他能够做到这样」。已经造好了一部分词，用户词典导出是这样的：

xi wang     希望  c=1 d=1.1 t=1
xi wang ta  希望他   c=1 d=1.1 t=2
xi wang ta neng gou     希望他能夠 c=1 d=1.1 t=3
xi wang ta neng gou zuo dao     希望他能夠做到   c=1 d=1 t=4
zhe yang    這樣  c=1 d=1 t=5

过程如下：

正常识别
接着：

被拆分了
在组句时，首选项还是趋向于拆散长词。这个长词「希望他能夠做到」其实已经检索出来了，但是放在第二候选。也许是长词词频太低，那就把用户词典的词频手动提高，再同步回去，现在是这样：

xi wang     希望  c=1000 d=980.297 t=5
xi wang ta  希望他   c=1000 d=985.21 t=5
xi wang ta neng gou     希望他能夠 c=1000 d=990.149 t=5
xi wang ta neng gou zuo dao     希望他能夠做到   c=1000 d=995.012 t=5
zhe yang    這樣  c=1000 d=1000 t=5

词频应该够高了，但结果输入时还是这样：

那把长词放到八股文，并给它一个词频，会怎样？
试试看：

〇六  505  
〇四  485  
希望他能夠做到   300  
㐀 0  

重新部署，再看

这次可以一气呵成打出了。再把八股文中的这个词的词频由300调到1，首选的长词又被拆散了。

八股文的词频很管用

再看看：
2、要打出「最强大脑在哪里呀」，之前已经造好了这些词：

zui qiang   最強  c=0 d=0.0970446 t=27
zui qiang da nao    最強大腦    c=1 d=1.14962 t=27
zui qiang da nao zai    最強大腦在 c=1 d=1 t=24
zui qiang da nao zai na li  最強大腦在哪裏   c=4 d=3.94585 t=27

（八股文中没有这些词）
用简拼打：

识别ok
然后，在后面补一个「呀」字会出现什么现象：

又被拆散了

把这个词加到八股文中，并给一个不大的词频：

最強大腦在哪裏   300

然后：

不会被拆散了

顺利打出。

……

最后观察到的规律是：
1、 超过五字的长词，如果放在八股文中，只要稍微给个不大的词频，就比较容易在组句中占据首选而不被拆散。但如果这样的长词只存在于用户词典中，那么即使打了无数遍，都只能在第二候选。（在五字以内的词没有这个问题）

2、如果不用八股文，dict也不设词频，完全由用户词典控制，那么就基本不会这样。

简言之，用户词典里超过5字的自造词在组句时都被程序自动降级了，所以通常都争不过八股文中的其它词。

其实每次它都可以被检索到（都排在第二位），看上去并不是计算量太大而被漏掉了。

可以感受到rime对每个细节都处理得很用心，只是不太明白，既然已经检索到了，又是用户词典的高频词，仅仅因为它超过5个字并且不在八股文中，就需要降级吗？

[lotem]

之前说过，为了兼顾效率，造句时并未用上所有的候选词。候选词列表会保证完整性，即与输入匹配的词一定会检索出来并在列出。但不能用所有候选词一一尝试组句。而是取一定量高频词来尝试。问题就在这里。固态词典里词条的词频是预知的，可以在部署时按词频排序，这样就可以快速取到每个拼音下面最高频的词条。而用户词典内容是不断更新的，内部结构也不一样，要找到最高频的若干词条，需要按照编码顺序扫描大量数据，并做词频比较。（此处应该可以优化，但要做到各种输入方案通用，难度又加大了）如果输入单字母简拼，匹配的词条可能达到词典中词条总数的1/26。事实上肯定没有这样做，而是用了贪心算法取得部分高频词。很显然，编码越是精确，对应的词条数越少，被选中的词在所有匹配项中的占比越高。在没有专门为简拼建立索引的情况下，没有任何算法能在有限时间内保证得到最优结果。简拼没有全拼准确，简拼越长越不准，这是有理论根据的。
我在考虑的一件事情，是要让输入方案为词典定义额外的索引。这可以提高简拼的表现。这件事本来不紧迫。因为我掌握的数据说，大多数拼音用家都打全拼（无声调），再者输入简拼的用户大多理解（以上讲的）简拼不准确。因为移动端对效率的更高要求，最近才重新想到这事。

[xiaoqun2016]

可以理解了，谢谢您耐心的回复！

[xiaoqun2016]

刚刚才突然意识到，我们对简拼有这么大的分歧的原因是什么。这应该是个误会，我还是再说清楚一点吧
全拼提供了更多细节（韵母），可以区分很多简拼的歧义，所以简拼确实没有全拼准确。简拼组句时，句子越长拆得越散，就越不准，这也是对的。这很容易理解。

但是
我们经常会用简拼输入自己已经打过并一次上屏的长句或长词，rime对这种简拼的支持做得很好（简拼精确匹配时，长词优先）。

然后，我们有时候会在这些打过的简拼长词的基础上加一两个高频的字或短词，组成一个新的长词。于是，下次就可以用简拼打刚才造的长词。这就是我说的渐进造词。

我们不知道背后的算法有多复杂，但rime对这种打法，每次都猜得很准。因为词库中本来就有一些长词。我们以为这些词是我们造的。而这些长词在组句时，总能顺利地作为首选。 于是，错觉就产生了。既然这种打法很管用，那就继续用下去了。所以，在长时间使用rime之后，我们会被本能地调教出这种造词习惯。这是我们被动找到的最高效地使用简拼的技巧，这也是对输入法的适应。很多人会下意识地这么打。

但时间长了，问题也来了。

在这样的输入习惯引导下，用户词库中的词会越来越长，也会混入很多自造的长词。谁也不会想到长度超过4或5字的长词会被特殊对待。同样的打法，之前猜得很准，现在偶尔会失灵了了，他们只会觉得输入法越来越难用了。

而我前面对rime规则的疑惑，有一部分就来自这种简拼长短词组句的混乱。

但现在知道了，我所谓的对输入法的理解，是长时间接触rime之后，无形中被rime教会的。
不知道这种打法是不是rime的初衷？也许只是我的误解吧？

而我之前也想得很简单，但凡用户打一长串简拼来组句的，肯定是基于这种输入习惯的。那输入法就不要想太多，直接从用户词典中取出最长的那个适配词，再加上前后的高频短词，这样组句就很快了。
我并没有想让rime用简拼逐词地从八股文或词库中检索所有的词组 ，再去做复杂的计算。我以为正常人都不会有这么夸张的要求，也就略过了这方面的说明。
我甚至觉得组句时只需要检索用户词典。只在单打词组时才检索全部词库。因为常人一辈子可能都只会反反复复地用用户词典中那几万个词，至于挂载的那几十万的词库，只是用于备选，只有单独打出，使其进入用户词典后，才需要用于组句。如果输入法只检索用户词典，组句效率应该更高。当然，这种想法也许太激进了。而且，从算法的实现来说，并不一定就高效，这涉及到专业知识，我没有发言权。

说到底还是我没表达清楚。请见谅！

[lotem]

其實沒有什麼「區別對待」。就好像某重點大學在本省只錄取十名考生，排名第十一的考生落選，考試制度並沒有對他區別對待，可他榜上無名，只得回家復讀一年。

長詞+後綴短語這個思路能解決不少案例，但也可能造成新的錯誤：長詞也可以加前綴短語呀，也可以用在中間呀。我不想靠添加「內部邏輯」來解決，還是把問題交給統計學吧。請參考：
https://www.byvoid.com/blog/slm_based_pinyin_ime

長詞進用戶詞庫這個做法，我本來不太喜歡，但目前也沒有什麼好辦法準確識別詞的邊界，只好把一長串字當一個詞記下。要根治這個問題，得做一番大改動。

造句只檢索用戶詞典，現實中不可行。如果這個輸入法真的已經用了一輩子，倒是可以這樣做。不然已記入用戶詞典的內容隨機性很大，以有限的詞彙可能根本造不出完整的句子，或只能勉強拼湊出一些無意義的文字。

[xiaoqun2016]

讨论了这么多，索性再补充一下
看全拼一例：

在朙月拼音的词库中加了一个简体的「其实没有什么」：

其实没有什么      qi shi mei you shen me
〇 ling
ㄓ zhi
ㄔ chi

另外用朙月拼音的造词功能造了一个繁体的「其實沒有什麼」。
现在我们有两个全拼相同的词条：一个是词库内的简体长词，另一个是用户自造的繁体长词。
输入若干次后，词频数据如下：

qi shi mei you shen me  其实没有什么  c=1 d=1 t=75
qi shi mei you shen me  其實沒有什麼  c=4 d=3.97017 t=75

很明显，繁体的那条词频更高，实际输入时也是这样：

这里没有其它干扰项，按这个情形，用于组句是不是也先用繁体的？
可是在组句时，变成这样：

我们看前三个候选，情况有点复杂，简体词优先用来组句，却在第2位候选的竞争中败给了繁体的词条。而之前繁体词在一对一PK中战胜了简体词，现在却在组句时被反转。
从表面看上去，用户自造的长词就是这样被「区别对待」的，组句时，并没有因为高频而被录取。而随便加入繁体词库中的简体词， 轻易地就被录取了。

经过您的解说，我已经理解区别对待是为了兼顾效率。很多事情都要在效率和效果上作平衡，这是不可避免的问题。
其实没有什么，我举的这些例子都不常见，没必要用这么苛刻的条件来要求rime。抠这些细节也许并没有用处，我只是被一开始的那个空码问题引起了兴趣，于是就一发不可收拾了。

讨论这个问题，也许可以供以后有相似疑惑的人参考。现有条件下，如果他需要自造的长词能被正常地组句，应该每隔一段时间就把这些词收录到rime的词库中，从而编译成固态词典。 而对于简拼的地位，也可以从您的解答中有所了解。对于某种输入习惯的形成，并不是rime的本意。rime希望通过输入技术上的创新（比如基于统计语言模型），变得更智能，而不是让用户苦练输入技术来达到快速输入（比如手动积累语料，造长词）。
不知道我的理解对不对？