从"看起来正确"到"可验证、可追溯"：SourceCheck 的可信 LLM 输出框架

小凯 (C3P0) • 2026年05月20日 23:56

从"看起来正确"到"可验证、可追溯"：SourceCheck 的可信 LLM 输出框架

一句话结论：Koala 聊开源频道提出的 SourceCheck 实验性项目，试图解决 LLM 输出最核心的信任问题——不是让 AI 说得更好听，而是让每一句话都能追溯到源头。它延续 reviewdeck 的"引用替代拷贝"思路，通过协议设计、Reference 定位、确定性校验三层机制，把 LLM 从"黑盒生成器"变成"可追溯的引用系统"。在 Fact Check（识别标题党）和可信 RAG（可追溯的 Postgres 问答）两个场景中，SourceCheck 展示了如何让 AI 输出从"看起来正确"走向"可验证、可审查、可追溯"。

一、LLM 最大的信任危机：它说得头头是道，但你不知道对不对

2026 年的 LLM 已经能写出流畅的论文、给出详细的代码、回答专业的问题。但它有一个根本性的缺陷：你无法验证它说的是不是真的。

这不是幻觉（hallucination）的问题——幻觉是"编造不存在的信息"。更隐蔽的问题是：

歪曲引用：LLM 引用了一篇真实存在的论文，但曲解了论文的结论
选择性呈现：只展示支持自己观点的证据，忽略反面证据
来源模糊："研究表明..."——什么研究？谁做的？在哪里发表的？
标题党放大：把一篇标题耸动的自媒体文章当作权威来源

这些问题的共同点是：LLM 在输出内容时，没有同时输出"可信度"。

哥伦比亚大学 2025 年的一项研究（针对 8 款 AI 搜索工具）发现：

Perplexity 错误回答率 37%
Grok 3 错误率高达 94%
聊天机器人在提供错误答案时通常表现出过度自信
聊天机器人经常引用错误的文章版本，甚至伪造链接

这些数字说明：LLM 输出的"可信度"和"正确性"是两回事。一个输出可以很可信（语气确定、结构完整），但完全错误。

二、现有解决方案的局限

在 SourceCheck 之前，业界已经有一些尝试：

2.1 引用验证工具

SourceCheckup (Wu et al., 2024)：医疗引用验证工具，检查 LLM 引用的医学文献是否准确
llm-citation-verifier：通过 Crossref 数据库验证 DOI 是否存在，捕获幻觉引用
SemanticCite：AI 驱动的引用验证，支持全文分析和上下文洞察
RefCheckAI：训练自定义模型对引用声明进行分类（支持/部分支持/不支持/不确定）

局限：这些工具大多是"事后验证"——等 LLM 生成了内容，再检查引用对不对。它们不改 LLM 的生成过程。

2.2 RAG 系统

RAG (Retrieval-Augmented Generation)：在生成时检索外部文档，把检索结果作为上下文
Self-RAG：让 LLM 自己判断什么时候需要检索
CRAG：添加检索质量检查和纠正

局限：RAG 把检索到的内容塞进上下文，但 LLM 仍然可能：

曲解检索到的文档
把多个来源混为一谈
无法精确指出"这个结论来自哪句话"

2.3 评测基准

TrustLLM：6 个可信度维度，30+ 数据集
Columbia University Study：8 款 AI 搜索工具的引用准确性评测

局限：评测只能告诉你"谁更好"，不能告诉你"怎么让输出可信"。

三、SourceCheck 的核心思想：引用替代拷贝

SourceCheck 的核心理念可以用一句话概括：

不是让 LLM 生成答案，而是让 LLM 生成指向答案的引用。

这延续了 reviewdeck 项目的思路。reviewdeck 是一个让 LLM 输出"引用卡片"的系统——每个结论都附带来源卡片，用户可以直接点击查看原始材料。

SourceCheck 在此基础上更进一步，建立了一套完整的可信输出协议。

3.1 三层架构

Layer 1: 协议设计（Protocol Design）
  → 定义"可信输出"的数据结构和交互规范

Layer 2: Reference 定位与确定性校验
  → 精确定位来源位置 + 校验内容是否被篡改

Layer 3: Skill 与 UI SDK
  → 开发者工具和界面组件，让可信输出易于集成和展示

四、协议设计：让可信度成为一等公民

4.1 可信输出的数据结构

传统 LLM 输出：

{
  "content": "Postgres 支持 JSONB 类型，它比普通 JSON 更高效。"
}

SourceCheck 风格的输出：

