10. 面试题

14 道题，分初级（概念）、中级（工程权衡）、高级（系统设计）三档。参考答案均可在本主题章节中找到出处。

初级

Q1. 什么是"答案引擎"？它和传统搜索引擎、聊天机器人的本质区别是什么？

参考：传统搜索引擎返回链接列表（把评估负担交给用户），聊天机器人生成无出处的自由文本（信任负担来自模型本身）；答案引擎直接生成带来源引用的答案，把"找到信息"和"信息可信"合为一步。Perplexity 2023 年以此定义新品类。引用（citation）既是信任机制，也是审计日志与版权谈判的筹码（背景、核心思想）。

Q2. Perplexity 为什么不训练基础模型？它如何回应"套壳（wrapper）"的批评？

参考：创始团队约 8 人起步，资金与人才都不支持预训练；战略上选择把资源投向推理经济学与产品速度【访谈】。对"套壳"的回应有三层：自建爬虫与索引（"抓取是域名知识密集的工作"）【访谈】、自研 Sonar 后训练模型、自建检索/存储/沙箱基建（Photon/CobbleDB/SPACE）。权重不自有 ≠ 没有模型工程（核心思想、核心模块）。

Q3. TTFT 和吞吐有什么区别？为什么答案引擎更关注 TTFT？

参考：TTFT 是首 token 延迟，决定用户多快看到第一个字；吞吐是解码速度，决定整段多快读完。流式渲染下用户感知延迟 ≈ TTFT + 读前几十个 token 的时间，与答案总长解耦；搜索用户大多只读开头，本主题 Mini Demo 中"读 100 token"场景 TTFT 占感知延迟 64%（核心思想 2.2、Mini Demo 场景 3）。

Q4. 什么是 tail latency（尾延迟）哲学？为什么看均值不够？

参考：对每一层（搜索、LLM）追踪 P90/P99 而非均值，思想借自 Google "The Tail at Scale"【访谈】。答案引擎一次查询串行经过多个环节，端到端 p99 由最慢环节主导；均值会掩盖缓存失效、索引合并、慢副本等长尾事件——Photon 旧系统就是在索引合并期间 p99 飙到 1.2 s（核心思想、核心模块 5.1）。

Q5. Sonar 模型是怎么做出来的？

参考：以 Llama 3 系列为基座做后训练（非预训练），训练目标是摘要、引用生成、上下文保持等 RAG 推理技能【访谈】；Cerebras 版 Sonar 基于 Llama 3.3 70B，官方口径约 1200 token/s【一手公告】。2026-09 起 Sonar API 退役，由 Agent API 的 presets 承接（核心模块 5.3）。

中级

Q6. 设计一个"按查询复杂度做模型路由"的系统，你会怎么建模成本与质量的权衡？

参考：三步：（1）为每档模型建质量曲线——质量随查询复杂度偏离该档最优点的距离衰减；（2）估计查询复杂度（启发式或分类器）；（3）策略取"满足质量下限的最便宜档"，无下限则取质量/成本性价比最高档。教学模型显示该策略可同时优于"全大模型"（便宜 10.9 倍且质量更高）与"全小模型"。生产版要把权衡暴露成产品档位（Agent API 的 fast/low/high/xhigh）（Mini Demo 场景 1、核心模块 5.7）。

Q7. exact 缓存与语义缓存各自的失效模式是什么？答案引擎的缓存有什么特殊约束？

参考：exact 缓存 miss 于同义改写（"原理是什么" vs "是什么原理"），语义缓存则有两个失效模式：阈值过低召回错误答案（不同问题共享词面）、阈值过高形同虚设。答案引擎的特殊约束是时效性分级 TTL——新闻类查询缓存几分钟就陈旧，百科类可缓存很久；与 Photon"高时效垂直领域个位数分钟入库"配合（核心模块 5.4、Mini Demo 场景 2）。

Q8. Photon 把检索 p99 从 800 ms 压到 65 ms，主要靠哪三类技术？各自解决什么问题？

参考：（1）数据表示——按 posting list 长度选编码（inline/偏移数组/bitmap）、Elias-Fano 文档记录、按有用度排序，解决"每文档数据膨胀 2.5 倍但内存有限"；（2）遍历与剪枝——WAND 式 driving/probe 双角色 + 上界剪枝，解决多词查询打分成本；（3）I/O 与缓存——io_uring 批量异步读、无锁缓存 + CLOCK 驱逐 + 预取，解决 RAM 装不下后的 page fault 与磁盘等待。另有架构前提：构建/查询节点分离，索引合并不再影响在线流量【一手：Photon 博客】（核心模块 5.1）。

