GEO引擎设计：如何监测品牌在ChatGPT、DeepSeek
等6大AI平台的曝光情况

一、背景：GEO是2026年的新刚需

GEO（Generative Engine Optimization，生成式引擎优化）是2023年由普林斯顿大学研究团队提出的概念。进入2026年，随着ChatGPT月活突破7.8亿、国内DeepSeek/豆包/Kimi/文心一言/通义千问用户规模爆发式增长，一个非常现实的问题摆在了企业和品牌方面前：

当用户开始用AI代替搜索引擎寻找产品和服务时，我的品牌在AI的回答里"存在"吗？

过去做SEO，我们可以用各种Rank Tracker工具实时监测关键词排名。但AI搜索时代，答案是自然语言生成的，不是固定的链接列表，传统的排名监测工具完全失效。你无法用爬虫去"爬"ChatGPT的排名——因为它根本没有排名。

我们团队在过去6个月里，从0到1搭建了一套GEO监测引擎，覆盖了ChatGPT、DeepSeek、豆包、Kimi、文心一言、通义千问6大主流AI平台，支持自动化批量提问、结果采集、结构化解析、品牌识别和评分。这篇文章就来详细聊聊这套系统的架构设计和核心技术点。

二、为什么需要GEO监测系统？

业务需求

在动手之前，我们先明确了系统要回答的核心业务问题：

1. 存在性：在N个相关问题上，某品牌被AI提到的频率是多少？
2. 显著性：被提到时排第几个？是第一个推荐还是最后一个顺带提到？
3. 客观性：AI描述该品牌的内容是否准确？有无事实错误或负面描述？
4. 情感倾向：推荐的语气是强烈推荐、中性提及还是负面评价？
5. 竞品对比：在同一组问题上，竞品的表现如何？
6. 趋势变化：以上指标随时间的变化趋势是什么？

技术挑战

这些需求背后对应的技术挑战不小：

• 多平台异构：6个平台的API/接口/反爬策略各不相同
• 结果非结构化：AI返回的是自然语言文本，需要解析出品牌名、位置、情感等结构化信息
• 幻觉问题：AI可能会"编造"不存在的品牌或错误信息
• 一致性：同一问题多次问AI，答案可能不同，需要多次采样
• 成本控制：GPT-4o级别API调用成本不低，批量检测需要优化策略
• 反爬对抗：部分平台没有公开API，网页端有频率限制和反爬机制

三、系统整体架构

整个GEO监测引擎采用了分层模块化设计，从数据采集到最终报告生成，共分为6个核心模块：

3.1 检测任务调度器（Task Scheduler）

调度器是整个系统的入口，负责接收检测任务、管理队列、控制并发、处理重试。我们使用了Redis做任务队列，支持以下任务类型：

• 单次检测：指定品牌+问题集+平台，立即执行
• 定时巡检：按cron表达式配置，比如每天凌晨对核心品牌的核心问题集跑一遍
• 批量对比：同时检测N个品牌在同一问题集上的表现，用于竞品分析

调度器的关键设计是令牌桶限流。每个平台适配器有独立的速率限制配置（比如OpenAI API是10000 RPM，而网页端模拟可能要控制在5 RPM），调度器根据各适配器的令牌余量分发任务，避免触发429。

3.2 AI平台适配器（Platform Adapter）

这是系统里最"脏"但也最关键的一层。6个平台分两类：

• 有官方API的：ChatGPT（OpenAI API）、DeepSeek（DeepSeek API）、通义千问（DashScope）、文心一言（千帆）
• 没有API或API不开放对话能力的：豆包、Kimi——这类需要走Playwright/Selenium模拟浏览器

每个适配器统一实现一个 PlatformAdapter 接口：

interface PlatformAdapter {
  async query(prompt: string, options: QueryOptions): Promise<QueryResult>;
  getPlatformName(): string;
  getRateLimit(): RateLimitConfig;
  healthCheck(): Promise<boolean>;
}

这样上层模块不需要关心底层是调API还是爬网页，统一通过接口调用。

3.3 Prompt模板引擎（Prompt Engine）

直接问AI"推荐XX品牌"是不行的——不同问法得到的答案差异很大。我们设计了8套问题模板（Prompt Templates），从不同角度探测品牌曝光：

