RAG 架构与数据治理

• 变更事件如何从源系统传播到索引（CDC、消息队列）
• 索引层的最终一致性保证机制（版本号、墓碑、双写）
• 回滚与版本管理策略

变更传播通常采用事件驱动架构：源系统（CMS、Wiki、数据库）产生变更事件后，通过 CDC（变更数据捕获）或消息队列（如 Kafka）通知索引服务，索引服务对变更文档执行重新解析、分块、Embedding，写入新向量并同步更新标量元数据。为保证最终一致性，需要引入"版本号 + 墓碑（tombstone）"机制：每个文档持有单调递增的版本号，新版本写入时覆盖旧版本，检索侧只返回最新版本；删除操作不物理删除向量，而是打删除墓碑标记，检索时过滤掉墓碑文档，从而避免删除传播失败导致的残留召回。为避免大规模回填引发索引震荡，可采用"双写 + 影子索引"：新内容先写入影子索引并与旧索引并行验证，确认无误后切换主索引。回滚依赖按版本构建的索引快照，一旦新版本出现质量问题，可整体回退到上一版本并重放事件流。权限变化同样作为一等事件传播：更新文档在索引中的 ACL 元数据，检索阶段按 ACL 实时过滤，保证删除与降权即时生效。

本题的核心难点是"上游变更与下游索引的非原子性"：文档系统与向量索引是两套独立存储，无法保证强一致，只能通过事件队列、版本号、墓碑与快照在业务可容忍的延迟内收敛到最终一致。答题时应先讲清传播链路（事件驱动 + 队列削峰），再讲一致性机制（版本号与墓碑），最后落到可回滚性（双写 + 快照切换），体现生产级 RAG 数据治理的完整闭环。

• 用自有 query 集与语料构建评估集而非盲信公开榜单
• 多语种、长文本、领域术语三类场景的专项指标
• 检索指标与工程指标（维度、延迟、成本）的综合权衡

Embedding 选型必须基于自有任务指标，因为公开榜单（如 MTEB）的任务分布、语言构成与语料领域往往与真实业务不符。评估的第一步是从生产查询日志抽样构造 query 集，配以人工或半自动标注的相关文档集，度量 Recall@K、MRR、nDCG 等检索指标。多语种场景要评估跨语种检索（中文 query 检索英文文档）的对齐能力，观察混合语言语料下的双语互检得分；长文本场景要对比模型的最大输入长度与"长文本截断后信息损失"的影响，必要时配合分块长度做联合调优；领域术语场景要构造包含专业术语、缩写、型号的 query，验证模型对领域语义的区分度，必要时在领域语料上做继续预训练或微调。此外还需评估向量维度对存储与延迟的影响、吞吐量与批处理成本、以及模型更新维护的便利性。

选型错误的根源是"用公开榜单替代自有评测"：MTEB 第一不一定适合企业任务，必须用自有 query 集与语料做端到端对比。答题思路是先搭评估集，再按多语种、长文本、领域术语三个维度设计专项指标，最后叠加维度、延迟、成本等工程指标，形成完整的选型矩阵。

• 按业务时效性分级设定端到端可见性 SLA
• 延迟链路拆解（摄取、分块、Embedding、写入、刷新）
• 数据新鲜度标记、水位监控与告警策略

端到端 SLA 应分数据等级设定：紧急/实时数据（如最新公告、交易信息）要求分钟级甚至秒级可见，可走"增量摄取 + 增量索引 + 准实时刷新"链路；普通知识库数据可接受小时级延迟，采用批量管道定时同步；归档类数据则允许 T+1。设定 SLA 前要先拆解延迟构成：源系统导出耗时、解析与分块耗时、Embedding 推理耗时、向量库写入与索引段合并（segment merge）耗时、以及检索端缓存 TTL。对过旧数据，应在文档元数据中记录抓取时间与更新时间，建立"数据新鲜度"指标：超过新鲜度阈值的文档在检索结果中降权或标记"过时"，并在管理看板上以水位图展示各来源的过期文档占比，超过阈值触发告警（如过期文档比例 > 5%），同时驱动增量重抓流程。

SLA 的设定本质是"业务时效性需求与管道成本"的权衡：不可能所有数据都实时可见，应分级承诺并逐级拆解延迟构成。回答的关键是给出"分级 SLA + 延迟链路拆解 + 新鲜度标记与告警"三位一体的治理框架，体现对 RAG 数据管道可观测性的理解。

