文件搜寻引擎

引擎结果

我使用Flask和Whoosh(一个纯Python搜索引擎库)构建了轻量级搜索服务。 您可以在finderseth.com上实时查看引擎。 资深的Python编码人员可以轻松地重新使用自己的代码。

我在设计时考虑了以下原则:可读URL,摘录的完整性和清晰度,探索性,完整性和易用性。

摘录

像结果一样,摘录可以按相关性或时间顺序排序。 当查看最佳匹配或(语义上)单个结果时,它们是完整的段落,否则它们由带有“ […]”省略链接的句子片段组成。 这些片段保留格式(例如,斜体)。

如果摘录暴露了足够长文档的一半以上,那么摘录数将受到限制以进行复制保护。

当JavaScript复制到剪贴板时,会仔细格式化并引用摘录。 那些按相关性排序的符号被强调以区别于源文本。

剪贴板引用:

“有意识的头脑不是浪子或自我的贫穷亲戚。” — NoPR第4章:第621节,1972年10月16日

完整文档的位置在展开箭头的后面可见:

匹配文档的扩展文本

使用Whoosh的“您的意思是……吗?”建议,并在其中添加了UK / US变体。 Whoosh支持许多高级搜索,例如日期范围,模糊术语和接近度。

默认搜索使用词干和停止词删除:
you are welcome → welcom
匹配“欢迎”,“欢迎”等

您可以在“ common”中加上停用词:
common:(you are welcome) → you ar welcom
或者跳过“精确”的词干:
exact:(you are welcome) → you are welcome

您当然可以在短语中使用引号:
common:"you are welcome" → "you ar welcom"

URL被设计为尽可能可读,例如
/q/heading:(essay+4)+'conscious+mind'/
,用流行的浏览器允许的字符替换html实体。

链接到/q/beer+OR+wine/20/等页面的链接始终可以正常运行,因为数字表示要跳过的匹配数,而不是可能会更改长度的“页面”。

使用OpenSearch可以从URL栏进行搜索,而顶部摘录则使用Open Graph在Facebook预览中呈现。

关键术语显示在每个文档标题的末尾。 这些功能既可作为摘要,又可作为链接,以探索文档中最独特的摘录。 它们是从Whoosh的tf-idf实现中生成的,然后通过词干清除了重复项。

在文档正文中不查找文本的搜索查询将显示为列表:

heading:dream的64条结果

最后有一个“更喜欢”部分:

相似的会议

我使用一组简单的正则表达式将Markdown格式的文本文件处理为Whoosh的“文档”(即单个结果),这些正则表达式指定了要处理的部分并标识了标题。 然后根据需要将标题分类。

这是一个示例books.py规范:

( books\sb.txt将包含Markdown)

在同一层中,新的标题将结束上一个标题。 我们用“ end”指定的其他任何内容。 例如,在到达附录后,我们在这里结束“部分”。 类似地,例如“第一部分”的开头结束了引言,就像“第二部分”的开头结束了“第一部分”的最后一章一样。 这些非常容易通过控制台输出进行调试。

“ tier2”是最具体的标题,并具有其自己的可搜索字段。 我们希望它对于单个文档的简洁URL来说大多是唯一的,例如session:869 ,尽管不是必需的。 您可以重命名它以适合您的应用程序,例如chapter:dogs 。

“ tier0”,“ tier1”以及“ headings_re”中用于标识它们的行是可选的。 它们参与了上面看到的简短标题和扩展标题的视觉样式,并且将搜索方式合并到heading ,例如
heading:"part one"或heading:"chapter 22" 。

带有venv和gunicorn的systemd单元/lib/systemd/system/search-engine.service:

自动启动: systemctl enable search-engine
运行: service search-engine start

如果您的某些文档具有比其他文档更深的层次结构,例如,某些文档是一整章,而另一些文档则是一章中的某个部分(在我的情况下为会话),那么您可能需要重命名“会话”→“标题”,并且’heading’→’extra’,或类似的对用户有意义的含义。

html输出有些模糊,并且大部分在代码内(尽管组织良好)而不是模板内。 将来可能会将其移至模板。

预期源文件位于Markdown中,但是您可以简单地为html省略commonmark() 。 我想它可以在纯文本上正常工作,但我还没有尝试过。

快乐的编码。