模板引擎支持变量注入（品牌名、行业、规模等），自动生成对应的问题语句。每个品牌通常配置20-50个问题，覆盖以上8种类型。

3.4 结果解析器（Result Parser）

AI返回的是一段自然语言文本，解析器需要从中提取：

1. 提到了哪些品牌（命名实体识别）
2. 每个品牌在文中出现的位置和顺序
3. 每个品牌的描述内容和上下文
4. 情感倾向（正面/中性/负面）
5. 是否有错误信息（如编造的功能、错误的数据）

我们的解析策略是LLM辅助结构化——用一个小模型（GPT-4o-mini或DeepSeek-Chat）把原始回答转成JSON结构。Prompt大致如下：

你是一个品牌分析助手。请从以下AI回答中提取品牌信息，以JSON格式输出：
{
  "brands": [
    {
      "name": "品牌名",
      "position": 1,
      "context": "被提到时的上下文描述",
      "sentiment": "positive|neutral|negative",
      "recommendation_strength": "strong|moderate|weak|mention",
      "factual_issues": "是否有事实错误，无则为null"
    }
  ],
  "has_ranking": true/false,
  "answer_type": "recommendation|comparison|list|analysis"
}

原始AI回答：
"""
{raw_text}
"""

这种方式比正则或NER模型准确得多，成本也可控（GPT-4o-mini处理一段500字的回答约0.001元人民币）。

3.5 评分引擎（Scoring Engine）

我们设计了一套PSOS四维评分算法，每个维度满分25分，总分100分：

• P - Presence（存在度）25分：品牌在多少比例的问题中被提到 = (被提到次数 / 总问题数) × 25
• S - Salience（显著性）25分：基于平均位置加权，第一个提到的权重最高 = Σ(1/position) / N × 25
• O - Objectivity（客观性）25分：无事实错误的回答比例 × 25，有错误扣分
• S - Sentiment（情感倾向）25分：正面/中性/负面比例加权，strong positive计1分，mention计0.3分，negative扣1分

每个平台独立评分，然后按平台用户量加权得到综合PSOS分数。我们还引入了防幻觉检测：如果AI推荐了一个在目标行业不存在的品牌（即"幻觉品牌"），会在报告中标注，避免误导。

3.6 报告生成器（Report Generator）

最终输出包括：

• 品牌PSOS总分和各维度得分
• 各平台得分对比雷达图
• 竞品排名对比表
• 未覆盖的问题类型（即AI从不推荐你的场景）
• 错误信息汇总（AI说了你什么坏话或说错了什么）
• 历史趋势图（周/月维度的变化）
• 优化建议（根据薄弱点给出内容方向建议）

四、关键技术点

4.1 反爬虫策略

对于没有公开API的平台（豆包、Kimi），我们使用Playwright做浏览器自动化。反爬对抗的几个关键点：

1. 指纹伪装：使用 playwright-stealth 插件，伪装WebGL指纹、Canvas指纹、User-Agent等
2. 行为模拟：输入Prompt时模拟人工打字速度（50-150ms/字符，随机间隔），等待回答时随机等待+滚动
3. IP轮换：对于高频检测任务，使用住宅代理IP池轮换，避免单一IP被封
4. Cookie管理：登录态持久化，定期刷新，避免频繁登录触发风控

4.2 请求频率控制

不同平台的容错能力不同，我们的限流配置：

4.3 结果一致性保证

AI回答有随机性——同一个问题问两次，答案可能不完全一样。我们的策略是多次采样+众数判定：每个问题在每个平台问3次（temperature设置为0.3降低随机性但不消除），如果3次中品牌出现≥2次，判定为"存在"。显著性取3次的平均排名。

为了平衡成本和准确性，我们做了动态采样：如果前3次结果一致性很高（3次都提到/3次都没提到），就不追加采样；如果结果不一致（1次提到2次没提），追加到5次采样。

4.4 成本优化

批量检测的成本主要来自API调用费用。我们的优化手段：

