项目实训 : 搜索引擎构想

由于古籍中存在大量的古文字，现存的搜索引擎对其支持度并不满意，于是我决定自己写一个小型的搜索引擎，以专门服务器与我们的古籍。

构思

存储

我们的目的是根据前端传入个个别字句进行文章的匹配。文章并不会包含字符，字符主要是存在Page中，Page包含了其父文章的id，并且存有具体的内容，我们可以根据这一特征构建一个BO，用于将不同的SdudocArticle转化为具有具体内容的SearchableArticleBO

SearchableArticleBO应该具有以下内容：

属性	类型	说明
articleId	String	SdudocArticle的唯一标识
content	String	文章包含的完整内容

然后我们根据content进行中文分词，将其分为若干个不相同的字词并对这些字词进行存储，存储为实体SearchableSegment，大致内容:

SearchableSegment

属性	类型	说明
content	String	唯一标识，同时也为该片段的文本信息，具有唯一性
articleIdList	List	文章的反向索引列表

由于存在列表，故使用MongoDB存储。

修改

其次，由于文章内容并不是一成不变的，所以还需要考虑当文章内容出现变动时，该如何修改当前的存储信息。

那么首先我们就必须直到我这篇文章关联了多少SearchableSegment，这也就意味着片段拥有逆向索引的同时，article也应当维护一个正向索引

SearchableArticle

属性	类型	说明
articleId	String	文章id，与SdudocArticle的ID对应
segmentList	List	片段的正向索引

当文章内容出现变更时，可以根据比较其segment的异同来判断哪些segment被移除，哪些是新添加的。然后根据正向索引去相应修改segment的逆向索引。

查找

查找是一个比较需要探讨的话题了，查找的精度其实是和传入的文本长度有关的，如果文本长度足够长，那么搜索引擎就更能精确的找到他想要的东西。当前端传来一个字符的时候，并不会走搜索引擎，因为如果搜索引擎要将segment细化到一个文字的话，会造成存储量爆炸，并且索引数量也是几何式的增加，这并不是我们想要的结果。我们关心的是长度在两个或两个以上，真正能形成词组的搜索文本。

那么对于单个文字，我们的搜索可以直接去SdudocPage里通过模糊查找符合条件的page并把page对应的文章进行汇总后返回，如果数量过大则采用分页的方式。

对于长文本，我们对其进行一次分词操作，将其分成若干个不同的部分。按照设计理念，我们应当实现按照相关程度顺序返回文章，那么问题来了，如何判断相关程度呢？

记得当时在学习数据科学导论的时候学会了一种tf-idf的方法，并利用余弦相似度进行匹配，但是那种方法主要用于匹配两个文本，而我们这里为了实现快速的查找，不能逐一进行匹配评分然后排序，而是之间比对，然后根据比对的结果来评分。我想到的切入点有两个：

1. 根据匹配的个数来评分

   由于一段文本可以被分为若干个部分，然后按照文章匹配文本段数的多少来进行排序，比如说文章a包含了我的搜索文本的6个片段，而文章b只包含了2个，那么我可以以很高的置信度下判断认为文章a比文章b更符合搜索内容。

2. 根据关键字进行评分

   一段分本并不是所有片段都是有用的，我们可以根据关键信息来进行加权评分，综合匹配个数来个出一个最终的分数。