1. 手机银行对话摘要按生成目的分类

说明：本分类中包含5种"传统摘要"（归档记录型、快速处理型、分析洞察型、用户理解型、模型训练型）和1个"特殊类型"（上下文压缩型）。上下文压缩型本质上不是传统意义上的"摘要"，而是一种"对话状态的高密度压缩表示"，其目标读者是AI模型而非人类，其核心使命是服务于意图识别模型的输入构造。由于它与"摘要"在形态上（都是对长文本的精简）有相似性，故归入同一分类体系，但需明确其特殊性。

1.1. 五大传统摘要类型

1.2. 特殊类型：上下文压缩型

为了服务"意图判断"这个目标，压缩摘要需要做几件特殊的事：

• 强制保留意图演化轨迹：不要只保留最终意图，要保留意图的变化路径。例如：❌“用户想办挂失。” ✅"用户先查余额→发现被盗刷→要求挂失→确认挂失成功后询问补卡流程。"因为意图的转折点往往对后续对话有重要提示作用。

• 保留关键槽位的最新状态及其变更历史：用户可能在对话中反复修改信息。压缩时只保留最新且确认过的槽位值，同时标注变更痕迹（如"[曾变更]"），变更类型（修正/更换）由上层意图识别模型或主模型判定，压缩摘要仅负责记录变更事实。

• 保留情绪趋势，而非单个情绪标签：长对话中情绪会波动。压缩时保留情绪走势（如"平稳→略有不满→缓和"），这对预判用户下一步行为很有用。

• 按业务领域过滤信息：每个业务领域有独立的过滤规则，决定哪些信息必须保留、哪些可压缩、哪些可外置、哪些可丢弃（详见第3.1.1节）。

• 去除冗余信息：删除与任务目标无关的社交性寒暄、礼貌性用语和确认性口头禅。但用户重复表达的内容（如反复强调"我真的很着急"）恰恰是信号，需要概括进摘要。

1.3. 多角色协作示例：一份对话的多种摘要版本

以下以一条实际对话为例，展示同一对话在不同目的下的摘要版本如何服务于不同角色。本示例是 2.2 节所述"六大摘要目的"的多角色协作实例化。

场景：用户投诉信用卡有一笔980元境外盗刷交易，客服核实后发起争议处理。

2. 手机银行用户对话系统性问题

手机银行会话过程中的主要问题。

2.1. 问题全景图：从输入到输出的完整链路

flowchart TB
    subgraph SYSTEM["手机银行对话系统完整链路"]
        direction TB
        
        subgraph MAIN["主流程"]
            direction LR
            U1["1. 用户输入"] --> U3["2. 上下文管理"] --> U2["3. 意图识别"] --> U4["4. 策略决策"] --> U5["5. 回复生成"]
        end

        subgraph ISSUES["各环节对应问题"]
            direction LR
            I1["文本输入<br>（含语音转写）"]
            I3["短期记忆超长<br>（问题B）"]
            I2["长对话注意力<br>分散（问题A）"]
            I4["提参表<br>设计缺失（问题D）"]
            I5["摘要质量不佳<br>（问题C）"]
        end

        subgraph DOWNSTREAM["下游影响"]
            direction TB
            D1["用户画像维度细分不足"]
            D2["个性化服务能力不足"]
        end

        U1 -.-> I1
        U3 -.-> I3
        U2 -.-> I2
        U4 -.-> I4
        U5 -.-> I5

        I1 --> DOWNSTREAM_INPUT
        I3 --> DOWNSTREAM_INPUT
        I2 --> DOWNSTREAM_INPUT
        I4 --> DOWNSTREAM_INPUT
        I5 --> DOWNSTREAM_INPUT

        DOWNSTREAM_INPUT["各环节问题汇聚"] --> D1 --> D2
    end

    style SYSTEM fill:#f9f9f9,stroke:#333,stroke-width:2px
    style MAIN fill:#e8f4fd,stroke:#2196F3,stroke-width:1px
    style ISSUES fill:#fff3e0,stroke:#FF9800,stroke-width:1px
    style DOWNSTREAM fill:#fce4ec,stroke:#f44336,stroke-width:1px
    style DOWNSTREAM_INPUT fill:#ffebee,stroke:#d32f2f,stroke-width:1px,stroke-dasharray: 5 5

说明：对于语音输入场景，ASR转写错误可能对摘要质量产生额外影响，建议在摘要生成前增加ASR置信度过滤机制。

