面试题库

30 天从前端工程师到 Agent 工程师

D12 长期记忆：pgvector、embedding、chunking、memory_search 工具

• chunking 的切分策略会怎么影响检索效果？切多大合适？How does the chunking strategy affect retrieval quality, and how do you pick a chunk size?

  国内高频海外高频进阶#chunking#rag#retrieval-quality

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

  1. 题眼在「怎么影响」。只回答一个数字（比如「切 500 字」）会被追着问为什么，所以要先把两个方向的失效模式讲出来，数字才有落点。
  2. 切太碎的失效模式：单张卡片脱离上下文。「他说要 42 码」检索命中了也没用，代词失去指代，模型拿到一句悬空的话反而更容易编。
  3. 切太整的失效模式更反直觉，也是这题真正的区分点：一块横跨三个主题时，它的向量是这几个主题的平均值，结果对哪个 query 都不太像，命中率反而下降。**块越大信息越全，却越难被检索到**——能说出这句话基本就过了。
  4. 然后给可操作的口径：目标 400 字符、相邻块重叠 80 字符，并优先在句号、换行这类自然边界收尾。重叠的作用要说清楚——一句关键的话被切口劈开时，两块各拿半句，重叠保证它至少在其中一块里是完整的。
  5. 补上代价，这是工程视角：重叠 80 除以 400 等于 20% 的存储放大，向量也跟着多一份；内容高度重叠的两块可能一起被检索出来，白占返回名额，所以要按内容去重。
  6. 可以预期的追问：怎么验证切分策略好不好？答案是准备一批 query 与标注好的期望命中，量召回率和 top-k 命中率，改切分参数后重跑对比——切分是可以被度量的，不该靠感觉调。第二个追问是「对话数据要不要原样切」，答不要：先让模型抽成陈述句再切，否则大量寒暄句会把向量拉平。

  How to reason about it · think before answering

  1. The hinge is 'how does it affect'. Naming a number alone invites a why, so describe both failure modes first and let the number follow.
  2. Too small: a chunk loses its context. 'He wants size 42' retrieves fine but resolves to nothing — pronouns dangle and the model is more likely to fabricate.
  3. Too large is the counter-intuitive half and the real discriminator: a chunk spanning three topics gets a vector that averages them, so it looks only vaguely like any query and recall drops. Bigger chunks carry more information yet are harder to retrieve.
  4. Give an operational default: target 400 characters with 80 characters of overlap, ending on natural boundaries such as sentence stops or newlines. Explain the overlap — when a key sentence lands on a cut, each side holds half of it, and the overlap guarantees at least one chunk holds it whole.
  5. Add the costs: 80 over 400 is 20% storage amplification plus an extra vector per duplicated span, and near-duplicate chunks can both surface and waste result slots, so deduplicate by content before returning.
  6. Expect: how do you validate a chunking strategy? Build a query set with labelled expected hits and measure recall and top-k hit rate, then re-run after changing parameters — chunking is measurable, not a matter of taste. Second follow-up: should raw dialogue be chunked as-is? No — have the model distil it into standalone statements first, or filler turns flatten the vectors.

  答题要点

  • 切太碎：单块脱离上下文，代词失去指代，命中了也用不上
  • 切太整：一块横跨多个主题，向量被平均，对任何 query 都不够像，命中率反而下降
  • 可操作口径：目标 400 字符、重叠 80 字符，优先在句号或换行这类自然边界收尾
  • 重叠的作用是保证被切口劈开的句子至少在一块里完整；代价是约 20% 的存储放大和可能的重复命中
  • 别直接切对话原文，先抽成陈述句；切分效果要用标注好的 query 集测召回率，而不是凭感觉

  Key points

  • Too small: chunks lose context, pronouns dangle, and a hit is useless
  • Too large: one chunk spans several topics, its vector averages them, and recall drops for every query
  • Working default: target 400 characters with 80 characters of overlap, cutting on sentence or newline boundaries
  • Overlap keeps a split sentence whole in at least one chunk, at roughly 20% storage amplification plus possible duplicate hits
  • Distil dialogue into standalone statements before chunking, and validate with a labelled query set measuring recall

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