• 权限模型的三层粒度：租户、文档、字段
• 摄取阶段与检索阶段的权限对齐机制
• 权限错误导致越权检索的风险与校验方法

RAG 权限模型通常分三层设计：租户隔离（collection/partition 级）、文档级 ACL（每个文档携带允许访问的用户/角色/组列表）、字段级遮盖（敏感字段如手机号、身份证在分块或生成前脱敏）。关键原则是"权限在检索前过滤、在生成前再校验"：摄取阶段把 ACL 解析为可过滤的标量元数据随向量一起入库，检索阶段在向量查询时附加 ACL 过滤条件（pre-filter），保证不被授权的文档根本不进入候选集；字段级遮盖在分块与 Embedding 阶段完成，避免敏感字段进入向量空间；生成阶段仍要执行答案级 ACL 复核，防止重排或上下文组装引入越权内容。三个租户之间通过 partition 或 namespace 物理隔离，配合检索时强制携带 tenant_id 条件。验证手段包括权限越权测试集：为不同角色构造"不应检索到"的断言，纳入 CI 回归。

本题考察的是"权限模型与检索链路如何同构"：仅靠生成阶段裁剪答案无法防止越权召回，必须在检索阶段用 ACL 元数据过滤。答题框架是三层粒度（租户、文档、字段）+ 两阶段对齐（摄取写 ACL、检索过滤 + 生成复核）+ 越权测试验证，形成闭环。

• 摄取层的租户标识与隔离（分区、命名空间）
• 检索层的强制过滤与查询参数化
• 缓存层与 Embedding 层的泄漏风险及防护

多租户隔离必须在每一层显式执行，任何一层遗漏都可能泄漏。摄取层：为每个租户建立独立的 partition/collection 或 namespace，向量与标量元数据均携带 tenant_id 字段，写入时校验数据归属与租户标识一致。索引层：租户内索引与共享索引并存时，用分区键约束查询范围，避免跨分区扫描。检索层：查询构造器强制注入当前租户的过滤条件（tenant_id 恒等条件），禁止把过滤条件交由模型或用户输入决定，防止提示注入篡改过滤；使用参数化查询而非字符串拼接。缓存层：LLM 响应缓存、Embedding 缓存与检索缓存都必须以 (tenant_id, query) 为键，且缓存命中时校验租户标识，防止租户 A 命中租户 B 的缓存；共享向量库的集合前缀隔离与 ACL 元数据双保险。最后用跨租户越权测试集持续回归：为租户 A 的查询断言绝不出租户 B 的文档。

跨租户泄漏往往是"某层忘记带租户条件"导致的：常见漏洞点包括缓存键未含 tenant_id、检索过滤器由 LLM 生成、共享索引未分区。答题时应逐层列举（摄取、索引、检索、缓存）并在检索与缓存两层强调强制注入与参数化，最后落到越权测试集验证，形成完整防护体系。

• 摘要/抽取导致的细节丢失类型（数字、专名、时序、表格结构）
• 稀疏检索（BM25/SPLADE）对精确关键词的补偿价值
• 双路召回融合（RRF）与路由策略

对长文档先做摘要或抽取再向量化，会丢失三类细节：一是精确信息，如型号、ID、金额、日期等数字与专有名词在摘要中被泛化；二是结构信息，如表格行列关系、代码缩进层级在抽取后扁平化；三是长尾细节，如低频术语与罕见事实被压缩掉。这些丢失对"精确匹配型"查询（查型号、查条款编号）影响最大。补偿方案是稀疏-稠密双路召回：稠密向量路负责语义相似召回，稀疏路（BM25、SPLADE、BM42）保留原始词的精确匹配能力，两路结果通过 RRF 或加权融合。实施时机判断：当评估集显示精确关键词查询的 Recall@K 显著低于语义查询、或摘要化处理被用于降本但精确查询占比高时，应启动双路召回；同时保留原始文档或父子分块（父块为原文、子块用于检索），让摘要只参与语义召回而精确信号走原文路径。

本题考察对"信息压缩有损性"的认知：摘要化省了成本但丢了精确信号，且这种丢失不可逆。答题要分三类细节展开（精确信息、结构信息、长尾细节），再给出双路召回补偿的机制与适用时机判断，体现"按查询类型选择召回路径"的工程思维。

• 维度与表达能力、检索精度的关系
• 维度对存储成本、内存与检索延迟的影响
• 维度选择与模型、数据集规模的匹配

