在搜索业务中，词项的精准识别是决定BM25与文本匹配效果的核心基础。

很多人都遇到过这样的搜索困扰：输入“iPhone 15 Pro Max”，返回的却是iPhone 15对比其他机型的无关内容；搜索拼写变体“odsseia”，却漏掉了大量关键词为“Odyssey”的相关结果。这类误召、漏召的问题在日常搜索中十分常见，不少人第一反应会调整BM25参数、修改匹配规则、更换嵌入模型，甚至叠加重排序模型来优化效果。

但实际上，检索系统的工作流程并非如此：原始文本并不会直接进入BM25或文本匹配环节，而是会先经过分词器（analyzer）处理，被转换为标准化的词项（Token），之后才会进入倒排索引构建、相关性匹配与打分阶段。

如果分词过程中出现词项切割错误、遗漏关键概念，或者引入过多噪声内容，哪怕后续的相关性打分公式再精细，也是在错误的基础上计算相关性，最终的搜索结果必然会出现偏差。

也就是说，如果词表存在缺陷，整套检索系统从源头就无法准确识别业务场景中的核心实体与概念，后续再多的优化都无法从根本上解决问题。而自定义词典的价值，正是帮助搜索系统明确词项边界：哪些字符串代表完整的业务概念，哪些应该拆分为基础词汇，哪些应该被忽略，哪些表达属于等价概念，哪些概念可以进行扩展。

一、自定义词典对BM25与文本匹配的核心影响

词表治理是影响BM25与文本匹配表现的根基。通用分词器在处理专业术语或复合短语时，往往会将其拆分为基础词汇，这种切割会破坏词项的边界，同时导致BM25评分偏离和文本匹配召回失控。

对于BM25来说，其词频（TF）、逆文档频率（IDF）和文档长度评分完全依赖词项统计。一旦分词粒度出现偏差，统计数据就会失真。

以“语义搜索”为例：如果分词器将其拆分为“语义”和“搜索”两个独立词汇，虽然拆分本身没有问题，但如果没有将“语义搜索”作为完整的固定短语赋予更高权重，那么系统在检索时，只要文章中包含“搜索”二字，哪怕是讲解搜索接口、搜索日志的普通内容，都会因为高频匹配获得较高的评分。而真正专门讲解语义搜索的专业文章，其专属的特征会被淹没在大量泛相关的结果中，权重被稀释，最终排名靠后难以被用户找到。

在医疗（药品名、疾病名）、金融（指标术语、监管术语）、电商（规格型号）及企业知识库（API名、算法名、内部系统名）等场景中，这种分词失真的问题尤为明显。自定义词典能够将专业词汇锁定为独立的统计单元，使BM25的TF/IDF计算完全基于业务语义，而非零散的字符组合。

不少人认为文本匹配只是简单的字符串包含或完全匹配，不需要依赖词典，但实际上文本匹配同样基于词项工作：查询文本会先被切分为token，再用这些词项去匹配倒排索引，只要存在任意一个相同的token就会被视为有效匹配。如果词项的边界不清晰，召回的结果就会偏离用户的真实搜索意图。

例如搜索“全文检索”时，若被切分为“全文”和“检索”，系统就会错误捞出“全文报告生成”或“日志检索接口”等文档。这些结果虽然凑巧包含了字符碎片，但与搜索意图无关。

这种情况下，自定义词典的作用在于固定Token边界，让“全文检索”、“向量数据库”、“权限模板”等专有名词成为明确的单个匹配单元，让文本匹配摆脱对零散字符组合的依赖。至于词语之间的顺序与邻近关系，则是后续短语匹配（Phrase Match）需要解决的问题，自定义词典处理的是更上游的词项边界问题。

二、词表治理的泛化与精准平衡

无论是BM25还是文本匹配，表面上处理的是词项，但系统真正需要识别的是文本背后承载的业务概念。然而词项和概念并非总是一一对应的：同一个概念可能被拆分为多个词项，多个独立的词项组合起来也可能代表一个更具体的业务概念。这就导致词表治理容易陷入两个极端。

