SEO / GEO 数据治理与规范标准细则（五）：数据源治理——不是所有数据都应该进入知识库

系列：SEO / GEO 数据治理与规范标准细则（五）

发布日期：2026年10月12日

前四篇，我们已经连续解决了四个问题：

为什么需要数据治理？
↓
数据怎样变成知识？
↓
哪个数据才是真相？
↓
谁对真相负责？

到了第五篇，整个体系必须继续向上游推进。

因为还有一个更加基础的问题：

这些进入企业数据系统、内容系统和AI知识库的信息，一开始到底从哪里来的？

假设今天企业准备建设一套SEO/GEO知识库。

团队很快搜集到了：

官网产品数据、

ERP数据、

工程PDF、

销售Excel、

供应商资料、

政府网站、

行业协会资料、

Google官方文档、

研究论文、

新闻报道、

竞争对手网页、

经销商页面、

Reddit讨论、

论坛帖子、

YouTube视频、

AI生成摘要、

ChatGPT回答。

然后全部导入Vector Database。

表面上看：

企业拥有的数据更多了。

AI能回答的问题更多了。

内容生产速度也更快了。

但真正的问题才刚刚开始。

其中哪些可以直接作为事实？

哪些只能作为参考？

哪些只能帮助发现问题？

哪些必须再次验证？

哪些已经过期？

哪些没有合法复用权限？

哪些本身就是AI生成的数据？

哪些来源甚至已经无法找到原始出处？

如果这些问题没有解决：

企业建设的并不是：

Knowledge Base。

而更可能只是：

Information Dump。

所以第五篇要正式建立：

Data Source Governance

也就是：

数据源治理。

一、不是“搜集到的数据”都有资格进入知识库

这是本篇首先需要建立的一条原则：

Collected Data
≠
Trusted Data

进一步：

Trusted Data
≠
Authoritative Data

再进一步：

Authoritative Data
≠
Automatically Publishable Data

一条信息即使是真实的，也可能已经过期、缺少Context、没有公开权限、属于另一个市场、只适用于某个型号、来自旧版本，或者不能直接用于当前产品。

所以：

数据采集与知识准入必须是两个独立阶段。

二、SEO/GEO最容易犯的错误，就是把“检索”当成“验证”

例如SEO人员搜索：

industrial ride installation time

Google返回某个行业网站：

Installation normally takes 3–5 days.

于是文章直接写：

Installation time: 3–5 days.

这中间实际上跳过了很多问题。

谁发布的？

描述的是哪种设备？

哪个国家？

什么安装条件？

几名工人？

是否包括基础施工？

文章是什么时候发布的？

这家公司是在描述自己产品，还是转载别人？

有没有原始工程依据？

因此：

Search Result
≠
Evidence

搜索引擎解决的是：

Retrieval。

不是企业内部的：

Truth Validation。

三、AI检索同样不能代替Source Governance

今天这个问题变得更加严重。

用户问AI：

某类工业设备一般需要多大的功率？

AI可能给出：

75–100 kW

这个答案或许合理。

但企业知识库不能因此直接创建：

rated_power = 80 kW

为什么？

因为：

AI Answer本身通常属于：

Derived Output。

而不是：

Authoritative Source。

NIST在Generative AI Risk Management Framework Profile中明确将Confabulation定义为生成式AI可能产生“看似有信心但实际错误或虚假的内容”的风险，并专门强调Content Provenance与Data Provenance，用于追踪内容与数据的来源、历史及修改过程。

官方资料：NIST AI 600-1: Generative AI Profile

因此在本系列中：

AI Output
Default Role
=
Derived Source

而不是：

AI Output
=
Source of Truth

四、AI不是不能使用，而是不能失去“来源链”

例如AI可以做：

20份官方技术文件
↓
Extraction
↓
Normalization
↓
Summary

AI生成：

Model FW-30 rated power is 82 kW.

如果我们仍然保留：

source_document:
Engineering-Spec-V4.2.pdf

page:
18

field:
rated_power

original_value:
81.7 kW

canonical_rule:
ROUND_1KW

那么AI只是：

Processor。

原始Authority仍然存在。

这是合理的。

危险的是：

AI Answer
↓
Copy
↓
Knowledge Base
↓
Forget Original Source

这时候：

Provenance断裂了。

五、真正的数据源治理首先要建立Source Registry

企业不应该看到一个网址就直接复制。

而应该先注册：

Source Registry

也就是：

数据源登记表。

最基本的Source Record可以包括：

Field	含义
source_id	数据源唯一ID
source_name	来源名称
source_type	来源类型
publisher	发布主体
owner	来源责任人
authority_domain	权威适用领域
jurisdiction	适用国家/地区
location	URL / 系统 / 文件位置
published_at	发布时间
modified_at	修改时间
retrieved_at	获取时间
version	版本
license	授权方式
rights	使用限制
provenance	来源关系
freshness_rule	新鲜度规则
risk_level	风险等级
allowed_use	允许用途
status	当前状态

这张表解决的第一个问题不是：