Embedding 维度决定了向量空间的表达能力与工程成本：维度越高通常能编码更细粒度语义，但存储与内存开销线性增长（每向量字节数 = 维度 × 4 字节 float32，量化后更低），高维空间还存在"维度灾难"——在有限数据上高维向量区分度可能不升反降。选择逻辑如下：首先由模型决定，先选模型再接受其输出维度，而非反向定制；其次看数据规模与语义复杂度，百万级以下的知识库 384-768 维通常够用，覆盖多语种与细粒度领域语义时选择 1024-1536 维；再次考虑量化空间，int8 或 PQ 量化会进一步压缩有效信息，可适当选择更高原始维度以保留量化后的精度；最后考虑部署约束，端侧与低延迟场景优先低维度小模型。选型后必须用自有评估集对比召回指标，并在同等召回下比较内存占用与 P95 延迟。

维度不是越高越好，而是"表达能力与工程成本"的平衡：高维带来更高精度上限，也带来更大的存储、内存与延迟开销，并受数据量制约。答题应建立"模型决定维度、数据规模决定取舍、量化与部署约束做修正、评估集做最终裁决"的决策链，避免拍脑袋选 1536。

• 反馈信号的偏差来源（选择偏差、曝光偏差、恶意刷评）
• 反馈加权的方式（文档级加权、排序微调）
• 防放大机制（置信度、衰减、限幅、A/B 验证）

用户反馈作为检索加权信号会引入系统性偏差，需要设计防放大机制。偏差来源主要有三类：选择偏差（只有被曝光且被浏览的文档才有反馈机会，热门文档天然获得更多反馈）、曝光偏差（排在前面的结果点击/点赞更多，形成马太效应）、恶意操纵（刷赞刷踩）。工程对策包括：反馈只作用于"文档级加权"，不直接重写查询语义；给反馈设置置信度门限，反馈量不足的文档不参与加权；引入时间衰减，旧反馈权重递减，防止历史偏好固化；对加权幅度设限（如权重上限 1.2x），防止个别文档凭反馈霸榜；将反馈统计与文档质量分层（新文档用内容先验、成熟文档用反馈后验）。上线前必须做 A/B 实验：对比加反馈与不加反馈的线上指标，并监控反馈分布是否失衡（如单一来源集中投票），发现问题即回滚加权并审计数据源。

反馈加权的本质是"用历史行为预测未来相关性"，天然带偏差且会自增强（反馈导致曝光变化，曝光变化又改变反馈）。答题要分两步：先识别偏差来源（选择、曝光、恶意），再给防放大机制（置信度、衰减、限幅、A/B 验证），体现对"反馈闭环失控"风险的警惕。

• 召回逻辑差异：词法精确匹配 vs 语义近似匹配
• 排序依据差异：BM25 统计打分 vs 向量相似度/模型排序
• 可解释性差异与混合检索的适用时机

两者差异体现在三个层面。召回逻辑：传统搜索基于倒排索引做词法精确匹配，查询词必须与文档词项重叠（可加同义词扩展）；RAG 的向量检索基于语义近似，不要求词项重叠，能召回"意思相近但用词不同"的文档，但会漏掉精确词项匹配。排序依据：ES/OpenSearch 默认 BM25 依据词频-逆文档频率统计打分，可解释性强、可复现；向量检索按余弦相似度或内积排序，语义相关但分数可解释性弱，且对查询改写敏感。结果可解释性：BM25 能明确回答"为什么排第一"（哪些词命中、命中频率），向量检索只能给出相似度分数。混合使用时机：当业务同时存在精确查询（型号、条款、ID、人名）与语义查询（找相似概念、意图理解）时，采用混合检索（BM25 + 向量 + RRF 融合），并结合查询路由按查询类型选择路径；需要强可解释与审计（金融、法务）的检索保留词法路兜底。

本题考察对"两类检索范式互补性"的理解：词法匹配精确但无法处理同义改写，语义匹配灵活但缺乏精确性与可解释性，两者不是替代关系。答题按"召回逻辑—排序依据—可解释性"三层对比，最后给出混合使用与查询路由的决策框架。

• 索引质量的可量化指标（分块重叠率、元数据完整率、重复率）
• 分块重叠、元数据缺失、重复文档的治理手段
• 索引质量看板与定期审计机制

