一种中文分词算法
维特比算法中文分词的原理
维特比算法中文分词的原理
维特比算法是一种基于动态规划的算法，用于中文分词。
它的原理如下：
1. 首先，将待分词的句子进行切割成一个个的字或词。
2. 对于每个字或词，计算概率最大的分词节点，并记录下来。
这个节点的概率可以通过统计语料库中的词频信息来计算。
3. 从句子的第一个字或词开始，每次选择当前位置概率最大的节点，并将其加入分词结果中。
然后，从当前位置的下一个字或词开始继续选择概率最大的节点，直到句子末尾。
4. 最后，得到的分词结果就是概率最大的路径。
维特比算法的关键是使用动态规划来计算概率最大的节点。
具体来说，可以使用一个二维数组来存储每个字或词位置的概率最大节点和对应的概率值。
通过不断更新这个数组，可以得到最终的分词结果。
维特比算法在中文分词中有广泛应用，它能够通过考虑字或词之间的概率关系来提高分词准确性。
同时，维特比算法的动态规划思想也使得它能够高效地处理长句子。
一种改进的中文分词正向最大匹配算法
２１ ０ １年 ３月
计 算机 应 用与软 件
Ｃｏ ｕｔｒ Ａｐ ｌｃ ｔｏ ｓａ ｄ Ｓ ｆ ｒ ｍｐ ｅ ｐ ｉ ａｉ ｎ ｎ ｏ ｗａｅ ｔ
Ｖ０ ＿ ｌ２８ Ｎｏ． ３
Ｍ ａ ． ０１ ｒ２ ｌ
一
种 改 进 的 中 文 分 词 正 向 最 大 匹 配 算 法
ｔ ｅ ｓ ｅ ｄ ａ ｄ ｅ ｃｅ ｃ ｆＣ ｉｅ ｅ Ｗ ｏ ｅ ｍｅ ｔｔ ｎ ａｇ ｒ ｈ ｈ ｖ ｅ ｎ ｏ ｖｏ ｓｙ ｉ ｒ ｖ ｄ ｈ ｐ ｅ ｎ ｆ ｉｎ ｙ ｏ ｈ ｎ ｓ ｒ ｓ ｇ ｎ ａｉ ｌｏ ｉ ｍ ａ ｅ ｂ ｅ ｂ ｉｕ ｌ ｍｐ ｏ ｅ ． ｉ ｄ ｏ ｔ Ｋｅ ｗｏ ｄ ｙ ｒｓ Ｃ ｉ ｅ ｅ ｗ ｒ ｅ ｍｅ ｔｔ ｎ Ｗ ｏ ａ ｋ Ｆ ｒ ｒ ｎ ｘ ｍｕ ｍａｃ ｉ ｇ ａｇ ｒｔ ｍ ｈ ｎ ｓ ｏ ｄ ｓ ｇ ｎ ａｉ ｏ ｄ ｒ ｂ ｎ ｏ ｗａ ｄ ｌａ ｉ ｍ ｔ ｈｎ ｌ ｏ ｉ ｈ
ｐ ｔ ｆｒ ａ ｄ ａ ｄ ａ ｆ ｒｉ ｒ ｖｎ ＭＭ ｌｏ ｉ ｍ ｈ ｔｉ ｏ ａ ｓｇ ｈ ｘｍｕ ｔｘ 一 ｎ ｔ ｏ ｂ ｒａ ｅ ｙ ａ ｃ ｌ ａ ｅ ｎ ｔ ｅ ｗ ｒ － ｕ ｓ ｏ ｒ ｎ ｉ ｅ ｏ ｍｐ ｏ ｉ ｇ Ｆ ｗ ａｇ ｒ ｈ ｔ ａ ｓ ｔ ｓ ｉｎ ｔ ｅ ｍａ ｉ ｍ ｅ ｔ１ ｇ ｈ ｔ ｅ ｔ ｔｄ ｄ ｎ ｍｉ ａｌ ｂ ｓ ｄ ｏ 同 的 统 计 ， ８—１ 因 ３字 的 词 所 占 比 例 较 小
０ 引 言
中文 自动 分 词 是 中文 信 息 处 理 中 最 为 基 础 、 为重 要 的 问 最 题 ， 汉语 文 本 自动 标 注 、 索 引擎 、 器 翻 译 等工 作 中 的 关 键 是 搜 机
一种改进的基于Hash的中文分词算法研究
福
建 电
脑
６ ９
一
种改进的基于 Ｈ ｓ ａｈ的中文分词算法研究
蔡 蕊
（山 东 大 学计 算机 科 学 与技 术 学 院 山 东 济 南 ２ ０ ０ ５ １ １）
【 要】 摘 ：在分析 已有的 中文分词算法的基础上， 用改进 的词典 结构， 出一种新的基 于 Ｈ ｓ 利 提 ａｈ的 中文分词算 法。 理论 和 实验 证 明 ， 进 的 算 法 可 以进 一 步 提 高分 词 的效 率 。 改 【 关键词 】 中文分词 哈希算法 ：
泛 而 深入 的研 究 一
分词 是 中 文 信 息处 理 的 基础 一 环 ．分 词 方 法 的 性 能 直 接 影
表 １ 词 条 分布 情 况表
由汉 语 的词 频 统 计 得 出 结 论 ．在 汉语 中．９ 的词 集 中在 四 ９％ 响 到 中文 信息 搜 索 的实 时 性 及 准 确 性 。考 虑 到 中文 分 词 算 法 的 应 用 领域 大多 对 实 时 性 和 准 确 性 两 方 面有 很 高 的 要 求 。因 此 ． 实 字 以下 的 词 语 ． 其 以双 字 词 为 数 最 多 。 尤 如果 能 在 词 典 中实 现 对 那 现 较 简 单 的基 于 Ｈ ｓ ａｈ算 法 中 的 正 向最 大 匹 配 法 仍 然 是 应 用 最 四字 以 内的 词 的 快 速查 找， 么 系统 的效 率 会 明显 提 高 我 们 利
所 示
搜 ７
ｌ
Ｉ
索
库 结 构
其 中 ． 果 有 以词 条 为 首 的 词 条 ． 么词 条 的 属 性 为 以该 词 如 那 条 为首 的词 条 的开 始 位 置 和 结 束 位 置， 则 为 ０ 否 。 ３２分 词 算 法 ． 分词算法首先 由 Ｈ ｓ 计 算的首字的地址． ａｈ 然后 利 用 二 分 查 找是 否 有 以前 两 字 为 首 的 词 条 。如 果 没 有则 作为 单 字 词输 出： 否
中文分词——HMM算法
中⽂分词——HMM算法上⼀篇⽂章中，我们讲述了如何⽤查词典的⽅法对中⽂语句分词，但这种⽅式不能百分百地解决中⽂分词问题，⽐如对于未登录词（在已有的词典中，或者训练语料⾥⾯没有出现过的词），⽆法⽤查词典的⽅式来切分，这时候可以⽤隐马尔可夫模型（HMM）来实现。
在实际应⽤中，⼀般也是将词典匹配分词作为初分⼿段，再利⽤其他⽅法提⾼准确率。
HMM介绍隐马尔可夫模型（Hidden Markov Model，HMM）是统计模型，是关于时序的概率图模型，它⽤来描述⼀个含有隐含未知参数的马尔可夫过程，即由⼀个隐藏的马尔可夫链随机⽣成不可观测的状态随机序列，再由各个状态⽣成⼀个观测⽽产⽣观测随机序列的过程。
序列的每⼀个位置⼜可以看作是⼀个时刻，其结构见下图。
其难点是从可观察的参数中确定该过程的隐含参数，然后利⽤这些参数来作进⼀步的分析，例如中⽂分词。
如上图所⽰，状态序列H可表⽰为：H=H1,H2,...,H T假设总共有n个状态，即每个状态序列必为状态集合之⼀，状态值集合Q为：Q={q1,q2,...,q n}观测序列O表⽰为：O=O1,O2,...,O T假设观测值总共有m个，则观测值集合为：V={v1,v2,...,v m}⼀个模型，两个假设，三个问题1、⼀个模型HMM的基本元素可以表⽰为λ={Q,V,π,A,B}Q：状态值集合V：观测值集合π：初始概率分布A：[a ij] 状态转移矩阵B：[b j(k)] 给定状态下，观测值概率矩阵，即发射矩阵2、两个假设齐次Markov即假设观测序列中t时刻的状态，只跟上⼀时刻t-1有关，P(h t+1|h t,...,h1；o t,...,o1)=P(h t+1|h t)观测独⽴即每个时刻的观测值只由该时刻的状态值决定P(o t|o t−1,...,o1;h t,...,h1)=P(o t|h t)3、三个问题HMM在实际应⽤中主要⽤来解决3类问题:评估问题(概率计算问题)即给定观测序列O=O1,O2,O3…O t和模型参数λ=(A,B,π)，怎样有效计算这⼀观测序列出现的概率.(Forward-backward算法)解码问题(预测问题)即给定观测序列O=O1,O2,O3…O t和模型参数λ=(A,B,π)，怎样寻找满⾜这种观察序列意义上最优的隐含状态序列S。
基于统计语言模型的中文分词算法研究
基于统计语言模型的中文分词算法研究中文是世界上使用人数最多的语言之一，它的排列方式和英语等西方语言有很大的不同，因此分词是中文自然语言处理的重要一环。
中文分词的主要目标是将一段连续的中文文本切分成单个的词语。
目前，基于统计语言模型的中文分词算法是最为流行和使用广泛的算法。
本文将会探讨中文分词的基础知识，以及基于统计语言模型的中文分词算法的核心思想和实现方法。
一、中文分词的基础知识中文文本是由汉字组成的，中文词语并不像英语词汇那样有明显的边界。
因此，中文分词器需要解决的第一个问题就是识别出哪些汉字是组成词语的基本单元。
然后，再根据组合方式将词语划分出来。
中文分词可以分为基于规则的分词和基于统计的分词两种算法。
基于规则的分词算法是手动编写规则，根据这些规则来解决分词问题。
但是这种方法实现起来非常困难，因为包含规则的样本集必须足够大而且需要频繁更新。
而且，规则往往是比较复杂的，需要人工不断调整和改进。
基于统计的分词算法是通过分析一定量的语言样本集，建立起一个统计模型来解决分词问题。
这种方法不需要手动编写规则，而是通过分析大量的语言样本，了解自然语言的规律，然后再根据语言的规律来处理分词问题。
因此，基于统计的分词方法相对于基于规则的方法更加高效和精确。
二、基于统计语言模型的中文分词算法基于统计语言模型的中文分词算法并不是直接对每个汉字进行分词，而是在每个可能的词边界处赋予一个概率权重，然后取最大概率的词语作为对应的分词结果。
基于统计语言模型的分词算法包含三个主要组成部分：分词模型、特征提取和概率计算。
1. 分词模型分词模型是中文分词的核心模型，它可以对中文句子进行分词。
分词模型可以分为两种类型：基于统计的分词模型和基于规则的分词模型。
基于统计的分词模型通常基于最大概率模型或条件概率模型，常用的模型包括Hidden Markov Model （隐马尔可夫模型）和Conditional Random Fields（条件随机场）模型。
hmm分词算法
hmm分词算法
HMM分词算法是一种基于隐马尔可夫模型的中文分词方法，其基本思路是将待分词的文本看作一个观测序列，将中文词语看作是一个隐藏的状态序列，通过对观测序列进行统计学习，推断出最可能的状态序列（即词语序列），从而实现中文分词。
HMM分词算法的核心是对隐马尔可夫模型的学习和推断，其中学习过程主要是通过训练样本对模型参数进行估计，包括状态转移矩阵、发射概率矩阵和初始状态分布；推断过程则是通过给定观测序列，利用Viterbi算法求解最可能的状态序列，从而实现分词。
HMM分词算法在中文分词领域有着广泛的应用，其优点是可以自动识别未登录词和歧义词，并且具有一定的鲁棒性；缺点是需要大量的训练数据和计算资源，并且对于长词和新词的识别效果不尽如人意。
同时，随着深度学习技术的发展，基于神经网络的分词方法也逐渐得到了广泛应用。
- 1 -。
中文bpe分词
中文bpe分词（原创实用版）目录1.中文分词的重要性2.BPE 分词方法的原理3.BPE 分词方法的优势4.BPE 分词方法的实际应用5.总结正文一、中文分词的重要性中文文本与英文文本在处理上存在很大差异，其中一个关键因素就是中文没有明确的词语边界。
英文文本通过空格可以清晰地划分单词，而中文文本则需要进行分词处理，将连续的文本切分成有意义的词汇单元。
中文分词在自然语言处理、信息检索、文本挖掘等领域具有重要意义。
二、BPE 分词方法的原理BPE（Backward Prefix-suffix）分词方法是一种基于字典的分词方法。
该方法通过遍历输入文本，动态构建一个有向无环图（DAG），并利用该图进行分词。
具体原理如下：1.构建字典：首先根据输入文本构建一个字典，存储每个字符或词语的出现频率及其前缀和后缀信息。
2.遍历输入文本：从输入文本的开始位置开始，依次将字符或词语添加到字典中，并更新它们的前缀和后缀信息。
3.动态规划：利用字典中的信息，通过动态规划算法计算每个字符或词语的分词概率。
4.切分词语：根据分词概率，从输入文本的末尾开始，向前切分出有意义的词语。
三、BPE 分词方法的优势BPE 分词方法具有以下优势：1.能够处理未登录词：BPE 分词方法可以识别字典中不存在的词语，如新词、专有名词等。
2.切分精度高：BPE 分词方法可以根据词语在文本中的上下文信息进行切分，从而获得较高的切分精度。
3.鲁棒性好：BPE 分词方法能够处理各种复杂的输入文本，如包含歧义、重复、噪音等。
四、BPE 分词方法的实际应用BPE 分词方法在许多自然语言处理任务中都有广泛应用，如文本分类、情感分析、机器翻译等。
通过 BPE 分词方法，可以有效提高这些任务的性能和准确性。
五、总结作为一种基于字典的中文分词方法，BPE 分词方法具有处理未登录词、切分精度高、鲁棒性好等优势。
简述中文分词算法的种类和基本原理
简述中文分词算法的种类和基本原理下载提示：该文档是本店铺精心编制而成的，希望大家下载后，能够帮助大家解决实际问题。
文档下载后可定制修改，请根据实际需要进行调整和使用，谢谢！本店铺为大家提供各种类型的实用资料，如教育随笔、日记赏析、句子摘抄、古诗大全、经典美文、话题作文、工作总结、词语解析、文案摘录、其他资料等等，想了解不同资料格式和写法，敬请关注！Download tips: This document is carefully compiled by this editor. I hope that after you download it, it can help you solve practical problems. The document can be customized and modified after downloading, please adjust and use it according to actual needs, thank you! In addition, this shop provides you with various types of practical materials, such as educational essays, diary appreciation, sentence excerpts, ancient poems, classic articles, topic composition, work summary, word parsing, copy excerpts, other materials and so on, want to know different data formats and writing methods, please pay attention!探索中文分词算法的种类与基本原理1. 导言中文分词是自然语言处理中的基础任务之一，其目的是将连续的中文文本切分成有意义的词语单位。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一种中文分词算法1.1.1 最大匹配法分词的缺陷尽管最大匹配法分词是常用的解决的方案，但是无疑它存在很多明显的缺陷，这些缺陷也限制了最大匹配法在大型搜索系统中的使用频率。
最大匹配法的问题有以下几点：一、长度限制由于最大匹配法必须首先设定一个匹配词长的初始值，这个长度限制是最大匹配法在效率与词长之间的一种妥协。
我们来看一下以下两种情况：（1）词长过短，长词就会被切错。
例如当词长被设成5时，也就意味着它只能分出长度为5以下词，例如当这个词为“中华人民共和国”长度为7的词时，我们只能取出其中的5个字去词库里匹配，例如“中华人民共”，显然词库里是不可能有这样的词存在的。
因此我们无法下确的划分出“中华人民共和国”这样的词长大于5的词。
（2）词长过长，效率就比较低。
也许有人会认为既然5个字无法满足我们的分词要求，何不将词长加大，例如加到10或者100，毕竟这个世界超过100个字长的词还是很少见的，我们的词长问题不就解决了？然而当词长过长时，我们却要付出另一方面的代价：效率。
效率是分词算法、甚至是整个算法理论体系的关键，毕竟算法书里所有的高深的查询或排序算法都是从效率出发的，否则任何笨办法都可以解决分词效率低的问题。
设想到我们把字长设成100个词时，我们必须将词从100开始一直往下匹配直到找到要查的字为止，而我们大多数词的字长却只有两三个字，这意味着前97次的匹配算法是徒劳的。
因此我们必须要在词长与效率之间进行妥协，既要求分词尽量准确，又要求我们的词长不能太长。
尽管我们可能找到这样一个比较优化的字长值使两者都达到比较满足的状态，但是毕竟不管我们怎么设定，总会有些太长词分出来，或者带来效率问题。
二、效率低效率低是最大匹配法分词必然会来的问题。
即使我们可以将字长设成相当短，例如5（注意，我们不能再缩短字长了，毕竟字长为5以上的词太多了，我们不能牺牲分词的准确），然而当我们的大数词长为2时，至少有3次的匹配算法是浪费掉的。
回想一下算法书里提到的最简单的字符匹配与KMP算法之间天差地别的效率，我们知道通过某种方法，这些浪费的掉的匹配时间是可以补回来的。
三、掩盖分词歧义中文是如此复杂的语言，它的表达方式如此之多，语法文法如此精妙，机械的电脑是很难理解这么复杂的语言，因此它必然会带来歧意性，以下是两个简单的例子：A.“有意见分歧”（正向最大匹配和逆向最大匹配结果不同）有意/ 见/ 分歧/有/ 意见/ 分歧/B.“结合成分子时”（正向最大匹配和逆向最大匹配结果相同）结合/ 成分/ 子时/由于词的歧义性使我们在使用最大匹配法分词会产生错误的结果，而且使用正向分词与逆向分词往往会产生截然不同的结果。
尽管使用回溯法或计算计算词的使用频率，可以使出现歧义的可能性减少，但是我们知道，这样的结果是不可避免的，因为中文的变化实在太多了。
四、最大匹配的并不一定是想要的分词方式最大匹配法基于的理念是找到最大的匹配词，但有的时候除了最大匹配词外，我们也可能只需要这个词的一部分。
例如“感冒解毒胶囊”是一个完整的词，按照最大匹配法我们无法对它进行拆分了，这样我们输入“感冒”的时候就根本搜不到我们需要的词。
这是我们需要的吗？做为生产这种药的厂商，它肯定希望用户输入“感冒”甚至“解毒”，我们都能查到对应的内容。
1.2 设计自己的中文分词算法1.2.1 设计目标基于对分词算法的理解和对最大匹配法分词的分析，我们知道我们必须提出不同的解决方案，使分词算法的效率、分词的长度限制甚至歧义处理上得到提高。
因此我们提出了如下的设计目标：一、高效中文分词算法必须要高效，毕竟效率对于搜索引擎的重要性是不言而喻的。
而且我们面对的是海量的数据，而不是一篇几百字或几千字的文章，效率的差别的影响可能会使最后运行效率差几个小时甚至几天。
因此我希望我们设计的算法一定要比最大匹配法高，毕竟我们已经常看到最大匹配法的很多次匹配都是浪费在无用功上了，肯定有办法把这些浪费的时间节省回来。
二、无长度限制最大匹配法的长度限制真是很讨厌的事，我们很难找到词长与效率的之间的平衡。
为什么我们需要长度的限制？为什么我们不能设计出任何词长的词（只要词库中存在）都可以分出来？三、歧义包容我们相信长度限制的问题总是可以解决的，因为虽然长度限制这个问题很难，但是它是有规律可循的，它是严谨的科学。
但是当我们碰到中文歧义时，我知道不管我们怎么努力，它仍然是不可能彻底解决的。
因为中文实在太博大精深了，即使有极强的人工智能和机器学习功能，这样的错误仍然是难以避免。
既然无法避免？我们为什么不换一个角度去考虑？我们为什么不可以将出现歧义的各种可能性都包含进去，作为分词的参考。
例如上述的“有意见分歧”的两种分词方法：有意/ 见/ 分歧/有/ 意见/ 分歧/为什么我们不能把这样两种结果都拿来分词呢？毕竟分词的目的是为了搜索，而不是为了教小孩读出。
如果把两种分词的可能性都告诉搜索引擎，搜索引擎会很高兴的，因为这下不管是“有意”还是“意见”，它都可以搜到了。
这就是我提出来另一个目标：歧义包容。
1.2.2 算法的突破口—词库虽然我们的目标已经确定下来了，但是要想出一个更好的算法却是非常难的事。
毕竟算法需要的是灵感与突发奇想，这与系统的架构设计和面向对象的设计与编者编码刚好是相反的，象设计模式或重构这样的东西我们需要的实践、总结、再实践。
而算法需要的却是当我们在山重水复疑无路的时候会换个角度思考。
但是分词算法的突破口在哪里呢？我们必须要有一个词库，我们必须将全文中的词与词库去匹配，这一切都是不可避免的。
真正要改善是就是我们的匹配过程，我们要减少匹配过程中的浪费，我们要解决匹配中的词长限制。
但是我们有什么办法呢？每次的匹配我们必须要去词库中查找一次。
怎么改善这样的做法？我们总是把优化的思路定格在更好的匹配算法，更好地处理词条和全文。
但是真正束缚我们的却是词库！是基于关系数据库的词库，我们需要的对词库的改造，我们要让我们的词库更适合用于匹配与分词！这是几十年来关系数据库带给我们的思维：我们查找的词是数据库的某条记录，通过表格与关系代数，我们总能找到这个词。
但是正是关系数据库的这种思维束缚着我们，关系数据库让我们的数据结构及关联表达得清楚又简单，并使某些查询的效率变得很高。
但是这不适用于中文分词，有的时候退到几十年前流行的数据库模型也许更适合。
这就是层次数据库。
我们要做的是将关系数据库的词按字打散，并存放到层次数据库中。
以下就是一个示例：红色的字表示树上面的字串是可以单独组成一个词的，例如“感冒”它本身是词库里可以找到的词，所有红色的表示的是终止符。
而黄色则表示树上面的字串是无法单独成词的，例如“感冒解”是不存在的词。
真的很奇妙，词库经过这样的改装后，所有的匹配的思维都变掉了。
任何一个句子都会打散成单字去与树状结构的单字去匹配，词的长度变成了树的高度，每一次的匹配变成了树的遍历，而这种遍历的效率竟然都是线性的！1.2.3 中文分词算法设计有了以上的中文词库后，我们分词算法设计就水到渠成的。
首先我们来看一下分词的步骤：（1）首先将要分的全文按标点符号打散成一个一个的句子。
这算是预处理的一个步骤，目的是让我们处理的句子短，效率更高。
毕竟中间有标点符号的词是不存在的。
（注：真正实现时我们是基于lucene的SimpleAnalyzer来做的，因为SimpleAnalyzer本身就是为了将全文打散成句子，因此我们没必要耗费体力去实现这一步）。
（2）我们开始将要处理的句子在树状结构中遍历，如果找到匹配的就继续，如果遇到红色的终止符，我们就发现这个词是一个完整的词了，这样我们就可以把这个词作为一个一个分词了。
（3）从分词后的下一字开始继续做步骤2这样的遍历，如此循环往复就将词分完了。
可以看到，我们字符匹配效率几乎是线性的！我们所要做的只是取出每一个字去树上找到相应的匹配，每次的匹配代价都是O(1)（如果词库用Hash表的话），这样匹配下来的时间复杂度就是字符串本身的长度！对于一个长度为n的字符串来说，它的分词复杂度是O(n)。
而最大匹配的平均复杂度是O(n2)。
当然我们这里没有考虑歧义包容与分支处理等情况，但即使加上这些我们复杂度仍然是有限的。
1.2.4 中文分词算法的实现细节一、建立词库有了改装词库的基本思想后，建立词库的步骤变得很简单，但是仍然会有好多的细节需要注意。
首先是词库的保存格式。
现在最常用的保存数据的方式当然是关系数据库，其次是文件系统中的二进制文件。
显然关系数据库对于我们并不适用，而自定义的二进制文件则实现起来比较困难，而且读写的效率也会有问题。
因为我们想到了最简单的方法是利用java的serialization的功能，把整个内存中的树状结构直接序列化成磁盘的文本文件是最方便的！而且读写的效率也会相当的高。
第二个问题是树的父子节点的导航。
我们的树并不是一颗二叉树，父亲的子节点会有好多！尤其是第一层，我们会把词库中所有的首字都取出来作为根节点的子节点，这意味着如果首字有4000个的话，根节点就有4000个儿子。
当然随着树层数的增多，节点的儿子数也会减少，毕竟以“感冒”开头的词在整个词库也只有四十多个，而以“感冒清”开头的词则只有两三个了。
这意味着如果设计得不合理，我们树的匹配遍历过程并不完全是线性的。
最坏的查找算法是O(N)（N代表儿子数）。
当然如果我们建词库时将儿子有序排列，再按照二分查找的方法，则我们的复杂度会减到O(lgN)，这样的复杂度已经可以接受了。
但是还有更简单又更快的存储方式，为什么不使用呢？那就是HashMap，毕竟在HashMap里查找东西时它的效率几乎是线性的，而且实现起来要比二分查询简单得多。
当然用HashMap要付出存储空间变大的代价，但这样的代价来换取速度与简单性也是的。
第三个问题是找到有终结符的字后，我们必须要将它建成一个完整的词。
这时我们必须能从字个往上回溯，直到找到根结点。
因此我们在每个节点里都保存了父节点的指针。
有了以上的设计思想，我们就动手建立了我们的词库，词库的来源是中医药数据库的词汇表，因为我们应用一直是围绕中医药的。
我们找到了两个最重要的表，这两个表几乎包含了中医药的全部词库：一体化语言系统词库 92112个词疾病大全、症状、证候 20879个词最后生成的词库是java serialization的一个文件，文件的大小是16M 。
当然这跟我们采用HashMap存放父子关联有关，也跟java的对象所占空间有关，虽然将词库按这种方式存放实际上也对词库进行了压缩（以“感”开头的字有数十个，关系数据库里就要保存数十个，但我们在词库只保存了一个“感”）。
但文件仍然偏大，因此用oracle将这两个表导出后生成的文件大小是4M。
不过这个大小仍然是可以接受的，毕竟效率才是关键。