中文分词算法：外包前应整理哪些需求
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2f4cfad7bd3c.html
📄
中文分词算法：外包前应整理哪些需求
把中文分词算法外包前，最该整理的不是一句“帮我做个分词”，而是一份能让开发方准确报价、按时交付、验收有据的需求说明。核心要写清四件事：文本从哪来、要分到什么粒度、用什么标准判断分得对、交付后由谁维护。缺少任何一项，返工概率都会明显上升。
先定义输入：文本来源与格式决定算法选型
中文分词算法的效果高度依赖输入文本的形态。同一套算法处理新闻标题、商品评论、法律文书和聊天记录，结果差异很大。外包前应把输入情况列成清单：
- 文本语言构成：纯简体中文，还是中英混排、含数字、表情、繁体或方言词。
- 文本长度：短句为主，还是整段、整篇文档。
- 领域范围：通用口语，还是医疗、金融、法律等有大量专有名词的领域。
- 数据格式：纯文本、JSON、CSV、数据库字段，还是需要从网页或接口抓取。
- 数据量与增长：一次性处理多少，之后每天或每月新增多少。
这些信息决定对方是用现成开源分词库加自定义词典，还是需要训练领域模型。如果只写“处理中文文本”，开发方只能按最保守的方式报价，成本往往偏高，交付物也可能不匹配。
再定义输出：分词粒度与标注要求
“分词”本身有不同含义，必须明确输出什么。常见的有：
- 只做词语切分，输出用空格或数组分隔的词序列。
- 切分同时标注词性，如名词、动词、地名、机构名。
- 识别未登录词，包括新词、品牌名、人名、产品型号。
- 输出实体边界，为后续搜索、推荐或统计做准备。
还要约定歧义处理原则。例如“乒乓球拍卖完了”可以切成“乒乓球/拍卖/完/了”，也可以切成“乒乓球拍/卖/完/了”。哪种算对，取决于业务用途。搜索场景通常偏向召回，统计场景可能偏向标准切分。把这些例子写进需求，比抽象描述“要准确”有用得多。
明确验收标准：用什么数据判断分得对
分词没有绝对唯一正确答案，所以验收必须靠双方认可的标注集。外包前应准备或要求对方准备一小批代表性文本，由业务方人工标注正确切分结果，作为测试集。验收时可以按以下指标判断：
- 准确率：切出来的词里有多少是正确的。
- 召回率：应该切出的词里有多少被切出来了。
- 未登录词处理：专有名词、新词是否被合理识别。
- 速度与稳定性：在约定数据量下能否在可接受时间内完成。
如果业务只关心搜索命中，可以更看重召回；如果用于词频统计，准确率更关键。这些取舍要提前写明，否则开发方按通用指标交付，业务方却觉得“不好用”，责任难以界定。
约定交付物、协作方式与维护责任
多人协作场景下，交付不清是返工的主要来源。需求中应列出：
- 可运行的分词程序或接口，以及调用说明。
- 自定义词典、模型文件及其更新方式。
- 测试集、评测脚本和评测结果。
- 代码或服务的部署环境要求。
- 后续新增词、调整粒度的维护方式和响应范围。
如果对方只交付一个在线接口，要确认数据是否外传、调用量限制和故障处理方式。如果交付源码，要确认许可证是否允许商用。这些条件直接影响总成本，不能等到签约后再补。
比较外包方式与选择步骤
常见选择有三种：直接使用成熟开源分词工具并自行调词典；在开源工具基础上让外包方做领域适配；完全定制训练模型。三者的代价不同：开源方案成本低、上手快，但领域效果有限；适配方案平衡成本和效果，适合多数业务；完全定制适合数据量大、领域特殊且有长期维护预算的场景。
可以按以下步骤做决定：
- 先用几百条真实文本测试开源分词工具，记录明显错误。
- 判断错误是否集中在专有名词和歧义句上，能否靠词典解决。
- 若词典能解决大部分问题，优先选适配方案，不必定制模型。
- 若错误分散且涉及语义理解，再考虑定制，并要求对方给出评测方案。
- 把输入、输出、验收、交付、维护五项写成一页需求文档，再对外询价。
下一步，先收集200到500条真实文本，人工标注其中一部分作为测试集。拿着这份测试集去问外包方“你打算怎么达到这个标准”，比只问价格更能判断对方是否靠谱。
