> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/context_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/context_engineering_guide/di-si-bu-fen-gong-cheng-shi-zhan-yu-wei-lai-yan-jin/12_production/12.2_optimization/12.2.8_cost_optimization_industry.md).

# 12.2.8 成本优化的具体行业数据

## 12.2.8.1 引言：从通用到行业特化的成本优化

上一节讨论了通用的成本建模框架。但在实际应用中，不同行业的 **上下文工程成本结构** 差异巨大。金融合规、医疗诊断、法律审查、客服对话——每个行业都有独特的上下文需求和成本特征。

本节用四个典型行业的 **教学测算** 说明成本优化方法，帮助您理解如何在自己的行业背景中有效控制成本。除非特别注明，下面的公司、价格、命中率、节省比例、ROI 和质量指标均为示例假设，不应当作为真实行业统计或当前厂商报价引用。

> 价格核验原则：模型单价、缓存折扣、长上下文溢价、区域处理溢价和服务层级会频繁变化。做生产预算时，请在方案中记录查询日期、模型 ID、价格页链接、输入/输出 token 单价、缓存命中率假设和本地压测结果。

## 12.2.8.2 金融行业：合规文档处理的上下文成本

### 典型场景：金融行业

金融机构需要处理海量的合规文档：

* 监管指南和法规（每年新增 500+份）
* 内部政策和流程手册（500 - 1000 份，频繁更新）
* 风险审查和合规检查清单（高频使用）
* 客户交易记录和合同（海量）
* 市场研究和投资建议（日级更新）

### 示例测算：某证券公司的合规助手

```
系统概况：
- 目标：为 5000名员工提供合规查询和指导
- 月均查询：50000次
- 平均查询复杂度：中等

上下文需求分析：
查询示例："交易金额超过 1亿元的融资交易需要什么合规审批"

所需上下文：
1. 融资交易规则（20KB）
2. 金额阈值政策（5KB）
3. 审批流程（15KB）
4. 历史案例（3 - 5 份，共 50KB）
5. 相关监管指南（30KB）
小计：约 120KB = 84000 tokens

使用模型：Claude 的当前 Sonnet 档位
价格：按预算当天官方价格页核对输入/输出 token 单价

*注：以下计算使用示例单价，仅用于展示公式。*
```

### 12.2.8.2.1 不同优化方案的成本对比

```
# 完整方案：每次查询加载所有上下文

context_per_query = 84000  # tokens
queries_per_month = 50000

# Token成本
input_cost_per_query = 84000 * 0.003 / 1000 = $0.252
output_cost_per_query = 2000 * 0.015 / 1000 = $0.03  # 平均 2K输出
total_per_query = $0.282

monthly_cost = total_per_query * queries_per_month = $14,100
annual_cost = monthly_cost * 12 = $169,200

问题：
- 成本高昂
- 许多查询不需要所有上下文
- 每次都重复加载相同内容
```

#### 方案 B：启用 Prompt Caching

```
# Prompt Caching: 静态内容缓存

# 缓存的内容：
# 1. 融资交易规则 (20KB)
# 2. 金额阈值政策 (5KB)
# 3. 审批流程 (15KB)
# 总计：40KB = 28000 tokens

# 缓存定价：
# 写入（首次）：28000 * 0.003 * 1.25 = $0.105
# 读取（后续）：28000 * 0.003 * 0.1 = $0.0084

# 每次查询的成本：
first_query_input = 28000 * 0.003 * 1.25 + 56000 * 0.003  # 缓存写入 + 动态内容
                  = $0.105 + $0.168 = $0.273
subsequent_queries_input = 28000 * 0.003 * 0.1 + 56000 * 0.003
                         = $0.0084 + $0.168 = $0.176
output_cost = $0.03

# 缓存命中率分析：
# 假设缓存内容日级更新，命中率 80%

monthly_cost = (10000 * $0.273 + 40000 * $0.176) + 50000 * $0.03
            = $2730 + $7040 + $1500
            = $11270

annual_cost = $11270 * 12 = $135,240

示例测算差异：($169,200 - $135,240) / $169,200 = 20.1%
```

#### 方案 C：分层式智能检索

