RAG 数据工程与企业知识库面试题

面向 RAG、知识库和企业应用岗位。本文默认读者已经理解 embedding、chunk、向量检索、rerank 和生成的基础概念，重点考察如何把它们做成可治理、可增量、可审计、可回滚的生产系统。

使用说明

以员工年假政策为例：HR 在八月换了版本，老文档仍在搜索引擎里。系统既要按生效日期和 ACL 过滤，又要让回答能点回具体页码；只把 PDF 切成向量，解决不了版本和权限问题。

这份题库不把“会调用向量数据库”当作完整答案。回答时要同时说明数据从哪里来、谁对内容负责、权限如何前置、索引如何发布、答案如何引用，以及出了问题怎样定位。面试时应主动补充数据规模、更新频率、延迟、合规和错误代价。

四条链路总览

离线入库链路

数据源/连接器
  -> 拉取与快照
  -> 解析（文本、版面、表格、OCR、图片）
  -> 清洗、规范化、去重
  -> 结构化文档树
  -> chunk / parent-child
  -> metadata 与 ACL 继承
  -> embedding 批处理
  -> 写入候选索引
  -> 完整性校验
  -> manifest / alias 发布

每一步都要有 document_id、source_version、pipeline_version 和可重试状态。解析成功不等于可发布，必须能检查文档数量、chunk 数、权限覆盖、引用定位和失败任务。

在线查询链路

用户问题 + AccessContext
  -> 意图/时间/版本识别
  -> query 改写或多查询
  -> ACL 与租户过滤
  -> 关键词 + 向量召回
  -> 去重、父文档补上下文
  -> rerank
  -> 新鲜度与证据覆盖判断
  -> 生成带 claim-citation 的答案
  -> 引用、权限、忠实度校验
  -> 返回答案与可审计 provenance

权限过滤发生在候选进入模型上下文之前。缓存命中也不能绕过当前权限和知识版本检查。

文档删除链路

源系统删除事件
  -> 校验 event_id / source_version
  -> 写 tombstone，标记 document_id 不可见
  -> 立即从查询过滤中排除
  -> 删除/回收所有 chunk、parent、附件和派生索引
  -> 清理缓存、搜索快照与引用入口
  -> 对账确认无孤儿数据
  -> 保留合规所需审计记录

软删除用于立即止血，不能代替合规要求的物理删除。迟到的旧更新事件不能把已删除文档重新写回。

核心 metadata/schema 示例

{
  "document_id": "hr-policy-2026-08",
  "tenant_id": "acme-cn",
  "source_uri": "s3://knowledge/hr/policy.pdf",
  "source_type": "pdf",
  "source_version": "etag:8a31",
  "content_hash": "sha256:...",
  "title": "员工福利政策",
  "section_path": ["人力资源", "假期", "年假"],
  "effective_from": "2026-08-01",
  "effective_to": null,
  "authority": "hr-policy-owner",
  "acl": {"mode": "groups", "principals": ["all-employees"]},
  "parser_version": "pdf-ocr-3",
  "chunk_version": "parent-child-2",
  "embedding_model": "embed-domain-v4",
  "index_release_id": "release-2026-09-02-07",
  "document_status": "published",
  "chunk_id": "hr-policy-2026-08:p12:c03",
  "parent_id": "hr-policy-2026-08:p12:section-02",
  "page": 12,
  "char_start": 18420,
  "char_end": 19012
}

document_id 标识逻辑文档，source_version 标识源文件版本，content_hash 用于幂等和去重，index_release_id 标识一次可回滚的发布。ACL、版本和定位信息必须与文本一起成为可查询、可审计的数据，而不是只存在于业务代码的临时变量里。

一、数据源与内容责任

Q1：企业知识库的数据源应该怎样盘点？

考察点：能否把数据接入问题转化为数据目录、风险和责任边界，而不是从文件上传接口开始。

回答脉络：先列来源，再做分级；明确 owner、更新方式、权威性、权限和删除语义；最后决定连接器和同步频率。

详细参考答案：我会为每个数据源登记 source_id、系统 owner、业务 owner、数据类型、权威等级、更新机制、最大允许延迟、ACL 来源、保留期限和删除接口。例如 HR 制度的权威源是 HR 系统，Wiki 只是发布副本，邮件属于低权威的线索。对接前先定义“哪些字段是正文、哪些是附件、哪些是评论或草稿”，再决定全量快照、增量 API、Webhook 或定时扫描。接入后的验收不是“能搜到”，而是抽样比对正文、版本、权限和删除结果。

常见追问及答案：

• 追问：没有统一 owner 怎么办？ 先将源标为不可发布或低权威，指定临时责任人和过期时间；不能把责任缺失转嫁给模型。
• 追问：为什么要记录权威等级？ 冲突处理需要依据；同一政策在公告、FAQ 和旧邮件中不应平等对待。

扣分点：只罗列“接入飞书、网页、PDF”；不问谁负责内容正确性；把搜索引擎当作权威源；没有删除和权限来源。

Q2：如何设计数据源 owner 和内容生命周期？（企业场景）

考察点：企业知识库的治理能力，以及能否处理草稿、审核、发布、废止。

回答脉络：区分技术 owner 与业务 owner；定义状态机和 SLA；把内容审批与索引发布关联。

详细参考答案：例如公司报销制度由财务部门维护。财务 owner 负责规则正确性，平台 owner 负责同步，安全 owner 负责 ACL。源文档应有 draft -> approved -> published -> superseded -> deleted 状态，只有 published 且通过解析和权限校验的版本进入在线 alias。effective_from 到达前可以入候选索引但不可见，旧版本在新版本生效后标为 superseded。我会对未更新的高风险文档设置 freshness SLA，过期后降低排序或提示“资料可能过期”，而不是悄悄继续当作当前规则。

