geo/docs/ai-brand-monitoring-collection-feasibility-v1.md

AI 品牌监测数据抓取可行性与采集方案 V1

1. 文档信息

项目	内容
文档名称	AI 品牌监测数据抓取可行性与采集方案 V1
文档版本	V1.0
文档状态	待评审
创建日期	2026-04-05
适用范围	AI 品牌监测的数据采集、解析、可行性验证
关联文档	docs/ai-brand-monitoring-tech-design-v2.md
关联文档	docs/question-driven-monitoring-design-v1.md
验证方式	本地代码审阅 + 官方文档核验（核验日期：2026-04-05）

2. 目标与非目标

2.1 目标

本文回答三个问题：

1. 现有“品牌监测”数据抓取是否技术上可行。
2. 如果可行，主链路应该怎么设计才稳定、可扩展、可验证。
3. 哪些结果可以承诺，哪些结果不能承诺。

2.2 非目标

本文不试图解决以下问题：

1. 不承诺“100% 复刻用户在各家 APP / Web 端看到的答案、排序和引用”。
2. 不展开前端页面与汇总查询设计，这部分仍以 docs/ai-brand-monitoring-tech-design-v2.md 为主。
3. 不直接替代各平台的商务接入、法务评估和账号申请流程。

3. 核心结论

结论先说：

1. “官方 API 口径下的品牌监测”是可行的。
2. “搜索增强 / 引用型品牌监测”是部分可行的，但要按平台能力分层实现。
3. “完全等价于终端用户在 APP / Web 里看到的内容”不可承诺，至少 DeepSeek 官方已明确 API 与 APP/Web 版本不同。

因此，监测目标必须拆成三档：

档位	定义	可行性	是否建议纳入主链路
A. 标准化 API 监测	统一问题、统一温度、统一提示词，通过官方 API 取回答，再做品牌/竞品/引用解析	高	是
B. 搜索增强监测	使用平台官方搜索增强、联网搜索、引文能力，监测“搜索型回答中的品牌曝光”	中到高	是，但只对支持平台开启
C. APP/Web 拟真监测	模拟用户在各家产品前台提问，追求与终端用户体验一致	低到中	否，不建议作为主数据源

对 V2 方案的建议是：

1. 主数据源只走官方 API。
2. 搜索增强能力按平台单独开关，不搞“全平台统一假设”。
3. 如果业务一定要看终端用户视角，单独做“小样本 UI 观测集”，不要并入核心统计口径。

4. 官方能力核验结果

以下结论基于 2026-04-05 当天核验到的官方材料。

4.1 平台能力矩阵

平台	官方能力核验	可用于监测的能力	可行性判断	备注
DeepSeek	官方 API 与 OpenAI 兼容；官方文档明确 API 对应的 deepseek-chat / deepseek-reasoner 与 APP/Web 版本不同；官方 rate limit 页面说明高流量下会排队，10 分钟未开始推理会断开	标准对话、流式、工具调用入口	标准 API 监测可行；终端拟真不可承诺	适合作为“基础语言口径”，不适合作为“用户端搜索曝光”唯一来源
通义千问 / 百炼	OpenAI 兼容；支持 tools；支持 enable_search 与 search_options.forced_search；支持 Batch Chat 与文件批量提交	标准对话、函数调用、联网搜索、批量离线推理	高可行	很适合作为主力采集平台之一
豆包 / 火山方舟	官方文档明确有 Web Search（联网搜索）、Function Calling、File API；部署文档区分在线推理与批量推理；常规在线推理说明公共资源池下延迟和并发一般、共享限流	标准对话、联网搜索、工具调用、批量推理	高可行	适合做搜索型监测，但生产要避免完全依赖公共在线推理
腾讯混元	OpenAI 兼容；默认 5 并发；支持 enable_enhancement、force_search_enhancement、search_info、citation	标准对话、搜索增强、返回搜索信息、回答角标引文	能力强，但默认并发偏低	搜索引用监测非常适合，但必须提前做并发扩容或限额申请
文心一言 / 千帆	百度官方产品页确认企业服务由千帆大模型平台提供，含推理服务和工具链，并支持私有资源托管保障并发	平台接入可行	中可行，需先做 PoC	本次核验中，官方可抓取材料足以确认“能接入”，但不足以确认搜索/引文参数细节

