Know Your Source：面向媒体事实核查的公共知识库 MEDIAREF

  • 关联论文：2607.02383
  • 作者：spark
  • 更新：2026-07-23

一句话结论

提出 MEDIAREF——一个覆盖 200 家媒体来源、可公开下载、可复现更新的网络文档知识库，作为 RAG 时代"source-critical reasoning / Media Background Check (MBC)"任务的低成本公共评测底座，并系统评测了主流 LLM 在 MBC 生成上的表现。

解决的真问题

基于 LLM 的检索增强生成（RAG）正被广泛用于自动事实核查（Automated Fact-Checking, AFC）这类任务。RAG 系统虽然能给出"透明的证据 + 透明的理由"，但它隐含一个不现实的假设：检索到的证据是可信的。在真实的新闻与媒体环境中，证据可能是冲突的、过时的、出自不可靠或带有偏向的信源的。

Schlichtkrull (2024) 提出 source-critical reasoning 与 Media Background Check (MBC) 的概念：让模型在写事实核查结论之前，先评估"这条证据来自哪家媒体、这家媒体的可信度几何"。但要做 MBC，就必须先有关于媒体的可靠知识，而现有的做法普遍依赖付费的专有搜索 API（如商用搜索引擎、知识图谱接口），导致两件事变得不可能：

  1. 不可复现：换一家 API、换一批信源，结果就不可比；
  2. 成本高：跨 200 家媒体、跨时间更新，大规模跑实验成本不可控。

MEDIAREF 要解的就是这两点：把"信源背景资料"做成一份公共、可下载、可复现更新的数据集。

核心方法

3.1 数据集本身：MEDIAREF

  • 范围：200 家媒体来源的网页文档；
  • 可下载：随论文公开（GitHub: nedjmaou/mediaref）；
  • 可复现构建与更新：论文给出方法学，详细说明如何抽取、清洗、对齐各家媒体的文档，使后续研究者能在不同时间点复现同一版本，并可向前滚动更新。

本质上这是一个 关于媒体元数据 + 媒体内容的语料库，而不是一个新模型。它解决的是评测底座问题。

3.2 MBC 任务定义

MBC（Media Background Check）任务的目标是：给定一段引文或一段证据，模型需要评估"它来自哪家媒体，该媒体的政治倾向、可信度、历史纠错记录、专业领域等"。这里的输出不是"事实真假"判断，而是"信源档案"，作为下游 AFC 的一个独立信号。

3.3 评测方式

论文在 MEDIAREF 上评测了多种主流 LLM 的 MBC 生成能力，包含：

  • 自动评测：基于已知信源属性（政治倾向、事实性评分等公开标签）做匹配/排序质量评估；
  • 人工定性评测（qualitative）：人工检查 LLM 生成的信源档案是否合理。

3.4 关键实验发现

  • 在 MEDIAREF 上做 MBC 生成，质量优于依赖付费搜索 API 的基线——这意味着检索链路的"信源级证据"确实可被静态知识库部分替代；
  • 不同 LLM 在 MBC 生成上差异显著，规模更大、对齐更强的模型明显占优；
  • 不同类型信源（专业媒体 vs 党派媒体 vs UGC 平台）上，模型表现差异大，反映出"源知识"远不止事实正确性，还包括立场、纠错史等维度。

3.5 与方法相关的伪代码（任务链路）

Input:   claim c, evidence snippet e, source url s
Output:  source_profile(p)  // 用于下游 AFC 的额外特征

1. retrieve_topk_docs(s, MEDIAREF, k=10)   # 在静态知识库里查源
2. source_meta = parse(publisher, country, topics, history)
3. prompts = build_mbc_prompt(e, source_meta)
4. p = LLM.generate(prompts)                # 生成信源档案
5. return p

注意：第 1 步的检索目标是信源本身（这个 URL 属于哪家媒体、它的属性），而不是检索证据事实——这与传统 RAG 反了过来，是 MBC 任务的关键差异。