“内容是什么？”

而是：

这份信息到底是谁发布的？

六、Source Registry和Data Catalog并不是完全相同的东西

Data Catalog通常管理：

Dataset、

Data Service、

Metadata、

Distribution。

W3C的DCAT 3就是一套用于描述数据集和数据服务、促进数据目录之间互操作和发现的标准模型，并支持Versioning、Dataset Series等能力。

官方资料：W3C DCAT 3

而本系列的：

SEO/GEO Source Registry

关注的是：

Where does our knowledge come from?

它可以登记Dataset，也可以登记网页、PDF、API、数据库、研究报告、人工访谈、AI输出。

所以它更接近：

Knowledge Source Governance Layer。

七、Source分类的第一种方法：第一方、第二方、第三方

数字营销经常使用：

First-party Data
Second-party Data
Third-party Data

但必须注意：

这套分类主要回答：

数据与企业之间的关系。

并不自动回答：

这个数据是否权威。

本系列采用下面的工程化定义。

八、First-party Data——企业自己产生的数据

例如：

ERP
CRM
PIM
PLM
CMS
Website Analytics
Customer Inquiry
Sales Record
Product Test
Project Record
Support Ticket

这些属于企业自己直接产生或控制的数据。

通常价值很高。

但：

First-party不等于Automatically Correct。

企业自己的Excel一样可能写错。

自己的CRM一样可能重复。

自己的旧PDF一样可能过期。

所以：

First-party
≠
Authoritative

Authoritative与否，仍然取决于第三篇建立的：

Source of Truth规则。

九、Second-party Data——来自直接合作关系的数据

例如：

供应商提供的零部件规格。

客户提供的项目要求。

经销商提供的当地市场信息。

合作平台提供的渠道数据。

这些数据与企业之间存在直接业务关系。

但仍然需要判断：

它在什么Domain中具有Authority。

例如：

客户可以定义：

Project Requirement

但客户不能定义：

Our Product Engineering Specification

所以Authority永远需要：

Domain Boundary。

十、Third-party Data——来自企业控制之外的数据

例如：

行业数据库、

市场研究机构、

新闻网站、

论坛、

公开数据、

第三方SEO工具、

竞争对手网站、

公开论文。

Third-party Data并不意味着质量差。

政府官方开放数据也是外部数据。

高质量学术研究也是外部数据。

问题仍然是：

它适合用来回答什么问题？

十一、所以“第一方/第三方”不能作为Source Quality的唯一标准

这是非常重要的一点。

例如：

企业内部销售Excel可能是First-party，但已经三年没有更新。

政府监管机构的新法规属于External Source，但它在监管问题上显然拥有更高Authority。

所以：

Ownership Relationship
≠
Authority

十二、本系列建议建立第二套分类：Source Authority Tier

为了SEO/GEO治理，更实用的方式是：

按照来源的Authority与使用方式分层。

我们定义：

S0
S1
S2
S3
S4
S5
S6

七级Source Tier。

十三、S0｜Internal Authoritative Source

最高级内部来源。

例如：

Approved PLM Specification
ERP Financial Record
Legal Registry
Compliance Database
Signed Contract
Approved Test Result
PIM Master Record

这些来源可以直接支持企业核心事实。

其典型用途：

Canonical Data
Product Fact
Commercial Fact
Legal Fact
Structured Data
AI Knowledge Base

前提是：

版本有效，

Context正确。

十四、S1｜External Primary Authoritative Source

外部第一手权威来源。

例如：

监管机构、

政府部门、

标准组织、

平台官方文档、

原始研究发布方、

产品制造商自己的正式技术资料。

例如SEO研究Google Search规则时：

Google Search Central应优先于转载Google更新的博客文章。

这是：

Primary Authority First

原则。

十五、Primary Source不等于“永远正确”

官方来源也可能更新、撤回、更正、拥有不同版本，或者只适用于特定Jurisdiction。

因此即使S1来源仍然必须记录：

Version
Published Date
Modified Date
Jurisdiction
Effective Date

Source Authority不是：

“找到官方网站以后治理结束”。

十六、S2｜Verified Secondary Source

第二级参考来源。

例如：

专业媒体、

行业研究机构、

高质量分析师、

权威咨询报告、

系统性综述。

它们的价值通常在于：

解释、

汇总、

比较、

提供背景。

但是如果S2与S1冲突：

关键事实原则上应回到：

Primary Source。

十七、Secondary Source真正的价值不是“替代原始来源”

而是：

Context
Interpretation
Comparison
Discovery

例如一篇高质量SEO媒体文章发现：

Google刚更新了文档。

它非常有价值。

但正式企业知识库应该进一步寻找：

Google Original Document

然后把媒体分析作为：

Context Source

保存。

十八、S3｜Community / Experiential Source

例如：

Reddit、

论坛、

用户评论、

行业社群、

问答社区、

售后反馈。

这些数据有一个非常重要的价值：

Experience。

例如研究：

用户最担心什么？

采购商怎么描述问题？

