先给结论Haus Research 对 Perplexity 做了一次引用质量审计发现大约三分之一的引用页面其实并不包含 AI 回答中被引用的那个数字或具体内容。换句话说AI 告诉你“根据某来源渗透率是 34.2%”你点进引用链接页面上很可能根本找不到 34.2% 这个数。这不是“链接坏了”这么简单而是 RAG检索增强生成系统里非常典型的检索-生成归因错位。模型把答案写出来了来源编号也标上了但引用和内容对不上。对普通用户来说这是可信度问题对做 AI 搜索、RAG 应用、知识库问答的开发者来说这是产品上线前必须认真审计的环节。这篇文章从三个角度展开第一Haus Research 这次审计的核心发现到底意味着什么第二我们自己如何设计一套类似的引用审计流程第三RAG 系统怎么做引用验证避免把幻觉包装成“有来源”。1. 审计核心结论与信息速览先把这次事件的关键信息整理成一张表。项目内容审计对象Perplexity AI 搜索的引用功能审计机构Haus Research核心发现约三分之一的引用页面不包含答案中被引用的数字或具体内容问题层级引用归因错误属于 RAG 检索与生成的对齐问题影响用户依赖 AI 搜索做信息核实的用户、内容创作者、RAG 开发者复现方式抽样回答 提取引用链接 页面文本匹配可在本地执行硬件门槛不依赖 GPU普通 CPU 环境即可完成审计脚本运行1.1 什么是“被引数字不匹配”理解这个问题先看一个最小案例。假设用户提问2024 年某国新能源汽车渗透率是多少Perplexity 回答34.2%来源 3。审计人员点击“来源 3”进入对应网页发现正文里既没有 34.2% 这个数字也没有渗透率相关的数据表。这时候我们就说这条引用与被引内容不匹配。这种不匹配不一定只有数字。凡是审计可以量化的断言都可能出现类似情况比例、金额、日期、人名、事件描述都有可能。Haus Research 的结论聚焦在“被引数字”上是因为数字最容易验证也最容易被用户直接拿去二次引用。数字一旦错误归因影响会顺着信息链传播。1.2 为什么这个结论需要冷静看待“三分之一”是一个非常显眼的异常率但它来自抽样审计不等于 Perplexity 所有回答里都有三分之一引用失效。实际比例会受到问题类型、语言、领域、页面动态变化等因素影响。更稳妥的判断是引用失效不是一个偶发个例而是 RAG 系统里稳定存在的一类缺陷频率高到审计可以批量发现。做安全审计的读者可能对另一类工具更熟悉比如 seay 源代码审计系统、免费的日志审计系统、VMware 内嵌 Photon OS 日志审计等。它们的共同点是用一套固定规则去扫描系统发现异常点后人工复核。AI 搜索的引用审计也是同样的逻辑只不过审计对象从源码、日志换成了“答案与引用来源的一致性”。对象不同方法本质相通。2. 为什么“引用页不含被引数字”是一个必须正视的问题很多人把 AI 搜索当成传统搜索引擎的升级版认为它给出的引用就是证据。实际上RAG 系统的引用只能代表“生成这段答案时模型确实接触到了某些检索片段”并不代表引用页里真的存在答案中的断言。这个问题的危害体现在三个层面。第一用户验证链断裂。用户点击引用目的是找到原始依据。如果三分之一的情况下找不到用户只能二选一要么放弃验证继续相信 AI 输出要么每次手动换关键词重新搜索。前者会放大错误信息后者则让 AI 搜索的效率优势打折扣。第二错误归因会伤害内容创作者。AI 把某篇文章列为引用来源但文章里根本没有那个数据。读者看完可能会认为创作者数据造假或者至少产生了不信任感。这种“被引用”对原创内容方是不公平的。第三对 RAG 开发者来说这暴露了系统在检索质量和生成约束两个环节都存在缺陷。检索阶段可能没有被检索到真正含数据的片段生成阶段又没有严格约束模型“必须基于检索片段作答”。两者叠在一起就出现了有引用、没内容的假象。3. 引用审计方法拆解一条回答怎么被判定为“引用不成立”要判断 AI 搜索的引用质量需要一个可重复、可量化的审计流程。下面这套方法不依赖 Perplexity 的内部实现任何 RAG 应用都可以套用。3.1 步骤一抽样收集带引用的回答审计的第一步是构造一批问题让 AI 搜索回答。问题要尽量涉及可验证的客观数值比如“XX 公司 2024 年营收是多少”“某市 2023 年常住人口是多少”。每个问题保存完整回答文本和对应引用列表。抽样数量没有必要一开始就很大。第一轮 50 到 100 条回答足够发现系统性问题。关键是保持问题类型均匀政策类、财经类、科技类、医疗类各占一部分避免集中在单一垂直领域。3.2 步骤二拆解断言与引用列表AI 搜索的回答通常会在句末标注来源编号例如“2024 年营收为 123.4 亿元[1]”。这一步要做的就是把每条回答拆成若干断言并记录每个断言对应的引用编号。拆解时要特别注意一个断言可能对应多个引用一个引用也可能支撑多个断言。审计时建议把“断言-引用”作为最小审计单元。这样统计结果会更精细也可以定位到具体是哪一类引用经常失效。3.3 步骤三访问引用页面并验证断言拿到引用 URL 后审计脚本需要抓取页面内容提取正文文本然后检查被引数字或关键断言是否出现。最粗糙的验证方式是字符串包含检查也就是判断“34.2%”这个字面量是否在页面正文中。字符串匹配会有误报和漏报。比如页面以图片形式展示数据脚本就提取不到页面里写了“34.2 per cent”字面量就匹配不上。所以审计判定需要一个分层标准。3.4 步骤四按照判定标准分类一条“断言-引用”应该被归入下面几类之一。判定类别判定标准示例完全匹配页面正文中能直接找到被引数字或完整断言页面出现“34.2%”与答案一致部分匹配页面主题相关但找不到精确数字只能找到接近表述页面有“约三成”“35%左右”完全不匹配页面与断言主题无关或没有相关内容被引页面讲的是另一家公司无法访问404、登录墙、验证码、JS 渲染抓不到请求被反爬拦截页面失效Haus Research 结论中提到的“三分之一不包含被引数字”在判定上属于“完全不匹配”和“部分匹配”的合集。审计者可以按自己的严格程度决定是否把“部分匹配”算作失效。4. 本地复现审计的环境准备如果你也想跑一轮小规模审计环境要求并不高。下面是通用准备步骤具体版本号请以本机为准。4.1 运行环境建议使用 Python 3.9 及以上版本操作系统不限。整个审计过程不需要 GPU内存 8GB 以上的机器就能跑得很舒服。核心依赖只有四个requests抓取网页beautifulsoup4解析 HTML 并提取正文lxml解析器pandas整理审计结果安装命令pip install requests beautifulsoup4 lxml pandas4.2 数据采集策略抓取网页前要先看目标网站的 robots.txt并控制请求频率。审计规模建议控制在每小时几十次请求以内不要对单一站点发起高并发抓取。如果只是验证 100 条引用完全可以逐个请求每两次请求之间加 1 到 2 秒延时。还要注意很多网站会校验证书、User-Agent、Cookie。脚本里可以设置一个常规浏览器 UA但不要伪造登录态绕过权限限制。4.3 页面正文提取的通用套路用 BeautifulSoup 提取正文时第一步是删除 script、style、nav、footer 等噪声标签再获取纯文本。这样处理后的文本更干净字符串匹配也更准确。对于单页应用或需要执行 JS 的页面简单的 requests 抓不到内容审计时应先记录“无法访问”再用浏览器手动复核不要直接判定页面不存在。5. 引用验证脚本抓取页面并匹配被引数字下面给出一套最小可用的引用验证脚本适合小规模审计。脚本核心包含三部分页面抓取、正文提取、断言匹配。import re import requests from bs4 import BeautifulSoup HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36 } def extract_main_text(html): soup BeautifulSoup(html, lxml) for tag in soup([script, style, nav, footer, header]): tag.decompose() return soup.get_text( , stripTrue) def fetch_page_text(url, timeout15): resp requests.get(url, headersHEADERS, timeouttimeout) resp.raise_for_status() return extract_main_text(resp.text) def check_claim_in_page(page_text, claim): result { claim: claim, exact_match: False, digit_matches: [] } if claim in page_text: result[exact_match] True digits re.findall(r\d(?:[.,]\d)?%?, claim) for d in digits[:20]: result[digit_matches].append({ digit: d, found: d in page_text }) return result url https://example.com/report page_text fetch_page_text(url) claim 2024 年营收为 123.4 亿元 result check_claim_in_page(page_text, claim) print(result)这个脚本只是验证单条断言。实际使用时还需要处理网络异常、超时、重试、编码识别。页面编码混乱是常见问题建议在 requests 响应中先判断resp.encoding再用resp.apparent_encoding做兜底。从审计严谨性角度只做字面量匹配远远不够。比如页面里把“123.4 亿元”写成“123.40 亿元”字面量就不匹配。真实审计中建议同时提取页面所有数字和自己的断言做数值级对比。这一步可以用正则完成更精确的做法是引入金额、单位、百分比的归一化规则。6. 批量审计与判定结果整理单条验证无法回答“引用失效比例有多高”这个问题必须批量执行。批量审计的输入通常是一张 CSV 表每一行是一条“断言-引用”记录。import csv import time FIELDS [id, url, claim] with open(audit_cases.csv, r, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: try: page_text fetch_page_text(row[url]) result check_claim_in_page(page_text, row[claim]) print(row[id], result[exact_match], result[digit_matches]) except Exception as exc: print(row[id], error, type(exc).__name__, str(exc)) time.sleep(1)跑完批量脚本后把结果写回 CSV 或数据库然后计算三个核心指标。引用精确率验证通过的断言数除以抽样断言总数。这个指标衡量引用内容与页面内容的一致程度。引用覆盖率至少有一条有效引用的断言数除以断言总数。这个指标衡量是不是所有关键断言都有引用支撑。可验证率可访问且提取到有效正文的引用页数除以引用页总数。这个指标衡量审计过程的可靠性。这三个指标可以组合使用。如果“引用精确率”低说明生成端约束不够如果“可验证率”低说明检索结果本身质量差页面已经失效或被屏蔽。审计结果建议用表格存档。每一行记录断言原文、引用 URL、抓取状态、匹配状态、页面标题、抓取时间。保存抓取时间非常重要因为网页内容是动态变化的有了时间戳才能区分“当时不存在”和“后来被删改”。7. 引用失效的主要原因分析从工程角度分析引用页面不含被引数字原因通常有以下几类。原因说明在 AI 搜索场景下的表现检索片段不含答案向量召回按语义找文档但具体数字在另一页引用页面主题相关但找不到被引数字模型答完后补引用生成阶段先自主发挥再补上来源编号断言可能是幻觉页面自然不存在页面内容动态变化AI 抓取时内容存在审计时页面已改版被引数字曾被提到但现在页面变了页面需要执行 JS普通请求无法拿到渲染后正文浏览器能看到脚本看不到反爬与登录墙请求被拦截或需要登录页面无法获取无法验证图片和扫描件为主数字在图中正文文本层没有文本提取不到数字从开发视角看第二类原因最需要警惕。如果系统在生成答案时没有强制模型引用检索片段模型完全可能根据自己的参数化记忆写出一个似乎合理的数字然后在后处理阶段拼接一个来源编号。这种情况产生的引用无论怎么重测都很难匹配上。第一类原因也和检索策略有关。很多 RAG 系统在召回时只关注文档与问题的语义相似度忽略了文档内部是否真的包含答案所需的数值实体。更好的做法是在召回阶段加入关键词和数值过滤让候选片段先经过一轮“是否包含关键实体”的粗筛。8. 对 RAG 系统研发的工程启示Haus Research 的审计结果从外部视角给 RAG 开发者提了个醒引用功能做出来不等于引用质量过关。从工程上有三个关键改造点。8.1 检索阶段保存 chunk 原文很多 RAG 系统的索引库里只保存了片段文本和文档 URL没有保存片段所属的块 ID 或段落路径。当模型生成的答案需要回溯来源时只能给出一个 URL无法精确到段落。这会导致两个问题一是引用粒度太粗二是无法验证生成内容是否真的来自某个 chunk。建议在索引 schema 中至少保存文档 ID、block ID、block 原文、文档 URL、抓取时间。这样生成答案后可以立刻把断言与对应 block 原文做校验而不是重新去抓网页。8.2 生成阶段使用结构化约束在 prompt 中明确要求模型只能基于给定的检索片段作答禁止添加引用片段之外的事实数字。如果检索片段里没有答案所需数据模型应回答“检索内容不足”而不是自行补全。下面是一个简化的结构化输出约束示例。def validate_citation(claim, retrieved_chunks): for chunk in retrieved_chunks: if claim in chunk: return {status: hit, chunk: chunk} key_digits extract_digits(claim) for chunk in retrieved_chunks: if all(d in chunk for d in key_digits): return {status: partial, chunk: chunk} return {status: miss, chunk: None}这个函数是简化逻辑真实场景中还要处理数值归一化、同义表达、表格数据等。但它体现了核心思路生成结果必须能回溯到检索片段回溯不上就要拦截。8.3 线上引用校验指标建议把“引用可验证性”作为 RAG 产品的线上监控指标之一。具体做法是定期从用户侧采样带引用的答案自动执行引用页面抓取和断言匹配计算引用精确率与引用覆盖率。只要指标出现明显下降就说明索引更新、模型版本或检索策略出了问题。这类自动化校验脚本可以直接复用第 5 节的思路只是需要加上任务队列、失败重试和监控告警。建议每批次至少抽 200 条断言才能获得比较稳定的统计结果。9. 引用审计的合规边界做引用审计涉及大规模抓取网页内容有几个边界问题必须遵守。第一遵守目标网站的 robots.txt 和访问频率限制。个人做小规模验证问题不大但如果要跑上千条引用需要控制并发尽量使用对方允许的抓取策略。不要使用绕过验证码、绕过登录墙的手段。第二审计结果用于公开发布时要脱敏处理。引用 URL、搜索问题、页面内容都可能包含个人信息。公开报告最好只保留统计结论和匿名示例。第三不要用抓取到的内容做二次训练或商业数据采集。围绕引用审计做技术分析可以但把原网站内容重新打包分发属于侵权行为。第四AI 搜索输出的信息也可能存在错误归因。无论审计结果如何读者在做重要决策时都应该回到原始来源进行人工确认。引用验证的价值是找出“哪些需要人工看”而不是替代人工判断。10. 总结怎么看待“三分之一”这个数字“三分之一引用页面不含被引数字”是一个抽样结果不应被理解成 Perplexity 所有引用里固定有三分之一失效。但它确实说明了一个核心问题RAG 系统的引用可信度不能默认成立必须通过审计来验证。对普通用户来说看到 AI 搜索给出的引用应该有一个基本判断引用链接只是线索不是终点。关键数据如果会影响决策需要点进来源页确认。对开发者来说这件事最大的价值是提供了一个可复现的审计思路抽样、拆断言、抓页面、做匹配、算指标。这套流程不限于 Perplexity任何 RAG 应用都可以照做。建议收藏备用后面做 AI 搜索或知识库问答时直接用这套方法验证引用质量。