熔岩概念成分提及排行的 days 回看陷阱：get_concept_stock_heat 读数的 10 个坑
摘要
熔岩（Lava）的概念成分提及排行 GET /concepts/stocks（MCP 工具 get_concept_stock_heat）回答的是：在某个概念下，最近哪些股票被提到最多、有多少机构/大V 提到。它有一个看似简单的参数 days：默认 30，范围 1～365。正是这个参数，加上 limit 上限、约 10 分钟的更新节奏和概念名精确匹配，造成了大量「两次查询对不上」「榜单突然换人」的困惑。本文用坑位清单的形式逐条列出，每一条都给出现象、原因和处理方式。所有数字均为示例，概念名使用「示例概念甲」等虚构名称。
先认清这张表在熔岩里的位置
熔岩的消息面数据分几块：全市场热度（个股热榜、加速榜、首提流、加权热榜）、个股热度（/opinions、/heat/windows、/panel/daily）、概念板块、机构/大V 评分（含 PIT 截面）与新闻点名。概念板块内部又有三条只读路径：
| MCP 工具 | HTTP 路径 | 时间参数 | 条数 | 更新 |
|---|---|---|---|---|
get_market_hot_concepts |
/hot/concepts |
window：1h / 4h / 18h / 24h / 3d，默认 24h，没有 7d |
默认 50，最大 200 | 约 2 分钟 |
get_concept_stock_heat |
/concepts/stocks |
days：默认 30，范围 1～365 |
默认 50，最大 100 | 约 10 分钟 |
get_stock_concept_heat |
/concepts/by-stock |
days：默认 90，范围 1～365 |
默认 30，最大 200 | 以接口返回为准 |
/concepts/stocks 的 concept 参数必填，精确匹配，长度不超过 30 字符。下面的坑大多围绕这张表展开。
坑 1：把「提及排行」当成官方成分表
现象：某只常被归入该概念的股票不在返回列表里。
原因：返回的是消息面里被提及的股票，不是交易所或指数公司的成分表。回看期内没被讨论的股票自然不会出现。
处理：在研究表里把这一列命名为「概念提及成分（days=N）」，不要命名为「概念成分」。需要官方成分时用你自有的数据源。
坑 2：不写 days 就默认是「最近」
现象：同事说「这个概念最近最热的是 A」，你查出来却是 B。
原因：一方用了默认 days=30，另一方传了 days=7。30 天的排行被月初的一次集中讨论主导，7 天的排行反映的是本周。
处理：任何引用都带上 days。示例写法：「示例概念甲，days=7，提及第 1 名」。
坑 3：长回看把旧事件「冻」在榜首
现象：days=90 或更长时，榜首长期不变。
原因：回看越长，单次大事件的累计提及越难被稀释。示例：某股 60 天前一次事件贡献了 300 次提及（示例数字），之后每天只有个位数，在 days=90 下仍可能排第一。
处理：长回看用于「这个概念长期由谁承载讨论」，短回看用于「最近谁在承载」。要看变化，把 7/30/90 三档并列，而不是只看一档。
坑 4：短回看的样本太薄
现象：days=1 的排行每次刷新都在大幅换人。
原因：一天内概念下的讨论条数可能很少，第 5 名和第 30 名只差一两次提及，名次对噪声非常敏感。
处理：短回看只读前几名，并同时看提及数本身；需要日内结构时，改用单股的 /heat/windows（1h 到 7d 六档加 hourly_24h）。
坑 5：days 与 window 混为一谈
现象：把 /hot/concepts?window=3d 的概念热度和 /concepts/stocks?days=3 的成分排行直接对比，觉得数字「对不上」。
原因：window 是滚动小时窗口，days 是以天计的回看；两者统计对象也不同，一个是概念整体，一个是概念下各股票。
处理：对账时只做同一接口内的比较。跨接口只比较方向和覆盖面，不比较绝对数。
坑 6：limit 上限 100 被忽视
现象：想取概念下「全部被提及股票」，结果只有 50 条或 100 条。
原因：limit 默认 50，最大 100，且没有文档化的分页偏移参数。
处理：若研究定义是「概念下全部提及股票」，就要在表头写清「前 100 名」；不要假设可以翻页。概念特别大时，可以缩短 days 让排行更集中，或从个股侧用 /concepts/by-stock 反查。
坑 7：在 10 分钟更新周期内反复刷新
现象：脚本每分钟拉一次，结果大多相同，费用却在增长。
原因：该接口约 10 分钟更新一次；成功调用每次按 0.005 元计费。
处理：轮询间隔至少 10 分钟，用内容哈希判断是否有变化，没变化就不落新快照。示例：一天盘中 4 小时按 10 分钟间隔约 24 次，按 1 分钟间隔是 240 次，后者大部分是重复数据。
坑 8：概念名不精确导致的「空榜」
现象：返回空列表或参数错误。
原因：concept 精确匹配。「示例概念甲」能查到，「示例概念甲概念」「示例 概念甲」未必能查到；全半角、空格、超过 30 字符都会失配。
处理：概念名一律从 /hot/concepts 或 /concepts/by-stock 的返回值复制，并在本地保存规范名表。空结果要如实记录为「该参数下无匹配」，不要换近似词反复试。
坑 9：把不同时刻的两次快照当成同一截面
现象：上午与下午各取一次 days=30，名次变化被解读为「讨论转移」。
原因：回看窗口在滑动，旧的一天移出、新的一天移入；上午与下午之间还经过了若干次数据更新。
处理：每次快照保存 meta.server_time 与 meta.request_id。比较「成分变化」时，固定每天同一时点取数，并把进入、退出分开统计。
坑 10：用 days 的回看去做回测
现象：拿今天取到的 days=30 排行，当成 30 天前那一天的概念成分。
原因：接口没有 as_of_date，回看窗口以取数时刻为终点。今天的结果包含了 30 天前那一天之后的讨论。
处理：历史研究改用日频面板 /panel/daily（get_stock_heat_panel）：type=stock 配 codes（单次最多 20 个）逐股取自然日序列，或 type=concept 配 names 取概念级序列，区间最长 92 天。若需要高分机构/大V 口径的历史截面，用 /hot/weighted 的 as_of_date（消息截至当天 15:00）或 /agencies/pit。
一个把 7/30/90 并列的取数示例
# concept_days_ladder.py —— 示例，地址与令牌为占位
import os, requests
BASE = os.environ.get("LAVA_BASE", "<YOUR_LAVA_BASE>/subscribe/v1")
H = {"Authorization": "Bearer " + os.environ.get("LAVA_API_KEY", "<YOUR_TOKEN>")}
CONCEPT = "示例概念甲" # 必须是从 /hot/concepts 复制的规范名
def members(days):
r = requests.get(BASE + "/concepts/stocks",
params={"concept": CONCEPT, "days": days, "limit": 100},
headers=H, timeout=60).json()
if not r.get("ok"):
return None, r.get("code")
rows = r["data"] if isinstance(r["data"], list) else r["data"].get("list", [])
# 成员标识与提及数列名以 OpenAPI 为准
return [x.get("ts_code") or x.get("stock_name") for x in rows], r["meta"]["server_time"]
ladder = {d: members(d) for d in (7, 30, 90)}
s7, s30, s90 = (set(ladder[d][0] or []) for d in (7, 30, 90))
print("三档共同:", len(s7 & s30 & s90), "仅 7 天:", len(s7 - s30 - s90))
示例读法：三档共同出现 18 只、仅在 7 天档出现 6 只（示例数字）。前者是该概念讨论的「长期承载者」，后者是「最近才被带进讨论的股票」。这种分层只描述讨论结构，不涉及任何取舍建议。
坑位速查表
| 编号 | 坑 | 一句话处理 |
|---|---|---|
| 1 | 提及排行当成官方成分 | 列名写「概念提及成分（days=N）」 |
| 2 | 不写 days |
引用时必带 days |
| 3 | 长回看冻住旧事件 | 7/30/90 三档并列 |
| 4 | 短回看样本薄 | 只读前几名，同时看提及数 |
| 5 | days 与 window 混用 |
只在同一接口内对账 |
| 6 | limit 上限 100 |
表头写「前 100 名」，不假设翻页 |
| 7 | 10 分钟内反复刷新 | 间隔 ≥10 分钟 + 内容哈希 |
| 8 | 概念名不精确 | 从热榜或个股关联概念复制规范名 |
| 9 | 不同时刻快照混比 | 固定时点 + 保存 server_time |
| 10 | 用回看做回测 | 改用 /panel/daily 或 PIT 接口 |
与个股反查配合：双向核对
概念 → 个股（/concepts/stocks）与个股 → 概念（/concepts/by-stock）是同一关系的两个方向，但默认回看不同：前者 days 默认 30，后者默认 90。双向核对时如果不统一 days，就会出现「概念榜里有这只股票，反查这只股票却看不到该概念排在前面」的假矛盾。
建议的核对步骤（示例）：
- 对「示例概念甲」调用
get_concept_stock_heat(concept="示例概念甲", days=30, limit=100)，取前 10 名代码； - 对这 10 只逐一调用
get_stock_concept_heat(ts_code=<代码>, days=30)，注意显式传days=30，不要用默认 90； - 检查「示例概念甲」在每只股票的关联概念里排第几；排名靠后说明该股的讨论主要由其他概念承载，示例概念甲只是它的次要标签；
- 把两边的
meta.server_time都记下，两者更新节奏不同，时间差过大时重新取数。
这一步共 11 次调用，按每次 0.005 元计约 0.055 元（示例估算）。概念板块与个股热度两块数据由此连成一张可解释的关系表。
FAQ
Q：/concepts/stocks 支持 min_score 吗？
A：是否支持以 OpenAPI 为准。需要高分机构/大V 口径时，可以在概念热榜 /hot/concepts 上加 min_score 观察，或对成分股逐只查看 /heat/windows（高分线默认 1050）。
Q：概念热榜没有 7d，周度怎么看？
A：用 /concepts/stocks 的 days=7 看概念下个股的周度提及，或用 /panel/daily 且 type=concept 看概念级日频序列，不要给 /hot/concepts 传未列出的窗口值。
Q：同一只股票在两个概念里排名都很高，怎么解释？
A：一条讨论可能同时涉及多个概念，股票也可能关联多个概念。用 /concepts/by-stock 查看它关联的全部概念及提及，比在两个概念榜之间来回比较更清楚。
Q：days 直接设成 365 有意义吗？
A：范围允许到 365，适合回答「一年里这个概念主要由哪些股票承载讨论」。但它几乎不反映近期变化，且受 limit 最大 100 限制，长尾会被截掉。建议把 365 档当作背景参照，与 7 天、30 天档一起读，而不是单独使用。
结论
get_concept_stock_heat 是一张「概念下谁被讨论」的提及排行，读数高度依赖 days。记住几条口径：默认 30、范围 1～365；limit 最大 100；约 10 分钟更新；概念名精确匹配且不超过 30 字符；没有 as_of_date，不能直接拿来回测。把 7/30/90 三档并列、每次快照带上参数与时间，就能避开本文列出的大多数坑。
数据来自熔岩消息面热度监测，仅供研究参考，不构成投资建议。
Comments
Join the discussionNo comments yet. Be the first to comment.