补充斗鱼弹幕日报信息提纯设计文档

- 明确本地统计与LLM语义提炼的职责边界 - 重新定义弹幕日报的数据分层、证据簇和结构化输出方案 - 约束后续实现优先提炼有效信息而非直接生成文风总结
2026-04-29 14:34:31 +08:00
parent 625d37018b
commit 44cd42d5f7
1 changed files with 440 additions and 0 deletions
--- a/docs/douyu_danmu_information_refining_design.md
+++ b/docs/douyu_danmu_information_refining_design.md
@@ -0,0 +1,440 @@
+# 斗鱼弹幕日报信息提纯设计
+
+## 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 只做主播相关有效信息的语义提炼；日报文本只是最终展示层，不再让模型直接从一大堆弹幕里盲猜重点。**