常见追问及答案：

• 追问：业务 owner 不愿意维护怎么办？ 提供待确认清单和影响面报告；到期自动降级为非权威或从在线库下线。
• 追问：审核通过但索引失败呢？ 源状态和索引状态分开记录，用户侧保持旧版本或显示未发布，不把半成品设为当前版本。

扣分点：把“抓到文件”当作上线；没有草稿和生效时间；业务 owner 只在事故后出现；无失败告警。

Q3：全量同步、增量同步和事件驱动同步怎样选择？

考察点：同步架构的成本、时效性和可靠性取舍。

回答脉络：比较源系统能力、数据量、可接受延迟和事件可靠性；通常事件驱动加定期全量对账。

详细参考答案：小型低频知识库可以每日全量拉取，简单但延迟高、重复处理多。大规模系统用 created/updated/deleted 事件触发增量解析，事件携带 event_id、document_id、source_version、content_hash 和发生时间；仍保留每日或每周全量对账，修复漏事件。若源系统事件没有可靠投递，不能假设“收到一次就一定完整”，需要 outbox、消息队列重试、死信队列和对账游标。只改 ACL 或标题时可以不重新 embedding，只更新 metadata，但要保留事件顺序和状态记录。

常见追问及答案：

• 追问：如何降低全量成本？ 先按源版本或 ETag 做条件拉取，按 hash 跳过未变化正文；全量扫描只做发现，不必全量重算向量。
• 追问：事件和定时扫描冲突怎么办？ 两者都进入同一个幂等状态机，由业务版本决定谁有效，而不是各写各的。

扣分点：只说“定时任务”；没有漏事件补偿；把每次 metadata 改动都重新 embedding；没有死信和对账。

二、复杂文档解析

Q4：复杂 PDF 的解析链路如何设计？（企业场景）

考察点：版面意识、解析降级和可追溯性。

回答脉络：先判断文本型/扫描型/混合型；保留版面坐标和页码；按置信度选择 OCR 或人工复核。

详细参考答案：我不会只调用一个 PDF 文本提取器。先判断每页是否有文本层、字体编码是否正常、是否存在多栏、表格、脚注和旋转页面。文本型 PDF 先按块读取并利用坐标重建阅读顺序；扫描页进入 OCR，并保存页图、OCR 置信度、文字框坐标。标题、正文、脚注、页眉页脚要分类，页码和页内坐标写入 locator。对金额、日期、否定词和表格等高风险内容设低置信度阈值，进入人工抽检。解析结果必须能回到原 PDF 页，而不是只保存一段失去位置的纯文本。

常见追问及答案：

• 追问：双栏 PDF 文字串行错了怎么办？ 依据文字框的列坐标分栏，再按列内 y 坐标排序，并用抽样页面回归。
• 追问：OCR 把“不得”识别成“得”怎么办？ 对否定词和关键数字做词表校验；低置信度不发布，要求复核。

扣分点：只说“用 OCR”；丢失页码；不检查列顺序；不保留原图和置信度；把解析失败当成空文档。

Q5：OCR 文档怎样避免“能搜到但不能回答”？（企业场景）

考察点：OCR 质量、证据保真和高风险内容控制。

回答脉络：质量检测 -> 关键字段校验 -> 低质量隔离 -> 引用回原页。

详细参考答案：OCR 产物要同时保存 raw_text、规范化文本、页图、词框、置信度和解析器版本。可以用字符置信度、异常字符比例、语言模型困惑度、数字/日期格式校验检测质量。合同金额、税率、产品型号等字段用规则和词典二次校验，发现“0/O”“1/l”“-”等疑似混淆就标记人工审核。检索时可以使用规范化文本，但引用展示必须回到原页或高亮区域，让用户核验。质量不足的页进入隔离索引，避免系统用错误 OCR 生成确定答案。

常见追问及答案：

• 追问：OCR 文字和原图冲突时信谁？ 原图是事实载体，OCR 只是检索表示；系统应提示需要人工查看原图。
• 追问：图片里只有印章或签名怎么办？ 记录视觉元素存在和位置，不把印章识别结果当作合同条款。

扣分点：只看 OCR 字符串；没有质量阈值；数字和否定词不校验；引用无法定位原图。

Q6：表格、合并单元格和跨页表格怎样入库？（企业场景）

考察点：结构化内容还原能力，以及避免单元格语义丢失。

回答脉络：识别表头和层级 -> 还原行列关系 -> 选择行、分组或整表表示 -> 保留坐标。

详细参考答案：表格不能把每个单元格孤立转成文本。应先识别表头、合并单元格、单位、脚注和跨页重复表头，把上层表头向下继承。例如把“华东 / 一季度 / 退款率 2.1%”序列化为包含完整路径的记录。小表可保留 Markdown 表格，大表可按业务实体或行组建 chunk，每行附表名、列名、单位和生效条件。跨页表要合并连续页并去掉重复表头；引用保留页码、表格编号、行列范围。对财务和价格表，还应保留原始单元格值，避免格式化丢失精度。

常见追问及答案：

• 追问：表格太大怎么查总计？ 表格检索负责定位，聚合和计算交给结构化查询或计算服务，模型不应心算全表。
• 追问：合并单元格为空代表缺值吗？ 不一定，可能继承上层分类；解析器要区分空值、继承值和原文缺失。

扣分点：按视觉顺序简单拼接；丢表头、单位、脚注；不区分缺值和继承值；让 LLM 代替数据库做精确聚合。

Q7：网页、Wiki 和邮件解析有哪些特殊问题？（企业场景）

考察点：正文抽取、动态内容、线程关系和时效性。