设备现场有什么常见痛点？

社区数据可能非常有价值。

但这类Source默认不应该直接承担：

Technical Authority
Legal Authority
Compliance Authority

十九、但是论坛并不是“低质量数据”的同义词

Source Quality必须依赖：

Fitness for Purpose

W3C Data Quality Vocabulary特别强调，数据质量并不存在一个脱离用途的绝对统一定义，数据消费者需要依据具体目的判断Dataset是否适合使用。

官方资料：W3C Data Quality Vocabulary

例如研究：

“采购商最常抱怨什么？”

Reddit评论可能是：

Primary Evidence。

因为它直接记录：

用户体验。

但研究：

“设备额定功率是多少？”

Reddit就不是：

Authoritative Source。

这就是：

Same Source
+
Different Question
=
Different Authority

二十、S4｜Commercial / Competitive Source

例如：

竞争对手官网、

经销商页面、

B2B平台、

广告素材、

销售页面。

这些来源可以帮助理解：

市场定位、

竞争信息、

命名方式、

商业叙事、

产品范围。

但是竞争对手写：

Our ride lasts 25 years.

不能直接推导：

Industry standard lifespan = 25 years.

因为：

Company Claim
≠
Industry Fact

二十一、竞争对手Source最适合承担什么角色？

主要是：

Market Intelligence
Discovery
Positioning
Competitive Analysis
Claim Monitoring

如果它描述的是：

“对方自己公开声称什么”，

那么竞争对手官网本身可以成为：

该Claim的Primary Source。

但它并不是：

该Claim真实性的独立证据。

这是非常重要的区分。

二十二、S5｜AI-generated / AI-derived Source

包括：

AI回答、

AI摘要、

自动生成的产品描述、

AI提取字段、

AI翻译、

AI分类、

AI生成研究摘要。

它们的共同特点是：

Derived

也就是：

通常不是原始事实的产生者。

NIST的Generative AI Profile明确把Confabulation列为GAI风险，并强调对数据输入、元数据与生成内容建立Provenance Tracking，以帮助追踪来源、历史、真实性和完整性。

因此本系列规定：

S5默认不得直接晋升为关键事实的Authoritative Source。

二十三、AI Source应该保留两套Source

例如：

source_type:
AI_DERIVED

generated_by:
Model X

generated_at:
2026-10-08

derived_from:
SOURCE-0012
SOURCE-0015
SOURCE-0019

这样AI结果仍然能够追溯原始依据。

而不是创建：

一个新的“无来源事实”。

二十四、Google对自动生成内容的要求也说明了同样的问题

Google针对生成式AI内容的官方指南强调：

自动生成内容仍然应该关注：

Accuracy、Quality、Relevance。

并建议在适当情况下向用户提供内容如何生成的Context。

官方资料：Google Search Central：Using generative AI content

因此：

AI可以提高Processing Speed。

但不能取消：

Source Verification。

二十五、S6｜Unknown / Opaque Source

例如：

不知道原作者的截图。

微信群转发的一张表。

没有来源的Excel。

AI回答但无法找到原始依据。

转载网站删除了原始链接。

文件名：

final_new_latest_v7_REAL.xlsx

但没人知道谁创建的。

这类数据应该默认：

UNVERIFIED

而不是：

Knowledge。

二十六、关键业务数据禁止使用“Unknown Source”

例如：

产品安全参数、

认证、

价格、

法律信息、

保修、

工程参数。

如果Source未知：

正确状态应该是：

QUARANTINED

而不是：

PUBLISHED

二十七、这就引出Source Admission Gate

所有外部或新进入系统的数据，都不应该：

Collect
↓
Knowledge Base

而应该：

Collect
↓
Staging
↓
Source Classification
↓
Verification
↓
Admission
↓
Knowledge Base

中间这一层就是：

Source Admission Gate。

二十八、Source Admission至少应该检查八个维度

建议检查：

Authority
Provenance
Quality
Freshness
Context
Rights
Risk
Conflict

也就是：

数据不是看起来合理就可以进入。

二十九、01 Authority——它有资格回答这个问题吗？

例如：

Google排名政策：

Google官方。

企业产品功率：

工程系统。

价格：

ERP。

用户感受：

用户评论。

不同Question对应不同Authority。

所以不要问：

这个网站权威吗？

而应该问：

它对这个具体Claim有没有Authority？

三十、02 Provenance——能不能追溯来源？

W3C的Data on the Web Best Practices明确建议发布数据Provenance信息，也就是完整描述数据来源以及发生过的修改，因为来源和历史是数据消费者判断质量与可信度的重要依据。

官方资料：W3C Data on the Web Best Practices

所以一条数据至少应该知道：

Who created it?
Who published it?
When?
From what source?
Was it modified?

如果这些问题都无法回答：

风险必须上升。

三十一、03 Quality——数据本身质量怎么样？

可以检查：

Accuracy
Completeness
Consistency
Validity
Uniqueness
Timeliness

但必须记住：

Quality不是单一分数。