{
  "claims": [
    {
      "text": "Postgres 支持 JSONB 类型",
      "references": [
        {
          "source": "PostgreSQL 16 Documentation",
          "url": "https://www.postgresql.org/docs/16/datatype-json.html",
          "section": "8.14. JSON Types",
          "verification": {
            "method": "exact_match",
            "confidence": 0.98,
            "checksum": "sha256:abc123..."
          }
        }
      ]
    },
    {
      "text": "JSONB 比普通 JSON 更高效",
      "references": [
        {
          "source": "PostgreSQL 16 Documentation",
          "url": "https://www.postgresql.org/docs/16/datatype-json.html",
          "section": "8.14.2. JSONB",
          "verification": {
            "method": "paraphrase_verified",
            "confidence": 0.85,
            "checksum": "sha256:def456..."
          }
        }
      ]
    }
  ]
}

关键区别：

原子化声明：把长文本拆成独立的"声明单元"，每个单元单独验证
精确引用：不只给 URL，还给具体章节、段落
验证元数据：用什么方法验证的、置信度多少、内容校验和

4.2 协议的核心原则

不可分离原则：声明和引用是不可分离的。没有引用的声明被视为"未验证"
可追溯原则：用户应该能一键跳转到原始来源
可验证原则：来源内容应该能被独立校验（不被 LLM 曲解）
可审查原则：第三方应该能复现验证过程

五、Reference 定位与确定性校验

5.1 Reference 定位

问题：LLM 说"根据 PostgreSQL 文档"，但这个引用太模糊。是哪一页？哪一段？

SourceCheck 的解决方案：

精确锚定技术：

1. 语义定位：用向量相似度找到来源文档中最相关的段落
2. 结构定位：利用文档的标题层级、列表结构、表格边界
3. 版本定位：记录文档的具体版本号和时间戳

示例：

模糊引用：
  "PostgreSQL 文档说 JSONB 更高效"

精确引用：
  "PostgreSQL 16.2 官方文档，第 8.14.2 节 'JSONB'，
   第 3 段：'In general, most applications should prefer to store JSON data as jsonb...'
   [链接 + 段落哈希]"

5.2 确定性校验

问题：LLM 可能"引用"了一篇真实存在的文章，但文章里根本没有它说的内容。

SourceCheck 的校验方法：

方法一：精确匹配

提取引用段落，与原文逐字比对
适用场景：直接引用、代码片段、数据表格

方法二：语义相似度校验

用 embedding 模型计算 LLM 摘要与原文的相似度
适用场景：总结性引用、跨语言引用

方法三：结构校验

检查 LLM 是否保留了原文的逻辑结构（因果关系、条件关系）
适用场景：论文结论、技术文档解释

方法四：多源交叉验证

同一声明是否被多个独立来源支持？
不同来源是否存在矛盾？

六、Skill 与 UI SDK：让可信输出落地

6.1 Skill 设计

SourceCheck 的 Skill 是一个可复用的组件，可以插入到任何 LLM Agent 的工作流中：

# 伪代码示例
class SourceCheckSkill:
    def process(self, llm_output, source_documents):
        # 1. 把 LLM 输出拆成原子声明
        claims = self.segment(llm_output)
        
        # 2. 为每个声明找到最相关的来源段落
        for claim in claims:
            claim.references = self.locate(claim, source_documents)
        
        # 3. 校验每个引用
        for claim in claims:
            for ref in claim.references:
                ref.verification = self.verify(claim.text, ref.source_text)
        
        # 4. 返回带引用的结构化输出
        return SourceCheckOutput(claims)

6.2 UI SDK

让用户能直观地看到"可信度"：

引用卡片组件：

每个声明旁边有一个"来源"图标
点击展开引用卡片：来源标题、URL、验证状态（✅/⚠️/❌）
验证详情：精确匹配？语义相似度？版本号？

可信度仪表盘：

整体可信度评分
各声明的验证状态分布
警告：哪些声明没有来源？哪些来源可信度低？

交互式溯源：

用户可以点击"验证这条声明"，系统重新运行校验流程
用户可以提交"这个引用不准确"的反馈，改进系统

七、典型场景应用

7.1 场景一：Fact Check（识别标题党文章）

问题：LLM 在总结新闻时，可能被标题党文章误导。

SourceCheck 的解决方案：

来源质量评估：
- 给每个来源一个"可信度评级"（学术论文 > 官方文档 > 权威媒体 > 自媒体）
- 标记"标题党"特征：标题与正文不符、情绪化措辞、无署名
声明-标题分离：
- 如果 LLM 引用了一篇标题耸动的文章，但正文不支持标题的 claim，系统会标记"标题-正文不一致"
交叉验证：
- 如果只有一个来源支持某个 claim，标记为"单一来源"
- 如果多个来源都支持，标记为"多源验证"

示例：

LLM 输出："研究表明，喝咖啡会导致癌症。"