回答脉络：区分正文与模板噪声；保存 URL、版本和抓取时间；邮件要处理线程、附件、收件人权限。

详细参考答案：网页要抽取正文区域，去掉导航、推荐、广告和重复页脚，同时保留标题层级、表格、代码块、锚点和更新时间。动态 Wiki 需要记录页面版本或更新时间，不能只以 URL 去重。邮件要把主题、正文、线程顺序、发件时间、附件关系分开，引用具体邮件而不是整条线程；签名、免责声明和重复引用要清理。邮件权限尤其敏感，收件人列表不能直接等同于永久访问权，应从邮件系统或项目空间计算 ACL。外部网页还要视为不可信数据，网页中的指令不可执行。

常见追问及答案：

• 追问：同一网页每天内容都变怎么办？ 用内容 hash 和抓取时间生成版本，保留快照，按业务要求决定当前版本。
• 追问：邮件里有人说“请忽略系统规则”怎么办？ 这是文本内容，不是系统指令；进入证据时标为不可信，不能改变工具或权限行为。

扣分点：把整页 HTML 入库；邮件只取最新一封导致上下文丢失；把收件人当 ACL；忽略外部文本注入。

三、清洗、规范化与去重

Q8：文档清洗应该删什么，不能删什么？

考察点：噪声清理与事实保留之间的边界。

回答脉络：按可回答性判断；保留限定条件；所有清洗都可复现、可回放。

详细参考答案：可以删掉重复页眉页脚、导航、广告、目录中的纯页码、无意义空白和重复引用，但不能删除“仅限”“不得”“除外”、适用范围、金额、日期、版本和生效条件。清洗最好输出原文、规范化文本和变更日志，并将 normalizer_version 写入 metadata。不要用大模型自由改写原文作为唯一入库文本，因为它可能改数字或否定词。对于口语、繁简体、全半角、单位和日期，可以做可逆或可解释的规范化，同时保留原始字符串用于引用和审计。

常见追问及答案：

• 追问：清洗后文本和原文不一致怎么办？ 检索用规范化文本，答案证据优先使用原文片段；两者有差异就提高审核等级。
• 追问：目录是否完全删除？ 目录不能作为主要证据，但可保存为导航结构，不应和正文 chunk 混在一起。

扣分点：以“看起来干净”为标准；用摘要替代原文；删除限制条件；没有原文留存和版本化。

Q9：如何做文档去重和近重复检测？

考察点：精确去重、近重复、版本判断和存储成本控制。

回答脉络：先 hash 精确去重，再做结构化指纹或相似度近重复；不要把相似误判为同一版本。

详细参考答案：精确重复用规范化正文的 SHA-256 或源 ETag 判断。近重复可比较标题、段落 shingle、MinHash 或文档级 embedding，再由规则判断：页眉变化、格式变化可能仍是同一内容；只改一条政策则必须形成新版本。索引可以复用相同内容的 canonical chunk，但每个业务文档仍保留自己的来源和 ACL 关系，不能因为正文相同就合并权限。去重结果要记录 canonical_document_id、匹配原因和置信度，方便撤销错误合并。

常见追问及答案：

• 追问：同一制度在两个部门目录里出现，是否只保留一份？ 内容可以 canonicalize，但来源关系和 ACL 分开；检索结果要按用户可见来源展示。
• 追问：近重复阈值怎么定？ 在标注集上按漏合并和误合并成本选择，不能凭一个通用 cosine 阈值。

扣分点：只按文件名去重；用向量相似就删除新文档；忽略权限和来源关系；没有人工回滚。

Q10：如何处理文档重命名、移动和复制？

考察点：逻辑身份设计和避免孤儿 chunk。

回答脉络：用稳定 document_id 与可变路径分离；识别 rename/copy 语义；更新引用和 ACL。

详细参考答案：路径不是文档身份，应该使用源系统稳定 ID 作为 document_id，把路径和标题作为可变 metadata。源系统明确发送 rename 时，只更新 metadata，保持 chunk ID 稳定；移动到新的安全目录时重新计算 ACL。复制操作要根据源系统语义判断是同一逻辑文档的新引用，还是独立文档：若是独立文档，需要新的 document_id，但可以共享 canonical 内容。同步后对账文档表和 chunk 表，确保旧路径没有残留引用。

常见追问及答案：

• 追问：chunk ID 直接带路径可以吗？ 不建议，路径变化会制造大量删除和重写；应以稳定文档 ID、版本和 chunk ordinal 或内容指纹组成。
• 追问：重命名期间用户点击旧链接怎么办？ 保留可审计的 locator 映射，前端跳转到新路径，但访问仍重新校验 ACL。

扣分点：用路径当主键；重命名当删除加新增但没有关联；忽略复制后的权限变化；不做孤儿数据检查。

四、chunk、parent-child 与结构

Q11：企业文档的 chunk 策略如何落地，而不是只给 token 数？（企业场景）

考察点：结构化切分、证据完整性和按文档类型配置。

回答脉络：先识别文档结构，再按语义单元切；数字、例外和条件不能跨 chunk 丢失；用评估集调参。

详细参考答案：制度按条款和标题层级切，FAQ 保持问答对，技术手册按章节、接口或代码块切，表格按表头加行组切。固定 token 只是兜底。每个 child chunk 都带 section_path、前置标题和适用条件，必要时在 chunk 前补一个轻量上下文前缀。对很长条款可以按句切，但保证定义、条件、例外和结论共同出现。应比较 chunk 版本的召回、证据覆盖、上下文 token、延迟和引用定位，而不是只看某个经验数字。

常见追问及答案：

