7. Mini Demo：答案引擎推理经济学
本主题的 Mini Demo 是一个纯 Python + numpy、CPU 可运行、完全确定性的模拟包 perplexity_case_mini，位于本主题的 mini-demo/ 目录（代码路径引用：docs/09-case-study/perplexity/mini-demo/）。它把 Perplexity 案例里最值得动手验证的四组权衡做成可运行的模型：
| 模块 | 模拟的权衡 | 对应章节 |
|---|---|---|
routing.py | 按查询复杂度选择大/小模型：成本-质量权衡曲线与阈值路由 | 2.1 推理经济学 |
caching.py | exact + 语义缓存的命中率与成本节省 | 5.4 缓存层 |
streaming.py | TTFT 与流式渲染对用户感知延迟的影响模型 | 2.2 速度即产品 |
rerank.py | 检索-重排-生成流水线中重排层的效果/延迟权衡 | 4. 工作流程 |
demo.py | 5 个端到端场景 | 本章 |
运行方式
cd docs/09-case-study/perplexity/mini-demo
pip install -e ".[dev]"
pytest tests/ -v # 48 个确定性测试
python -m perplexity_case_mini.demo下文所有数字均来自 demo 的实际输出（确定性，可复现）。所有模型参数为教学用的简化值（参照公开口径的相对量级），不代表 Perplexity 真实内部数字。
场景 1：成本-质量帕累托——路由为什么必须存在
核心代码（routing.py）：三档模型各有"最优复杂度"与质量衰减曲线，estimate_complexity 用确定性启发式（长度 + 任务词）估计查询复杂度，route 执行"满足质量下限的最便宜档"策略。
实测输出（1000 条确定性混合复杂度查询流：50% 简单 / 30% 中等 / 20% 复杂）：
全走小模型: 成本 $1.00, 平均质量 0.6271, 分发 {'small(Sonar 档)': 1000}
全走大模型: 成本 $30.00, 平均质量 0.6426, 分发 {'large(Reasoning 档)': 1000}
阈值路由(质量下限 0.62): 成本 $2.75, 平均质量 0.7121,
分发 {'small(Sonar 档)': 650, 'medium(Sonar Pro 档)': 350}三个读数的方法论意义：阈值路由同时打败了两种极端——比"全走大模型"便宜 10.9 倍且质量更高（0.7121 vs 0.6426，因为每类查询都落在擅长它的档位上）；比"全走小模型"贵 2.75 倍但质量提升 0.085（650 条简单查询仍由小模型承接）。这就是 Perplexity"模型无关 + 按复杂度调度"的产品形态在成本公式里的样子；Agent API 的 fast/low/high/xhigh 预设（5.7）是把同样的权衡暴露成产品参数。
场景 2：缓存收益——毛利率的隐藏杠杆
核心代码（caching.py）：规范化串的 exact 缓存 + 词袋向量余弦（≥ 0.85）的语义缓存，TTL 过期。查询流刻意构造为 40% 精确重复 + 20% 同义改写（"vllm pagedattention 分页 注意力 原理" vs 追加"解释"，余弦 0.9129）。
实测输出（600 条查询流，单次生成成本 $0.004）：
查询总数 600: exact 命中 414，语义命中 180，未命中 6
exact 命中率 69.00%，语义命中率 30.00%，总命中率 99.00%
成本 $0.02（无缓存基线 $2.40），节省 99.00%两个工程读数：语义缓存把"同义改写"从 miss 变成 hit（180 次），但召回必须设阈值——本例中模板间余弦为 0，阈值 0.85 刚好只召回真改写；真实系统里语义缓存的精度/召回权衡要严格得多，且新闻类查询的 TTL 必须按类别分级（5.4）。99% 节省来自刻意构造的高重复负载，真实流量中该数字会低得多——数量级意义大于数值意义。
场景 3：流式感知延迟——TTFT 才是用户感知的全部
核心代码（streaming.py）：感知延迟 = TTFT + 读完前 k 个 token 的时间；非流式 = 等整段生成完。
实测输出（400 token 答案）：
Sonar 档(1200 tok/s): 非流式整段 0.48s，流式读到 100 token 0.23s，
感知加速 2.07x，TTFT 占整段 31.03%
Reasoning 档(150 tok/s): 非流式整段 3.57s，流式读到 100 token 1.57s，
感知加速 2.28x，TTFT 占整段 25.23%
敏感性(Sonar 档, 读 100 token): 基线 0.2333s，TTFT+10% -> 0.2483s，
吞吐-10% -> 0.2417s，TTFT 占比 64.29%关键读数：流式把 400 token 答案的感知延迟砍半以上，且用户读得越少，TTFT 占比越高——只读前 100 token 时 TTFT 占 64.3%，扰动敏感性也更高（TTFT +10% 比吞吐 −10% 伤害更大）。这就是 2.2 说的"TTFT 与吞吐是两个指标"的定量形式：面向搜索场景（用户只读开头），优化 TTFT 的边际收益约为优化吞吐的 1.4 倍（0.015/0.0075... 由敏感性输出可直接对比）。
场景 4：重排层效果与延迟权衡
核心代码（rerank.py）：24 文档固定种子合成语料；一阶段检索按高噪声（0.45）相关性估计取 top-k，二阶段重排用低噪声（0.05）重估；NDCG@5 与延迟（检索基线 65 ms + 每候选 2 ms）同时计量。
实测输出：
不重排(top-5 直接截断): NDCG@5=0.8777，延迟 65ms
重排(召回 24 -> 截 5): NDCG@5=0.9985，延迟 113ms
候选池 5: NDCG@5=0.9134，延迟 75ms
候选池 8: NDCG@5=0.9884，延迟 81ms
候选池 12: NDCG@5=0.9985，延迟 89ms
候选池 16: NDCG@5=0.9985，延迟 97ms
候选池 24: NDCG@5=0.9985，延迟 113ms读数：重排把 NDCG@5 从 0.8777 提到 0.9985（代价 +48 ms）；但候选池存在收益饱和点——池子从 12 扩到 24，质量一分不涨、延迟线性 +24 ms。生产含义：候选池大小应该由质量-延迟曲线拐点定（本模型 12），而不是越大越好；Photon 的 driving/probe 双角色与上界剪枝，本质就是在不扩大物理候选池的前提下扩大有效召回（5.1）。
场景 5：一次查询的生命线
端到端延迟分解（教学预算，与 4.3 的预算表一致）：
查询理解与路由 5 ms
缓存查询(exact+语义) 2 ms
检索召回(Photon 量级 p99) 65 ms
重排(top-24) 48 ms
首次生成 TTFT(Sonar) 150 ms
流式解码 300 token @1200 tok/s 250 ms
引用渲染与后处理 30 ms
合计 550 ms
推理经济学：混合策略 $4.30/千次，全大模型基线 $30.00/千次，节省 85.7%这张总账把四个模块串成一句话：检索层（65 ms 公开口径）已经快到任何"省检索"的优化都不如"让生成别拖后腿"值钱——TTFT + 解码合计 400 ms，占端到端预算的 73%；成本侧路由 + 缓存 + 重排的混合策略比无脑全大模型便宜 85.7%（教学参数）。
测试
pytest tests/ -v：48 个测试全部通过（routing 13、caching 10、streaming 8、rerank 11、demo 6）。所有测试断言具体数值（如 expected_quality(0.25) == 0.72、流式加速 2.07x、候选池 24 的 NDCG 0.9985 与 113 ms 延迟、场景 5 各阶段之和恰为 550 ms），保证模型行为与本文数字一致。
小结
- 场景 1 证明：按复杂度路由可以用 1/10 的成本超过"全大模型"的质量——前提是质量曲线按档位建模。
- 场景 2 证明：exact + 语义缓存是毛利率的隐藏杠杆，语义阈值与 TTL 分级是设计核心。
- 场景 3 证明：流式把感知延迟砍半，且用户读得越少，TTFT 越是要命指标（占比 64%）。
- 场景 4 证明：重排候选池有收益饱和点，应由质量-延迟拐点而非"越大越好"决定。
- 场景 5 证明：端到端预算中生成侧占大头——检索基建的"快"只有与生成侧的"省"配合，推理经济学才成立。