```
# 分层策略：
# 换算沿用本节口径：0.7 token/字节，即 1KB ≈ 700 tokens（见后文合同场景的同一换算）
# L1：快速检索（基础规则）- 10KB = 7000 tokens
# L2：完整检索（规则+案例）- 40KB = 28000 tokens
# L3：深度分析（全文档）- 120KB = 84000 tokens

# 查询分类：
# - 简单规则查询（60%）：使用 L1
# - 需要案例的查询（35%）：使用 L2
# - 复杂合规咨询（5%）：使用 L3

simple_ratio = 0.6
medium_ratio = 0.35
complex_ratio = 0.05

simple_query_input = 7000 * 0.003 / 1000 = $0.021
medium_query_input = 28000 * 0.003 / 1000 = $0.084
complex_query_input = 84000 * 0.003 / 1000 = $0.252

average_input_cost = (0.6 * $0.021 + 0.35 * $0.084 + 0.05 * $0.252)
                   = $0.0126 + $0.0294 + $0.0126 = $0.0546

output_cost = $0.03
cost_per_query = $0.0846

monthly_cost = $0.0846 * 50000 = $4,230
annual_cost = $4,230 * 12 = $50,760

示例测算差异：($169,200 - $50,760) / $169,200 = 70.0%
```

#### 方案 D：混合方案（分层 + 缓存）

```
# 结合分层和缓存的最优方案

# 缓存配置：
# - 基础规则 L1（固定，缓存）：10KB
# - 审批流程（固定，缓存）：15KB
# 缓存总计：25KB = 17500 tokens
# 缓存成本：首次$0.066，后续$0.0053/次

# 动态内容：
# - L1增补：5KB = 3500 tokens
# - L2增补：25KB = 17500 tokens
# - L3增补：45KB = 31500 tokens

# 按查询类型的成本（缓存部分按读取价 0.1x 计；此处假设命中率 100%，
# 与方案 B 的 80% 命中假设口径不同，两者的年成本不可直接横比）：
L1_with_cache = (17500 * 0.003 * 0.1 + 3500 * 0.003) = $0.0053 + $0.0105 = $0.0158
L2_with_cache = (17500 * 0.003 * 0.1 + 17500 * 0.003) = $0.0053 + $0.0525 = $0.0578
L3_with_cache = (17500 * 0.003 * 0.1 + 31500 * 0.003) = $0.0053 + $0.0945 = $0.0998

average_input_cost = 0.6 * $0.0158 + 0.35 * $0.0578 + 0.05 * $0.0998
                   = $0.00948 + $0.02023 + $0.00499 = $0.0347

output_cost = $0.03
cost_per_query = $0.0647

monthly_cost = $0.0647 * 50000 = $3,235
annual_cost = $3,235 * 12 = $38,820

示例测算差异：($169,200 - $38,820) / $169,200 = 77.1%
```

**金融行业的最优方案总结**：

| 方案      | 示例年成本    | 示例相对节省 | 实现难度 | 推荐指数 |
| ------- | -------- | ------ | ---- | ---- |
| A: 无优化  | $169,200 | 0%     | 低    | ✗    |
| B: 缓存   | $135,240 | 20.1%  | 中    | ✓✓   |
| C: 分层检索 | $50,760  | 70.0%  | 高    | ✓✓✓  |
| D: 混合   | $38,820  | 77.1%  | 高    | ✓✓✓✓ |

## 12.2.8.3 医疗行业：病历分析的上下文策略

### 典型场景：医疗行业

医疗机构需要处理：

* 电子病历（EHR）：海量患者历史数据
* 医学指南和治疗协议（频繁更新）
* 临床研究和最新医学知识
* 药物相互作用数据库
* 诊断和治疗建议

### 示例测算：某三甲医院的诊断辅助系统

```
系统概况：
- 目标：为医生提供诊断和治疗建议
- 日均患者咨询：500例
- 月均：15000例

单个患者的上下文需求：
1. 患者病历摘要（5KB）
2. 相关诊断指南（20KB）
3. 治疗方案参考（15KB）
4. 类似病例（3 - 5 份，30KB）
5. 最新研究（10KB）
总计：80KB = 56000 tokens

特殊性：医疗数据敏感，不能外部缓存
- 必须在院内系统处理
- 不能使用云 API的缓存（隐私法规）
```

**医疗成本优化方案**：

### 方案 A：本地部署开源模型

