geo/docs/question-driven-monitoring-design-v1.md

GEO 平台问题驱动的数据监控设计 V1

1. 文档信息

项目	内容
文档名称	GEO 平台问题驱动的数据监控设计 V1
文档版本	V1.0
文档状态	待评审
创建日期	2026-03-25
适用范围	品牌词库、问题集、数据追踪页
关联文档	docs/geo-platform-prd-v1.md
关联文档	docs/geo-platform-tech-architecture-v1-50k.md

2. 设计背景

当前数据监控页不是通用 BI，而是明确来源于：

• 品牌
• 关键词
• 关键词下的问题集
• 模型
• 最近 30 天时间窗口

因此，数据监控的真实逻辑源头不是“文章”本身，也不是“关键词”本身，而是：

• 品牌关键词下配置的问题
• 系统按周期执行这些问题后的模型回答结果

这意味着整套监控系统必须按“问题驱动”来设计，否则后续会出现：

• 指标口径不清
• 历史数据与问题版本混淆
• 任务量失控
• 查询逻辑和数据模型对不上

3. 核心结论

V1 建议采用以下原则：

1. 问题 是监控数据的最小采集单元。
2. 关键词 只是问题集合的容器和聚合维度。
3. 品牌监控页 展示的是问题运行结果的聚合视图。
4. 历史数据必须绑定问题版本，不能因为改了问题文案就覆盖历史口径。
5. 页面查询只查汇总表，不扫描原始问答记录。

4. 页面逻辑拆解

结合当前页面，用户选择条件是：

• 品牌
• 关键词
• 模型
• 时间范围，最多近 30 天

页面展示内容包括：

• 提及率
• 首位提及率
• 首选推荐率
• 正面提及率
• 日趋势折线
• 高频问题
• 引用排行榜

这些数据不应该直接从原始问答明细实时计算，而应该来自预聚合结果。

5. 数据采集逻辑

5.1 问题来源

问题来源于品牌词库中的关键词问题集。

例如：

• 品牌：12
• 关键词：数字时尚
• 问题：
  • 数字时尚品牌有哪些值得关注的新趋势
  • 如何选择适合自己的数字时尚单品
  • 数字时尚和传统时尚的主要区别是什么

这些问题是监控任务的输入，不是单纯展示内容。

5.2 采集单元

建议将一次监控采集定义为：

• 一个问题
• 一个模型
• 一次执行时间

即：

1 question x 1 model x 1 run_time = 1 条原始监控记录

5.3 指标来源

每次模型回答返回后，系统进行解析，得到结构化结果：

• 是否提及品牌
• 是否首位提及品牌
• 是否首选推荐品牌
• 情感倾向是否正向
• 是否引用系统文章
• 引用了哪篇文章

然后再做日级汇总。

6. 推荐数据模型

6.1 主数据表

brand_keywords

• id
• brand_id
• name
• status
• created_at

brand_questions

• id
• brand_id
• keyword_id
• current_version_id
• status
• created_at

说明：

• 一条问题属于一个品牌和一个关键词
• 数据监控页中的“高频问题”和“问题集”都可以从这里关联出来

brand_question_versions

• id
• question_id
• question_text
• question_hash
• version_no
• is_active
• created_at

说明：

• 问题文案一旦修改，新增版本，不覆盖历史版本
• 历史监控记录绑定到具体 question_version_id

6.2 原始采集表

question_monitor_runs

• id
• brand_id
• keyword_id
• question_id
• question_version_id
• model_id
• run_date
• run_at
• task_batch_id
• status
• raw_answer_storage_key
• created_at

说明：

• 一次执行一条记录
• 模型原始回答建议放对象存储，数据库只存引用路径和摘要字段

question_monitor_parse_results

• id
• run_id
• mentioned_brand
• top1_mentioned
• first_recommended
• positive_mentioned
• citation_article_count
• citation_platform_count
• parser_version
• created_at

说明：

• 解析结果是后续聚合的直接来源

6.3 汇总表

question_model_daily_metrics

粒度：

• brand_id + keyword_id + question_id + question_version_id + model_id + date

字段：

• ask_count
• mention_count
• top1_mention_count
• first_recommend_count
• positive_mention_count
• citation_count
• updated_at

用途：

• 回看单个问题在每天的表现
• 支撑高频问题排行和问题详情

keyword_model_daily_metrics

粒度：

• brand_id + keyword_id + model_id + date

字段：

• question_count
• ask_count
• mention_count
• top1_mention_count
• first_recommend_count
• positive_mention_count
• citation_count
• mention_rate
• top1_mention_rate
• first_recommend_rate
• positive_mention_rate
• updated_at

用途：

• 直接支撑你截图里的 30 天趋势和顶部指标卡

keyword_model_top_questions_daily

粒度：

• brand_id + keyword_id + model_id + date + question_id

字段：

• question_text_snapshot
• ask_count
• mention_count
• score

用途：

• 支撑右侧“高频问题”

keyword_model_citation_rank_daily

粒度：

• brand_id + keyword_id + model_id + date + cited_article_id

字段：

• citation_count
• citation_rate

用途：

• 支撑引用排行榜

7. 查询口径定义

7.1 顶部指标卡

以所选：

• 品牌
• 关键词
• 模型
• 时间范围

为过滤条件，从 keyword_model_daily_metrics 汇总得出：

