面试题库

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

D5 向量索引与库选型：HNSW 与倒排文件、量化省内存、带过滤的查询与多租户隔离

• 什么时候应该把向量搬出 PostgreSQL？给出可量化的触发条件，也说说不该搬的理由。When should you move your vectors out of PostgreSQL into a dedicated vector database? Give measurable triggers, and also make the case for staying.

  国内高频海外高频进阶#vector-database#architecture#trade-offs

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

  1. 这题考的是工程判断，不是技术偏好。开口就说「专用向量库更专业」的人会被追问到答不上来；面试官想看的是你有没有把迁移成本算进去。
  2. 先给默认立场并给出理由：第一版留在 PostgreSQL，因为事务、备份、时间点恢复、权限、跟业务表 JOIN 和现成的运维工具全是白送的。多一个数据库就多一份同步、一份一致性问题、一份值班负担，这些成本很少被写进选型文档。
  3. 然后给四条可量化的触发线：数据量（判据不是行数而是索引还塞不塞得进内存）、写入频率（分钟级流式更新会让聚类失真、让图持续膨胀）、过滤复杂度（十几个属性的任意组合让部分索引和分区都排列组合不过来）、团队运维能力（没人愿意长期照看第二个数据库，前三条再成立也别搬）。
  4. 第三条要展开一点，因为它最常是真正的原因：专用向量库把过滤做进了索引结构本身，而不是扫完索引再筛，所以在复杂过滤下天然占优。把这一点说出来，说明你理解的是机制而不是口碑。
  5. 还要主动给一条常被忽略的替代路径：很多「向量检索不够用」的问题，真正的解法是混合检索加重排，而不是换数据库。先把关键词一路加回来、把重排接上，再决定要不要搬——顺序搞反了会白搬一次。
  6. 可预期的追问：真要搬怎么迁？答分三步——先双写并在影子流量上比对两边的召回与延迟，再把读流量按比例切过去，最后才停掉旧路径。中间任何一步指标不达标就停下，这比一次性切换安全得多。

  How to reason about it · think before answering

  1. This tests engineering judgement, not tooling preference. Opening with 'dedicated vector databases are better' invites follow-ups you cannot answer.
  2. State the default position and justify it: keep the first version in PostgreSQL, because transactions, backups, point-in-time recovery, permissions, joins with business tables and the tooling your team already knows all come free. A second datastore adds synchronisation, a consistency surface and an on-call burden that selection documents rarely price in.
  3. Then give four measurable triggers: data volume (the test is whether the index still fits in memory, not the raw row count), write frequency (minute-level streaming updates distort clusters and inflate graphs), filter complexity (arbitrary combinations of a dozen attributes defeat both partial indexes and partitioning), and operational capacity.
  4. Expand on filter complexity, because it is most often the real reason: dedicated vector databases push filtering into the index structure instead of applying it after the scan, which is a mechanical advantage rather than a reputational one.
  5. Volunteer the alternative people skip: many 'vector search is not good enough' problems are actually solved by hybrid retrieval plus re-ranking, not by a new database. Add the keyword path and a re-ranker first, then decide.
  6. Expected follow-up: how would you migrate? Dual-write, compare recall and latency on shadow traffic, shift read traffic gradually, and only then retire the old path. Stop at any step where the metrics regress.

  答题要点

  • 默认留在 PostgreSQL：事务、备份、恢复、权限、JOIN 和现成运维都是白送的，多一个库就多一份同步与值班成本。
  • 触发线一是数据量，判据是索引还塞不塞得进内存，而不是行数本身。
  • 触发线二是写入频率，分钟级流式更新会让聚类失真、让图持续膨胀。
  • 触发线三是过滤复杂度，专用库把过滤做进索引结构，复杂过滤下有机制上的优势。
  • 触发线四反过来看：没有长期运维第二个数据库的人手，前三条成立也不该搬；很多问题的真正解法是混合检索加重排。

  Key points

  • Default to staying in PostgreSQL: transactions, backups, recovery, permissions, joins and familiar tooling are free, and a second store adds sync and on-call cost.
  • Trigger one is data volume, measured by whether the index still fits in memory rather than by row count.
  • Trigger two is write frequency: minute-level streaming updates distort clusters and inflate graphs.
  • Trigger three is filter complexity: dedicated stores push filtering into the index structure, a mechanical advantage under complex predicates.
  • Trigger four cuts the other way: without people to run a second database, do not move even if the first three hold. Often hybrid retrieval plus re-ranking is the real fix.

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