索引质量可拆为三个可度量维度。分块重叠：以"重叠 token 占比/块总数"度量，重叠过高会导致同一信息被多次召回、重复引用与上下文浪费，治理上统一分块策略参数（块大小与重叠比例），用采样统计重叠率并设阈值告警；语义分块场景还要检查块边界是否切开完整语义单元。元数据完整性：统计缺失来源 URL、更新时间、标题、权限等关键字段的文档占比，治理上在摄取管道加 schema 校验，缺失必填元数据的文档进入待修复队列而非索引库。去重：以内容哈希与向量相似度双重手段检测重复（同一文档多个版本、近似重复段落），治理上按文档指纹去重保留权威版本，相似块用相似度阈值聚类合并或标记。整体上建立索引质量看板，覆盖文档总数、有效块数、重叠率、元数据完整率、重复率、嵌入失败率，纳入每周巡检与索引重建审计。

"索引质量"是 RAG 质量的起点，但常被忽视——坏块、重复、缺元数据直接导致坏召回与坏引用。答题应把质量拆成可测量的指标（重叠率、完整率、重复率），每个指标给出治理动作与阈值机制，最后落到看板化持续监控，体现数据治理的系统观。

• pre-filter 与 post-filter 的执行语义差异
• 对召回率、延迟、权限正确性的影响
• 安全过滤的放置原则与双保险策略

pre-filter 在向量检索之前先按标量条件（租户、权限、时间窗）圈定候选范围再算相似度，保证过滤条件严格生效、权限正确性最高，但当过滤条件过严时命中候选过少，导致召回率下降，且部分实现（如 HNSW 无索引支持的过滤）需要全量扫描，延迟可能升高。post-filter 先按向量检索 top-k，再对结果过滤，召回率相对有保障、检索延迟稳定，但存在两个致命问题：一是权限过滤被"后置"，被过滤的越权文档可能已进入候选集并暴露于日志或重排阶段；二是过滤后剩余结果不足 k 条，可用结果变少且无法保证"绝不召回越权文档"。安全过滤（权限、合规、敏感内容）必须放在检索前（pre-filter），且权限条件应由服务端强制注入而非模型生成；对 post-filter 只用于非安全性的软过滤（如样式过滤）。高安全场景还需在检索后做二次断言校验（过滤条件与结果集逐条核对），形成双保险。

本题考察过滤执行顺序对三要素的耦合影响：pre-filter 牺牲部分召回率换取权限正确性，post-filter 反之。答题核心是"安全过滤必须 pre-filter 且服务端强制注入"，因为权限泄漏不可接受，并补充二次校验兜底。

• MTEB 基准的任务构成与语言、领域偏差
• 榜单分数与业务检索任务的错位原因
• 自有 query 集评估的正确做法

MTEB（Massive Text Embedding Benchmark）覆盖多语言、多任务的综合分数，但直接迁移到企业任务存在三重错位：一是任务错位，MTEB 以短文本语义相似度、分类、聚类、检索混合任务为主，企业 RAG 多为长文档检索、问答证据检索，任务形态不同；二是领域错位，榜单语料以通用网页、新闻、百科为主，企业语料充满私有术语、型号、代码、行业黑话，通用模型在这些词上区分度不足；三是语言与分布错位，企业可能是中文为主、中英混合、特定写作风格，榜单语言权重与真实流量不符。因此必须用自有 query 集评估：从生产查询日志抽样（覆盖高频与长尾），由业务人员标注或 LLM 辅助标注相关性，计算 Recall@K、MRR、nDCG，并在多轮迭代中对比候选模型；同时记录领域难点案例（术语查询、指代查询）的人工质检结果，作为榜单分数的补充证据。

本题考察对"基准迁移失效"的认知：榜单是通用参考系，企业任务是特定分布，二者在任务形态、领域词汇、语言构成上系统性错位。答题先讲三层错位，再给出"生产日志抽样 + 人工标注 + 检索指标 + 难点案例质检"的自有评估流程，强调评估集要贴近真实分布。

• 检索增强元数据（来源、时间、权限、标签）的分类
• 元数据在过滤、溯源、新鲜度治理中的作用
• 元数据 schema 设计与一致性维护

