分块、索引、检索与重排

• 按文档类型选择分块策略（结构分块、语义分块、代码边界分块）
• 分块与检索粒度的匹配（父子分块）
• 可定位元数据（页码、章节、代码位置）的保留

分块策略必须与文档类型匹配。合同类：按条款结构分块（第几条、第几款），保留条款编号与页眉页脚信息，分块边界必须落在条款边界上，避免把两个独立条款拼进一块；可配合"条款级块 + 合同级摘要"的两级结构。技术文档：按标题层级（章节）分块，保留 heading 路径作为元数据（如"3.2 部署 → 3.2.1 环境要求"），表格与代码示例单独成块或作为块的子结构保留。源代码：按代码边界分块——函数、类、方法为自然单元，块内保留文件路径、函数签名、语言与起始行号，注释与代码同块保证上下文完整；对超长函数用语义子块并保留父块指针。可定位元数据统一记录：doc_id、块序号、来源 URL、原文位置（PDF 页码与坐标、Word 段落号、代码文件行号区间、章节路径），这些元数据直接支撑答案引用跳转与"块级溯源"。分块后还要校验：块是否完整（不切碎语义单元）、块大小分布是否健康、重复块占比是否可控。

分块不是"按固定 token 一刀切"，而是"结构优先、语义兜底"：合同按条款、文档按章节、代码按函数，本质是把文档的天然语义单元当作块边界。答题要同时给出三类文档的具体策略与可定位元数据的清单，体现对"块即证据、块可溯源"的理解。

• 分块粒度与重叠的影响因素（文档类型、查询粒度、模型上下文）
• 上下文完整性与噪声的权衡
• 用查询集评估分块参数的流程

分块粒度与重叠没有通用固定值，因为最优参数取决于四个因素：文档类型（合同条款适合大块、FAQ 适合小块）、查询粒度（细粒度事实查询适合小块、主题级问题适合大块）、Embedding 模型的最大输入长度（块应不超过模型有效长度）、以及检索后的使用方式（直接拼上下文还是配合父子分块）。粒度越大上下文越完整、但噪声越多、向量语义越模糊（长文本平均化）；粒度越小精度越高、但上下文易被切断。重叠的作用是缓解"信息恰好落在块边界"的问题，重叠越大信息冗余与重复召回越多。评估方法：构造带标注的查询集，用不同分块参数（块大小、重叠比例、策略）分别建索引，对比 Recall@K、nDCG 与"答案可支撑率"（答案句能否在召回块中找到证据）；同时统计块级质量指标：被截断语义单元占比（完整性问题）与跨块重复信息占比（噪声问题）。用"查询集 + 标注 + 指标对比"代替拍脑袋选 512/50 等经验值。

本题考察对分块参数"场景依赖"的认知：分块是检索质量的杠杆，但参数必须与文档形态、查询形态、模型能力匹配。答题先讲清楚权衡（完整性 vs 噪声），再给出"查询集驱动"的评估流程，强调用指标而非经验值决策。

• 三类检索方式的典型失败模式
• 查询路由的判定信号与路由策略
• 混合检索与路由的兜底机制

三类检索各有典型失败模式。关键词检索（BM25）：词汇鸿沟失败——用户用"涨薪规定"检索"薪酬调整制度"，词项不重叠即召回失败；同义词与多义词处理差；对长 query 敏感。向量检索：精确匹配失败——型号、ID、专有名词、缩写（如"VPC-204B"）的微小差异导致向量区分度不足，语义相近但事实不同的文档互相污染；对长文档块的平均化使细节丢失；高频实体可能"语义坍缩"。混合检索：融合参数不当导致两路结果互相压制；两路都失败的查询（如拼写错误、指代不清）依然召回为空。查询路由设计：先用查询分析判定信号——是否含精确实体词（型号、ID、人名、条款号）→ 走关键词或混合路；是否为语义描述型 → 走向量路；是否含时间/权限等限定 → 附加元数据过滤；是否为多跳复杂问题 → 走 Agentic 多步检索。路由后仍需混合检索兜底：默认混合（RRF 融合）覆盖大部分查询，路由只做倾向性加权而非二选一，并保留"无结果降级路径"（扩召回、去过滤、模型拒答）。

