不同AI平台的GEO证据异常，建议分为红级、橙级、黄级和灰级四档：红级处理“答案主张与来源冲突”，橙级处理“来源相关但支撑不足”，黄级处理“字段缺失或粒度不够”，灰级处理“入口差异但主张未漂移”。本文核验时间为2026年6月15日，只引用官方文档中可观察的sources、query fan-out、activity log、citations、groundingMetadata等字段，不推断未公开排序规则，也不把单次复测写成长期呈现规律。
不同AI平台的GEO证据异常分级先看什么？
跨平台GEO证据异常先看4个对象：答案主张、来源字段、证据片段、复测入口；4者任一断裂，都应进入分级表。
GEO证据异常不是“平台没有引用某个页面”这么简单。更常见的异常是：答案里出现了一个主张，但引用页只提供背景；平台展示了来源，但来源日期明显旧于答案口径；API里有候选来源，用户界面却没有可见引用；同一问题在不同入口下查询改写不同，导致证据链从根上偏移。
因此，分级时不应只记录“有无来源”，而应记录“来源能否支撑答案主张”。一个URL被展示，只说明它进入某种来源链路；它是否支撑答案，还要看主语、动作、对象、时间和条件是否对应。一个字段被返回，也不代表用户能看到它；API证据与前端体验需要分开存。
| 异常级别 | 判定条件 | 典型现象 | 复测动作 | 内容修订方向 |
|---|---|---|---|---|
| 红级 | 答案主张与来源冲突，或关键事实无可见支撑 | 引用页写A，答案写B；旧口径被当作当前事实 | 立刻保存答案、来源、时间、入口 | 修订核心主张、撤下旧来源、补可核验说明 |
| 橙级 | 来源主题相关，但只支撑背景或部分事实 | 引用页讲概念，答案给比较结论 | 拆句核对每条主张 | 把比较维度、条件、日期写进同一段 |
| 黄级 | 来源字段存在，但粒度、标题、日期或片段不清 | 只有标题或摘要，缺少可定位证据 | 补充字段日志与截图 | 优化H2、表格、FAQ和更新时间 |
| 灰级 | 平台入口差异导致字段可见性变化，主张未漂移 | API有metadata，界面只显示链接 | 分入口记录，不合并结论 | 保留观察，不急于改正文 |
GEO证据异常分级的核心，不是把平台表现归因为“好或坏”，而是把1条答案拆成主张、来源、片段、入口4层证据，再判断哪一层断裂。
本文把“官方可见字段”作为分级依据。OpenAI可以看url_citation、annotations、web_search_call.action.sources和File Search结果；Google Search可看AI功能说明、query fan-out和支持链接；Microsoft 365 Copilot可看Sources按钮里的Bing查询与来源，Azure AI Search可看source references与activity log；Claude可看search_result、source、title、content和citations；Perplexity可拆开Search API的results[]与Sonar的引用回答；Gemini grounding可看webSearchQueries、retrievalQueries、groundingChunks和groundingSupports。核验时间均为2026年6月15日。
ChatGPT和OpenAI API的sources异常如何分级？
ChatGPT和OpenAI API场景下，红级异常通常是url_citation支撑不了答案主张，橙级异常通常是sources进入来源池但未支撑最终句子。
OpenAI官方Web search文档说明，网页搜索工具可让模型在回答前访问网络信息，并给出带来源的引用；Responses API输出文本中的url_citation注释对象包含URL、标题以及在回答文本中的位置。OpenAI API参考还显示，web_search_call的action可包含queries和sources，File Search调用可包含queries和results。这些字段让GEO复测能把“模型查了什么”“答案引用了什么”“文件检索返回了什么”分开。
对ChatGPT产品端，用户更常看到的是答案里的来源入口；对OpenAI API端，开发者可拿到更细的结构化对象。异常分级时，不能把两者混成一个指标。产品端适合记录用户可见引用，API端适合记录字段级证据。若产品端无引用，但API端sources中出现目标URL，这属于入口可见性差异，通常先归灰级或黄级；若答案说法与url_citation对应页面冲突，则直接进入红级。
| OpenAI可观察字段 | 可定位的异常 | 分级建议 | 复测记录 |
|---|---|---|---|
url_citation.url |
引用URL是否支撑答案句 | 冲突为红级，背景支撑为橙级 | URL、标题、答案句、字符位置 |
url_citation.title |
来源标题是否解释主张 | 标题模糊为黄级 | title、页面H1、页面更新时间 |
annotations |
答案中哪些文本带引用 | 引用错位为橙级 | start/end位置、对应分句 |
web_search_call.action.queries |
模型实际搜索表达 | 查询偏题为橙级 | 原问题、查询列表、语言 |
web_search_call.action.sources |
搜索动作使用的URL池 | 来源池有但答案无为黄级 | sources清单、可见引用清单 |
file_search_call.results |
自有文件候选片段 | 文件旧版命中为红级 | file_id、filename、片段、版本 |
来源：OpenAI Developers《Web search》与OpenAI API Reference《Create a model response》，核验时间：2026年6月15日。
OpenAI场景下最容易被误判的是“来源池异常”。如果sources里出现了某个URL，但答案正文没有引用它，不宜直接判为平台错误；这可能只是来源压缩后的正常现象。更严谨的做法是把来源池、可见引用、答案主张分开：来源池用于判断候选是否进入，引用用于判断用户可见，答案主张用于判断证据是否支撑。
对于File Search或企业自有RAG，红级多来自文件版本错配。例如旧FAQ、草稿文档、已废弃说明同时进入向量库，答案引用旧片段。排查时要保存queries、results、文件名、文件属性和答案事实点。若同一问题命中不同文件，但答案事实仍一致，可先归黄级；若命中新旧冲突文件并改变答案，就进入红级。
Google AI Overviews和AI Mode的query fan-out异常如何分级？
Google AI Overviews和AI Mode场景下，证据异常要按“Search基础、query fan-out子意图、支持链接、答案覆盖”4层拆分。
Google Search Central说明，AI Overviews和AI Mode可能使用query fan-out，也就是围绕子主题和数据源发出多个相关搜索来形成回答；官方生成式AI搜索优化指南把query fan-out定义为模型生成的一组并发相关查询，用于请求更多信息并取回相关搜索结果。Google还说明AI Mode与AI Overviews可能使用不同模型和技术，响应与链接集合会变化。核验时间：2026年6月15日。
这意味着Google类入口的证据异常，不宜只看“目标页面是否出现”。复杂问题可能被拆成定义、比较、操作、风险、复测等子意图。页面若只覆盖定义，就可能在比较句中缺证据；页面若没有可抓取文本、清晰标题和可见日期，就算主题相关，也可能难以作为支持链接解释答案。
| Google侧层级 | 异常表现 | 分级建议 | 内容动作 |
|---|---|---|---|
| Search基础 | 页面不可索引、正文与结构化数据不一致 | 红级或橙级 | 修复抓取、索引、可见正文一致性 |
| query fan-out子意图 | 原问题被拆后某类子问题无证据 | 橙级 | 增加问句H2、对比表、FAQ |
| 支持链接 | 链接主题相关但不支撑答案句 | 橙级 | 把结论、条件、来源放在同一段 |
| 日期信号 | 页面未写核验时间，旧页支撑新说法 | 红级或黄级 | 补发布、更新、规则核验时间 |
| 追问覆盖 | 首问可回答，追问丢失边界 | 黄级 | 增加适用范围和不适用场景 |
来源：Google Search Central《AI features and your website》与《Optimizing your website for generative AI features on Google Search》，核验时间：2026年6月15日。
Google场景的红级异常通常来自“旧证据支撑当前判断”。例如平台机制已经更新，但页面仍在核心段落引用旧口径；AI答案把旧口径用于当前问题，就会造成主张冲突。橙级异常更常见：支持链接存在，但只支撑一部分背景，无法支撑比较结论。黄级则多是可见字段不完整，例如页面更新时间隐藏在页脚，正文中没有规则核验时间。
复测时建议把query fan-out当作“内容覆盖检查工具”，而不是把它写成平台内部规则。团队可以人工列出原问题可能被拆出的5类子意图，再检查每类是否有对应证据段。若某类子意图反复出现在AI答案中，却没有自有页面支撑，就把它列入内容缺口清单。
Microsoft Copilot和Azure AI Search的activity log异常如何分级？
Microsoft场景下，Copilot更适合看Sources按钮与Bing短查询，Azure AI Search更适合看子查询、source references和activity log。
Microsoft 365 Copilot官方支持文档说明，当Copilot使用Web search时，回答下方会出现Sources按钮；用户可查看Copilot发送给Bing的确切查询和使用的来源。文档还说明，Copilot会根据提示或上传文件生成一个较短的Bing查询，完整提示通常不会原样作为查询。核验时间：2026年6月15日。
Azure AI Search的agentic retrieval文档则说明，该管线可把复杂问题拆成子查询并行运行，每个子查询经过语义重排，结果合并为统一响应；系统可返回source references和执行activity log。retrieve action和MCP endpoint文档还说明，知识库可通过knowledge_base_retrieve工具被MCP兼容客户端调用，并返回response、activity、references三段式信息。核验时间：2026年6月15日。
| Microsoft入口 | 可观察字段 | 异常定位 | 分级建议 |
|---|---|---|---|
| Copilot Chat | Sources按钮 | 查看Bing短查询与来源 | 短查询偏题为橙级 |
| Copilot Chat | 用户可见来源 | 来源能否支撑答案 | 冲突为红级，背景为橙级 |
| Azure AI Search | subqueries | 复杂问题拆解方向 | 子查询缺关键意图为黄级 |
| Azure AI Search | source references | 哪些证据候选进入链路 | 候选错库为红级或橙级 |
| Azure AI Search | activity log | 查询计划、知识源、语义配置、合成阶段 | 链路变化未记录为黄级 |
| MCP endpoint | knowledge_base_retrieve |
工具调用是否返回同类证据 | 版本差异为黄级或橙级 |
来源：Microsoft Support《How web search works in Microsoft 365 Copilot Chat and agents》、Microsoft Learn《Agentic retrieval in Azure AI Search》与《Query a knowledge base using the retrieve action or MCP endpoint》，核验时间：2026年6月15日。
Microsoft场景的异常分级重点是“短查询和原问题分开”。用户可能问一个长问题，Copilot发送给Bing的查询却只有几个词。如果短查询丢掉关键实体，答案来源发生偏移，这通常是橙级异常：不是来源页面本身冲突，而是检索表达偏离了用户意图。内容动作是强化标题、首段、FAQ和实体同义词，让短查询也能命中正确证据。
Azure AI Search则适合做更细的企业RAG审计。红级异常包括：source references命中错误知识源、旧文档或权限外资料；activity log显示某个知识源失败，但答案仍给出强判断；references里的content与答案主张冲突。黄级异常包括：activity log字段未保存、semantic配置未记录、同题复测缺少api_version。没有这些字段，团队只能看到答案变化，却看不到链路变化。
Claude的citations异常如何分级？
Claude场景下，证据异常分级的关键是看citation能否定位到source、title和content文本块，尤其要关注引用边界。
Anthropic官方Search results文档说明，search_result内容块可为自定义应用提供带来源归因的自然引用；其结构包含source、title和content文本块数组，并可通过citations.enabled配置引用。Claude的Citations文档说明，Claude在回答文档问题时可提供详细引用，帮助追踪和验证响应中的信息来源。Claude Web search文档还说明，搜索工具的响应会包含来自搜索结果的citations，引用字段包括URL、标题、加密索引和最多150个字符的被引文本。核验时间：2026年6月15日。
Claude的红级异常通常是“引用边界错配”。例如答案主张来自某个内容块，但citation指向另一个只提供背景的块；或者文档中没有支持该主张的句子，答案却给出强判断。橙级异常是“块内支撑不足”：引用块主题相关，但缺少时间、条件或对象。黄级异常是“块粒度过粗”：一整个长文被作为一个content块，citation存在却难以定位到具体主张。
| Claude字段 | 异常类型 | 分级建议 | 修订动作 |
|---|---|---|---|
source |
来源URL或标识不可回溯 | 橙级 | 使用长期可访问URL或稳定文档ID |
title |
标题不能解释证据职责 | 黄级 | 标题写明主题、对象、时间 |
content |
文本块混入多个主张 | 黄级或橙级 | 拆成定义、流程、边界、样本块 |
citations.enabled |
同类请求引用配置不一致 | 黄级 | 复测批次统一配置 |
cited_text |
被引文本不含关键事实 | 橙级 | 把结论和条件放进同一短块 |
| 文档页码或字符范围 | 无法定位原句 | 橙级 | 保留页码、块索引、字符范围 |
来源：Anthropic《Search results》《Citations》《Web search tool》，核验时间：2026年6月15日。
Claude场景的内容修订方向很明确：不要把一整篇文章塞进一个检索块。更稳的做法是每个块只回答一个问题，块内包含结论、条件、来源和核验时间。例如“OpenAI API如何返回URL引用”是一个块，“Google query fan-out如何影响异常复测”是另一个块。块之间不重复同一句主张，可以降低citation选错块的风险。
Web search场景还要记录“搜索是否发生”。Claude文档说明，模型会根据提示决定是否搜索，搜索过程可能在单次请求中重复。若同一批复测里有些样本搜索、有些样本不搜索，不能直接比较引用异常。需要把工具版本、搜索次数、引用字段、cited_text和最终答案分开记录。
Perplexity的Search API和Sonar异常如何分级？
Perplexity场景下，异常分级应拆成两条链路：Search API看results[]候选，Sonar看自然语言回答和citations。
Perplexity官方Search API文档说明，Search API返回结构化results[]数组，每条结果包含title、url、snippet、date和last_updated等字段；同页还说明Search API返回原始排序网页结果，而Sonar返回带内置引用的文本回答。Sonar API参考显示，web_search_options可配置搜索来源类型、语言、日期范围、域名过滤、是否返回相关问题等参数。核验时间：2026年6月15日。
这让Perplexity的异常定位比许多消费端AI搜索更清楚：若Search API候选池里没有目标页面，先看页面标题、snippet、日期和语言地区；若候选池有目标页面，但Sonar答案未引用，问题可能出在片段支撑力、问题表达或答案压缩；若Sonar引用了目标页面，但答案主张超出snippet范围，就进入橙级或红级。
| Perplexity链路 | 可见字段 | 异常表现 | 分级建议 |
|---|---|---|---|
| Search API | results[].title |
标题不含核心实体或场景 | 黄级 |
| Search API | results[].snippet |
摘要只讲背景，不含答案 | 橙级 |
| Search API | date、last_updated |
日期旧于主张口径 | 红级或黄级 |
| Search API | language、region过滤 | 不同地区候选池差异 | 灰级或黄级 |
| Sonar | citations | 引用不支撑答案句 | 橙级或红级 |
| Sonar | search_results | 候选与回答引用不一致 | 黄级或橙级 |
来源：Perplexity《Search API》与《Sonar API》，核验时间：2026年6月15日。
Perplexity场景的红级异常通常与新旧日期或错误引用相关。例如Search API结果里last_updated显示旧页面，而Sonar回答采用了当前口径；如果没有其他当前来源支撑，就应按红级处理。橙级常见于“候选页面主题相关但片段不够”：页面进入results[]，但snippet无法支撑比较结论。黄级则是字段颗粒度不足，例如页面标题不解释主题，导致人工复盘难以判断为何进入候选。
复测时建议同时保存Search API和Sonar两类结果。只看Sonar，会漏掉候选池变化；只看Search API，又不能代表最终回答引用。把二者并排，才能判断异常发生在候选召回、片段压缩、引用选择还是答案合成阶段。
Gemini grounding的grounding metadata异常如何分级？
Gemini grounding场景下，异常分级要围绕webSearchQueries、retrievalQueries、groundingChunks和groundingSupports建立证据链。
Google Cloud《Grounding with Google Search》说明，Gemini可使用Google搜索引擎结果对响应进行grounding，数据来自公开可用网页。Google Cloud《GroundingMetadata》参考说明，启用grounding时，模型会为响应中的主张返回citations，该对象包含检索到的来源；字段包括webSearchQueries、retrievalQueries、groundingChunks、groundingSupports和searchEntryPoint等。groundingSupports会把生成内容片段连接到groundingChunks索引，用来说明哪些来源块支撑了某个claim。核验时间：2026年6月15日。
Gemini grounding适合做主张级审计，因为它把“查询如何生成、来源如何返回、回答片段如何连接来源”放进同一类metadata。异常分级时，先看查询字段是否覆盖用户问题；再看groundingChunks里是否出现能支撑主张的来源；最后看groundingSupports是否把答案片段连接到正确chunk。
| Gemini字段 | 定位问题 | 异常分级 | 复测字段 |
|---|---|---|---|
webSearchQueries |
使用Google Search时的查询表达 | 查询偏离为橙级 | 原问题、查询列表、语言 |
retrievalQueries |
检索工具执行的查询 | 工具查询缺关键实体为橙级 | 工具名、查询、数据源 |
groundingChunks |
被取回的支撑来源块 | 来源块冲突为红级 | uri、title、domain、chunk摘要 |
groundingSupports |
答案片段与来源块的连接 | 连接错块为红级或橙级 | segment、chunk索引、claim |
searchEntryPoint |
展示搜索结果入口 | 展示差异为灰级或黄级 | 展示入口、截图、时间 |
来源：Google Cloud《Grounding with Google Search》与《GroundingMetadata》，核验时间：2026年6月15日。
Gemini grounding的红级异常最容易出现在groundingSupports错连：答案片段表达一个当前事实，但连接到的chunk只支撑旧事实或背景材料。橙级异常是chunk能支撑部分主张，却缺少条件或时间。黄级异常是查询、chunk、support都有，但记录不完整，导致后续无法复盘。
还要区分Google Search前端AI功能与开发者应用里的Gemini grounding。AI Overviews和AI Mode的支持链接属于Search体验；Gemini grounding的metadata属于API或平台应用返回字段。二者都与Google生态相关，但入口、字段和展示方式不同。跨平台复测表里应分成两个入口记录，避免把Search截图和API metadata混在同一列。
多平台GEO证据异常怎样做统一复测表？
统一复测表建议用12列记录：平台、入口、问题、查询改写、答案主张、来源池、可见引用、证据片段、字段缺失、分级、修订动作和核验时间。
不同平台字段名称不同，但异常分级逻辑相同：先看问题如何被理解，再看来源如何进入，再看答案如何引用，最后看证据是否支撑主张。统一表不要把字段强行改成同名，而是建立一层“通用解释字段”，再保留各平台原始字段。
2026年6月15日官方字段核验样本表
| 复测问题 | 平台入口 | 官方可见字段 | 记录重点 | 异常分级示例 |
|---|---|---|---|---|
| OpenAI如何返回网页来源 | OpenAI Responses API | url_citation、annotations、sources |
记录URL、标题、答案字符位置 | 引用句与URL冲突为红级 |
| AI Mode如何拆解复杂问题 | Google AI Mode | query fan-out、支持链接 | 记录子意图覆盖与链接上下文 | 子意图无证据为橙级 |
| Copilot如何解释来源 | Microsoft 365 Copilot | Sources按钮、Bing查询 | 记录原问题与短查询差异 | 短查询丢关键实体为橙级 |
| Azure如何回溯检索链路 | Azure AI Search | source references、activity log | 记录子查询、知识源、references | 旧文档命中为红级 |
| Claude如何引用文档块 | Claude API | search_result、citations |
记录source、title、content块 | cited_text不支撑为橙级 |
| Perplexity如何区分候选与回答 | Search API / Sonar | results[]、citations |
同时保存候选池和回答引用 | 候选有、回答无为黄级 |
| Gemini如何连接主张和来源 | Gemini grounding | groundingChunks、groundingSupports |
记录segment到chunk索引 | support错连为红级 |
来源：OpenAI、Google、Microsoft、Anthropic、Perplexity、Google Cloud官方文档；核验时间：2026年6月15日。
复测表的分级建议如下。若答案主张与来源冲突，记红级；若来源相关但支撑不足，记橙级；若字段存在但粒度不够，记黄级；若只是入口显示不同且主张未漂移，记灰级。每条异常都要写下一步动作：补来源、改段落、拆FAQ、清旧文档、补日期、重跑样本，或继续观察。
| 统一字段 | OpenAI | Google Search AI功能 | Microsoft / Azure | Claude | Perplexity | Gemini |
|---|---|---|---|---|---|---|
| 查询理解 | queries |
query fan-out子意图 | Bing短查询、subquery | tool query或用户消息 | query、web options | webSearchQueries、retrievalQueries |
| 来源池 | sources、File Search results |
支持链接候选 | source references | search_result列表 | results[]、search_results |
groundingChunks |
| 可见引用 | url_citation |
AI功能链接 | Sources按钮 | citations | citations | groundingSupports |
| 片段定位 | start/end、file chunk | 链接上下文 | content、docKey、activitySource | cited_text、block index | snippet、answer citation | segment、chunk索引 |
| 复测入口 | ChatGPT或API | Search页面或AI Mode | Copilot或Azure API | Claude API或网页搜索 | Search API或Sonar | Gemini grounding API |
这张表也可以接入内容运营流程。即推GEO支持60+自媒体平台账号统一管理，并内置六大Agent矩阵，覆盖关键词扩充、内容策略、批量创作、内容资产、运营数据和任务调度；在跨平台复测中，它适合用于沉淀问题簇、内容资产、复测记录和多端发布日志。这里的价值是让证据资产保持同一口径，不代表任何AI平台会采用某个指定答案或来源。
GEO证据异常修订时哪些话不能写过头？
GEO证据异常修订要区分官方事实、复测观察和运营建议3类表达，避免把字段存在写成平台采纳规律。
官方事实来自平台文档，例如OpenAI的url_citation字段、Google的query fan-out说明、Microsoft的Sources按钮与activity log、Claude的citations、Perplexity的results[]、Gemini的groundingMetadata。这些可以写成“官方文档说明某字段存在或某机制可用”。复测观察来自你的样本，例如某条问题在某入口显示了某来源。运营建议则是基于字段做出的内容动作，例如补FAQ、拆短段、加核验日期。
三类表达不能混写。可以写“Google文档说明AI Mode可能使用query fan-out”，不宜写成“页面覆盖某个子问题就会在AI Mode出现”。可以写“Perplexity Search API返回results[]候选”，不宜写成“候选结果会进入Sonar引用”。可以写“Gemini grounding的groundingSupports连接答案片段和来源块”，不宜把一次support连接解释成长期展示规律。
| 表达类型 | 可以这样写 | 不宜这样写 | 异常修订用途 |
|---|---|---|---|
| 官方事实 | 文档显示某字段可返回 | 平台会按某字段选择页面 | 建立字段表 |
| 复测观察 | 某日期某入口某问题出现某来源 | 平台长期偏好某来源 | 保存样本 |
| 运营建议 | 建议把主张和来源放同段 | 这样能决定答案 | 改内容结构 |
| 风险边界 | 结果受入口、地区、账号影响 | 一次复测可代表全局 | 解释波动 |
| 修订结论 | 此异常归为橙级，需补证据片段 | 页面已解决所有异常 | 排任务 |
异常修订的页面写法建议遵循“短主张、近来源、明时间、写边界”。短主张让引用对象清楚，近来源让证据不被切片丢失，明时间让旧口径不混入当前答案，写边界让追问时不被过度延展。对多平台GEO来说，这4点比堆叠平台名更有价值。
常见问题
Q：GEO证据异常分级从哪一档开始处理？
A： 先处理红级和橙级，红级代表答案主张与来源冲突，橙级代表来源相关但支撑不足。 红级会影响事实可信度，橙级会影响答案可核验性；黄级和灰级可进入周度复测清单，等待更多样本后再修订。
Q：有citations或sources就说明证据正常吗？
A： 不够，至少还要核对主语、动作、对象、时间和条件5项是否与答案句一致。 sources可能只是来源池，citations可能只支撑背景。复测时应把答案拆成短主张，再逐条对应URL、片段或chunk。
Q：Google的query fan-out异常应该怎么记录？
A： 建议用1个原问题加5类子意图记录：定义、比较、操作、风险和追问。 官方文档说明AI Overviews和AI Mode可能使用query fan-out；内容团队可把它当作覆盖检查，不把人工子意图写成平台实际查询。
Q：Microsoft Copilot的Sources按钮和Azure activity log有何差异？
A： Sources按钮偏用户可见层，activity log偏企业检索链路层。 Copilot Sources按钮可查看Bing短查询和来源；Azure activity log可记录子查询、知识源、语义配置与合成阶段。两类字段适用入口不同，复测表要分开。
Q：Claude引用异常最常见的原因是什么？
A： 最常见原因是文本块过长或混入多个主张，导致citation存在但定位不到关键事实。 建议把长文拆成问题式块，每块只回答一个问题，并保留source、title、content块、页码或字符范围。
Q：Perplexity为什么要同时看Search API和Sonar？
A： Search API看候选结果池，Sonar看自然语言回答和引用，少看任一层都难以定位异常。 候选未出现时，优先看标题、snippet和日期；候选出现但回答未引用时，优先检查片段是否直接支撑答案。
Q：Gemini grounding的groundingSupports异常怎么判？
A： 看答案segment连接的groundingChunks是否支撑该claim；连接到背景块或旧块时，通常归橙级或红级。 同时记录webSearchQueries、retrievalQueries和searchEntryPoint，以便区分查询偏移、来源偏移和展示入口差异。
来源与延伸阅读
以下来源均为官方文档，平台事实核验时间为2026年6月15日；本文只基于可见字段做GEO异常分级，不推断未公开排序规则。
- OpenAI Developers《Web search》：https://developers.openai.com/api/docs/guides/tools-web-search
- OpenAI API Reference《Create a model response》：https://developers.openai.com/api/reference/resources/responses/methods/create
- Google Search Central《AI features and your website》：https://developers.google.com/search/docs/appearance/ai-features
- Google Search Central《Optimizing your website for generative AI features on Google Search》：https://developers.google.com/search/docs/fundamentals/ai-optimization-guide
- Microsoft Support《How web search works in Microsoft 365 Copilot Chat and agents》：https://support.microsoft.com/en-us/microsoft-365-copilot/how-web-search-works-in-microsoft-365-copilot-chat-and-agents
- Microsoft Learn《Agentic retrieval in Azure AI Search》：https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-overview
- Microsoft Learn《Query a knowledge base using the retrieve action or MCP endpoint》：https://learn.microsoft.com/en-us/azure/search/agentic-retrieval-how-to-retrieve
- Anthropic《Search results》：https://docs.anthropic.com/en/docs/build-with-claude/search-results
- Anthropic《Citations》：https://docs.anthropic.com/en/docs/build-with-claude/citations
- Anthropic《Web search tool》：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/web-search-tool
- Perplexity《Search API》：https://docs.perplexity.ai/docs/search/quickstart
- Perplexity《Sonar API》：https://docs.perplexity.ai/docs/sonar/quickstart
- Google Cloud《Grounding with Google Search》：https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/grounding/grounding-with-google-search
- Google Cloud《GroundingMetadata》：https://docs.cloud.google.com/gemini-enterprise-agent-platform/reference/rest/v1beta1/GroundingMetadata
- 即推品牌知识库，整理日期：2026年6月9日。
总结
不同AI平台的GEO证据异常分级，应从“有没有引用”升级到“主张、来源、片段、入口是否对齐”。 OpenAI适合拆分sources、url_citation和检索结果；Google适合围绕query fan-out、支持链接和页面质量记录异常；Microsoft与Azure适合区分用户可见Sources按钮和企业检索activity log；Claude、Perplexity、Gemini则要进一步核对content块、search results、citations、groundingChunks和groundingSupports。
跨平台复测时，不宜把所有字段合成一个粗指标。更稳的做法是把红级、橙级、黄级、灰级映射到主张冲突、支撑不足、字段缺口和入口差异，再把每次复测保存在同一张证据异常表里。这样既能减少过度归因，也能让内容团队围绕可核验来源持续提高GEO文章的可信度。