RAG 索引的元数据可分为四类。溯源类：来源 URL、文档标题、作者、所属系统，用于引用跳转与可信度判断，是答案引用（citation）落地的数据基础。时间类：抓取时间、最后更新时间、生效时间与过期时间，用于新鲜度过滤、按时间窗检索与过期告警。治理类：删除标记（墓碑）、版本号、去重指纹、文档状态（草稿/已发布），支撑删除传播、版本回滚与重复治理。权限类：租户 ID、文档级 ACL、敏感级别，支撑检索阶段的权限过滤。此外可按业务需要加标签类元数据（产品线、文档类型、语言）。这些元数据在摄取阶段写入并做 schema 校验，检索阶段承担两类职责：一是过滤（时间窗、租户、权限、文档类型），二是排序与展示（按时间加权、展示来源链接）。元数据一致性通过摄取管道与源系统同步维护，删除标记必须与源系统删除事件联动，防止"删了源、留了索引"。

元数据是 RAG 从"能检索"到"可治理"的关键：没有来源 URL 无法做引用溯源，没有时间戳无法做新鲜度控制，没有 ACL 无法做权限过滤。答题按溯源、时间、治理、权限四类展开，并强调元数据在过滤与展示两个环节的实际作用，以及删除标记与源系统的事件联动。

• 两阶段瓶颈的区分维度（资源、耗时、结果）
• 定位手段：压测、链路追踪、指标拆解
• 常见瓶颈案例与对应解法

区分两阶段瓶颈应从资源与行为两个角度观察。向量库瓶颈的特征：CPU/内存/磁盘 IO 持续高水位、写入与查询互相争抢、segment 合并或索引构建积压、查询 QPS 触顶后延迟线性恶化、扩容副本后延迟显著改善。检索逻辑瓶颈的特征：资源用量不高但单次查询耗时波动大、耗时集中在查询改写/重排等模型调用、过滤条件导致候选集扫描异常大、返回结果数与相关性与预期不符（逻辑正确性问题）。定位方法：一是链路追踪，在检索链路各环节埋点（改写耗时、向量查询耗时、过滤耗时、重排耗时、组装耗时），用火焰图找耗时大头；二是隔离压测，直接压向量库 API 测其最大吞吐与延迟基线，再对比端到端，差值即逻辑开销；三是指标拆解，监控向量库侧 QPS、P95 延迟、segment 数量、内存命中率，逻辑侧监控过滤条件命中数、候选集大小、重排批次大小；四是复现实验，同一查询分别跑"仅向量""向量+过滤""向量+过滤+重排"，观察每步增量。

两类瓶颈的修复手段完全不同：向量库瓶颈靠扩容、分片、量化、索引参数调优；逻辑瓶颈靠缓存、过滤下推、重排降频、查询改写优化。答题关键是给出可操作的区分方法（资源特征对比 + 链路埋点 + 隔离压测 + 增量实验），而不是空谈"排查"。

• 批量下架的触发来源与条件匹配（来源、文档 ID、指纹）
• 删除传播链路：标记、过滤、索引清理
• 下架后的验证与告警闭环

批量下架的关键是"先不可见、后清理、再验证"三步。触发来源包括内容审核发现、源系统删除、运营人工下架、质量巡检自动识别，下架条件应支持按来源 URL 前缀、文档 ID 列表、内容指纹、标题模糊匹配批量圈选。执行链路：第一步在检索层立即可见地屏蔽——为命中文档批量写入删除墓碑标记（tombstone），检索过滤条件即时生效，保证错误内容在清理完成前不再被召回；第二步后台异步物理清理——删除向量与元数据，重建或合并索引段；第三步验证与闭环——统计下架前后相关查询的召回命中率，抽查确认无残留，并对该批文档的下架动作记录审计日志。对"过期但未删"的场景，可先降权标记"过时"再走人工确认；对紧急错误内容（如错误价格公告），应提供一键下架入口，目标可见性收敛时间控制在分钟级，并联动缓存清理，防止旧结果从响应缓存中继续流出。

批量下架的本质是"紧急止血与后台清理分离"：如果先物理删除再等索引重建，中间窗口错误内容仍会被召回；正确顺序是先墓碑屏蔽（秒级生效）再异步清理。答题强调可见性收敛时间、缓存联动与验证闭环，体现对内容安全事故的处置能力。

• 数据流各阶段的职责划分与产物定义
• 可观测性设计（链路追踪、指标、日志）
• 可回滚与可验证机制（版本、快照、评估门禁）