失败模式分析是检索设计的基础：没有一种检索方式通吃所有查询，关键词死于词汇鸿沟，向量死于精确匹配。答题先枚举三类失败模式，再给出"以查询特征为信号的路由 + 混合兜底 + 降级路径"的设计，体现系统化而非单点优化。

• 查询改写与多查询扩展的延迟构成（LLM 调用次数）
• 收益场景：指代消解、口语化查询、多意图查询
• 成本收益权衡与工程优化（并行、缓存、轻量模型）

延迟构成：每次查询改写是 1 次 LLM 调用（几百 ms 到 1-2s），多查询扩展（MQR）产生 N 个子查询，串行执行则延迟乘以 N，并行执行延迟约等于单次改写 + 最慢子查询，但仍需对 N 路检索结果做融合。总体增量通常为 500ms-3s，占 RAG 端到端延迟的显著比例。是否值得取决于场景：多轮对话（指代消解"它、上面那个"必须改写否则检索必然失败）、口语化/缩写查询、多意图复合查询（一个 query 含多个子主题）、低质量 query 占比较高的线上分布——这些场景改写带来的 Recall 提升显著；而单轮、明确、精确的查询（型号、条款号）改写收益小甚至有害（改写引入歧义）。优化手段：改写与扩展用轻量小模型或复用主模型但限制输出；子查询并行执行并去重；对改写结果做缓存（相同原始 query 命中缓存跳过改写）；仅对"低置信度"查询触发改写（先检索、失败再改写，两段式）；A/B 验证改写开关对端到端指标（召回率、答案忠实度、P95 延迟）的影响后再全量放开。

本题考察"成本-收益"决策：改写/扩展是检索质量的强杠杆，但延迟代价明确。答题应拆解延迟构成、明确收益场景、给出两段式触发与并行/缓存优化，结论是"按需触发而非全量启用"。

• 各环节在检索流水线中的位置与依赖关系
• 顺序对质量的影响（过滤前置 vs 后置、重排候选规模）
• 顺序对延迟的影响（串行与并行、候选集大小）

推荐顺序是"查询理解（改写/扩展）→ 元数据过滤 → 向量/词法召回 → reranker → 精排"，关键约束有三：一是改写必须在召回之前，因为改写的产物（标准查询、子查询、意图标签）决定了检索的输入；若先召回再改写则第一轮召回基于错误查询，产生无用开销。二是元数据过滤尽量前置（pre-filter）以缩小候选集，减少召回与重排的无效计算；但过滤条件必须可靠，权限类过滤强制前置，宽松标签类过滤可后置。三是 reranker 放最后，它只对少量候选做精排（交叉编码器成本高），候选集大小由前置召回决定（如 top-50 进重排、top-5 出结果）。延迟优化：改写与多查询扩展可并行；过滤在向量库内部完成（下推）避免拉取全量；reranker 的候选数按"收益曲线"选择（50→100 召回提升有限但延迟翻倍）。质量影响：顺序错误会导致级联错误——如先过滤后改写，改写生成的子查询可能违反过滤条件；先重排后过滤则把计算花在会被过滤掉的候选上。整体上"理解→过滤→召回→重排"的顺序能保证每步输入正确、每步输出最小化。

检索流水线是串行的依赖链，顺序错误会导致级联质量损失与无效计算。答题应给出标准顺序并逐一解释顺序理由（改写须在召回前、过滤前置缩小候选、重排末位精排），再谈延迟优化手段，体现对流水线整体性的把握。

• 升级期间新旧向量并存的架构（双写、影子索引）
• 回填策略与一致性校验
• 影子检索对比与切换/回退流程

无停机升级分四步。第一步准备：新 Embedding 模型离线推理并产出新向量，但此时不接线上流量。第二步双写：线上写入路径同时写旧向量与新向量（新向量进影子索引），保证升级期间新数据不丢失；双写期间监控两边写入延迟与失败率。第三步回填：对存量文档分批重算向量写入影子索引，用游标控制进度，回填中校验新索引的 doc 数与指纹一致性，回填完成后做"新旧索引抽样相似度对比"（同一文档新旧向量在各自空间的相对邻居一致性）。第四步影子检索与切换：影子索引接收复制流量（同一查询同时跑新旧索引），对比 Recall@K、结果分布与延迟，达到阈值后切换主查询路由到新索引；切换采用灰度——先切 1% 流量、监控异常（零结果率、用户反馈、延迟）再逐步放大，异常时一键回退到旧索引（旧索引保留至稳定期结束）。维度变化时还需处理：查询侧向量维度切换的一致性、旧缓存失效（按模型版本键控缓存）、以及评估集上的回归指标记录。

