03a | AI可见性监测系统 - 技术规格书
内部机密 | 返回 技术壁垒与产品化路线 | 返回 报告目录
目录
1. 系统概述
1.1 系统定位
AI可见性监测系统是GEO SaaS平台的 P0核心模块,负责持续追踪品牌在多个AI平台(DeepSeek、豆包、Kimi、文心一言、ChatGPT、Perplexity、Gemini)中的可见性表现。该系统是整个平台的数据基座,为内容优化引擎(P1)、幻觉检测系统(P2)、竞品对标分析(P2)提供底层数据支撑。
1.2 系统边界
1.3 设计目标
| 目标 | 指标 | 说明 |
|---|---|---|
| 并发品牌数 | 200+ | 同时监测200个以上品牌 |
| 查询延迟 | <1min | 从Prompt发出到结果入库 |
| 平台覆盖 | 7+ | 中国4个 + 海外3个AI平台 |
| 语种支持 | 4种 | 中文、日文、韩文、英文 |
| 数据准确率 | >95% | 品牌提及检测的准确率 |
| 系统可用性 | 99.5% | 月度SLA |
2. API接口设计
2.1 API总览
所有接口遵循RESTful规范,基础路径为 /api/v1,认证方式为 Bearer Token(JWT)。
2.2 品牌管理接口
POST /api/v1/brands - 创建品牌
// Request
{
"name": "资生堂",
"category": "beauty",
"market": ["jp", "cn", "kr"],
"aliases": [
{"name": "Shiseido", "language": "en"},
{"name": "しせいどう", "language": "ja"},
{"name": "시세이도", "language": "ko"}
],
"competitors": ["SK-II", "雪花秀", "POLA"]
}
// Response 201
{
"id": "brand_8f3a2b1c",
"name": "资生堂",
"category": "beauty",
"aliases": [...],
"competitors": [...],
"created_at": "2026-04-15T08:30:00Z"
}GET /api/v1/brands - 品牌列表
查询参数: page, page_size, category, market
PUT /api/v1/brands/{brand_id} - 更新品牌配置
DELETE /api/v1/brands/{brand_id} - 删除品牌
2.3 监测任务接口
POST /api/v1/monitoring/tasks - 创建监测任务
// Request
{
"brand_id": "brand_8f3a2b1c",
"platforms": ["deepseek", "chatgpt", "perplexity", "gemini"],
"languages": ["zh", "ja", "en"],
"prompt_template_ids": ["tpl_001", "tpl_002", "tpl_003"],
"schedule": {
"type": "recurring",
"cron": "0 */6 * * *"
}
}
// Response 201
{
"task_id": "task_a1b2c3d4",
"status": "scheduled",
"next_run_at": "2026-04-15T12:00:00Z",
"estimated_cost_per_run": 0.42
}GET /api/v1/monitoring/tasks/{task_id}/status - 查询任务状态
// Response 200
{
"task_id": "task_a1b2c3d4",
"status": "running",
"progress": {
"total_queries": 84,
"completed": 67,
"failed": 2,
"pending": 15
},
"started_at": "2026-04-15T12:00:01Z"
}2.4 结果查询接口
GET /api/v1/visibility/scores - 可见性得分查询
查询参数: brand_id, platform, language, start_date, end_date, granularity(hourly/daily/weekly)
// Response 200
{
"brand_id": "brand_8f3a2b1c",
"period": {"start": "2026-04-01", "end": "2026-04-15"},
"overall_score": 72.5,
"scores_by_platform": [
{"platform": "chatgpt", "score": 78.3, "trend": "+2.1"},
{"platform": "deepseek", "score": 65.8, "trend": "-1.4"},
{"platform": "perplexity", "score": 81.2, "trend": "+5.3"}
],
"time_series": [
{"date": "2026-04-01", "score": 70.1},
{"date": "2026-04-02", "score": 71.3}
]
}GET /api/v1/visibility/mentions - 品牌提及详情
查询参数: brand_id, platform, prompt_id, sentiment, page, page_size
GET /api/v1/visibility/competitors - 竞品对比数据
查询参数: brand_id, competitor_ids, platform, date_range
2.5 Prompt模板接口
POST /api/v1/prompts/templates - 创建Prompt模板
// Request
{
"name": "product_recommendation",
"category": "beauty",
"template": "推荐一款适合{skin_type}的{product_type},预算在{budget}左右",
"variables": ["skin_type", "product_type", "budget"],
"languages": ["zh", "ja", "en", "ko"],
"tags": ["recommendation", "skincare"]
}GET /api/v1/prompts/templates - 模板列表
POST /api/v1/prompts/generate - 从模板批量生成Prompt
3. 数据模型设计
3.1 ER关系图
3.2 核心表字段说明
Brand(品牌表)
| 字段 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | VARCHAR(32) | PK | 品牌唯一标识,格式 brand_xxxx |
| tenant_id | VARCHAR(32) | FK, NOT NULL | 所属租户 |
| name | VARCHAR(200) | NOT NULL | 品牌主名称 |
| category | VARCHAR(50) | NOT NULL | 品类(beauty, electronics, food等) |
| markets | JSONB | 目标市场列表 ["jp","cn","kr"] | |
| created_at | TIMESTAMPTZ | NOT NULL | 创建时间 |
| updated_at | TIMESTAMPTZ | NOT NULL | 更新时间 |
AIResponse(AI回答表)
| 字段 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | VARCHAR(32) | PK | 回答唯一标识 |
| prompt_id | VARCHAR(32) | FK, NOT NULL | 关联的Prompt |
| platform_id | VARCHAR(32) | FK, NOT NULL | AI平台标识 |
| response_text | TEXT | NOT NULL | AI回答全文 |
| latency_ms | INTEGER | API响应延迟(毫秒) | |
| cost | DECIMAL(10,6) | 本次查询成本(USD) | |
| metadata | JSONB | 模型版本、token数等元信息 | |
| queried_at | TIMESTAMPTZ | NOT NULL | 查询时间,用于时序分区键 |
VisibilityScore(可见性得分表)
| 字段 | 类型 | 约束 | 说明 |
|---|---|---|---|
| id | VARCHAR(32) | PK | 得分记录标识 |
| brand_id | VARCHAR(32) | FK, NOT NULL | 品牌标识 |
| platform_id | VARCHAR(32) | FK | 平台标识,NULL表示跨平台聚合 |
| overall_score | FLOAT | NOT NULL | 综合可见性得分(0-100) |
| mention_rate | FLOAT | 品牌提及率 | |
| avg_position | FLOAT | 平均推荐排位 | |
| sentiment_avg | FLOAT | 情感均值 | |
| share_of_voice | FLOAT | 声量占比 | |
| citation_accuracy | FLOAT | 引用准确率 | |
| cross_platform_consistency | FLOAT | 跨平台一致性 | |
| score_date | DATE | NOT NULL | 得分日期,分区键 |
| granularity | VARCHAR(10) | NOT NULL | 粒度: hourly/daily/weekly |
4. Prompt调度引擎
4.1 架构设计
Prompt调度引擎负责将模板转化为具体的查询Prompt,并按照成本最优路径分发到多个AI平台执行。核心组件包括:
- 模板渲染器:将Prompt模板与变量组合,生成多语种Prompt实例
- 调度器:基于cron表达式或事件触发的任务编排器
- 路由器:根据平台状态、成本、速率限制选择最优执行路径
- 限流器:per-platform的Token Bucket速率控制
- 重试管理器:指数退避重试 + 死信队列
4.2 调度流程
4.3 成本优化路由策略
路由器按以下优先级选择平台执行顺序:
| 优先级 | 条件 | 策略 |
|---|---|---|
| 1 | 平台健康度 | 跳过过去5分钟内错误率 >20% 的平台 |
| 2 | 速率余量 | 优先选择当前窗口内余量 >50% 的平台 |
| 3 | 单次查询成本 | 在同等条件下选择成本最低的平台 |
| 4 | 历史响应延迟 | 选择P95延迟 <5s 的平台 |
4.4 速率限制配置
| 平台 | RPM限制 | 日配额 | 退避策略 |
|---|---|---|---|
| ChatGPT | 60 | 10,000 | 指数退避 + jitter |
| DeepSeek | 100 | 50,000 | 线性退避 |
| Perplexity | 40 | 5,000 | 指数退避 |
| Gemini | 60 | 15,000 | 指数退避 + jitter |
| 豆包 | 80 | 20,000 | 线性退避 |
| Kimi | 50 | 10,000 | 指数退避 |
| 文心一言 | 60 | 10,000 | 指数退避 |
5. 回答解析流水线
5.1 流水线架构
5.2 品牌提及检测详细逻辑
检测按以下优先级顺序执行,匹配命中后标记 match_type 和 confidence:
| 匹配方式 | 算法 | 置信度 | 示例 |
|---|---|---|---|
| 精确匹配 | 字符串全匹配(大小写不敏感) | 1.0 | ”Shiseido” in text |
| 别名匹配 | 多语种别名表查找 | 0.95 | ”しせいどう” -> 资生堂 |
| 模糊匹配 | Levenshtein距离 <= 2 | 0.80 | ”Shisedo” -> Shiseido |
| 语义匹配 | Embedding余弦相似度 > 0.85 | 0.70 | ”日本百年护肤老牌” -> 资生堂(需上下文) |
5.3 推荐排位提取规则
解析器识别以下结构模式以提取推荐排位:
- 编号列表:
1. 品牌A 2. 品牌B-> position = 序号 - Markdown列表:
- **品牌A**: ...-> position = 出现顺序 - 段落首提:第N段首次提及 -> position = N
- 表格结构:表格行中的排列顺序
- 未列入推荐:品牌未被提及 -> position = NULL
5.4 情感分析模型
采用两层分析架构:
- 整体情感:使用微调的多语种BERT模型(支持中/日/韩/英),输出 polarity 值域 [-1.0, +1.0]
- 维度情感(Aspect-based):对品牌关联的各维度分别打分
维度定义:
| 维度 | 说明 | 关键词示例 |
|---|---|---|
| quality | 产品质量 | 高品质、耐用、效果好 |
| price | 价格评价 | 性价比、昂贵、实惠 |
| service | 服务体验 | 售后好、响应快 |
| innovation | 创新能力 | 技术领先、突破性 |
| reputation | 品牌口碑 | 值得信赖、老牌 |
6. 指标计算公式详解
6.1 AI可见性综合得分(AI Visibility Score)
$$ V_{score} = w_1 \cdot M_{rate} + w_2 \cdot P_{norm} + w_3 \cdot S_{norm} + w_4 \cdot A_{rate} $$
其中权重默认值:$w_1 = 0.3,\ w_2 = 0.3,\ w_3 = 0.2,\ w_4 = 0.2$(租户可自定义)
得分范围:0-100
6.2 品牌提及率(Brand Mention Rate)
$$ M_{rate} = \frac{N_{mentioned}}{N_{total}} \times 100 $$
- $N_{mentioned}$:包含品牌提及的AI回答数(任意 match_type,confidence >= 0.7)
- $N_{total}$:相关Prompt的AI回答总数
6.3 平均推荐排位(Average Recommendation Position)
$$ P_{avg} = \frac{\sum_{i=1}^{n} pos_i}{n} $$
归一化到0-100分:
$$ P_{norm} = \max\left(0,\ 100 - (P_{avg} - 1) \times 20\right) $$
其中 position=1 得100分,position=6及以上得0分。
6.4 情感得分(Sentiment Score)
$$ S_{raw} = \frac{\sum_{i=1}^{n} polarity_i}{n}, \quad polarity_i \in [-1, +1] $$
归一化到0-100分:
$$ S_{norm} = (S_{raw} + 1) \times 50 $$
6.5 声量占比(Share of Voice)
$$ SoV_{brand} = \frac{N_{brand_mentions}}{N_{category_total_mentions}} \times 100% $$
其中 $N_{category_total_mentions}$ 为同品类所有被追踪品牌(含竞品)的总提及次数。
6.6 引用准确率(Citation Accuracy Rate)
$$ A_{rate} = \frac{N_{accurate_statements}}{N_{total_statements}} \times 100 $$
需要品牌知识库配合,将AI回答中的事实性陈述与品牌知识图谱进行比对。准确性判定阈值:语义相似度 >= 0.90 判定为准确。
6.7 跨平台一致性得分(Cross-platform Consistency Score)
$$ C_{score} = \frac{2}{k(k-1)} \sum_{i=1}^{k} \sum_{j=i+1}^{k} sim(R_i, R_j) \times 100 $$
- $k$:监测的AI平台数量
- $R_i, R_j$:不同平台对同一Prompt的回答
- $sim$:语义相似度函数(Embedding余弦相似度)
即对所有平台对(pairwise)计算回答语义相似度,取均值。
7. 性能与扩展性设计
7.1 并发模型
- Worker隔离:为高频调用的平台分配专用Worker,避免慢平台阻塞快平台
- 动态扩缩:基于队列深度自动调整Worker数量(Kubernetes HPA)
- 并发度:单Worker内采用asyncio协程,每Worker并发处理20个API请求
7.2 缓存策略
| 缓存层 | 存储 | TTL | 用途 |
|---|---|---|---|
| API响应缓存 | Redis | 5min | 相同查询参数的Dashboard请求去重 |
| 可见性得分缓存 | Redis | 1hour | 聚合得分查询加速 |
| Prompt模板缓存 | 本地内存 | 10min | 避免频繁查库 |
| AI回答去重 | Redis Bloom Filter | 24hour | 避免相同Prompt短期内重复查询 |
7.3 数据库分区策略
AIResponse表(数据量最大)采用TimescaleDB时序分区:
- 分区键:
queried_at - 分区粒度:按周自动创建分区(chunk)
- 保留策略:原始数据保留90天,聚合数据保留2年
- 压缩策略:超过7天的chunk自动压缩(约10:1压缩比)
VisibilityScore表按 score_date 分区:
- 粒度:按月分区
- 保留策略:永久保留(数据量可控)
索引策略:
| 表 | 索引 | 类型 |
|---|---|---|
| AIResponse | (platform_id, queried_at) | B-tree复合索引 |
| AIResponse | (prompt_id) | B-tree |
| BrandMention | (brand_id, response_id) | B-tree复合索引 |
| BrandMention | (match_type, confidence) | B-tree |
| VisibilityScore | (brand_id, score_date, platform_id) | B-tree复合索引 |
7.4 水平扩展架构
扩展节点:
- API Server:无状态,直接增加实例
- Celery Worker:按平台维度独立扩展
- TimescaleDB:主库写入 + 只读副本分担查询
- ClickHouse:用于复杂聚合分析查询的OLAP引擎,通过定时ETL从TimescaleDB同步
容量规划(200品牌并发监测):
| 资源 | 规格 | 数量 |
|---|---|---|
| API Server | 2C4G | 3实例 |
| Celery Worker | 4C8G | 6实例(中国3 + 海外3) |
| TimescaleDB | 8C32G, 500GB SSD | 1主 + 1只读 |
| Redis Cluster | 4C16G | 3节点 |
| ClickHouse | 8C32G, 1TB SSD | 1实例 |
8. 告警系统设计
8.1 告警规则引擎
8.2 告警规则配置
阈值告警(Threshold Alert)
{
"rule_type": "threshold",
"metric": "overall_score",
"condition": "lt",
"value": 50,
"platform": "all",
"severity": "critical",
"cooldown_minutes": 60
}变化率告警(Rate of Change Alert)
{
"rule_type": "rate_of_change",
"metric": "mention_rate",
"condition": "decrease_pct_gt",
"value": 20,
"window": "24h",
"severity": "warning",
"cooldown_minutes": 120
}异常检测告警(Anomaly Detection Alert)
基于过去30天的数据建立基线(均值 + 标准差),当新数据点偏离基线超过指定标准差时触发:
$$ |x_{current} - \mu_{30d}| > k \cdot \sigma_{30d} $$
默认 $k = 2.5$(对应约98.8%置信区间)。
8.3 告警严重等级与升级策略
| 等级 | 定义 | 通知渠道 | 响应要求 |
|---|---|---|---|
| info | 信息性变化,无需立即处理 | Dashboard站内通知 | 无 |
| warning | 指标出现不利趋势 | Email + Dashboard | 24小时内确认 |
| critical | 指标严重恶化或异常 | Email + Slack/企业微信 + Dashboard | 2小时内确认 |
| emergency | 系统级异常(如平台API全部不可用) | 全渠道 + 电话通知 | 30分钟内响应 |
8.4 告警升级策略
| 条件 | 升级动作 |
|---|---|
| Warning告警24小时未确认 | 升级为Critical,通知团队负责人 |
| Critical告警2小时未确认 | 升级为Emergency,触发电话通知 |
| 同一品牌1小时内触发3+次Critical | 合并为Emergency,触发即时通知 |
| 单平台连续3次监测失败 | 触发平台异常Emergency告警 |
8.5 告警抑制与聚合
为避免告警风暴,系统实施以下策略:
- 冷却期(Cooldown):同一规则在冷却期内不重复触发
- 聚合窗口:5分钟内同一品牌的多条告警合并为一条摘要
- 维护窗口:支持设定计划维护时段,期间暂停告警
- 依赖抑制:当平台API不可用时,抑制该平台的所有业务指标告警
返回 技术壁垒与产品化路线 | 返回 报告目录