• 追问：overlap 越大越好吗？ 不是，过大增加重复和成本；优先通过结构化边界保证完整性。
• 追问：chunk 改版会影响引用吗？ 引用定位要绑定文档版本和 locator，不能假设 chunk ordinal 永久不变。

扣分点：只背 500 token；所有文件用同一策略；不保留标题和条件；只看向量分数不做评估。

Q12：parent-child 检索怎样设计？

考察点：小粒度召回与大上下文回答的协调。

回答脉络：child 负责命中，parent 负责上下文；控制扩展范围、去重和权限继承。

详细参考答案：把章节或表格主题保存为 parent，把可检索的段落、条款或行组保存为 child。先对 child 做混合召回和 rerank，再按 parent_id 聚合，返回命中的 child 加有限的相邻 child 或 parent 摘要。这样既能命中精确句子，又不让模型只看到孤立条件。parent 和 child 必须继承同一文档版本、ACL 和删除状态；扩展 parent 后仍要重新做权限过滤。上下文拼装要限制每个 parent 的最大 token，避免一个命中把整本手册带进 prompt。

常见追问及答案：

• 追问：父块权限更宽、子块权限更窄怎么办？ 以最小权限为准，继承关系不能扩大访问范围；必要时按安全边界拆 parent。
• 追问：父块没有向量是否可行？ 可行，父块作为结构和回答上下文，child 作为主要索引单元。

扣分点：召回 child 后无条件返回整篇文档；父子权限不一致；不处理重复上下文；删除 child 忘记 parent。

Q13：如何处理跨 chunk 的多跳问题和上下文窗口？

考察点：证据组合、查询规划和上下文预算。

回答脉络：识别是否需要多证据；分解子问题；分别召回后合并去重；不以扩大 top_k 解决一切。

详细参考答案：例如“北京研发员工今年能否把未休年假转到明年”可能需要组织政策、地区规则和当前年份公告。系统先把问题拆成实体、适用范围、时间和条件，分别检索，再检查证据是否覆盖同一员工范围和版本。候选按证据角色组织，而不是单纯按分数排序；合并时去重、保留冲突，并给每个 claim 分配来源。上下文预算应优先保留直接支持数字和条件的片段，剩余内容做摘要或二次检索。没有覆盖就返回不确定，而不是靠模型常识补桥。

常见追问及答案：

• 追问：多跳要不要让 Agent 自己决定？ 可以，但后端限制最大查询次数、允许的过滤字段和 token 预算，不能把检索规划完全交给模型。
• 追问：多跳结果冲突怎么办？ 按适用范围、权威等级和生效时间分层；无法消解就显式列冲突。

扣分点：只提高 top_k；不做子问题边界；跨版本硬拼；没有最大跳数和成本上限。

五、metadata、ACL 与多租户

Q14：核心 metadata 应该有哪些字段？哪些字段不能只放在业务库？

考察点：检索过滤、引用、版本和可观测性所需的数据模型。

回答脉络：按身份、来源、时间、结构、索引、质量、权限、定位八类说明；区分事实字段和派生字段。

详细参考答案：至少需要：tenant_id、document_id、source_uri、source_version、content_hash、标题和 section_path；effective_from/to、updated_at、authority；document_status、acl_policy_id；parser_version、chunk_version、embedding_model、index_release_id；page、坐标或字符偏移；质量分数和 deleted_at。其中租户、文档版本、状态、ACL、locator 和索引 release 必须能随检索结果一起读取，否则无法在检索层过滤、做引用校验和重放历史回答。业务库仍可保存完整 ACL 关系，但索引侧要有安全的可执行投影。

常见追问及答案：

• 追问：metadata 过多会不会拖慢向量检索？ 只把需要过滤和返回的字段做索引，复杂 ACL 可转成安全域或授权文档集合；不要无差别存大 JSON。
• 追问：派生的 freshness score 能否当事实？ 不能，它是排序特征；事实仍以源版本和生效时间为准。

扣分点：只有 text 和 vector；没有 tenant、状态和版本；把权限放在前端；引用没有 locator。

Q15：权限为什么必须前置过滤？如何避免“检索后再隐藏”？（企业场景）

考察点：检索泄露、ACL 下推和纵深防御。

回答脉络：先构造服务端 AccessContext；在召回前下推租户和 ACL；生成、引用、缓存、日志再次校验。

详细参考答案：无权限内容一旦进入 rerank 或 prompt，就可能通过摘要、存在性、数字或拒答理由间接泄露，生成后删除原文无法补救。因此查询服务应从认证身份和授权服务生成不可由用户篡改的 AccessContext，包含租户、角色、部门、安全域、策略版本和时间。检索器只接受这个对象，将过滤条件下推到索引或先得到允许的文档集合。返回模型前再核对文档状态和 ACL，引用链接访问时重新授权。缓存 key 绑定租户、策略版本和索引 release；普通日志只记 ID 和判定结果，不记无权原文。

常见追问及答案：

• 追问：候选集合太大，过滤下推很慢怎么办？ 按租户、安全域或 ACL 预分区；或维护授权文档 ID 集合，选择支持过滤的存储，而不是先召回全库。
• 追问：权限刚收回但缓存还有答案怎么办？ 权限变更事件递增策略版本并主动失效；每次命中还校验当前策略。

扣分点：依赖模型自觉；先全库搜索再脱敏；允许前端传 ACL；忽略引用、缓存和日志泄露。

Q16：多租户知识库如何隔离？

考察点：租户边界、共享索引风险和运营成本。

回答脉络：根据隔离等级选择物理库、分区或 metadata；所有主键、缓存、指标和任务带 tenant；做越权测试。