本题考察生产级索引升级的工程流程：核心是"新旧并存、灰度切换、可回退"。答题按准备→双写→回填→影子检索切换四步展开，强调一致性校验（doc 数、指纹、邻居对比）与灰度/回退机制，避免"全量重建 + 一刀切"的停机式升级。

• 父子分块的结构与检索路径（子块检索、父块返回）
• 对完整性与精确性的平衡机制
• 参数选择与代价（存储、延迟、上下文占用）

父子分块用"小块检索、大块阅读"解决粒度矛盾：子块（如 100-200 token）负责向量化与检索，保证匹配精度；命中子块后返回其父块（如 1000-2000 token 或整个章节/函数）作为上下文输入给生成模型，保证语义完整。平衡机制：子块粒度决定召回精度（过细则主题信息被切碎、过粗则噪声增多），父块大小决定上下文完整性与 token 成本（父块越大上下文越完整但越占窗口、噪声越大）；父块内可只取命中子块附近的局部窗口（如子块前后各 500 token）而非整块，进一步控制成本。工程要点：子块必须记录 parent_id 指针与子块在父块中的偏移；检索阶段可对同一父块的多子块命中做合并去重（避免同一父块重复进入上下文）；父子块分别建立索引时，父块向量可不建或仅建子块索引（检索子块、映射父块）。适用场景：长文档（合同、论文、技术手册）的高精度问答；代价是存储量增加（父子两层向量）与检索后处理逻辑变复杂，需要在评估集上验证收益。

父子分块的本质是"用两次抽象解决粒度矛盾"：小块负责精确召回，大块负责完整上下文，检索与阅读解耦。答题要讲清结构（子块索引、父块返回）、参数权衡（子块精度 vs 父块成本）与工程细节（parent_id、合并去重、局部窗口），体现对长文档 RAG 的深入理解。

• 多语种混合语料的检索挑战（跨语种对齐、代码语义）
• 多语种 Embedding 模型的选型与验证
• 混合语料的工程策略（分语言索引、翻译桥接、查询侧处理）

多语种混合检索的挑战：同一知识库中文档可能中英混合（如英文论文 + 中文解读）、代码与注释混杂；中文 query 需要检索英文文档（跨语种检索），若 Embedding 模型无跨语种对齐能力，语义相似的跨语言文本向量距离大、召回失败；代码的语义在词法空间中与自然语言差异大（变量名、API 名、符号）。是否需要多语种模型：如果语料与查询存在跨语种交互（中文问、英文答），必须选择经多语种语料训练的模型（如支持中英的 multilingual 模型），并在自有评估集中构造"中文 query → 英文文档"的跨语种样本验证互检命中率；若各语言查询与文档完全隔离，可用单语模型分语言建索引。工程策略：查询侧做语言检测并保留原文（不做劣质翻译）；索引侧按语言/文档类型打标签，跨语种查询时可放宽语言过滤；代码检索可对代码块单独走"代码感知"处理（保留标识符、符号结构），必要时对代码用专门模型；评估集必须覆盖中→英、英→中、中英混合 query 与代码 query 四类，防止整体指标掩盖跨语种短板。

多语种检索的核心是"跨语种对齐能力 + 分语料策略"：模型能力决定跨语种召回上限，工程策略（语言标签、过滤、代码特化）决定成本与质量平衡。答题要点出"是否需要多语种模型取决于是否存在跨语种交互"，并用跨语种评估集验证，避免盲目选型。

• 元数据过滤与向量检索的结合方式（pre-filter/post-filter）
• 时间窗、产品线等结构化限定条件的表达
• 过滤与相似度打分的联合排序

