搜索一个刚发生的热点，结果页可能塞满改写稿：彼此措辞不同，原始出处却指向同一篇文章，甚至根本找不到源头。对搜索引擎和 RAG 来说，这些页面都是可检索文档；对用户来说，它们并没有增加新的证据。
当机器生成的内容再次被搜索引擎收录，又进入模型训练或问答系统，错误便可能一轮轮传下去。PingWest 在《AI，正在疯狂污染中文互联网》中援引研究观点称，AI 生成数据的污染会扭曲模型对现实的认知，也会让未来依靠互联网数据训练模型变得更困难。
新华网评论《警惕“AI污染”乱象》把重点放在源头治理上：平台需要把控训练和生成所用的素材，承担生成内容的监管责任，并推动 AI 生成内容标识。
AI 生成内容与虚假新闻不能直接画等号。真正棘手的是来源不明、反复转述、无法核验的机器文本。一旦它们进入搜索索引，RAG 也会跟着中招。
RAG会检索，却不会自动判断真假
RAG 的基本做法并不复杂：先从外部数据源检索相关材料，再把材料交给大模型组织答案。
InterSystems 将 RAG 定义为把大型语言模型的固有知识与外部数据库中的实时信息结合起来。Google Cloud 强调，RAG 可以利用搜索系统和数据库，让输出更准确、及时，也更贴近具体需求。Elastic 则提到，私有或专有数据源能够补充模型知识，而且不必重新训练模型。
这些定义有一个共同前提：检索进来的材料得有用。
常见检索器擅长寻找语义相近的文本。语义相似度能回答“像不像”，回答不了“靠不靠谱”。如果几篇网页都在转述同一条错误消息，系统可能把重复看成印证，再由模型整理成一段语气笃定的回答。
RAG 因此不会天然消除幻觉。检索源受到污染时，它甚至可能给错误答案配上看似完整的引用。
先把来源分层
公开网页并非不能用，关键是把来源规则写进检索流程。不同问题应当优先寻找不同材料：
| 查询内容 | 优先检查的来源 | 需要警惕的材料 |
|---|---|---|
| 政策与法规 | 发布部门原文 | 无原文链接的解读、截图和转述 |
| 产品能力 | 厂商官方文档 | 营销软文、版本不明的教程 |
| 学术结论 | 原论文、作者或机构页面 | 只给结论、不附论文的二手摘要 |
| 企业内部问答 | 经审核的业务文档和数据库 | 来源不明的公开网页 |
工程上可以在向量库元数据里保存 source_type、publisher、published_at、original_url、domain_rank 和 ai_label 等字段。检索时先按业务范围过滤，再把语义相关度与来源规则一起用于排序。
域名权重只能作为一个信号。官方站点、学术数据库和新闻机构在对应议题上通常值得优先检查，但仍要核对发布主体、原始链接和内容时间。把 .gov、.edu 或某个知名域名直接当成真伪开关，仍有误判风险。
Elastic 提到的私有或专有数据源，在这里尤其重要。金融、医疗、法律或企业知识问答可以先限定检索范围，优先使用经过审核的内部材料，再决定是否补充公开网页。检索范围越可控，后续核验越容易。
事实核查要找到独立证据
来源评分拦不住制作精细的错误内容。生成答案前，还需要把关键事实单独拿出来检查。
可核验的对象通常很具体：人名、日期、数字、产品名称、政策名称以及明确的因果判断。系统可以围绕这些信息再次检索，寻找原始文件或独立来源。政策信息回到发布部门，产品信息回到官方文档，研究结论尽量回到论文。
这里最容易踩的坑，是把多篇转载当成多个证据。如果网页 A、B、C 都来自同一条未经证实的消息，它们仍然只算一条信息链。交叉核验需要检查来源之间是否独立，而不只是比较页面数量。
InterSystems 对 RAG 的介绍强调实时信息检索。实时只能缩短知识滞后，来源真伪仍需另查。系统还可以按场景接入业务数据库、结构化知识库，或评估 Wikidata、Google Knowledge Graph 等外部知识源。不同数据源的覆盖范围和更新时间并不一致，冲突信息应当保留下来。
遇到冲突时，模型不该自行挑选措辞最顺的一方。更稳妥的处理包括：
- 同时列出存在分歧的来源；
- 标明哪些事实尚未得到确认；
- 缩小回答范围，避免继续推断；
- 在医疗、法律、金融等高风险场景转交人工复核。
核验过程也要留痕。至少应记录检索到的文档、引用片段、来源链接和冲突情况，方便用户或下游系统追查答案依据。
AI标识有用，但不能代替核验
新华网评论提出，应推动 AI 生成内容标识。对 RAG 系统来说，这类标识可以直接进入索引元数据，例如记录为 is_ai_generated: true，再按照业务需要降权、排除或送入额外审核。
不过，AI 标识说明的是内容生产方式，无法直接证明内容真假。机器生成的文本可能引用可靠材料，人工撰写的文章也可能出错。没有 AI 标识，同样不代表来源可信。
更实用的做法，是把 AI 标识与发布主体、原始出处、引用关系和时间信息放在一起判断。最终答案也应保留引用，让用户知道结论来自哪里，而不是只看到一段流畅的总结。
开发者真正要改的是流水线
一套更稳妥的 RAG 流程可以拆成：
问题分类 → 限定数据源 → 检索 → 来源评分 → 冲突核验 → 生成 → 引用与降级
无论团队使用 LangChain、LlamaIndex、Haystack，还是通过 Dify、Langflow 编排流程，工具都不会替团队决定哪些来源可信。来源名单、评分规则、冲突处理和人工复核条件，仍要根据业务自己制定。
上线前需要回答几个具体问题：
- 哪些查询允许访问公开互联网？
- 找不到原始来源时，系统是拒答还是缩小回答范围？
- 多个来源互相冲突时，谁来复核？
- 外部核验服务不可用时，系统如何降级？
- 答案没有有效引用时，是否允许直接展示？
增加检索和核验步骤会拉长响应时间，也会增加外部调用。更合适的办法是按风险分流：内部常见问题可以依赖受控知识库；涉及医疗、法律、金融判断的回答，则提高来源要求，并保留人工入口。
运维侧也要持续检查来源集中、引用缺失、文档过期和事实冲突等情况。如果一批回答长期只引用同一个站点，或者找不到原始出处，就该回头检查索引和排序规则。
RAG能守住的是答案边界
RAG 清理不了整个互联网，但可以管住自己的检索范围：少把重复转述当证据，少让来源不明的页面进入上下文，遇到冲突时明确说清楚。
技术之外，平台标识、源头素材管理和生成内容监管同样重要。新华网提出的平台责任，为搜索引擎和 RAG 提供了另一层支持；工程团队则要把这些要求变成可执行的过滤、核验和追溯规则。
判断一套 RAG 是否可信，不妨看三个问题：用户能否看到答案依据，系统能否解释来源冲突，证据不足时是否愿意停下来。找不到可靠材料时，收窄结论或直接提示不确定，通常比流畅地补完一段话更有价值。