```
# 使用开源模型避免 API 成本

model_options = {
    "本地开源模型 A": {
        "成本": "一次性购买$50K服务器 + $1K/月维护",
        "推理成本": "近乎 0",
        "延迟": "2 - 5 秒",
        "质量": "需用院内评测集验证"
    },
    "本地开源模型 B": {
        "成本": "一次性$30K + $500/月",
        "推理成本": "近乎 0",
        "延迟": "0.5 - 2 秒",
        "质量": "需用院内评测集验证"
    }
}

# 与 API成本对比：
api_monthly_cost = 56000 * 15000 / 1000 * 0.003 = $2,520
# 每个患者：56K tokens * $0.003 = $0.168
# 月成本：$0.168 * 15000 = $2,520

# 本地部署 1年总成本：
# $50K初期 + $1K*12 = $62K
# vs API: $2,520 * 12 = $30,240

# 分析：本地部署是否更经济，取决于查询量、硬件折旧、运维和质量达标情况
```

### 方案 B：医学知识压缩与摘要

```
# 医学知识的特点：高度结构化
# 可以有效压缩而不损失关键信息

# 原始输入：
full_diagnosis_guideline = """
XX病的诊断包括以下几个方面：
1. 临床表现：包括症状和体征...
   - 症状：疲劳、头晕、呼吸困难...
   - 体征：心率加快、血压升高...
2. 实验室检查：
   - 血常规：红细胞减少、血红蛋白降低...
   - 生化检查：肝功能、肾功能...
3. 影像学检查：
   - X光：胸部扩大...
   - CT：显示...
4. 诊断标准：根据...
...
(共 15KB)
"""

# 压缩后：
compressed_guideline = """
XX病诊断标准：
症状：疲劳、头晕、呼吸困难
检查：RBC↓、Hb↓、肝肾功异常
影像：胸部扩大
诊断：满足 3个以上标准
(共 2KB，信息保留度需用临床评测集验证)
"""

compression_ratio = 2 / 15 = 0.133

# 示例成本差异：
original_cost_per_patient = 56000 * 0.003 / 1000 = $0.168
compressed_cost = 56000 * 0.133 * 0.003 / 1000 = $0.0224

monthly_saving = ($0.168 - $0.0224) * 15000 = $2,184
annual_saving = $2,184 * 12 = $26,208

质量影响：
- 必须通过医学专家标注集、召回率和安全性评估验证
- 不应仅用压缩率判断是否可接受
```

### 方案 C：多层次检索系统

```
# 医疗特化的多层检索

class MedicalRetrieval:
    def retrieve_for_diagnosis(self, patient_data, chief_complaint):
        # 第 1层：快速初筛（症状匹配）
        # 成本：10KB = 7K tokens
        quick_guidelines = self.retriever_l1(chief_complaint)

        # 第 2层：增强检索（详细指南）
        # 成本：30KB = 21K tokens
        if diagnosis_certainty < 0.8:
            detailed_guidelines = self.retriever_l2(chief_complaint)

        # 第 3层：深度分析（类似病例、研究）
        # 成本：40KB = 28K tokens
        if requires_differential_diagnosis:
            similar_cases = self.retriever_l3(patient_profile)

        return combined_context

# 按症状复杂度的成本分布：
simple_cases = 0.4  # 常见症状，仅 L1
moderate_cases = 0.35  # 需要详细指南，L1+L2
complex_cases = 0.25  # 鉴别诊断，全层次

avg_tokens = (0.4 * 7000 + 0.35 * 28000 + 0.25 * 56000)
           = 2800 + 9800 + 14000 = 26600 tokens

cost_per_patient = 26600 * 0.003 / 1000 = $0.0798
monthly_cost = $0.0798 * 15000 = $1,197
annual_cost = $1,197 * 12 = $14,364

相比无优化的示例测算差异：($30,240 - $14,364) / $30,240 = 52.5%
```

**医疗行业建议**：

```
优先级排序（考虑隐私和成本）：
1. 本地部署 + 开源模型（若查询量>1000/天）
2. 医学知识压缩（必做，质量损失可控）
3. 多层检索（按症状复杂度动态选择）

NOT推荐：
- 外部云 API（隐私风险）
- 知识图谱（医学信息快速更新）
```

### 注意事项：隐性成本因素

上述成本模型假设所有成本都来自 LLM 调用和计算资源。**在实际部署中，存在其他影响整体成本的因素**：

