自然语言处理库中死代码的危害与清理

死代码应当被清理

自然语言处理领域发展迅速，维护一个优秀的库意味着需要不断淘汰旧内容。大多数库在这方面表现糟糕，因为学术界不喜欢进行内容筛选。本文解释了这一问题为何具有破坏性，以及开发spaCy时如何采用不同方法。

设想使用某翻译服务时，系统要求先选择模型。虽然提供了强大的新深度学习模型，但同时也存在大量过时选项。若用户选择了一个名称花哨但实为20年前基于烤箱说明书语料训练的实验模型，其表现可能仅略高于随机猜测，且从输出结果无法辨别问题。自然语言处理库普遍存在此类问题，这非常糟糕。

自然语言处理研究进展迅速，新模型不断取代旧模型。然而大多数NLP库不愿淘汰任何内容。历史悠久的库因此显得庞大而令人印象深刻，但在这里"大"并不代表美。向用户提供十几个劣质选项绝非优点。

以某知名软件为例：其包含12年开发积累的大量内容，但几乎零 curation（内容策展），哲学仅仅是"提供东西"，使用决策完全交给用户。

这种做法非常有害。例如提供MiniPar实现却不标注这是20年前就该淘汰的技术；同样的问题存在于RASP解析器。更糟糕的是，这些组件没有任何使用警告。理想情况下应该标注开发日期，但即使用户需要研究领域历史，也不应在2015年还执行这类软件。

相对温和的案例是某核心NLP库：提供多种具有复杂速度/精度/加载时间权衡的模型，许多模型输出存在细微差异。虽然大多数模型不存在绝对优劣，但选项过多且使用建议模糊不清。

更新（2016年10月20日）：该批评现已失效——3.6.0版本引入的简易API非常优秀，文档质量也大幅提升。

为何未参与NLTK开发

多人询问为何选择开发新Python NLP库spaCy而非支持NLTK项目，核心原因在于：如果你认为某个项目首先应该丢弃几乎全部内容，就不可能为其作贡献。此时应该创建自己的项目——这正是我的选择。

查看NLTK模块列表时，表面内容丰富实则不然。它包含：合格的分词器、若干可用词干提取器、优秀的句子边界检测器（经重写后）、可视化工具以及其他库的封装器，其余内容均无实用价值。

以nltk.parse为例：看似包含能预测句子句法结构的代码，实则只有外部解析器的封装器，以及2003年基于转换的依存解析算法实现。但由于缺乏模型且依赖外部学习器，该实现速度过慢无法实际使用。

若编写优质代码而非拼凑外部依赖，本可完全避免这些问题。曾向NLTK推荐过用500行Python代码实现现代依存解析器的教程（BSD许可），但被婉拒且问题被突然关闭。2012年另一位研究者提供类似模型实现也未获回应。

nltk.tag情况类似：大量封装器包裹着实际具有标注功能的外部库，而唯一自带的标注模型质量低下，甚至开发组似乎都不清楚其词性标注器的训练方式——该模型作为一个.pickle文件流传五年，来源已不可考。向用户推荐此类组件是不可接受的。

更新（2016年10月3日）：NLTK后续使用平均感知机标注器解决了该问题。

开源软件应当明确自身局限性。提供远低于暗示功能的软件如同承诺接送朋友却爽约——完全不做事无可厚非，只要从未承诺过做事。但提供劣质方案比不提供更糟糕。

---

更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）或者 我的个人博客 https://blog.qife122.com/
公众号二维码