完整 RAG 数据流应划分为三个阶段、九个子环节：离线数据侧（摄取-解析-清洗-分块-Embedding-索引）与在线推理侧（检索-重排-生成引用），两侧重合点在"文档与块的版本"上。可观测性设计：为每个环节定义输入输出产物（原始文件、清洗后文本、块列表、向量、索引版本），用全局 trace_id 串联整条链路，记录每环节耗时、成功/失败数量、质量指标（解析失败率、清洗丢弃率、嵌入失败率、索引延迟），失败样本进入死信队列并可在管理台重放。可回滚设计：每个环节产物按版本管理（文档版本、块 schema 版本、Embedding 模型版本、索引版本），任意环节升级可整体回退；索引采用蓝绿或影子切换，回填期间双写。可验证设计：建立门禁流水线——摄取后校验文档数与指纹、分块后校验块结构与重叠率、嵌入后校验维度与空向量率、索引后校验 doc 计数与抽样相似度、上线前用黄金评估集跑 Recall@K 与忠实度指标，未达阈值不放行。在线侧每个答案附带检索链路日志（用什么块、排第几、置信度多少），支撑问题回溯。

本题考察 RAG 数据流的工程化程度：单纯"能跑通"不够，必须可观测、可回滚、可验证。答题框架是"阶段职责划分 + trace 级可观测 + 版本化可回滚 + 门禁化可验证"四要素，并把离线与在线两侧通过文档/块版本统一起来。

• 统一向量空间的构建方式（多模态 Embedding 模型）
• 模态标签元数据与路由策略
• 跨模态语义鸿沟的成因与缓解手段

跨模态联合检索的核心是把不同模态映射到同一向量空间。实现方式有二：一是使用多模态对齐模型（如 CLIP 类图文模型、或统一多模态 Embedding 模型）直接输出共享空间向量，文本与图像在同一坐标系中可比；二是"桥接映射"——对图像用视觉-语言模型生成 caption/描述文本，对视频抽帧转写、对音频转写文本，把非文本模态先转成文本再进文本向量空间。联合索引时每类模态记录 type 标签（text/image/table/video/audio），检索默认跨模态统一打分，也可按模态标签过滤。跨模态语义鸿沟的成因：底层特征差异（像素 vs 词）导致相似度分数跨模态不可直接比较；解决手段包括分数归一化（每模态内部 z-score 或按模态分开排后再融合）、模态间用对齐模型而非各自独立的单模态向量、以及用多模态评估集验证"文本查图、图查文本"的互检命中率。工程上还需为图像保留 OCR 文本与版面区域坐标，为表格保留行列结构文本，作为可引用的证据文本。

本题考察多模态检索的统一空间思想：要么用对齐模型共享空间，要么用转写桥接文本空间，两者可组合。答题还需点出"分数跨模态不可比"这一常见陷阱与归一化对策，以及模态标签元数据在过滤与路由中的作用，避免只谈模型不谈工程。

• 删除权请求的索引传播链路（源系统、墓碑、物理删除）
• 向量残留的风险点（备份、副本、日志、缓存、重排结果）
• 删除验证与合规审计

合规删除要求"请求到达后，个人数据从所有可检索位置消失"。传播链路：删除权请求先到源系统执行删除并产生删除事件，事件经消息队列驱动索引服务打墓碑标记，检索层立即过滤（分钟级不可见）；随后后台物理删除向量与元数据、清理相关缓存与重排服务缓存，最后合并索引段释放空间。防止残留的关键是盘点所有副本载体：向量库多副本与备份快照（备份需按保留策略覆盖或加密销毁旧快照）、日志与链路追踪数据（其中的查询文本、文档文本可能含个人信息）、Embedding 缓存与 LLM 响应缓存、重排服务缓存、以及派生数据（用户反馈统计、摘要表）。对"无法物理删除"的备份，需登记台账并纳入定期覆盖销毁。验证机制：构造含该用户数据的测试 query 断言召回为空；扫描向量库中与删除文档指纹匹配的向量；对全链路做抽样审计，并记录删除请求的执行日志（何时、删了什么、哪些系统已确认）以满足监管审计要求。删除应支持按用户 ID 反查文档清单，先冻结再删除。

合规删除的难点不在"删索引"，而在"残留"：向量库的多副本、缓存、日志、备份都是个人数据可能残留的载体。答题按"传播链路（墓碑→物理删除）→残留盘点（副本/缓存/日志/备份）→验证审计"展开，突出反查、冻结、删除、验证四步法。

• RRF 融合原理与排名冲突的表现
• 冲突案例的分类（精确匹配被压制、语义结果混入噪声）
• 调试手段：分数/排名日志、case 分析、参数调优