• 提及率 = sum(mention_count) / sum(ask_count)
• 首位提及率 = sum(top1_mention_count) / sum(ask_count)
• 首选推荐率 = sum(first_recommend_count) / sum(ask_count)
• 正面提及率 = sum(positive_mention_count) / sum(ask_count)

7.2 趋势图

直接查询 keyword_model_daily_metrics 最近 30 天数据。

每个点只是一行日汇总，查询量很小。

7.3 高频问题

从 keyword_model_top_questions_daily 取最近 30 天累计 TopN。

7.4 引用排行榜

从 keyword_model_citation_rank_daily 取最近 30 天累计 TopN。

8. 任务调度设计

8.1 为什么要控制任务量

监控任务量不是由页面访问量决定，而是由：

• 品牌数
• 每个品牌下关键词数
• 每个关键词下问题数
• 模型数
• 每天执行次数

共同决定。

8.2 数据量公式

每日原始采集量近似为：

品牌数 x 每品牌关键词数 x 每关键词问题数 x 模型数 x 每日执行次数

例如：

轻量场景

• 50 个品牌
• 每品牌 10 个关键词
• 每关键词 10 个问题
• 5 个模型
• 每天 1 次

则：

50 x 10 x 10 x 5 x 1 = 25,000 条/天

中等场景

• 100 个品牌
• 每品牌 20 个关键词
• 每关键词 20 个问题
• 5 个模型
• 每天 2 次

则：

100 x 20 x 20 x 5 x 2 = 400,000 条/天

如果每条原始回答按 5KB 估算：

• 每天约 2GB 原始文本
• 30 天约 60GB 原始文本

因此：

• 原始回答不建议长期放 PostgreSQL
• 建议放对象存储
• PostgreSQL 只保存解析结果和汇总结果

8.3 V1 推荐执行频率

为了控制数据量，V1 建议：

• 每个问题每天默认执行 1 次
• 重要品牌或付费用户可提升为 2 次
• 不建议 V1 做高频小时级轮询

8.4 去重策略

如果同一品牌下多个关键词出现完全相同的问题文案，建议：

• 通过 question_hash 检测重复问题
• 同一品牌、同一模型、同一天内同 hash 的问题尽量复用一次执行结果

但聚合归属仍可按映射关系分别记账。

这样可以显著减少任务量。

9. 版本与历史口径

9.1 为什么必须版本化

如果用户把问题：

• “数字时尚品牌有哪些值得关注的新趋势”

改成：

• “2026 年数字时尚品牌有哪些值得关注的新趋势”

那前后两者其实已经不是同一个监控口径。

如果直接覆盖旧问题，历史趋势就会失真。

9.2 推荐做法

• 问题修改时新建 question_version
• 新运行记录绑定到新版本
• 历史数据仍归属旧版本
• 页面默认展示当前版本问题的聚合数据

如果要做历史总览，可按 question_id 聚合，但需要在文档里说明“跨版本聚合”。

10. 页面查询策略

10.1 页面不查原始表

数据页不能直接查：

• question_monitor_runs
• question_monitor_parse_results

这些表只用于：

• 问题详情
• badcase 回放
• 算法验证

10.2 页面只查汇总表

数据页查询路径应为：

1. 先查 Redis
2. Redis miss 后查 PostgreSQL 汇总表
3. 后台异步更新缓存

10.3 Redis Key 建议

可按以下维度缓存：

• brand:{brand_id}:keyword:{keyword_id}:model:{model_id}:range:30d:summary
• brand:{brand_id}:keyword:{keyword_id}:model:{model_id}:range:30d:trend
• brand:{brand_id}:keyword:{keyword_id}:model:{model_id}:range:30d:top_questions
• brand:{brand_id}:keyword:{keyword_id}:model:{model_id}:range:30d:citation_rank

11. V1 性能判断

针对当前页面，如果采用“按问题采集、按天汇总、按 30 天查询”的模型，PostgreSQL 是够用的。

原因是：

• 页面查询只查 30 天汇总数据
• 每次查询最多几十到几百行
• 高频问题和排行榜都可提前汇总
• Redis 可以承接高频重复查询

真正可能变大的不是页面查询，而是：

• 原始问题执行任务量
• 原始模型回答存储量

所以要重点控制的是任务调度和原始结果留存，而不是页面 SQL 本身。

12. V1 推荐保留策略

建议：

• 原始运行记录保留 30 ~ 90 天
• 原始回答正文放对象存储
• PostgreSQL 解析结果保留 90 天
• 日级汇总表保留 180 天 或更久

如果页面只看 30 天，也建议汇总表多保留一段时间，方便后续扩展。

13. 升级边界

当出现以下情况时，再升级架构：

• 问题量暴涨
• 模型数明显增加
• 每日执行次数明显增加
• 页面支持自由筛选、明细钻取
• 监控维度从 30 天扩展到半年、一年

此时可以逐步升级为：

• 独立分析库
• 更大规模任务调度
• 更复杂的去重复用逻辑
• 专用分析引擎

14. V1 最终建议

结合你当前页面和品牌词库结构，V1 最合理的设计是：

1. 以 问题 为最小监控采集单元。
2. 以 关键词 作为问题的聚合容器。
3. 以 问题版本 保证历史口径稳定。
4. 以 日级汇总表 支撑页面查询。
5. 以 对象存储 保存原始回答，避免 PostgreSQL 膨胀。
6. 以 问题 hash 去重 控制执行量。
7. 默认每题每天执行 1 次，避免 V1 数据量失控。

这样做，逻辑、数据量、页面性能三者才能对齐。