详细参考答案：强监管或客户数据完全隔离时，使用独立存储、密钥和索引；普通 SaaS 可以共享集群但按 tenant_id 分区，并强制过滤下推。租户 ID 不能只在应用层拼接，索引、对象存储、任务队列、缓存、日志和监控标签都要带租户。共享 embedding 批任务要防止跨租户 payload 混淆，导出和备份也要按租户隔离。查询和引用服务都要做 negative test：用户 A 的召回集合、缓存和 locator 不能出现用户 B 的文档。

常见追问及答案：

• 追问：每租户独立索引太贵怎么办？ 按风险和规模分级：小租户共享分区，大租户独立分片；统一发布和对账接口。
• 追问：租户删除如何保证彻底？ 删除租户级 tombstone，停止新任务，清理对象、向量、缓存、备份中的可删除数据，并输出审计证明。

扣分点：只给 query 加 tenant_id；忽略备份和异步任务；租户删除只删向量；没有越权回归。

六、增量、乱序、删除与发布

Q17：增量事件重复、乱序或迟到时怎样保证幂等？

考察点：事件驱动索引的状态机、版本比较和可重试性。

回答脉络：事件 ID 去重只是第一层；以源版本或单调序列保护新旧；任务结果可重复。

详细参考答案：事件表记录 event_id，消费端先做幂等去重，但不能只依赖 event ID，因为同一变化可能有不同事件。以 document_id 为聚合键比较 source_version 或源系统序列号，旧版本事件只能记录为过期，不能覆盖新版本。任务写入使用 document_id + source_version + chunk_id + pipeline_version 作为业务键，upsert 前后都检查状态。解析和 embedding 失败可重试，非暂时性错误进死信；任务完成后才更新文档版本状态。即使消息重复执行，最终 chunk 集合和 metadata 也应相同。

常见追问及答案：

• 追问：源版本不是单调数字怎么办？ 使用源 ETag、更新时间加冲突规则，或在连接器侧维护可靠游标；无法判断时进入人工/对账队列。
• 追问：新版本任务慢，旧版本事件先完成怎么办？ 写入时做版本条件更新，旧任务可以落到隔离版本，但不能推进 current 状态。

扣分点：只用消息队列保证顺序；只按 event_id 去重；没有旧版本覆盖保护；失败任务直接丢弃。

Q18：文档删除如何传播到所有派生数据？（企业场景）

考察点：删除闭环、软硬删除和迟到事件防护。

回答脉络：先 tombstone 止血，再清理所有派生物；用对账确认；保留必要审计但不保留可访问正文。

详细参考答案：删除事件到达后，先在权威文档表写 deleted_at 和 tombstone，使查询过滤立即排除该 document_id 的所有版本、parent、child 和附件。随后异步清理向量、关键词索引、对象存储解析物、OCR 页面、缓存、预计算摘要和引用入口。tombstone 保留 source_version 或删除序列，防止迟到旧更新重建。完成后对账：源系统已删文档在每个派生索引都没有可检索数据，删除失败进入告警和补偿队列。历史答案可保留不可点击的审计摘要，但不能通过历史引用重新读取已删除原文。

常见追问及答案：

• 追问：物理删除期间会不会被搜到？ 查询以 tombstone 和状态过滤止血；物理残留仍要按合规期限清理，不能把软删除当永久删除。
• 追问：删除和新建同名文件如何区分？ 以稳定源 ID 和版本区分，不以文件名判断。

扣分点：只删当前 chunk；没有 tombstone；清理不了缓存和附件；没有删除证明和迟到事件保护。

Q19：索引发布怎样保证用户不会看到半套新内容？

考察点：构建、校验、发布和读取的一致性语义。

回答脉络：新版本隔离构建；manifest 校验；alias 原子切换；明确读旧或读新，不读混合状态。

详细参考答案：为每次构建生成独立 index_release_id，所有新增 chunk 写入候选索引，不直接污染 current。构建完成后校验文档数、chunk 数、失败比例、ACL 覆盖、版本分布、抽样召回和引用定位，生成不可变 manifest。查询路由读取 knowledge_current alias，发布时原子地从旧索引切到新索引；同一请求固定一个 release，不在一次回答中混用两个 release。新版本未准备好时继续读旧版本，并在运维面告警。保留旧索引一段时间，支持快速回滚。

常见追问及答案：

• 追问：增量更新也要整库发布吗？ 可以按安全边界发布小 release，但必须有可见性标记和原子路由；不能因为是增量就允许半套状态裸露。
• 追问：读旧版本是否会过期？ 配置最大陈旧时间；高风险规则可要求新版本就绪后再回答或转人工。

扣分点：直接在生产索引 upsert 并立即可见；没有 manifest；没有 alias 和回滚；请求中混合版本。

Q20：embedding 或 chunk 策略升级怎样双写、灰度和回滚？

考察点：索引版本隔离、可复现性和发布工程。

回答脉络：新模型/新切分器独立索引；离线评估；双写或重建；小流量灰度；原子切换和回滚。

详细参考答案：embedding 模型、维度、归一化、距离度量、解析器或 chunk 策略变化，都应形成新的索引版本，不能在一个向量空间里混用。记录完整构建配置和输入快照，先离线比较 recall@k、nDCG、答案忠实度、引用支持率、延迟、成本和权限错误。增量期可以新旧双写，全量历史文档异步重建；线上按租户或固定流量灰度，同一请求只选一个 release。切换通过 alias 完成，保留旧 release；若出现召回下降、越权、延迟或成本异常，切回旧 alias。修复后重新构建，不能在生产索引上手工补几条向量。

常见追问及答案：

• 追问：维度变了能否更新原字段？ 通常不能，维度和语义空间不兼容，应使用新索引和新查询配置。
• 追问：双写期间查询哪套？ 由实验路由明确选择；双写是写入策略，不代表在线把两个空间的分数直接混合。

