llm-token-optimizerlisted

# LLM Token 优化器 在**效果不明显下降**的前提下，系统性减少大模型应用的无效 Token 消耗。 适用两类场景： 1. **工程审计**：已有 LLM 应用（客服、判责、告警降噪、RAG、Agent），找浪费点并出改造方案 2. **方案设计**：Hackathon / 立项文档，输出「问题理解 → 创新解法 → 创造价值」 ## 核心能力 - 识别 6 类 Token 浪费根因并量化 - 按「路由 → 上下文 → Prompt → 模型 → 输出 → 缓存」六层给出改造清单 - 结合 error-triage 等实战经验，输出可迁移的工程模式 - 给出 Before/After 指标与验证计划（eval 驱动，不靠感觉砍 prompt） ## 工作流程 ### Step 0: 确认输入（缺了就问） 向用户确认： | 项 | 说明 | |---|---| | **场景** | 工程审计 / Hackathon 提案 / 两者都要 | | **目标系统** | 应用名、链路描述、或贴代码/Prompt/架构 | | **约束** | 准确率下限、延迟要求、能否改模型、能否加缓存 | | **现状数据** | 单次 input/output token、日调用量、月成本（有则精算，无则估） | 若用户只给赛题描述、没有具体系统 → 走 **Hackathon 模式**（Step 5）。 若有具体代码/Prompt → 走 **审计模式**（Step 1–4）。 --- ### Step 1: Token 浪费诊断（6 类根因） 逐条扫描当前链路，标注浪费类型与严重度（高/中/低）： | # | 浪费类型 | 识别信号 | 典型浪费占比 | |---|---|---|---| | 1 | **上下文过长** | 整段历史、整库文档、无关字段全塞入 | 30–60% | | 2 | **Prompt 冗余** | system prompt 重复规则、过长范例、全量加载 | 15–30% | | 3 | **RAG 不精准** | 召回 chunk 过长、无关文档、未做摘要分层 | 20–40% | | 4 | **模型路由不当** | 简单分类/抽取也上大模型 | 40–70% 成本 | | 5 | **输出不受控** | reason 过长、未约束 JSON、多余 markdown | 10–25% | | 6 | **失败重试** | 工具调用失败、解析失败反复重调 | 视失败率 | **诊断输出**：每张浪费类型填「现状 → 证据 → 严重度 → 改造方向」。 --- ### Step 2: 六层优化框架（Tiered Token Governance） 按优先级从「零风险」到「需 eval 验证」排列改造项： ``` 请求 → ①路由层 → ②上下文层 → ③Prompt层 → ④模型层 → ⑤输出层 → ⑥缓存层 ``` #### ① 路由层（Router First）— 最高 ROI **原则**：先分类，再决定「要不要 LLM、用哪套 Prompt、用哪个模型」。 | 手段 | 做法 | 参考模式 | |---|---|---| | 规则/前缀路由 | pathname、关键词、错误码先走确定性逻辑 | `error-triage/router.js`：pathname 归一 → 归属判别 → 有序规则 | | 轻量分类器 | 小模型或 embedding 做意图/复杂度分类 |