2.2. 三大系统性问题的分层拆解

说明：问题A、B、C之间并非并列关系，而是存在因果链条——问题B（窗口不匹配） 是根本性的技术瓶颈，它直接导致长回复被截断；问题A（摘要质量差） 是现有摘要方案自身的缺陷；二者共同导致了问题C（注意力分散） 这一最终表现。下文按"根因→方案缺陷→最终表现"的层次进行拆解。

2.2.1. 问题A：对话摘要质量差、内容杂乱（方案缺陷层）

问题本质：摘要系统没有一个以"目的"为导向的分类体系，导致一条摘要想覆盖所有场景，最终哪头都不靠。

2.2.2. 问题B：短期记忆数据超长（根因层——技术瓶颈）

问题本质：主对话模型与意图识别模型的上下文窗口容量不匹配，导致系统生成长回复污染了意图识别模型的输入。这本质上是"上下文压缩摘要"需要解决的一个核心应用场景——将长对话压缩为意图识别模型能够消费的极简结构化输入。

2.2.3. 问题C：长对话中意图识别的注意力分散（最终表现层）

问题本质：意图识别是"一次性"的，而不是"持续追踪"的——缺乏在对话全生命周期中对意图、情绪、槽位的动态维护。

3. 上下文压缩型摘要

上下文压缩型摘要是6个目的中最特殊的一个——它的目标读者不是人，而是AI模型。它直接解决前面提到的三个核心问题：

• 问题A（摘要杂乱）：通过结构化强制收敛到意图链+槽位+情绪+待办四个维度
• 问题B（短期记忆超长）：通过高压缩比（15%-25%）替代原始对话，为意图识别模型提供极简输入，彻底解决长回复撑爆窗口问题
• 问题C（注意力分散）：通过保留意图演化轨迹和情绪走势，让模型聚焦于关键转折点

特别说明：上下文压缩型摘要在本方案中是重点阐述的对象，因为它是实时对话链路中的关键组件，直接决定了意图识别模型能否在长对话中稳定工作。其他5种摘要类型（归档、处理、分析、用户理解、模型训练）的技术实现将在第4.5节统一说明。

3.1. 核心设计规范

本节定义8条核心设计规范，涵盖业务领域过滤、信息取舍、复杂场景处理三个层面，构成完整的规范体系。跨业务领域指代处理作为独立机制，在第3.3节单独阐述。

3.1.1. 基础原则（信息取舍层）

3.1.2. 按业务领域过滤

3.1.2.1. 手机银行业务领域清单

3.1.2.2. 各业务领域独立过滤规则表

3.1.2.3. 跨域关系类型

3.1.2.4. 跨域保留的约束规则

3.2. Prompt模板设计

3.2.1. 全量生成版（对话结束后或首次压缩）

你是一个对话状态压缩器。你的任务是将【原始对话】压缩为一段极短的"语义主干"，目的是替代原始对话，作为后续对话的上下文前缀。

**第一步：业务领域识别（优先执行）**
1. 识别用户输入涉及的所有业务领域（fund/wealth/transfer/credit_card/deposit/loan/account/complaint）
2. 标注主领域（primary_domain）、关联领域（secondary_domains）
3. 标注跨域关系类型：并行跨域（∥）/因果跨域（→）/流程跨域（→）/引用跨域（↗）/互斥（∥）/无跨域
4. 如果存在跨域关系，输出跨域链（如 fund→transfer→wealth）

**第二步：按业务领域规则过滤**
每个业务领域有独立的过滤规则，必须严格执行：

| 领域        | 必须保留                               | 可压缩保留               | 可外置                 | 可丢弃         |
| :---------- | :------------------------------------- | :----------------------- | :--------------------- | :------------- |
| fund        | 意图、基金代码、金额、持仓状态         | 风险等级、持有时间、情绪 | 完整持仓列表、历史净值 | 寒暄、礼貌用语 |
| wealth      | 意图、产品代码、金额、到期日、风险等级 | 风险偏好、收益预期       | 完整说明书、历史收益   | 寒暄、礼貌用语 |
| transfer    | 意图、金额、收款人、转账状态           | 转账备注、急迫程度       | 历史转账记录列表       | 寒暄、礼貌用语 |
| credit_card | 意图、卡号尾号、金额、还款状态         | 信用等级、逾期风险       | 完整账单明细           | 寒暄、礼貌用语 |
| deposit     | 意图、金额、存期、利率                 | 到期提醒偏好             | 历史存款记录           | 寒暄、礼貌用语 |
| loan        | 意图、贷款金额、利率、还款状态         | 信用评分                 | 完整合同条款           | 寒暄、礼貌用语 |
| account     | 意图、账号/卡号、账户状态              | 开户时间                 | 完整交易流水           | 寒暄、礼貌用语 |
| complaint   | 意图、问题描述、处理状态、责任人       | 情绪强度                 | 完整投诉历史           | 寒暄、礼貌用语 |