结构化限定（时间窗、产品线、语言、文档类型）通过元数据过滤实现：文档在摄取时把这些维度写入标量元数据（published_at、product_line、lang、doc_type），查询时解析用户限定条件为过滤表达式，与向量检索结合执行。结合方式两种：pre-filter——先按过滤条件圈定候选再算向量相似度，限定严格生效，但过滤条件过严时候选太少导致召回下降；post-filter——先向量召回再过滤，召回稳定但过滤后结果可能不足且权限类限定不安全。实现层面：现代向量库（Milvus、Qdrant、pgvector、Elasticsearch）均支持"过滤条件 + 向量查询"的联合查询，过滤字段需建标量索引；过滤下推（filter pushdown）在向量库内部执行避免拉取全量。联合排序：过滤只决定"哪些候选参与"，相似度仍决定排序；若业务要求"限定内按时间加权"，可对分数做加权修正（如新鲜度加成）。查询侧还需处理限定来源：时间窗可能来自用户显式输入、意图解析或对话上下文（"最近三个月"），产品线来自用户画像或参数注入；限定条件应由服务端解析注入，避免拼接注入。

元数据过滤是 RAG 从"通用检索"走向"业务化检索"的关键能力：限定条件的解析（从自然语言到结构化表达式）与执行（pre-filter 下推）是两个核心环节。答题覆盖"摄取写元数据→查询解析限定→过滤与向量联合执行→排序修正"的完整链路。

• 意图分类的维度（检索意图、对话意图、操作意图）
• 意图识别的实现方式（规则、分类模型、LLM）
• 意图到后续动作的路由（检索、闲聊、工具调用）

查询分析在 RAG 链路最前端，把用户输入分类为三类意图。搜索意图：用户想获取知识库信息（"退款政策是什么"），路由到检索+生成主链路。对话意图：寒暄、澄清、追问（"你好""再说一遍"），无需检索，直接对话或要求澄清，避免把无效查询塞进检索。操作意图：用户想执行动作（"帮我改个订单""生成报表"），路由到工具调用/Agent 链路而非知识检索。实现方式：轻量场景用规则+关键词/正则（"帮我""改成"等操作词、问句结构判断）；数据充分时用意图分类模型（小模型快、成本低）；复杂场景用 LLM 做意图分类（带 few-shot 与输出约束，可解释性差但泛化好），常配合"意图 + 槽位（entity）"一起抽取。工程要点：意图识别结果要附加置信度，低置信度走"澄清追问"而非武断路由；识别"搜索 vs 对话"尤其关键——对话类输入进检索会拉低检索命中率与答案质量；搜索意图内部还可细分（精确查询/语义查询/多跳查询）以选择检索路径；所有路由决策写入日志，供评估与迭代。

查询分析是检索链路的"闸门"：不区分意图会把闲聊、操作请求错误地投入知识检索，既浪费成本又破坏体验。答题按"三类意图的定义→识别实现（规则/模型/LLM）→置信度与路由动作"展开，强调低置信度澄清机制。

• rerank 延迟瓶颈与候选集规模的关系
• 前置廉价过滤信号（向量分阈值、关键词、粗排序）
• 前置过滤与 rerank 质量损失的权衡

应该，但必须衡量"过滤收益与召回损失"。Rerank 延迟与候选集大小近似线性：交叉编码器对每对 (query, doc) 做全量编码，候选 100 条时耗时显著，候选 20 条时可降到 100ms 级。前置廉价过滤的目标是把候选集从"宽召回"压缩到"值得重排"的规模，可用信号包括：向量相似度阈值（低于阈值的直接丢弃）、粗排序截断（只保留向量 Top-K）、关键词硬过滤（不含任何查询实体的候选剔除）、去重（语义重复的候选合并）。取舍原则：前置过滤应"宽松"——只去除明显无关或明显重复的候选，宁可多留也不误杀；真正的精排交给 rerank，保证前置过滤的误杀率（被滤掉的相关文档比例）可控（如 <1%），用评估集量化：分别测"宽候选 + 全量重排"与"窄候选 + 小批量重排"的 nDCG 差异，若指标损失小于阈值（如 <0.5%）则压缩可行。此外还可配合：重排结果缓存、只对 top 候选做重排而尾部候选用向量分兜底、以及异步流水线（先返回粗结果、重排完成后替换）。

本题考察"延迟与质量的工程权衡"：重排延迟由候选集规模决定，前置廉价过滤是降延迟的主流手段，但必须防止误杀。答题要点是"过滤宽松化 + 评估集量化误杀率 + 缓存/兜底优化"，避免只谈过滤不谈质量损失。