W3C DQV的核心思想之一就是让Dataset提供质量相关Metadata，使使用者能够根据自己的具体用途判断是否“fit for purpose”。

所以：

产品页需要的质量标准，

和趋势研究需要的质量标准，

可以不同。

三十二、04 Freshness——这条数据还有效吗？

例如：

一篇2019年的SEO Guide，今天可能仍然有部分价值。

但2019年的Google Structured Data支持列表，就可能已经过期。

Google当前Structured Data指南要求提供准确、与页面一致且非误导的信息。

官方资料：Google Structured Data General Guidelines

所以Source Registry必须记录：

published_at
modified_at
retrieved_at
valid_until
freshness_status

三十三、不同数据必须拥有不同Freshness SLA

例如：

价格：

minutes / hours / daily

库存：

real-time / near real-time

产品工程参数：

event-driven

法规：

effective-date driven

SEO平台文档：

change-driven

历史项目：

可能基本不会变化。

所以：

One Freshness Rule
for All Data

本身就是错误治理。

三十四、05 Context——这条数据在哪个条件下成立？

假设Source写：

Capacity:
96 passengers

必须进一步知道：

哪个型号？

哪种Configuration？

哪个市场？

哪种计算方式？

Maximum还是Rated？

所以Source Admission必须防止：

Context Collapse

也就是：

把一个局部事实，

错误升级成：

普遍事实。

三十五、06 Rights——能够访问，不等于能够自由使用

这是SEO/GEO数据治理里非常容易被忽略的一层。

互联网上公开可访问，不代表可以无限复制、重新发布、重新分发。

W3C Data on the Web Best Practices明确建议数据发布者提供License信息，并指出License信息对于数据消费者判断数据是否可以使用和复用十分重要。

DCAT 3也为Dataset Distribution定义了License、Rights、Access Rights与Policy等相关Metadata。

因此Source Registry应该至少记录：

license
rights
allowed_use
attribution_required
redistribution_allowed

三十六、Citation不等于License

这是一个必须区分的问题。

写上：

“来源：XXX”

并不自动意味着：

你获得了复制权、再发布权、商业复用权。

所以：

Citation
≠
Permission

对于大规模内容采集、Dataset构建、AI Knowledge Base、训练数据尤其需要重视。

具体法律使用范围仍需按照适用法律与来源许可判断。

三十七、07 Risk——Source本身有没有风险？

例如：

匿名帖子。

未知文件。

未经验证的数据Feed。

外部上传PDF。

AI输出。

它们都应该拥有：

Source Risk

风险可以来自：

错误、

过期、

偏见、

操纵、

权限、

隐私、

安全、

版权、

恶意内容。

因此：

Source Tier与Source Risk最好分别记录。

三十八、08 Conflict——它与已有知识是否冲突？

假设新Source说：

Power = 80 kW

当前Canonical Value：

82 kW

系统不应该自动覆盖。

也不应该求平均：

81 kW

正确行为应该是：

Conflict Detected
↓
Check Context
↓
Check Authority
↓
Check Version
↓
Steward Review

这与第三篇的Source of Truth直接衔接。

三十九、Source Governance最大的价值之一：阻止“错误进入上游”

如果错误数据已经进入：

Knowledge Base

它就可能继续进入：

AI
↓
Article
↓
Product Page
↓
Schema
↓
PDF
↓
Sales
↓
Search

修复成本越来越高。

因此最便宜的数据治理通常发生在：

Admission

而不是：

Publication

四十、这就是Data Quarantine

未通过Admission的数据，不是必须立即删除。

可以进入：

Data Quarantine。

例如：

QUARANTINED

Reason:
Source Unknown

Allowed:
Research only

Forbidden:
Public Content
Product Fact
Schema
AI Answer

这样企业可以保留：

“有潜在价值但尚未验证”

的数据。

四十一、建议建立六种Admission Status

AUTHORITATIVE
VERIFIED_REFERENCE
CONDITIONAL
LEAD_ONLY
QUARANTINED
REJECTED

四十二、AUTHORITATIVE

允许直接支持Canonical Truth。

例如：

有效PLM工程规范。

四十三、VERIFIED_REFERENCE

经过验证，可以支持内容、分析、知识引用。

但不能覆盖Authoritative Source。

例如：

高质量行业研究。

四十四、CONDITIONAL

仅在某个Context使用。

例如：

某国家法规。

某型号配置。

某时间区间。

必须绑定Context。

四十五、LEAD_ONLY

只能作为调查线索。

例如论坛帖子说：

某个产品似乎出现问题。

它可以触发：

Investigation

但不能直接生成事实结论。

四十六、QUARANTINED

暂时不能进入正式知识层。

原因可能是：

Source未知、

版本不明、

存在冲突、

License不明、

无法验证。

四十七、REJECTED

明确禁止进入Knowledge Layer。

例如：

已确认错误信息。

伪造文件。

失效且无历史价值的数据。

来源被篡改的数据。

四十八、因此Knowledge Base应该存在两层

很多企业现在只有：

Vector Database