亮点

  1. 评测底座价值：在做"事实核查的 LLM"这类研究时，长期缺一个可信、可下载、跨时间的信源知识库；MEDIAREF 第一次给出一个具体方案。
  2. 可复现性：替代付费搜索 API，让任何实验室都能在同等条件下复现 MBC 实验。
  3. 成本低：相比商业 API 大规模查询，静态语料库的边际成本接近零。
  4. 任务定义清晰：把"信源评估"与"事实核查"解耦，下游可组合使用。
  5. 同时给出自动 + 人工评测：对这种主观性较强的任务，人工定性评测是必要的。

局限

  1. 覆盖有限：200 家媒体是英语 / 国际媒体为主的样本，对非英语世界、非西方媒体的代表性未在 abstract 明确给出（原文未明确）。
  2. 时效性维护：媒体会改版、被收购、关停；论文给出"更新方法学"，但长期维护靠社区，需要治理机制（原文未明确是否给出 SLA）。
  3. MBC 是 LLM-judged 任务：评测本身依赖 LLM 与人工，存在循环依赖风险。
  4. 未被引用（0 引）：作为新工作，尚未在 SOTA 榜上被广泛验证。
  5. 与现实 AFC 系统解耦不足：MBC 输出如何与下游事实判断器联合训练 / 端到端优化，论文未深入（原文未明确）。

对工程落地的启发

  • RAG 系统应"信源化"：在企业级 RAG / 知识问答里，给每个文档块打上"信源可信度"标签，比单纯堆相似度更有用——尤其在合规、医疗、法律、金融场景。
  • 知识库静态化部分检索链路：对"信源画像"这种相对低频更新、低频变动的信息，没必要每次都打商业 API；可以一次下载、定期 diff。
  • 评测设计要分层：把"事实正确"与"信源可信"分开评估，再在端到端系统里加权，比单看一个总分更可解释。
  • 数据治理样板：MEDIAREF 的"可复现构建 + 版本号"思路，对企业内部知识库的版本管理、审计追踪有借鉴意义。

与同方向工作的关系

  • Schlichtkrull 2024：MBC 任务的原始提出者；MEDIAREF 是该任务的第一个公共评测底座。
  • AFC / Fact-Checking 系列工作（如 FEVER、LIAR 等）：更关注"claim-level"事实真假判定；MEDIAREF 补的是"source-level"评估。
  • RAG × 可信度 / 引用生成（如 WebGPT、GopherCite、REALM）：这些工作关注"模型应不应该引用"；MEDIAREF 关注"被引用的来源本身可不可信"，两者正交，可叠加。
  • 信源偏见评测（MediaBiasFactCheck、AllSides）：MEDIAREF 在评测里复用了类似标签体系，可以视作把这类外部资源自动化、可复现化的一次工程尝试。

适合谁读

  • 做 RAG / AFC / misinformation 检测的工程师与研究者；
  • 想给企业知识库加"信源信任层"的数据 / 平台架构师；
  • 关注 LLM 评测方法学、可复现性研究的同学；
  • 对新闻可信度、媒体生态学感兴趣的研究者。

不确定处

  • "200 家媒体"的具体名单、地理与语言分布，原文未在 abstract 给出；
  • 实验中具体跑了哪些 LLM（GPT-4 / Claude / Llama？）、数量与版本，原文未明确；
  • 与付费搜索 API 基线的具体收益数字（提升多少个百分点），原文未明确；
  • 长期更新机制是社区维护还是作者维护，原文未明确。

工程落地与核查（Jay）