扣分点：同索引混模型；只做离线答案对比；没有固定 release；升级后删除旧索引；不能快速回滚。

七、检索、结构化查询与答案可信度

Q21：混合检索如何与结构化数据库联合查询？（企业场景）

考察点：非结构化语义检索与精确事实查询的边界。

回答脉络：先分类问题；结构化事实走 SQL/API；文本证据走 hybrid；通过实体 ID 汇合，并分别引用。

详细参考答案：例如“华东客户过去 30 天未结算订单及对应合同条款”不能只搜向量。先从订单库按租户、客户、时间和状态查询精确数据，再用合同文档索引按合同 ID、条款号做关键词加向量检索。两边通过 customer_id、contract_id、order_id 汇合，模型只负责解释和归纳，金额、数量和日期以数据库结果为准。SQL 参数必须由后端绑定并做权限校验，不能让模型自由生成并直接执行高风险 SQL。最终答案分别引用结构化查询快照和合同文档 locator。

常见追问及答案：

• 追问：什么时候不该用向量库？ 精确聚合、排序、事务状态、库存、余额等问题优先用数据库或业务 API。
• 追问：数据库记录也会更新，如何引用？ 保存查询时的快照版本或时间戳；引用说明“截至某时刻”，不能伪装成静态文档。

扣分点：用向量相似度回答金额总和；模型直接执行无约束 SQL；不做实体关联；结构化结果没有时间边界。

Q22：混合检索的候选如何合并？

考察点：BM25/关键词与向量分数不可直接比较，以及去重策略。

回答脉络：分别取候选；分数归一化或使用 rank fusion；按稳定 ID 去重；权限过滤尽量前置。

详细参考答案：关键词和向量分数分布不同，不能简单相加。可以分别取 top-k，用 Reciprocal Rank Fusion 等基于名次的方法合并，或在验证集上校准归一化分数。候选按 canonical chunk 或 chunk_id 去重，同一 parent 可以保留多个互补 child。对订单号、错误码、版本号和条款号提高关键词权重；自然语言问题用向量补召回。融合后再 rerank，记录各路命中和最终排名，便于判断是词法漏召回还是语义噪声。

常见追问及答案：

• 追问：先过滤还是先融合？ 租户、ACL、删除状态和 release 必须在候选进入后续阶段前过滤；无权候选不能参与排名。
• 追问：词法召回空了怎么办？ 向量仍可独立召回；两路失败时进入无答案或澄清路径。

扣分点：直接把 cosine 和 BM25 相加；只保留一条路径；不去重；无权限结果参与 rerank。

Q23：rerank 应该放在哪一层，怎样控制成本？

考察点：粗召回与精排的职责、候选规模和降级策略。

回答脉络：先宽召回，再对有限候选 rerank；根据问题风险和候选质量自适应；设置超时降级。

详细参考答案：初召回追求 recall，通常取多个来源的候选并做 ACL、状态和去重；reranker 只处理几十条以内的 query-document 对，输出精确相关性。生成前再按证据覆盖、时间和 authority 做最终选择。高风险制度、复杂比较可以扩大候选或使用更强 reranker；简单 FAQ 使用轻量模型或跳过。设置超时后退回融合排名，但要记录降级事件。rerank 评估要看 top-3 是否包含直接支持和限制条件，不能只看平均分。

常见追问及答案：

• 追问：rerank 分数能代表真实性吗？ 不能，只代表 query-document 相关性；真实性和权威性由来源、版本和证据校验决定。
• 追问：rerank 把旧文档排第一怎么办？ 让时效、有效期和 authority 参与排序或过滤，不能只信相关性。

扣分点：对全库 rerank；把相关性分数当真值；不设超时和降级；不检查条件和版本。

Q24：引用 provenance 如何做到可验证？

考察点：claim 与证据绑定、精确定位和历史审计。

回答脉络：答案拆 claim；服务端生成 citation ID；绑定本次 evidence 和 release；渲染前校验权限与版本。

详细参考答案：模型不应自由生成 URL 或文档名。检索服务为每个证据分配本次请求内的 citation_id，包含 document_id、source_version、index_release_id、page/字符偏移、原文 hash 和 ACL 快照。生成要求返回 claims: [{text, citation_ids}]，服务端检查 citation 是否来自本次可见证据，原文是否能支持 claim，数字和限制条件是否覆盖。前端显示标题、页码和可展开片段，后端保存 immutable provenance 用于回放。文档删除或权限变化后，历史回答仍可保留当时 release 和摘要审计，但点击原文必须重新授权。

常见追问及答案：

• 追问：引用文档名存在就够了吗？ 不够，必须定位到版本、章节、页码或偏移，并证明它支持具体 claim。
• 追问：一个 claim 由三份文档共同支持呢？ 绑定多个 citation，并记录是联合支持、相互印证还是存在冲突。

扣分点：只显示来源标题；相信模型编的链接；引用与当前请求无关；忽略删除和 ACL。

Q25：如何处理“无答案”和“相似但不支持”的结果？

考察点：拒答路由、证据覆盖和避免硬编。

回答脉络：无答案不能只靠相似度阈值；综合覆盖、精确约束、权威性、冲突和时效；支持澄清、扩大检索、转人工和拒答。

详细参考答案：高相似度只说明表达接近，不代表包含问题的结论。系统应检查候选是否覆盖实体、时间、地区、产品版本和否定条件，是否有明确支持句，多个来源是否一致，且是否仍在生效。把结果分类为 answerable、needs_clarification、insufficient_evidence、conflicted 和 forbidden。生成 prompt 明确不允许用参数记忆补全；生成后逐 claim 做支持校验。真正没有依据时说“当前知识库未找到足够依据”，说明搜索范围和缺失信息，必要时转人工，不把拒答率本身当作越高越好。