Q9. CobbleDB 为什么敢放弃事务与强一致？hedged reads 解决了什么问题？

参考：它服务的是搜索热读路径——网页段落与 embedding 的批量读，业务本身容忍短暂不一致与重复，强一致是纯开销。hedged reads：当某个副本响应慢时并行向另一副本发同样的读，用一点冗余读流量换掉尾延迟；配合可用区亲和路由避免跨区毫秒级惩罚。实测 batch read 中位数 31.4 → 5.6 ms、p99 123 → 24.2 ms【一手】（核心模块 5.2）。

Q10. 流式渲染如何改变延迟优化的优先级？给一个量化结论。

参考：流式把"等待整段"变成"等待第一个词元"，感知延迟与答案长度解耦。量化（教学模型，400 token 答案）：1200 tok/s 档非流式 0.48 s、流式读前 100 token 仅 0.23 s（2.07 倍）；且 TTFT 占感知延迟 64.3%，TTFT +10% 的伤害大于吞吐 −10%。结论：面向搜索类负载优先砸 TTFT（检索预热、KV 缓存、小模型先行、投机解码），吞吐其次（Mini Demo 场景 3）。

高级

Q11. 设计一个日查询 10 亿次的答案引擎，给出端到端延迟预算与容量规划方法。

参考：延迟预算按 p99 逐层分配：路由/缓存 <10 ms、检索 <100 ms（对标 Photon 65 ms）、重排 <50 ms、生成 TTFT <200 ms、首屏渲染在 TTFT 后 100 ms 内——端到端首屏 p99 目标 500 ms 量级。容量：按 QPS × 每层单请求成本（检索 CPU 核时、生成 GPU 秒、存储 IOPS）折算各层机器数；生成侧按模型档位分池，快档保 TTFT（专属硬件）、重档走批量容量。缓存命中率与路由分布直接进容量公式：命中率每升 10%，生成池需求近似线性下降。瓶颈永远跟着 p99 走（工作流程 4.3、Mini Demo 场景 5）。

Q12. 同时接入多家模型供应商（GPT/Claude/Gemini/Grok/自研），网关层需要哪些机制来管理"合作者即竞争者"的风险？

参考：四层机制：（1）可替换性——统一接口抽象，任何供应商可摘除，自研 Sonar 作为兜底池；（2）显式路由与 fallback——按档位/成本/健康度调度，供应商故障自动切换（官方文档公开 model fallback）；（3）观测中立——质量与延迟按供应商分别度量，防止"默认走某家"的惰性锁定；（4）容量对冲——关键档位保持至少两个供应源，自推理容量覆盖头部查询。商业层注意投资/供应交叉关系（NVIDIA/Google 既是股东又是供应商）（生产实践 8.2、生态 6.4）。

Q13. Agent 产品（如 Computer）为什么必须自建沙箱而不是用商业方案？SPACE 的关键设计有哪些？

参考：必要性：Agent 安全是产品可信度的根，且规模上来后商业方案的成本与弹性不可控（SPACE 披露前供应商方案创建慢 3–5 倍）。关键设计【一手】：VM 级隔离（非容器级）、默认不信任沙箱（网络与凭证由沙箱外管理）、快照存"变更"使创建/恢复/分支廉价（支撑暂停等人审 → 恢复的长任务）、控制平面统一管理生命周期；对抗流程上 108 次逃逸尝试全失败、修复后复测并向同行披露。可复用要点：凭证永远不进 Agent 环境，逃逸测试常态化（架构 3.4、生产实践 8.4）。

Q14. 从基础设施视角评价 Perplexity 与 Google（AI Overviews）、OpenAI（ChatGPT Search）的竞争：各自的结构性优势与包袱是什么？

参考：Perplexity——优势：无旧广告盘包袱、全栈为低延迟答案而建、基建透明可快速迭代；包袱：版权诉讼未决、无自有分发入口（依赖浏览器/应用下载）、无最强模型。Google——优势：索引、分发、广告盘与 TPU 全链；包袱：生成答案会蚕食点击广告收入，组织上搜索与 AI 两条线互搏。OpenAI——优势：会话入口与用户习惯；包袱：搜索引用质量与新鲜度、同样的训练/推理成本压力。终局变量：版权边界 + Agent 是否成为新搜索入口（生产实践 8.6）。