Data construction playbook
我们的数据该怎么建
Slack × Twitter × 事实层
这页不是「社媒数据有没有价值」的论文，是给同事的构建手册： 按什么形状囤数据、出哪几张任务卡、怎么冻结评测。 考场骨架借 TweetEval，语料与考题是我们自己的 desk 事件。
1. 三个来源，各答一件事
一句话分工 + 一张决策表。结论先给：Slack 是主矿，Twitter 按事件配套，Reddit 只做参考。
TMTB Slack
钱怎么想
- 买盘预期 / bogey
- 敏感点与 fade 条件
- print 后定价归因
- 稀缺、自有、可训练
Twitter / X
街上演什么
- 分钟级反应
- 叙事传播与热度
- 高密度 thread
- 公开、噪声大
问题怎么讲清楚
- 长论证 / 纠错
- ELI5 类比
- 多轮讨论树
- 大众、训练受限
| 决策维度 | Slack（TMTB） | Twitter / X | |
|---|---|---|---|
| 回答什么 | 买盘预期、敏感点、定价归因 | 分钟级时间线、叙事传播 | 长论证、把问题讲清楚 |
| 对我们的独特性 | 接近唯一 | 低；事件对齐后高杠杆 | 低 |
| 可否用于训练 | 可（自有工作区） | 受限（协议禁第三方训练） | 受限（需授权） |
| 数据栈角色 | 解释层 · 主矿 | 公开层 · 事件配套 | 参考 · 不入栈 |
注意 Slack 唯一性的边界：「公司说了什么」不是 Slack 的独特价值——那去 transcript / IR（事实层）； 「数字相对谁高低」去 Street。Slack 接近唯一的是 「买盘进场前在赌什么、盘后为什么这样定价」。 所以事实层必须先于社交层存在，社交层挂在事实层之上。
2. TweetEval → 我们的方法骨架
TweetEval（Cardiff NLP，Findings of EMNLP 2020）把 7 个推文分类任务装进同一个考场： 统一 schema、固定 train/val/test、同一评测脚本——让不同模型分数可比较。 我们借它的考场，不借它的考题。
借 · 方法论
- 少量稳定任务卡，而不是无限标签
- 统一输入输出契约（一种 atom 进，结构化标签出）
- 固定 split / as-of golden，禁止随手改测集
- 同一指标做版本间纵向对比
- 正视短文本噪声：反讽、缩写、quote / RT
不借 · 任务内容
- hate / emoji / irony 等标签语义
- 拿 TweetEval 分数指导金融系统
- 单标签 F1 当唯一产品指标
- 把通用情绪当成 buyside 相关性
- 当预训练语料（它是考场不是教材）
| TweetEval 的做法 | 我们的对应 |
|---|---|
| 统一输入 schema（一条 tweet） | 统一 atom：message / tweet 带作者层级、时间戳、quote / RT / thread 结构 |
| 7 个少而稳定的任务 | 5 + 2 张任务卡（第 3 节） |
| 固定 train / val / test split | 按 event 冻结的 as-of golden；按事件切分防泄漏 |
| 同一指标（macro-F1 等） | 分任务 macro-F1 + 高代价错误率 |
| 排行榜可比较 | 内部版本回归：换 prompt / 模型后同卷重考 |
更近的近邻是 TweetFinSent（按「对某股票预期涨跌」标注，stock sentiment ≠ 情绪好坏）， 但它也只是分类任务——digest / desk 的语义与对错标准仍要自建。
3. 数据怎么建：event_pack 是唯一单位
不收散装语料。每一份进库的数据都长成同一个形状： 一个事件、一个时间窗、三层内容、少量冻结标注。
3.1 event_pack schema
3.2 三层各自的职责
- 事实层 facts：校准数字、防二手 bogey 当真值——Slack 里的数字必须能对回 transcript / Street。
- 解释层 slack：买盘框架、敏感点、定价归因——我们的差异化全部在这一层。
- 公开层 twitter：时间线、传播、热度——回答「何时起热、谁在传哪条叙事」。
低价值反例（不要这样建）：分库随机抽、无时间窗、不分层作者、没有事实层。 两个并排的语料库没有联合价值；联合价值 ≈ 事实层 × (Slack 解释力 + Twitter 时间线) × 对齐质量。
3.3 任务卡（少量、稳定，一年内不加不改）
| 级别 | 任务卡 | 问题 | 输出 / 指标 |
|---|---|---|---|
| 消息级 | relevance_to_universe | 这条和我们的股票池有关吗 | 0/1 · macro-F1 |
| 消息级 | claim_type | 事实 / 传闻 / 观点 / 玩笑 | 4 类 · macro-F1 |
| 消息级 | ticker_binding | 绑定到哪个 ticker / 主题 | 列表 · 准确率 |
| 消息级 | stance | 方向立场（仅文本显式时） | long / short / neutral / none · macro-F1 |
| 消息级 | should_surface_in_digest | 该不该进日报 | 0/1 + 理由 · F1 + 高代价错误率 |
| 事件级 | sensitivity_point | print 后哪个 KPI 主导定价 | KPI 排序 · 对照 Slack 归因 golden |
| 事件级 | bogey_vs_street | 事前买盘 bogey 与 Street 差在哪 | 结构化差值 · 对照冻结 bogey 表 |
3.4 冻结规则（TweetEval 精神）
- 按事件切分，不按消息切——同一事件的全部消息进同一侧，防止 train/test 泄漏。
- as-of golden：定稿后不改；要改只发新版本号，历史卷面保留。
- 作者集冻结 + 匿名化：作者层级进特征，真实身份不进 R2 / git。
- failure taxonomy 与分数并列：漏重大传闻、旧闻当新、RT 当原创、把 nitpick 当敏感点。
4. 一个完整例子：GOOGL 业绩包
用一场谷歌业绩演示：pack 里装什么，怎么变成训练 / 评测单元。数字为示意。
同一个 pack，产出四种单元：
| 用途 | 产出的单元 |
|---|---|
| RAG 问答 | 问「为什么数字好看还跌」→ golden 答案引 Slack 归因（capex intensity / margin），数字对回 facts 层 |
| 任务卡样本 | capex intensity 线程 → should_surface = 1；「75 vs 72」→ claim_type = opinion、should_surface = 0；事件级 → sensitivity_point = [capex intensity, margin] |
| SFT 对 | (pack 上下文) → desk 风格三段简报：事前 bogey、print 落点、盘后争议 |
| eval 对照 | 同一卷去掉 slack 层重答——量化「有无 Slack」差多少 |
对照评测里没有 Slack 层的模型有个典型失败模式：把「数字好看」直接推成「利好」， 把 GCP 75 vs 72 当头条——听得懂电话会，听不懂这场电话会在市场上意味着什么。 这正是我们数据要教掉的东西，也是任务卡 golden 的主要来源。
5. 怎么用：优先级
规模决定用法：这批数据用来做问答与微调，不做预训练主力。
| 优先级 | 用法 | 预期回报 |
|---|---|---|
| P0 | event_pack RAG（facts + Slack + Twitter 分层出答） | 问答质量立刻可见，先跑通 |
| P1 | 被 cite / 高互动样本 → SFT 简报 | 文风与优先级对齐 desk |
| P2 | DPO：好线索 vs 热闹噪音 | 降噪、防追热点 |
| P3 | 领域 LoRA（术语 / 框架） | 中等 |
| 不做 | 用社交语料大规模预训练 | 规模不够、合规紧、ROI 差 |
eval 与训练同源：holdout 的 event_pack 就是考卷（TweetEval 固定 split 的精神）。 每次换 prompt / 模型 / 检索策略，同卷重考、同指标对比；先跑「有 / 无 Slack 层」「有 / 无 Twitter 层」两组对照，再谈微调。
问答输出应长这样（分层）
6. 合规、风险、下一步
合规（2026）
- Reddit：Data API Terms 禁止未授权用于 ML / AI 训练；商业需签约——所以只做方法参考，不进主数据栈。
- X / Twitter：开发者协议禁止第三方用 API / 内容 fine-tune 或训 foundation model（xAI 自用除外）——Twitter 层按事件检索、做 RAG 与评测语境，训练用途从严。
- TMTB Slack：工作区自有、用途清晰；对外只推匿名 ledger，原始身份不进 R2 / git。
风险
- 小圈子过拟合：头部作者风格主导模型——作者分层采样。
- 同质偏见：buy-side 共识被当成真理——事实层强制对账。
- 时效衰减：季度叙事框架会变——event_pack 按季滚动，golden 只增版本。
- 二手数字：Slack bogey 必须对照 Street / transcript，不能当真值入库。
下一步（可直接排期）
- 定稿 event_pack schema v1（字段如第 3 节：window、作者层级、匿名化规则）。
- 回填 2–3 场已有完整 Slack 线程的业绩（GOOGL 起步，再加一场 semis）。
- 每张任务卡标 50–100 条，冻结 golden v1（as-of，按事件切分）。
- 跑第一轮对照 eval：有 / 无 Slack 层、有 / 无 Twitter 层，记 macro-F1 + 高代价错误率。
- 结果通过后按季度滚动建包；golden 只增版本，不改历史。