面试题库

14 天 RAG：从检索到可信回答

D3 文档进来这一关：PDF 与 HTML 解析、表格与扫描件、清洗规则和必须留下的元数据

• 文档解析阶段应该保留哪些元数据？少了其中某一项会在哪个环节出问题？Which metadata should a document parsing stage preserve, and which downstream feature breaks if you drop each one?

  国内高频海外高频进阶#metadata#ingestion#access-control

  分析过程 · 先想清楚再作答

  1. 这题最容易答成列清单。区分度不在你能列出几个字段，而在能不能给每个字段配一个具体的下游功能——列了八个字段却说不出谁在用，等于没设计过。
  2. 用一条判据把字段选出来：删掉之后还能不能从原件重新恢复。不能恢复的，解析时就必须留；能恢复的（比如格式、空白）可以放心丢。
  3. 然后一一对应地说：块编号支撑可验证的引用，没有它引用就只能靠模型自觉；标题路径支撑「这句话出自哪一节」和按结构切块；页码支撑引用精确到页；权限标签支撑检索层过滤；更新时间支撑材料冲突时的取舍；内容指纹支撑增量同步。
  4. 挑两个讲透代价。权限标签少了，等到要做访问控制时只能全量重新解析一遍；更糟的是有人会图省事在生成阶段过滤，那等于内容已经进了上下文，泄露已经发生。
  5. 内容指纹少了，每次同步都是全量重建：重新解析、重新切块、重新向量化。一份几千篇的知识库每天重算一次，光 embedding 的账单就够说服任何人。
  6. 可预期的追问：字段拿不准要不要留怎么办？答保守——存储是整条链路上最便宜的一环，加一个字段的代价远小于重跑一次全量解析。

  How to reason about it · think before answering

  1. The trap here is answering with a bare list. The differentiator is pairing every field with a concrete downstream feature. Listing eight fields without naming who consumes them shows you never designed one.
  2. Give the selection rule first: can this be recovered from the original file later? If not, it must be captured at parse time. Formatting and whitespace can be dropped because the original still has them.
  3. Then map fields to consumers: a stable chunk id makes citations verifiable, a heading path tells the user which section a sentence came from and enables structure-aware chunking, page numbers make citations land on the right page, an access-control label enables filtering inside retrieval, an updated-at date resolves conflicting sources, and a content hash enables incremental sync.
  4. Take two of them all the way to cost. Without the access label you must re-parse the whole corpus when access control lands, and worse, people work around it by filtering at generation time, which means the content already reached the context and the leak already happened.
  5. Without a content hash, every sync is a full rebuild: re-parse, re-chunk, re-embed. For a few thousand documents synced daily, the embedding bill alone settles the argument.
  6. Expected follow-up: what about a field you are unsure of? Be conservative. Storage is the cheapest part of the pipeline, and adding a field costs far less than re-running a full parse.

  答题要点

  • 判据是「删了还能不能从原件恢复」，不能恢复的必须在解析时留下。
  • 块编号服务于可验证的引用，标题路径服务于定位与按结构切块，页码服务于引用精确到页。
  • 权限标签必须在解析时打上，否则做访问控制时要全量重解析，且容易被错误地放到生成阶段过滤。
  • 更新时间用于材料冲突时并列两种说法，内容指纹用于增量同步，少了它每次都要全量重建。
  • 拿不准就保守保留：加一个字段的成本远低于重跑一次全量解析。

  Key points

  • The rule is recoverability: if it cannot be recovered from the original later, capture it at parse time.
  • Chunk ids back verifiable citations, heading paths back localisation and structure-aware chunking, page numbers make citations land precisely.
  • Access-control labels must be attached during parsing, otherwise enabling ACL means re-parsing everything, and teams end up filtering at generation time where the leak has already occurred.
  • Updated-at lets you present conflicting sources side by side; a content hash enables incremental sync instead of full rebuilds.
  • When unsure, keep the field: storage is far cheaper than a full re-parse.

D13 上生产：增量同步与去重、按权限过滤、缓存分层、链路追踪与成本延迟账