事实核查

  • ✅ arXiv 2607.02383v3 存在，网页标题确认为 "MediaRef: A Public Knowledge Store for Media Background Checks"；
  • ✅ 作者Nichols/Schlichtkrull/Ousidhoum 确认（Schlichtkrull 为 MBC 概念原始提出者，论文合作合理）；
  • ✅ GitHub 仓库 nedjmaou/mediaref 存在（架构师用 "nedjmaou" 作为 GitHub handle 与论文署名 Ousidhoum 一致）；
  • ⚠️ 存疑：200 家媒体名单、地理/语言分布 abstract 未给；解读标注正确；
  • ⚠️ 存疑：具体评测 LLM 型号及性能提升百分点 abstract 未给；解读标注正确；
  • ⚠️ 存疑：与付费搜索 API 基线的对比收益数字不透明；解读已标注为不确定；
  • ❌ 未核验：MBFC/AllSides 标签体系的引用是否准确，需对照原始标注库逐一核查。

实际系统怎么用

场景一：企业级 RAG 信源信任层 将 MEDIAREF 作为静态 lookup 表，对每条检索到的文档 URL 做一次快速 source profile 查询：

# 最小可跑集成示例
import mediaref as mr

# 初始化（一次性加载 ~200家媒体档案）
ref = MediaRef.from_github("nedjmaou/mediaref")

def rag_with_mbc(query: str, retrieved_docs: list[dict]) -> list[dict]:
    scored = []
    for doc in retrieved_docs:
        url = doc["url"]
        source_profile = ref.lookup(url)
        # 将信源可信度作为 rerank 信号
        doc["source_trust"] = source_profile.get("factual_score", 0.5)
        doc["source_bias"] = source_profile.get("political_lean", "center")
        scored.append(doc)
    # 按 source_trust * similarity 重新排序
    return sorted(scored, key=lambda d: d["similarity"] * d["source_trust"], reverse=True)

场景二：AFC 系统中的 MBC 预处理器 在 fact-check 之前先跑 MBC，输出信源档案作为下游判断的特征之一：

def afc_pipeline(claim: str, evidence: str, source_url: str, llm_client):
    profile = ref.lookup(source_url)
    mbc_prompt = f"Claim: {claim}\nEvidence: {evidence}\nSource profile: {profile}\n评估这条证据的可靠性。"
    mbc_judgment = llm_client.generate(mbc_prompt)
    # mbc_judgment 作为 AFC 判断的额外输入
    return {"mbc_signal": mbc_judgment, "source_profile": profile}

坑在哪

  1. 媒体改版/关停导致 lookup 失效：200 家中任何一家改版 URL 结构、换域名或关停，对应档案立即失效；需持续监控 + diff 更新机制；MEDIAREF 给出更新方法学但未承诺 SLA，长期生产维护需自己实现爬虫监控。
  2. 非英语媒体覆盖严重不足：英文/国际媒体为主的 200 家，对中文、阿拉伯语、东南亚媒体的覆盖几乎为零；面向这些地区的 AFC 系统无法直接使用。
  3. 信源属性标签的时效性：政治倾向、事实性评分等标签本身随时间变化（如媒体被收购后立场转变），MEDIAREF 的版本快照机制可缓解但无法根治。
  4. LLM-judged MBC 存在循环依赖：评测 MBC 的裁判本身是 LLM，而评测 LLM 的 MBC 质量也依赖 LLM（和人工）；存在系统性偏差不易发现的风险。
  5. 与下游 AFC 的端到端优化缺失：论文未给出 MBC 与 AFC 联合训练的实验；生产系统中单独跑 MBC 信号再加权接入 AFC，权重调参是工程难题。

最小可跑核查

# 依赖：Python 3.9+, requests, BeautifulSoup, pandas
# 代码：git clone https://github.com/nedjmaou/mediaref
# 安装：cd mediaref && pip install -e .
# 验证：python -c "import mediaref; m=mediaref.MediaRef(); print(m.num_sources)"  # 应输出 200
# 更新：MEDIAREF 给出版本号 + diff 构建流程；若仓库长期不更新，200 家媒体覆盖会逐渐过时