共计 1456 个字符，预计需要花费 4 分钟才能阅读完成。
前两篇文章解说了 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 频道和咱们进一步探讨。