• 为什么权限过滤不能放在生成阶段做？放在那里会泄露什么？Why can't access control be applied at the generation step? What exactly leaks if you put it there?

  国内高频海外高频深入#access-control#filter-pushdown#multi-tenancy

  分析过程 · 先想清楚再作答

  1. 这题在考你有没有真的把 RAG 当系统看。答成「因为不安全」拿不到分，面试官要的是「具体泄露了什么」和「除了泄露还有什么后果」两件事。
  2. 先用一个画面把位置说清楚：档案管理员先把全部档案摊在桌上让你挑，你挑完他再抽走三份说这些不能看——你已经看见标题了。在生成阶段过滤就是这个动作。
  3. 然后拆后果，两条，第二条更能显出做过工程：一是**泄露面**，越权文档已经进过检索、参与过排序、被进程读进过内存、大概率写进了检索日志和链路追踪，哪怕最终答案里没有它的内容；二是**结果被稀释**，取前 8 条里有 3 条不该看，筛掉只剩 5 条，而本该补位的第 9、10 名合法结果永远没机会上来——用户体感是「查不到」，你的日志里却是一次正常检索。
  4. 给正确做法：把权限谓词和排序、LIMIT 写进同一条查询，数据库先裁行再排序取前 k，越权的行一次都没被比较过。两种落法要都讲：行级过滤是一份索引加一个谓词，索引隔离是按边界各建各的索引。
  5. 选型判据要给出来：看隔离边界的数量和稳定性。部门这种个位数且几乎不变的边界，隔离划算；几万个用户各自的私有文档就只能行级过滤，否则运维扛不住。补一句共用索引的副作用——数据量大的租户会拖慢别人的检索质量，因为候选名额是共享的。
  6. 可预期的追问：缓存怎么办？这是同一个问题的第二现场——答案缓存的 key 里必须带上权限范围，否则一个用户的答案会被另一个用户命中，而且这条泄露路径连检索日志都不会留下痕迹。

  How to reason about it · think before answering

  1. This checks whether you think about RAG as a system. 'Because it's insecure' scores nothing; the interviewer wants what specifically leaks, and what else goes wrong besides the leak.
  2. Anchor the position with an image: the archivist spreads every file on the table, you pick nine, and only then does he pull three back saying you may not read those. You have already seen the titles. Filtering at generation time is that gesture.
  3. Then split the consequences, and note the second one is what shows engineering experience. First, exposure: the unauthorized documents were retrieved, ranked, read into process memory, and almost certainly written to retrieval logs and traces, even if none of their text reaches the answer. Second, dilution: you take the top 8, three are off-limits, the user gets five, and the legitimate results ranked ninth and tenth never get promoted. The user experiences 'it can't find anything' while your logs show a perfectly normal retrieval.
  4. State the fix: put the permission predicate in the same query as the ordering and the LIMIT, so the database prunes rows before ranking and unauthorized vectors are never compared. Cover both shapes: row-level filtering is one index plus a predicate; index isolation is a separate index per boundary.
  5. Give the selection criterion: the number and stability of the isolation boundaries. A handful of departments that rarely change makes isolation worthwhile; tens of thousands of per-user private document sets leave you with row-level filtering, because that many indexes is unmanageable. Add the shared-index side effect: a large tenant degrades everyone else's retrieval quality because candidate slots are shared.
  6. Expected follow-up: what about caching? It is the same bug's second crime scene. The answer cache key must include the permission scope, or one user's answer will be served to another, and that leak leaves no trace in the retrieval log at all.

  答题要点

  • 在生成阶段过滤时，越权文档已经被检索、排序、读进内存并写进日志与追踪，泄露面比「答案里有没有」大得多。
  • 第二个后果是结果被稀释：筛掉之后名额空着不补，用户体感是查不到，日志里却是一次正常检索。
  • 正确做法是把权限谓词和排序、LIMIT 写进同一条查询，让数据库先裁行再排序取前 k。
  • 行级过滤与索引隔离的选型判据是隔离边界的数量与稳定性；共用索引时大租户会挤占小租户的候选名额。
  • 缓存是同一个漏洞的第二现场：答案缓存的 key 必须包含权限范围，否则会跨用户串答案且不留痕迹。

  Key points

  • Filtering at generation time means unauthorized documents were already retrieved, ranked, held in memory and written to logs and traces; the exposure is far wider than 'did the text reach the answer'.
  • The second consequence is dilution: filtered-out slots are not backfilled, so users see 'nothing found' while the log shows a normal retrieval.
  • The fix is to put the permission predicate in the same statement as ordering and LIMIT so the database prunes before ranking.
  • Choose between row-level filtering and index isolation by the count and stability of the boundaries; a shared index lets a large tenant crowd out a small one's candidate slots.
  • Caching is the same bug's second crime scene: the answer cache key must carry the permission scope or answers leak across users without a trace.