• 重复召回的检测（向量相似、文本哈希、同文档聚簇）
• 多样性策略（MMR、按文档限流）
• 父子块扩展与上下文组装规则

召回内容重复集中于同一文档时，上下文会被同一信息反复占用，导致覆盖不足。处理分三步。去重：先用文本哈希（MinHash/SimHash）过滤完全重复块，再用向量相似度阈值（如余弦 > 0.95）合并近似重复块，同一文档的连续命中合并为"文档片段"而非多个独立块。多样性：按文档维度限流——单文档最多进入 top-N 个块（如最多 3 块），保证多文档覆盖；更精细可用 MMR（最大边际相关）重排：每次选择"与查询相关且与已选集合最不相似"的结果，在相关性与多样性之间做贪心平衡；也可按来源类型（文档、FAQ、手册）配额保证覆盖。父子块扩展：去重后若需要完整上下文，对保留的子块做父块扩展（返回其父块），但同一父块只扩展一次；扩展后的块仍要按"与查询相关度"重排组装。最后检查组装上下文的信息熵：若 80% 内容来自同一文档且答案涉及多主题，说明召回多样性不足，应回溯扩大召回或调整多样性参数。

重复召回的本质是"召回数量≠信息量"：上下文长度有限，重复与单一来源集中会挤占其他相关证据。答题按"去重（哈希+相似度）→多样性（限流+MMR）→父子扩展（去重扩展）"三步展开，并给出"多文档覆盖率"的检查视角。

• 量化对向量精度的损失机制（SQ/PQ 的信息损失）
• 用同一标注集对比召回指标的方法
• 量化参数的权衡决策（精度 vs 速度/内存）

量化（int8 标量量化 SQ、乘积量化 PQ、二进制/混合量化）会压缩向量精度，召回损失与量化程度正相关，必须量化前后对比测量。正确流程：第一步固定评估集——使用与选型/调优相同的带标注查询集（几百到几千条 query），量化前后完全一致，保证可比性；第二步分别建索引——原精度索引与量化后索引使用相同的分块、Embedding 与检索参数（k、过滤条件），只变化量化配置；第三步对比指标——量化索引与原索引在 Recall@K、MRR、nDCG 上的差异即为量化召回损失（如 Recall@10 从 0.82 降到 0.79，损失 3.7%）；同时记录延迟与内存收益（QPS 提升倍数、内存下降比例），形成"精度-性能"权衡表；第四步验证答案质量——对 RAG 端到端跑部分样例，确认召回损失未传导为答案错误。注意事项：不能只比较 QPS（QPS 提升不代表召回无损）；量化损失与数据分布相关（长尾词、稀疏向量对量化更敏感），需分层统计（按查询类型）；上线前用影子流量对比量化索引与全精度索引的实际结果差异，必要时对高价值查询走全精度索引兜底。

量化的核心问题是"用多少召回损失换多少性能收益"，只有同一标注集下的前后对比才能回答。答题强调"固定评估集 + 分层统计 + 端到端验证"的方法论，并指出只比 QPS 的常见误区。

• 粗筛 k 与精排 k 的职责差异
• 各环节 k 值的经验区间与影响
• 按数据量与查询类型调整 k 的依据

检索通常分两级：粗筛（召回）与精排。粗筛 k（召回数量）的目标是"覆盖足够多的相关文档"：经验区间为 50-200，若数据量小或查询明确可取 20-50；粗筛 k 过小会漏召回（精排再好也救不回），过大则增加重排成本。精排 k（最终进入上下文的结果数）取决于上下文预算与任务：单轮问答通常 3-5 条，需要多证据综合或长文档分析时可到 8-10 条；精排 k 受 LLM 上下文窗口约束，并按"块大小 × k"估算 token 占用。经验公式只能作为起点：一种实用做法是"按召回率曲线定 k"——在评估集上画 Recall@k 曲线，取"召回率增速变缓"的拐点（如 k=80 后召回率不再显著上升，则粗筛取 80）；精排 k 可用"答案支持率"实验确定（k=5 与 k=8 的答案忠实度无差异时取 5）。另需考虑：混合检索时两路各取 k 再融合（融合后候选集为 2k）；数据量大、相似文档多时适当提高 k；多跳检索中每跳的 k 可递减（第一跳宽、后续窄）。