一种倾向是认为token越多越好，以为更多的词项能带来更强的泛化和联想能力，但代价是存储、索引和搜索开销同步上升：词项越多，倒排索引中的词项和posting list就越多，写入、索引构建、查询匹配与打分需要处理的数据量都会增加。

另一种倾向是过度压缩token数量，虽然搜索速度变快、存储占用变少，但联想能力会下降：当用户查询一个宽泛概念时，系统无法召回那些只在更具体概念中出现的文档。

真实业务中，我们通常需要在两者之间找到平衡。比如企业搜索需要一定的泛化能力，输入“检索”时希望也能找到包含“搜索”的内容；而电商搜索则需要更高的精准度，搜索“向量数据库”时，不能被大量只包含“向量”或“数据库”的无关文档淹没。

因此，自定义词典并非简单地“多加词”，而是需要精准区分“一个完整的技术概念”和“两个词刚好连续出现”的情况，然后根据当前场景的需求，控制哪些地方需要泛化，哪些地方需要精准；哪些概念应该被拆开，哪些概念应该被组合保留；以及哪些概念应该被无效化、等价化，或者只做单向扩展。

在实践中，不同语言的词项边界规则不同，不同业务场景关注的概念也不同，自定义词典需要根据实际情况做灵活变通。

（一）中文场景：解决概念发现问题

中文文本没有天然的空格分隔边界，因此中文搜索首先需要解决的问题是从连续的文本中准确识别出有意义的词项。如果没有自定义词典，系统很难判断“向量数据库”是一个完整的业务概念，还是“向量”和“数据库”两个独立词汇的偶然连续组合。

主流的中文分词工具自带默认词典，可以覆盖通用场景中的常见词汇，但默认词典无法天然识别企业内部的产品名、项目名、医学术语、金融产品、商品型号、技术缩写等专有词汇，也很难及时覆盖新出现的专业术语。

这就是中文自定义词典最基础的作用：补充更贴近业务场景的词汇表，让专业概念能够被正确识别和拆分。

此外，中文概念往往存在多级组合关系：从“向量”到“向量数据库”，再到“分布式向量数据库”。如果希望保留多粒度召回，可以使用更偏泛化的分词模式，让组合概念和子概念都进入索引；如果更关注精准度和搜索速度，可以使用更少泛化的模式，减少词项数量。这时就更依赖自定义词典来保证关键领域词能被正确提取。

（二）英文与法语场景：处理复合词与专业词组

如果说中文自定义词典的核心作用是解决概念发现的问题，那么英文、法语等带有天然空格分隔的语言，自定义词典更多是在已有词项边界的基础上，进行概念拆分和概念组合。

英文、法语等语言通常可以通过空格和标点完成基础的词项发现，还可以通过词干提取或词形归一化，让run、runs、running这类词在概念上保持一致。但这并不意味着这类语言不需要自定义词典。

英文中有大量复合词和专业环境下的固定词组：有些词项过于粗粒度，需要拆分为更小的概念；有些连续的词项单独看都很普通，但组合起来才是专业概念。

decompounder工具用于拆分复合词，将过粗的词项拆分为更小的概念。比如技术文档、商品描述、内部命名中常见的复合写法，如果不进行拆分，在搜索组成部分时就可能丢失召回结果。

phrase_dictionary（词组词典）则用于将词典中声明的连续词项组合为稳定的概念，适合产品名、专业术语、专有名词，以及不希望被过度泛化的固定表达。

（三）跨语言通用词典：停用词与同义词

除了语言本身带来的差异，还有一些词典场景几乎适用于所有语言。它们不一定改变基础分词，但会决定哪些概念应该进入检索，哪些概念应该被忽略，哪些概念应该被扩展。

