面经库最初只是内容展示页。真正接入模拟面试时，需要解决三个问题：如何识别主问题与追问链、如何从大量问题中找到相关候选、如何把召回结果改写成适合当前候选人的问题。

从原始帖子到问题链

入库阶段先把帖子拆成问题组，并标注：

  • main、follow_up 等问题角色；
  • clarify、deepen、compare 等追问意图；
  • generic 或 experience_anchored 的锚定方式；
  • 规范化问题、知识点和 embedding。

项目经历型问题不能直接套给另一个候选人，因此 experience_anchored 追问会结合当前简历重新改写措辞，同时保持原考察点不变。

embedding 与图谱各自解决什么

embedding 擅长寻找语义相似的问题，例如“LCP 优化”和“怎么提升首屏加载速度”。但它不天然知道 LCP、FCP、CLS 在性能知识结构中的邻接关系。

知识图谱承担补充关系：从命中的知识点出发，沿父子与共现边展开，再参与候选重排。召回链路因此被设计为：

  1. embedding 找到语义候选；
  2. 图谱扩展关联知识点；
  3. 根据知识边界与追问意图排序；
  4. 对项目型问题做上下文适配。

对于小规模面经库，embedding 可以直接驻留内存并进行余弦遍历，不必为了形式完整提前引入向量数据库。

为什么后来收缩了检索范围

这套能力确实实现过，但提交 ce41d27 随后从面试主流程删除了通用 evidence retrieval 与 Sirchmunk pipeline，共删除约 2500 行相关代码和文档。每轮回答不再额外检索候选人资料与外部知识证据，也不再把召回结果送入评分链路。

原因不是“检索没有价值”，而是面试主链路同时承担评分、追问、流式输出、上下文和容错。继续叠加外部检索会增加延迟、失败点和调试复杂度，收益却还没有被独立评估证明。

这次删除并没有取消题库内的追问复用。当前流程仍会从主问题携带的 _follow_up_chain 中，根据候选人回答暴露出的知识边界选择追问；如果是项目经历型问题，还会结合当前简历改写措辞。知识图谱也继续用于面经整理和关系维护。退出关键路径的是“每轮都做一次通用证据检索”，而不是整个面经能力。

能做与应该做

这次收缩让我意识到，架构设计不能只展示新增了多少能力。关键路径上的每一层都需要回答：它带来的质量增益，是否值得延迟、成本与故障面的增加？

实现之后再删除不是白费。它明确了模块边界，也让后续重新接入必须先通过独立评估，而不是因为“已经有检索系统”就自动进入主流程。