**网络延迟与基础设施成本**：

虽然云 API 定价按 Token 计算，但真实场景中还需考虑：

1. **网络延迟**：
   * 从医疗设备 → 云 API 的往返时间：50 - 200ms
   * 在高延迟网络下（医疗机构内网），可能到达 500ms+
   * 这不计入 Token 成本，但影响实际用户体验和硬件投入
2. **API 速率限制与重试**：
   * 云 API 通常限制 QPS（如：10 - 100 requests / sec）
   * 超过限制的请求需排队或重试，额外延迟
   * 重试会产生额外的 API 调用（浪费成本）
   * 医疗场景中，批量查询可能触发速率限制
3. **网络基础设施成本**：
   * 医疗机构通常要求专线连接（不能用公网）
   * 专线成本：$500 - 2000 / 月（远超 LLM 成本）
   * VPN/安全通道维护成本

**修正后的成本模型**：

```
# 在前面计算的基础上，需增加：
network_latency_cost = {
    "专线费用": "500 - 2000 / 月",
    "VPN维护": "200 - 500 / 月",
    "重试导致的额外 API调用": "计价的 15 - 25% 额外开销"
}

实例：若 LLM月成本$1200，加上：
- 网络：$1000/月
- 重试开销：$300/月
总成本 = $2500/月（是 LLM成本的 2倍多）

因此，本地部署可能更经济，但结论必须结合合规、质量、运维和硬件折旧重新测算。
```

**建议调整**：

在医疗场景中，应该对比：

* **选项 A**：云 API（LLM $1.2K + 网络 $1.2K + 重试 $0.3K = $2.7K/月）
* **选项 B**：本地部署（初期 $50K + 维护 $1K/月 = 平均$2K+/月，但无网络成本）

本地部署的总体成本优势需要用本机构约束条件验证。

## 12.2.8.4 法律行业：合同审查的上下文管理

### 典型场景：法律行业

法律服务需要处理：

* 合同模板库（千份+）
* 法律判例库（百万份+）
* 法律法规和政策（频繁更新）
* 行业惯例和最佳实践

### 示例测算：某律师事务所的智能合同审查系统

```
系统概况：
- 律师数：50人
- 月均审查合同：300份
- 合同平均大小：40KB（28K tokens）

审查需要的上下文：
1. 用户上传的合同（40KB）
2. 对标模板（2-3份，60KB）
3. 相关法律（30KB）
4. 风险检查清单（10KB）
5. 类似案例（3份，40KB）
总计：180KB = 126K tokens

成本计算（示例单价，非实时报价）：
$0.0025/1K input, $0.015/1K output
```

**方案对比**：

### 方案 A：标准流程（无优化）

```
context_per_review = 126000 tokens
reviews_per_month = 300

cost_per_review = (126000 * 0.0025 + 3000 * 0.015) / 1000
                = (315 + 45) / 1000 = $0.36

monthly_cost = $0.36 * 300 = $108
annual_cost = $108 * 12 = $1,296

注：实际成本需按预算当天选定模型重新计算
```

### 方案 B：合同去冗与表结构化

```
# 法律合同有很多冗余：
# - 重复条款说明（每份 20-30%冗余）
# - 标准法律序言（5-10%）
# - 通用条款（10-15%）

# 智能去冗策略：
# 1. 提取合同关键条款（金额、各方、期限、违约责任等）
# 2. 结构化存储（JSON）
# 3. 只提交关键条款给模型

original_contract = "40KB"
key_clauses_only = 40 * 0.3 = "12KB"  # 关键条款占 30%

context_reduction_ratio = 12 / 40 = 0.3

# 新成本：
reduced_context = 126000 * 0.3 + 40000  # 关键条款 + 对标模板缩小
                = 37800 + 40000 = 77800 tokens

cost_per_review = (77800 * 0.0025 + 3000 * 0.015) / 1000
                = (194.5 + 45) / 1000 = $0.2395

monthly_cost = $0.2395 * 300 = $71.85
annual_cost = $71.85 * 12 = $862.20

示例测算差异：($1,296 - $862.20) / $1,296 = 33.5%
质量影响：需用合同审查评测集确认，不能默认最小
```

### 方案 C：分批次处理 + 缓存

