全文检索为什么需要精细化分词
在构建搜索、RAG、知识库等应用时，全文检索是绑定业务语义的关键环节。对于中文场景，分词质量直接决定检索的召回率与准确率——分得太粗会漏掉结果，分得太细则引入噪声。
传统做法是在应用层自行集成分词器（如 jieba、HanLP），再将分词结果写入数据库。这种方案的问题在于：分词逻辑与存储分离，词典更新需要重新灌数据，且难以在 SQL 层直接利用分词能力做实时检索。
PolarSearch 作为 PolarDB 内置的搜索引擎，将分词能力下沉到数据库内核，提供 IK 和 ANSJ 两套中文分词插件，并配合统一的词典管理体系（自定义词库、同义词、停用词），使得开发者可以在数据库层面完成从分词、词典配置到检索优化的完整链路。
两套分词引擎：IK 与 ANSJ 的差异化定位
PolarSearch 同时支持 polar-analysis-ik 和 analysis-ansj 两个分词插件，覆盖从通用场景到精细化 NLP 场景的不同需求。
polar-analysis-ik：快速落地的首选
IK 分词插件提供两种分词模式：
- ik_smart（粗粒度）：倾向于将文本切分为最少数量的词语，适合用于搜索查询端。例如"计算机汉字输入方法"仅会被拆成"计算机"、"汉字输入"、"方法"。
- ik_max_word（细粒度）：对文本做最大程度的切分，输出所有可能的词语组合，适合用于索引端以提高召回率。同样的"计算机汉字输入方法"会同时被拆成"计算机"、"计算"、"算机"、"汉字输入"、"汉字"、"输入"、"方法"等多个词条。
一个典型的实践策略是：索引时使用 ik_max_word 确保最大召回，查询时使用 ik_smart 提高精确度。这样既不会漏掉相关文档，又能保证排序合理。
IK 插件支持自定义主词典和停用词词典，通过 ext_dic_main 和 ext_dic_stop 参数进行配置。更重要的是，IK 支持热更新——修改词典后无需重启集群即可生效。
analysis-ansj：面向精细化 NLP 场景
ANSJ 分词基于 ansj_seg 算法实现，提供五种分词模式，每种模式针对不同的使用场景做了优化：
- base_ansj（基础分词）：基于词典的标准分词，速度快，适合对性能要求高、对分词进度要求不高的批量处理场景。
- index_ansj（索引分词）：针对全文索引优化，类似 IK 的 max_word 模式，输出更多词条以提高索引覆盖度。
- query_ansj（查询分词）：针对搜索查询优化，输出更精简但更有意义的分词结果，减少噪声。
- dic_ansj（用户词典）：当业务有大量专有名词（如药品名、型号、品牌）时，此模式会优先匹配用户词典中的词条，避免将专业术语错误拆分。
- nlp_ansj（NLP 高精度）：基于CRF（Conditional Random Field，条件随机场）模型，分词准确度最高，适合对语义理解要求严格的场景，如智能问答、意图识别等。
ANSJ 支持四类词典：用户词典、停用词词典、歧义词典和同义词词典，支持在配置文件中通过添加后缀Key区分并加载多个同类词典文件。
词典管理：三大能力构建检索语义闭环
分词器只是基础，真正让检索"智能"起来的是词典管理能力。PolarSearch 通过 cluster-dict-management 插件提供统一的词典管理平台，支持自定义词典、同义词和停用词三大核心能力。
自定义词典：让分词器认识你的业务术语
默认分词器的词库基于通用语料训练，面对特定领域术语时往往力不从心。例如"大语言模型"可能被错误切分为"大/语言/模型"，"向量检索"可能被切成"向量/检索"而丢失作为一个完整技术概念的语义。
通过上传自定义词典，可以将这些业务术语作为整词加入分词器。
同义词：扩展检索的语义覆盖
用户的搜索意图和文档中的表述往往不一致。"手机"和"移动电话"是一回事，"us"在某些场景下等同于"美国"。如果不做同义词扩展，这些语义等价的查询就会导致漏召回。
PolarSearch 支持两种同义词定义方式：
- 等价同义词：用逗号分隔的词组，如“手机,移动电话,智能手机”，表示这些词在检索时互相等价，搜索任意一个词都匹配所有。
- 定向映射：使用 => 语法，如“usa,us => 美国”，表示搜索"usa"或"us"时自动扩展为标准词"美国"进行检索，但反向不生效。
停用词：过滤噪声提升检索精度
"的"、"了"、"是"、"在"这类高频虚词几乎出现在每一篇文档中，如果不加过滤，它们会占据大量索引空间且对检索毫无贡献。停用词机制就是在分词阶段将这些词过滤掉。
PolarSearch 支持两种配置方式：
一是上传停用词文件（UTF-8 编码，每行一词），通过 stopwords_path 在分析器中引用；
二是在索引定义中使用 stop 过滤器直接以列表形式定义。
在实际项目中，建议根据业务语料统计高频无意义词，定制停用词表以获得最佳效果。
实战场景：电商搜索中的分词与词典协同
以一个电商搜索场景为例，看看分词与词典管理如何协同工作。
假设用户输入搜索词"苹果14手机壳"。处理流程如下：
第一步：分词。IK 分词器（ik_smart 模式）将查询切分为"苹果14"、"手机"、"壳"三个词条。如果没有自定义词典，"苹果14"可能被进一步拆分为"苹果"和"14"，导致检索结果中混入大量水果相关内容。这里自定义词典确保了"苹果14"作为一个品牌型号整词处理。
第二步：同义词扩展。同义词规则将"苹果14"扩展为"iPhone14"，将"手机壳"补充为"保护套"、"手机保护壳"等变体。这样即使商品标题中使用的是"iPhone14保护套"，也能被成功召回。
第三步：停用词过滤。如果查询中包含"的"、"个"等虚词，在此阶段被过滤，避免对召回产生干扰。
第四步：检索返回结果。经过分词、扩展和过滤后的词条集合用于匹配索引，返回精准的商品列表。
整个过程中，如果有新品发布（如"苹果15"），只需在自定义词典中添加新词条并触发热更新，无需重建索引或重启服务，即可让搜索引擎立即识别新术语。
工程实践建议
基于上述能力，总结几条在实际项目中的工程建议：
索引与查询使用不同分词策略。索引端用 ik_max_word 或 index_ansj 最大化召回，查询端用 ik_smart 或 query_ansj 提高精度。这是搜索引擎领域的经典实践，PolarSearch 原生支持在 mapping 中为同一字段分别指定 analyzer 和 search_analyzer。
词典更新后注意存量数据。IK 和 ANSJ 都支持词典热更新，但热更新只影响新写入的数据。存量数据如果需要应用新分词规则，需要执行 reindex 操作，实际操作中可考虑先在测试索引验证效果再执行重建。
同义词放在查询端而非索引端。如果将同义词扩展放在索引阶段，每次更新同义词规则都需要全量重建索引。放在查询阶段则更灵活——修改同义词文件后立即生效，无需触碰存量数据。
ANSJ 的 dic_ansj 模式适合垂直领域。当业务中存在大量不可拆分的专有名词（如药品通用名"盐酸二甲双胍缓释片"、产品型号"RTX-4090-Ti"等），dic_ansj 模式会优先匹配词典中的长词，避免将专业术语碎片化。
总结
PolarSearch 的分词与词典管理将文本分析能力内置于数据库层面，使得开发者无需在应用端维护独立的分词服务和词典同步逻辑。IK 插件适合快速落地的通用搜索场景，ANSJ 插件则为需要精细化控制的 NLP 应用提供了更多选择。配合自定义词典、同义词和停用词的统一管理与热更新机制，可以在不停服的前提下持续优化检索效果，满足业务演进中不断变化的语义需求。