D4 切块策略：固定、递归、按结构、父子与语义五种切法，以及用评估而不是直觉来选

• 你怎么决定切块大小？说出你会看的两个指标和一个反例。How do you decide on chunk size? Name two metrics you would look at, and one counterexample.

  国内高频海外高频进阶#chunking#evaluation

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

  1. 这题的题眼是「怎么决定」，不是「多大合适」。答一个具体数字（512 token、1000 字符）就已经输了——面试官想看的是你有没有一套定法，而不是你记得住哪个默认值。
  2. 先把矛盾摆出来：块大则信噪比低、上下文贵，块小则单块缺语境、模型答不出所以然。切块大小就是在这两头之间找位置，所以两个指标必须分别对应这两头。
  3. 第一个指标是检索侧的命中率——答案文档有没有进上下文。第二个是生成侧的可用性，最省事的代理指标是切碎率，也就是有多少块结尾停在半句话上；再往前一步就是忠实度和引用是否可定位。
  4. 关键补一句：两个指标必须在**同一个 token 预算**下比，不能按「取前 k 块」比。k 固定时块越大塞进去的字越多，大块切法会赢在买得多而不是切得准上。这一句往往是这道题的区分点。
  5. 反例要具体。最好用的一个是：把块从 400 字调到 1200 字，命中率不降反升——但那是因为一整篇短文档被当成一块塞了进去，检索其实什么都没做，等于退化成了全文投喂。指标涨了，系统更差了。
  6. 可预期的追问是「那你第一次上手时从哪个数字起步」。答：先按文档类型选切法（有标题层级就按结构切），块长从 300 到 500 字起步、重叠取一到两成，然后立刻建一组标准问题跑评估，用两三轮迭代把它调到位。起步值是起步值，不是结论。

  How to reason about it · think before answering

  1. The question is about method, not about a number. Answering with a specific default (512 tokens, 1000 characters) already loses it — the interviewer wants to hear that you have a procedure.
  2. State the tension first: large chunks dilute the signal and cost context; small chunks lose the surrounding meaning so the model cannot use them. The two metrics you name should map onto those two failure modes.
  3. Metric one is retrieval-side hit rate: did a document that actually answers the question make it into the context. Metric two is generation-side usability, cheaply proxied by the fraction of chunks that end mid-sentence, and more seriously by faithfulness and whether citations resolve.
  4. Add the point that separates candidates: both metrics must be compared under the same token budget, never under a fixed top-k. With fixed k, bigger chunks simply buy more text and win for the wrong reason.
  5. Make the counterexample concrete: raising chunk size from 400 to 1200 characters can lift hit rate purely because whole short documents now fit in one chunk, which means retrieval stopped doing anything and you are back to stuffing full documents. The metric improved while the system got worse.
  6. Expect the follow-up: where do you start on day one. Pick the strategy from the document type first (structural splitting whenever headings exist), start around 300 to 500 characters with 10 to 20 percent overlap, then build a golden set immediately and iterate. A starting point is not a conclusion.

  答题要点

  • 先按文档类型选切法，再调长度：有标题层级就按结构切，没有结构才谈固定长度或语义。
  • 看两个指标：检索侧的命中率，生成侧的切碎率（进一步是忠实度与引用可定位性）。
  • 两个指标必须在同一个 token 预算下比，不能按「取前 k 块」比，否则大块只是买得更多。
  • 反例：块调大后命中率上升，但那是因为整篇被当成一块，检索退化成全文投喂。
  • 起步值 300 到 500 字、重叠一到两成，然后靠一组固定问题迭代，不靠直觉定稿。

  Key points

  • Choose the strategy from the document type first, then tune length: split on headings whenever the structure survives parsing.
  • Watch two metrics: retrieval hit rate on one side, mid-sentence break rate (then faithfulness and citation resolvability) on the other.
  • Compare under an equal token budget, never a fixed top-k, or larger chunks win by buying more text.
  • Counterexample: hit rate rises after enlarging chunks because whole documents now fit in one chunk and retrieval has effectively stopped working.
  • Start near 300 to 500 characters with 10 to 20 percent overlap, then iterate against a fixed question set instead of guessing.
