面试题库

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

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

• 一份 PDF 解析出来的文字顺序是乱的，你会怎么排查和修复？The text extracted from a PDF comes out in the wrong order. How do you diagnose and fix it?

  国内高频海外高频进阶#pdf-parsing#ingestion#data-quality

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

  1. 这题在考你有没有真的动手解析过 PDF。区分度在第一句：能不能说出「PDF 里根本没有阅读顺序」这个前提。答不出这句的人，后面只会说「换个库试试」。
  2. 先给排查顺序：把抽出来的文本片段连同页码、坐标、字号一起打印出来，别只看拼好的字符串。乱序的原因几乎都藏在坐标里，看纯文本永远看不出来。
  3. 然后按现象分三类。左右两栏一行一行地交替，是多栏没识别；同一段话被拆成很多短片段且 y 值有回跳，是内容流按绘制顺序写的；文字整体没问题但夹着重复出现的短句，那不是乱序，是页眉页脚没剔。
  4. 修法对应着来：多栏就重建阅读顺序——把每页文字块的左边界排序找最大空隙当分栏线，再按「栏号、y 从大到小、x 从小到大」重排；页眉页脚按固定的 y 值带切掉，并打印剔除条数确认没误伤。
  5. 补一条能证明你在生产里干过的话：修完要有可回归的判据，不能靠肉眼。用乱序疑似度——顺着排好的顺序走一遍，统计「同栏内往回跳」和「从右栏跳回左栏」的比例，它不需要标准答案，可以挂进流水线天天跑。
  6. 可预期的追问：多栏识别错了怎么办？回答分两头——把分栏判定做保守（空隙不够宽、或者一侧内容占比太低就按单栏处理），并且让断言在双栏被误判成单栏时同样会报警，宁可漏修也不要悄悄改错。

  How to reason about it · think before answering

  1. This checks whether you have actually parsed a PDF yourself. The first sentence is the differentiator: a PDF has no reading order at all, only drawing instructions with coordinates.
  2. Start with the diagnostic step: dump the extracted fragments together with page, x, y and font size instead of looking at the concatenated string. The cause is always in the coordinates.
  3. Then classify the symptom. Lines alternating between left and right means multi-column layout was not detected. Fragments with y jumping backwards means the content stream was written in drawing order. Clean text sprinkled with a repeated short line is not disorder at all, it is a header or footer that was never stripped.
  4. Match the fix to the symptom. For columns, rebuild the order: sort the left edges of the fragments on each page, take the widest gap as the column boundary, then sort by column, then y descending, then x ascending. For headers and footers, cut fixed bands at the top and bottom and print how many fragments you dropped so you can confirm you did not cut into the body.
  5. Add the production-grade part: the fix needs a regression signal, not an eyeball check. Compute an out-of-order score by walking the sorted fragments and counting backward jumps within a column plus right-to-left column jumps. It needs no ground truth, so it can run on every ingest.
  6. Expected follow-up: what if column detection is wrong? Keep the detector conservative, treating a narrow gap or a lopsided split as single column, and make sure the assertion still fires when a two-column page is misread as one. Missing a fix is better than silently corrupting the order.

  答题要点

  • 前提先说清：PDF 只存「在某页某坐标画某段文字」，段落和阅读顺序都是解析时推出来的。
  • 排查时把片段连同页码、坐标、字号一起打印，纯文本看不出乱序的原因。
  • 三种典型成因：多栏没识别、内容流按绘制顺序写、页眉页脚没剔除。
  • 多栏的修法是找最大 x 空隙定分栏线，再按「栏号、y 降序、x 升序」重排。
  • 修完要有不依赖标准答案的回归指标，比如乱序疑似度，能挂进摄取流水线。

  Key points

  • State the premise: a PDF stores only drawing instructions, so paragraphs and reading order are inferred, not read.
  • Debug by dumping fragments with page, coordinates and font size; plain text hides the cause.
  • Three common causes: undetected multi-column layout, content stream written in drawing order, and headers or footers left in.
  • Fix columns by finding the widest gap between left edges and sorting by column, then y descending, then x ascending.
  • Add a ground-truth-free regression metric such as an out-of-order score so the fix stays fixed.
• 文档解析阶段应该保留哪些元数据？少了其中某一项会在哪个环节出问题？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.

D7 第一周综合：把六天的零件装成一个可一键启动的检索问答服务并复盘

• 摄取链路和查询链路应该共享哪些代码？强行复用会带来什么具体问题？What should the ingestion path and the query path share, and what concretely goes wrong when you over-share?

  国内高频海外高频进阶#architecture#ingestion#retrieval

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

  1. 题眼在「强行」两个字。面试官想看的是你能不能说出复用的边界，而不是背诵「不要重复自己」。
  2. 先说清两条链路的性质差异：摄取是批处理，几十秒跑完，失败重跑一遍就行；查询是在线请求，几百毫秒要出结果，失败用户当场看到。错误处理、超时、并发策略天然不同。
  3. 所以结论是：**共享接口，不共享流程**。两边唯一该共享的是存储层的那个接口，以及 embedding 的函数签名——注意后者共享的是签名和模型选择，不是调用流程。
  4. 给出强行复用的具体症状：抽出来的公共模块里开始出现 isIngest 这类分支，一个改动要同时验证两条链路，最后没人敢动它。
  5. 补一条真正必须一致的东西：给块算向量和给问题算向量必须用同一个模型。这不是复用代码，是复用配置——而且要把模型名写进向量表，否则模型换了没人发现，检索会静默地返回垃圾。
  6. 可预期的追问：那切块逻辑呢？查询侧压根不切块，所以它只属于摄取链路；真要在查询侧用到（比如 D11 的父子回填），走的也是存储层读回大块，不是把切块器搬过来。

  How to reason about it · think before answering

  1. The word to notice is 'over-share'. The interviewer wants the boundary, not a recital of DRY.
  2. Start from how the two paths differ. Ingestion is batch: tens of seconds, and a failure just means rerunning it. Query is online: hundreds of milliseconds, and a failure is visible to the user immediately. Error handling, timeouts and concurrency are simply not the same problem.
  3. Hence the rule: share the interface, not the flow. The only genuinely shared thing is the storage interface, plus the embedding function signature.
  4. Name the symptom of over-sharing: the extracted module fills up with isIngest branches, every change has to be verified on both paths, and eventually nobody dares touch it.
  5. Add the one thing that truly must match: chunks and queries must be embedded by the same model. That is shared configuration, not shared code, and the model name belongs in the vector table so a silent mismatch is detectable.
  6. Expected follow-up: what about chunking? The query path never chunks. Even when it needs a parent block, it reads it back through storage rather than importing the chunker.

  答题要点

  • 共享接口不共享流程：唯一的交界是存储层，加上 embedding 的函数签名。
  • 两条链路的错误处理与延迟约束根本不同，批处理可以重跑，在线请求必须快速失败。
  • 强行复用的症状是公共模块里长出 isIngest 分支，改一次要验两条链路。
  • 必须一致的是模型选择而不是代码：块与查询要用同一个 embedding 模型，并把模型名记进向量表。
  • 切块只属于摄取；查询侧需要大块时通过存储层读回，而不是把切块器搬过去。

  Key points

  • Share the interface, not the flow: storage is the only boundary, plus the embedding signature.
  • The two paths have different error handling and latency budgets; batch can rerun, online must fail fast.
  • Over-sharing shows up as isIngest branches and changes that must be verified twice.
  • What must match is the model choice, not the code: record the model name alongside every stored vector.
  • Chunking belongs to ingestion only; the query path reads larger units back through storage.