abot/docs/douyu_danmu_information_refining_design.md

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

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 的输入，不再是“大量压缩后的弹幕散点”，而是以下结构。

{
  "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，再由程序拼接成日报。

建议结构如下：

{
  "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 只做主播相关有效信息的语义提炼；日报文本只是最终展示层，不再让模型直接从一大堆弹幕里盲猜重点。