版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。一、测试条件先统一语料、查询、参数同一条查询「中文分词粒度对检索的影响」三种切法都把 d5 排在第一但第二名不是同一篇逐字切给出 d4相邻两字切给出 d3。同一批文档、同一个公式、同一句查询只因切词方式不同第二名就换了人。可见中文检索里切词粒度能直接改排序。语料只有 5 篇查询只有 3 条先把边界说清实测语料是 5 篇中文短文档d1–d5每篇一句话、长度接近分别落在向量索引、多路召回、分块粒度、前缀缓存、中文分词五个主题查询是 3 条中文短问句q1「检索召回率怎么提高」、q2「中文分词粒度对检索的影响」、q3「向量索引和内存占用」。句子短、主题不重叠切法带来的排序差异不被长文档噪声掩盖代价是它只能说明这 5 篇文档上的排序不能替真实语料下结论。这条限制第 4 章展开。三种切法的最小单位不一样三种切法不是三种技巧是三种什么算一个词的定义。字符 unigram 把每个汉字当一个词——「检索」切成「检」「索」。字符 bigram 把相邻两字绑成一个单位——「检索」「索召」「召回」都算独立条目。BPE字节对编码按频次把高频片段合并成子词不认汉字边界切出的单位可能正好是一个词也可能跨在词的接缝上。三种定义导向三套不同的倒排表。参数固定成官方默认切法才是唯一变量比排序最怕顺手调了别的参数。这次把 BM25 的权重钉死成 Elasticsearch 官方默认k11.2、b0.75。k1 管词频饱和b 管文档长度归一化这两个值一动名次就跟着动就分不清差异来自切法还是调参。维度取值说明语料5 篇中文短文档d1–d5每篇一句覆盖向量索引、多路召回、分块、前缀缓存、中文分词查询3 条中文短问句q1–q3分别指向召回、中文分词粒度、向量索引与内存切法字符 unigram / 字符 bigram / BPE(cl100k)逐字、相邻两字、按词频合并的子词打分自写 BM25k11.2、b0.75取值与 Elasticsearch 官方默认一致第 4 章对账排序口径取分数最高的前三名不做重排、不做同义词扩展、不加停用词计算环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写未依赖检索框架二、实测结果三种切法的排序对照先给结论三种切法的前三名多数指向同一批文档但名次顺序和分数不是一回事——同一个第一名BPE 下 6.083 分bigram 下 5.172 分算微弱领先还是显著领先取决于切法。 实测环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写这段脚本把三件事写死三种切词函数、一套 BM25 打分、一个只取前三名的排序循环k1 与 b 都取默认值。importmath,collections,tiktoken enctiktoken.get_encoding(cl100k_base)deftok_char1(s):# 字符 unigram逐字return[chforchinsifnotch.isspace()]deftok_char2(s):# 字符 bigram相邻两字t[chforchinsifnotch.isspace()]return[t[i]t[i1]foriinrange(len(t)-1)]deftok_bpe(s):# BPE(cl100k)按子词切return[enc.decode([t])fortinenc.encode(s)]defbm25(query,docs,tokenizer,k11.2,b0.75):toks{d:tokenizer(t)ford,tindocs.items()}Nlen(docs)avgdlsum(len(v)forvintoks.values())/N dfcollections.Counter()forvintoks.values():forwinset(v):df[w]1qttokenizer(query)scores{}ford,vintoks.items():tfcollections.Counter(v)s0.0forwinqt:ifwnotintf:continueidfmath.log(1(N-df[w]0.5)/(df[w]0.5))sidf*tf[w]*(k11)/(tf[w]k1*(1-bb*len(v)/avgdl))scores[d]sreturnscores把 3 条查询分别喂给三种切法各取前三名原样输出如下对照 Elasticsearch 官方默认 BM25 参数k11.2, b0.75 分词方案字符 unigram 检索召回率怎么提高 - d2:5.604 | d5:2.815 | d1:2.065 中文分词粒度对检索的影响 - d5:11.643 | d4:3.754 | d3:3.484 向量索引和内存占用 - d1:9.189 | d5:2.249 | d2:1.389 分词方案字符 bigram 检索召回率怎么提高 - d2:5.172 | d5:1.486 | d1:1.353 中文分词粒度对检索的影响 - d5:8.180 | d3:0.871 | d2:0.859 向量索引和内存占用 - d1:7.468 | d5:0.920 | d2:0.000 分词方案BPE(cl100k) 检索召回率怎么提高 - d2:6.083 | d5:2.943 | d1:2.314 中文分词粒度对检索的影响 - d5:9.037 | d4:3.993 | d3:3.502 向量索引和内存占用 - d1:8.664 | d5:2.588 | d2:1.740同一个问题三种切法给出的前三名把输出摊平成一张对照表查询切法前三名文档:分数q1 检索召回率怎么提高字符 unigramd2:5.604 / d5:2.815 / d1:2.065q1 检索召回率怎么提高字符 bigramd2:5.172 / d5:1.486 / d1:1.353q1 检索召回率怎么提高BPE(cl100k)d2:6.083 / d5:2.943 / d1:2.314q2 中文分词粒度对检索的影响字符 unigramd5:11.643 / d4:3.754 / d3:3.484q2 中文分词粒度对检索的影响字符 bigramd5:8.180 / d3:0.871 / d2:0.859q2 中文分词粒度对检索的影响BPE(cl100k)d5:9.037 / d4:3.993 / d3:3.502q3 向量索引和内存占用字符 unigramd1:9.189 / d5:2.249 / d2:1.389q3 向量索引和内存占用字符 bigramd1:7.468 / d5:0.920 / d2:0.000q3 向量索引和内存占用BPE(cl100k)d1:8.664 / d5:2.588 / d2:1.740q1 和 q3 的三行前三名成员和顺序完全一样只有 q2 这组bigram 把第二名从 d4 换成 d3、第三名从 d3 换成 d2。可见切法会不会改排序在不同查询上答案并不统一。分数整体高度BPE 最高、bigram 最扁BPE 的分普遍最高q1 第一名 6.083、q3 第一名 8.664bigram 最低5.172 和 7.468unigram 居中。这不是 BPE更懂中文它词表最小同一个词被切成更少的单位每个命中的 IDF 权重被放大bigram 把词拆成大量低权重的字对每个命中都很轻分数被摊薄。绝对值没意义有意义的是第一和第二差多少——第 3 章算。一个必须记下的异常bigram 在 q3 上给出 0.000输出里有一行值得单独拎出来q3 在 bigram 下d2 的分数是 0.000——不是排得靠后是一分没拿。原因不难推q3 的字对是「向量」「索引」「内存」这些相邻两字而 d2 讲的是多路召回与重排这些字对一个都没出现倒排表里查不到就只能落 0。unigram 不会这样逐字切法里「内」「存」「向」「量」至少能撞上一两个。三、反直觉的那一半Top1 一致第二三名和分数间距不一致三条查询 × 三种切法共 9 个排序结果Top1 全部一致——这是最干净的一半但第二名的归属有一处分歧、第一名到第二名的间距也分化这是被 Top1 一致掩盖的另一半。只看 Top1 会得出切法无所谓看间距结论相反。 实测环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写同一份脚本继续往下跑输出 Top1 一致性与词表规模 三种分词 Top1 一致性 检索召回率怎么提高 - unigramd2 bigramd2 bped2 一致True 中文分词粒度对检索的影响 - unigramd5 bigramd5 bped5 一致True 向量索引和内存占用 - unigramd1 bigramd1 bped1 一致True 词表规模对比同一批 5 篇文档 3 条查询 字符 unigram 总 token 数188 去重后词表103 字符 bigram 总 token 数180 去重后词表151 BPE(cl100k) 总 token 数224 去重后词表74Top1 一致是真的但它能证明的东西很有限三条查询的 Top1 都是一致True这不是巧合。q2 的查询句几乎就是 d5 的复述关键词密集三种切法都能捞出来q1、q3 同理查询里最重的词几乎原样出现。Top1 一致说明最相关那篇太好认不是排序稳定。把口径放宽到 Top3、Top5分歧就露出来了——这恰是重排模型关心候选列表的区间。次名间距bigram 把第一名拉得更远把第一名分数 − 第二名分数算出来差异立刻现形。查询切法Top1次名次名分数与 Top1 的间距q1 检索召回率怎么提高unigramd2d52.8152.789q1 检索召回率怎么提高bigramd2d51.4863.686q1 检索召回率怎么提高BPEd2d52.9433.140q2 中文分词粒度对检索的影响unigramd5d43.7547.889q2 中文分词粒度对检索的影响bigramd5d30.8717.309q2 中文分词粒度对检索的影响BPEd5d43.9935.044q3 向量索引和内存占用unigramd1d52.2496.940q3 向量索引和内存占用bigramd1d50.9206.548q3 向量索引和内存占用BPEd1d52.5886.076q1 最典型三种切法选出的 Top1、Top2 完全相同但 unigram 下两者只差 2.789 分bigram 下差到 3.686 分。同一份候选列表unigram 说第一名只领先一点点bigram 说第一名断层领先。下游若按分数阈值做候选截断这两种信号会导出不同结果而 Top1 那栏一模一样。q2 的间距最大都在 5 分以上因为它近乎复述查询三种切法都把它和其他文档甩开。词表规模bigram 让倒排条目变多BPE 让它变少再看词表这一侧同一批 5 篇文档 3 条查询字符 unigram总 token 188去重后词表 103字符 bigram总 token 180去重后词表 151BPE(cl100k)总 token 224去重后词表 74。总量和去重量不同向。bigram 的总 token 最少180去重词表却最大151——相邻字对几乎各不相同重复率极低索引条目多而稀疏。BPE 相反总 token 最多224去重词表最小74——高频子词被反复复用。倒排索引的存储和查询开销由去重词表 倒排链表长度决定这三行账已指向不同的成本结构bigram 条目最多BPE 词表最小unigram 适中。四、找独立信源对一遍官方默认参数与 CJK 分词做法自测最容易挨质疑的是你自己写的 BM25凭什么说它和业界一致。这一章就是对账打分参数和中文切法各找一个独立信源核一遍。对账点一BM25 的两个默认参数Elasticsearch 官方《Similarity settings》在 BM25 条目下把两个参数写得很明确k1 Controls non-linear term frequency normalization (saturation). The default value is 1.2.b Controls to what degree document length normalizes tf values. The default value is 0.75.也就是说k1 默认 1.2、b 默认 0.75 是官方默认值。我的自写实现取的正是这两个值见第 2 章bm25(...)所以第 2、3 章的分数和用 ES 跑同一批文档、同一个 BM25同口径。这就是本次交叉验证的核心对账点切法是变量公式不是——公式锁在官方默认上差异才归因得到切法。对账点二中文 bigram 是不是官方做法第二个要核的是相邻两字切有没有官方背书。Elasticsearch 官方《CJK bigram token filter》的定义是Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.它说明这是内置的 CJK 语言分析器能力底层用 Lucene 的 CJKBigramFilter职责就是把 CJK 文本切成 bigram。单字怎么处理官方选项是output_unigrams If false, a CJK character is output in unigram form when it has no adjacent characters. Defaults to false.默认 false 的含义是只有某汉字没有相邻字时才退回按单字输出。也就是说官方默认的中文切法就是 bigramunigram 只是兜底。我把 unigram 全部逐字切当对照比官方默认更激进如实标出它不是官方默认是粒度放到最细的边界对照。按这两点写一份最小分析器设置{settings:{analysis:{filter:{my_cjk_bigram:{type:cjk_bigram,output_unigrams:false}}}}}对账点三BPE 子词切法的出处第三种切法用的是 tiktoken 的 cl100k_base 编码。tiktoken 官方仓库把 BPE 说得很清楚tiktoken is a fast BPE tokeniser for use with OpenAI’s modelsByte pair encoding (BPE) is a way of converting text into tokensIt’s reversible and lossless它明确了两件事这是 BPE按字节对频次合并切词且切分可逆无损。所以本文的 BPE 不是随便找个分词器是官方公开的 BPE 编码拿它切中文相当于用一个面向英文词频的子词方案当第三只对照眼。对账点我的做法独立信源结论BM25 的 k1自写实现取 1.2ES《Similarity settings》「k1 … The default value is 1.2.」与官方默认一致BM25 的 b自写实现取 0.75同上「b … The default value is 0.75.」与官方默认一致相邻两字切字符 bigramES《CJK bigram token filter》「Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.」同一路做法单字兜底我把 unigram 全部逐字切同上output_unigrams 默认 false仅无相邻字时输出单字我比官方默认更激进BPE 子词tiktoken cl100k_basetiktoken 官方仓库fast BPE tokeniserBPE reversible and lossless官方公开编码语料规模5 篇文档 3 条查询——无法外推见下必须说清的限制小语料上的结论不能外推上面所有一致“不一致都建立在 5 篇文档、3 条查询、句长接近的前提上。两个偏置文档短BM25 的长度归一化几乎不起作用查询与目标文档高度重合Top1 才会三种切法全一致。真实语料里文档动辄上千字、长短混杂、查询还带口语这些条件一松Top3 的分歧会比这里大也可能出现 Top1 都不一致。所以本文结论只到在这批小语料上切法改的是间距和次名不是 Top1”要指导生产选型必须换你自己的语料重跑。独立复跑声明本文第 2、3 章的分数全部来自脚本work/exp1011/exp05_bm25.py的一次完整运行输出原样贴出、未做修饰随后照抄命令重跑一遍退出码 0逐行一致。脚本只依赖标准库和 tiktoken可照抄重跑核对。这份资料是什么一份 AI 大模型知识库的在线目录含检索与 RAG 工程化的专题。本文这一章讲怎么拿官方默认参数给自测对账在那里能接着看到倒排索引与向量召回更完整的评测写法。放在资料包里扫码即可获取五、差异来自哪里以及由此得到的选型判据差异不在谁更准在切法同时改了两件事一条查询能命中多少倒排条目以及文档长度归一化的分母。前者决定能不能捞到后者决定捞到后给多高的分两者叠加才出现Top1 一致、间距不一致。三种切法的差异拆到机制这一层unigram 把命中面放到最宽。逐字切后查询里每个字都是一个小索引项文档里出现过其中一个就能加分不相关文档很难被彻底归零q3 里 d2 拿到 1.389 分就是这个原因。后果是次名分数被抬起来第一名和第二名贴得近、间距小。它的词表中等103。bigram 把命中要求变专。相邻两字成词后必须字对同时出现才计分d2 在 q3 上一个字对都没命中分数直接是 0。专的另一面是区分度大命中的被推高、没命中的压到零第一名领先幅度拉大、间距最大代价是去重词表冲到 151倒排条目最多。BPE 让单个 token 变重。按频次合并的子词不认词的边界可能把一个词整块合并、也可能跨接缝切结果是词表最小74、每个 token 的 IDF 更重分数整体被抬高落在 unigram 和 bigram 之间词表最省间距居中。一句话收束切法改变的是命中的门槛和单次命中的权重BM25 的公式没动。门槛越低unigram命中越多、间距越小门槛越高bigram命中越少、间距越大、词表越膨胀。由此得到的选型判据看词表规模 次名间距本次实测最有用的一句判断在小语料上三种切法的 Top1 常常一致但排序稳定性和倒排规模差异很大所以选切法要看词表规模 次名间距不能只看 Top1。落到具体动作上是四条只取 Top1 直接返回三种切法都能用切法不是瓶颈别在这里耗时间。要把 Top5 交给重排模型看次名间距。间距大且稳定bigram 在 q1、q3说明第一名可信、后面可截断间距小unigram说明前几名贴得近截断前要多留候选免得把真答案一起砍掉。索引体积或内存吃紧看去重词表。BPE(74) unigram(103) bigram(151)bigram 省钱的反面是倒排条目最多这三行账搬到大语料只会更极端。要做中文短查询的精确匹配bigram 更合适它会把不相关文档直接归零误召更少代价是可能漏掉换了说法但意思相同的文档。什么时候该停手最后给一条止损线语料只有几十到几百篇时不要在切法上反复调参。小语料上 Top1 的差别本来就会被样本量掩盖调出来的最优切法很可能只是过拟合这几篇文档。先把语料扩到能代表线上分布的量级再拿本文这套口径重跑让数据决定切法。在这之前用官方默认的 bigram 起步就够了——它是官方 CJK 分析器的默认做法最不容易踩空。这份资料是什么一套从环境搭建到 Agent 落地的视频课目录含私有化部署、EmbeddingRAG 与检索评测全流程。本文最后落在看词表规模和次名间距来选切法它的检索模块恰好是按这个顺序讲的。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处本文位置「k1 Controls non-linear term frequency normalization (saturation). The default value is 1.2.」Elasticsearch 官方《Similarity settings》BM25 条目elastic.co/guide/en/elasticsearch/reference/current/index-modules-similarity.html第 4 章「b Controls to what degree document length normalizes tf values. The default value is 0.75.」同上第 4 章「Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.」内置 CJK 语言分析器用 Lucene 的 CJKBigramFilterElasticsearch 官方《CJK bigram token filter》elastic.co/guide/en/elasticsearch/reference/current/analysis-cjk-bigram-tokenfilter.html第 4 章「output_unigrams If false, a CJK character is output in unigram form when it has no adjacent characters. Defaults to false.」同上第 4 章「tiktoken is a fast BPE tokeniser for use with OpenAI’s models」「Byte pair encoding (BPE) is a way of converting text into tokens」「It’s reversible and lossless」tiktoken 官方仓库 github.com/openai/tiktoken第 4 章本次实测5 篇中文文档 3 条查询三种切法 Top1 完全一致但次名与分数间距差异明显去重词表 unigram 103、bigram 151、BPE(cl100k) 74本次实测脚本 work/exp1011/exp05_bm25.pyPython 3.13.12 / macOS / tiktoken 0.14.0自写 BM25k11.2、b0.75第 2、3 章附表 B术语速查表术语人话解释BM25一种把词频、逆文档频率、文档长度揉成一个打分的排序公式检索里最常用的那一档IDF逆文档频率一个词在越多文档里出现它越不值钱权重越低字符 unigram把每个汉字单独当一个词逐字建索引字符 bigram把相邻两个字绑成一个词如「检索」「索引」各算一个索引项BPE字节对编码按语料出现频次把高频片段合并成子词不认汉字词边界倒排索引词 → 出现该词的文档列表这张表词表规模直接决定它的体积CJK bigram token filterElasticsearch 内置的 CJK 分析器滤镜把中日韩文本切成 bigram写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。
版权与内容来源声明本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容均在附表 A 中标注来源引用官方原文保持原样不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式也不对任何收益结果作承诺。转载请注明出处。一、测试条件先统一语料、查询、参数同一条查询「中文分词粒度对检索的影响」三种切法都把 d5 排在第一但第二名不是同一篇逐字切给出 d4相邻两字切给出 d3。同一批文档、同一个公式、同一句查询只因切词方式不同第二名就换了人。可见中文检索里切词粒度能直接改排序。语料只有 5 篇查询只有 3 条先把边界说清实测语料是 5 篇中文短文档d1–d5每篇一句话、长度接近分别落在向量索引、多路召回、分块粒度、前缀缓存、中文分词五个主题查询是 3 条中文短问句q1「检索召回率怎么提高」、q2「中文分词粒度对检索的影响」、q3「向量索引和内存占用」。句子短、主题不重叠切法带来的排序差异不被长文档噪声掩盖代价是它只能说明这 5 篇文档上的排序不能替真实语料下结论。这条限制第 4 章展开。三种切法的最小单位不一样三种切法不是三种技巧是三种什么算一个词的定义。字符 unigram 把每个汉字当一个词——「检索」切成「检」「索」。字符 bigram 把相邻两字绑成一个单位——「检索」「索召」「召回」都算独立条目。BPE字节对编码按频次把高频片段合并成子词不认汉字边界切出的单位可能正好是一个词也可能跨在词的接缝上。三种定义导向三套不同的倒排表。参数固定成官方默认切法才是唯一变量比排序最怕顺手调了别的参数。这次把 BM25 的权重钉死成 Elasticsearch 官方默认k11.2、b0.75。k1 管词频饱和b 管文档长度归一化这两个值一动名次就跟着动就分不清差异来自切法还是调参。维度取值说明语料5 篇中文短文档d1–d5每篇一句覆盖向量索引、多路召回、分块、前缀缓存、中文分词查询3 条中文短问句q1–q3分别指向召回、中文分词粒度、向量索引与内存切法字符 unigram / 字符 bigram / BPE(cl100k)逐字、相邻两字、按词频合并的子词打分自写 BM25k11.2、b0.75取值与 Elasticsearch 官方默认一致第 4 章对账排序口径取分数最高的前三名不做重排、不做同义词扩展、不加停用词计算环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写未依赖检索框架二、实测结果三种切法的排序对照先给结论三种切法的前三名多数指向同一批文档但名次顺序和分数不是一回事——同一个第一名BPE 下 6.083 分bigram 下 5.172 分算微弱领先还是显著领先取决于切法。 实测环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写这段脚本把三件事写死三种切词函数、一套 BM25 打分、一个只取前三名的排序循环k1 与 b 都取默认值。importmath,collections,tiktoken enctiktoken.get_encoding(cl100k_base)deftok_char1(s):# 字符 unigram逐字return[chforchinsifnotch.isspace()]deftok_char2(s):# 字符 bigram相邻两字t[chforchinsifnotch.isspace()]return[t[i]t[i1]foriinrange(len(t)-1)]deftok_bpe(s):# BPE(cl100k)按子词切return[enc.decode([t])fortinenc.encode(s)]defbm25(query,docs,tokenizer,k11.2,b0.75):toks{d:tokenizer(t)ford,tindocs.items()}Nlen(docs)avgdlsum(len(v)forvintoks.values())/N dfcollections.Counter()forvintoks.values():forwinset(v):df[w]1qttokenizer(query)scores{}ford,vintoks.items():tfcollections.Counter(v)s0.0forwinqt:ifwnotintf:continueidfmath.log(1(N-df[w]0.5)/(df[w]0.5))sidf*tf[w]*(k11)/(tf[w]k1*(1-bb*len(v)/avgdl))scores[d]sreturnscores把 3 条查询分别喂给三种切法各取前三名原样输出如下对照 Elasticsearch 官方默认 BM25 参数k11.2, b0.75 分词方案字符 unigram 检索召回率怎么提高 - d2:5.604 | d5:2.815 | d1:2.065 中文分词粒度对检索的影响 - d5:11.643 | d4:3.754 | d3:3.484 向量索引和内存占用 - d1:9.189 | d5:2.249 | d2:1.389 分词方案字符 bigram 检索召回率怎么提高 - d2:5.172 | d5:1.486 | d1:1.353 中文分词粒度对检索的影响 - d5:8.180 | d3:0.871 | d2:0.859 向量索引和内存占用 - d1:7.468 | d5:0.920 | d2:0.000 分词方案BPE(cl100k) 检索召回率怎么提高 - d2:6.083 | d5:2.943 | d1:2.314 中文分词粒度对检索的影响 - d5:9.037 | d4:3.993 | d3:3.502 向量索引和内存占用 - d1:8.664 | d5:2.588 | d2:1.740同一个问题三种切法给出的前三名把输出摊平成一张对照表查询切法前三名文档:分数q1 检索召回率怎么提高字符 unigramd2:5.604 / d5:2.815 / d1:2.065q1 检索召回率怎么提高字符 bigramd2:5.172 / d5:1.486 / d1:1.353q1 检索召回率怎么提高BPE(cl100k)d2:6.083 / d5:2.943 / d1:2.314q2 中文分词粒度对检索的影响字符 unigramd5:11.643 / d4:3.754 / d3:3.484q2 中文分词粒度对检索的影响字符 bigramd5:8.180 / d3:0.871 / d2:0.859q2 中文分词粒度对检索的影响BPE(cl100k)d5:9.037 / d4:3.993 / d3:3.502q3 向量索引和内存占用字符 unigramd1:9.189 / d5:2.249 / d2:1.389q3 向量索引和内存占用字符 bigramd1:7.468 / d5:0.920 / d2:0.000q3 向量索引和内存占用BPE(cl100k)d1:8.664 / d5:2.588 / d2:1.740q1 和 q3 的三行前三名成员和顺序完全一样只有 q2 这组bigram 把第二名从 d4 换成 d3、第三名从 d3 换成 d2。可见切法会不会改排序在不同查询上答案并不统一。分数整体高度BPE 最高、bigram 最扁BPE 的分普遍最高q1 第一名 6.083、q3 第一名 8.664bigram 最低5.172 和 7.468unigram 居中。这不是 BPE更懂中文它词表最小同一个词被切成更少的单位每个命中的 IDF 权重被放大bigram 把词拆成大量低权重的字对每个命中都很轻分数被摊薄。绝对值没意义有意义的是第一和第二差多少——第 3 章算。一个必须记下的异常bigram 在 q3 上给出 0.000输出里有一行值得单独拎出来q3 在 bigram 下d2 的分数是 0.000——不是排得靠后是一分没拿。原因不难推q3 的字对是「向量」「索引」「内存」这些相邻两字而 d2 讲的是多路召回与重排这些字对一个都没出现倒排表里查不到就只能落 0。unigram 不会这样逐字切法里「内」「存」「向」「量」至少能撞上一两个。三、反直觉的那一半Top1 一致第二三名和分数间距不一致三条查询 × 三种切法共 9 个排序结果Top1 全部一致——这是最干净的一半但第二名的归属有一处分歧、第一名到第二名的间距也分化这是被 Top1 一致掩盖的另一半。只看 Top1 会得出切法无所谓看间距结论相反。 实测环境Python 3.13.12 / macOS / tiktoken 0.14.0BM25 为标准库自写同一份脚本继续往下跑输出 Top1 一致性与词表规模 三种分词 Top1 一致性 检索召回率怎么提高 - unigramd2 bigramd2 bped2 一致True 中文分词粒度对检索的影响 - unigramd5 bigramd5 bped5 一致True 向量索引和内存占用 - unigramd1 bigramd1 bped1 一致True 词表规模对比同一批 5 篇文档 3 条查询 字符 unigram 总 token 数188 去重后词表103 字符 bigram 总 token 数180 去重后词表151 BPE(cl100k) 总 token 数224 去重后词表74Top1 一致是真的但它能证明的东西很有限三条查询的 Top1 都是一致True这不是巧合。q2 的查询句几乎就是 d5 的复述关键词密集三种切法都能捞出来q1、q3 同理查询里最重的词几乎原样出现。Top1 一致说明最相关那篇太好认不是排序稳定。把口径放宽到 Top3、Top5分歧就露出来了——这恰是重排模型关心候选列表的区间。次名间距bigram 把第一名拉得更远把第一名分数 − 第二名分数算出来差异立刻现形。查询切法Top1次名次名分数与 Top1 的间距q1 检索召回率怎么提高unigramd2d52.8152.789q1 检索召回率怎么提高bigramd2d51.4863.686q1 检索召回率怎么提高BPEd2d52.9433.140q2 中文分词粒度对检索的影响unigramd5d43.7547.889q2 中文分词粒度对检索的影响bigramd5d30.8717.309q2 中文分词粒度对检索的影响BPEd5d43.9935.044q3 向量索引和内存占用unigramd1d52.2496.940q3 向量索引和内存占用bigramd1d50.9206.548q3 向量索引和内存占用BPEd1d52.5886.076q1 最典型三种切法选出的 Top1、Top2 完全相同但 unigram 下两者只差 2.789 分bigram 下差到 3.686 分。同一份候选列表unigram 说第一名只领先一点点bigram 说第一名断层领先。下游若按分数阈值做候选截断这两种信号会导出不同结果而 Top1 那栏一模一样。q2 的间距最大都在 5 分以上因为它近乎复述查询三种切法都把它和其他文档甩开。词表规模bigram 让倒排条目变多BPE 让它变少再看词表这一侧同一批 5 篇文档 3 条查询字符 unigram总 token 188去重后词表 103字符 bigram总 token 180去重后词表 151BPE(cl100k)总 token 224去重后词表 74。总量和去重量不同向。bigram 的总 token 最少180去重词表却最大151——相邻字对几乎各不相同重复率极低索引条目多而稀疏。BPE 相反总 token 最多224去重词表最小74——高频子词被反复复用。倒排索引的存储和查询开销由去重词表 倒排链表长度决定这三行账已指向不同的成本结构bigram 条目最多BPE 词表最小unigram 适中。四、找独立信源对一遍官方默认参数与 CJK 分词做法自测最容易挨质疑的是你自己写的 BM25凭什么说它和业界一致。这一章就是对账打分参数和中文切法各找一个独立信源核一遍。对账点一BM25 的两个默认参数Elasticsearch 官方《Similarity settings》在 BM25 条目下把两个参数写得很明确k1 Controls non-linear term frequency normalization (saturation). The default value is 1.2.b Controls to what degree document length normalizes tf values. The default value is 0.75.也就是说k1 默认 1.2、b 默认 0.75 是官方默认值。我的自写实现取的正是这两个值见第 2 章bm25(...)所以第 2、3 章的分数和用 ES 跑同一批文档、同一个 BM25同口径。这就是本次交叉验证的核心对账点切法是变量公式不是——公式锁在官方默认上差异才归因得到切法。对账点二中文 bigram 是不是官方做法第二个要核的是相邻两字切有没有官方背书。Elasticsearch 官方《CJK bigram token filter》的定义是Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.它说明这是内置的 CJK 语言分析器能力底层用 Lucene 的 CJKBigramFilter职责就是把 CJK 文本切成 bigram。单字怎么处理官方选项是output_unigrams If false, a CJK character is output in unigram form when it has no adjacent characters. Defaults to false.默认 false 的含义是只有某汉字没有相邻字时才退回按单字输出。也就是说官方默认的中文切法就是 bigramunigram 只是兜底。我把 unigram 全部逐字切当对照比官方默认更激进如实标出它不是官方默认是粒度放到最细的边界对照。按这两点写一份最小分析器设置{settings:{analysis:{filter:{my_cjk_bigram:{type:cjk_bigram,output_unigrams:false}}}}}对账点三BPE 子词切法的出处第三种切法用的是 tiktoken 的 cl100k_base 编码。tiktoken 官方仓库把 BPE 说得很清楚tiktoken is a fast BPE tokeniser for use with OpenAI’s modelsByte pair encoding (BPE) is a way of converting text into tokensIt’s reversible and lossless它明确了两件事这是 BPE按字节对频次合并切词且切分可逆无损。所以本文的 BPE 不是随便找个分词器是官方公开的 BPE 编码拿它切中文相当于用一个面向英文词频的子词方案当第三只对照眼。对账点我的做法独立信源结论BM25 的 k1自写实现取 1.2ES《Similarity settings》「k1 … The default value is 1.2.」与官方默认一致BM25 的 b自写实现取 0.75同上「b … The default value is 0.75.」与官方默认一致相邻两字切字符 bigramES《CJK bigram token filter》「Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.」同一路做法单字兜底我把 unigram 全部逐字切同上output_unigrams 默认 false仅无相邻字时输出单字我比官方默认更激进BPE 子词tiktoken cl100k_basetiktoken 官方仓库fast BPE tokeniserBPE reversible and lossless官方公开编码语料规模5 篇文档 3 条查询——无法外推见下必须说清的限制小语料上的结论不能外推上面所有一致“不一致都建立在 5 篇文档、3 条查询、句长接近的前提上。两个偏置文档短BM25 的长度归一化几乎不起作用查询与目标文档高度重合Top1 才会三种切法全一致。真实语料里文档动辄上千字、长短混杂、查询还带口语这些条件一松Top3 的分歧会比这里大也可能出现 Top1 都不一致。所以本文结论只到在这批小语料上切法改的是间距和次名不是 Top1”要指导生产选型必须换你自己的语料重跑。独立复跑声明本文第 2、3 章的分数全部来自脚本work/exp1011/exp05_bm25.py的一次完整运行输出原样贴出、未做修饰随后照抄命令重跑一遍退出码 0逐行一致。脚本只依赖标准库和 tiktoken可照抄重跑核对。这份资料是什么一份 AI 大模型知识库的在线目录含检索与 RAG 工程化的专题。本文这一章讲怎么拿官方默认参数给自测对账在那里能接着看到倒排索引与向量召回更完整的评测写法。放在资料包里扫码即可获取五、差异来自哪里以及由此得到的选型判据差异不在谁更准在切法同时改了两件事一条查询能命中多少倒排条目以及文档长度归一化的分母。前者决定能不能捞到后者决定捞到后给多高的分两者叠加才出现Top1 一致、间距不一致。三种切法的差异拆到机制这一层unigram 把命中面放到最宽。逐字切后查询里每个字都是一个小索引项文档里出现过其中一个就能加分不相关文档很难被彻底归零q3 里 d2 拿到 1.389 分就是这个原因。后果是次名分数被抬起来第一名和第二名贴得近、间距小。它的词表中等103。bigram 把命中要求变专。相邻两字成词后必须字对同时出现才计分d2 在 q3 上一个字对都没命中分数直接是 0。专的另一面是区分度大命中的被推高、没命中的压到零第一名领先幅度拉大、间距最大代价是去重词表冲到 151倒排条目最多。BPE 让单个 token 变重。按频次合并的子词不认词的边界可能把一个词整块合并、也可能跨接缝切结果是词表最小74、每个 token 的 IDF 更重分数整体被抬高落在 unigram 和 bigram 之间词表最省间距居中。一句话收束切法改变的是命中的门槛和单次命中的权重BM25 的公式没动。门槛越低unigram命中越多、间距越小门槛越高bigram命中越少、间距越大、词表越膨胀。由此得到的选型判据看词表规模 次名间距本次实测最有用的一句判断在小语料上三种切法的 Top1 常常一致但排序稳定性和倒排规模差异很大所以选切法要看词表规模 次名间距不能只看 Top1。落到具体动作上是四条只取 Top1 直接返回三种切法都能用切法不是瓶颈别在这里耗时间。要把 Top5 交给重排模型看次名间距。间距大且稳定bigram 在 q1、q3说明第一名可信、后面可截断间距小unigram说明前几名贴得近截断前要多留候选免得把真答案一起砍掉。索引体积或内存吃紧看去重词表。BPE(74) unigram(103) bigram(151)bigram 省钱的反面是倒排条目最多这三行账搬到大语料只会更极端。要做中文短查询的精确匹配bigram 更合适它会把不相关文档直接归零误召更少代价是可能漏掉换了说法但意思相同的文档。什么时候该停手最后给一条止损线语料只有几十到几百篇时不要在切法上反复调参。小语料上 Top1 的差别本来就会被样本量掩盖调出来的最优切法很可能只是过拟合这几篇文档。先把语料扩到能代表线上分布的量级再拿本文这套口径重跑让数据决定切法。在这之前用官方默认的 bigram 起步就够了——它是官方 CJK 分析器的默认做法最不容易踩空。这份资料是什么一套从环境搭建到 Agent 落地的视频课目录含私有化部署、EmbeddingRAG 与检索评测全流程。本文最后落在看词表规模和次名间距来选切法它的检索模块恰好是按这个顺序讲的。放在资料包里扫码即可获取附表 A本文引用事实与出处对照表事实出处本文位置「k1 Controls non-linear term frequency normalization (saturation). The default value is 1.2.」Elasticsearch 官方《Similarity settings》BM25 条目elastic.co/guide/en/elasticsearch/reference/current/index-modules-similarity.html第 4 章「b Controls to what degree document length normalizes tf values. The default value is 0.75.」同上第 4 章「Forms bigrams out of CJK (Chinese, Japanese, and Korean) tokens.」内置 CJK 语言分析器用 Lucene 的 CJKBigramFilterElasticsearch 官方《CJK bigram token filter》elastic.co/guide/en/elasticsearch/reference/current/analysis-cjk-bigram-tokenfilter.html第 4 章「output_unigrams If false, a CJK character is output in unigram form when it has no adjacent characters. Defaults to false.」同上第 4 章「tiktoken is a fast BPE tokeniser for use with OpenAI’s models」「Byte pair encoding (BPE) is a way of converting text into tokens」「It’s reversible and lossless」tiktoken 官方仓库 github.com/openai/tiktoken第 4 章本次实测5 篇中文文档 3 条查询三种切法 Top1 完全一致但次名与分数间距差异明显去重词表 unigram 103、bigram 151、BPE(cl100k) 74本次实测脚本 work/exp1011/exp05_bm25.pyPython 3.13.12 / macOS / tiktoken 0.14.0自写 BM25k11.2、b0.75第 2、3 章附表 B术语速查表术语人话解释BM25一种把词频、逆文档频率、文档长度揉成一个打分的排序公式检索里最常用的那一档IDF逆文档频率一个词在越多文档里出现它越不值钱权重越低字符 unigram把每个汉字单独当一个词逐字建索引字符 bigram把相邻两个字绑成一个词如「检索」「索引」各算一个索引项BPE字节对编码按语料出现频次把高频片段合并成子词不认汉字词边界倒排索引词 → 出现该词的文档列表这张表词表规模直接决定它的体积CJK bigram token filterElasticsearch 内置的 CJK 分析器滤镜把中日韩文本切成 bigram写在最后这篇用到的资料写这篇文章时把相关的官方文档和源码又翻了一遍顺手也整理了几份配套的东西大模型学习路线图从零基础到能自己动手做 Agent按阶段说明每一步该学什么、哪些可以先跳过《LangChain LangGraph MCP 智能体开发实战》视频课7 个模块从私有化部署、EmbeddingRAG 到 MCPAgent 全流程AI 大模型知识库在线可查Agent Skills 从入门到落地、Claude Skills 完全指南等专题按目录浏览即可640 套 AI 大模型行业报告 经典 PDF 书籍看行业落地案例和别人怎么做的时候用得上大模型零基础到精通教学视频跟着敲一遍比只读文档快得多资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「AI」优先通过。资料按「先路线、再动手、最后查漏」的顺序整理好了建议先看学习路线那一份照着它挑一条适合自己当前基础的路径再往下看。
