# 斗鱼弹幕日报信息提纯设计

## 1. 背景

当前斗鱼弹幕日报的问题，不是“压缩不够”，而是“压缩目标不对”。

现状容易出现两个偏差：

1. 把大量无效但高频的弹幕情绪词喂给 LLM，例如 `哈哈哈`、`666`、`?`、同一句复读几十次。
2. 把真正有价值的信息和无价值信息混在一起，导致模型虽然看到了材料，但没有把重点提出来。

本设计的目标是重新划清边界：

1. **本地规则和统计能完成的事情，绝不交给 LLM。**
2. **只有需要语义归纳、背景理解、近期话题提炼的部分，才交给 LLM。**
3. **给 LLM 的输入不再是“压缩后的弹幕大杂烩”，而是“本地已经提纯过的高价值证据包”。**

---

## 2. 核心目标

斗鱼弹幕日报的核心目标不是生成“好看的总结”，而是：

1. 从直播间弹幕中提取**有效信息**。
2. 剔除大量**无效信息**。
3. 将最终结果拆成两类：
   - **本地可直接得出的确定性信息**
   - **需要 LLM 进行语义提炼的信息**

最终日报应该像：

1. 先有一层可靠的本地事实统计。
2. 再有一层 LLM 输出的“主播相关信息提炼”。
3. 而不是让 LLM 从一大堆原始弹幕里自己猜重点。

---

## 3. 总体原则

### 3.1 本地优先

凡是满足以下条件的信息，都优先在本地处理：

1. 可由规则、计数、聚合、去重直接得出。
2. 不需要理解上下文隐含语义。
3. 不需要结合主播背景或近期事件进行解释。

### 3.2 LLM 只做语义值钱的部分

凡是满足以下条件的信息，才交给 LLM：

1. 需要从多条弹幕中归纳出一个“正在讨论的事实”。
2. 需要理解主播背景、赛事背景、人物关系、近期话题。
3. 需要把局部零散证据整理成可读的结构化结论。

### 3.3 LLM 输入必须是证据包，不是原始垃圾堆

给 LLM 的材料必须满足：

1. 已经做过去噪。
2. 已经做过重复合并。
3. 已经按“主题证据”组织。
4. 已经把低价值情绪刷屏降权。

---

## 4. 功能边界重定义

## 4.1 本地层负责什么

本地层只做**确定性提纯**，不做“理解性总结”。

建议本地层负责以下内容：

### A. 基础清洗

1. 去掉平台系统提示。
2. 去掉机器人检测文案。
3. 去掉空白、乱码、纯符号内容。
4. 去掉超长模板垃圾文案。

### B. 重复压缩

1. 完全相同弹幕合并。
2. 高频短词合并。
3. 高频模板句合并。
4. 情绪刷屏单独归类，不再当正文语料反复出现。

例如：

1. `哈哈哈` * 200 -> 只保留为“情绪爆发词：哈哈哈，200次”
2. `梦幻小镇` * 50 -> 保留为“高频共识梗：梦幻小镇，50次”
3. 完全一样的长句 * 20 -> 保留为“模板复读内容”

### C. 时间与窗口统计

1. 分时间桶统计弹幕高峰。
2. 找出热点窗口。
3. 每个窗口保留少量代表样本。
4. 记录每个窗口的活跃人数、主要重复句、样本发言。

### D. 用户画像归并

1. UID 不在每条弹幕里重复出现。
2. 粉丝牌、牌子等级、房间等级统一抽到用户索引。
3. 样本弹幕只保留昵称或压缩后的 speaker_id。

### E. 本地直接可得的结构化事实

这一层仍然属于本地，不需要 LLM：

1. 总弹幕数
2. 去重后弹幕数
3. 高频复读句
4. 高频情绪词
5. 热点时间段
6. 活跃用户数量
7. 带牌用户数量
8. 高频提到的显式关键词

注意：

这里的“显式关键词”仅用于辅助聚类，不等于最终结论。

---

## 4.2 LLM 层负责什么

LLM 只负责**语义提炼**，不负责基础统计。

建议 LLM 专注处理以下几类问题：