常见追问及答案：

• 追问：能否用 cosine 小于阈值拒答？ 只能作为特征，分数需按 query 类型和模型校准；还要看证据内容和约束覆盖。
• 追问：用户坚持让你猜怎么办？ 明确猜测不具备企业依据；可以给出待确认因素和官方渠道。

扣分点：空结果才拒答；相似度高就回答；把模型常识填进去；没有区分无答案与无权限。

Q26：多个版本冲突时怎样回答？（企业场景）

考察点：版本、适用范围、权威性和冲突呈现。

回答脉络：先判断是否真冲突；按生效时间、适用范围、权威等级选择；无法判断就并列说明。

详细参考答案：先比较 effective_from/to、适用部门、地区、产品版本和发布状态，很多“冲突”其实是不同范围。相同范围下，优先已发布且当前生效、权威等级更高的版本；旧版本保留为历史证据但默认不进 current 查询。若两份公告日期和 authority 无法区分，答案应列出两种规则、各自生效条件，并请求用户确认场景。引用同时显示版本和日期，避免只写“根据员工手册”。冲突检测可以在入库阶段做规则提示，在查询阶段做最终裁决。

常见追问及答案：

• 追问：新文档发布时间晚但生效日期更晚，当前用哪个？ 看当前查询时间和 effective_from，发布时间不能替代生效时间。
• 追问：FAQ 与正式制度不一致怎么办？ 正式制度通常 authority 更高，FAQ 可作为解释但不能覆盖正式条款。

扣分点：只按更新时间选；把旧版本物理删掉导致无法审计；强行合并冲突；不展示适用范围。

Q27：如何处理知识时效性和过期风险？

考察点：freshness 与 correctness 的区别，及高风险内容策略。

回答脉络：记录源更新时间和生效区间；按文档类型设 SLA；过滤、排序和回答提示分层处理。

详细参考答案：时效性不是简单按 updated_at 越新越好。制度要看生效日期，产品版本要看适用版本，新闻或运营公告要看发布时间和失效时间。索引记录 effective_from/to、last_verified_at、源同步延迟和 freshness 状态。已过期内容默认过滤；尚未确认的新内容不进入 current；高风险内容超过 SLA 时提示“需核验”，或直接转人工。评估时单独统计索引新鲜度和过期内容误召回，不能因为答案看似正确就忽略已失效政策。

常见追问及答案：

• 追问：更新时间字段不可信怎么办？ 以源系统版本、审批和生效事件为主；不可信字段只能做弱排序特征。
• 追问：老文档是历史问题的正确答案怎么办？ 查询识别“截至某日期”或历史语境，显式选择历史 release/版本。

扣分点：按抓取时间代替生效时间；过期文档仍默认可见；没有 SLA 和告警；不支持历史查询。

八、缓存、成本、评估与多模态

Q28：RAG 缓存应该缓存什么？如何避免越权和陈旧？

考察点：分层缓存、权限边界和版本失效。

回答脉络：区分 embedding、候选、rerank、答案缓存；key 绑定知识和权限版本；命中后仍校验。

详细参考答案：可以缓存公共 query embedding、规范化 query、按 release 的公共候选，必要时缓存 rerank 结果。最终答案缓存风险最高，key 至少包含 query、tenant、权限策略版本、index release、prompt/model 版本和语言。文档或 ACL 变化通过版本递增和事件主动失效，不能只设置很长 TTL。命中缓存也要重新检查文档状态、ACL 和引用可见性。对多轮会话，缓存不能把上一用户的 AccessContext 混入当前请求。

常见追问及答案：

• 追问：检索结果缓存后文档更新怎么办？ 把 index_release_id 放进 key，新 release 自然隔离；高时效数据再配主动失效。
• 追问：答案缓存适合内部制度吗？ 只有在权限、版本和生效时间都稳定时才谨慎使用，否则优先缓存 embedding 或公共候选。

扣分点：按 query 全局缓存答案；忽略 ACL 和 release；命中就跳过授权；只靠 TTL 保证一致性。

Q29：怎样控制 RAG 的成本而不盲目降低质量？

考察点：成本分解、路由、批处理和质量预算。

回答脉络：拆 embedding、存储、检索、rerank、LLM、OCR 成本；按问题风险自适应；用质量指标验证。

详细参考答案：离线成本主要是 OCR、解析和 embedding，在线成本主要是 query embedding、候选检索、rerank、输入 token 和输出 token。优化方法包括增量 hash 跳过未变文档、embedding 批处理和限流；查询先做轻量分类，简单 FAQ 小 top-k，复杂比较才启用 hybrid、rerank 和多跳；去重和上下文裁剪减少 token；低风险场景使用小模型，高风险保留强模型。每种优化都要在固定集比较 recall、答案忠实度、引用支持率、P95 和单请求成本，不能只看账单。

常见追问及答案：

• 追问：top_k 降低会不会漏答案？ 可能，所以先按问题类型和评估集找拐点；对高风险或低置信度请求自动升级策略。
• 追问：能否只保留摘要降低 token？ 摘要不能替代关键原文证据；可用摘要导航，再取原文支持 claim。

扣分点：只换便宜模型；把 top_k 一刀切；不计算 OCR 和重建成本；成本下降但没有质量回归。

Q30：如何区分召回指标、答案忠实度、引用支持率和索引新鲜度？

考察点：是否能建立分层质量观测，而不是用一个“准确率”概括 RAG。

回答脉络：逐一给出定义、计算对象和失败归因；强调四者不能互相替代。

详细参考答案：

