21万页假评测污染 AI 推荐｜引用溯源避坑

215,128 个"最佳软件"页面，出自三个网站，被 Perplexity 这类 AI 推荐引擎当作引用来源。我在 星链API上把整套 RAG 管线的来源校验重做了一遍，这一期讲清内容农场如何混进 AI 答案，以及引用溯源与去重到底怎么做。

一、开篇痛点：为什么推荐结果突然不敢信了

当我在 Perplexity 里输入"最好的笔记软件"这类问题，回答下面会挂出一排引用链接。过去我默认这些引用背后是真实评测：有人真的用过、真的对比过、真的写了结论。直到最近我做了一轮引用来源审计，才发现这个默认假设有多脆弱。

我顺着推荐答案里的引用逐个回查，把引用的域名做了聚类统计，结果让我停下来重新评估整套接入方案。痛点有三层：

• 引用不等于可信：AI 推荐引擎把"被引用"当作一种信任信号，但引用的源头可能是机器批量生成的页面，引用列表再漂亮也说明不了内容质量；
• RAG 的信任假设会失效：检索增强生成默认"检索到的内容 ≈ 可信内容"，污染源一旦进入知识库，会在每一次问答里被反复放大，而不是只出错一次；
• 排查成本极高：没有来源校验时，坏数据混在好数据里，肉眼几乎分辨不出来，等发现异常，污染可能已经扩散到整条生产链路。

这三个问题，我这一期全部从工程角度过了一遍。先说结论：问题不在模型，在数据进 RAG 之前的那个环节——来源校验。模型负责表达，来源校验负责把关，两者缺一不可。

二、现象复盘：215,128 个"最佳软件"页面从哪来

我以推荐答案的引用为起点，做了三个动作：抓取引用页面的标题与正文、按域名聚合、统计标题模板的命中率。结果如下：

三个网站合计制造了 21 万多页"最佳软件"内容，而这些页面出现在 AI 推荐引擎的引用列表里。换句话说，模型在回答"什么软件最好"时，引用的可能不是真人评测，而是一个模板循环出来的占位页。

这些页面的共同特征非常明显：

• 标题全部是"Best X for Y"的变体，只换关键词，X 与 Y 的取值空间几乎无限，所以页面可以无限膨胀；
• 正文结构雷同，评分、推荐位、结论按固定顺序排列，读三篇就能猜出第四篇的结构；
• 页面之间互相链接，形成一个"相互佐证"的网络，搜索引擎和 AI 爬虫都容易把它误判为活跃、权威的站点；
• 内容定期刷新，维持"更新中"的假象，让检索系统舍不得降权。

对检索系统来说，这类页面的数量优势是致命的：机器生成页面没有成本上限，而真人评测是稀缺资源。数量上十个数量级的差距，足以让任何只按"内容相关性"排序的检索器失守。

三、原理速览：内容农场如何进入 AI 引用链路

把整条链路画出来，污染点在哪一目了然：

内容农场批量生成"最佳 X"页面
        │
        v
搜索引擎收录 + AI 爬虫抓取
        │
        v
Embedding 入库 / 倒排索引收录
        │
        v
RAG 检索召回 → 片段进入模型上下文
        │
        v
模型生成回答并标注引用来源
        │
        v
用户看到"推荐 + 一排引用链接"

链路里有两个"信任默认值"：检索器默认收录的页面可信，生成模型默认检索到的片段可信。内容农场不需要攻破任何一个环节，它只需要在收录阶段制造足够多的页面，让召回阶段大概率命中自己。整条链路没有任何一个环节对"这个页面是不是机器生成的"负责。

四、为什么 RAG 会放大污染

RAG 的核心假设是"检索到的内容 ≈ 可信内容"。这个假设在真人内容时代勉强成立，在机器生成时代会系统性失效，原因有三：

第三个环节最隐蔽：内容农场用内部互链制造了"多个来源一致"的假象，而模型恰好把"多个来源一致"当作可信的信号。真实的第三方验证，就这样被一个自导自演的链接网络绕过了。