### A. 近期有效信息提炼

从证据包里提炼直播间正在讨论的有效信息，例如：

1. 主播最近要参加什么比赛
2. 最近是否有选人、报名、分组、训练赛等话题
3. 观众最近在讨论主播打什么位置
4. 是否在讨论教练、队友、队内分工

### B. 主播相关背景信息提炼

从弹幕中提炼“粉丝正在把主播和哪些背景联系起来”，例如：

1. 老职业时期的身份梗
2. 与哪些圈内人物被反复提起
3. 与哪些历史赛事、名场面相关
4. 当前直播内容与过往印象之间的关联

### C. 对局有效信息提炼

这里不是让 LLM 解说整局，而是提炼“观众明确在讨论的局势信息”。

例如：

1. 本局重点玩的英雄是什么
2. 观众反复提到哪些装备、节奏点、失误点
3. 某局是顺风、翻盘、被翻、队友崩盘还是后期接管
4. 某局为何引发大量吐槽或称赞

### D. 场外互动与梗提炼

比如：

1. 是否大量观众要求开摄像头
2. 是否在调侃光头、外形、状态
3. 是否大量提到团播人物、户外人物、主播关系人
4. 是否有明显的场外乐子线

---

## 5. 本地层与 LLM 层的分工表

| 信息类型 | 本地处理 | LLM处理 | 说明 |
| --- | --- | --- | --- |
| 哈哈哈、666、?、坏了等情绪词 | 是 | 否 | 本地统计次数即可 |
| 完全相同弹幕复读 | 是 | 否 | 本地合并 |
| 高频模板长句 | 是 | 否 | 本地合并并保留样本 |
| 热点时间段 | 是 | 否 | 本地统计即可 |
| 活跃用户、牌子、等级 | 是 | 否 | 本地汇总即可 |
| 比赛预告、选人、位置讨论 | 否 | 是 | 需要从多条弹幕归纳 |
| 近期主播相关话题 | 否 | 是 | 需要语义理解 |
| 对局关键剧情 | 部分 | 是 | 本地给证据，LLM做归纳 |
| 主播背景和粉丝讨论的关联 | 否 | 是 | 需要语境理解 |
| 团播人物关系、场外梗 | 部分 | 是 | 本地聚类，LLM提炼结论 |

---

## 6. 新的数据流设计

建议将日报处理拆成三层。

### 第一层：原始弹幕层

输入：

1. 原始弹幕文本
2. 时间戳
3. 用户标识
4. 粉丝牌与等级
5. 直播房间上下文

输出：

1. 标准化后的 message 列表

### 第二层：本地提纯层

输入：

1. 标准化后的 message 列表

输出：

1. 基础统计结果
2. 高频情绪词
3. 高频复读句
4. 热点窗口
5. 用户索引
6. 主题证据簇

这一层是关键。

**主题证据簇** 是给 LLM 的核心材料，不是简单词频。

例如：

1. `赛事相关簇`
2. `位置讨论簇`
3. `英雄与对局簇`
4. `摄像头调侃簇`
5. `团播人物簇`

每个簇都应该包含：

1. 簇名
2. 匹配次数
3. 涉及人数
4. 时间范围
5. 3-6条代表性原始弹幕

### 第三层：LLM 语义提炼层

输入：

1. 房间上下文
2. 本地统计摘要
3. 主题证据簇
4. 少量热点窗口样本

输出：

1. 结构化语义结论
2. 最终日报文本

---

## 7. 给 LLM 的推荐输入结构

建议后续给 LLM 的输入，不再是“大量压缩后的弹幕散点”，而是以下结构。