**第三步：跨域约束检查**
- 如果存在跨域链（如 fund→transfer→wealth），链上每个环节的"必须保留"信息必须同时存在于摘要中
- 如果某环节的保留信息缺失，标注"跨域不完整：{缺失项}"
- 互斥跨域（∥）需标注"互斥选择态"

**第四步：压缩规则**
1. 保留意图演化轨迹：用"→"连接意图变化路径
2. 保留最新确认的槽位值，标注"[曾变更]"
3. 保留情绪走势：起始→中间→当前
4. 保留重复信号
5. 保留索引锚点（列表场景）
6. 压缩目标：总Token≤200，【压缩正文】≤50字

**输出格式（强制结构化）：**
【业务领域】：主域={主领域}，关联域=[{关联领域}]，跨域链={链}，跨域类型={类型}
【意图轨迹】：{意图1} → {意图2} → {意图3}
【当前状态】：{槽位1}={值1}，{槽位2}={值2}
【情绪走势】：{起始} → {中间} → {当前}
【待办事项】：{有/无}，{具体事项}
【列表锚点】：{有/无}，{list_id}，{entity_type}，domain={业务领域}，共{数量}项，TTL={时长}
【压缩正文】：{不超过50字}

【原始对话】：
{dialogue_content}

业务领域标注与过滤示例：

3.2.2. 增量更新版（适用于长对话实时维护）

你是一个对话状态更新器。当前已有【旧压缩摘要】如下：
{old_summary}

现在新增了【新一轮对话】如下：
{new_dialogue}

请基于新对话内容，**更新**旧摘要，输出新的压缩摘要。

**更新规则：**
1. 业务领域：如果本轮涉及新领域，追加到关联域；如果形成新的跨域链，更新跨域链。
2. 意图轨迹：如果出现新意图，追加；如果是对旧意图的确认/否定，在相应位置标注。
3. 槽位状态：如果用户修改了之前的槽位值，替换为最新值，并标注"[已变更]"。
4. 情绪走势：根据本轮情绪调整走势，保留完整变化链。
5. 待办事项：如果客服做出了新承诺或用户提出了新要求，更新待办。
6. 列表锚点：如果本轮输出了新的列表，创建新锚点（含domain字段）。
7. 跨域检查：如果新增内容导致跨域链变化，重新检查跨域完整性。
8. 压缩正文：重写为包含新信息的最新概括，控制在50字以内。

输出格式同全量生成版。

3.2.3. 触发策略建议

3.3. 跨业务领域指代处理机制

本节是全文的核心机制之一。按业务领域过滤信息后，不同领域的关键信息被保留在摘要中，而列表等详情类信息被外置到索引映射表。当用户使用指代词（“那个”“它”“那笔钱”“第三个”）时，所指代的对象可能位于不同的业务领域或不同的存储位置。本节系统阐述跨业务领域指代的识别、追踪与解析机制。

3.3.1. 问题本质：指代词跨越了业务领域边界和存储位置

按业务领域过滤后，不同领域的信息被存储在不同的位置：

跨业务领域指代的核心矛盾：

用户输入（当前轮）：
"把那笔钱转过去"
         │
         │ 指代词"那笔钱"指向的是...
         ▼
   可能指向 fund 域的"50,000元基金收益"
   也可能指向 wealth 域的"30,000元理财余额"
   还可能指向 transfer 域的"待处理转账金额"

如果没有跨域链追踪，系统无法确定"那笔钱"到底指哪一笔。

3.3.2. 跨业务领域指代的类型体系

3.3.2.1. 按指代方向分类

关于类型D（指向已丢弃域）：当用户指代的对象已被判定为"可丢弃"而完全删除时，这属于指代消解的失败场景而非标准指代类型。该场景的处理机制详见第3.8节"容错与降级机制"。

3.3.2.2. 按跨域关系分类

