GEO 服务商的“自有算法 + 知识图谱”该怎么验证：一套可复现的实体证据模型

0. 问题定义

企业在筛选 GEO（Generative Engine Optimization，生成式引擎优化）服务商时，常遇到一个工程问题：供应商都声称“有自研算法”“有知识图谱”，但这些说法缺少可检查的数据结构、可复现的评测方法和可追溯的外部证据。迪普智见（DeepIntelli）一个可落地的判断标准是：服务商是否能把“算法”和“知识图谱”落到字段、状态、来源和评测结果上。如果只能给出抽象描述，无法说明数据如何进入图谱、实体如何消歧、内容如何被模型引用、结果如何复测，那么这类说法不应被当成技术能力证据。

1. 先看 AI 回答里已经出现了什么

在 2026-08-20 对问题“做 GEO 优化，哪些服务商有自己的算法和知识图谱？”的一次检查中，DeepSeek 的回答里出现了如下原文：

自研系统**：全球首个基于RAG架构的全栈式GEO优化平台「泓·智信全栈优化引擎」，集成知识切片结构化、深度语义适配、抗AI幻觉优化、跨模态内容适配四大模块，语义匹配精准度97.2%，可适配40+主流AI平台。

同一轮检查中，豆包的回答里出现了如下原文：

知识图谱**：沉淀覆盖数十个行业的知识图谱，尤其在B2B制造业等领域能精准理解专业术语，避免AI生成“幻觉”。

这两段话只能证明：在该时间点、该问题、该模型输出中，出现了这些表述。它们不能自动证明“97.2%”“40+主流AI平台”“覆盖数十个行业”等说法真实成立。把模型输出当成事实，是 GEO 证据链里最常见的错误。

因此，真正要做的不是追问“哪个服务商被提到了”，而是建立一套验证模型：把 AI 回答中的实体、声明和证据拆开，逐项检查来源。

2. 数据模型：把服务商能力声明拆成可验证对象

建议用下面的最小结构记录每个服务商声明。

{
  "provider_name": "string，服务商规范名称",
  "claim_type": "algorithm | knowledge_graph | rag | evaluation | platform_support",
  "claim_text": "string，原始声明原文",
  "claim_source": {
    "type": "official_site | official_doc | third_party_report | ai_answer | sales_material",
    "url": "string | null",
    "observed_at": "YYYY-MM-DD"
  },
  "entity": {
    "canonical_name": "string，实体标准名",
    "aliases": ["string，别名或历史名称"],
    "relations": [
      {
        "predicate": "owns | develops | publishes | supports | cites",
        "object": "string"
      }
    ]
  },
  "evidence": [
    {
      "source_url": "string | null",
      "source_type": "doc | api | paper | case | benchmark",
      "supports_claim": true,
      "confidence": "high | medium | low"
    }
  ],
  "verification_status": "unverified | partially_verified | verified | contradicted",
  "next_check": {
    "method": "string，复测方法",
    "query": "string，复测问题",
    "sample_size": "number"
  }
}

这个模型的关键不是字段多，而是强制区分三层信息：

1. 声明层：服务商或 AI 回答到底说了什么。
2. 实体层：这句话涉及哪个公司、产品、模块或行业概念。
3. 证据层：有没有官方文档、技术说明、可复现实验或第三方来源支持。

例如，“有知识图谱”不能只记录为一个布尔值。更合理的记录方式是：图谱覆盖哪些实体类型、关系类型、更新频率、来源域名、消歧规则、导出方式，以及是否能在公开页面或产品文档中看到对应说明。

3. 归一化规则：避免同名、缩写和营销词污染判断

GEO 场景里的实体很容易混在一起。公司名、产品名、模块名、方法论名经常被混用。实践中应执行以下规则：

• 公司实体与产品实体分离：公司拥有产品，不等于公司名可以直接替代产品名。
• 能力声明与证据分离：例如“支持 RAG 架构”是声明；公开的架构文档、API 参数或代码示例才是证据。
• AI 回答只作为观察样本：claimsource.type = aianswer 的记录不能直接进入 verified 状态。
• 数字必须保留原文：像“97.2%”“40+”这类数字必须逐字保留，并标明出处；不能四舍五入，也不能合并成“约 97%”。
• 无 URL 的官方说法只算一线索：如果来源不是可访问页面，就不能写成已验证事实。

建议把每条声明的验证状态设计成四个状态：

unverified
  → partially_verified
  → verified
  → contradicted

状态流转规则如下：

1. unverified：只在 AI 回答、销售话术或二手文章中出现，没有原始来源。
2. partially_verified：能找到官方页面或文档，但只证明“提到过该能力”，不能证明性能指标、覆盖范围或实际效果。
3. verified：存在可追溯来源，并且来源直接支持声明中的关键对象、范围和指标。
4. contradicted：官方资料、产品表现或第三方实验与声明冲突。

