5.4 性能优化与资源管理

账单来了

本节在实践章的第四站：场景跑通后，真正的账单来了。全册里前三章的闭环每轮都要调模型、抓网页、存向量，成本随步数线性涨。一个反问能点醒：同样一份周报，有人花 20 万 token，有人花 3 万，质量却差不多——差的不在模型，在资源管理。这一节给四种压成本手段，并诚实说清每种的副作用。

手段一：查询缓存与聚类。语义相近的查询合并，历史结果进向量库复用，不重复抓。副作用是可能用到过期结果，需带时效标签。手段二：早停。信息增益低于阈值（5.2 的 early_stop_gain）就结束，不凑满步数。副作用是可能漏边角证据，适合时效优先场景。手段三：分层摘要。长文先抽关键段再深入，不一次性喂全文。副作用是丢细节，适合概览类任务。手段四：模型蒸馏。把强模型策略蒸馏到小模型处理简单查询。副作用是复杂查询质量掉，需路由判断。

# 成本优化：查询聚类复用 + 早停 双管齐下
def should_stop(gain_history: list, threshold: float) -> bool:
    if len(gain_history) < 2:
        return False
    recent = gain_history[-3:]
    return all(g < threshold for g in recent)   # 连续低增益 停止

def dedup_query(new_q: str, cache: dict) -> str:
    # 简化：若新查询含缓存里的核心词 直接复用
    for key in cache:
        if key in new_q:
            return f"复用:{key}"
    return "新检索"

# 运行示例
gains = [0.3, 0.2, 0.04, 0.03, 0.02]
print(should_stop(gains, 0.05))        # True 连续低增益 该停
print(dedup_query("量子 药物 临床前", {"临床前": "已抓"}))   # 复用:临床前
​

运行输出 True 与 复用:临床前。第一段说明增益连续低于 0.05 就该停，避免无谓步数；第二段说明语义重叠的查询直接复用，省一次抓取加一次模型调用。两者叠加，token 能砍掉一大块。

我们主张：成本优化第一原则是"先测增益曲线，再定早停阈值"，不是拍个小数。阈值定太高（如 0.2）会过早停、漏证据；定太低（0.01）则省不下。用历史任务的增益分布定阈值，比凭感觉稳。这也和 3.2 的预算逻辑同源——资源约束要数据驱动。

分层摘要的实现关键在"先抽后读"。下面演示长文处理：只把关键段送模型，而非全文。

# 分层摘要：长文先抽关键段 再送模型 控 token
def layer_summary(full_text: str, key_sentences: list) -> str:
    kept = [s for s in key_sentences if s in full_text]
    return "摘要:" + " / ".join(kept[:3])    # 最多三段 控长度

long = "背景冗长... 核心发现是产能受限 ... 另一发现是成本偏高 ... 结尾套话"
print(layer_summary(long, ["产能受限", "成本偏高", "产能受限"]))
# 摘要:产能受限 / 成本偏高 / 产能受限
​

输出只保留关键句，长文被压成三段。若把全文喂模型，token 可能是十倍且重点被稀释。分层摘要是"保准确又控成本"的常用招，代价是细节可能漏——概览类任务可接受，精细类不行。

完整案例：背景→操作→结果→解读→变式

• 背景：某团队周报每篇 18 万 token，月账单惊人，且质量无优势。
• 操作：加 should_stop（阈值 0.05）+ dedup_query 聚类 + layer_summary 三段上限。
• 结果：单篇降至 4 万 token，降幅约 78%，按第四章综合分（4.5）几乎持平。
• 解读：省下的是重复抓取与全文吞吐，研究质量靠增益与关键段保住。
• 变式：若为监管报送（不容漏），则早停阈值降到 0.01、分层摘要改全文，成本换覆盖——取舍随场景，详见 5.3。

四种手段不是都要上，按场景选。概览类周报：早停加聚类足够，分层摘要可省（要全貌）；精细类尽调：分层摘要必开、早停阈值要低（不容漏）；高频类监控：查询聚类收益最大（同一问题天天问）；成本敏感类：蒸馏优先。选错手段反而伤：给精细尽调开早停，会漏关键证据；给概览开全文，浪费且稀释重点。手段组合是配置的一部分（呼应 5.2），应随场景在配置里声明，而非硬编码。

还有个隐性成本常被算漏：工程复杂度。每加一种优化，代码分支、测试、监控都变多。蒸馏要维护两套模型与路由，聚类要养向量库，早停要存增益历史。小团队若四种全上，维护成本可能超过省下的 token。我们主张先做"增益曲线分析"（本节 should_stop 的思路）量化每种手段的边际收益，只上边际为正且工程可负担的。优化是权衡，不是堆叠——和 3.2 预算逻辑一脉相承。

优化还要防"边际为负"。早停阈值太低，省了 token 却漏关键证据，下游用错结论的损失远大于省的钱；聚类太激进，把不同查询硬并，结果答非所问。所以每次加优化，都要用第四章综合分（4.5）量化"省了多少成本、掉了多少质量"，比值不正就不上。我们主张建一张"优化账本"：每行记手段、预计节省、实测质量变化、是否保留。账本让优化从拍脑袋变可核算，也避免"为省而省"。

最后落到组织：优化决策应谁拍板？不是工程独断，要拉业务——省下的 token 是工程的，漏掉的证据风险是业务的。双方对着优化账本谈，才能定阈值。这又把技术取舍拉回"场景与责任"（呼应 5.3、第六章），优化不是纯技术问题。

蒸馏这招值得单说。把强模型的研究策略（如"先找矛盾再补搜"）用大量轨迹蒸馏到小模型，简单查询交给小模型，省下大模型调用。但蒸馏有"能力天花板"：复杂多跳、强矛盾的任务，小模型会掉链。所以路由要准——用 3.5 的上下文策略类似思路，按查询复杂度分流。我们见过团队蒸馏过度，结果长链任务全错，省的钱不够赔。蒸馏的正确姿势是"只蒸馏简单部分"，而非"全盘换小"，边界由实测质量（4.5）划定，不靠想象。优化账本上应单独记一行"蒸馏后难任务质量"，让它永远可见，不被平均收益掩盖。

5.5 看这些优化与部署里，必然撞上的墙怎么翻。