3.3.3. 跨业务领域指代追踪流程

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                     跨业务领域指代追踪流程                                           │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│  用户输入（含指代词）                                                               │
│  "把那笔钱转过去"                                                                  │
│      │                                                                              │
│      ▼                                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤1：从压缩摘要中读取【业务领域】和【跨域链】                            │   │
│  │  ─────────────────────────────────────────────────────────────────────────── │   │
│  │  读取结果：主域=transfer，关联域=[fund, wealth]，跨域链=fund→transfer→wealth │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤2：识别指代词类型                                                       │   │
│  │  ─────────────────────────────────────────────────────────────────────────── │   │
│  │  "那笔钱" → 金额类指代，需在跨域链上依次查找"金额"类槽位                      │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤3：沿跨域链依次查找指代对象                                              │   │
│  │  ─────────────────────────────────────────────────────────────────────────── │   │
│  │  链：fund → transfer → wealth                                               │   │
│  │  ① 查 fund 域：找到"基金收益50,000元" → 命中！                              │   │
│  │  ② 标注来源域=fund，来源槽位=基金收益                                        │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤4：解析结果写回摘要（跨域提升）                                         │   │
│  │  ─────────────────────────────────────────────────────────────────────────── │   │
│  │  【当前状态】：指代解析="那笔钱"=fund域50,000元收益，来源域=fund              │   │
│  │  → 将指代解析结果显式写入摘要，供后续轮次直接使用                             │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤5：业务执行 → 使用解析结果执行转账 → 主模型生成回复                     │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘

3.3.4. 向索引表指代（类型C）的处理流程

当指代词指向的是外置列表中的某一项时（如"第三个基金"）：

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                     向索引表指代（类型C）处理流程                                    │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│  阶段1：系统输出列表（外置到索引表）                                                │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  用户："我想买基金，有什么推荐吗？"                                         │   │
│  │  系统：推荐5只基金：1.华夏... 2.易方达... 3.广发...                         │   │
│  │  压缩摘要：【列表锚点】：list_id=fund_rec_001，domain=fund，共5项            │   │
│  │  索引表：{list_id, position→entity_id映射, domain="fund"}                    │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  阶段2：用户指代列表项                                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  用户："给我解读下第三个基金"                                                 │   │
│  │  业务领域标注：主域=fund（继承）                                              │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤1：意图识别模型输出                                                     │   │
│  │  输出：意图="基金详情查询"，槽位={position:3, list_id: fund_rec_001}        │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤2：索引表查询                                                           │   │
│  │  输入：list_id=fund_rec_001，position=3                                     │   │
│  │  查询索引映射表 → 返回 entity_id=004851，entity_name=广发医疗保健            │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                      │                                              │
│                                      ▼                                              │
│  ┌─────────────────────────────────────────────────────────────────────────────┐   │
│  │  步骤3：解析结果写回摘要                                                     │   │
│  │  【当前状态】：聚焦基金=广发医疗保健（004851）                                 │   │
│  │  → 供后续轮次（如"那它的历史收益呢"）直接使用                                 │   │
│  └─────────────────────────────────────────────────────────────────────────────┘   │
│                                                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘

3.3.5. 索引映射表作为"跨域桥梁"的核心设计

索引映射表在跨业务领域指代中扮演"跨域桥梁"角色。其数据结构扩展了业务领域维度：

{
  "list_id": "fund_recommendation_20260814_001",
  "list_type": "fund_recommendation",
  "entity_type": "fund",
  "domain": "fund",                          // 所属业务领域
  "source_session_id": "session_20260814_001",
  "ttl": 1800,
  "position_mapping": [
    {"position": 1, "entity_id": "000001", "entity_name": "华夏成长混合"},
    {"position": 2, "entity_id": "005827", "entity_name": "易方达蓝筹精选"},
    {"position": 3, "entity_id": "004851", "entity_name": "广发医疗保健"}
  ],
  "cross_domain_refs": {                     // 被其他领域引用
    "referenced_by": ["wealth", "transfer"],
    "ref_count": 3
  },
  "access_count": 3,
  "last_accessed_position": 3,
  "created_at": "2026-08-14T14:23:00Z"
}

索引映射表的跨域查询接口：