k 值的本质是"覆盖率与成本"的权衡参数：粗筛 k 决定召回上限，精排 k 决定上下文成本。答题要点是分层设置（粗筛 50-200、精排 3-10）、用评估曲线定 k 而非拍脑袋，以及混合检索、多跳检索等场景的调整原则。

• 结果不稳定的来源（索引版本、量化、HNSW 随机性、缓存缺失）
• 证据强度的度量（多路信号、多次采样、引用频度）
• 稳定排序的实现（投票、聚合、确定性规则）

结果不稳定主要来自四类来源：索引版本切换期间新旧索引结果并存、量化后近似检索的随机扰动（HNSW 探索路径随机）、重排模型分值的微小波动、以及缓存未命中导致的计算路径差异。稳定排序的核心是把"单次得分"升级为"证据强度"。实现手段：一是多路信号聚合——把向量分、BM25 分、重排分、元数据信号（时间新鲜度、来源权威度）做加权融合，单一信号的抖动被稀释；二是多次采样投票——同一查询多次检索（不同 ef_search 或重复执行）取出现频次高的结果并加权，类似集成；三是引用频度信号——在多次问答日志中，被答案引用次数多的文档证据强度高，可作排序修正；四是确定性兜底——对分数接近的结果按固定规则打破平局（文档 ID、更新时间、来源优先级），保证相同输入产出相同排序。工程上还要保证：评估与线上使用同一索引版本与参数；关键查询结果做缓存并签名版本号，版本升级时缓存失效而不是静默混用；监控"同查询多次检索的结果重合率"，低于阈值时告警排查索引或参数漂移。

结果不稳定会破坏用户体验与可复现性（同一问题两次回答引用不同文档）。答题先列不稳定来源，再给"证据强度"思路（多路聚合、多次采样、引用频度、确定性打破平局），最后落到版本化缓存与重合率监控。

• 敏感信息遮盖的时机选择（索引前、检索后、生成前）
• 遮盖对检索质量的影响与规避
• 不同敏感等级的分级处理

敏感信息遮盖应分时机、分等级处理。原则是"向量化前脱敏最安全，生成前遮盖最灵活，检索质量优先在索引层保证"。第一层：摄取/索引前——对敏感字段（身份证号、手机号、token、内部账号）做脱敏替换（如保留格式的掩码 138****1234、或替换为占位符），这样敏感原文根本不进入向量空间，检索与日志均无泄漏，但会损失精确匹配能力（掩码后的文本无法被"13812341234"查询精确命中）；为此可对精确查询走"脱敏后规则匹配"的补充路径。第二层：检索后/生成前——检索到的块若含敏感信息，在组装上下文前做遮盖（mask），保证不进入 prompt；若遮盖破坏证据语义（如型号含敏感前缀），可保留"证据检索用原文、上下文展示用遮盖"的双份字段。第三层：输出层——答案展示时的遮盖与权限复核。分级处理：低敏数据（用户名）可轻遮盖；高敏数据（token、密钥）必须索引前脱敏且检索侧强制过滤；日志与链路追踪中的查询文本也要脱敏。关键校验：脱敏后跑评估集确认 Recall 损失在可接受范围（如 <2%），并对"遮盖后无法检索"的高敏查询设计替代检索路径（按脱敏值检索）。

遮盖时机是"安全性与检索质量"的博弈：越早遮盖越安全，但越容易破坏检索信号。答题按"索引前脱敏（保安全）→检索后遮盖（保上下文安全）→输出复核"分层展开，并强调脱敏后召回损失的评估与替代路径，体现分级分类治理。

• 语义分块的原理（嵌入相似度找边界）与实现
• 明显胜出的文档类型及原因
• 语义分块的代价与适用边界