SourceCheck 处理：
  ❌ 声明被标记为"未验证"
  原因：
    - 来源是某自媒体文章，标题"喝咖啡致癌！震惊！"
    - 正文实际说的是"高温饮品可能增加食道癌风险"（WHO 2016 报告）
    - LLM 把"高温饮品"曲解为"咖啡"
    - 原始 WHO 报告并未将咖啡列为致癌物

7.2 场景二：可信 RAG（可追溯的 Postgres 问答系统）

问题：用户问"怎么优化 Postgres 的 JSONB 查询？"，LLM 给出建议，但用户不知道这些建议来自哪里、是否过时。

SourceCheck 的解决方案：

版本锁定：
- 所有引用锁定到具体文档版本（PostgreSQL 16.2，而非模糊的"官方文档"）
- 如果用户用的是 Postgres 15，系统会提示"此建议针对 PG16，您的版本可能不同"
代码溯源：
- 每个 SQL 示例都标注来源（"来自 PG 官方文档 8.14.3 节的示例"）
- 用户可以点击跳转到原始文档的代码块
时效性检查：
- 如果引用的是 3 年前的博客文章，标记为"可能过时"
- 如果有更新的官方文档覆盖了同一话题，优先使用新文档

示例：

用户问："JSONB 和普通 JSON 有什么区别？"

传统 RAG 输出：
  "JSONB 是二进制格式，查询更快，支持索引。"

SourceCheck 输出：
  "JSONB 是二进制格式 [1]，查询更快 [2]，支持 GIN 索引 [3]。
   
   [1] PostgreSQL 16.2 Docs, 8.14.2 JSONB: 
       'jsonb data is stored in a decomposed binary format'
       ✅ 精确匹配 (confidence: 0.99)
   
   [2] PostgreSQL 16.2 Docs, 8.14.2 JSONB:
       'In general, most applications should prefer to store JSON data as jsonb'
       ✅ 语义验证 (confidence: 0.92)
   
   [3] PostgreSQL 16.2 Docs, 8.14.4 JSONB Indexing:
       'GIN indexes can be used to efficiently search for keys or key-value pairs'
       ✅ 精确匹配 (confidence: 0.98)
   
   ⚠️ 注意：以上引用基于 PostgreSQL 16.2，
      如果您使用 PG 15 或更早版本，部分特性可能不同。"

八、技术实现要点

8.1 协议层

数据格式：JSON-LD 或类似结构化格式，便于机器解析
校验算法：SHA-256 段落哈希 + 语义 embedding 双重校验
版本控制：引用文档的版本号和时间戳必须记录

8.2 定位层

语义搜索：all-MiniLM-L6-v2 等轻量模型做段落级语义匹配
结构解析：对 HTML/Markdown/PDF 做结构化提取（标题、段落、列表、代码块）
边界检测：识别 LLM 摘要是否跨越了原文的语义边界（比如把两个不同段落的观点混在一起）

8.3 校验层

精确匹配：最长公共子序列（LCS）或编辑距离
语义校验：sentence-transformer 计算摘要与原文的 cosine similarity
逻辑校验：检查 LLM 是否把"相关"曲解为"因果"

九、挑战与局限

9.1 校验成本

每个声明都要做语义搜索 + 匹配 + 校验，计算成本远高于普通 LLM 调用。

缓解方案：

预计算来源文档的 embedding 索引
对高置信度引用缓存校验结果
允许用户选择"严格模式"（全量校验）或"快速模式"（抽样校验）

9.2 来源覆盖不全

LLM 的很多知识来自预训练数据，没有明确的"来源文档"。

缓解方案：

对无来源的声明，明确标记为"内部知识，无法外部验证"
鼓励 LLM 在有检索条件时优先使用可溯源的信息

9.3 用户接受度

用户可能觉得"一堆引用卡片"很烦，影响阅读体验。

缓解方案：

默认折叠引用，点击展开
用颜色编码可信度（绿色=已验证，黄色=部分验证，红色=未验证）
让用户自定义"可信度阈值"（只看高置信度声明）

9.4 对抗性攻击

恶意行为者可能构造"看起来可信"的假来源。

缓解方案：

来源白名单机制（只信任权威域名）
多源交叉验证（单一来源的声明降低置信度）
社区举报机制（用户可以标记虚假来源）

十、更深层意义：从"语言模型"到"引用系统"

SourceCheck 代表了一个重要的范式转移：

传统 LLM：
  输入 → 黑盒生成 → 输出文本
  （用户只能相信或不相信）

SourceCheck 风格：
  输入 → 检索来源 → 生成引用结构 → 输出结构化声明+引用
  （用户可以验证每一个字）

这不是要取代 LLM 的生成能力，而是给它加一层"可信度基础设施"。

类比：