def resolve_cross_domain_reference(user_input, compressed_summary):
    """
    解析跨业务领域指代
    """
    # 步骤1：从摘要中读取跨域链
    cross_chain = extract_cross_chain(compressed_summary)  # 如 ["fund", "transfer", "wealth"]
    referent_type = extract_referent_type(user_input)       # 如 "金额类指代"
    
    # 步骤2：沿跨域链依次查找
    for domain in cross_chain:
        # 先在摘要的【当前状态】中查找
        result = search_in_summary(compressed_summary, domain, referent_type)
        if result:
            result["source_domain"] = domain
            # 写回摘要（跨域提升）
            update_summary_reference(compressed_summary, user_input, result)
            return result
        
        # 再查该域的索引表
        result = search_in_index_table(domain, referent_type)
        if result:
            result["source_domain"] = domain
            result["source"] = "index_table"
            update_summary_reference(compressed_summary, user_input, result)
            return result
    
    # 步骤3：未找到，触发澄清（参见3.8节容错机制）
    return trigger_clarification(user_input)

3.3.6. 各类指代类型的处理规则汇总

3.3.7. 索引映射表的生命周期管理（含跨域桥梁字段）

跨会话指代场景的用户可见行为：主对话模型基于"列表不存在"信号，生成回复：“您上次的推荐列表已过期，是否需要我重新为您生成一次？”

3.3.8. 跨业务领域指代处理的评估

3.4. 应用场景：替代系统长回复注入意图识别模型

上下文压缩摘要的一个核心应用场景是替代系统生成长回复，作为意图识别模型的输入，彻底解决"系统长回复撑爆意图识别模型窗口"的问题。

3.4.1. 核心原则

意图识别模型与主对话模型的上下文完全分离，独立维护：

┌─────────────────────────────────────────────────────────────────────────────────────┐
│                    上下文压缩摘要的核心应用场景（问题B解决方案）                      │
├─────────────────────────────────────────────────────────────────────────────────────┤
│                                                                                     │
│  用户输入 ──┬──→ 主对话模型（128K窗口）                                             │
│             │       ↓                                                              │
│             │   生成完整回复（可很长，如转账记录、理财说明书、合规披露）              │
│             │                                                                      │
│             └──→ 意图识别模型（4K-8K窗口）                                         │
│                      ↑                                                             │
│                      │                                                             │
│               【上下文压缩摘要】←── 3.2节的产出                                      │
│               （业务领域 + 意图轨迹 + 当前状态 + 情绪走势 + 待办事项 + 列表锚点）    │
│                                                                                     │
│              ✗ 绝不放入主模型生成的长回复                                           │
│                                                                                     │
└─────────────────────────────────────────────────────────────────────────────────────┘

3.4.2. 意图识别模型的具体输入格式

上下文压缩摘要（3.2节定义）的输出格式为：

【业务领域】：主域=credit_card，关联域=[account]，跨域链=account→credit_card，跨域类型=流程
【意图轨迹】：查询账单明细 → 确认卡片安全状态 → 质疑交易真实性 → 要求争议处理
【当前状态】：卡号尾号=8899，争议金额=980元，交易类型=境外游戏平台
【情绪走势】：平静 → 疑惑 → 着急/不满 → 缓和
【待办事项】：有，争议审核中
【列表锚点】：无
【压缩正文】：用户尾号8899信用卡有一笔980元境外游戏平台交易，客服已发起争议申请

意图识别模型直接消费上述摘要，并拼接用户最新输入：

【对话状态摘要】：
【业务领域】：主域=credit_card，关联域=[account]，跨域链=account→credit_card
【意图轨迹】：查询账单明细 → 确认卡片安全状态 → 质疑交易真实性 → 要求争议处理
【当前状态】：卡号尾号=8899，争议金额=980元，交易类型=境外游戏平台
【情绪走势】：平静 → 疑惑 → 着急/不满 → 缓和
【待办事项】：有，争议审核中
【列表锚点】：无
【压缩正文】：用户尾号8899信用卡有一笔980元境外游戏平台交易，客服已发起争议申请

【用户最新输入】：
{当前用户问题}

请判断用户意图。

输入Token数：压缩摘要（约200-300 Token）+ 用户最新输入（约50-100 Token）= 总计约300-400 Token，远低于4K窗口限制。

3.4.3. 典型长回复场景处理案例

以下通过5个典型场景，展示系统生成长回复时，上下文压缩摘要如何替代长回复进入意图识别模型。其中场景五（基金推荐/列表指代）是核心难点，涉及跨业务领域指代处理（详见第3.3节）。

3.4.3.1. 场景一至四：摘要策略对比一览

场景一示例（理财说明书）：