语义分块通过计算相邻句子/段落嵌入的相似度，把"语义断点"（相似度骤降处）作为块边界，块内主题连贯。明显胜出的文档类型：一是散文式长文（论文、书籍章节、深度文章）——固定 token 切分会把段落与主题切开，语义分块让每块对应完整论点；二是多主题混杂文档（含多个独立小节的综合报告、新闻合集）——固定切分把不同主题拼进一块导致向量语义混杂，语义分块按主题聚簇；三是对话/访谈记录——按话题转折分块比按字数分块更符合检索粒度。而固定 token 切分仍占优的场景：结构化文档（合同条款、代码、表格数据）已有明确边界，不需要语义检测；短文本（FAQ、公告）本身即完整单元；以及需要严格控制块大小（成本、延迟）与强可复现性的流水线。语义分块的代价：需要 Embedding 推理（增加摄取成本与延迟）、块大小不可控（长句与列表会导致块大小方差大）、边界质量依赖模型。工程实践常"结构优先 + 语义兜底"：先按标题/段落等结构切分，结构不清晰处用语义边界补全。

语义分块胜出的本质是"块与语义单元对齐"：主题连贯的块检索命中率与上下文质量更高，而固定切分在主题混杂的散文类文档上劣化明显。答题要给出胜出/不占优的两类文档及原因，并点出代价与"结构+语义混合"的实践。

• BM25 的精确词项匹配机制与向量检索的语义匹配差异
• 精确匹配场景向量检索失败的原因
• 二者互补的组合策略

BM25 基于倒排索引做精确词项匹配：查询词必须在文档中字面出现才计分，对型号、ID、专有名词这类"词形即身份"的实体，字面命中就是最强的相关性证据。向量检索失败于精确匹配的原因：一是 Embedding 是语义压缩，两个只有细微差异的字符串（如 VPC-204B 与 VPC-240B）语义向量几乎相同，无法区分，导致错误召回；二是低频/稀有词（新型号、内部编码）在训练语料中出现少，向量表征不稳定；三是长词串被平均化稀释。而 BM25 对这些场景是"精确制导"：一字不差即命中，且 TF-IDF 机制对稀有词赋予高权重。为什么不是替代关系：两者失败的互补——BM25 死于词汇鸿沟（同义改写、语义相关但无词项重叠），向量死于词汇精确（同形不同义、微差实体）；BM25 无语义能力，向量无精确能力。组合策略：混合检索（BM25 + 向量，RRF 融合）让两类信号互补；或查询路由——检测到精确实体词（型号、ID 模式）时优先 BM25 结果，语义描述型查询优先向量结果；生产实践普遍采用"双路召回 + 重排"架构，而不是二选一。

本题考察对检索范式本质的理解：BM25 匹配"词形"，向量匹配"语义"，而精确实体查询的相关性恰恰由"词形完全一致"决定。答题要点是讲清向量对微差字符串区分失败的原因，并论证互补性（词汇鸿沟 vs 精确匹配的双向失效）与组合策略。

• 稀疏检索的原理（学习式词项权重、词项扩展）
• 相比 BM25 的显著提升场景
• 稀疏检索的代价与适用边界

传统 BM25 是静态词频统计，无法处理词汇鸿沟；稀疏检索（SPLADE、BM42）用 Transformer 学习查询与文档的词项权重，并具备"词项扩展"能力——模型会为查询补充语义相关的未出现词项（如查询"涨薪"可扩展出"薪酬、调薪"），从而缓解同义改写导致的召回失败。提升显著的场景：一是同义改写与口语化查询——用户口语表达与文档书面用词不一致时，BM25 召回为空而稀疏检索能命中（如"公积金能取吗"检索"住房公积金提取条件"）；二是跨领域术语与翻译变体——专业术语的多种说法（"深度学习/深层神经网络"）；三是长查询与复杂描述——稀疏模型能为长查询中的关键概念分配权重并扩展；四是短语与实体变体场景。代价：推理成本高于 BM25（需要模型前向计算）、索引更大（稀疏向量需倒排或特殊存储）、延迟略高；对完全精确匹配（型号、ID）与 BM25 差异不大，因为字面命中两者都能做到。工程实践：把稀疏检索作为混合检索的一路（与向量路 RRF 融合），或用于冷启动与低资源场景下的语义补偿。

稀疏检索的本质是"可学习的 BM25 + 词项扩展"：它保留词法匹配的可解释性，又获得语义扩展能力，恰好补上 BM25 的词汇鸿沟短板。答题要对比机制差异、给出提升显著的三类场景（同义改写、术语变体、长查询），并诚实指出其代价与适用边界。