stop words（停用词）用于去掉没有检索价值，或在当前数据集中区分度太低的概念。除了通用的虚词，企业文档中的“系统”“平台”“服务”“模块”这类高频模板词，也可能在特定场景中成为检索噪声。

synonym（同义词）用于处理相同含义的不同表达，或者需要单向扩展的上下位概念。比如“搜索”和“检索”可以视为等价；在某些场景下，搜索上位概念时希望召回下位概念的内容，但搜索下位概念时不希望反向扩展到所有上位内容。

实际使用中，可以将几种自定义词典组合使用：领域词典负责发现和保留专业概念，decompounder和phrase_dictionary分别处理词项拆分与组合，stop words降低检索噪声，synonym补足表达差异和概念引申。

三、自定义词典需要独立管理的必要性

如果自定义词典只有寥寥几个词条，直接写在系统配置中似乎可行，但在真实的业务系统中，词典的规模往往要大得多。一个企业知识库可能包含几千个内部术语，一个电商系统可能有几十万个品牌、型号、规格和别名，一个医疗搜索系统需要维护大量药品名、疾病名和检查项目，一个技术文档系统则会持续新增新的API、参数、错误码和组件名。

这些词表并非一成不变：新产品发布、文档改版、业务线合并、术语标准化，都会带来词典的更新。因此，自定义词典更自然的形态是独立的文件，而非几行内联配置。

使用独立文件作为词典有诸多优势：

• 可以批量维护大量词条，提升管理效率

• 可以由搜索团队、业务团队、数据团队共同协作维护

• 可以纳入版本管理和审查流程，确保变更可追溯

• 可以在多个数据集或应用之间复用，避免重复配置

• 可以独立进行测试、灰度发布和回滚，降低变更风险

将词典作为独立文件管理，也意味着我们承认它是检索质量的核心组成部分，和嵌入模型、索引参数、重排序模型一样，都会直接影响最终的搜索体验。正因为词典是企业的业务资产，需要被稳定分发、版本化、复用和保护，因此在分布式系统中，如何做好词典的管理就变得尤为重要。

四、不同部署环境下的自定义词典使用方案

（一）单机或共享存储环境下的本地词典使用

最简单的词典使用方式，是让检索系统读取本地的词典文件。这种模式适合两类场景：单机部署的检索系统，或者所有相关节点都能访问同一份共享磁盘、共享文件系统的集群环境。在这些场景中，文件路径本身是稳定的，所有进程都能看到同一份词典文件。

使用时，只需要准备好词典文件，放置在检索系统进程可访问的路径下，然后在数据集的文本字段配置中引用该文件即可。例如，一个中文分词自定义词典可以包含以下内容：

向量数据库
语义搜索
全文检索
混合搜索

在字段配置引用该词典后，相关文本在进入索引和查询阶段时，这些领域词就可以作为稳定的检索单元参与BM25或文本匹配计算。

停用词文件的使用方式类似，比如常见的中文停用词可以包括：

的
是
在
了
和

同义词文件则可以维护查询表达和文档表达之间的映射关系，例如：

搜索, 检索, 查询
向量, 矢量, vector
删除, 移除, drop
红色，红 => 玫瑰红，蔷薇红 //搜索红色时可以召回对应的扩展色，但是搜索具体扩展色时不会反向扩展到宽泛的红色

只要文件路径稳定、所有节点都能访问该文件，本地文件模式就是最直接高效的词典使用方案。

（二）本地文件在分布式环境中的局限性

一旦进入无共享文件系统、也没有统一资源分发机制的分布式环境，本地文件模式很快就会带来一系列运维问题。

检索系统集群通常包含多个进程，查询、建索引、数据导入、压缩等阶段可能在不同的节点上执行。如果某个数据集依赖某一份词典文件，那么所有相关节点都需要看到同一份文件，这会带来多个实际问题：

• 文件分发困难：需要确保每个查询节点、数据节点或相关组件上都存在完全一致的词典文件