用户：“这个理财产品怎么样？风险高吗？” → 主模型返回约3000 Token的完整产品说明书。
压缩摘要：【业务领域】：主域=wealth。【意图轨迹】：咨询理财产品 → 询问风险评估 → 关注购买方式。【当前状态】：产品名称=XX增利365天，风险等级=R3，状态=用户在了解阶段。【情绪走势】：中性 → 略带疑虑 → 回归中性。【压缩正文】：用户咨询R3级理财产品，已了解基本信息和风险等级，尚未表达购买意向。

场景二示例（转账记录）：

用户：“帮我把上个月的转账记录导出来” → 主模型返回36笔转账明细（约4000 Token）。
压缩摘要：【业务领域】：主域=transfer。【意图轨迹】：查询月度转账记录 → 查看明细列表 → 已列出全部交易。【当前状态】：查询期间=上月，总笔数=36笔，总金额=284,600元。【列表锚点】：有，list_id=transfer_20260812_001，entity_type=transaction，domain=transfer，共36项，TTL=30分钟。【压缩正文】：已展示上月36笔转账记录，用户正在浏览列表中。

3.4.3.2. 场景五（核心难点）：基金推荐列表 + 序号指代消解

本场景涉及跨业务领域指代（第3.3节定义的跨域指代机制），是索引映射表的核心应用场景。

处理流程（详见第3.3.4节）：

1. 系统输出列表时：创建索引映射表 list_id=fund_rec_001, domain=fund，摘要中记录【列表锚点】。
2. 用户追问时：意图识别模型输出 意图="基金详情查询", position=3, list_id=fund_rec_001。
3. 索引表查询：返回 entity_id=004851, entity_name=广发医疗保健。
4. 结果写回摘要：【当前状态】更新为 聚焦基金=广发医疗保健（004851），供后续轮次直接使用。

3.5. 应用效果量化预期

说明：以下数据为预期目标，基于离线测试集和理想条件下的评估结果。实际生产环境可能因数据分布、系统延迟等因素有所偏差，建议在上线后持续监控并根据实际情况调整阈值。

4. 压缩摘要的替代与补充方案

上下文压缩摘要是本文档重点阐述的方案，但它并非处理长回复与超长对话历史的唯一路径。业界还有三种主流且有效的解决思路：外部记忆库、分层摘要和关键信息提取。这些方法并非相互排斥，在实际的手机银行系统中常常组合使用，以达到最佳效果。

4.1. 外部记忆库：“外挂大脑”

核心思想：将长回复等大量信息存储在模型上下文窗口之外，只在需要时按需调用。

• 具体做法：不将完整的长回复（如几十条转账记录、完整的理财说明书）放入意图识别模型的上下文窗口，而是将这些信息存入一个外部的、可快速检索的数据库（如向量数据库、Redis等）。当用户后续提问时，系统先根据用户的问题去外部记忆库中检索最相关的信息片段，再将这些精简后的片段与用户问题一起输入给模型。

优势：

与本文档的关系：第3.3节跨业务领域指代处理机制中的索引映射表，本质上就是外部记忆库的一种具体实现——它按业务领域（fund、transfer等）分类存储列表类详情信息，当用户说"第三个"时（向索引表指代），指代消解层查询索引表而非在上下文里寻找。外部记忆库是这个思想的泛化，可以处理列表之外的更多非结构化信息。

4.2. 分层摘要：“分而治之”

核心思想：将一个复杂的长文本摘要任务分解为多个简单的短文本摘要任务。

• 具体做法：对于一段超长的对话历史，不直接让模型一次性生成最终摘要，而是分两步走：
  1. 分段摘要：将长对话按主题、时间或固定轮次（如每10轮）切分成多个小段，为每一段生成一个简短的摘要。
  2. 全局摘要：将所有分段摘要拼接起来作为新的输入，让模型生成一个最终的全局摘要。

优势：

与本文档的关系：3.2.2节的**“增量更新版"Prompt**就体现了分层摘要的思想——它不是每次都重新处理全部对话，而是在"旧压缩摘要"的基础上，结合"新一轮对话"来生成"新摘要”，这是一种在线的、流式的分层摘要。

4.3. 关键信息提取：“只取所需”

核心思想：不生成连贯的文本摘要，而是直接从对话中抽取出结构化的关键信息。

• 具体做法：放弃生成自然语言摘要，转而定义一个结构化的信息模板（如JSON格式），让模型只负责从对话中填充这个模板。例如，只提取{"业务领域": "fund", "意图": "赎回", "基金代码": "004851", "金额": "50000"}等关键字段。

优势：