所有资料全部丢进去。

更成熟的结构应该至少分成：

Source Layer
↓
Governed Knowledge Layer

Source Layer允许保存原始材料。

Knowledge Layer只允许进入：

通过Admission的数据。

四十九、再进一步可以形成四层架构

Raw Source Layer
↓
Staging / Quarantine Layer
↓
Verified Knowledge Layer
↓
Published Knowledge Layer

Raw Source：

原始材料。

Staging：

等待判断。

Verified：

已经验证。

Published：

允许对外使用。

五十、RAG尤其需要这层隔离

如果RAG直接索引：

整个Google Drive、

所有PDF、

旧报价、

旧目录、

AI生成稿，

那么Retrieval并不知道：

哪个是旧版本。

哪个是真的。

哪个可以公开。

哪个只是内部讨论。

最终：

RAG只是：

高效率地检索混乱。

所以：

RAG Quality的上限，很大程度上受Source Governance约束。

五十一、Vector Database不是Knowledge Base

这是非常重要的一句话。

Vector Database主要解决：

Similarity Retrieval

它本身并不会自动解决：

Authority
Truth
Freshness
License
Version
Context

因此：

Vector Database
≠
Governed Knowledge Base

五十二、Embedding也不会自动解决错误数据

错误：

Power = 75 kW

经过Embedding以后，只是变成：

可以被更快找到的错误数据。

所以：

Better Retrieval
of Bad Data
=
Better Distribution
of Bad Data

这正是为什么数据治理必须发生在：

Retrieval之前。

五十三、SEO知识库也不能直接等于“互联网资料库”

一个SEO系统可能采集：

Google、

Bing、

Ahrefs、

Semrush、

媒体、

论坛、

分析师。

正确做法不是：

把所有信息融合成一个答案。

而应该保留：

Source Identity

例如：

Claim:
Google uses X ranking signal.

Source:
Third-party SEO Blog

Status:
UNVERIFIED

与：

Claim:
Google Search uses crawling, indexing and serving stages.

Source:
Google Search Central

Status:
PRIMARY_OFFICIAL

完全不同。

五十四、Source必须绑定Claim，而不是只绑定Article

一篇文章可能包含20个事实。

其中5个来自官方。

5个来自内部数据。

5个来自研究报告。

5个是作者判断。

如果只记录：

Article Source:
Google

显然不够。

更成熟的方式是：

Claim
↓
Evidence
↓
Source

这就是未来：

Claim-level Source Governance。

五十五、Source Registry最终要连接Claim Registry

例如：

claim_id:
CLAIM-9921

claim:
FW-30 rated power is 82 kW

source_id:
SOURCE-PLM-002

evidence:
SPEC-V4.2

status:
VERIFIED

这样企业以后可以回答：

网站里哪些Claim来自这份Source？

五十六、一旦Source失效，就可以知道哪些内容受影响

例如某标准：

STANDARD-V2

正式被：

STANDARD-V3

取代。

有了Lineage以后：

系统可以找到：

Affected Claims
↓
Affected Pages
↓
Affected Schema
↓
Affected PDFs
↓
Affected AI Answers

这就是：

Source Impact Analysis。

五十七、来源不仅需要Quality，还需要Health

可以监控：

Source Available?
Source Updated?
API Healthy?
Schema Changed?
License Changed?
Authentication Changed?
Publisher Changed?

这叫：

Source Health Monitoring。

尤其对：

API、

数据Feed、

自动采集

非常重要。

五十八、Source删除也是一种事件

假设：

供应商撤回某PDF。

官方文档404。

API字段消失。

这不能只被看作：

“爬虫失败。”

可能意味着：

Source Lifecycle Event

需要进一步判断：

该知识是否仍然有效？

是否有新版本？

是否应该Deprecate？

五十九、因此Source也有生命周期

Discovered
↓
Registered
↓
Verified
↓
Admitted
↓
Active
↓
Updated
↓
Deprecated
↓
Retired

而不是：

找到以后永远有效。

六十、W3C PROV正好解决了“来源关系”

PROV家族标准用于表达Provenance，并能够描述Entity、Activity、Agent以及数据如何由其他数据派生。

官方资料：W3C PROV

DCAT 3也明确指出，Dataset Provenance可以使用PROV-O表达，并可以描述：

wasGeneratedBy
wasAttributedTo
wasDerivedFrom

等关系。

这和SEO/GEO未来的Knowledge Provenance高度相关。

六十一、例如一篇文章的Source Graph可以是

Government Standard
↓
Internal Compliance Interpretation
↓
Product Compliance Record
↓
Website Claim
↓
Structured Data
↓
AI Answer

真正成熟以后：

AI Answer不是一个孤立文本。

而是：

一条可追溯的：

Knowledge Lineage。

六十二、Source Quality不能只做一个总分

很多企业喜欢设计：

Source Score = 87

问题是：

一个来源可能Authority很高，但已经过期。

也可能数据很新，但没有使用权限。

因此不建议用一个总分掩盖Hard Failure。

更合理的是：