指标	关注对象	典型定义	不能说明什么
召回指标	检索结果	Recall@k：标注的相关证据是否出现在前 k；MRR/nDCG 看排名和多证据质量	命中了不代表模型正确使用
答案忠实度	答案与上下文	将答案拆成 claim，判断每个 claim 是否被本次证据蕴含	忠实不一定代表答案完整或业务上正确
引用支持率	claim 与 citation	被有效引用直接支持的关键 claim 数 / 关键 claim 总数	有引用不代表引用内容支持结论
索引新鲜度	源状态与可查询索引	例如源变更到 current release 可见的延迟、SLA 内文档占比	新鲜不代表解析正确或有权限

一个系统可能 recall 很高但忠实度低，说明生成阶段乱补；答案忠实但引用支持率低，说明引用绑定或展示有问题；新鲜度高但召回低，说明新内容已进库却不可检索。排障必须按 source -> parse -> index -> retrieve -> generate -> cite 分层归因。

常见追问及答案：

• 追问：最终答案准确率能替代召回率吗？ 不能，模型可能凭常识答对，或用错误证据碰巧答对。
• 追问：引用存在率和引用支持率一样吗？ 不一样。存在率只看是否有 citation，支持率还看 citation 是否真的支持对应 claim。

扣分点：把 cosine 分数当准确率；把有引用当支持；不测索引延迟；只报端到端满意度。

Q31：如何构建企业 RAG 的离线评估集和线上监控？

考察点：评估集设计、切片分析和回归机制。

回答脉络：脱敏真实问题加专家题；标注证据、权限、版本和无答案；离线回归与线上反馈闭环。

详细参考答案：评估样本至少包含 question_id、用户 AccessContext、corpus/index release、期望答案、expected_evidence_ids、关键约束、问题类型、风险等级和 is_unanswerable。覆盖简单事实、多证据比较、精确编号、时间版本、权限不可见、冲突、删除后不可见和无答案。把数据拆成开发集、固定回归集和隐藏集，文档或解析器升级自动跑。线上 trace 记录各阶段耗时、候选、release、token、成本、拒答原因和引用校验结果；用户反馈进入人工复盘，但不能直接把未核验答案加入知识库。

常见追问及答案：

• 追问：模型裁判能否完全替代人工？ 不能。用人工标注的小集校准模型裁判，权限、合规和关键数字必须人工抽查。
• 追问：怎样定位一次答案错在哪？ 用 trace 回放原始 query、AccessContext 摘要、召回列表、rerank、prompt、claim-citation 和 release，逐层归因。

扣分点：评估集只有问题和答案；没有权限、无答案和版本样本；只看平均分；没有固定回归和 trace。

Q32：多模态文档怎样让图片、图表和扫描附件可检索？（企业场景）

考察点：文本与视觉证据的联合表示、引用和权限继承。

回答脉络：先区分图片中的文字、结构和视觉关系；文本 OCR 与视觉 embedding 并行；答案引用回原页/区域。

详细参考答案：多模态文档可以并行生成 OCR 文本、表格结构、图片说明和页面视觉 embedding，但不要把图片说明当成原始事实。图表要保存标题、坐标轴、图例、单位、数据点区域；流程图要保留节点和连线关系。检索时可做文本、视觉和结构化三路召回，再由多模态 reranker 或模型组合。所有派生对象继承文档版本、ACL 和删除状态，引用包含页码、图片 ID、坐标框或表格行列。对于扫描合同、工程图和财报，关键数字需回显原图核验，低置信度结果不直接生成确定结论。

常见追问及答案：

• 追问：图片没有文字还能搜吗？ 可用视觉 embedding 和人工/模型生成的描述做候选召回，但最终答案应引用图片区域，且描述要标注为派生信息。
• 追问：图像 OCR 与 PDF 文本重复怎么办？ 用页面和区域关联去重，保留质量更高的表示，不要让两路重复 token 淹没上下文。

扣分点：只对图片做一句泛化 caption；丢失坐标和单位；视觉派生文本没有版本和 ACL；不做关键数字复核。

面试收口：一段可复述的生产级答案

如果面试官要求在一分钟内总结，可以这样回答：

我会先建立数据目录，明确每个源的技术 owner、业务 owner、权威等级、ACL、版本和删除语义。
离线链路从快照和增量事件开始，经过可回放的 PDF/OCR/表格/网页解析、清洗去重、结构化切分、
parent-child、metadata 继承和批量 embedding，写入独立候选索引；校验通过后用 manifest 和 alias 发布。
在线链路把用户身份生成服务端 AccessContext，在召回前做租户和 ACL 过滤，再做 hybrid、去重、rerank、
时效和证据覆盖判断，答案按 claim 绑定服务端生成的 provenance。更新要处理重复、乱序、删除传播和旧版本保护，
模型或 chunk 升级采用新索引、离线评估、双写灰度、原子切换和可回滚。
质量上分开看 Recall@k、答案忠实度、引用支持率、索引新鲜度，以及权限错误、延迟和成本。

常见总扣分点

• 把 RAG 题答成向量数据库产品名和参数名。
• 没有数据源 owner、权威等级、审批、生效和删除语义。
• 只说“重新切分和 embedding”，不处理重复、乱序、失败重试、tombstone、对账和发布一致性。
• 权限放在生成后、前端或 prompt 中，忽略租户、缓存、引用和日志。
• 混淆召回、相关性、答案正确性、忠实度、引用支持率和新鲜度。
• 让模型代替数据库做金额、库存、状态和聚合查询。
• 只展示文档标题，不提供版本、页码、偏移、区域和可验证 provenance。
• 升级索引时混用 embedding 空间，或删除旧索引导致无法回滚。
• 没有无答案、冲突、权限不可见、删除和过期版本的评估样本。