用 LSP 补全来做输入法的体验

twiddling · 2022 年9 月 19 日 12:57

好的，那我先用当前想到的方式，就在 lsp 服务端检测，尽量不改 lsp-bridge，如果效果不好再尝试加 hook 之类的。

确实是这样，但我也怀疑 “不输入太长的句子” 额外原因可能是因为输入法局限以及句子长了人容易打错的导致，如果输入法真的足够准，正常来说输入越长其实应该越准才对，因为限制更多了，就像我们说一句话，把话说完整比单独断断续续说几个词连起来更容易理解。但太长容易打错，导致整个句子错误（rime 输入法里也有手写正则来纠错的功能，可以缓解这类问题，但配起来很麻烦），另外，如果是基于常用词库（或者自己的按频率排序的词库），习惯之后效率是很高的，首先常用词并不是很多，积累好了大部分情况都能命中词库里的词，所以输入两三个词后看到命中了基本就会选择（选择是按一个空格的成本，但继续输入可能是要重新打一遍的成本，哪一更高因人以及输入法交互方式而异）

这个输入法没有那种直接通过拼音检索的内置词库，从作者文章里摘的内容如下，用的是一个统计模型，作者没有写用什么策略来切分句子进行训练，估计统计了很多不合理的词频进去才导致返回一些奇怪的选项（这个我也发现，有些排序很不符合日常的用词的频率）

由于训练HMM模型的需要，我们从搜狗实验室找到了SogouQ用户查询数据集，预处理成合法的句子之后大约有360M，且为了避免查询句太短，我们也增加了将近30M的搜狐新闻数据作为训练语料，这里面包含了很多的长句子。

yibie · 2022 年9 月 19 日 13:58

记得以前 Windows XP 的时代，微软输入法就是基于长句预测的，但不知道当时的技术成果还在不在网络上。

manateelazycat · 2022 年9 月 19 日 14:06

其实我觉得现在的lsp协议配合正常词库和词频算法就很好。

现在这个预测模型经常出很多奇奇怪怪的预测，句子越长反而错的越离谱，需要调整地方太多，就完全不想用了。

twiddling · 2022 年9 月 20 日 01:05

是的，用词库词频一般就可以满足基本输入，我这周更新一下读取外部文件的接口试试效果，因为词库基本是靠自己配置。当前输入法是 github 上找的用来测试 lsp 补全协议的，刚开始都不抱希望（比如以为会很卡 acm 刷新不过来，或者有些词根本没有），没想到装上基本就能用了，只是用一会发现给的词会混乱，毕竟还是学生的课程项目，和实用还有很大差距，但总的来说已经超出我预期了。

另外增加词库这类的方法基本很难体现出 lsp 的优势，所以我不打算去优化这块（输入法坑太大，而且我的主要是想做中文的 lsp 服务，这还包括很多其他接口，比如诊断，doc，当前不想花时间重做一个输入法），但等我把 lsp 其他接口尝试一遍后，有空可能会把 GitHub - VisualJoyce/Transformers4IME: Transformers for Input Method Engine 尝试移植过来，我觉得这个更有趣，其他按规则的方法再怎么优化也还是重复造轮子，感觉不是很有必要

manateelazycat · 2022 年9 月 20 日 01:25

如果走 LSP 协议， acm 天生就会对抗后端卡顿导致 Emacs 卡的问题，所以即使后端真的很卡， acm都不会有半点卡顿。具体可以看 https://manateelazycat.github.io/emacs/2022/06/26/why-lsp-bridge-not-use-capf.html

词库可以考虑内置 https://archlinux.org/packages/?name=fcitx5-pinyin-zhwiki ，这个词库我天天都在用，客观性和数量都非常好。

twiddling · 2022 年9 月 20 日 11:16

这个词库怎么读呀， Releases · felixonmars/fcitx5-pinyin-zhwiki · GitHub 下载里有一个是 .dict 文件，一个是 yaml，dict 打开查看内容如下，一些奇怪的中文里夹着英文缩写，不太理解

