乐趣区

关于算法:系列教程-用Jina搭建PDF搜索引擎Part-3

前两篇文章解说了 PDF 搜寻的操作方法,本期推送将解说构建 PDF 搜索引擎的教训和教训。

之前咱们以一个案例为代表讲述的 PDF 搜索引擎的构建,并不能包揽全副 PDF 搜寻的品种和状况。

咱们的初始版本如下:

https://github.com/alexcg1/ex…

它旨在:
01

具备通用性,并能很好地解决任何类型的 PDF 数据(强调工作良好 – 仅仅返回后果并不意味着它是好的 – 它须要返回高质量的后果)。

02

跨模态搜寻,因而你能够应用图像 / 文本作为输出 / 输入。

初始版本后果

后果是次优的。我将一些从维基百科下载的 PDF 文件作为示例数据集,从那儿咱们能够找到任何事物的维基百科搜寻页面。

但数据迷信的根本规定是:绝大部分的工作都在于依据用例做数据预处理。因为每个潜在的应用案例都有截然不同的数据,因而破费数小时将维基百科 PDF 整顿好没有多大意义。

例如,在搜寻“兔子耳朵”时:

咱们能够失去简短的无序列表的文本片段,这些文本片段只有 URL 链接或者是只有几个单词长的字符串。

只管对于兔子耳朵的句子被索引了,然而其中大多数只是对于兔子的,没有提到耳朵。

与一些不太相干的匹配后果相比,最相干的匹配得分较低(在余弦中,分数越低意味着相关性越高)。

只管键入了所述图像的形容且被索引,然而都无奈返回图像。

后果失败起因

01

编码器或模型自身不够好(反驳:CLIP 尽管不适宜文本,然而至多是可用的。)

02

兴许数据集自身太小了(反驳:尽管它只是几个 PDF,但被分解成几千块,其中许多是残缺的句子或图像。)

03

索引(* 尾注,文本片段,对书页的援用)不是“实在内容”,编码器无奈解读其中的大部分内容。(解释:可能是次要问题)

如何调整 PDF 搜寻以适应别人建设的 PDF?

到目前为止,在 PDF 搜寻中大多数人都心愿只关注文本,这并非好事。

以前咱们试图搜寻文本和图像,须要一个编码器能够将两者都嵌入到一个公共向量空间中。即 CLIPEncoder(如下所示):

https://hub.jina.ai/executor/…

CLIP 十分善于图像搜寻,然而文本搜寻体验较为个别!

咱们能够用什么来代替 CLIP?

如果咱们只解决文本,咱们能够应用其余编码器,例如:

01

SpacyTextEncoder:反对多种语言,速度快,适宜通用文本。

参考链接:

https://hub.jina.ai/executor/…

02

TransformerTorchEncoder:反对多种语言和非凡例子(例如医学文本搜寻)。

参考链接:

https://hub.jina.ai/executor/…

咱们将建造什么样的搜索引擎?

挪动部件更少就可能更分明地看到工作细节,咱们能够采纳这种策略构建搜索引擎。

因而,咱们咱们将为简略文本 PDF 构建一个搜索引擎,文本不须要太多预处理:

1、删除页码。

2、删除尾注、脚注。

3、解决大量援用和意外标点符号(如)。Fly-fishing for Dummies, 1988 Penguin Press, A.Albrechtson et al, pp.3–8. http://penguin.com/flyfishing

4、在分页符之间合并文本块。

简而言之,剥离所有可能使编码器无奈运作的事物。启动运行后,咱们就能够开始思考:

1、更简单的 PDF(逐步减少)。

2、多语言搜寻(曾经存在用于此的模型)。

3、搜寻文本和图像。

欢送提出对 PDF 搜寻的想法!如果您有任何想法,通过 https://slack.jina.ai/ 退出咱们的 Slack,并在 #projects-pdf 频道和咱们进一步探讨。

退出移动版