语义层：双重蒸馏

Token 降本增效 · 10 / 13 语义层：双重蒸馏格式的税砍完了，往深一层看内容本身。RAG 和长文档场景里最常见的工程错误：把上下文窗口当垃圾桶——Few-Shot 案例、检索文档全怼进去，让模型自己辨识。能用，但不该这样用。 O(N²) 中段迷失动态 Few-Shot LLMLingua-2 一句话速览中段迷失效应：塞得越多越抓不住重点。动态 Few-Shot 从 4000 砍到 500，LLMLingua-2 压缩 5-20 倍垃圾桶式上下文的两宗罪第一，贵而且慢。 Transformer 自注意力的计算复杂度是 O(N²)：提示词长度翻倍，计算量翻四倍。提示词越长，Prefill 越久，首字延迟越高——用户还没看到第一个字，耐心已经消磨没了。第二，效果可能更差。有效信息被废话淹没后，会产生「中段迷失」效应。就像人读长文章：开头认真看（要搞清楚讲什么），结尾也留意（快出结论了），中间那一大坨——眼睛扫过去，脑子没过去。你精心挑选的参考资料如果不幸落在中段，模型可能根本没认真看。

交互演示 · 注意力是怎么被稀释的色条模拟模型对 Prompt 各位置的注意力强度（绿=强，灰=弱）。拖动长度，看中段怎么塌下去。

Prompt 长度

6k Tokens

开头中段结尾

上下文不是越多越好。关键信息要么放开头，要么放结尾；中间的位置，留给「丢了也不心疼」的内容。

策略一 · 动态 Few-Shot，别硬编码拿 Text-to-SQL 举例：为了覆盖各种业务场景，有人在 Prompt 里写死 20 个 SQL 案例，加起来 4,000 多 Token。每次用户提问，模型都要先「复习」一遍这 4,000 字，既烧 Token 又慢。换个思路：

1 把 20 个案例存进向量数据库。 2 用户问「上个月销售额」时，先用语义检索只捞 Top-3 个财务相关的案例。 3 最终 Prompt 从 4,000 Token 砍到 500 。

-87.5% Token 成本 3x+ 响应速度更高 SQL 准确率（去掉了无关案例的干扰）

策略二 · 长文档先压缩再喂金融研报、会议纪要这类文档充满「正确的废话」：免责声明、重复的背景介绍、口语化垫话。直接喂给 AI，等于花大成本请博士生帮你读垃圾邮件。解法是在 RAG 检索后、送去推理之前，插一层 LLMLingua-2 中间件。它不是粗暴砍词：用 BERT 的双向注意力同时看到上下文前后，精准识别核心语义（实体、数据、关键动词），剔掉冗余噪音。压缩 5–20 倍，原本 1 秒的预填充压完 50 毫秒搞定 ——高并发场景吞吐量直接上一个量级。

动态 Few-Shot + 文档压缩，两道漏斗滤掉噪音：高密度的 Prompt 才能换来高质量的 Attention。（图：作者分享原稿）

蒸馏对象手段典型收益第一重 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 核心 · 上下文窗口。