!木里灰岩黄芩XDGDXHXQC!穆姆普费弗卢山野站VT!牧野天音S!穆木天LVC!木暮公延兽Q!木木枭暮光VAS!苗刘兵变谋克敦牟盛XWXMX!牧之原服务区NFPOC!牧者丛地铁站C!目白台站ZPFOC!牧者丛火车站穆迪埃C!牧者丛站C!木知原站NAS!苗刘之变N!牧之原市FOC!木知原车站FOC!牧者丛车站NPDOC! 牧者丛市场站!目击者FOC!目白台车站!木吉镇RH!木棘证人京IAE!木登城堡目标!目标值^!目标客群NUNUCXI]HN!目标定向项目管理AQSN!木里茶藨子ILK!目白圣公会镜LUN!目标软件公司!暮白首栅站山站DXQNSNVX! 穆里尔副狮子鱼FML

yaml 结构是比较清晰的，但没有权重，而且这里说 sort by_weight, 但看上去这些词也不是按常用频率排序的

yaml 前几行如下

---
name: zhwiki
version: "0.1"
sort: by_weight
...

吖丙啶  ya bing ding
吖丁啶  ya ding ding
吖啶橙  a ding cheng
吖啶黄  a ding huang
吖啶酮  a ding tong
吖啶    a ding
吖庚环  ya geng huan

最后几行如下（不理解这个 sort: by_weight 的 weight 是什么了）

祚建豹蛛        zuo jian bao zhu
胙城县  zuo cheng xian
胙城乡  zuo cheng xiang
胙国    zuo guo
胙土命氏        zuo tu ming shi
胙州    zuo zhou
阼湖    zuo hu
嫲嫲    ma ma

twiddling · 2022 年9 月 20 日 11:20

我查了些资料，早期的长句预测应该都是依赖这里提到的 HMM 类统计语言模型，原理并不复杂，但真正要训练起来非常多细节，暂时不想入坑

manateelazycat · 2022 年9 月 20 日 11:21

应该是fcitx的格式，估计要看fcitx的文档

book · 2022 年10 月 15 日 05:04

安装时出现如下错误：

git apply 0001-for-py3.patch
error: patch failed: GodTian_Pinyin.py:7
error: GodTian_Pinyin.py: patch does not apply
error: patch failed: PinyinTrie.py:6
error: PinyinTrie.py: patch does not apply
error: patch failed: gui.py:1
error: gui.py: patch does not apply
(base)

twiddling · 2022 年10 月 15 日 07:31

你是不是在 Wen 项目目录下执行的 git apply ？这个命令要在GodTian_Pinyin 目录（或者按 readme 说明是在 completion 目录）下执行的，给拼音输入法项目打补丁，也可能是重复执行，git diff 看看是不是已经打过补丁了

suliveevil · 2022 年10 月 15 日 14:49

一个想法：

用 LSP 补全，建立好词库应该就可以实现拼音双拼五笔的混合输入了。

有输入、有词库映射、有提示，有输出，比来回切换输入法好。

manateelazycat · 2022 年10 月 15 日 15:00

不会这么简单，中文最复杂的是它不像拉丁语系都是空格风格单词的，人眼可以智能分词的情况，程序首先面临的问题是正确分词和理解上下文。

如果分词都不准确，中文的拼音可以对应多个汉字，分词不对就意味着词库的选择就会错误，目前看 LSP 虽然可以减少输入法的切换，但是分析上下文和预测正确分词的算法还是要引入输入法厂商的各种算法，没有这些算法加持， LSP拼音输入法的体验非常差。

suliveevil · 2022 年10 月 15 日 15:20

是我想的太简单了，光想着有输入有输出，忘了候选框是有限的。

选词算法或许可以利用拼写检查、模糊搜索相关的技术（HanLP、BERT、word2vec、SymSpell）做判断。