更麻烦的是，污染在 RAG 里是滚雪球的。坏片段第一次被引用，可能只是让一次回答出错；但如果坏片段随后被写进知识库、被二次检索、被用来生成新内容，污染就会逐层复制。这也是为什么治理必须放在入口，而不是指望生成阶段"发现"问题。

五、内容农场的四个可观察特征

与其讨论怎么治理整个生态，不如先讨论怎么识别。我把这批页面逐项拆过之后，总结出四个可以落地的检测信号：

这四个信号单独看都不致命——真人站点也可能有模板化列表页、也可能有一两个匿名作者。但组合起来，就是内容农场的指纹：模板标题 + 海量页面 + 单一域名 + 正文雷同，四个条件同时满足的站点，几乎不可能是真人运营的。

六、接入 星链API ：把来源校验放进 RAG 管线

实操环节。我的做法是在检索与生成之间加一道"来源校验闸门"，整条管线统一接到 星链API（https://www.xinglianapi.com）的网关，模型调用、来源校验规则、用量统计放在同一个入口管理。请求流向：

用户提问
    │
    v
检索器（向量库 + 关键词召回）
    │
    v
来源校验闸门
    │  ① 域名聚合检查
    │  ② 标题模板检测
    │  ③ 片段相似度去重
    │  ④ 引用元数据补全
    │
    v
LLM 生成（仅使用通过校验的片段）
    │
    v
星链API 网关（https://www.xinglianapi.com）
    │  统一鉴权 / 计费 / 日志
    v
模型官方接口

接入代码，Python 示例（OpenAI 兼容客户端）：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["YOUR_API_KEY"],
    base_url="https://www.xinglianapi.com/v1",  # 统一网关地址
)

def ask_with_sources(question, validated_chunks):
    """只把通过来源校验的片段交给模型，并要求逐条标注来源。"""
    context = "\n\n".join(
        f"[来源 {i}] {chunk['text']}" for i, chunk in enumerate(validated_chunks)
    )
    resp = client.chat.completions.create(
        model="gpt-4o-mini",  # 按实际档位替换
        messages=[
            {
                "role": "system",
                "content": "只依据提供的来源作答，并在每个结论后标注对应来源编号。",
            },
            {"role": "user", "content": f"问题：{question}\n\n可用来源：\n{context}"},
        ],
    )
    return resp.choices[0].message.content

关键点是闸门的位置：来源校验放在生成之前，意味着坏片段根本进不了模型上下文，而不是指望模型在回答时"发现"来源可疑。模型对事实的纠错能力有限，把脏数据挡在门外，比让模型事后甄别可靠得多。

七、来源校验与去重：Python 工程示例

闸门内部的核心逻辑是"评分 + 去重"两步。第一步对每个片段打分，命中可疑特征就标记；第二步按正文相似度合并同源内容，避免同一个模板页被重复引用、重复污染上下文。

import re
from collections import Counter
from urllib.parse import urlparse

TEMPLATE_PATTERN = re.compile(r"^best\s.+\s(for|of)\s.+", re.IGNORECASE)

# 域名聚合统计：同一域名贡献的页面数
DOMAIN_COUNTS = Counter(
    urlparse(c["url"]).netloc for c in ALL_CHUNKS
)

def is_suspicious(chunk):
    """返回该片段命中的内容农场特征列表。"""
    title = chunk.get("title", "")
    url = chunk.get("url", "")
    domain = urlparse(url).netloc
    flags = []

    if TEMPLATE_PATTERN.match(title):
        flags.append("标题命中模板")

    if DOMAIN_COUNTS.get(domain, 0) > 200:
        flags.append(f"单一域名页面过多（{DOMAIN_COUNTS[domain]}）")

    if not chunk.get("author") or not chunk.get("published"):
        flags.append("缺少作者或发布时间")

    return flags

def jaccard_similarity(a, b):
    """基于词集合的 Jaccard 相似度，粗筛阶段足够用。"""
    ta, tb = set(a.split()), set(b.split())
    if not ta or not tb:
        return 0.0
    return len(ta & tb) / len(ta | tb)