4.2 关键判断

判断 1：能抓到数据，不代表能复刻用户端

DeepSeek 官方文档明确说 API 模型与 APP/Web 版本不同，这意味着：

1. 即使问题文案一样，回答内容也可能不同。
2. 即使回答主题相近，排序、措辞、引用也可能不同。
3. 因此不能把 API 数据直接包装成“终端用户真实看到的内容”。

判断 2：搜索增强和引用能力不是全平台对齐的

各家平台差异很大：

1. 混元已经把 search_info 和 citation 直接定义成参数。
2. 千问已明确支持 enable_search，还能强制搜索。
3. 方舟已把 Web Search 作为标准工具能力。
4. DeepSeek 在本次核验的官方材料里，没有看到同等级别的“原生联网搜索 + 引文返回”说明。
5. 百度千帆本次核验只确认了平台接入能力，搜索与引文细节仍需单独 PoC。

因此，“平台统一采集器 + 平台能力开关”是必须的，不是可选项。

判断 3：批量离线比凌晨突发跑批更靠谱

监测任务本质是离线任务，不是用户实时请求。对于大批量问题：

1. 千问官方明确提供 Batch Chat，适合“无需实时响应”的场景。
2. 方舟文档体系也区分了在线推理和批量推理。
3. 混元默认只有 5 并发，不适合把所有任务集中在 2 小时窗口内硬跑。

所以应把采集方案设计成：

1. 全天分布式执行。
2. 优先使用批量接口。
3. 只有需要搜索增强或即时补采时，才走在线 API。

5. 建议的数据抓取目标口径

5.1 统一采集单位

沿用 V1 结论，但扩展成更适合多平台的形式：

1 question_version x 1 ai_platform x 1 run_mode x 1 run_time = 1 条原始采集记录

其中 run_mode 必须显式记录：

1. api_standard
2. api_search_grounded
3. ui_sample

没有这个字段，后续所有跨平台比较都会失真。

5.2 必须采集的原始字段

建议在现有 question_monitor_runs / question_monitor_parse_results 之外，至少保证以下信息能落盘：

类别	字段
请求侧	provider_key, model, run_mode, prompt_template_version, temperature, top_p, seed, search_enabled, tool_enabled
响应侧	raw_answer_text, raw_response_json_key, response_latency_ms, finish_reason, usage_prompt_tokens, usage_completion_tokens
搜索证据	search_hit, search_provider, search_info_json, citation_markers, normalized_citations_json
解析结果	brand_mentioned, brand_position, top1_mentioned, first_recommended, competitor_mentions, sentiment_label, brand_keywords_extract
调试追踪	request_id, retry_count, error_code, error_message, parser_version, extractor_version

其中：

1. raw_answer_text 可以存对象存储。
2. raw_response_json_key 也应该存对象存储，方便 badcase 回放。
3. search_info_json 必须保留原始返回，后续才能验证引用解析是否正确。

6. 推荐抓取架构

6.1 平台适配器，而不是一个通用 LLM Client 硬扛全部平台

当前代码里 Config 只有一份全局 LLMConfig，llm.New() 也只按单个 provider 初始化客户端，这不足以支撑监测场景的多平台采集。

相关代码：

1. server/internal/shared/config/config.go
2. server/internal/shared/llm/client.go

建议改成：

type ProviderCapability struct {
    Chat            bool
    Search          bool
    Citation        bool
    ToolCalling     bool
    Batch           bool
    Streaming       bool
    Deterministic   bool
}

type MonitoringProvider interface {
    Key() string
    Capability() ProviderCapability
    Generate(ctx context.Context, req CollectRequest) (*CollectResponse, error)
    SubmitBatch(ctx context.Context, jobs []CollectRequest) (*BatchJob, error)
    PollBatch(ctx context.Context, jobID string) (*BatchJobResult, error)
}

6.2 建议的抓取链路

调度器
  -> 任务生成（按品牌 / 问题版本 / 平台 / 模式）
  -> 去重与幂等校验
  -> 队列
  -> Provider Adapter
  -> 原始响应落对象存储
  -> 标准化解析器
  -> 引用规范化
  -> 质量采样 / badcase
  -> question_monitor_runs / parse_results
  -> 日级聚合

