欢迎回来
登录你的知识库账户
忘记密码?
还没有账户?立即注册
创建账户
注册你的专属知识库
已有账户?去登录
找回密码
输入注册邮箱获取验证码
返回登录
请输入图片中的验证码以继续注册
加载中...
取消
新建收藏
手动添加你喜欢的内容
取消
编辑头像与昵称
上传新头像或修改你的显示昵称
支持 JPG/PNG,最大 2MB
取消

问题反馈

notebasewww.notebase.cn
控制台
内容库
动态
管理
账户
U
用户
--
在线
v0.8.7 · 知识库
笔记
KnowledgeBase
网络无边,知识有迹。
0笔记
0工具
30推荐

分类导航

按主题直达

编辑精选

站内用户贡献 · 真实笔记

最新收录

每日更新
继续浏览全部内容 →
>
笔记
0
加载中...
工具
0
此页用于记录用户反馈问题后的每一次改进
笔记用法

“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本,起稿或二次编辑时都能随时切换,同一篇笔记想用哪种形态来记,都由你说了算。

md、txt、csv、json 这类纯文本则原样载入,不做多余加工。拿一张现成的表倒进来、改几笔、再导出去,等于白用一台免费的格式转换器。

要带走就在右上角点“下载”,可导出 PDF、Word、Markdown、Excel、TXT 等格式;列表卡片“⋯”菜单里,也有同样的下载入口。

工具用法

在“工具”页点“+ 上传工具”即可发布:填好名称与链接,再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用,比堆介绍实在。

要分发安装包就一并上传压缩包(ZIP、RAR、7Z、TAR.GZ,最大 35MB),别人在详情页一键下载;只放链接不带附件也可以。

工具按大家的收藏热度排序,好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。

隐藏笔记

写笔记时勾上“隐藏”,这篇就只存在于你自己的账号里:不进列表、不进搜索、不上首页精选,也不会出现在任何公开的页面,链接发给别人同样打不开。

适合放密码、草稿、日记这类只给自己看的内容;想公开,去“发布”打开它,把“隐藏”的勾去掉再保存,之后编辑会默认保持原状态,不会悄悄变回公开。

数据安全

你的内容会同时保存在多个副本上,系统定期做备份与完整性校验,再配合异地容灾机制:就算某台机器出问题,数据也不会丢,可以长期放心存放;特别重要的资料,仍建议你另外再留一份备份。

技术

全站跑在容器化、模块化的现代架构上,更新、部署、回滚都很快,扩展性和稳定性都按长期运营的标准来设计(Built for reliability, designed to scale)。

理念

这个网站最早只是一个人的笔记仓库,后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法,只是干干净净地存放一些东西;既然做好了,就公开出来,万一有人用得上呢。

原则

不做大而全,不做平台梦,保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护:不会突然冒出付费墙,不会在角落塞广告位,也不会把你的数据卖给第三方。

更多

产品会持续迭代,站内日志页记录着每一次改动,改了什么都有迹可循;想了解这个站是怎么一步步走到今天的,翻翻日志就能看到来龙去脉。

举报

如果在这里看到涉嫌违规的内容,点对应卡片右侧的“举报”按钮就能提交,我们会尽快核实处理;也谢谢你花一点时间,一起把这里维护干净。

趋势
// 点击导航加载发现
归档
// 归档为空
最近浏览
// 暂无浏览记录
发布
// 加载中...
用户发布
// 加载中...
用户管理
// 加载中...
访问统计
// 加载中...
内容审核
// 加载中...
个人信息
// 加载中...
返回首页

Perplexity 引用审计:三分之一标注的引用并未包含所引用的数据

1970/1/1人工智能

对 Perplexity 搜索模型 1826 条数字相关引用的审计发现,34.7% 的引用无法打开或不包含所引用的数字;按断言计,14.4% 的事实陈述缺乏有效证据支撑。

背景:为什么引用审计重要