• 父子切块的收益是什么？它在什么情况下反而会拖慢系统？What does parent-child chunking buy you, and when does it slow the system down instead?

  国内高频海外高频进阶#chunking#parent-child

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

  1. 这题考的是你有没有意识到「检索单位」和「上下文单位」可以是两个东西。答不出这句话，后面说什么都是复述。
  2. 收益一句话说清：小块进索引，信噪比高、容易被找到；命中之后顺着父指针把整节回填给模型，语境完整。精度和完整度这次不用二选一。
  3. 拖慢的场景要从代价一条条推。第一条是上下文预算：每命中一个新子块可能拖进来一整个父节，同样的 token 预算装不下几条，检索结果的多样性反而变差。
  4. 第二条是写入侧：父子两套都要维护，文档更新时两边都要重算，块 id 的稳定性也更难保证，增量同步的复杂度明显上升。
  5. 第三条是收益消失的条件：当文档本身的小节就不长时，父块和子块差不多大，你付了两套索引的钱，什么也没多买到。所以父子切块适合长节、深层级的文档，不适合结构本来就细碎的知识库。
  6. 可预期的追问是「那和直接把块切大有什么区别」。答：切大是把噪声一起放进索引，父子是只把噪声放进上下文、不放进索引——被检索的那一段始终是干净的短文本，这是本质区别。

  How to reason about it · think before answering

  1. This question checks whether you know that the retrieval unit and the context unit can be two different things. Without that sentence, everything else is recitation.
  2. State the benefit compactly: small chunks go into the index so they are easy to match, and once a child is hit you follow the parent pointer and hand the model the whole section. You stop trading precision against completeness.
  3. Derive the slowdown from the costs. First, the context budget: every new child may drag in an entire parent, so an equal budget holds fewer distinct pieces and result diversity drops.
  4. Second, the write path: two levels to maintain, both recomputed on every document update, and chunk ids become harder to keep stable, which makes incremental sync noticeably more complex.
  5. Third, the condition under which the benefit disappears: when sections are already short, the parent and the child are nearly the same text, so you paid for two indexes and bought nothing. Parent-child suits long sections and deep hierarchies, not already fine-grained knowledge bases.
  6. Expect the follow-up: how is this different from simply using bigger chunks. Bigger chunks put the noise into the index; parent-child puts the noise only into the context. What gets matched stays short and clean.

  答题要点

  • 核心是把检索单位和上下文单位拆开：小块负责被找到，大块负责被读懂。
  • 收益是精度与完整度同时拿到，不用在信噪比和语境之间二选一。
  • 代价一：一次命中可能拖进整个父节，同样的上下文预算装得下的条数变少，结果多样性下降。
  • 代价二：父子两套索引都要维护与重算，文档更新时增量同步的复杂度明显上升。
  • 失效场景：文档小节本来就短时父子块差不多大，多付一套成本却没多买到东西。

  Key points

  • The core idea is decoupling the retrieval unit from the context unit: small chunks get found, large chunks get understood.
  • The payoff is precision and completeness at the same time instead of trading one for the other.
  • Cost one: a single hit can drag in a whole parent, so an equal context budget holds fewer distinct results and diversity suffers.
  • Cost two: two index levels to maintain and recompute, which makes incremental sync on document updates considerably harder.
  • It stops paying off when sections are already short, because parent and child are nearly identical and you bought nothing for the extra cost.

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

