面经策

如何优化过长的提示词？提示词压缩有哪些技巧？ ​

  • 标签：Prompt、提示词压缩

🏛 业务架构师 ​

优化过长提示词的技巧，我按"先诊断再优化"的顺序讲：

第一步·诊断冗余来源：上下文里通常堆着四类内容——系统提示、Few-shot 示例、检索文档、历史对话。先统计各部分 token 占比，找到大头（常见病：示例 20 条太多、检索文档灌了 10 篇、历史 50 轮没裁剪）。

压缩技巧按对象分：

  1. 系统提示瘦身：删掉不改变行为的"礼貌性废话"（"你是一个非常有帮助的助手"），合并重复约束；指令从"叙述文"改"清单化"——密度提升且模型遵循更稳；
  2. 示例精选：示例从数量转向质量——3 个覆盖典型+边界的示例，好过 15 个重复的；示例本身也要精简（只保留与任务相关的字段）；
  3. 检索内容压缩：只送与问题相关的段落（不整篇）；用小模型做"面向问题的摘要"后送入；去重合并（多个分块讲同一件事时合并表述）；
  4. 历史管理：滑动窗口+滚动摘要；工具返回结果限幅；
  5. 格式优化：JSON/结构化比自然语言描述省 token 且解析更稳；分隔符用短标记。

进阶手段：提示压缩工具（LLMLingua 类，token 级裁剪，可压 50%+ 但有信息损失风险——重要内容慎用）；把稳定的长前缀做 Prompt Caching（不减 token 但降费用）。

业务纪律：压缩是"有损换便宜"——压缩前后必须跑评测集对比效果，别为省 30% token 掉 10 个点准确率；把"提示词 token 预算"写进团队规范（如：系统提示 ≤800，检索内容 ≤3000），从源头防膨胀。

🏗 系统架构师 ​

提示词过长的问题我分诊断 → 压缩 → 架构化三步处理：

先诊断（哪段长、该不该长）：把 Prompt 分段打点——System Prompt / few-shot / 检索内容 / 历史，token 构成画像。通常发现：示例冗余（相似示例堆叠）、检索内容过量（塞了 10 个 chunk 用 3 个）、规则啰嗦（同一约束写三遍）。

压缩技巧（按 ROI 排序）：

  • 结构化改写：段落式规则改紧凑条目（"你需要非常仔细地检查…"→"校验：1. 格式 2. 数值范围"）——通常省 40% 无损；
  • few-shot 瘦身：示例从完整版改最小化版（只保留输入输出对，去掉解释）；3~5 个精选示例 > 10 个冗余示例；
  • 检索侧裁剪：Top-K 从 10 降到 3~5（配合 Rerank 保精度）、chunk 内要点抽取（每条先摘再进 Prompt）；
  • token 级压缩：LLMLingua 类工具自动删 token（压 1/4~1/2，需回归验证）；
  • 历史摘要：旧对话滚动摘要替换原文；
  • 缓存友好的架构化（成本视角）：稳定内容（系统规则、示例）放最前缀吃 Prompt Cache（命中省 50~90%），动态内容后置——"变短"和"变便宜"是两个杠杆，后者常被忽略。

上线纪律：压缩是有损操作——每次压缩跑回归集（准确率/格式合规率），省了 token 丢了效果是常见事故；关键约束白名单保护不压。

💻 全栈开发专家 ​

提示词太长的优化我分「结构治理」和「自动压缩」两手：

结构治理（治本，先做）：

  1. 模块化拆分：长 prompt 通常是多职责堆叠——拆成 system（角色/安全/格式）+ 动态注入（任务说明/领域知识按需加载），非必要模块不进上下文（参考 Skills 的渐进披露）；
  2. 删冗余：客气话、重复约束、过时的旧规则——我们审计过一份 6000 token 的 prompt，砍到 2200 token 效果不变：规则越多服从度越稀释，删比加有效；
  3. 要点化：段落改条目、条目压短句，同信息密度 token 省 40%；
  4. few-shot 精选：示例从 5 个砍到 2 个最代表的（一个正常+一个边界）。

自动压缩（LLMLingua，成本敏感场景）：

python
from llmlingua import PromptCompressor
pc = PromptCompressor("microsoft/llmlingua-2-xsmall")
out = pc.compress_prompt(long_context, rate=0.33)   # 压到 1/3

小模型给 token 打困惑度分，删「好猜」的冗余词——2~20 倍压缩，任务掉点很小。

内容级压缩：

  • 历史对话滚动摘要；工具结果摘要+落盘引用；
  • 检索文档只留最相关段落（rerank 后 top 精选，less is more）。

纪律：压缩必须配评测——每次压缩策略变更跑任务回归，省了 token 掉了准确率是负优化；「不可压缩区」（system 安全规则、任务目标、最近 2 轮）永远保原文。前置缓存配合：稳定部分放前面吃 prompt caching，压缩和缓存两手抓，成本能降 70%+。