语义层：双重蒸馏
中段迷失效应：塞得越多越抓不住重点。动态 Few-Shot 从 4000 砍到 500，LLMLingua-2 压缩 5-20 倍
本页解决的问题
先给结论「语义层：双重蒸馏」要解决的关键问题是什么？
中段迷失效应：塞得越多越抓不住重点。动态 Few-Shot 从 4000 砍到 500，LLMLingua-2 压缩 5-20 倍
把成本看成形状，不是一个数字。 把一次请求拆成输入、输出、重试、工具和等待时间。使用量的形状，通常能告诉你是哪项设计选择最贵、哪里值得先改。
优化想象中的平均值之前，先测一次真实请求。
调用便宜了，却悄悄增加了重试、延迟或人工复核。
第一，贵而且慢。Transformer 自注意力的计算复杂度是 O(N²)：提示词长度翻倍，计算量翻四倍。提示词越长，Prefill 越久，首字延迟越高——用户还没看到第一个字，耐心已经消磨没了。
第二，效果可能更差。有效信息被废话淹没后，会产生「中段迷失」效应。就像人读长文章：开头认真看（要搞清楚讲什么），结尾也留意（快出结论了），中间那一大坨——眼睛扫过去，脑子没过去。你精心挑选的参考资料如果不幸落在中段，模型可能根本没认真看。
色条模拟模型对 Prompt 各位置的注意力强度（绿=强，灰=弱）。拖动长度，看中段怎么塌下去。
拿 Text-to-SQL 举例：为了覆盖各种业务场景，有人在 Prompt 里写死 20 个 SQL 案例，加起来 4,000 多 Token。每次用户提问，模型都要先「复习」一遍这 4,000 字，既烧 Token 又慢。换个思路：
把 20 个案例存进向量数据库。
用户问「上个月销售额」时，先用语义检索只捞 Top-3 个财务相关的案例。
最终 Prompt 从 4,000 Token 砍到 500。
（去掉了无关案例的干扰）
金融研报、会议纪要这类文档充满「正确的废话」：免责声明、重复的背景介绍、口语化垫话。直接喂给 AI，等于花大成本请博士生帮你读垃圾邮件。
解法是在 RAG 检索后、送去推理之前，插一层 LLMLingua-2 中间件。它不是粗暴砍词：用 BERT 的双向注意力同时看到上下文前后，精准识别核心语义（实体、数据、关键动词），剔掉冗余噪音。压缩 5–20 倍，原本 1 秒的预填充压完 50 毫秒搞定——高并发场景吞吐量直接上一个量级。
| 蒸馏 | 对象 | 手段 | 典型收益 |
|---|---|---|---|
| 第一重 | Few-Shot 案例 | 向量检索动态选 Top-K | 4,000 → 500 Token |
| 第二重 | 检索回来的文档 | LLMLingua-2 语义压缩 | 压缩 5–20 倍，预填充 1s → 50ms |
提示词翻倍 = 计算量翻四倍：O(N²) 是长上下文又贵又慢的物理根源。
中段迷失：关键信息放开头或结尾，中间留给丢了不心疼的内容。
Few-Shot 别硬编码，存向量库按问题动态检索：省 87.5% 还更准。
长文档先过 LLMLingua-2 再推理：高密度 Prompt 换高质量 Attention，别让用户在等待里流失。
内容来源：整理自作者团队内部分享《AI Token 降本增效策略分享》实战篇「02｜语义层」。中段迷失可延伸阅读 Chroma 的上下文腐烂（Context Rot）研究；压缩基准见 LLMLingua。上下文窗口原理复习Harness 核心 · 上下文窗口。
「垃圾桶式上下文的两宗罪」的完整成本怎么算
「第一，贵而且慢。」提醒我们，AI 成本不是单价乘一次调用这么简单。输入、输出、重试、工具调用、等待时间和人工收尾，会共同决定一次任务到底贵不贵。
先找出账单里不断重复的部分
「第二，效果可能更差。」对应的关键变量通常是上下文是否每轮重复发送、输出是否过长、失败是否触发重试，以及每次调用是否真的带来有用结果。减少无效 Token 往往同时降低费用、延迟和并发压力。
便宜的单次调用可能换来更贵的全流程
以「长文档先过 LLMLingua-2 再推理： 高密度 Prompt 换高质量 Attention，别让用户在等待里流失」为起点做一张小表：输入、输出、重试、工具和人工复核分别花了什么，再比较优化前后的质量，避免只看某一项价格。
从「垃圾桶式上下文的两宗罪」走到「交互演示 · 注意力是怎么被稀释的」
「垃圾桶式上下文的两宗罪」先把问题落在「第一，贵而且慢。 Transformer 自注意力的计算复杂度是 O(N²)：提示词长度翻倍，计算量翻四倍。提示词越长，Prefill 越久，首字延迟越高——用户还没看到第一个字，耐心已经消磨没了」上；到了「交互演示 · 注意力是怎么被稀释的」，讨论继续推进到「色条模拟模型对 Prompt 各位置的注意力强度（绿=强，灰=弱）。拖动长度，看中段怎么塌下去」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
分析成本时，先画出完整交互，再找每轮重复的输入、无效输出和失败重试；单次调用便宜，并不代表整个任务便宜。
- 「垃圾桶式上下文的两宗罪」：第一，贵而且慢。 Transformer 自注意力的计算复杂度是 O(N²)：提示词长度翻倍，计算量翻四倍。提示词越长，Prefill 越久，首字延迟越高——用户还没看到第一个字，耐心已经消磨没了
- 「交互演示 · 注意力是怎么被稀释的」：色条模拟模型对 Prompt 各位置的注意力强度（绿=强，灰=弱）。拖动长度，看中段怎么塌下去
- 「最后的要点」：提示词翻倍 = 计算量翻四倍： O(N²) 是长上下文又贵又慢的物理根源
最后的「最后的要点」把讨论落到「提示词翻倍 = 计算量翻四倍： O(N²) 是长上下文又贵又慢的物理根源」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。