基于 CSS 选择器的解析器在网站更改布局时会崩溃。基于 LLM 的解析器不会崩溃，但每个页面都会收费。到 2026 年，它们之间的选择不再是个人喜好：模型的价格相差十倍，而同一页面的费用可能根据您发送给模型的内容而为 3000 或 20000 个令牌。以下是三种方法在费用、可靠性和代理流量上的比较，基于 1000 页和一百万页的计算。
简而言之：选择什么
- 选择器 (CSS/XPath) — 一个页面模板，大量数据，稳定的布局。提取成本接近于零，但支持工作由开发者承担。
- LLM 提取 — 多个不同的网站，不稳定的布局，单次任务。您需要为每个页面支付令牌，并且必须验证响应。
- 混合模式 — LLM 一次性编写选择器，之后使用选择器，只有在数据验证失败时才调用模型。对于大多数常规解析器来说，这是最佳选择。
比较标准
我们从五个实际影响最终费用和数据质量的方面进行比较：
- 每 1000 页的提取成本；
- 布局更改时的表现；
- 虚构值的准确性和风险；
- 速度和延迟；
- 代理流量消耗 — 如您所见，这几乎不受方法选择的影响。
LLM 提取的成本：根据 2026 年 10 月的价格计算
标准费率下每百万个令牌（输入/输出）的官方价格：
- Gemini 2.5 Flash-Lite — $0.10 / $0.40；
- Gemini 3.1 Flash-Lite — $0.25 / $1.50；
- Claude Haiku 4.5 — $1 / $5；
- Gemini 3.5 Flash — $1.50 / $9。
Google 和 Anthropic 提供批量 API，输入和输出享受 50% 的折扣 — 对于不需要即时响应的解析，这是一种节省的第一杠杆。
主要变量不是模型，而是您发送给它的内容
原始 HTML 页面在传递给模型时通常占用 10,000 到 40,000 个令牌。Cloudflare 在启动代理的 Markdown 功能时给出了一个例子：同一篇博客文章在 HTML 中占用 16,180 个令牌，而在 Markdown 中占用 3,150 个令牌 — 减少了 80%。其他关于新闻、文档和商品卡片的测量显示减少幅度在 67% 到 94% 之间。
为了计算，我们假设：原始页面为 20,000 个令牌，清理后的 Markdown 为 3,000 个，加上 500 个令牌用于指令和模式，输出为 300 个令牌的 JSON。在 1000 页的情况下，我们得到：
| 模型 | 原始 HTML (2050 万输入) | Markdown (350 万输入) |
|---|---|---|
| Gemini 2.5 Flash-Lite | ≈ $2.17 | ≈ $0.47 |
| Gemini 3.1 Flash-Lite | ≈ $5.58 | ≈ $1.33 |
| Claude Haiku 4.5 | ≈ $22.00 | ≈ $5.00 |
| Gemini 3.5 Flash | ≈ $33.45 | ≈ $7.95 |
在相同结果下，最差和最佳选项之间的差异为 70 倍。这个差异的三分之二来自于输入的清理，而不是模型的选择。在每月一百万页的情况下，这要么是大约 $470，要么超过 $33,000。
还有一个细节：从 4.7 版本开始，Claude 模型使用新的令牌化器，根据 Anthropic 的数据，能够为相同文本提供大约 30% 更多的令牌。在比较不同代模型的账单时，请考虑这一点 — Haiku 4.5 使用的是旧的令牌化器。
选择器：几乎免费，直到网站更改
在已经下载的页面上执行 CSS 或 XPath 选择器的成本是处理器的毫秒级分数。根据 ScrapingBee 的指南，在稳定布局下，普通选择器的成本大约是 LLM 提取的 10 倍更低且更快。在实践中，差异甚至更大，因为选择器没有对模型 API 的网络请求。
选择器的成本在于支持：
- 网站重命名类或将块包装在新的 div 中 — 解析器默默返回空字段；
- A/B 测试向不同访客展示不同模板，部分页面无法解析；
- 在 50 个不同的网站上，您需要支持 50 套选择器。
最危险的场景不是崩溃，而是数据的静默损坏：选择器抓取了相邻元素，旧价格在数据库中写入数周而不是当前价格。
LLM：对布局具有韧性，但会虚构
模型不需要精确的元素路径 — 它根据语义查找“价格”。这解决了重命名类和不同模板的问题。但出现了三种典型故障，所有在生产中运行过这种解析器的人都描述过：
- 虚构值 — 模型“猜测”页面上不存在的价格或货号；
- 缺失字段 — 部分数据未提取；
- 结构漂移 — 字符串代替数字，键名不同。
保护是必需的：严格的响应模式、验证（例如，Pydantic）、温度 = 0 和错误时重试。零温度减少了波动，但并不能完全消除幻觉。对于价格和库存，合理地添加检查“值确实出现在页面文本中”。
延迟也更高：通过代理加载页面的时间加上模型的响应 — 从几分之一秒到几秒。对于每天监控一次，这并不重要，但对于跟踪掉落则至关重要。
混合模式：LLM 编写选择器，而不是提取数据
第三种方法得到了流行库的直接支持。在 Crawl4AI 中有生成模式的功能：模型一次查看 HTML 示例并返回一组 CSS/XPath 选择器，之后提取过程无需调用 LLM。文档强调这是一次性成本，模式可以无限制地重复使用；在多个示例中，模型通常选择更稳定的基于属性的选择器，而不是脆弱的基于位置的选择器，如 nth-child。
混合模式的工作流程：
- LLM 根据 3-5 个相同模板的页面示例生成选择器。
- 解析器在选择器上工作，每条记录都由验证器检查：字段到位、类型正确、价格在合理范围内。
- 如果无效记录的比例超过阈值（例如，2-5%），页面将转到 LLM 提取，而模式将重新生成。
- 新模式在控制样本上运行，只有在此之后才替换旧模式。
这样，您只需在布局更改时为模型付费，而不是为每一百万页付费。
汇总表
| 标准 | 选择器 | LLM 提取 | 混合模式 |
|---|---|---|---|
| 提取成本 | 接近零 | $0.5–33 每 1000 页 | 接近零 + 单次调用 |
| 布局更改 | 崩溃，通常默默无声 | 通常能够承受 | 自动修复 |
| 虚构数据的风险 | 无（但有“不是那个元素”） | 有，需要验证 | 最低 |
| 速度 | 最大 | + 每个页面的模型响应 | 与选择器相同 |
| 多个不同网站 | 维护成本高 | 强项 | 良好，每个模板都有模式 |
| 代理流量 | 相同 — 模型不会减少下载的字节 | ||
关于代理：LLM 不节省流量
计算中的一个常见错误是认为“智能”解析器在网络上更便宜。实际上：HTML 转换为 Markdown 在下载后进行，因此无论采用何种提取方法，完整页面都会通过代理传输。例外情况是网站所有者自己启用了通过 Accept: text/markdown 头部返回 Markdown（如 Cloudflare 的功能），但这是网站的解决方案，而不是您的。
为了规模：如果 HTML 大小为 200 KB，没有图片，1000 页大约是 0.2 GB，或大约 $0.54 在 住宅代理 上，每 GB $2.70。与上表比较：将原始 HTML 发送到 Claude Haiku 4.5 的模型费用将是代理费用的 40 倍，而在 Markdown 和 Flash-Lite 中，它们是可比的。如果您使用无头浏览器渲染页面，流量将大幅增加 — 我们在比较中有测量 Playwright、Puppeteer 和 requests 在 1000 页上的流量消耗。
无论采用何种方法，真正影响流量的因素有：
- 不下载图片、字体和分析工具，如果不需要的话；
- 寻找内部 JSON API 而不是 HTML；
- 避免不必要的重复：每次封禁和重试都是付费字节。有关每 GB 费用为何具有误导性的更多信息，请参见 成功记录的真实成本分析。
对于没有严格反机器人保护的简单目录，使用 数据中心代理 每 GB $1.50 足够；在 IP 主机在入口处被切割的地方需要住宅代理。
场景建议
- 监控一到三个市场的价格，数十万张卡片。 混合模式或纯选择器加验证器。仅在重新生成模式时连接 LLM。
- 从数百个不同网站收集数据（线索、职位、联系方式）。 通过便宜的模型在批处理模式下进行 Markdown 的 LLM 提取。没有严格的模式和验证不要启动。
- 对几千页进行一次性研究。 LLM：花费几美元可以节省数天的选择器编写时间。
- 数据错误会造成经济损失（重新定价的价格、库存）。 选择器或混合模式加上与页面原始文本的值核对。
- RAG 和知识库。 这里需要的不是结构，而是纯文本：转换为 Markdown 而不提取字段，模型仅在响应阶段使用。
结论
LLM 提取并没有取代选择器，而是改变了选择的重点。最便宜的是混合模式：模型编写和修复选择器，而不是读取每个页面。如果在每个页面上都无法避免使用模型，请先将输入清理为 Markdown，并使用批处理：这两个步骤在您开始选择模型之前将费用减少 5-10 倍。请记住，代理流量不受提取方法的影响：节省流量需要在您下载的内容上，而不是在您如何解析上。