Authority: PASS
Provenance: PASS
Freshness: FAIL
Rights: PASS
Context: PASS

只要关键Gate失败：

就不能晋升。

六十三、可以采用Hard Gate + Soft Score

Hard Gate

必须通过：

Identity
Provenance
Rights
Critical Conflict Check

Soft Score

再评价：

Authority
Freshness
Completeness
Reputation
Machine Readability

这样不会出现：

“License为0，但其他分数高，最终还能达到85分”

这种错误。

六十四、不同用途应该拥有不同Admission Policy

Product Fact

要求：

S0 / S1
+
Evidence
+
Current Version

Market Research

允许：

S1 / S2 / S3 / S4

但必须标注Source。

User Pain Point

可以大量使用：

S3

AI Brainstorm

甚至可以使用：

S5

但结果不得直接升级成：

Canonical Truth。

所以：

Source Governance不是消灭低等级Source，而是限制它们的用途。

六十五、这是最容易被忽略的一个思想

Source Tier不是：

Good
vs
Bad

而是：

Allowed for What?

论坛可能不适合Engineering Specification。

但非常适合Customer Voice。

竞争对手网站不适合定义行业标准。

但非常适合Competitive Messaging Analysis。

AI不适合直接定义事实。

但非常适合Extraction、Classification、Transformation、Discovery。

六十六、所以企业需要Allowed Use Matrix

Source Tier	Product Fact	Research	Content Context	User Insight	AI Processing
S0	✓	✓	✓	—	✓
S1	✓	✓	✓	✓	✓
S2	△	✓	✓	✓	✓
S3	✕	△	✓	✓	✓
S4	✕	✓	✓	△	✓
S5	✕	△	△	△	✓
S6	✕	✕	✕	△	✕

其中：

✓ = Allowed
△ = Conditional
✕ = Not Allowed

六十七、SEO内容研究与事实发布必须分开

例如研究关键词时：

可以采集：

论坛、

竞争对手、

社交媒体、

AI建议。

因为这个阶段是：

Discovery

但进入正式文章中的数字、法规、技术Claim、产品参数，必须重新进入：

Evidence Validation

所以：

Research Source
≠
Publication Source

六十八、这对于GEO尤其重要

GEO的目标之一是：

提高企业信息在生成式搜索中的理解、检索、引用能力。

但如果企业知识层本身包含大量Source不明的信息，那么生成出来的FAQ、Answer Unit、Knowledge Graph、AI回答都会继承这种不确定性。

因此：

GEO不是让更多信息进入AI，而是让更可信、更明确、更可追溯的信息进入AI。

六十九、Structured Data同样必须遵守Source Governance

Google当前Structured Data质量指南要求结构化数据真实代表页面内容，不应误导，并应与页面可见内容保持一致。

所以：

JSON-LD里的数据也不能：

“SEO插件觉得应该有，就自动补一个。”

正确逻辑仍然是：

Verified Source
↓
Governed Data
↓
Visible Content
+
Structured Data

七十、如果Source不可靠，Schema只会让错误变得更机器可读

这是值得反复强调的。

Bad Data
+
Schema
=
Machine-readable Bad Data

结构化：

不是验证。

Embedding：

不是验证。

AI总结：

不是验证。

搜索收录：

也不是验证。

真正的验证必须来自：

Governance。

七十一、企业应该建立Source Risk Flags

例如：

SOURCE_UNKNOWN
AI_GENERATED
OUTDATED
LICENSE_UNKNOWN
CONFLICTING
ANONYMOUS
DERIVED
LOW_AUTHORITY
UNVERIFIED
JURISDICTION_MISMATCH
CONTEXT_MISSING

这样下游系统能够自动判断：

是否允许使用。

七十二、Source Metadata应该随数据一起流动

不要：

数据进入PIM以后，Source就消失了。

更合理的是：

Value:
82

Source:
PLM

Source Record:
SPEC-V4.2

Verified:
TRUE

Verified At:
2026-09-20

这就是：

Provenance-preserving Data Pipeline。

七十三、导出到CMS以后也不应该丢失Source

即使前台用户不需要看到所有Metadata，后台仍然应该保留：

source_id
evidence_id
verified_at
version

这样发现问题以后才能：

回溯。

七十四、AI知识库必须保留Document-level Metadata

例如：

document_id
source_id
publisher
published_at
retrieved_at
version
authority_tier
license
verification_status
valid_from
valid_to

而不是只保存：

chunk_text
embedding

否则向量库只知道：

“这段文字相似”。

不知道：

“这段文字可信不可信”。

七十五、进一步还需要Chunk-level Provenance

一个PDF拆成100个Chunk以后：

每个Chunk应该尽量仍然知道：

document_id
page
section
source
version

这样AI引用时才能真正返回：

Evidence。

七十六、数据源治理最终会改变AI回答方式

低成熟度：

Question
↓
Similar Chunk
↓
Answer

高成熟度：

Question
↓
Allowed Source Filter
↓
Authority Filter
↓
Freshness Filter
↓
Retrieval
↓
Evidence
↓
Answer