RRF（Reciprocal Rank Fusion）按"1/(k+rank)"融合两路排名，冲突的典型表现有两类：一类是精确关键词查询中，BM25 高命中的权威文档因融合后排名靠后而被语义噪声结果压制；另一类是语义查询中，向量路召回的相关文档被 BM25 的强词频命中（如高频通用词）挤掉。调试步骤：第一，建立结果日志——记录每条结果的 BM25 分、向量分、RRF 分与各自排名，输出对比表，直接定位"两路排名分歧大"的查询；第二，按查询类型聚类分析——把冲突 query 分为"关键词型（型号、条款）"与"语义型（找相似概念）"，若关键词型冲突多，说明融合权重偏向向量路或 k 值过小；第三，参数调试——调整 RRF 的 k 值（k 越小对排名靠前的结果权重越大，k 通常在 30-100 间取）与两路加权系数，或对精确词命中做加成（如 BM25 分超过阈值时直接置顶）；第四，引入查询路由——根据查询是否含精确实体词，决定以哪一路为主，融合只是兜底。最后用构造的冲突测试集回归，验证修复效果。

RRF 冲突调试的本质是"两路信号的排名分歧可视化"：没有两路排名与分数日志，冲突只能靠感觉。答题给出可执行的调试链路（日志对比→分类→调参/路由→回归测试），并点出 k 值与权重的实际意义，体现工程调试的严谨性。

• 多版本文档的检索层映射（版本号、生效时间、版本状态）
• 权限到检索过滤条件的映射
• 版本与权限组合过滤的验证

多版本映射的核心是"检索只返回当前用户有权看到的有效版本"。文档元数据记录 version、is_latest、effective_time、expire_time、status（草稿/已发布/已归档）与 ACL 列表。检索层过滤条件组合：status=已发布 AND is_latest=true（或按 effective_time 命中时间窗）AND ACL 包含当前用户。版本切换时通过更新 is_latest 标志或版本号实现原子切换，旧版本仍保留在索引中供"按版本追溯"查询，但默认检索路径只暴露最新有效版本。权限映射：把源系统的角色-权限关系同步为文档级 ACL（或按目录继承），检索时由服务端注入用户身份并展开为过滤条件；高安全场景下权限校验放在向量库内部执行（pre-filter），并做结果级二次校验。验证手段：构造"低权限用户 + 多版本文档"的越权测试集，断言低权限用户检索不到任何非授权版本；对版本切换窗口做并发测试，防止切换期间新旧版本同时泄漏或同时不可见。

本题考察"文档生命周期与权限的组合约束"：只过滤权限不看版本会泄漏旧版本，只过滤版本不看权限会越权。答题应给出元数据字段设计（version、is_latest、有效期、状态、ACL）与组合过滤条件，并落到越权测试集与切换窗口验证。

• 融合方式对比（RRF、线性加权、分数归一化）
• 阈值的设定依据（按分数分布、按评估指标）
• 调优流程与回归验证

分数融合有三种主流方式。RRF：对两路排名做倒数排名融合，无需分数归一化、对分数尺度不敏感，适合两路分数不可比时使用，缺点是丢弃了分数强度信息；线性加权：先把 BM25 分与向量相似度分别归一化（min-max、z-score 或 platt 缩放），再按权重相加，保留分数强度，但归一化方法直接影响效果；学习式融合：用小模型（如 lambdaMART、逻辑回归）以两路分数与查询特征为输入学习权重，效果最好但需标注数据。调优流程：第一步构造带标注的评估集；第二步网格搜索融合参数（k 值、权重、归一化方式）并以 Recall@K、nDCG 为目标做离线对比；第三步在最优参数下分析阈值——画出检索分数分布图，观察相关/不相关结果的分数重叠区，按"覆盖率与准确率平衡"选择阈值（如保留 95% 相关结果的分数下界），对低于阈值的查询走"无结果"或降级路径；第四步上线 A/B 验证，监控零结果率与反馈指标。阈值还应分查询类型配置：精确查询阈值可低（宁缺毋滥），语义查询阈值可高（保障覆盖）。

融合与阈值是混合检索的两层调优：先解决"怎么排序"，再解决"排多少"。答题要点出 RRF 与线性加权的适用差异（分数可比性），以及阈值应基于分数分布与评估指标设定而非拍脑袋，并强调分查询类型的差异化配置。

• 多来源文档的格式归一化（解析、编码、结构提取）
• 摄取前的权限校验与来源登记
• 可追溯性的元数据与溯源链路