• 父子索引和上下文检索都在补『块被切碎』这个问题，它们的差别到底在哪？Parent-child indexing and contextual retrieval both patch the same problem — chunks losing their context. What actually distinguishes them?

  国内高频海外高频进阶#indexing#contextual-retrieval#chunking

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

  1. 这题的题眼是『补的是哪一半』。答成『一个是切块技巧、一个是加提示词』就是在描述实现，面试官想听的是它们各自作用在检索管道的哪一段。
  2. 拆的办法是把管道分成两段问：检索时看到什么、生成时看到什么。父子索引改的是**生成侧**——检索单位还是小块，只是命中之后把上下文单位换成大块；上下文检索改的是**检索侧**——块头拼进去是为了让这一块能被检索到，模型生成时并不需要它。
  3. 结论：父子索引解决『找到了但看不全』，上下文检索解决『看得全但找不到』。前者不改变谁被检索到，后者不改变模型看到多少。它们正交，可以叠加。
  4. 这个差别还决定了它们各自要用什么指标去量：上下文检索动的是名次，用召回率和 nDCG 量得到；父子索引动的是『材料够不够答』，召回率这种二值指标量不出来。我们那份 20 题评估集单文档档已经 100% 饱和，父子索引在表里跟基线持平——那不是它没用，是尺子量不了它。
  5. 顺着这条差异能推出一个立刻能用的优化：既然块头只服务检索，就不该进上下文。它进了上下文就是在每一次查询里白占预算，而且这笔钱是长期的。我们的实验里把这个开关一改，五列指标一个不变，600 token 的预算里多装进了 36 个 token。
  6. 代价也不同：父子索引的代价是索引条目变多、每次装进上下文的东西变大；上下文检索的代价是一次性要给每块调一次模型，加上索引 token 永久变大。前者是空间，后者是时间加空间。
  7. 可预期的追问是『那我全都上』。答案是先看失败案例：日志里是『材料不完整』多，还是『压根没检索到』多。没有对应的失败模式就不该上，这两个手法都不是免费的。

  How to reason about it · think before answering

  1. The hinge is which half of the pipeline each one fixes. Answering 'one is a chunking trick, the other adds a prompt' just describes implementations; the interviewer wants to know where each acts.
  2. Split the pipeline in two and ask separately: what does the retriever see, and what does the generator see. Parent-child changes the generation side — retrieval still runs on small chunks, but a hit is swapped for its parent. Contextual retrieval changes the retrieval side — the header exists so the chunk can be found at all, and the generator does not need it.
  3. Conclusion: parent-child fixes 'found it but can't read it'; contextual retrieval fixes 'readable but never found'. Neither changes what the other changes, so they compose.
  4. That difference also dictates which metric can see each one. Contextual retrieval moves rank, so recall and nDCG catch it. Parent-child moves 'is the evidence sufficient to answer', which a binary recall metric cannot see. Our 20-question set is already saturated at 100% on single-document questions, so parent-child comes out level with the baseline — that is the ruler failing, not the technique.
  5. That difference yields a free optimization: since the header only serves retrieval, keep it out of the context window. Leaving it in pays rent on every single query. Flipping that one switch in our lab freed 36 tokens inside a 600-token budget with every metric unchanged.
  6. The costs differ too. Parent-child costs index entries and a bigger context unit. Contextual retrieval costs one model call per chunk up front plus a permanently larger index. One is space; the other is time and space.
  7. Expect the follow-up 'why not both'. Look at the failure logs first: are you mostly seeing incomplete evidence, or nothing retrieved at all? Without the matching failure mode, neither is worth its price.

  答题要点

  • 父子索引作用在生成侧：检索单位是小块，上下文单位换成父块，解决『找到了但看不全』。
  • 上下文检索作用在检索侧：块头让块能被检索到，解决『看得全但找不到』。
  • 两者正交可叠加；块头只该进索引不该进上下文，否则每次查询都在为它付钱。
  • 父子索引的代价是索引条目与上下文单位变大；上下文检索的代价是一次性建索引调用加永久变大的索引。
  • 选哪个看失败案例：材料不完整选前者，压根没检索到选后者。

  Key points

  • Parent-child acts on the generation side: retrieve small, swap in the parent for context. It fixes 'found but unreadable'.
  • Contextual retrieval acts on the retrieval side: the header makes the chunk findable. It fixes 'readable but never found'.
  • They are orthogonal and compose; keep the header in the index only, never in the context window.
  • Parent-child costs more index entries and a larger context unit; contextual retrieval costs one call per chunk plus a permanently larger index.
  • Pick based on the observed failure: incomplete evidence points to the former, zero retrieval to the latter.