这才是真正：

Governed Retrieval。

七十七、Source Admission可以形成策略规则

例如：

IF
source_type = AI_GENERATED
AND
claim_type = TECHNICAL_SPEC

THEN
require_human_verification = TRUE

又例如：

IF
license = UNKNOWN
AND
use = REDISTRIBUTION

THEN
REJECT

再例如：

IF
source_status = DEPRECATED

THEN
exclude_from_current_answer = TRUE

这就是：

Source Policy as Code。

七十八、SEO/GEO Source Governance的MUST规范

MUST｜必须

1. 进入正式Knowledge Layer的数据必须存在可识别Source。
2. Critical Business Data不得以Unknown Source作为事实依据。
3. AI生成或AI派生数据不得默认成为Source of Truth。
4. AI输出用于关键事实前必须追溯并验证原始依据。
5. Source必须至少记录Publisher、来源位置与获取时间。
6. 关键数据必须记录Version、Effective Date或等效的新鲜度信息。
7. 外部Source用于大规模复用或再发布前必须检查License / Rights。
8. 存在Source Conflict时不得自动覆盖Canonical Value。
9. Source Tier必须与Allowed Use分离管理。
10. 关键Source失效、撤回或版本变化时必须能够识别受影响的Knowledge Asset。

七十九、SHOULD｜建议

企业应该：

建立Source Registry。

建立Source Tier。

建立Source Admission Gate。

建立Data Quarantine。

建立Allowed Use Matrix。

记录Retrieval Date。

记录Freshness SLA。

记录License。

记录Source Risk Flag。

记录Claim-to-Source Mapping。

保存Source Version。

建立Source Health Monitoring。

建立Source Impact Analysis。

建立AI-derived Data Provenance。

八十、MAY｜可选

成熟以后可以进一步建设：

Enterprise Data Catalog
Automated Provenance Capture
Content Credentials
Digital Signature
Checksum Verification
License Policy Engine
Source Reputation Model
Automated Freshness Detection
Automated Source Diff
Source Lineage Graph
Knowledge Admission Workflow
Policy-as-Code
RAG Source Filtering

但仍然需要强调：

数据治理的核心不是收集更多Metadata，而是让Metadata真正决定“这条数据能不能被使用”。

八十一、企业可以立即建立的Source Registry

最简版本只需要：

Source	Type	Tier	Owner	Freshness	Allowed Use	Status
PLM	Internal	S0	Engineering	Event-driven	Product Fact	Active
Google Search Central	Official	S1	SEO	Change-driven	SEO Standard	Active
Industry Report	Research	S2	Marketing	Annual	Market Research	Active
Reddit	Community	S3	Research	Current	User Insight	Conditional
Competitor Website	Competitive	S4	Marketing	Monthly	Competitive Research	Conditional
AI Output	AI Derived	S5	AI Ops	Per generation	Processing Only	Verify
Unknown Excel	Unknown	S6	Unknown	Unknown	None	Quarantine

企业即使只做到这一步，就已经开始把：

Information Collection

升级为：

Source Governance。

八十二、Source Admission Checklist

Identity：知道Source是谁吗？

Publisher：知道谁发布的吗？

Authority：它有资格回答当前问题吗？

Provenance：能找到原始来源吗？

Version：当前是什么版本？

Freshness：现在仍然有效吗？

Context：适用于哪个产品、国家、时间、配置？

Quality：数据是否完整、准确、一致？

Rights：可以使用、引用、复制、再发布吗？

Conflict：与现有Canonical Knowledge冲突吗？

AI：是否经过AI生成、改写或推导？

Allowed Use：可以用于事实、研究、背景还是仅作为线索？

Status：应进入Verified、Conditional、Quarantine还是Rejected？

如果这些问题无法回答：

数据就不应该直接进入：

Trusted Knowledge Layer。

八十三、可以把Source Admission压缩成一条流水线

Discover
↓
Register
↓
Classify
↓
Verify
↓
Check Rights
↓
Check Freshness
↓
Check Context
↓
Check Conflict
↓
Assign Allowed Use
↓
Admit / Quarantine / Reject

只有完成这些步骤，才进入：

Knowledge

八十四、真正成熟的知识库不是“最大”，而是“受治理”

很多AI项目的第一目标是：

更多Documents
更多Tokens
更多Vectors

但知识库的价值并不与Document数量线性增长。

一个包含100万份重复、冲突、过期、来源不明资料的知识库，可能不如10万份：

Verified
Current
Traceable
Contextualized
Licensed

的数据。

所以：

Knowledge Base的核心指标不应该只有Coverage，还应该有Trustworthiness。

八十五、这也是为什么数据源治理是SEO/GEO的上游工程

SEO最后看到的是：

网页。

GEO最后看到的是：

AI Answer。

但两者真正的上游都是：

Source

如果Source错误：

Data会错误。

如果Data错误：

Knowledge会错误。

如果Knowledge错误：

Content会错误。

如果Content错误：