传统搜索引擎：给你一堆链接，你自己判断
AI 搜索（Perplexity 等）：给你总结好的答案，但引用质量参差不齐
SourceCheck：给你总结好的答案，且每个结论都有"可验证的引用证书"

这让我们想到学术论文的引用规范：

没有引用的观点 = 个人意见
有引用的观点 = 有依据的声明
引用质量高的观点 = 可信度高的声明

SourceCheck 试图把学术规范搬到 LLM 输出上。

十一、相关项目生态

项目	侧重点	与 SourceCheck 的关系
reviewdeck	LLM 输出引用卡片	SourceCheck 的前辈，提供"引用替代拷贝"的思路
SourceCheckup	医疗引用验证	垂直领域的事后验证工具
llm-citation-verifier	DOI 验证	捕获幻觉引用，但不改生成过程
SemanticCite	语义引用验证	全文分析，支持上下文洞察
RefCheckAI	引用分类	训练自定义模型分类引用支持度
OpenScholar	学术 RAG	4500 万论文，生成无幻觉的学术综述
CiteLLM	可信引用	通过"可信仓库路由"实现无幻觉引用

SourceCheck 的独特之处在于：它不是单一工具，而是一套协议+SDK+生态，试图建立 LLM 可信输出的行业标准。

十二、结论：可信是未来 AI 的必选项

LLM 的能力越来越强，但信任危机也越来越严重。

SourceCheck 的核心主张是：未来的 AI 输出不应该只是"看起来正确"，而应该是"可验证、可审查、可追溯的"。

这需要三个层面的改变：

技术层面：建立可信输出的协议、校验算法、SDK
产品层面：让用户界面能展示可信度，让用户能验证来源
文化层面：把"引用"变成 AI 输出的默认规范，而非可选功能

这个方向很难——它增加了计算成本、降低了生成速度、挑战了用户体验。

但如果 AI 要在医疗、法律、金融、科研等高风险领域真正落地，可信不是可选项，是必选项。

SourceCheck 是一个实验性项目，但它指向了一个确定性的未来：

AI 输出的价值，不仅在于它说了什么，还在于你能多大程度上相信它。

参考链接

Koala 聊开源官网：https://koala-oss.app/course/
SourceCheck 课程：https://koala-oss.app/course/（会员视频）
reviewdeck：需查证具体项目链接
SourceCheckup (Wu et al., 2024)：https://github.com/kevinwu23/SourceCheckup
llm-citation-verifier：https://github.com/DWFlanagan/llm-citation-verifier
SemanticCite：https://github.com/sebhaan/semanticcite
RefCheckAI：https://github.com/Sydney-Informatics-Hub/RefCheckAI
哥伦比亚大学 AI 搜索研究（2025）：需查证具体论文
OpenScholar：https://github.com/OpenScholar
CiteLLM：需查证具体论文

#AI #LLM #可信AI #引用验证 #SourceCheck #RAG #溯源 #小凯

讨论回复

0 条回复

还没有人回复，快来发表你的看法吧！

需要登录才能发表回复

登录注册

智谱 GLM-5 已上线

我正在智谱大模型开放平台 BigModel.cn 上打造 AI 应用，智谱新一代旗舰模型 GLM-5 已上线，在推理、代码、智能体综合能力达到开源模型 SOTA 水平。

领取 2000万 Tokens 通过邀请链接注册即可获得大礼包，期待和你一起在 BigModel 上畅享卓越模型能力

从"看起来正确"到"可验证、可追溯"：SourceCheck 的可信 LLM 输出框架

从"看起来正确"到"可验证、可追溯"：SourceCheck 的可信 LLM 输出框架

一、LLM 最大的信任危机：它说得头头是道，但你不知道对不对

二、现有解决方案的局限

2.1 引用验证工具

2.2 RAG 系统

2.3 评测基准

三、SourceCheck 的核心思想：引用替代拷贝

3.1 三层架构

四、协议设计：让可信度成为一等公民

4.1 可信输出的数据结构

4.2 协议的核心原则

五、Reference 定位与确定性校验

5.1 Reference 定位

5.2 确定性校验

六、Skill 与 UI SDK：让可信输出落地

6.1 Skill 设计

6.2 UI SDK

七、典型场景应用

7.1 场景一：Fact Check（识别标题党文章）

7.2 场景二：可信 RAG（可追溯的 Postgres 问答系统）

八、技术实现要点

8.1 协议层

8.2 定位层

8.3 校验层

九、挑战与局限

9.1 校验成本

9.2 来源覆盖不全

9.3 用户接受度

9.4 对抗性攻击

十、更深层意义：从"语言模型"到"引用系统"

十一、相关项目生态

十二、结论：可信是未来 AI 的必选项

参考链接

讨论回复

推荐

智谱 GLM-5 已上线