a)       目前采用的策略：提取项目描述信息中be动词之前的部分，进行一系列去噪（包括：去除定语描述信息——逗号限定定语，去除定语描述信息——定冠词the限定定语，去除从句描述信息——that、which、what限定词，去除指示代词——it、the、this等，去除单纯的项目表示词——project、application，去除指示代词和单纯项目表示词的笛卡尔积——this project等）

b)      出现的问题：

                      i.            这样提取出来的项目别名一般性不好，在程序运行中发现会出现提取出What、There等这样的特殊词，而且统计结果表现出很多项目都存在这样的情况，因此在后面的匹配过程执行完后会出现包含这中项目别名的项目大量聚合形成程序默认的相同项目（聚合的原因还与我们下面的第二个问题有密切关联），因此出现错误的聚合。

                    ii.            这样提取还存在别名提取不到或别名中包含大量项目描述信息的问题：例如这样的项目描述（目前的很多的项目中都用到了GIS 软件，然而在开源的GIS软件中有SharpMap在工程应用中开始被人发觉。）用我们的别名提取策略就不能提取出有效信息，因为无法找到有效的be动词；而对于下面这个描述信息（关于 BeautyEye L&F BeautyEye is a Java Swing cross-platform look and feel.），我们程序中会提取到“关于 BeautyEye L&F BeautyEye”这样的别名，而实际上前面一部分只是描述信息。

2.     项目相似度计算阈值的设置：

a)       目前采用的策略：对具有相同项目别名的项目进行TFIDF算法的相似度计算，如果两个项目都有标签信息，则采用标签信息进行计算；如果两者之一没有标签信息，则采用项目描述信息进行文本相似度计算。对于来自同一社区的项目我们认为只有相似度大于0.9才能算确实是同一个项目；对于不同社区的项目我们认为只要相似度大于0.1，就认为是相同的项目。

b)      出现的问题：这两个阈值设置的没有科学依据，因为在上一个问题的基础上，我们有了一个来自openhub社区的项目一，它提取出的别名是“There”，在实际的匹配中会出现很多来自非openhub社区提取出“There”作为项目别名的项目与项目一匹配上了，这就说明在这种情况下这个阈值设置的过低。

3.     IK分词器的分词效果不理想：

a)       目前采用的策略：目前在计算文本相似度的时候我们会用到ik分词器对项目描述信息进行分词。

b)      出现的问题：

                      i.            ik分词器智能分词选项智能比较好地处理中文，对于英文只是简单采取空格分割的方法，对于这个问题我们目前增加了一步人工处理（对于每一个分词用正则表达式提取中英文，中间用空格连接）。

                    ii.            ik分词器中停用词过少，分词结果中有很多常用词，影响最后相似性的计算（目前的停用词词库采用的是项目帖子匹配程序中ik分词器停用词词库）。