00 使用说明与阅读路线（先看这篇）

本目录是为字节跳动面试准备的 BinRag（docs-rag）项目面试材料。 所有内容基于当前仓库源码逐行核对，带行号的技术事实可以直接在 IDE 里跳转验证。 一条纪律贯穿全篇：代码里有的数字照实说，代码里没有的效果数字一律不编——面试官一追问测试方法就会穿帮，而"我没测但我能设计测法"是完全可接受的答案。

---

一、文件清单与用途

文件	对应简历 bullet	用途	优先级
01-项目口述介绍.md	全部	30 秒 / 2 分钟 / 5 分钟口述稿 + vibe coding 怎么坦白 + 12 个数字卡 + 雷区清单	⭐⭐⭐ 必读必背
02-入库链路深挖问答.md	② 完整文档处理管道	17 个 Q：同步/异步边界、多格式解析、扫描件拒绝、三种分块、chunk_id 与幂等、worker 原子认领、退避、重启恢复、PG↔Qdrant 一致性	⭐⭐⭐
03-检索与重排深挖问答.md	① 混合检索与精排	16 个 Q：BM25 公式与自研实现、中文 bigram、RRF 与量纲、cross-encoder、多租户隔离、BM25 重启失效 / BM25 独有命中无正文 / 无 oversample 三个真实缺陷	⭐⭐⭐ 深挖主战场
04-LLM问答链路深挖问答.md	③ LLM 问答链路	23 个 Q：Query 改写、上下文 token 预算与截断顺序、prompt 原文、SSE 事件序列与断连、多查询/分解/Step-Back/HyDE/路由、增强模式工具循环	⭐⭐⭐
05-MCP-Server深挖问答.md	④ MCP Server 接口	16 个 Q：MCP 协议与 streamable HTTP、6 个 Tool 逐个、401 与 -32001 分层、双层开关、审计、owner 解析 fail-open、默认不限流	⭐⭐
06-认证权限与多租户深挖问答.md	OIDC 登录 / API Key	认证双通道、API Key 哈希存储、OIDC/GitHub 流程、JWT 缺陷、跨租户越权面、安全自查清单	⭐⭐⭐（字节安全面必问）
07-工程化部署与评估深挖问答.md	双形态部署 / RAG 评估	单二进制 + Wails、Docker/CI、配置系统、评估体系（Recall@K + LLM-as-Judge + RAGAS 服务）、可观测性缺口	⭐⭐⭐
08-压力面-量化指标与反问.md	—	效果/容量/对比/自我批判类逼问的标准答法、白板手撕关联题、反问清单、收尾话术	⭐⭐⭐ 必读
09-口袋速背卡片.md	—	一页速背：主线口述 + 数字卡 + 十个必答 + 六个缺陷 + 三个反问	⭐⭐⭐ 考前只看这个

---

二、3 天冲刺路线（按这个顺序）

Day 1 — 建立主干（约 3 小时）

1. 读 01，把「30 秒版」和「2 分钟版」念出来录音，听哪里卡壳。
2. 读 01 第六节（vibe coding 话术）——这一段决定面试的基调，要能自然说出口。
3. 背 01 第七节的 12 个数字。
4. 读 08 第一~三节（数字库存 + 效果/容量答法）。

Day 2 — 深挖三块硬骨头（约 4 小时） 5. 精读 03（检索）：重点 Q1、Q4（RRF）、Q8（BM25 独有命中无正文）、Q9（BM25 重启失效）、Q11（无 oversample）。这五个是主动加分点。 6. 精读 02（入库）与 04（问答）：每篇至少把「30 秒总述 + 五个最可能被问的 Q」背下来。 7. 读 05、06、07 的「30 秒总述 + 不足与改进表」——安全和评估是字节最看重的两块，不必逐题死背，但要能讲清机制。

Day 3 — 模拟与收口（约 3 小时） 8. 对着白板默画 09 第八节的架构图并同步讲 5 分钟。 9. 找人（或自问自答）随机念简历的一条 bullet，即时展开 60 秒。 10. 只读 09，把「六个缺陷」的"一句缺陷 + 一句影响 + 一句修法"练到脱口而出。 11. 睡前读 08 第九节速查表。

---

三、这个项目的三个"记忆锚点"（面试全程反复用）

如果只让你记三件事，记这三件：

1. 量纲不可比 → 所以用 RRF：余弦相似度 0~1、BM25 无上界，加权求和必须先归一化、而归一化假设不成立；RRF 只用排名，天然可比，且双路命中自动上位。
2. BM25 重启静默失效：内存索引无持久化、启动无回灌 → DocCount()>0 门控整路跳过 → 混合检索悄悄退化成纯向量。主动承认它，比被问出来强一百倍。
3. 重排候选池 = topK（没有 oversample）：等于把漏斗的下半截砍了，重排只能改排序、救不了召回。这是最容易被面试官认可的"你懂 RAG 工程"的判断。

---

四、答不上来时的三条保命话术

1. 效果数字类："我没有可信的基线，所以不编数字——但我可以说清评估怎么设计、瓶颈在哪。"
2. 质疑 AI 生成类："是 AI 辅助。我先写 spec 和可验证的 checklist，做过一次全量 review 修掉 6 个 P0 + 十几项 P1；有些模块我只做到行为验证，比如 ffmpeg 抽帧和 Wails 打包。"
3. 真不会的细节："这一层我没做到源码级——我知道的边界是 X，回去我会先看 Y。（绝不硬编）"

---

五、材料的事实边界（避免你误用）

• 所有技术机制、常量、默认值、行号均来自当前仓库源码核对，可以放心引用。
• 没有真实用户、没有线上流量、没有压测数据、没有大规模标注评测集——08 第一节把这些列为"B 类数字"，任何场景都不要编造。
• 评估框架（cmd/eval + Python RAGAS 服务）已落地可跑，但基线尚未跑完；并且 Go 侧评估 CLI 因为 BM25 未回灌，实际只测到了纯向量检索路径——这一点在 03 Q9 和 07 里都标注了，被问到要主动说。
• 引用行号对应的是生成这批材料时的代码版本（docs/34-review-p1-fix 之后的版本）；如果之后又改了代码，行号可能漂移，面试前建议抽查几处。