设置可搜索字段

可搜索字段用于控制用户的关键词可以匹配你的数据中的哪些字段。

在你开始设置索引时，第一步，也是最重要的一步，就是设置可搜索字段，以此控制数据中的哪些字段可以被用户的搜索词匹配到。

好的可搜索字段设置应该可以精准地为用户尽可能多地找到对应的数据，同时减少噪音和不相关对象出现在结果集中。本文中我们介绍如何选择和设置可搜索字段。

如何选择可搜索字段

并不是所有的字段都适合作为可搜索字段，比如说，如果你的数据中有一个随机生成的 id 字段，比如 APP7B997C，代表文章 ID 的话，就不应该包括在可搜索字段中。

原因是，用户在搜索时，极少会想去搜索这个随机字段中的词语。因此，将这个字段设置成可搜索，反而会让引擎搜索出不相关的对象，提高噪音对象的比例。

因此，可搜索字段不是越多越好，虽然增加字段可能提高搜索的召回率，但可能会极大地降低搜索结果的准确性，让用户看到太多无关的对象，影响用户体验。

在思考选择用哪些字段可以优化搜索体验时，可以逆向思考：如果用户用一个搜索词，在这个字段中匹配到了，会对他们找到这条数据有帮助吗？

在上面的例子中，如果我们把这个 ID 作为了可搜索字段 (APP7B997C），那么当用户搜索 APP 这个词时，即使标题和内容中不包含 APP，但因为 ID 中有，这个对象也会被包含到结果中，造成用户的疑惑。因此，这个字段对于用户搜索来说，没有帮助，不应该包含在可搜索字段中。

接下来我们用一个实例来说明怎样选择可搜索字段：

如果你的数据均为一些用户生产的文章（UGC），这些文章有以下字段

对很多帖子来说，标题和摘要就可以包含整个帖子的信息。因此，标题和摘要应该被包含在可搜索字段中。

而正文则需要视情况而定。如果这些帖子都很长，那么它们就很可能包含越多与主题不相关的信息，因此包含正文不一定可以增强搜索体验。另一方面，很多文章在开头都会写一段提纲挈领的话，而这段话的信噪比会比较高。因此，把正文的前 100 个字符单独作为一个字段，增加到可搜索字段中，也许是一个不错的选择。

最后，文章链接通常不会含有太多信息，因此通常不添加至可搜索字段中。

我们给出一些不同使用业务下，常见的应该加入可搜索字段中的例子

应排除出可搜索字段的例子

在卡拉搜索后台，你可以很方便地设置可搜索字段。

下图的例子中，我们添加了一个 title 标题字段和一个summary 摘要字段。

$\u8BBE\u7F6E\u53EF\u641C\u7D22\u5B57\u6BB5$

请注意，所有对索引的设置都是实时生效的，如果你调整了索引的设置，它会立即生效。

如果你刚开始接触排序，我们建议你新建一个测试索引。先往这个测试用索引上传一些测试数据，调整好排序后，尝试在后台直接搜索验证一下排序效果。确认无误后，再将设置放到生产环境的索引中。

同时，在此处字段类型必须是字符串型，但即使你添加了一个数值类型的字段，引擎也不会报错，但会忽略掉这个设置。因此在添加字段时，请务必检查类型为字符类型，且字段名拼写正确。

对于一个查询，可搜索字段不仅会影响哪些对象出现在结果集中，也可能会影响这些结果的排序。

原因是，可搜索字段的顺序会影响到一些排序器的行为，从而影响最终结果的顺序。

如果你添加了最佳字段排序器，那么在以下的例子中，可搜索字段的顺序会影响结果的顺序，详情请见排序器设置

假设你的数据中有两个对象，分别是

对象 1:

{
    "title": "无间道",
    "summary": "一部2002年香港警匪电影"
}

对象 2：

{
    "title": "末路狂澜",
    "summary": "又名《神偷无间道》，故事发生在车水马龙人头攒动的法国巴黎街头..."
}

你在索引上如果将可搜索字段调整成从上至下 title 即电影标题, summary 即电影简介，那么对于查询 无间道 来说，它会将对象 1，即《无间道》排得更前，因为引擎会按照你的要求优先考虑标题。

而如果你把字段调整成先 summary 再 title，那么搜索 无间道 时，它会将《末路狂澜》排得更前，因为引擎会按你的要求优先考虑电影简介。

对于排序器如何工作，以及可搜索字段如何影响排序，请参考文档：排序器设置