RediSearch FT.SEARCH 的 SLOP 和 INORDER 有什么区别

不少用RediSearch做全文检索的后端开发，写FT.SEARCH语句的时候经常分不清SLOP和INORDER两个参数的用法，两者的定位完全不同，用不对很容易出现匹配结果不符合预期的问题。

在 RediSearch 里，短语查询“能不能命中”经常不是索引没建好，而是两个约束混在了一起：词之间允许隔多远，以及词出现的顺序是否必须一致。SLOP 管前者，INORDER 管后者。它们可以分别使用，也可以叠加。

官方地址：https://redis.io/docs/latest/commands/ft.search/

本文只比较 FT.SEARCH 的短语词距和词序语义，假设索引已经存在，不展开索引创建、排序和分页。

先把 SLOP 和 INORDER 放到同一张语义表里

因此，SLOP 2 并不表示“必须按顺序”，INORDER 也不表示“两个词必须相邻”。前者限制距离，后者限制方向。

用同一组短语看 SLOP 如何控制词距

假设 @phrase:(hello world) 是查询短语。相邻的 hello world 中间没有词；hello simple world 中间有一个词；hello somewhat less simple world 中间有三个词。

# SLOP 1：只放宽到最多一个中间词
redis-cli FT.SEARCH memes '@phrase:(hello world)' NOCONTENT SLOP 1

# SLOP 3：允许最多三个中间词，召回范围比上面更宽
redis-cli FT.SEARCH memes '@phrase:(hello world)' NOCONTENT SLOP 3

# 不设置 SLOP：不额外限制 hello 与 world 的词距
redis-cli FT.SEARCH memes '@phrase:(hello world)' NOCONTENT

官方示例中，SLOP 1 可以命中相邻短语和只插入一个词的短语；SLOP 3 还能覆盖中间有三个词的文档。也就是说，数值越大，距离边界越宽，命中数量可能增加，但短语的紧密程度会下降。

如果业务问题是“标题里两个词必须靠得很近”，从较小的 SLOP 开始；如果只是想把少量修饰语视为同一概念，再逐步放大，而不是直接依赖默认的无限距离。

INORDER 只收紧词序，不收紧距离

不加 INORDER 时，查询词可以在文档中以不同顺序出现。比如文档包含 amazing hello world，查询 hello world 仍可能命中，因为两个目标词之间的相对顺序没有被额外锁定。

# 默认不要求同序：查询词的相对顺序不被额外锁定
redis-cli FT.SEARCH memes '@phrase:(world hello)' NOCONTENT

# INORDER 只要求 hello 在 world 之前，不负责限制两者相隔多远
redis-cli FT.SEARCH memes '@phrase:(hello world)' NOCONTENT INORDER

# 两个条件叠加：既要同序，又最多允许两个中间词
redis-cli FT.SEARCH memes '@phrase:(hello world)' NOCONTENT SLOP 2 INORDER

官方文档把 INORDER 描述为词项按查询顺序匹配，并特别说明它通常和 SLOP 一起使用。最后一条命令的语义可以读成：“hello 必须先于 world，且两者之间最多出现两个词”。

实际选择时记住这三个边界

1. 只关心距离：使用 SLOP n，不要误以为它会自动保持查询词顺序。
2. 只关心方向：使用 INORDER，它不会把相隔很远的词自动变成相邻短语。
3. 两者都关心：显式组合，例如 SLOP 2 INORDER，让“最多插入几个词”和“必须按什么顺序”同时可读。

还要留意查询语法和分词结果：SLOP 统计的是索引中的中间词项，不是字符数；中文或其它语言的切词方式变化，也会影响你对“相隔几个词”的直觉判断。

相关问题

SLOP 设置得越大越好吗？不是。它扩大召回范围，也可能让不够紧密的文本被当成短语，应该按业务容忍度选择。

INORDER 能替代精确短语匹配吗？不能。它只表达词序，精确程度还取决于查询词距、分词和其它查询条件。