• 路径容易不一致：某个节点上的路径是/data/dicts/domain.txt，另一个节点可能不存在该目录结构

• 扩缩容引入新节点：新节点启动后，如果没有提前配置好词典文件，就无法正确处理依赖该词典的数据集

• 容器和本地盘不稳定：重启、迁移、镜像更新、本地目录清理等操作，都可能导致词典文件丢失

• 生命周期不可控：如果某个数据集已经依赖某份词典，人工删除或替换本地文件可能导致线上搜索行为发生变化，但系统本身无法感知这种依赖关系

• 权限和审计困难：无法清晰管理谁可以添加、删除词典，哪些数据集正在使用该词典，仅靠手工拷贝文件无法解决这些问题

也就是说，本地文件模式只适合单机或共享磁盘场景，在普通的分布式部署环境中，它并不是理想的词典分发方式。

（三）分布式环境下的集群级文件管理：File Resource

为了从根本上解决分布式环境下的词典管理问题，检索系统引入了file resource的概念。这一机制并非专为分词器或词典设计，而是用于管理外部文件的通用方案。

File resource可以理解为检索系统识别的一份外部文件：文件本身存储在对象存储中，系统会保存它的资源名、存储路径和元数据，并负责将文件同步或下载到需要使用它的节点上。

这种方式带来的最大变化是，配置不再直接依赖某台机器上的本地路径，而是引用一个由系统统一管理的资源。文件内容本身可以是词典，也可以是后续其他需要集群统一管理的文件；file resource关注的是“这份文件如何被系统识别、分发和保护”。例如，我们可以通过以下方式声明一个file resource：

resource_name = shared_text_assets
file_name = resource.txt

而不再需要指定每个节点上的具体本地路径。

将文件注册为file resource后，系统可以管理这份文件的元数据、分发、缓存和生命周期。节点可以在需要时自动同步或下载文件；创建数据集时，系统可以验证资源是否存在，并记录数据集对该资源的引用；当资源正在被数据集使用时，系统可以阻止误删操作。

这正是本地文件模式所缺失的核心能力。

File resource带来的不是新的分词能力，而是一套更可靠的资源管理方式，让集群能够清晰地认识并管理各类资源：

• 文件集中存放在对象存储中，便于统一管理

• 系统通过资源名管理文件，无需依赖具体本地路径

• 节点可以自动同步或按需下载所需文件

• 数据集会记录自己依赖的资源，便于追溯和管理

• 正在被使用的资源无法被误删，保障线上服务稳定

• 资源的添加、删除、查看操作可以纳入权限体系，提升安全性

对于使用该系统的团队来说，这意味着自定义词典、停用词表、同义词表、复合词拆分词表等文件，都可以集中放在对象存储中，通过资源名被数据集引用，并由系统负责将文件分发到需要的节点上。查询、索引构建、数据导入、压缩等流程看到的都是同一份受管理的词典，而不是各个节点上手工维护的本地文件。

更重要的是，file resource也为词典的后续演进留下了空间。词典作为业务资产，必然会不断更新：新产品名会加入，旧术语会下线，同义词关系会调整，停用词也会随着数据变化而更新。未来可以在file resource的基础上，通过修改数据集引用的资源，实现词典版本的平滑替换。

再进一步，file resource本身也可以引入版本管理，让团队更清晰地知道某个数据集正在使用哪一版词典，并支持更安全的灰度发布、回滚操作和审计追踪。

小结

总的来说，词项质量是影响BM25与文本匹配效果的核心关键。通过自定义词典，我们可以让检索系统更精准地识别业务场景中的核心概念，避免分词偏差带来的误召、漏召问题，让检索系统更好地适配业务文本的处理需求。

具体选型时，单机或共享存储场景可以使用本地词典文件，配置简单且高效；当集群需要自主管理文件分发、验证和生命周期时，file resource是更合适的机制，它可以将词典文件升级为集群级资源，让自定义词典在分布式系统中稳定、可控地运行。