• 你会怎么划分一个检索增强生成系统的模块边界？其中哪一层最应该做成可替换的，为什么？How would you draw the module boundaries of a RAG system, and which layer most needs to be swappable? Why?

  国内高频海外高频基础#architecture#modularity#embeddings

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

  1. 这题考的是你有没有真的维护过这类系统。只按「解析、切块、检索、生成」复述一遍流程图，面试官会判定你只搭过 demo——流程图人人都会画，切口画在哪才是经验。
  2. 给一条可复用的判据再往下推：切口应该落在「将来最可能被整个换掉」的地方，而不是按代码量或者功能名称均分。
  3. 用它过一遍：embedding 一年会换好几次，换一次库里所有向量作废、必须全量重算，所以它必须是接口；存储可能从 PostgreSQL 换成专用向量库，而且摄取和查询都要通过它，所以它是两条链路的唯一交界；切块策略在调优期天天改，所以它必须是配置项而不是硬编码。
  4. 结论：最该做成可替换的是 embedding 那一层，理由不是「设计模式」，而是「换模型这件事真的会发生，且发生时代价极高」。
  5. 顺手点出抽象的代价：每多一层间接就多一次跳转和一份心智负担，所以判据是「那件事会不会真的发生」，不会发生的别抽象。
  6. 可预期的追问：那生成模型要不要也抽象？答案是要，但优先级低——换生成模型不需要重算任何存量数据，回滚也便宜，所以它是配置项而不是一层接口。

  How to reason about it · think before answering

  1. This question separates people who have maintained such a system from people who have only built a demo. Reciting the pipeline diagram is not an answer; where you cut it is.
  2. Offer a reusable criterion first: cut where a layer is most likely to be replaced wholesale, not by lines of code or by tidy functional names.
  3. Apply it. Embedding models change several times a year, and each change invalidates every stored vector, so that layer must be an interface. Storage may move from PostgreSQL to a dedicated vector database, and both ingestion and query talk through it, so it is the single shared boundary. Chunking changes daily during tuning, so it belongs in config, not in code.
  4. Conclusion: the embedding layer is the one that must be swappable, because the swap is both likely and expensive, not because interfaces are good style.
  5. Name the cost of abstraction too: every indirection is one more hop while debugging, so the test is whether the change will actually happen.
  6. Expected follow-up: should the generation model be abstracted as well? Yes, but at lower priority, because swapping it does not force recomputation of stored data and rollback is cheap. It is a config value, not a layer.

  答题要点

  • 先给判据：切口落在最可能被整体替换的那一层，不按代码量或功能名称均分。
  • embedding 是最该抽象的一层：换模型意味着存量向量全部作废、必须全量重算，代价高且真的会发生。
  • 存储层是摄取与查询唯一的交界，接口要先定下来再谈两边实现。
  • 切块与检索路数做成配置项，因为它们在调优期改动最频繁，改一次不该动代码。
  • 抽象有成本，判据是那件事会不会真的发生；不会发生的抽象就是过度设计。

  Key points

  • Lead with the criterion: cut where a layer is most likely to be replaced wholesale.
  • The embedding layer is the one to abstract: swapping models invalidates every stored vector and forces a full recompute.
  • Storage is the single boundary shared by ingestion and query, so define its interface before either implementation.
  • Chunking and retrieval routes belong in configuration because they change most often during tuning.
  • Abstraction costs indirection, so only abstract changes that will actually happen.
• 摄取链路和查询链路应该共享哪些代码？强行复用会带来什么具体问题？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.

D11 高级索引：父子文档、摘要索引、上下文检索，以及树状聚合与图检索的取舍

