🔄 复习日 / Review Day
今天是复习日！回顾过去4天的内容。
📝 Quick Quiz — 3 Mini-Reviews
Pick 3 topics from 3 different sections.
Q1: [🏗️ System Design] 设计 URL Shortener 时，为什么「短链 → 长链」映射通常不能只放在单机内存里？如果你改成分布式缓存（如 Redis）+ 持久化数据库，你会如何处理：一致性、缓存穿透/击穿、以及读写高峰？
<details><summary>显示答案 / Show Answer</summary>
单机内存会成为单点故障且容量/扩展受限，一旦重启映射丢失会直接导致短链失效。常见做法是“缓存读为主、DB 为真源”：写入时先生成唯一 code（如雪花/号段/哈希+冲突处理），写 DB 成功后再写缓存；读取时走缓存未命中再查 DB 并回填缓存（cache-aside）。为防穿透可对不存在的短码做短 TTL 的 negative cache 或 Bloom Filter；为防击穿/热点可加互斥锁/请求合并、并对热点 key 做预热与更长 TTL；一致性上接受短暂不一致（最终一致）通常更划算，但要确保“写后读”路径可通过写穿/双写顺序与幂等更新降低概率。
</details>
Q2: [💻 Algorithms] 在「Permutation in String」里，用滑动窗口比较频次时，为什么很多实现会维护一个 matches（或 need）计数，而不是每次都比较 26 个字符计数？你需要小心哪些边界更新才能保证 matches 不出错？
<details><summary>显示答案 / Show Answer</summary>
</details>
Q3: [🤖 AI] 你在做一个基于 RAG 的问答系统：为什么单纯“把更多文档塞进向量库”往往不会让答案更好？请用 3 个维度说明（检索、生成、评估），并给出你会优先做的 2 个改进动作。
<details><summary>显示答案 / Show Answer</summary>
文档越多不等于命中率更高：检索层会面临噪声增大、相似度分数更难区分、以及 chunk 粒度/重叠不合理导致关键信息被切碎；生成层则会遇到上下文拥挤（有效信息被淹没）、模型对冲突信息无法仲裁、以及引用不稳定；评估层如果没有“可量化”的离线集与指标（如 answer correctness、citation faithfulness、latency），你很难知道到底是检索还是生成在拖后腿。优先改进通常是：① 做检索质量工程（更好的 chunking + metadata 过滤 + 关键词/向量混合检索 + reranker）；② 建立评估闭环（黄金问答集、自动评测+人工抽检），用数据驱动地迭代提示词、检索 top-k、与 rerank 策略。
</details>
💡 复习巩固记忆，螺旋式上升。
📅 明天继续新内容！