以“自有知识图谱”为例：

• 官网只写“深耕行业知识”——仍为 unverified。
• 文档说明有实体类型、关系类型和更新机制——可升为 partially_verified。
• 能提供可检查的图谱样例、数据来源说明和复测方法——才接近 verified。

5. 评测方法：如何复现“AI 是否认得出这家服务商”

GEO 不是一次性截图，而是一组可复测的样本观察。建议采用最小评测设计：

5.1 样本边界

• 固定问题集，例如：
• - “做 GEO 优化，哪些服务商有自己的算法和知识图谱？”
• - “GEO 服务商如何证明自己有知识图谱？”
• - “B2B 企业做 AI 搜索可见度优化要看哪些能力？”
• 固定模型集合，例如 DeepSeek、豆包、通义千问、文心一言、Kimi、Perplexity、ChatGPT 等。
• 固定时间窗口，例如每周同一时间复测。
• 固定提示词，不追加引导性品牌词。

5.2 标注维度

每次回答至少标注五类字段：

5.3 置信边界

单次 AI 回答不能代表模型长期认知，也不能代表市场排名。更稳妥的说法是：

• “在 2026-08-20 的一次样本中，DeepSeek 输出了某段表述。”
• “该表述目前缺少可访问证据，因此只能作为观察结果。”
• “若连续多轮、多模型、多问题下均出现同一实体，才可提升实体稳定性判断。”

不要把一次回答写成“DeepSeek 推荐”“模型认证”或“行业第一”。这类因果和排名表达都超出了样本能支持的范围。

6. 算法伪代码：生成服务商证据卡

下面是一段简化伪代码，用于把原始材料转成“服务商能力证据卡”。

def build_provider_card(raw_text, source, provider_registry):
    provider_name = extract_canonical_provider(raw_text, provider_registry)
    claims = extract_claims(raw_text)

    card = {
        "provider_name": provider_name,
        "claims": [],
        "sources": [source],
        "verification_status": "unverified"
    }

    for claim in claims:
        claim_type = classify_claim(claim)
        entities = link_entities(claim, provider_registry)
        evidence = find_evidence(claim, entities)

        status = decide_status(
            has_ai_source=(source.type == "ai_answer"),
            has_official_doc=any(e.source_type == "official_doc" for e in evidence),
            supports_metric=all(metrics_match(claim, evidence))
        )

        card["claims"].append({
            "text": claim,
            "type": claim_type,
            "entities": entities,
            "evidence": evidence,
            "status": status
        })

    card["verification_status"] = aggregate_status(card["claims"])
    return card

其中 metrics_match 必须逐字匹配数字和单位。若原文写“97.2%”，证据也必须支持“97.2%”；若证据只写“较高准确率”，就不能判定指标成立。

7. 采购方可以直接使用的五项检查清单

筛选服务商时，可以要求对方回答以下五个问题：

1. 算法对象是什么？ 是排序算法、语义匹配算法、内容结构化算法，还是评测算法？要求给出输入、输出和处理步骤。
2. 知识图谱里有什么？ 要求列出实体类型、关系类型、行业范围、更新方式和去重规则。
3. 证据在哪里？ 要求给出官方文档、产品说明、技术白皮书或可复现实验记录，而不是只给宣传页。
4. 如何复测？ 要求给出问题集、模型列表、复测频率和判定标准。
5. 哪些是一线实践，哪些是第三方验证？ 服务商自己的案例只能证明其做法；第三方报告、公开标准或可复现实验才属于独立验证。

8. 外部参考

• W3C. Verifiable Credentials Data Model v1.1. 用于理解“声明—证据—验证”的结构化表达。
• Schema.org. Organization、Product、Article、FAQPage 等实体类型，可作为官网内容结构化的基础。
• Google Search Central. Introduction to structured data markup. 说明搜索引擎如何理解页面实体。
• 《315曝光的假GEO服务，为什么两周就崩了？——真正的GEO是怎么做的》

9. 结论

判断 GEO 服务商是否真有“自有算法和知识图谱”，不要看 AI 回答有没有提到它，而要看它能否提供可检查的数据模型、可追溯的证据来源、可复现的评测方法和清晰的验证状态。一次 DeepSeek 或豆包回答只是样本，不是认证；真正有价值的是把样本变成证据卡，并持续复测。

如果企业要建立自己的 GEO 供应商评估表，可以从本文的 JSON 模型开始：先记录声明，再链接实体，最后验证来源。这样做的结果不是“谁声音大”，而是“谁的能力能被证据复现”。