切块 —— 别把答案切成两半
原型上线一周，客服反馈：企业版退款的问题经常答一半。排查发现不是模型的问题，是手册在切块时被拦腰截断，关键的「但是……不适用」落在了另一块里。
切块（chunking）是 RAG 里最不起眼、却最影响上限的一步：检索的最小单位是块。块太小，答案被切碎，每块都缺上下文；块太大，一块里混了好几件事，向量变成「平均意思」，检索变模糊，还多花 token。没有万能尺寸，要在自己的数据上量。
主流切法怎么选 —— 从单层到解耦
| 切法 | 做法 | 代表实现（如 LlamaIndex） | 什么时候用 |
|---|---|---|---|
| 固定长度 | 每 N 个字符/token 一刀，保留前后重叠 | SentenceSplitter | 起步基线；结构混乱的纯文本 |
| 递归（结构感知） | 优先按标题、段落切，超长再按标点、换行切 | MarkdownNodeParser | 绝大多数 Markdown、手册的默认选择 |
| 语义 / 按主题 | 相邻句子 Embedding 差异大处下刀，动态聚类 | SemanticSplitterNodeParser | 长篇叙述、访谈转录；计算慢，需权衡收益 |
| 句子窗口（解耦） | 单句做向量索引，元数据挂载前后 N 句上下文 | SentenceWindowNodeParser | 事实型问答、精准条款；高命中 + 完整语境 |
| 父子层级（解耦） | 多级切块（2048/512/128），小块命中向上合并 | HierarchicalNodeParser | 复杂合同、长篇规章；彻底根治跨段落逻辑割裂 |
进阶深潜现代 RAG 进阶切分全景：句子窗口、父子层级与 Late Chunking 架构图解 ▾
传统切分逼迫我们在「块太大检索不准」与「块太小上下文残缺」之间做两难妥协。以 LlamaIndex、Jina AI 为代表的现代工业界实践，通过解耦检索与生成单元以及颠倒嵌入时序打破了这一死局：
解决痛点：单句做 Embedding 时语义密度最高，不会被段落其他杂质稀释；但大模型答题只看一句往往断章取义。
LlamaIndex 实践：用 SentenceWindowNodeParser(window_size=3) 将单句存入向量库，前后各 3 句存入元数据。检索召回后，后处理器 MetadataReplacementPostProcessor 自动将单句替换成 7 句连续窗口送入提示词。
解决痛点：本页开篇“企业版退款关键限制落在另一块”，正属于跨段落长程依赖，单纯扩大滑动窗口极易爆 token 且引入噪声。
LlamaIndex 实践：用 HierarchicalNodeParser(chunk_sizes=[2048, 512, 128]) 构建多层树。向量库仅存 128 token 的叶子节点。当检索命中同一父节点的多个子块时，AutoMergingRetriever 自动折叠并向上传递完整的 2048 token 大块。
机制颠覆：传统方法是「先切块，再单独计算各块 Embedding」，导致第二块中的“她”、“这项免责声明”与第一块的主语彻底绝缘。Late Chunking 利用现代长上下文 Embedding 模型（如 jina-embeddings-v3），先把整篇文档（如 8192 token）完整输入 Transformer；所有 Token 在多层自注意力机制中完成全局信息交互后，最后才在 Token 输出向量层按切块边界做 Mean Pooling。
核心收益：输出的依然是短小精准的切块向量，但每一个向量都天生浸润了全篇上下文，彻底治愈跨块代词指代丢失，且完全不需要调用大模型写背景摘要的额外开销。
让每一块自己说清「我是谁」
块一旦脱离原文，就失去了「我在哪份文件、哪一节」的信息。「但是已开通超过 5 个席位的账号不适用」单独看，不知道是什么产品的什么政策。解决这个问题的现代方案有两条主流路径：
路径 A · 外部补写语境（Contextual Retrieval）：最便宜的版本是拼上标题路径（上面实验台的开关，不需要模型）；更强的版本是让模型为每块前置写一两句背景说明，这就是 Anthropic 2024 年提出的 Contextual Retrieval，评测显示它把检索失败率降低了约 49%，叠加重排降低约 67%（代价是建库时每块多一次 LLM 调用）。
路径 B · 模型原生全局注意力（Late Chunking）：如上方进阶架构所示，直接使用支持长上下文的嵌入模型整篇编码后再切片 Pooling，零额外 LLM 提示词调用成本，依靠模型内部注意力机制守住上下文。
查看参考答案
块太小像把一页纸剪成碎条，每条都读不懂；块太大像一整章当一张卡片，翻到它也不知道重点在哪。试着选「递归」、块大小 120～200，答案就在同一块里了。
小块：语义不完整、召回碎片化；大块：向量被稀释、噪声多、占用上下文预算。结构感知切分按文档层级优先保持语义单元完整；重叠用来缓冲边界损失但会膨胀索引。块前缀（标题路径或 LLM 生成的背景）同时改善 BM25 与向量两路。
嵌入模型 —— 2026 年怎么选
块切好了，下一步是选「翻译官」：把文字变成向量的嵌入模型。它决定了「意思相近」这件事被量得准不准。
过去两年最大的变化有两个。一是开源追上并超过了不少闭源 API：Qwen3-Embedding-8B 曾在 MTEB 多语言榜上排第一，开源嵌入不再只是「省钱的备选」。二是大模型底座的嵌入更强但更贵：参数量上去，质量涨，延迟和存储成本也跟着涨（2026 年有论文专门讨论这个取舍，见参考资料）。选型的核心就是在质量、语言、长度、成本、部署方式之间找平衡点。
阿里通义，提供 0.6B / 4B / 8B 多种尺寸。8B 曾登顶 MTEB 多语言榜。小尺寸适合自部署控成本，大尺寸追质量。
智源出品，支持 100+ 语言、8192 token 输入，一次前向同时输出稠密、稀疏、多向量（ColBERT 式）三种表示，混合检索可以只用一个模型。
开箱即用、按量计费。text-embedding-3 支持用 dimensions 参数截断维度。Cohere、Voyage、Google 等厂商也有各自的嵌入服务，以官方文档为准。
榜单只能帮你缩小候选范围。榜上第一的模型在你的业务语料上不一定第一：用 50～100 条真实问题自己标注一遍，比读十篇评测更可靠。
选型清单（按顺序问）
- 语言：中文为主的语料，优先看对中文有专门优化或多语言榜靠前的模型。
- 最大输入长度：块比模型上限长，尾部会被悄悄截掉（和重排器的坑同一类）。
- 查询与文档是否需要不同前缀：不少模型要求给查询加指令、给文档加另一种前缀，漏了不报错，只是悄悄变差。
- 能否自部署、许可是否允许商用：数据不能出境或量很大时，自部署才划算。
- 维度与存储：直接决定向量库的内存账（下面的实验和 C 页第 1 章）。
查看参考答案
先问会不会说中文、能读多长的块、要不要特殊的提问格式、能不能放在自己机房里。再算账：1000 万条 × 1024 个数 × 每个数 4 字节，大约 41 GB，光放着就要这么多内存。
语言覆盖、最大 token 长度、查询/文档指令前缀、部署与许可、维度与存储。10⁷ × 1024 × 4 B ≈ 40.96 GB（不含索引与元数据）。榜单分数只作候选筛选，最终以自有标注集的 recall@k 为准。
混合检索与 RRF —— 两份名单怎么合并
A 页已经看到：BM25 和向量各有盲区，必须双路并进。但 BM25 吐出的分数是 14.8，向量吐出的余弦是 0.89，两份完全不同量纲的名单，怎么合才不失真？
直接把两路分数相加绝对行不通：这就像让两位打分风格迥异的评委共同评审一场歌手比赛：
- 评委 A（BM25 · 严苛粗放）：按关键词词频算分。命中生僻错误码可以打出 35 分的高分，普通词只给 1.2 分，分数上不封顶、大起大落；
- 评委 B（向量 · 内敛保守）：按余弦相似度算分，所有候选文档的分数往往全挤在 0.81 到 0.89 之间，差 0.01 都隔着好几个身位。
如果把分数直接相加，BM25 会完全淹没向量；如果做 Min-Max 归一化（缩放到 0～1），只要 BM25 某次只查出一条孤立结果，那一条就会被直接拉到满分 1.0，导致排名极度脆弱。RRF（Reciprocal Rank Fusion，倒数排名融合）的大智慧是：不问评委各自打了多少分，只看在各自眼里排第几名！
如果按「第 1 名 + 第 2 名 = 3 分」排，一旦某篇文档在 BM25 没搜出来（未上榜），它该算第几名？排第 10000 名吗？名单长度不一时，名次相加直接瘫痪。
倒数自然地把「名次」转化为「得分」：第 1 名拿最大分，名次越靠后衰减越快。未上榜的文档排名无穷大，倒数得分为 0，天然包容两份长短不一的名单！
防止极端偏执！若不加 k（k=0），第 1 名得 1.0 分，第 2 名得 0.5 分，第 1 名是第 2 名的整整两倍（一票否决权）。加上 60 后变为 1/61 与 1/62，头部差距被温和抚平，让两路都觉得不错的候选稳健胜出。
BM25 极度偏爱排 第 1 名，但向量模型觉得语义毫无关联，只排到 第 30 名。
RRF 得分 = 1/(60+1) + 1/(60+30) ≈ 0.01639 + 0.01111 = 0.02750结论：虽然在一路夺冠，但在另一路太拉胯，最终综合得分被拉低。
BM25 表现良好排 第 2 名，向量语义也十分贴近排 第 3 名。
RRF 得分 = 1/(60+2) + 1/(60+3) ≈ 0.01613 + 0.01587 = 0.03200结论：得分高于文档 A！“宁选两个人都觉得挺好的，不要选一个狂热、另一个鄙视的”。
E2001 磁盘满了：BM25 只有一条结果，min-max 归一化会把它直接拉到满分 1.0，而 RRF 仍只给它「第 1 名」该得的 1/(k+1)。再拖动 k：k 越小，头部名次差距越大，k 越大，各名次越接近。工程总结：公式写为 score(d) = Σ wᵢ / (k + rankᵢ(d))。k=60 来自 RRF 原论文（Cormack 等，2009 SIGIR），十几年来已是各类混合检索与向量库的事实标准；除非你有大量标注数据专门拟合，否则保持默认 60 即可。权重 wᵢ 则根据场景调节：代码、型号等专有名词多的场景，适当调大 BM25 权重；口语化和长意图场景，调大向量权重。
查看参考答案
两个评委打分尺度不同，一个满分 100、一个满分 5，直接加分就不公平。RRF 只问「你在每个评委那儿排第几」，排第 1 的拿 1/(60+1)，排第 3 的拿 1/(60+3)，加起来。两个评委都喜欢的，一定在前面。
score(d) = Σᵢ wᵢ / (k + rankᵢ(d))。例：某文档在 BM25 第 1、向量第 3，k=60：1/61 + 1/63 ≈ 0.0323。只依赖名次，因此不需要校准不同检索器的分数分布，对离群分数、单条结果都稳健。
重排 —— 先广撒网，再精挑细选
混合检索把候选召回到 top-50，但前几名的顺序仍然粗糙：向量只用「一个点」代表整块文字，细节被压没了。重排（rerank）是第二道工序，用更贵但更准的模型，只对这 50 条重新打分。
为什么不一开始就用这个准的模型？因为它要把问题和每个候选放在一起读，没法提前算好、没法建索引，对一千万条逐条读一遍不现实。所以才分两段：第一段便宜、广泛、追求别漏（召回），第二段昂贵、小范围、追求排准（精排）。
候选集被粗筛缩小到了 50 条，接下来的工程抉择是：模型到底以什么方式给这 50 条重新排座次？是一对一单挑精读？还是轻量比对？还是打包在一起集体比选？工业界在「极致精度（深度交互）」与「计算成本（延迟与算力）」的持续博弈中，演化出了三大主流技术流派：
重排的三大技术流派：在「精度」与「速度」间走出的三条路
考官把「问题 + 候选文档」印在同一张卷子上，从头到尾一字一句连着读，模型内部注意力全开。最准，连微小的“不适用”、“除非”等否定词也能敏锐识别；但计算最耗时，对 50 条候选要跑 50 次完整模型推理。
文档入库时，提前给文档里的每个词各算一个向量离线存好；查询时，只对问题的词做轻量配对求和（MaxSim）。速度极快且文档可提前预计算，但词级向量会让存储开销翻倍。
前两派都是盲人摸象式的一对一单挑打分；列表式则是直接把 20 篇候选打包成一张大清单塞给模型，一眼通览直接排出 1 到 20 名。具备全局比较视野，能识别重复和互补信息；现代专用列表重排器单次前向直接出整批结果，吞吐暴增。
2026 现代主流重排模型地图
搞清了这三大流派的思想，在实际工程落地中，我们通常不需要自己从头训练，而是直接选成熟的开源模型或托管 API。当前工业界的主流选择高度分化：
| 模型家族 | 代表版本 | 类型与部署 | 特点与核心场景 |
|---|---|---|---|
| BGE-Reranker 系列 | bge-reranker-v2-m3 / large | 开源（自部署） | 开源中流砥柱。北京智源出品，多语言极强，配对 BGE-M3 嵌入模型，是企业自建/私有化知识库的首选。 |
| Cohere Rerank 系列 | rerank-v3.5 | 商业 API（全托管） | 企业级精度标杆。支持 100+ 语言与 4K+ 上下文，免 GPU 运维，对各类复杂语料调校极深，商业 RAG 的开箱首选。 |
| Jina Reranker 系列 | jina-reranker-v3 | 开源 / API | 超长窗口与列表式极速。支持 8K 甚至 32K token，利用列表式（Listwise）并行打分，大候选集重排吞吐极高。 |
| Qwen-Reranker 系列 | qwen3-reranker (4B/8B) | 开源（自部署） | 大模型底座推理。阿里通义开源，由大语言模型底座深度蒸馏，对深层逻辑推断、中文行话、长因果链的重排能力极强。 |
块长度 + 问题长度 ≤ 重排器最大输入窗口。查看参考答案
像招聘：先用简历粗筛从一万人里捞出五十人（便宜快速、宁多勿漏），再一个个面试排出前五（昂贵精细，但只面五十人）。交叉编码器是逐个单面，打分最准；列表式是把几十个人拉进一个群里同台比选，速度更快、还能识别重复与互补。
召回阶段用可预计算的向量/倒排索引，复杂度与语料规模次线性；精排阶段对 top-N 做高算力消耗的重打分。Cross-Encoder 具备全注意力交互精度最高但 O(N) 较慢；Listwise 一次前向评估候选集合吞吐更高且具备全局上下文感知。
改写问题 —— 用户的问法往往不是最好的检索词
用户一句话里塞了三件事，或者问得很口语。直接拿原句去检索，向量会被「平均」成一个模糊的方向。第三条路是先让模型把问题改写成更好检索的样子。
| 技术 | 做法 | 适合 | 代价 |
|---|---|---|---|
| 问题分解 | 把复合问题拆成几个子问题，各自检索再融合 | 多意图、多跳问题 | 多一次模型调用 + 多次检索 |
| 多查询（multi-query） | 让模型把同一问题改写成 3～5 种问法，各自检索再 RRF | 用户措辞和文档措辞差距大 | 检索次数 ×N，延迟上升 |
| HyDE | 先让模型写一个「假想答案」，用它去检索（答案和文档更像） | 问题很短、很抽象 | 模型可能写错，污染检索方向 |
| 退一步（step-back） | 先问一个更宽泛的问题检索背景知识，再回答具体问题 | 问题过于具体、需要原理背景 | 多一轮检索，上下文变长 |
2026 年的做法是把它们折进「自适应」或 Agent 流程：先判断问题复杂度，简单问题直接检索，复杂问题才拆分或多轮检索。改写没有免费午餐：每多一次模型调用就多一份延迟和成本，先从 multi-query + RRF 这个最稳的组合起步。
查看参考答案
一句话里有三个诉求，检索时只会朝「平均方向」找，通常只找回其中一件事。拆开问、各自找、再合并，三件事都能找到。代价是多问几次，更慢更贵。
复合查询的嵌入是各意图的混合，近邻只覆盖主导主题。问题分解 / multi-query 增加查询多样性换取召回；HyDE 用假想答案缩小「问句 vs 陈述句」的分布差；step-back 引入背景。均以额外 LLM 调用与检索延迟为代价。
评估 —— 用数字回答「到底准不准」
调了切块、换了模型、加了重排，直觉上感觉“好像变灵光了”。但「感觉」不能作为发布上线的依据，也没法在版本迭代中防止退步。RAG 系统的调优，本质上是“以评促改”——必须把质量拆解成客观可衡量的数字。
排查铁律：先检索，后生成
当用户抱怨“系统答得不对”时，很多团队的第一反应往往是“换个更大更贵的模型”。这是最常见的误区。RAG 系统有两个完全独立的失败环节：
- 检索死穴（巧妇难为无米之炊）：包含正确答案的切块压根没被检索出来，或者被挤在 top-k 之外。大模型连参考资料的影子都没看见，只能凭空猜测。
- 生成死穴（视而不见与信口雌黄）：关键材料已经送进了 Prompt，但大模型产生了幻觉（无中生有）、漏看了限制条件，或者答非所问。
排查铁律：先查检索层，再查生成层。若正确的切块根本没进 top-k，生成模型再强也无力回天。因此，工业界将评估明确划分为两大部分：检索层硬指标（基于确定性标注，靠数学公式硬算）与生成层软指标（基于自然语言理解，由大模型当裁判打分）。
检索层的四大硬指标：从及格线到黄金 C 位
检索层评估的是「该找的材料有没有找齐、排得靠不靠前」。在建立好测试题库（标注了每个问题对应的标准参考切块）后，通过以下四个数学指标衡量：
通俗理解：知识库里藏着 4 处关键凭证，前 5 条捞出了 3 处，Recall@5 = 75%。它决定了系统的能力天花板。粗排/召回阶段通常盯紧 Recall@50，宁可多带点杂质，绝不能把答案漏掉。
通俗理解：抓出 5 条材料供模型阅读，其中只有 2 条有用，Precision@5 = 40%。虽然模型上下文越来越大，但杂质过多会引发“迷失在中间”（Lost in the Middle）并严重浪费 token。精排后通常盯紧 Precision@5。
通俗理解：第 1 个真答案排第 1 名得 1 分，排第 2 名得 0.5 分，排第 10 名只有 0.1 分。大模型极度容易被前几条材料“先入为主”带偏。MRR 对单意图问答系统非常敏感，要求排头兵必须过硬。
通俗理解：经典搜索引擎与精排推荐的核心标杆。命中相关文档有奖励，但排在第 1 名的奖励远高于第 5 名。它衡量整个 top-K 排序质量是否兼具“命中率”与“高价值前置”。
生成层与端到端指标：LLM-as-a-Judge 与 RAG 三元组
检索材料可以靠数学硬算，但最终大模型生成的自然语言回答千变万化，既无法做文本绝对匹配，也无法靠关键词统计。2026 年的主流解法是 LLM-as-a-Judge（大模型充当裁判）：使用能力更强、更中立的高阶大模型，输入严格的评分量表（Rubric）与思考链（CoT），对生成质量打分。
业界最经典的评估基石是 RAG 三元组（RAG Triad），它紧扣用户提问（Query）、检索上下文（Context）、模型回答（Answer）三者之间的闭环关系：
核心审问：“回答里的每一句话，能否在检索出来的材料里找到白纸黑字的证据？”
裁判模型把回答拆分成单句陈述，逐句去参考材料里“核对证据”。哪怕回答再通顺，只要资料里没写，就判定为捏造扣分。这是防止法律合规翻车的红线底线。
核心审问：“回答有没有正面回应提问者的真实诉求？有没有避重就轻打太极？”
裁判模型根据生成的回答，反推“提问者可能问了什么”，比对反推问题与原问题的语义重合度。如果用户问“如何退款”，回答却滔滔不绝讲公司历史，即便完全忠于材料也是低分。
核心审问：“检索器抓回来的这堆材料，对解答用户的问题到底有没有帮助？”
排查检索层是否存在严重的“题文无关”。如果检索器拉回来的切片全是噪音，即使模型硬着头皮答对，也是低分。它连接了检索层与生成层，检验上下文有效利用率。
除了三元组，2026 年企业落地普遍结合 G-Eval（基于思维链的业务自定义评分）：针对具体业务量身定制评分量表，例如：客服回答的专业语气与同理心、免责声明是否齐备、敏感保密信息审查、面对无答案问题是否安全拒答，由裁判模型输出 1～5 分及详细的采分理由。
2026 业界评估版图：主流开源框架与商业 SaaS
2026 年的工程界已经彻底告别了“手工在测试页面里随便搜两句”的作坊阶段，形成了从算法实验、本地 CI 门禁到线上生产监控的成熟工具链：
| 工具 / 平台 | 阵营与形态 | 核心杀手锏与特色 | 适用阶段与场景 |
|---|---|---|---|
| DeepEval Confident AI |
开源 Python 单元测试流 |
Pytest 原生集成。像写普通单元测试一样写 RAG 评测（assert_test）；内置 14+ 种指标（G-Eval、幻觉检测、RAG 三元组），原生支持 GitHub Actions 门禁。 |
研发本地流水线与 CI/CD 门禁首选。最契合以代码库和 PR 为核心的工程团队。 |
| Ragas Exploding Gradients |
开源 Python 算法与题库合成 |
学术鼻祖与合成测试集。首创 RAG Triad 指标；核心杀手锏是 Testset Generator，可用 Multi-Agent 针对文档库全自动合成简单事实、多跳推理、边界例外测试题。 | 算法调优与冷启动评测。项目初期缺乏人工标注集时，自动合成黄金题库。 |
| Arize Phoenix / Langfuse | 开源可私有化 OTel 链路追踪 |
全链路 Trace 观测与影子评估。基于 OpenTelemetry 记录从 Embedding、向量库召回、Prompt 拼装到 LLM 回复的完整链路；支持离线评测与线上采样异步评估。 | 生产环境全链路监控与合规场景。重视数据隐私、需要私有化自部署的企业首选。 |
| LangSmith / Galileo | 商业 SaaS 企业全生命周期 |
开箱即用的大一统协同平台。支持产品/运营团队无代码协作标注、Prompt 线上 A/B 测试、在线安全护栏（Guardrails）与多维度监控看板。 | 中大型企业与跨团队协作。产研运需要协同质检、预算充裕且希望快速交付投产。 |
工业级 RAG 评估工程落地三步法
许多团队之所以 RAG“越改越心虚、改了这个崩了那个”，根本原因是没有将评估固化为研发流水线。2026 年工业级团队的标准落地作业流分为三步：
拒绝凭感觉随机抽问。利用 Ragas / DeepEval 工具，从企业文档库中自动合成 100～200 道测试题，覆盖「直接事实题」、「跨文档多跳推理题」、「边界例外题」以及「库中无答案的诱导题」。由业务专家花费半天时间精审校对，固化为系统专属的黄金测试基准集。
将评测脚本接入 GitHub Actions / GitLab CI。任何人修改了切块大小、更换了 Embedding 维度、调节了重排阈值，提交 PR 时自动跑黄金集。若 Recall@5 环比下降超过 2%，或 Faithfulness < 90%，CI 亮红灯直接拦截合并。杜绝暗中退步与负向优化。
生产环境接入 Langfuse / Phoenix，对线上真实流量进行 5%～10% 的影子异步抽检，后台由轻量裁判模型打分。用户在线上的每一次“点踩、重问、放弃复制”，系统自动将该 Session 打标归档至“线上错题本”，作为下一期测试集补充，实现自进化闭环。
查看参考答案
检索指标看「材料找得全不全、排得前不前」（数学硬算）；生成指标看「有没有乱编幻觉、答得跑不跑题」（大模型当裁判）。出问题先查检索再查生成。上线前用黄金题库在 CI 跑自动化测试，不达标不准发布。
检索层依赖黄金标注集硬算 Recall@k（覆盖率）与 nDCG@k（排序增益）；生成层用 LLM-as-a-Judge 评估 RAG Triad（Faithfulness 忠实度防幻觉、Answer Relevance 切题度、Context Precision 纯度）。工程化通过 Ragas/DeepEval 合成测试集并在 CI/CD 中设立回归门禁，结合 Langfuse 进行线上链路追踪与抽检。
终极测验 · 5 题验收
答对 4 题以上，才算把「检索质量」这一页带走。
参考资料 · References
博客类来源标为「观点」，具体数字（榜单、上限、成本）会随版本变化，请以官方文档为准。
原理出处
- Anthropic, Introducing Contextual Retrieval（2024，块前缀 + 混合检索 + 重排的失败率数据）· anthropic.com/news/contextual-retrieval
- Cormack, Clarke & Büttcher, Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods（SIGIR 2009，RRF 与 k=60）
- Khattab & Zaharia, ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT（2020）· arxiv.org/abs/2004.12832
- Es et al., RAGAS: Automated Evaluation of Retrieval Augmented Generation（2023）· arxiv.org/abs/2309.15217
2026 年的资料
- RAG Best Practices 2026: Chunking, Reranking, Hybrid Search（观点，含重排器截断上限）· callmissed.com
- 8 Embedding Models Compared for Production RAG [2026 Benchmark]（观点）· tensoria.fr
- Best Open-Source Embedding and Reranker Models 2026（观点，Qwen3-Embedding / BGE-M3）· builderai.tools
- The Embedder's Dilemma: LLMs Are Better, but at What Cost?（2026，论文）· arxiv.org/pdf/2608.12875
- Reranking for RAG Explained: Cross-Encoders & More (2026) · dataaspirant.com
- Hybrid Search with Reranking · Qdrant 文档 · qdrant.tech
- RAG Evaluation: Metrics, Tools, and the Context Gap (2026)（第五维度：上下文可信度，观点）· atlan.com
- DeepEval: The Open-Source LLM Evaluation Framework（Pytest 集成与生产 CI/CD 门禁）· confident-ai/deepeval
本页 BM25 为标准公式（k1=1.2，b=0.75）；实验台里的「向量」为教学玩具模型，MaxSim 矩阵为示意值。