• 同一份语料建了三套索引，检索时你怎么决定走哪一套？You have built three different indexes over the same corpus. How do you decide which one a query goes to?

  国内高频海外高频进阶#index-routing#evaluation#architecture

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

  1. 这题是送分还是丢分，取决于你有没有先反问一句『真的需要三套吗』。上来就答路由策略的人，默认了一个没被验证的前提。
  2. 第一步是承认多数情况下答案是『都不走，走默认那套』。我们在 30 篇语料上把五种索引结构各测一遍，**召回率全部停在 93.8%，没有一种跑赢基线**；唯一动了的是 nDCG@10（块头把它从 0.6438 抬到 0.7218），而两段式的摘要索引还掉到了 87.5%。每种结构补的都是一个特定短板，你没有那个短板时它只带来成本。
  3. 第二步才是路由，而判据不是『哪套准』——那是离线评估该回答的问题，不是运行时能知道的。运行时能拿到的只有**问题的形状**：细节型（答案落在某一段）、概括型（要全库的一个概括）、多跳型（要跨实体串联）。按形状分流，正好对应块级索引、树状聚合索引、图索引。
  4. 实现上就是一个轻量意图分类器，跟前一天的意图路由是同一套东西，不必再造一个。分类结果作为元数据带进请求，方便事后拿评估集回看分错了多少。
  5. 兜底策略要说清楚：分类错了**回落到默认那一套**，不要并行全查一遍再融合。并行看着稳，实际上把延迟和成本按索引套数翻倍，而多出来的那两路大概率一条都进不了上下文预算。
  6. 可预期的追问是『怎么知道分类器分对了』。答案是把路由决策记进日志，定期拿标准答案集回放：对每个问题分别走三套索引，看分类器选的那套是不是指标最好的那套。这是一个能持续跑的离线作业，不需要人工标注。

  How to reason about it · think before answering

  1. Whether this is an easy point or a lost one depends on whether you first ask 'do we actually need three?'. Jumping straight to routing accepts an unverified premise.
  2. Step one is admitting the answer is usually 'none of them — use the default'. Across 30 documents we measured five index structures and every one landed at 93.8% recall, none beating the baseline. The only metric that moved was nDCG@10, which headers lifted from 0.6438 to 0.7218, while the two-stage summary index fell to 87.5%. Each structure patches one specific weakness; without that weakness it is pure overhead.
  3. Step two is routing, and the criterion is not 'which index is more accurate' — that is an offline evaluation question, not something you know at request time. What you do have at request time is the shape of the question: detail-seeking, summarizing, or entity-chaining. Those map onto the chunk index, the tree-summary index and the graph index.
  4. Implementation is a lightweight intent classifier — the same one from the previous day's intent routing, no need to invent another. Carry the decision as request metadata so you can replay it later.
  5. Spell out the fallback: on a misclassification, fall back to the default index rather than fanning out across all three and fusing. Fan-out looks safe but multiplies latency and cost by the number of indexes, and the extra routes usually never make it into the context budget anyway.
  6. Expect 'how do you know the classifier is right'. Log every routing decision and replay the golden set periodically: run each question through all three indexes and check whether the classifier picked the best-scoring one. It is a standing offline job that needs no human labelling.

  答题要点

  • 先反问是否真需要三套：实测五种索引结构召回率全部持平在 93.8%，没有对应短板就是纯成本。
  • 运行时的判据是问题的形状——细节型、概括型、多跳型，分别对应块级、树状摘要、图索引。
  • 复用前一天的意图路由做分类，把路由决策记进请求元数据。
  • 分类错了回落到默认索引，不要并行全查再融合——延迟和成本按套数翻倍。
  • 用标准答案集定期回放，检验分类器选的那套是不是指标最好的那套。

  Key points

  • First challenge the premise: all five index structures landed at the same 93.8% recall in our measurement, so an index without a matching weakness is pure cost.
  • At request time the usable signal is question shape — detail, summary, or entity-chaining — mapping to chunk, tree-summary and graph indexes.
  • Reuse the previous day's intent router for classification and record the routing decision as request metadata.
  • Fall back to the default index on misclassification instead of fanning out and fusing, which multiplies latency and cost.
  • Replay the golden set periodically to check whether the classifier picks the best-scoring index.