6.3 任务状态机

必须补全任务状态，不建议只保留 pending/running/completed/failed 四态。

建议至少支持：

1. pending
2. leased
3. running
4. succeeded
5. retryable_failed
6. dead_letter
7. cancelled
8. skipped_dedup

原因：

1. 平台 API 容易超时、排队、限流。
2. 搜索增强请求比普通请求更容易波动。
3. 如果没有 retryable_failed 和 dead_letter，PoC 阶段会很难判断是平台问题还是解析问题。

6.4 幂等策略

建议幂等 key：

tenant_id + brand_id + question_version_id + ai_platform_id + run_mode + business_date

这样可以保证：

1. 同一天重复调度不会重复记账。
2. 同题跨平台不会互相覆盖。
3. api_standard 与 api_search_grounded 能并存。

7. Prompt 与解析方案

7.1 Prompt 原则

抓取时不要用自由发挥的产品提示词，要用固定模板。

建议：

1. 系统提示词固定版本化。
2. 用户问题原文直接使用 question_version.question_text。
3. 除非平台要求，否则 temperature 设为低值。
4. 能设置 seed 的平台尽量设置，提升复现性。
5. 搜索增强模式下，显式要求模型给出品牌推荐及可验证来源。

7.2 解析顺序

解析不要一上来全交给 LLM。

建议顺序：

1. 规则层：品牌名、竞品名、URL、角标、序号。
2. 轻语义层：品牌排名、首位提及、是否明确推荐。
3. LLM 兜底层：情感倾向、品牌印象词、复杂引用归因。

原因：

1. 规则层稳定、便宜、可复跑。
2. 复杂语义才需要 LLM。
3. 这样 badcase 也更容易定位。

7.3 引用解析策略

引用解析建议拆成三层：

1. 显式链接：从平台返回的 search_info、角标链接、正文 URL 中直接抽取。
2. 正文映射：把角标 [1]、[2] 映射回 search_info。
3. 规范化：统一域名、小写 host、去掉追踪参数、提取站点名、生成 citation_hash。

建议新增规范化后的引用事实结构：

{
  "url": "https://example.com/a",
  "normalized_url": "https://example.com/a",
  "domain": "example.com",
  "site_name": "Example",
  "citation_type": "editorial",
  "position": 1,
  "source": "search_info",
  "confidence": 0.98
}

8. 吞吐与调度建议

8.1 不要把采集窗口锁死在凌晨 1 点到 3 点

以 V2 的规模假设为例：

100 品牌 x 100 问题 x 5 平台 x 1 次/天 = 50,000 条/天

如果把 50,000 条任务都塞进 2 小时窗口：

1. 平均需要 6.94 req/s。
2. 算上超时、重试、抖动，实际需要按 15~20 req/s 设计。
3. 对默认 5 并发的混元，这个窗口过于激进。

因此建议：

1. 日常采集分 6 个时间窗执行，或者全天滚动执行。
2. 重要品牌再补一轮搜索增强采集。
3. 聚合 Job 与采集 Job 解耦，不要求同一夜全部完成。

8.2 平台分流策略

建议把平台分成三类：

类别	平台	建议方式
标准对话主链路	DeepSeek	在线 API，低温、固定 prompt
搜索增强主链路	千问、混元、方舟	优先开官方搜索能力
待验证平台	百度千帆	先做 PoC，不直接承诺上线指标

8.3 批量优先级

建议优先级：

1. 能批量就批量。
2. 需要搜索增强或引用时再走在线 API。
3. 需要“接近用户侧”验证时，只做样本观测，不做全量。

9. PoC 可行性验证方案

这部分是本方案最核心的落地动作。

9.1 PoC 目标

在决定正式开发前，先验证四件事：

1. 各平台能否稳定返回可解析的回答。
2. 搜索增强模式下能否拿到可追溯引用。
3. 同一个问题多次执行时，结果波动是否在可接受范围内。
4. 成本、时延、失败率是否可控。

9.2 PoC 样本设计

建议最小样本：

1. 3 个品牌
2. 每品牌 30 个问题
3. 5 个平台
4. 2 种模式：api_standard、api_search_grounded
5. 连续跑 3 天

