激进的AI爬虫让维基运营变得有些糟糕

# 激进的 AI 爬虫让运行维基变得相当困难 来源：https://weirdgloop.org/blog/clankers AI 爬虫月均请求估算图 机器人目前正以前所未有的速度抓取互联网，用于 LLM 训练数据\[1\]、\[2\]、\[3\]，推高了成本，破坏了面向公众的网站的稳定性。我想聊聊**这对维基来说尤其困难**，而且近几个月情况变得更加严重。 我运营着 Weird Gloop (https://weirdgloop.org/)，托管着一些有史以来最大的电子游戏维基，比如 Minecraft (https://minecraft.wiki/)、OSRS (https://oldschool.runescape.wiki/) 和 League (https://wiki.leagueoflegends.com/)。在过去三年里，我们不得不将越来越多的时间花在与这种机器人流量的对抗上——这种流量峰谷波动大，成本不成比例地高昂，并且越来越难以与人类区分。 **如果我们不持续缓解机器人攻击，它们消耗的计算资源将是我们所有其他东西加起来的约 10 倍**——尽管“所有其他东西”包括每天数千万次（人类）页面浏览和数万次编辑。所有运行维基的人都面临完全相同的问题。维基媒体基金会发表了一篇关于它影响运营的帖子，每个主要的维基农场都经历过不同程度的服务中断，一些较小的独立维基甚至完全下线。 总体而言，我估计今年维基生态系统中的所有服务器问题中，大约 95% 是由糟糕的爬虫引起的。我交谈过的每一位维基系统管理员都在处理这些具体问题： ## 爬虫伪装成人类访客，而且越来越像 我看到的大多数关于爬虫的讨论都集中在主要 AI 公司运营的机器人上（GPTBot、ClaudeBot、PerplexityBot 等）。尽管这些“官方”机器人有时难以遵守 robots.txt，但至少它们*通常*会在用户代理字符串中正确标识自己为机器人，这使得网站运营者通过 Cloudflare、nginx 或任何其他技术阻止它们变得非常容易。 问题是，当站长开始根据用户代理阻止 AI 爬虫时，它产生了巨大的激励，让机器人伪装成人类流量以避免被封锁。这场猫捉老鼠的游戏在过去几年里一直上演，并且机器人已经非常擅长模仿人类请求。现在，命中我们维基的大部分 AI 爬虫流量都在精心构建请求，发送正确的标头来伪装成最新版本的谷歌 Chrome，这消除了我们以前可以用来阻止它们的明显的“机器人或真人”信号。 ## 它们使用数千万个 IP 地址 在 2023 年之前，如果我们遇到有人抓取维基的问题，95% 的情况下它们只使用单个 IP 地址，或者单个数据中心的少量 IP 子网。因此，根据 IP 或 ISP 特征来阻止不良行为者大体上是有效的。 ……然而住宅代理出现了，任何人只要有信用卡，就可以让他们所有的抓取请求通过一个由数百万个 IP 地址组成的网络进行“洗白”。维基有时会受到每天循环使用数百万个 IP 的爬虫运行的攻击，而且它们>看起来<像是来自合法的地方：主要是住宅 ISP（康卡斯特、AT&T、查特等），那里的客户很可能甚至不知道他们的 IP 被用作住宅代理的出口节点。 除了住宅代理之外，很多抓取发生在属于 Facebook 和 Google 的 IP 上。不良行为者能够使用 facebookexternalhit 链接预览或 Google 翻译来让请求发生在 Google/Facebook 服务器上，这完全掩盖了请求的来源。有时我们不得不在我们所有的维基上禁用 Google 翻译的 URL 工具，因为通过它发出的请求有 99.99% 是滥用的。 ## 它们主要爬取愚蠢的 URL 大多数这些 AI 爬虫似乎以最愚蠢的方式选择目标： 1. 访问维基首页 2. 访问该页面上的所有链接 3. 访问那些页面的所有链接 4. ... 5. 重复直到所有链接都被访问过 它们似乎完全不知道有 robots.txt 和站点地图会告诉它们哪些 URL 值得抓取。对于维基来说，这是一个特别愚蠢的策略，原因如下。OSRS 维基有大约 40,000 篇“文章”，所以有 40,000 个 URL 构成了网站上绝大多数有用信息。但是，一旦你考虑到所有旧修订版本、编辑屏幕和特殊页面——这些页面供编辑维基的人使用，至少有**十亿**个可导航的 URL。 这对攻击维基的爬虫意味着两件事： 1. 这种天真的爬取过程永远不会完成 2. 绝大多数的请求没有做任何有用的事情 使用浏览器用户代理的爬虫请求 这些 URL 中的大多数对于训练 LLM 来说不可能是有用的数据，但似乎它们把大部分资源都花在了这上面。这些奇怪的请求对我们来说*服务成本*也异常高昂，因为它们绕过了大多数真实用户请求命中的各种缓存层。缓存命中通常需要不到 20 毫秒的处理时间，但这些奇怪的旧差异版本经常需要 1-2 秒。这意味着顶层指标（“每天 800 万次机器人请求”、“机器人使用了 65% 的带宽”等）**严重低估**了问题的范围，因为 CPU 能力通常是重要的瓶颈，而带有所有奇怪查询参数的机器人请求的服务成本往往是其他请求的 50-100 倍。 ## 最糟糕的机器人流量非常峰谷波动，因此汇总指标低估了问题 minecraft.wiki 逐分钟请求图 我之前说过，我们每月收到大约 2.5 亿次机器人请求（大约每秒 100 次），但这只是长期平均值：这些爬虫经常以每秒超过 1000 次的短爆发方式运行，几乎与老式的 DDoS 攻击无法区分。因此，尽管从长期来看，机器人可能只占我们总 CPU 使用率的 ~50%，但它们滥用性的流量峰值却导致了维基正在经历的 ~95% 的缓慢和中断。 ## 不清楚是谁在做 我一直称这些不良流量为“AI 爬虫”，但因为每个都在伪装成 Google Chrome，我不知道谁对此负责，也不知道他们用他们吞噬的大量维基数据在做什么。是数据经纪人？是同时进行多方面研究的前沿实验室？还是仅仅是有权访问住宅代理的随机独立项目？我低估了现在的准入门槛有多低吗？我真的不知道。 如果奇迹发生，正在阅读这篇文章的某人是这些努力背后的推手……老实说，给我发封邮件或什么的。我很想知道你从这当中得到了什么，并为你找到一种不那么愚蠢的方式来做这件事。 --- ## 对我们有效的方法 整个情况听起来有点悲惨，对吧？如果这是个推销宣传，这大概就是我要切换话题，告诉你我们有一个价值百万美元的魔法解决方案出售的地方。我们没有，我很确定这只是一个非常困难的问题，每个人都在与之斗争。 最常见的技巧是将你的网站放在 Cloudflare 挑战或 Anubis 之类的东西后面，这在过去一年里在互联网上变得无处不在。这有点效果，但有两个主要问题： Cloudflare 挑战 1. 会有一些时期，某些机器人能够持续通过挑战。我们不太清楚它们用什么方法，但我认为在幕后，Cloudflare 和机器人开发者之间存在着一场军备竞赛。Cloudflare 赢得这场战斗的概率可能是 90%，但剩下的 10% 可能相当棘手。 2. 实际读者**讨厌**在访问维基之前看到挑战。你能怪他们吗？所以理想情况下，你有好的启发式规则来决定哪些流量值得挑战，以便大多数人不受影响……这又回到了可靠检测哪些流量是自动化的困难。 几乎所有的人都有一些**手写的防火墙规则**，这些规则针对其基础设施和过去遇到的攻击是特定的。通常这些过滤器会基于特定的用户代理字符串、IP 组或 ASN。我们在 Cloudflare/CDN 级别做大部分工作，但其他一些维基则在 nginx/Web 服务器端做。当然，仅仅基于用户代理/IP 进行阻止如今很少足够了。因此，随着时间的推移，我们不得不查看请求的更复杂属性——HTTP 版本、标头、TLS 密码和与 ja4 相关的哈希——以尝试找到简单规则来判断哪些流量是机器人的。 我们发现一个非常有用的视角是**寻找人类在聚合层面做而机器人不做的事情**。对于运行 MediaWiki 软件（和我们一样）的维基，有许多类型的 HTTP 请求是真实浏览器上的正常人在使用维基时常做的，而机器人通常不会做。因此，如果你看到一些可以分割出来的流量块（基于标头、ja4 哈希或其他什么），它访问了很多文章但没有进行任何经典的“人类”请求，这是一个强烈的信号，表明你可以对这个流量块进行挑战。 这种寻找机器人流量中**不存在的**人类行为请求的技巧非常强大。我们开始构建一个系统，它查看我们“缺失”的流量，并自动提出基于“决策树”的启发式规则来决定挑战哪些流量。到目前为止的测试中，它似乎做得很好，几乎根除了所有爬虫，但我一直犹豫是否让其无人监督运行，因为我们不清楚它对有不同寻常浏览习惯的人（NoScript 用户、屏幕阅读器、意外类型的设备）会产生什么样的误报。我也不喜欢为这个永久构建和维护我们自己的机器学习/数据分析基础设施的想法。我当然更愿意专注于制作维基。 还有更奇特的技术： - 我见过有人通过 TCP/TLS 时序差异成功识别住宅代理 - 有公司出售住宅代理 IP 的实时数据库，尽管我不清楚当大多数住宅代理同时也被真实人员使用时，这有多大的可操作性。 - 这个机器人检测问题直观上感觉**应该**可以在大规模范围内解决，像 Cloudflare 或大型云提供商这样的人，可以利用他们庞大流量中的包级网络信息来制作出色的启发式规则……但我交谈过的任何人都没有对任何这些商业机器人检测产品（包括那些年花费六位数的产品）的启发式规则感到印象深刻。 ## 对其他读者来说不好的其他想法 有一些阻止 AI 爬虫的“核选项”，但它们对真人来说更具破坏性。我见过最常见的是： - 要求读者登录才能查看任何可能生成成本高昂的页面。这就是 Fandom 几个月前在他们所有维基上所做的。 - 对所有流量提供 Cloudflare 挑战 这两者作为站长都是可以理解的做法，但对维基及其社区的长期健康来说很糟糕。我从 16 年建立维基社区的经验中学到的主要教训是，**吸引新贡献者到维基的最佳方法是消除摩擦**——让编辑更容易，让探索维基内部更容易，并拆除将读者与编辑分开的进入壁垒。所有这些更极端的反机器人技术都增加了新的摩擦，并带来了可预见的后果——我做了一个小分析，发现 Fandom 上来自新用户的贡献在 Fandom 将“内部页面”对 >95% 没有账户的读者隐藏后下降了大约 40%。我很难认为这是一个值得的权衡。 --- ## 我们从这里走向何方？ 只是为了让人们不要太沮丧——*我们仍然做得不错！*尽管我希望能让时间倒流三年，再也不用处理这些爬虫的废话……但我仍然喜欢托管维基，我喜欢帮助维基迁移离开 Fandom，而且我想象不出机器人会严重改变其中任何一部分的情景。我长期担心“AI 概览”会扼杀将维基读者转化为维基贡献者的管道，但那是另一天的故事了。 我甚至有几位朋友半开玩笑地建议，这波机器人浪潮可能**对** Weird Gloop**有好处**，因为我们在 MediaWiki 技术方面比平均水平更好，而且也许我们会受益，因为爬虫提高了托管维基所需的技术和时间门槛。但我认为**如果人们不能轻松托管维基，互联网会变得更糟**。我可以想象一个噩梦般的情景，如果你最终需要一个值班轮换人员、一个机器学习工程师或一个企业级产品才能托管一个维基，而不被爬虫机器人间歇性打击……这对整个独立维基社区来说将是非常坏的消息。 我真的不确定结局会如何。我怀疑机器人拥有者和站长之间的军备竞赛将持续下去，直到有人想出一个巧妙的方法来改变围绕抓取的结构性激励。例如，我认为 Cloudflare 新的爬取 API 有可能改变这种动态，如果使用那个 API 最终对机器人来说比构建他们自己的忽略 robots.txt 并给我们带来问题的系统更省力。当然，我更希望抓取根本不要发生，但我们可能无法让那个潘多拉魔盒关闭。 但是！让我感到乐观的是，实际上**有成千上万像我们一样的人**——运营他们的网站，并寻找越来越巧妙的技术来对付机器人。我在私下交谈中从其他系统管理员那里听到了一些非常酷、非常具体的想法，我假设在随机的 Slack、Discord 和其他小群体中有很多讨论在进行。但是**我希望有更多关于实践和具体细节的公开讨论**，因为我 [原文在此处中断]