与本文档的关系：3.2.1节定义的上下文压缩型摘要的输出格式（业务领域、意图轨迹、当前状态、情绪走势、待办事项、压缩正文）已经非常接近关键信息提取。可以说，上下文压缩摘要是"关键信息提取"和"自然语言摘要"的结合体——它既保留了结构化的字段，也生成了一段连贯的"压缩正文"。

4.4. 四种方案的对比与组合策略

在实际的手机银行系统中，一个健壮的方案很可能是组合拳：

• 用压缩摘要作为基础，维持对话的连贯性（即本文档第3章的主线方案）；
• 用业务领域过滤规则（第3.1.1节）来决定各领域信息的取舍；
• 用跨业务领域指代处理机制（第3.3节）来解决跨域指代追踪问题；
• 用外部记忆库/索引映射表来承载各业务领域的列表类详情信息；
• 用关键信息提取的思路来设计摘要的结构化字段，方便下游系统调用。

4.5. 其他类型摘要的实现要点

本方案的焦点在"上下文压缩型摘要"上，因为它直接决定了实时对话链路的稳定性。但第1.1节还定义了5种传统摘要类型，本节简要说明它们在技术实现上的定位以及与压缩型摘要的协作关系。

4.5.1. 生成时机与技术路径对比

4.5.2. 设计原则

1. 异步生成，不影响实时链路：归档、分析、画像、训练四类摘要均在对话结束后异步触发，不占用实时意图识别的计算资源和延迟预算。
2. 复用压缩摘要的中间产出：压缩摘要的【业务领域】【意图轨迹】【情绪走势】【当前状态】等结构化字段，可直接作为其他摘要的输入素材，减少重复计算。
3. 按需调整详略程度：归档型要求最完整，分析型要求最精炼，画像型要求标签化，各自使用独立的Prompt模板，而非在同一份摘要上做删改。
4. 统一存储，分表管理：所有摘要按类型分表存储（或同一表内加type字段），便于下游系统按需检索。
5. 业务知识注入：分析洞察型和用户理解型摘要需结合预定义的业务标签体系（如"商机信号"清单、"流失风险"关键词库）进行生成，而非完全依赖模型的开放式总结，以提高标签的准确性和可用性。
6. 过滤规则因类型而异：对压缩摘要属于"可丢弃"的信息（如寒暄），对归档记录型摘要而言属于"必须保留"（合规审计需要完整语境）。各类型摘要应独立定义其过滤规则。

4.5.3. 快速处理型与压缩型摘要的协作示例

以第3.4.3.2节场景五"基金推荐+序号指代"为例：

• 压缩摘要（实时链路，200 Token）：【业务领域】：主域=fund。【意图轨迹】：咨询基金推荐→系统展示5只基金→用户要求解读第3只。【列表锚点】list_id=fund_rec_001，domain=fund，共5项。【压缩正文】用户正针对第3只基金进行追问。
• 快速处理型摘要（转人工时生成，80字）：用户要求解读广发医疗保健基金（代码004851），已展示产品详情，用户正在浏览，暂无购买意向，无需紧急跟进。
• 归档记录型摘要（对话结束后生成，完整记录，保留社交寒暄）：2026-08-14 14:23用户咨询基金推荐，14:25系统推荐5只基金，14:26用户指定第3只（广发医疗保健）要求解读，14:28系统展示完整产品详情（净值、持仓、费率），14:35用户表示"再看看"，未产生购买。全程合规风险提示已展示。

4.5.4. 压缩摘要作为"信息底座"的价值

高质量的上下文压缩摘要不仅是意图识别模型的输入，它结构化、高密度的信息（如【业务领域】、【意图轨迹】、【情绪走势】、【待办事项】）可以作为"中间件"，为其他五种摘要的生成提供坚实的数据底座，从而从根源上解决第2.2.1节问题A中提到的"摘要目的不明确"和"信息取舍无标准"的问题。

• 对归档记录型：压缩摘要提供事实骨架（关键事件、时间线、业务实体），原始对话负责填充血肉（如寒暄、完整语境），两者配合确保归档的完整性与可读性。
• 对快速处理型：压缩摘要的【待办事项】和【当前状态】是核心素材，可直接复用，大幅缩短工单生成时间。
• 对分析洞察型：压缩摘要的【意图轨迹】和【跨域链】是极佳的分析特征，可用于聚类和归因，帮助产品团队快速定位高频问题和跨域关联。
• 对用户理解型：压缩摘要的【情绪走势】和【意图轨迹】可直接转化为行为标签，如"情绪敏感型用户""跨域操作频繁"等，丰富用户画像。
• 对模型训练型：压缩摘要的结构化字段可作为训练数据的预标注，大幅降低人工标注成本，加速模型迭代周期。