总任务量：

3 x 30 x 5 x 2 x 3 = 2,700

这个规模足够看出：

1. 平台成功率
2. 搜索命中率
3. 引用解析效果
4. 回答波动

9.3 PoC 验收指标

建议先用下面的阈值：

指标	目标
API 调用成功率	>= 97%
解析成功率	>= 99%
搜索增强模式下“存在可用引用”的比例	>= 60%
品牌提及检测准确率	>= 95%
引用 URL 规范化成功率	>= 95%
单任务 P95 延迟	<= 20s
重试后仍失败率	<= 2%

如果某平台低于阈值：

1. 不要强行并入统一统计。
2. 先降级成“样本观测平台”。

9.4 PoC 输出物

PoC 结束后必须产出：

1. 平台能力对比表
2. badcase 样本集
3. 成本与时延报告
4. 建议上线的平台白名单

10. 建议补充的数据表

V2 当前只覆盖了运行表和解析表，若要把抓取做扎实，建议再补三类表：

10.1 monitoring_collect_tasks

用途：

1. 存调度任务
2. 管理状态机
3. 支撑重试、死信、优先级

10.2 monitoring_citation_facts

用途：

1. 保存规范化后的引用事实
2. 便于后续按域名、站点、页面统计
3. 避免每次都从 JSONB 重新解析

10.3 monitoring_parse_badcases

用途：

1. 保存低置信度或人工标错样本
2. 支撑解析器迭代
3. 给后续模型评测提供数据集

11. 实施建议

Phase A：两周内完成 PoC

1. 先接 3 个最清晰的平台：千问、混元、方舟。
2. DeepSeek 只做 api_standard。
3. 百度千帆只做可接入性验证，不承诺引用链路。

Phase B：收敛主链路

1. 形成统一 MonitoringProvider 抽象。
2. 完成搜索增强、引用解析、规范化。
3. 上线 badcase 采样与抽检。

Phase C：再决定是否做 UI 观测

只有当业务方明确要求“终端用户真实视角”时，才考虑单独建设 UI 观测链路；且必须先做：

1. 法务 / ToS 评估
2. 账号稳定性评估
3. 样本规模评估

它不应进入 V1 主数据链路。

12. 对现有 V2 方案的直接修正建议

基于本文结论，建议对 docs/ai-brand-monitoring-tech-design-v2.md 做以下修正：

1. 把“采集流水线”从通用 llm.Client 调整为“平台适配器 + 能力开关”。
2. 增加 run_mode 字段，区分标准模式与搜索增强模式。
3. 增加任务表、死信策略、重试退避、幂等 key。
4. 不再默认所有平台都能产出引用来源数据。
5. 把凌晨集中跑批改成“滚动采集 + 批量优先”。
6. 在上线前增加 PoC 验收阶段，而不是直接进入全量开发。

13. 官方核验链接

以下均为本次用于判断可行性的官方材料：

1. DeepSeek API Docs: https://api-docs.deepseek.com/
2. DeepSeek Rate Limit: https://api-docs.deepseek.com/quick_start/rate_limit
3. 阿里云百炼 OpenAI 兼容: https://help.aliyun.com/zh/model-studio/compatibility-of-openai-with-dashscope
4. 阿里云百炼 Batch Chat: https://help.aliyun.com/zh/model-studio/openai-compatible-batch-chat
5. 腾讯混元 OpenAI 兼容接口: https://cloud.tencent.com/document/product/1729/111007
6. 火山方舟 Web Search: https://www.volcengine.com/docs/82379/1756990
7. 火山方舟常规在线推理: https://www.volcengine.com/docs/82379/2121998
8. 百度文心一言 / 千帆平台: https://cloud.baidu.com/wenxin.html

14. 最终结论

一句话总结：

这件事能做，但必须把“官方 API 监测”与“终端用户视角监测”分开设计。

对当前项目最现实的路线是：

1. 先做基于官方 API 的标准化品牌监测。
2. 对具备官方搜索能力的平台，叠加搜索增强与引用监测。
3. 用 PoC 决定百度千帆是否进入第一批上线平台。
4. 不把 APP/Web 前台抓取作为主链路承诺项。