[关闭]
@caos 2015-10-21T02:03:21.000000Z 字数 1845 阅读 532

Language Tool 技术分析报告

LT OM


写在前边

Langguage Tool(LT) 作为一款基于Java语言的文本检查开源软件,有着多种语言的支持。目前就写匠项目的需要,对 LT 中文检查的实现与设计思路进行分析。取其优点,避其不足。

LT 模块简介

LT 包括错误规则配置、分词模块、文本检查三个主要的模块,其中错误规则配置是最为核心的模块,也是 LT 基于错误匹配对文本进行检查的核心思想的体现。

分词模块

分词模块 LT 主要采用了成熟的第三方分词库 ICTCLAS 做分词处理,核心代码以 ictclas4j-1.0.1.jar 的集成在系统中,主要用于切分段落和语句,将整块的文本切分可标注的字词段。以各项字典文件做为字词标注的依据,标注切分后文本的词性。该模块的工作先于规则解析之前完成,是规则解析的基础。

规则解析模块

LT 采用错误匹配的形式检查文本中可能出现的问题,使用 XML 文件配置的方式定义错误规则,目前中文的语法规则数量已经达到786个,全部以 XML 元素的形式保存在 grammar.xml 文件中。

支持用户自定义错误的语法规则,按照 pattern.xsdrules.xsd 两个模板定义文件中的格式要求,配置额外的错误语法。规则解析前会对其进行语法校验。

文本检查模块

软件会在文本处理的时候读取现有的规则配置,使用多线程的方式对分词过后的文本进行分析。
文本检查的核心类为 JLanguageTool 调用分词结果和规则结果,使用正则匹配对文本内容进行检查,并根据规则配置中的建议返回改错的结果。

LT的优缺

优点

缺点

写匠与LT

作为 LT 的同类产品,从写匠项目中改错模块目前的需求来看,LT 面临着很多实际问题,也是写匠需要避免的。

数字、数词筛选困难

中文中的量词包含阿拉伯数字、中文大小写数字等,数词的筛选很困难,找出统一的判断规则配置的难度极大。

解决方案:编写复杂的正则表达式尽可能的去匹配各种量词使用情景,难度在于对现有语法的穷举。另一种方式是更换更加智能的分词词库,提高量词的分词效果,能够减轻语法规则的配置工作。

语法描述困难——抽象能力不足

以错误的匹配规则检查语法的方式,难以做到高度抽象,无法涵盖到不同的语法情况,就需要通过具体的字词匹配,才能满足改错的精确性。

解决方案:具体错误具体配置,依据实际出现的写作错误对规则众包配置。这就要求规则配置要足够简单易行,目前现有的配置方法需要略作改进。

隐性错误描述困难

一些不常用的词语和隐性的表达方式,难以用规则涵盖,使用LT提供的XML系统也难以进行统一规格化描述,不得不为每一种“隐性错误”进行区别对待,单独编写规则。

解决方案:暂无。

标点符号处理困难

标点符号的类别多样,目前 LT 所使用的 ICTCLAS 分词系统,对大部分符号的支持度都不高,甚至会对一些符号进行断句处理,这样就无法通过规则匹配出大部分符号使用错误的语法规则。

解决方案:从分词系统中入手解决符号验证的问题,改进字词拆分的算法。

「词语缺失」处理困难

这里包括目前 LT 的匹配方式为从前至后的正向匹配,目前的规则无法做到反向匹配,同时多元表达的错误也无法纠正。

解决方案:解决反向匹配问题,可以重新设计规则匹配模块,或是在现有的模块基础上扩展反向匹配的算法,多元表达式目前暂无解决方案。

分词错误

LT 所依赖的分词系统与规则耦合度很高,一旦更换分词系统,有可能导致之前的规则配置失效,更新修改的任务繁重。

解决方案:更换 ICTCLAS 分词系统,但可能需要重新设计规则匹配系统,调整 LT 语言标记模块与其耦合的代码,并更新规则。

基于现有功能的设想

现有的思路是用 python 语言完成写匠改错模块的实现,Web 服务使用 Django 框架驱动,数据库为 PostgreSQL ,另外会整合第三方的服务,作为规则处理的一部分。

功能

需要通过 python 重构一个完整的文本检查模块,其中功能包括:

需要注意

借鉴 LT 的设计思想,也需要注意的问题:

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注