大语言模型(LLM)驱动的搜索引擎(如 Perplexity)与传统搜索引擎最大的不同在于:它不只返回链接列表,而是直接生成一段带有内联引用标记的答案。内联引用标记(如 [1]、[2])是 Perplexity 区别于普通聊天机器人的核心机制——它让用户能够追溯答案中每一句话的来源。这种设计本身是对 provenance(出处)的一种承诺:这句话来自这个 URL。

然而,这份承诺的有效性从未被系统性验证过。对于那些涉及具体数字的陈述(金额、百分比、日期、规模等),我们不需要额外的专家判断就能核实引用是否真实——只需要打开被引用的页面,检查上面是否真的出现了那个数字。Haus Research 正是基于这一思路,对 Perplexity 的两个搜索模型进行了一次大规模、可复现的引用真实性审计。

核心发现:三分之一引用落空

研究团队向 Perplexity 的 perplexity/sonar 和 perplexity/sonar-pro 两个模型提出了 310 个关于 210 家科技公司的事实性问题(每个问题涉及一个公司一个模板,部分公司获得第二个不同模板的问题)。所有问题均以温度 0(即确定性输出)提交。

收集到的所有引用中,共有 2511 个引用标记。其中,附加在包含具体数字的句子上的引用有 1826 个(占绝大多数,因为这些数字性陈述是最容易客观核验的)。这些数字性引用中:

  • 34.7% 指向的页面要么无法被普通读者打开,要么打开后完全没有包含该句子中的任何一个数字。
  • 如果以断言(claim)为单位而不是以引用为单位计分——即只要一个断言所指向的任意一个页面包含了它的任一数字,就算该断言通过——那么 14.4% 的断言失败(872 个带数字断言中有 126 个失败)。

团队之所以以引用为单位作为首要统计口径,是因为每个引用标记本身就是对出处的一个独立声明:"这个句子来自那个 URL"。引用失败,意味着这个声明不成立。

排除死链幻觉:主要问题不是链接失效

一个值得注意的细节是,失败的主因并非死链。在所有被引用的 URL 中,只有 1.3% 是真正失效的(404、410、DNS 失败、软 404 等)。真正的失败分为两个大类别:

  1. 页面无法进入(占 16.1%):被登录墙、付费墙、403 或反爬虫机制拦截。
  2. 页面可打开但不包含所引用的数字(占可读取页面的 16.1%)。

这两类问题的性质完全不同。前者可能是源网站的商业行为(如 PitchBook、ZoomInfo、Crunchbase、Reuters 等需要付费订阅),但作为引用来说依然失败——一个读者无法打开的脚注,是对出处主张的无法验证,恰恰违反了引用机制存在的意义。后者则更为严重:页面完全可读,但内容并不支持引用它的那个句子。

死链清单:程序化生成的 SEO 垃圾

虽然死链占比小,但它们极具特征性。在 sonar 报告的 38 个死链中,约一半(20 个)来自同一类网站模式:

  • komo.ai/directory/<company>-offices
  • temperstack.com/plans/<company>
  • devhelm.io/sla/<company>
  • apollo.io/where-is/<company>
  • portersfiveforce.com/blogs/brief-history/<company>
  • 以及 matrixbcg.com 和 canvasbusinessmodel.com 上的相同路径结构

这些页面显然是按公司批量生成的模板页面,目的就是为了捕获类似于 Perplexity 所问的查询,然后在下架时也极其廉价。例如,当被问到 Elastic 的总部时,sonar 引用了 komo.ai/directory/elastic-offices,但该 URL 返回 404;问到 Reddit 总部时,两个模型都引用了 apollo.io/where-is/reddit,返回 410 Gone;问到 Discord 最便宜的付费套餐时,sonar-pro 引用了 temperstack.com/plans/discord,同样返回 404。这些页面在被抓取的当天就已经不存在了。

可打开但不支持引用:最典型的两种模式

模式一:数字缺失

一个最干净的示例:当被问到 Vercel 最便宜付费套餐的入门价格时,sonar 回答 "免费 Hobby 计划是 $0/月,因此第一个付费层级起价 $20/月",并引用了 vercel.com/docs/plans。团队在写报告时抓取了该页面——HTTP 200 正常返回,页面确实列出了各计划名称,但 $20、$20/month 和 20/month 这些字符串完全没有出现。

