量化轮动系统建设手记（二）：新闻与事件——与限流斗智斗勇

行情数据的世界是安静的：数字、表格、收盘。而新闻数据的世界是喧闹的：每天几千条消息从几十个来源涌进来，还带着「你请求太快」的耳光。这篇记录把新闻变成可用数据的全过程——以及一场至今仍在进行的限流博弈。

一、新闻 → 板块：给每一条消息找到"归属"

要让新闻对轮动模型有用，第一步是把「一条消息」映射到「一个行业」。我们建了一张实体→行业映射词典，四层匹配、由精确到宽松：

• 股票名精确匹配：把五千多只 A 股股票名（含常见变体）直接映射到所属申万行业——新闻里提到公司，就知道它属于哪个板块；
• 知名公司手册：对非 A 股的巨头（海外科技、能源、医药等）人工维护一份映射清单；
• 行业关键词：半导体→电子、光伏→电力设备、券商→非银金融……覆盖行业类实体词；
• 大宗商品映射：原油→石油石化、黄金/铜→有色金属、焦煤→煤炭……

实际运行：1617 条词典条目，把近期新闻中「带实体的文章」的 26%完成了板块归集——其余多为人物、国家等不适合映射的实体。产出一张「板块 × 日期」的热度表（条数 + 重要性加权 + 代表性标题），每日自动刷新。

二、事件抽取引擎：把消息变成"事件"

热度只是量，事件才是质。规则版引擎把新闻归类成 8 类事件并打上方向标签：

每条事件带：日期、类型、方向（利好/利空/中性）、关联板块、相关主体。首轮跑出三千多条事件。随后上线的事件研究统计会持续计算「事件发生后 T+1/T+3/T+5 天相关板块的超额收益与命中率」——样本每天自动累积，为将来的「事件条件化」信号打地基。

三、历史新闻：两座大山

自有采集只能从「今天」开始积累，而回测需要「过去」。我们找了两条公开历史数据通道：

• Media Cloud（学术新闻数据库）：11 个主题、2015-2026 的日度报道量序列，一次入库 4.7 万行，非常顺利；
• GDELT（全球事件数据库）：同样是 2015+ 的主题日度数据，但它的 API 把我们结结实实教育了一顿。

四、GDELT 限流战：从 2340 次请求到 200 次

GDELT 文档接口对匿名调用施以极严格限流（"one every 5 seconds"），实测几个出口 IP 都会收到 429。原计划是「逐月拉取」：10 个主题 × 2 种口径 × 117 个月 = 2340 次请求——在实测出的节流节奏下，这个量级要跑几十天，基本不可行。

转折来自两个发现：

1. 「年窗口」可用：把请求窗口从一个月放大到一整年，一次就能取回全年 365 天的逐日数据，请求数从 2340 降到 200 次；
2. 多出口并行：不同服务器的出口 IP 有独立的限流额度，于是「主站 + 云主机」双通道各跑一半。

工程细节同样重要：自适应退避（被限流就等 2 分钟起步、逐级拉长，成功后立即恢复快节奏）、分片断点续跑（任何时候中断都能续）、看门狗（每 6 小时检查进程，死了自动拉起，跑完自动收工）。目前仍在后台慢慢啃这批数据——这类任务恰当的形态是「无人值守的一周」，而不是「盯一晚上」。

经验小结

• 对公开数据源要轻手轻脚：把请求数当作稀缺资源来设计（聚合优先、能一次拿完不分十次）；
• 聚合数据比全文更可持续：相比抓取全文，主题级日度序列体量小、够用、还不触红线；
• 一切长任务都要可恢复：断点水位 + 幂等写入 + 看门狗，三件套缺一不可；
• 诚实的预期管理：限流是常态，不是意外。

免责声明：本系列为个人技术研究记录，所述系统为个人研究工具，不构成任何投资建议。