Search和AI只是在放大错误。

所以：

Source Quality
↓
Data Quality
↓
Knowledge Quality
↓
Content Quality
↓
Search / AI Quality

这条链条不能倒过来。

八十六、第五篇真正要建立的是“知识入口控制”

第一篇：

Why Govern?

第二篇：

How Data becomes Knowledge?

第三篇：

Which Value is Truth?

第四篇：

Who owns Truth?

第五篇：

What is allowed to become Knowledge?

到这里，整个SEO/GEO数据治理体系开始形成一个闭环：

Source
↓
Admission
↓
Truth
↓
Ownership
↓
Knowledge
↓
Publication

写在最后

数据治理最危险的误区之一是：

认为：

数据越多越好。

AI时代尤其容易出现这种思维。

网页全部抓下来。

PDF全部上传。

企业Drive全部接入。

论坛全部采集。

竞争对手全部抓取。

AI再生成几十万条摘要。

最终看起来：

企业拥有了一个巨大的知识库。

但如果没有Source Governance，你并不知道：

哪些是真的，

哪些是旧的，

哪些只是观点，

哪些属于别的Context，

哪些没有使用权限，

哪些是AI再次生成出来的内容，

哪些甚至已经找不到原始依据。

所以：

企业知识治理的第一原则，不是“什么都知道”，而是“知道自己为什么知道”。

这也是第五篇最核心的结论：

不是所有可以获取的数据，都应该进入知识库；不是所有进入知识库的数据，都应该拥有同样的Authority；不是所有能够被AI检索的信息，都应该有资格进入最终答案。

真正成熟的SEO/GEO知识体系应该是：

Source
↓
Provenance
↓
Verification
↓
Admission
↓
Governed Knowledge
↓
Retrieval
↓
Citation

而不是：

Internet
↓
Crawler
↓
Vector Database
↓
AI

前一种体系生产的是：

可追溯知识。

后一种体系生产的，很可能只是：

可检索信息。

二者之间的差距，就是数据治理。

下一篇

《SEO / GEO 数据治理与规范标准细则（六）：Data Provenance——为什么“这条数据从哪里来”必须能够被机器追溯？》

第五篇解决的是：

哪些Source有资格进入系统？

第六篇将继续解决：

数据进入系统以后，怎样保证它永远不会失去自己的来源？

我们将正式拆解：

Source
Creator
Publisher
Activity
Transformation
Derived From
Generated By
Attributed To
Version
Timestamp
Evidence
Lineage

并建立：

SEO / GEO Provenance Record

进一步回答：

AI改写以后怎样保留Source？

数据清洗以后还能不能追溯Raw Data？

一个Claim经过三次内容转换以后怎样找到最初Evidence？

Schema、网页、PDF和AI Answer能不能最终追溯到同一条原始事实？

以及如何把：

“来源：某某网站”

升级成真正机器可计算的：

Machine-readable Provenance

参考依据与标准边界

W3C《Data on the Web Best Practices》明确建议数据发布者提供数据的License与Provenance信息。其中License用于帮助数据消费者理解共享与复用限制，而Provenance用于说明数据的来源、历史以及发生过的修改，使数据消费者能够更好判断其质量与可信度。

官方资料：W3C Data on the Web Best Practices

W3C《Data Quality Vocabulary》提供了一种描述Dataset Quality的方法，并特别强调数据质量与具体使用目的相关，数据消费者需要根据Quality Metadata判断Dataset是否适合自己的用途。

官方资料：W3C Data Quality Vocabulary

W3C DCAT 3是W3C Recommendation，用于描述Dataset与Data Service并促进数据目录互操作，同时提供Versioning、License、Rights、Access Rights等数据目录与分发Metadata；DCAT 3还说明Dataset Provenance可以结合PROV-O表达。

官方资料：W3C DCAT 3

W3C PROV系列提供Entity、Activity、Agent及Derivation等Provenance模型，用于描述数据或数字资源由谁、通过何种过程、依据哪些上游信息产生。

官方资料：W3C PROV

NIST《Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile》将Confabulation列为生成式AI的重要风险之一，并专门讨论Content Provenance，指出Provenance Tracking可以记录数字内容及数据输入的来源、历史、修改和相关Metadata，从而支持真实性、完整性与风险管理。

官方资料：NIST AI 600-1

Google关于生成式AI内容的官方指南要求自动生成的网站内容继续重视Accuracy、Quality与Relevance；Google Structured Data质量指南同时要求结构化数据代表页面真实内容且不得误导。

官方资料：Google Search Central：Using generative AI content

本文提出的 S0–S6 Source Tier、Source Registry、Source Admission Gate、Allowed Use Matrix、Data Quarantine、Admission Status、Source Risk Flags、Governed Retrieval、Claim-level Source Governance、Source Impact Analysis以及SEO / GEO Source Admission Standard，属于本系列面向SEO、GEO、RAG、AI搜索与数字营销数据实践建立的工程化治理框架，并不是W3C、NIST或Google共同发布的一套统一行业标准。