我们帮助 将搜索集成到他们的应用程序中 的许多客户希望他们的搜索能比严格匹配文档更智能。
实现这一点有很多方法。Manticore Search使这变得非常容易，因为模糊匹配是开箱即用的。它由三个主要组件组成：

1. 法定人数运算符：

"computing and technology news"/2这意味着短语中至少应该匹配两个词，即这个查询将找到同时包含"computing news"和"technology news"的文本。

2. 邻近搜索运算符：

"computing news"~3这意味着查询词之间可以有少于N个不匹配的词。以下是几个例子，给定文本为a b c d e f g h：

• "a h"~7 可以找到，因为b c d e f h是6个不匹配的词，这小于7
  然而 "a h"~6 将找不到文本
• "a d h"~6 可以找到
• "a d h"~5 将找不到

3. NEAR运算符

computing NEAR/6 "technology news"

上面的邻近运算符仅适用于关键词集。NEAR更通用，可以接受任意子表达式作为其两个参数，当两个子表达式在N个词之内找到，无论顺序如何，就匹配文档。

上述查询将：

• 匹配包含computing is a popular topic in technology news的文档，因为第一个词和短语在6个词之内找到
• 但不会匹配computing nowadays is a popular topic in* technology news，因为间隔已经是6并超过了NEAR运算符中设置的限制。

二次传递逻辑

我们的许多客户使用二次传递逻辑：首先运行一个更严格的查询，如果没有找到结果或返回的结果不够，则发出第二个不那么严格的查询。还可能有更高级的逻辑，包括第三和第四次传递。这取决于您的需求，以及是否希望用户无论如何都能找到一些内容。或者，相反，您希望他们找到完全匹配其查询的内容。

有时反过来做并使查询更严格也是有意义的。例如，如果您的默认匹配策略是"应该匹配任何词"，并且您的应用程序没有扩展语法让用户自己指定最佳查询，那么首先尝试"所有词都应该匹配"的策略，甚至是"短语应该匹配"，这可能会显著提高搜索质量。

在某些应用程序中，并行化第一/第二次传递查询是有意义的。这可以通过Manticore Search的多重查询轻松完成。这里的逻辑是提前进行第二次传递查询，如果第一次传递查询没有找到任何内容，结果就已经准备好了，由于查询是同时进行的，这提高了性能。然而，这取决于很多因素。您应该小心，因为有时可能会降低性能。这些因素包括：

• 您使用什么硬件？如果硬件不足以同时处理两个查询，或者响应时间接近单个查询响应时间的两倍，那么使用这种技术就没有太大意义。
• 您的负载是什么？如果您的Manticore Search实例/服务器已经负载很重，您将得到更差的响应时间。
• 您的统计数据是什么？如果99%的查询第一次传递都返回结果，那么与第一次传递查询同时进行第二次传递查询就没有太大意义，这只是浪费资源。