```
# 法律审查的特点：重复度高
# - 同一事务所的模板会重复
# - 同一行业的对标模板固定
# - 法律法规相对稳定

# 缓存策略：
cached_context = {
    "法律法规": "30KB（周级更新）",
    "行业对标模板": "40KB（月级更新）",
    "事务所标准清单": "10KB（几乎不变）"
}

cache_size = (30 + 40 + 10) = 80KB = 56000 tokens

# 缓存成本：
cache_write_cost = 56000 * 0.0025 * 1.25 / 1000 = $0.175  # 首次
cache_read_cost = 56000 * 0.0025 * 0.1 / 1000 = $0.014    # 后续

# 关键：缓存写入次数由 TTL 决定，不由内容更新频率决定
# Anthropic 的缓存最长只有 1 小时（见 6.4 节），所以「缓存内容月级更新」
# 不等于「每月只写一次缓存」——每个超过 TTL 的空档都要重新写入。
# 假设：300 份/月 ÷ 22 个工作日 ≈ 13.6 份/天，散布在约 8 个工作小时中，
# 即约 8 个 1 小时窗口/天 × 22 天 ≈ 176 次写入，其余 124 次命中缓存。

contract_only = 8400 * 0.0025 / 1000 = $0.021  # 只用关键条款（12KB ≈ 8400 tokens，按 0.7 token/字节）
output_cost = 3000 * 0.015 / 1000 = $0.045

write_review_cost = $0.175 + $0.021 + $0.045 = $0.241  # 该窗口的首次
hit_review_cost   = $0.014 + $0.021 + $0.045 = $0.080  # 同窗口内的后续

monthly_cost = $0.241 * 176 + $0.080 * 124 = $42.42 + $9.92 = $52.34
annual_cost = $52.34 * 12 = $628.03

示例测算差异：相比方案 B 为 27.2%

# 注意这里的结论方向：在这个请求密度下（约 14 份/天），缓存的优势远没有
# 「按月写一次」算出来的那么大。若把写入次数放宽到 240 次/月，优势进一步
# 降到约 12.8%。**Prompt Caching 的收益取决于单位 TTL 内的请求密度，
# 而不是被缓存内容多久更新一次**；低频场景下它可能跑不赢方案 B 的去冗。
```

### 方案 D：AI 驱动的自动化审查

```
# 三层审查系统：
# L1：自动化（15分钟内完成）
#   - 提取关键信息
#   - 与模板自动对比
#   - 标记明显风险
# L2：LLM辅助审查（30分钟）
#   - 需要专业判断的条款
#   - 隐藏风险识别
# L3：律师人工审查（30分钟）
#   - 复杂商业条款
#   - 最终确认

# 按审查复杂度分类：
simple_contracts = 0.3  # 自动化可处理 90%
medium_contracts = 0.5  # 需要 L1+L2
complex_contracts = 0.2  # 需要全层次

# L1成本几乎为 0（仅本地处理）
# L2使用轻模型，成本低
# L3减少律师的审查时间成本

auto_only_cost = 0  # L1完全本地
light_llm_cost = 12000 * 0.003 / 1000 = $0.036  # L2 轻模型完整处理一次 12K tokens 的上限
manual_time_savings = 15  # 分钟，需按实际人工成本核算

# 各层单次评审成本取含调用开销的示意值（L2≈$0.1、L3≈$0.3）
average_cost_per_review = 0.3 * $0 + 0.5 * $0.1 + 0.2 * $0.3
                        = $0 + $0.05 + $0.06 = $0.11

monthly_cost = $0.11 * 300 = $33
annual_cost = $33 * 12 = $396
# 律师时间差异：需按真实流程、复核要求和人工成本核算

# ROI 需在试点后用真实吞吐、误报漏报和人工复核时间验证
```

**法律行业建议**：

```mermaid
graph TB
    A["法律审查成本优化"] --> B["内容结构化<br/>关键条款提取"]
    A --> C["Prompt缓存<br/>对标模板固定"]
    A --> D["自动化 L1审查<br/>自动标记风险"]

    B --> E["示例：降低输入量"]
    C --> F["示例：提高缓存复用"]
    D --> G["示例：减少人工初筛"]
    E --> H["综合应用"]
    F --> H
    G --> H
    H["综合应用"] --> I["需试点验证 ROI"]
```

## 12.2.8.5 客服行业：对话历史管理的成本