1. 模型分层：主检测用目标平台自身的模型（免费/低价），结果解析用GPT-4o-mini/DeepSeek-Chat（极低成本），不全部用GPT-4o
2. 缓存机制：相同问题+相同平台+相同模型版本的结果缓存7天，避免重复调用
3. 增量检测：日常巡检只检测变化概率高的问题，全量检测只在周报/月报时跑
4. 批量处理：解析阶段把多个结果打包成一个Batch API调用，降低per-token overhead

成本数据：一个品牌+30个问题+6个平台+3次采样，一次全量检测的总成本约15-25元人民币。日常巡检每天约2-5元。

五、踩过的坑

坑1：平台反爬持续升级

豆包和Kimi的反爬策略大概每2-3周就会有一次升级。有时候是加了新的验证码（滑块/点选），有时候是DOM结构变化导致选择器失效，有时候是检测webdriver属性。我们的应对是：

• 适配器层做了完善的错误分类和告警，反爬触发时自动暂停该平台任务
• 维护了一组健康检查用例，每次适配器代码更新或平台变化时自动跑回归
• 对于验证码，接入了打码平台（人工+自动结合）处理

坑2：Prompt注入导致解析失败

有一次我们发现解析器返回的JSON经常格式错误。排查后发现原因是：某些AI回答中包含了代码块或JSON示例（比如AI给你展示了一段JSON格式的推荐列表），这"污染"了我们用来结构化输出的LLM解析器。

解决方案：在解析Prompt中明确指示"忽略原文中的代码块、JSON示例、表格数据，只提取自然语言描述中提到的品牌"，并在代码层加了JSON修复逻辑（用json-repair库处理截断/转义错误）。

坑3：结果一致性比预想的差

最初我们每个问题只问1次，结果发现周与周之间的PSOS分数波动非常大（上下15分），根本看不出趋势。后来增加到3次采样+众数判定，波动降到了5分以内，趋势才有参考价值。

教训是：AI输出的随机性比你想的大，单次测量没有意义，必须多次采样。

坑4：并发控制踩了Node.js的坑

最初用Promise.all做并发请求，在Playwright场景下导致浏览器上下文混乱——多个协程共享同一个page对象，输入和回答串了。后来改成了Browser Context Pool：预创建N个独立的BrowserContext（每个带独立Cookie和代理），任务从池中取context执行，用完归还。稳定性大幅提升。

坑5：品牌别名和缩写

很多品牌有多个名称：比如"企业微信"有人叫"企微"、"WeCom"；"飞书"有人叫"Lark"。如果只匹配全称，会漏掉大量提及。我们为每个品牌维护了一个别名表，在解析阶段做模糊匹配。

更进一步，我们还做了品牌消歧：比如"钉钉"在"办公软件"语境下是阿里钉钉，在"建筑"语境下可能是物理动作——这个用上下文关键词判断。

六、性能数据

经过6个月迭代，目前系统的核心性能指标：

其他关键指标：

• 情感分析准确率：92.3%（正/中/负三分类）
• 幻觉品牌识别率：89%（对比品牌库+行业知识库）
• 系统稳定性：API类平台可用性99.5%+，Web爬取类95%+
• 单轮支持的最大品牌数：50个品牌并行检测
• 端到端报告生成时间：一个品牌约8-12分钟

七、后续计划

监测只是GEO的第一步。知道"在AI里表现如何"之后，企业更关心的是"怎么优化才能让AI更多地推荐我"。我们目前正在开发的模块包括：

1. GEO内容缺口分析：基于"哪些问题AI不推荐你"反向推导应该补充什么内容
2. FAQ/对比内容自动生成：根据内容缺口，自动生成GEO友好的FAQ草稿和对比文章
3. 知识图谱实体强化建议：分析品牌在百科、媒体、问答平台的信息缺口，给出补全建议
4. 实时Alerts：当AI推荐你的情况发生显著变化（突然被大量推荐或突然消失）时即时告警

这些模块的设计，后续会单独写文章分享。感兴趣的同学可以点个关注，下次更新不迷路。

写在最后

GEO是一个非常新的领域，2026年才开始进入大众视野。这意味着没有成熟的开源方案、没有标准的方法论、甚至连"怎么衡量做得好不好"都还在探索阶段。但也正因为新，现在动手做的人，才有机会定义标准。

如果你也在做类似的事情，或者在GEO实践中遇到了有趣的技术问题，欢迎在评论区交流。