```json
{
  "report_meta": {},
  "room_context": {},
  "local_stats": {
    "message_count": 0,
    "unique_user_count": 0,
    "top_emotion_bursts": [],
    "top_repeated_messages": [],
    "peak_windows": []
  },
  "topic_evidence_clusters": [
    {
      "label": "赛事预告与选人讨论",
      "count": 0,
      "user_count": 0,
      "time_range": "",
      "samples": []
    },
    {
      "label": "位置与身份讨论",
      "count": 0,
      "user_count": 0,
      "time_range": "",
      "samples": []
    },
    {
      "label": "英雄与关键对局",
      "count": 0,
      "user_count": 0,
      "time_range": "",
      "samples": []
    },
    {
      "label": "团播人物与场外互动",
      "count": 0,
      "user_count": 0,
      "time_range": "",
      "samples": []
    },
    {
      "label": "镜头与外形调侃",
      "count": 0,
      "user_count": 0,
      "time_range": "",
      "samples": []
    }
  ]
}
```

这里最重要的是：

1. `top_emotion_bursts` 只是氛围参考
2. `topic_evidence_clusters` 才是 LLM 的主要工作材料

---

## 8. LLM 输出建议改为结构化中间结果

为了避免 LLM 一步直接写日报导致遗漏信息，建议加一个中间层输出。

LLM 先输出结构化 JSON，再由程序拼接成日报。

建议结构如下：

```json
{
  "effective_information": {
    "recent_event_updates": [],
    "position_or_role_discussions": [],
    "hero_and_match_topics": [],
    "streamer_background_topics": [],
    "off_stream_interactions": []
  },
  "fans_digest": {
    "summary": "",
    "fun_points": [],
    "scene_quotes": [],
    "meme_rank": [],
    "closing_line": ""
  }
}
```

这样做的原因：

1. “信息提炼” 和 “文风输出” 分离。
2. 先保证有效信息提全，再生成乐子日报。
3. 后续也方便把有效信息单独展示或缓存。

---

## 9. 以当前问题为例，理想输出应该覆盖什么

对于用户给出的案例，LLM 最终应该能从证据中提炼出类似如下信息：

### A. 近期比赛信息

1. 观众正在讨论主播即将参与的 `老头杯`。
2. 弹幕提到 `4月30日` 的选人或相关流程。

### B. 位置讨论

1. 粉丝在争论主播届时打 `1号位` 还是 `5号位`。
2. 部分弹幕在讨论是否可能承担教练或指挥视角角色。

### C. 对局与英雄信息

1. 当天重点讨论英雄包括 `奶绿（Muerta）`、`德鲁伊`、`小小`。
2. 关键对局中，观众围绕装备、局势、队友崩盘、是否翻盘进行高频讨论。

### D. 场外互动信息

1. 大量观众希望主播打开摄像头。
2. 弹幕在调侃主播外形、光头、镜头感。
3. 团播人物如 `糯糯`、`瑶瑶`、`冬瓜强` 被频繁提到。

### E. 直播间氛围信息

1. `哈哈哈`、`梦幻小镇`、`坏了` 这类内容只需要作为氛围补充，不应该霸占正文主体。

---

## 10. 非目标

这套功能暂时不追求以下内容：

1. 不做逐局完整战报。
2. 不做严格赛事解说。
3. 不做全量主播百科生成。
4. 不要求每条弹幕都被解释。

重点是：

**从大量噪音弹幕里，稳定挖出当天真的有用的信息。**

---

## 11. 推荐实施顺序

后续编码建议按下面顺序推进。

### 第一步：收缩本地层职责

1. 明确哪些字段是纯本地统计。
2. 把 `哈哈哈`、`666`、相同复读句彻底从 LLM 主材料里降权。

### 第二步：新增主题证据簇

先做本地证据簇，不急着写新 prompt。

优先做：

1. 赛事相关簇
2. 位置讨论簇
3. 英雄与对局簇
4. 团播人物簇
5. 摄像头调侃簇

### 第三步：把 LLM 输出改成“先结构化，后成文”

1. 先提炼有效信息 JSON
2. 再基于 JSON 生成粉丝日报

### 第四步：最后再调文风

文风是最后一步。

在有效信息没提全之前，不要优先优化“好不好笑”“像不像整活”。

---

## 12. 一句话结论

斗鱼弹幕日报后续应该改成：

**本地做去噪、去重、统计、聚类证据；LLM 只做主播相关有效信息的语义提炼；日报文本只是最终展示层，不再让模型直接从一大堆弹幕里盲猜重点。**