5. 容错与降级机制

说明：任何AI系统都必须考虑"降级"和"容错"。本节补充了当压缩摘要生成服务本身发生故障时的应对策略，是系统健壮性的必要保障。

5.1. 摘要生成服务异常处理

5.2. 指代消解失败时的兜底策略

以下场景涵盖了第3.3.2.1节中"类型D（指向已丢弃域）"及其他指代失败情况的处理。

设计原则：对于指向已丢弃域的指代及各类无法解析的指代，系统不应"假装理解"，而应主动承认信息缺失并引导用户补充。

5.3. 监控与告警

6. 评估指标体系

上下文压缩摘要的评估不是看"好不好看"，而是看"压缩后任务能不能不掉链子"。

6.1. 评估维度总览

6.2. 各维度详细评估方法

（1）意图保真度（核心指标）

离线评估操作步骤：

1. 抽取100-200条真实手机银行对话（覆盖单轮/多轮/投诉/查询等场景）
2. 人工标注每条的最终意图标签（作为Ground Truth）
3. 分别用原始对话和压缩摘要作为输入，调用意图识别模型
4. 计算两组的准确率，对比差异
5. 预期目标：压缩后准确率 ≥ 原始准确率的95%

（2）槽位召回率与准确率

实施方法：按各业务领域的"必须保留"清单，定义关键槽位（基金代码、金额、卡号尾号等），写正则表达式从对话中提取这些槽位，对比压缩摘要中是否完整保留。

（3）任务完成度（北极星指标，一票否决）

操作步骤：

1. 选取3-5个高频业务场景
2. 每个场景准备30-50组真实对话
3. A/B两组分别用原始对话和压缩摘要作为上下文
4. 执行相同的下游任务，记录成功率
5. 如果B组任务成功率低于90%（一票否决阈值），说明压缩摘要质量不达标

（4）跨业务领域指代准确率（专项评估）

详见第3.3.8节。

（5）压缩效率

6.3. 边缘案例测试分类表

以下按测试目的分为三大类，每类包含对应的测试案例：

6.4. 增量更新摘要的专项评估

7. 落地实施路线图

最简起步方案（如果资源有限）：先抓6个核心指标：意图一致性（离线100条）、槽位是否丢（自动化脚本）、任务成功率（选1个高频场景做30组对比）、指代消解准确率（列表场景专项测试）、跨域金额/实体指代准确率、3-4个高频边缘案例。这六个跑通后再逐步完善。

8. 总结

本文档系统阐述了手机银行场景下"上下文压缩型摘要"的设计理念、核心机制和实施路径。核心要点可归纳为以下六条：

1. 定位清晰：上下文压缩型摘要的目标读者是AI模型而非人类，其本质是"对话状态的高密度压缩表示"，服务于意图识别模型的输入构造。

2. 因果链条明确：第2章梳理了三大问题的层级关系——问题B（窗口不匹配） 是根因，问题A（摘要质量差） 是方案缺陷，二者共同导致问题C（注意力分散） 的最终表现。压缩摘要直面这三个问题，通过结构化输出和高压缩比实现稳定控制。

3. 业务领域驱动：通过"业务领域识别→按领域规则过滤→跨域约束检查"的三步流程，确保不同业务场景下的信息取舍有据可依，解决了传统摘要"该留的不留、该删的不删"的问题。

4. 跨域指代机制：第3.3节定义的四类指代类型（域内/跨域/向索引表/指向已丢弃域）和对应的追踪流程，是压缩摘要在多轮、多域对话中保持语义连贯性的核心保障。索引映射表作为"跨域桥梁"，承载了列表类信息的精确映射。

5. 架构分离：意图识别模型与主对话模型的上下文完全分离，压缩摘要替代系统长回复注入意图识别模型，彻底解决了"长回复撑爆窗口"的问题。

6. 多摘要协同：压缩摘要作为"信息底座"，为归档、处理、分析、画像、训练等五种传统摘要提供结构化数据支持，形成一个完整的摘要生产体系。

落地实施建议遵循"先离线验证、再小流量实验、最后全量上线"的渐进式路径，并持续监控任务完成度这一北极星指标，确保压缩摘要带来的收益可量化、可追溯。