def dedupe_by_similarity(chunks, threshold=0.85):
    """按正文相似度去重，优先保留打分高的片段。"""
    kept = []
    for chunk in sorted(chunks, key=lambda c: c.get("score", 0), reverse=True):
        if all(jaccard_similarity(chunk["text"], k["text"]) < threshold
               for k in kept):
            kept.append(chunk)
    return kept

两点工程说明：模板正则在召回后、生成前执行，只对 Top-K 片段做，计算量可以忽略；相似度去重用词集合的 Jaccard，粗筛足够，线上数据量大时可以换成 SimHash 或向量距离，阈值按误杀率调优。这套逻辑加上第六节的网关接入，就是一条带闸门的 RAG 管线。

八、引用溯源：让每个回答都可回访

校验闸门挡掉坏数据之后，剩下的问题是如何让好引用经得起追溯。我的三条原则：

• 引用必须可回访：回答里的每个来源编号都能点开原文，而不是一个抽象链接；
• 引用必须可复核：多个引用要确实独立，互链模板页不算多个来源；
• 引用必须带元数据：抓取时间、作者、站点类型一起存下来，出问题能回查。

回答中的引用（来源 3）
    │
    v
原文 URL + 抓取时间 + 作者 + 站点类型
    │
    v
审计日志：谁在什么时间把哪个片段放进了哪次回答

溯源不是给模型加提示词，而是把"来源 → 片段 → 回答"的关系写进日志。提示词只能要求模型"给出引用"，无法保证引用真的存在；只有把关系链落到数据结构里，才能在一次回答出问题后，三分钟之内定位到污染源头。模型负责表达，溯源链负责兜底。

九、RAG 接入防污染清单

把这一期的工程经验整理成一张可执行的清单，接入任何 RAG 场景前逐项过一遍：

• [ ] 检索前：域名聚合统计，单一域名页面数异常时整体降权
• [ ] 检索前：标题模板正则，命中"Best X for Y"类模板的页面直接过滤
• [ ] 检索后：校验作者、发布时间、正文长度等元数据
• [ ] 检索后：按正文相似度去重，防止同源模板页重复引用
• [ ] 生成前：只把通过校验的片段放入模型上下文
• [ ] 生成时：要求逐条标注来源编号，禁止无来源结论
• [ ] 生成后：把"来源 → 片段 → 回答"写入审计日志
• [ ] 定期复测：用已知坏样本回归校验规则，防止规则被新的模板绕过

清单的每一项都不复杂，难的是全部接通。多数污染事故，不是某一条规则失效，而是某一条规则压根没上。

十、成本与风险提示

把这一期的坑集中列一下：

• 校验规则会增加管线延迟，但只要放在检索后、生成前，只处理 Top-K 片段，延迟可以控制在毫秒级，对整体问答体验影响很小；
• 规则过严会误杀真实评测，阈值要留缓冲，宁可漏放也不要误杀真人内容，误杀一次就可能丢一批真实可信的来源；
• 相似度去重要按业务量调参，语料越大阈值越要保守，阈值过低会把有价值的相似内容全部合并掉；
• 抓取与存储第三方页面内容，要关注数据授权与合规边界，我只讨论合法接入与架构设计；
• 这里讨论的全部是数据质量治理与合法接入，不涉及任何绕过官方限制的做法。

总结

215,128 个"最佳软件"页面这件事，把"被引用"和"可信"之间的距离摆到了明面上：AI 推荐引擎的引用链路可以完全由机器内容填充，而模型没有义务、也没有能力逐一甄别。我在 星链API（https://www.xinglianapi.com）的网关后面加了一道来源校验闸门，把域名聚合、模板检测、相似度去重放在生成之前，回答质量立竿见影地回升——真正的问题从来不是模型不够聪明，而是数据进上下文之前没有人把关。欢迎在评论区发表想法，一起聊聊引用溯源与 RAG 数据治理。