Redis FT.SPELLCHECK 怎样排除业务专有词典

先用 FT.DICTADD 建立业务专有词字典，再在纠错请求后增加 TERMS EXCLUDE 字典名。如果业务目标是让查询中的品牌名、内部术语免于拼写纠错，这个写法比把它们强行加入搜索文档更直接。

需要注意“排除”作用在哪里：本文结合官方仓库当前实现讲解——查询词命中排除字典时，不为这个词返回纠错建议。不要把它当成一个必然从所有建议结果中删去禁词的通用黑名单。

Redis 官方命令地址：https://redis.io/docs/latest/commands/ft.spellcheck/

# 创建或补充业务专有词字典；词项使用单独参数传递。
redis-cli FT.DICTADD demo:spell:protected lumora navexa

# demo:catalog是已经存在的搜索索引；专有词按查询级排除规则处理。
redis-cli FT.SPELLCHECK demo:catalog "lumora camrea" TERMS EXCLUDE demo:spell:protected

lumora、navexa是本文虚构的业务词，camrea是用于说明纠错的拼写输入。实际候选取决于索引内容，不能因为命令写了camrea就保证一定返回camera。本文所有命令均为写作示例，未在数据库执行。

为什么不能只靠普通纠错保护专有词

搜索框里的一个词不在索引中，可能是拼写错误，也可能是刚上线的产品代号。用户输入的专有词如果总被提示改成别的普通词，问题往往在纠错范围，而不是编辑距离不够大。

有些系统会把专有词塞进文档来“消除报错”，结果让索引承担了不属于文档的数据职责。更清晰的做法是分别管理索引词汇与业务保护词，并在需要保护的纠错请求中显式引用字典。这是规则配置的选择，不代表新增了搜索召回数据。

新规则是查询级引用，不是全局永久开关

FT.DICTADD负责管理字典内容，FT.SPELLCHECK中的TERMS负责选择本次如何使用它。创建一个字典，不代表所有索引和所有后续请求都会自动采用它；应用构造请求时必须带上所需参数。

官方命令参考对TERMS作了包含与排除的简要说明；官方概念页把排除词描述为不返回的拼写替代项。但官方仓库的SpellCheck_ReplyTermSuggestions实现先用查询词检查excludeDict，命中就直接不生成该词的建议。两处措辞不宜混为一个更强的保证：本文示例采用后者明确可见的“输入词免纠错”行为，具体部署应以对应版本为准。

因此，若目标是屏蔽建议中某些不允许显示的词，应用仍需要独立的候选过滤策略，不能仅凭EXCLUDE这个名字就认定该需求已经覆盖。不要把业务展示规则与搜索纠错参数混在同一份隐含约定里。

INCLUDE与EXCLUDE怎样选择

把同一个业务词同时放进保护字典和候选字典并不是一种通用的“更强保护”。应先写明产品规则：保护用户原词，还是允许把别的拼写建议成该词，再决定请求使用哪份字典。命令支持多组TERMS，但配置越多并不自动意味着语义越清晰。

# 候选词字典用于补充建议来源，和输入保护词字典分开命名。
redis-cli FT.DICTADD demo:spell:candidates camera camcorder

# 同一次请求可以引用不同用途的字典；不把INCLUDE当作免纠错。
redis-cli FT.SPELLCHECK demo:catalog "lumora camrea" DISTANCE 1 TERMS EXCLUDE demo:spell:protected TERMS INCLUDE demo:spell:candidates

DISTANCE控制建议的最大编辑距离，默认值为1，官方命令参考给出的最大值为4。它解决相近拼写的候选范围，不能替代词项是否属于业务专有词的判断。

独立演示：让索引与保护词各司其职

以下使用仅供演示的新索引和文档前缀。在支持Redis Search的隔离环境中，确认名称未占用再逐条使用；创建失败应停止，不要继续写入未知的已有索引。

# 创建演示索引，只收集独立前缀下的HASH文档。
redis-cli FT.CREATE demo:spell:catalog ON HASH PREFIX 1 demo:spell:doc: SCHEMA title TEXT

# 普通候选词来自演示文档，专有词则维护在字典中。
redis-cli HSET demo:spell:doc:1 title "camera camcorder"
redis-cli FT.DICTADD demo:spell:protected lumora navexa

# 先说明无排除参数的请求形式，再给出业务保护请求。
redis-cli FT.SPELLCHECK demo:spell:catalog "lumora camrea"
redis-cli FT.SPELLCHECK demo:spell:catalog "lumora camrea" TERMS EXCLUDE demo:spell:protected

这个对比的目标是观察输入lumora是否被排除出需要建议的词项，而不是预设整份返回数组逐字相同。索引准备程度、词项处理方式和实际内容会影响建议，本文没有编造响应分数或命中数量。

排除规则以实际解析到的词项为对象。多词品牌、连字符、大小写与语言分词都可能让用户看到的字符串和参与纠错的词项不同；不能把一整句原始输入放进字典，就假定所有组成部分都会受到同样保护。

接入时保留明确的边界

把字典名、词项列表及请求选项放在受控配置中，调用客户端时按独立参数传递。不要把用户输入直接拼接成shell命令，查询里的空格也不能让命令行替你决定参数边界。多业务共用Redis时，可以在字典命名中体现业务范围，避免一份通用保护表改变所有场景的行为。

建议返回给用户以后，也应由产品决定是展示“你是否想搜”，还是等待用户确认。FT.SPELLCHECK产生建议，并不会替应用自动改写和执行原搜索请求。没有建议也不等于输入一定拼写正确，更不等于搜索一定有结果。

FT.DICTADD会把专有词写入搜索索引吗？

不会，它维护自定义字典。字典内容与索引文档是不同对象。

TERMS EXCLUDE会删除业务词或文档吗？

不会，这里的参数用于本次拼写纠错请求，不执行字典删除或文档删除。

为什么设置后某个多词品牌仍有建议？

先区分原始短语与解析词项，再确认应用发出的请求确实引用了正确字典。也要明确需求是保护输入，还是过滤返回候选，两者不可混用。

依据：FT.SPELLCHECK参考、FT.DICTADD、纠错概念说明与官方纠错实现。本文借用变更解释的组织方式，并未声称这是某个刚发布的提案或新功能。