这个数字很可能是正确的。但引用不能作为这个说法的证据。模型从训练数据中习得了这个价格共识(Vercel 的 Pro 计划第一档确实是 $20/月),但没有找到任何实际承载该数字的页面,于是就把一个文档页硬安了上去。

模式二:地址张冠李戴——模型自认"多源"却只引 Wikipedia

第二种模式更具揭示性,因为它跨公司重复出现。当被问及总部地址时,两个模型都产出了一个街道地址,却把它归因于该公司的 Wikipedia 条目:

公司 声称的地址 被引用的 Wikipedia 页面 该页面是否包含该地址?
Docker 3790 El Camino Real #1052, Palo Alto, CA 94306 en.wikipedia.org/wiki/Docker,_Inc. 否
Rippling 430 California Street, San Francisco, CA 94104 en.wikipedia.org/wiki/Rippling_(company) 否
Substack 111 Sutter Street, San Francisco, CA 94104 en.wikipedia.org/wiki/Substack 否
SentinelOne 444 Castro Street, Mountain View, CA 94041 en.wikipedia.org/wiki/SentinelOne 否

四个页面在写报告时均被重新抓取,都不包含所述的街道号码、街道名或邮编。更讽刺的是,部分回答甚至自己在措辞上已经暴露了痕迹——比如"多个来源列出..."或"几个商业目录列出...",但模型仍然只附加了一个 Wikipedia 链接。

这一现象深刻地揭示了:断言和其引用是由同一个过程生成的,而这个过程不是检索(retrieval),而是生成(generation)。模型先产生了认为正确的答案(基于预训练知识中的共识),然后为了满足"有引用"这个形式要求,生成了一个指向最可能承载该资料的页面的提及(mention),完全不顾及该页面是否真的包含了答案中的具体细节。

一个更温和的版本:sonar 声称 GitLab 的 CEO 是 Bill Staples,且他在 2024 年 12 月 5 日上任,引用了 GitLab 自己的高管团队页面。该页面确实列有 Bill Staples 的名字,但完全没有提及那个日期。也就是说,半个句子的出处是支持的,另一半没有。

按问题类型:在哪类问题中失败最严重

两个 Perplexity 模型合并,按问题模板分类,引用包含所引数字的比例排序如下:

问题类型 引用对数量 通过率(引用页面包含至少一个数字)
现任 CEO 是谁 235 44.3%
总部地址 202 53.0%
入门价格 171 62.6%
安全事件 205 66.8%
停机 SLA 145 69.0%
收购 278 69.1%
最近融资轮 103 70.9%
收入或 ARR 192 72.4%
创立时间 128 75.0%
员工人数 167 82.0%

这个排序并非随机。它精确地追踪了"该事实在某个权威单一来源里被结构化记录的程度":

  • 员工人数和创立年份通常存在于结构化字段中(如 Crunchbase、Wikipedia infobox),页面的设计就是为了承载这类数据,模型容易找到正确页面。
  • CEO 上任日期和办公地址的街道号则属于那种"每个人都在反复提及,但没有任何人把它当作规范发布出来"的信息。这类信息散落在新闻报道、公司博客、LinkedIn 摘要的散文段落里,没有一个单一可引用的信源。模型在这种情况下从训练数据中提取了共识值,却无法指向一个实际承载它的页面,于是随手抓一个语义相关的页面(通常是 Wikipedia)就附上引用。

付费墙与无效链接的普遍程度

在 perplexity/sonar 的 2915 个唯一被引 URL 中,分类如下:

  • 可访问且可读:78.7%
  • 登录/付费墙/403/反爬墙后:16.1%
  • 客户端渲染外壳(不可读):2.5%
  • 死链(404、410、DNS 失败、软 404):1.3%
  • 三次抓取尝试后仍不可达:1.4%

汇总到答案层面:84.2% 的 sonar 回答(310 个中)至少引用了一个普通读者无法打开的 URL;10.6% 的回答引用了至少一个完全死掉的链接。