### 典型场景：客服行业

客服系统需要：

* 维持长对话历史
* 实时处理客户咨询
* 支持多轮交互

### 示例测算：某电商平台的客服 AI

```
系统概况：
- 日均对话：50000条
- 平均对话轮数：4-5轮
- 单条消息长度：200字（140 tokens）

对话历史的成本问题：
消息序列：
客：问题 1 (140 tokens)
助：回答 1 (200 tokens)
客：跟进问题 (100 tokens)
助：回答 2 (250 tokens)
...

假设 5轮对话：
总 tokens = 5轮 * (140+200) = 1700 tokens

但如果用户问新问题，需要重新加载历史：
新查询 (140) + 历史 (1700) = 1840 tokens

API成本（使用示例轻量模型单价，非实时报价）：
$0.001/1K input, $0.005/1K output
```

**客服行业的成本优化**：

### 方案 A：完整历史（无优化）

```
avg_conversation_length = 1700  # tokens
new_query = 140

total_tokens_per_query = avg_conversation_length + new_query = 1840

cost_per_query = 1840 * 0.001 / 1000 = $0.001840
output_cost = 200 * 0.005 / 1000 = $0.001000

cost_per_interaction = $0.001840 + $0.001000 = $0.002840

daily_cost = $0.002840 * 50000 = $142.0
annual_cost = $142.0 * 365 = $51,830

问题：对于高频交互，成本可观
```

### 方案 B：对话摘要 + 滑窗

```
# 策略 1：摘要化的对话历史
# "我想咨询退货政策，特别是电子产品的退货时限"
# "已确认是 30天内无理由退货"
# →摘要：用户咨询电子产品退货，已告知 30天政策

# 策略 2：滑窗方法
# 仅保留最近 3轮对话（而非所有历史）

# 结果：
compressed_history = 1700 * 0.4  # 40%的原始大小
                   = 680 tokens

total_tokens = compressed_history + new_query
             = 680 + 140 = 820

cost_per_query = 820 * 0.001 / 1000 + 200 * 0.005 / 1000
               = $0.000820 + $0.001000 = $0.001820

daily_cost = $0.001820 * 50000 = $91.0
annual_cost = $91.0 * 365 = $33,215

示例测算差异：($51,830 - $33,215) / $51,830 = 35.9%
质量影响：需用真实客服对话回放验证
```

### 方案 C：分层式上下文

```
# 三层上下文：
# L0：最新消息 (当前用户输入)
# L1：摘要历史 (过去 3轮压缩摘要，200 tokens)
# L2：详细历史 (过去所有对话，但按需加载)

# 按查询类型的层级需求：
# - 简单问题（结账、配送）：仅 L0
# - 中等问题（产品咨询）：L0 + L1
# - 复杂问题（投诉、特殊请求）：L0 + L1 + L2

simple_query_ratio = 0.5
medium_query_ratio = 0.35
complex_query_ratio = 0.15

simple_cost = (140 * 0.001 + 200 * 0.005) / 1000 = $0.001140
medium_cost = ((140 + 200) * 0.001 + 200 * 0.005) / 1000 = $0.001340
complex_cost = ((140 + 200 + 1700) * 0.001 + 200 * 0.005) / 1000 = $0.003040

avg_cost = 0.5 * $0.001140 + 0.35 * $0.001340 + 0.15 * $0.003040
         = $0.000570 + $0.000469 + $0.000456 = $0.001495

daily_cost = $0.001495 * 50000 = $74.75
annual_cost = $74.75 * 365 = $27,283.75

示例测算差异：($51,830 - $27,283.75) / $51,830 = 47.4%
```

### 方案 D：智能轮换 + 缓存

```
# 客服场景的特殊性：
# - 客户经常重复问同样的问题
# - 热点问题（退货、发货）重复度高
# - 常见 FAQs可以缓存

# 缓存应用：
faq_context = """
常见问题：
Q: 退货政策是什么?
A: 30天无理由退货...
Q: 如何追踪订单?
A: 登录账户，选择订单...
Q: 运费是多少?
A: 满 50免运...
"""

faq_tokens = 300  # 压缩的 FAQ

# 对于 FAQ类问题（占 40%）：
faq_cost = (300 * 0.001 * 0.1 + 140 * 0.001 + 200 * 0.005) / 1000
         = ($0.000030 + $0.000140 + $0.001000) / 1 = $0.001170

# 对于非 FAQ问题（60%）：
non_faq_cost = 0.001820  # 使用方案 B的成本

weighted_avg = 0.4 * $0.001170 + 0.6 * $0.001820
             = $0.000468 + $0.001092 = $0.001560

daily_cost = $0.001560 * 50000 = $78.0
annual_cost = $78.0 * 365 = $28,470

示例测算差异：($51,830 - $28,470) / $51,830 = 45.1%
```

