当 LLM 提取不再划算时

Firecrawl 抓取一个页面收取 1 个积分，而从同一页面提取结构化字段则收取 5 个积分（Firecrawl 定价，2026 年）。对于通过模型处理的相同 HTML，这相当于 5 倍的溢价。

宣传口号确实很吸引人：描述你想要的内容，直接获取 JSON 返回，无需维护选择器。对于不稳定的布局和一次性目标，它确实值这个溢价。但对于每天从相同的五个零售商那里抓取 50 万个商品页面的生产流水线来说，它并不划算。

我们目睹了许多团队上线了默认使用 LLM 提取的方案，但在收到账单月结单时，便开始寻找退路。解决办法通常不是放弃 LLM，而是将其放在流水线中的正确位置。

账目很快就会变得很难看

以价格较低的 Firecrawl 为例。在不进行爬取的情况下，抓取加上 AI 提取为每页 6 个积分，进行爬取则为 7 个积分（ScrapeGraphAI 拆解，2026 年）。在他们的成长档套餐中，每天处理 10 万个页面，在计算重试和支付任何 proxy 费用之前，每月大约需要花费 2.1 万美元。

即使运行自己的 LLM 流水线，账目虽有所变化，但开销依然不小。GPT-4o 的价格为每百万输入 token 收费 2.50 美元，每百万输出 token 收费 10 美元（PricePerToken，2026 年）。一个转换为 markdown 后的商品页面大约需要 4K 到 8K 的输入 token。假设输入为 6K，输出 JSON 块为 200。在每天 10 万个页面的情况下，这意味着每天需要 360 美元，每月需要 1.1 万美元，而这项工作在一次性设置好 CSS 选择器后完全是免费的。

这还是便宜的模型。如果换成 Claude Sonnet 4.6（输入 3 美元，输出 15 美元），账单就会翻倍（PE Collective，2026 年）。如果换成推理模型，根据其回答前的思考量，还会增加 3 到 10 倍的开销。

这些都还没把失败率算进去。3% 到 5% 的幻觉率听起来无伤大雅，但当你算一笔账时就不同了。在每天 10 万个页面的情况下，这意味着有 3000 到 5000 条错误记录流入你的数据仓库，而且由于模型给出的回答非常自信，这些错误记录看起来与正确记录一模一样。正如 DataHen 所说：“问题不在于 AI 有时会犯错，而在于它犯错时还极其自信。”（DataHen，2026 年）。

经验丰富的团队实际上是如何做的

阅读那些在生产环境中实际运行爬虫的厂商文档，你会发现一个一致的模式：混合模式。使用 LLM 分析一次页面，然后对后续的所有内容运行成本极低的确定性代码。

Zyte 在其官方文档中明确指出：“与其对每个页面都使用 LLM，不如利用 LLM 根据第一个页面的原始 HTML 生成所需字段的 CSS选择器，然后使用这些选择器来解析所有其他页面。”（Zyte LLM 指南，2026 年）。Apify 在其 2026 年指南中也推荐了相同的流程：先尝试 CSS 选择器，失败时再回退到 LLM（Apify 2026 指南）。DEV Community 上一篇关于生产环境部署的文章准确地描述了这种架构：缓存的选择器路径不花一分钱，只有在校验失败时才会触发 LLM（DEV.to，2026 年）。

因此，生产环境中的分工如下：

LLM 引导生成选择器（每个目标调用一次，成本微乎其微）
选择器针对每个页面运行（免费）
验证器（通常是正则表达式或存在性检查）捕获页面漂移
漂移在数周或数月后触发重新引导生成

单页成本从约 0.005 美元骤降至远低于 0.0001 美元。由于确定性解析不会产生幻觉，数据质量也得到了提升。这样，你就可以把 token 花在 LLM 真正擅长的工作上：阅读新颖的结构，而不是机械地重复你已经映射好的结构。

哪些场景下 LLM 依然物有所值

这并不是一篇反对 LLM 的文章。在许多提取任务中，模型确实是正确的工具，且积分计算也是合理的：

每周都在变化的极不稳定布局。 每周二都会失效的选择器所消耗的工程时间，比 LLM 提取消耗的 token 成本还要高。这种情况下，运行模型。
永远不会访问第二次的长尾目标。 编写选择器毫无收益。运行模型。
输出本身就是摘要的非结构化内容。 例如从职位描述提取技能、从文章提取主张、从评论提取情感。选择器无能为力。运行模型。
可选字段分散在各种布局变体中的页面。 包含 20 个条件渲染的单一模板，正是 LLM 击败正则表达式链的典型场景。

审视你的流水线。按数量对目标进行排序。请求量前 20% 的目标几乎总是具有稳定的结构（这就是为什么它们能占到前 20% —— 因为你是刻意集成它们的）。它们是选择器的候选对象。而长尾目标才是属于模型的地方。

这对你的技术栈意味着什么

2026 年的厂商宣传希望你默认使用 LLM 提取。积分定价让这在小型项目上看起来很合理。但当你规模化时，它就不再合理了，这就像一旦底层信号失效，proxy pool 规模不再能预测真正的成功一样。

为构建真实流水线的团队提供三点启示：

将获取与解析分离。 如果你的抓取服务商只返回经 LLM 提取的 JSON，那么在账单寄到时，你就无法回退到选择器。选择能够向你提供 HTML 并允许你自主选择提取路径的基础设施。
在选择器层级进行强力缓存。 生成的选择器可以在数千个页面中复用。昂贵的是生成调用，而不是使用。
按每条记录评估成本，而不是按每个页面。 一个单页成本为 0.001 美元但包含 5% 错误记录的流水线，其最终成本要高于单页成本为 0.005 美元但传输干净数据的流水线。存储、下游查询以及最终的清理工作都需要付出代价。

选择枯燥但有效的那一半

默认使用 LLM 提取适合做 Demo，但不适合用于生产环境。那些做对的团队，是将 LLM 视为理解页面的工具，而不是阅读页面的工具。在 2026 年，枯燥的确定性代码依然在处理海量数据的竞争中胜出，而模型则在处理新颖性方面胜出。两者在技术栈中都占有一席之地。

在 FourA，Single 和 Browser 会返回原始响应（HTML、渲染后的 DOM、headers、body）并止步于此。无论你是使用选择器进行解析、将其发送给模型，还是两者兼施，都由你决定。我们不会对我们未执行的提取操作加收积分倍数。