作者特别指出:被门禁拦截并不是源网站的错——PitchBook、ZoomInfo、Crunchbase 等商业情报服务本来就有权收费。但作为引用,一个无法打开的脚注使溯源验证变得不可能,这违背了引用的本质目的。

方法论严谨性

值得注意的研究设计细节:

  1. 题目设计:十种问题模板全部对应真实用户会查找的事实(如融资轮次、员工数、总部位置、收入、违约事件等),每个公司获得一个模板问题,100 家公司获得第二个不同模板的问题,总计 310 问。
  2. 控制组:以带网页插件的 GPT-4.1 作为基线参照(但未展开详细对比结果)。
  3. 引用抓取策略:团队抓取了所有唯一 URL(仅 sonar 就有 2915 个)。任何第一次抓取失败的页面都会获得两次额外机会:更长的超时,然后通过轮换代理重试——以免因为某个数据中心 IP 地址不受欢迎而被误判为"不可访问"。第三轮重试救回了 192 个 URL。也就是说,分类结果永远偏向页面有利的一侧。
  4. 数字匹配规范化:报告声称"$185 million"与"$185M"与"185000000"等价,全部视为匹配。只要有一个数字(哪怕只是一个年份)出现在页面上,就算该引用通过。因此 34.7% 的失败率实际上是一个下限——每个失败的引用对意味着页面上连所引句子中的一个数字都没有出现。
  5. 温度为零:确保模型输出可重复性。

付费模型并不更好

初期的探索性研究暗示 sonar-pro 的接地性(grounding)可能比 sonar 差。但扩大到完整规模后,这个差距消失了。sonar 在数字引用对上通过了 65.9%(95% 置信区间为 62.7%-69.1%,这里暂时可以解读为:约三分之一的引用是不合格的)。也就是说,Pro 模型并不更差,但也绝对不更好。

更深层的启示

Perplexity 的引用机制虽然号称提供出处证据,但实际使用时需要高度警惕。问题的本质不是"检索不到的链接",而是模型在生成答案时把"知识"与"来源"错误地绑定。模型从训练语料的统计规律中得出正确答案(这解释了为什么 CEO 和地址的共识性信息失败率最高),然后被迫把一个不合适的 URL 作为"来源"生硬地附加到答案上。

对于 AI 搜索产品的用户而言,这意味着:

  1. 不要仅因为引用了权威域名(如 Wikipedia、公司官网)就信任某条带数字的陈述。引用来源的可访问性是真问题,但"可访问的页面里是否有那句话说的事实"是更深层的问题。
  2. 对于创始人信息、融资轮次、具体价格这类结构化数据,Perplexity 的可靠度尚可(70-80% 引用通过率);但对于 CEO 上任日期、办公室街道地址这类"人人皆知但无人规范发布"的信息,AI 搜索的引用模式会退化为"复述训练数据共识 + 象征性附加一个相关页面"。
  3. 由于自动化生成的低质量爬虫页面(如 komo.ai、temperstack.com 等批量 SEO 页面)也能混入引用列表,用户应警惕那些针对特定公司名称 + 问题类型的模板 URL——它们通常在查询发生时才生成答案,随后即下架。

结论

Perplexity 的引用质量现状:一个普通的读者打开被引页面,大约有三分之一的机会发现页面根本不支持它所引用的数字。这个问题的根源在于架构——当模型不执行真正的检索而是凭记忆生成出处时,引用就只是一种概率性的幻觉。它对基于共识的数字(价格、员工数、创立年份)表现较好,但对非标准化的事实(CEO 确切上任日期、精确街道地址)有着系统性的失误。

简言之:引用不是证据链,而是概率关联。用户在把 AI 搜索的引用当作可验证的脚注使用之前,必须意识到这条链的脆弱性。


原文链接:https://hausresearch.com/reports/perplexity-citation-audit/

编写使用方法
Markdown 格式 · Ctrl+Enter 确定
新建笔记
预览
数据表格
点击单元格编辑 · Tab 移动
A1fx
Sheet1
BIH1H2≡🔗</>
隐私提醒

取消
编辑工具
取消