格式归一化要做四件事：一是统一解析——PDF 用版面解析（区分正文、页眉页脚、表格、图片 OCR），Word 提取段落与样式层级，Confluence 走 API 拉取结构化内容，Slack 处理消息线程与附件，邮件解析正文与附件并识别转发链；二是编码与清洗——统一字符编码、去除控制字符、规范化空白、处理超链接与附件引用；三是结构归一化——所有来源统一为"文档→章节→块"的中性结构，保留标题层级、表格结构与图片占位，供分块与引用使用；四是来源登记——为每篇文档生成稳定 ID 并记录来源系统、原始 URL、拉取时间。权限校验：摄取时验证"采集账号对该文档的读取权限"并同步目标用户的 ACL（Confluence 空间权限、Slack channel 权限、邮件收件人范围），把 ACL 写入文档元数据，检索时按当前用户过滤。可追溯性：每块保留 doc_id、来源 URL、原文位置（页码、段落序号），答案引用时跳转原文；建立"原始文件→解析产物→块→向量→引用"的全链路映射表，任何引用可反查到原始来源。

本题考察多源异构数据的工程化摄取：归一化解决"格式各异怎么统一处理"，权限校验解决"采集到的内容能否给所有用户看"，可追溯解决"引用怎么反查原文"。答题按归一化四步、权限双校验、溯源映射表三个层次展开。

• 语料不足时的预热策略（导入既有文档、知识抽取）
• 空库/低覆盖状态的前置拦截与降级
• 预热完成度的验证与上线门禁

冷启动分两层处理。预热策略：优先导入结构化程度高的既有资产（企业 Wiki 导出、FAQ 手册、历史工单、产品文档），按优先级先索引高频问题对应的文档；对内容空白的场景，用"种子问答"机制——业务方提供高频问题清单，系统检索对应文档，覆盖不足的问题驱动补充语料；还可临时启用大模型兜底（回答前声明"知识库未覆盖"）但必须标记来源可信度。空状态拦截：上线前设定"覆盖率门禁"——用种子问题集跑检索，度量检索命中率（有相关结果的 query 占比）与 Top-1 相关率，低于阈值（如命中率 < 80%）禁止正式上线或仅灰度给小流量；检索阶段对"低置信度"查询强制走"无法回答"路径并引导用户提交工单，同时把这些 query 收集为语料补采清单。空库直接上线的风险不仅是答不好，还会积累大量错误反馈污染后续评估，因此冷启动期间应打开"检索置信度提示"，让用户知道答案来自检索还是模型兜底。

冷启动的本质是"语料覆盖不足期"的质量管理：既要快速补料（导入 + 种子问答 + 兜底策略），又要防患（覆盖率门禁、低置信度拒答、反馈收集反哺语料）。答题强调上线前必须有量化门禁，避免空状态对用户体验与评估数据的双重伤害。

• 幻觉的两种类型：引用溯源失败 vs 无检索依据的模型编造
• 区分方法：引用支持率、句级对齐、证据链检查
• 各自的治理手段

两类问题都表现为"答案无依据"，但机制不同。引用溯源失败（citation failure）：模型确实基于检索到的证据生成，但引用标注错误——引用了错误段落、引用编号与内容不匹配、或把检索内容与自身知识混排后标注错误，属于"有据但标错"。无检索依据的幻觉（hallucination）：检索到的证据不足或为空，模型越过证据用参数化知识自由发挥，生成内容与任何检索块都不对应，属于"无据硬答"。区分方法：一是引用支持率（citation support rate）——把答案按句切分，检查每个句子能否在对应引用的块中找到语义等价证据，用 NLI 模型或规则判定"句子-块对齐"；二是证据链检查——回溯答案中每个事实断言对应的引用块与检索排名，无引用或引用不存在的断言即为疑似幻觉；三是空检索检查——当检索返回零结果或低分结果时，观察模型是否仍给出自信答案，这类"高置信空检索"最危险。治理上：溯源失败靠生成阶段的引用约束（强制引用编号来自候选集）与引用校验；无据幻觉靠检索覆盖率提升、拒答策略（证据不足时明确"无法回答"）与置信度降级。

两类问题共享"答案不可信"的外在表现，但定位不同：溯源失败是"证据管理问题"（引用机制），幻觉是"生成约束问题"（拒答机制）。答题先辨析机制差异，再给出可操作的区分手段（引用支持率、证据链、空检索检测），最后分治，体现 RAG 质量诊断的精确性。