面试题库

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

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.

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

1. 这题的题眼在后半句。前半句网上到处都能抄到，能不能说清「什么时候不该用」才是区分度所在——只答前半句的人，多半没在真实语料上跑过。
2. 先给机制：向量检索比的是语义相似度，而用户的疑问句和文档里的制度条文在文体、句式、用词上都不同类。HyDE 先让模型编一段「长得像目标文档」的假文本，用它的向量去找邻居，等于把查询搬进了文档所在的那个语域。
3. 紧接着点破一个常见误解：这段假文本的**事实对不对根本不重要**，因为它不给用户看，只贡献一个向量方向。理解到这一层，才算真懂它为什么不怕模型瞎编。
4. 带偏有两种典型情况。一是模型编得太具体，给出语料里根本不存在的字段名或流程名，向量朝着一个不存在的方向去了；二是语料里压根没有答案，本该拒答的问题被编出来的假文档匹配到几个「看起来挺像」的邻居，拒答率掉下去、瞎编率涨上来。
5. 说完风险要给对策，这一步最见工程经验：门槛卡在**每一路检索器的原始分**上而不是融合分上（融合分是相对的，最不相干的一批也能拿最高分）；以及把假设文档当成**第二个检索式与原问题融合**，而不是直接替换原问题——替换在模型编歪时会把原问题的信号一起丢掉。
6. 可预期的追问是「它多花多少钱」。答：假设文档要写上百字，输出 token 是查询改写的十几倍，是查询侧四种手法里最贵的一次调用，而且检索次数翻倍。所以它通常不该默认打开，应该进 A/B 队列。

How to reason about it · think before answering

1. The tell is in the second half. Anyone can recite why HyDE works; only someone who has run it on real data can say when it hurts.
2. Give the mechanism first: dense retrieval compares semantic similarity, but a user's question and a policy paragraph differ in register, syntax and vocabulary. HyDE has the model draft a fake passage that looks like the target document, then retrieves with that vector — effectively moving the query into the documents' register.
3. Then kill the common misreading: the factual accuracy of the draft does not matter, because it is never shown to the user. It only contributes a direction in embedding space.
4. Two failure modes. The model invents an over-specific field or process name that does not exist in the corpus, and the vector chases something imaginary. Or the corpus genuinely has no answer, and the fabricated passage finds plausible-looking neighbours anyway — abstention rate drops and hallucination rate climbs.
5. Pair the risk with a mitigation: gate admission on each retriever's raw score, never on the fused score (fused scores are relative, so even the worst batch tops out at 1.0); and treat the hypothetical document as a second query fused with the original rather than a replacement, so a bad draft can only dilute the signal, not erase it.
6. Expect the follow-up on cost. The draft runs to a hundred-plus output tokens, an order of magnitude more than a rewrite, and it doubles retrieval calls. That is why it belongs in an A/B queue, not in the default config.