**客服行业综合建议**：

```python
class CustomerServiceOptimization:
    """综合优化方案"""

    def __init__(self):
        # 使用通过质量评测的轻量模型
        self.model = "fast_low_cost_model"

        # 启用缓存 FAQ
        self.use_faq_cache = True

        # 对话摘要
        self.use_summarization = True

        # 滑窗历史
        self.history_window = 3  # 轮数

        # 分层上下文
        self.use_tiered_context = True

    def estimate_monthly_cost(self, monthly_queries=1500000):
        # 基于上面的方案 D 单次查询成本
        per_query_cost = 0.00156
        monthly = monthly_queries * per_query_cost
        return monthly

# 成本矩阵（与上文方案 A-D 的逐步测算一致）
cost_summary = {
    "方案 A（无优化）": "$51,830/年",
    "方案 B（摘要+滑窗）": "$33,215/年（示例）",
    "方案 C（分层）": "$27,284/年（示例）",
    "方案 D（智能轮换+缓存）": "$28,470/年（示例）",
    "综合应用 D+模型选择": "$14,000-18,000/年（示例）",
}
```

## 12.2.8.6 跨行业成本优化对比

### 成本结构对比

```mermaid
graph TB
    A["金融"] -->|"定长文档<br/>缓存友好"| B["缓存优先"]
    C["医疗"] -->|"隐私限制<br/>本地优先"| D["本地部署"]
    E["法律"] -->|"高冗余<br/>结构化优先"| F["内容压缩"]
    G["客服"] -->|"高频短交互<br/>轮换优先"| H["历史管理"]

    B --> I["收益取决于命中率"]
    D --> J["收益取决于规模"]
    F --> K["收益取决于压缩质量"]
    H --> L["收益取决于对话分布"]
```

### 行业成本效益矩阵

| 行业 | 示例初始成本/年 | 示例优化后成本 | 示例节省比例 | 难度 | ROI 周期 |
| -- | -------- | ------- | ------ | -- | ------ |
| 金融 | $169K    | $39K    | 77%    | 中  | 2 月    |
| 医疗 | $30K     | $14K    | 53%    | 高  | 1 月    |
| 法律 | $1.3K    | $290    | 78%    | 高  | 3 月    |
| 客服 | $52K     | $28K    | 45%    | 低  | 1 月    |

## 12.2.8.7 行业特化的最佳实践

### 通用优化步骤

```
Step 1：监测基准 (1-2周)
- 记录当前成本和性能
- 识别成本驱动因素
- 建立评估框架

Step 2：快速胜利 (1-2月)
- 模型选择优化
- 启用 Prompt缓存
- 简单的结构化优化

Step 3：中期优化 (3-6月)
- 内容压缩
- 分层检索
- 工作流重设计

Step 4：长期演进 (6-12月)
- 架构重构
- 自动化增强
- 持续优化迭代
```

### 行业特化的优先级

**金融优先级**：缓存 > 分层检索 > 模型选择 **医疗优先级**：本地部署 > 知识压缩 > 多层检索 **法律优先级**：内容结构化 > 缓存 > 自动化 **客服优先级**：历史管理 > FAQ 缓存 > 分层上下文

## 12.2.8.8 小结

不同行业的上下文工程优化策略差异显著：

* **金融**：着重利用内容重复性和缓存，收益取决于静态内容比例与缓存命中率
* **医疗**：受隐私和合规限制影响，本地部署是否更优需结合质量、运维和硬件折旧评估
* **法律**：结构化与去冗可能降低输入量，但必须验证漏报风险和人工复核成本
* **客服**：聚焦对话管理和常见问答，收益取决于问题重复度和摘要质量

关键是 **深入理解行业特性**，而非套用通用优化方案。最优的策略往往来自对特定行业成本结构的精细分析。