← 返回信息流

dev.to #ai短讯

Firecrawl vs Tavily:AI Agent 检索广度决定事实召回率(97% vs 82%)

dev.to作者:Sravya Dangeti教程AI评分:50/100

作者构建了一个基于 Gemini 的竞品调研智能体,通过对比 Tavily 和 Firecrawl 两种检索后端,发现 Firecrawl 在事实召回率上达到 97%,优于 Tavily 的 82%。结论指出检索广度直接决定了 AI 应用的 grounding 效果。

我运行着一个竞品调研智能体:给它一个公司网址,它就能找到并验证该公司的竞争对手。它是无框架的(在 Gemini 上直接使用工具调用的循环),并且具备确定性的伪造检查机制:智能体引用的每一个页面,都必须在我代码实际获取的页面账本中。

检索仅使用 Tavily。我将 Firecrawl 作为第二个后端添加到一个提供商切换器后面,并对两者进行了基准测试。以下是我的发现,包括 Firecrawl 失分的地方。

测量方法

  • 10 家公司,20 个页面,选择了不同类型的网站:重度 JS 应用、文档为主的开发者工具、定价页面、内容稀疏的早期初创公司网站。
  • 针对每个官方页面的事实答案键(定价层级、产品名称、标语、YC 批次)。每个事实都通过纯 HTTP 请求与原始 HTML 进行审计,不涉及任何提供商。更正记录在仓库中。
  • 两个实验:A,仅检索:每页抓取两次,不涉及 LLM,评估哪些事实进入了内容。B,端到端:运行完整的智能体,保持模型、提示词和温度恒定。

实验 A:检索质量

Tavily(基础版,部署时)Firecrawl
抓取成功率100%100%
事实召回率82% (56/68)97% (66/68)
延迟 p50250 毫秒1,391 毫秒
中位数内容量11,735 字符16,257 字符

Firecrawl 找到了更多关键事实。它的速度慢了约 5.6 倍,按公布的价格计算,每页的信用点成本约为 5 倍。

Tavily 的高级提取层并没有帮助:它在 20 个页面中的 19 个页面上返回了与基础版字节完全相同的内容,而在一个页面(docs.firecrawl.dev/billing)上,它返回了 404 错误,而基础版成功获取。我在我的代码之外通过原始 API 调用重现了这一点。

样板过滤器的真实代价

Firecrawl 的 only_main_content=True 会剥离导航栏和页脚。我测量了开启和关闭的情况:

页面样板内容(开 / 关)找到的事实(开 / 关)
brickanta.com12% / 19%1/1 / 1/1
composio.dev10% / 16%2/2 / 2/2
composio.dev/pricing4% / 18%2/2 / 2/2
notion.com13% / 45%0/1 / 1/1

在三个页面上它是免费的。在 notion.com 上,它移除了导航菜单中的产品名称,而这正是我需要的那个事实。要找回它意味着接受 45% 的样板内容。通常是免费的,偶尔很昂贵。

实验 B:检索广度决定接地能力

惊喜来自端到端的运行结果。根据智能体咨询的来源数量对所有模式进行汇总:

咨询来源数运行次数被拒绝的引用每次运行平均
10 个或更少9485.3
超过 10 个42120.3

所有低来源数的运行都来自我的一个配置:使用 Firecrawl 搜索配合全页抓取,限制每次搜索结果最多 3 条以节省信用点。来源越少,智能体搜索得越多,更频繁地达到其 9 次调用的预算限制,并引用了它从未获取过的页面。

伪造检查机制捕获了所有这些引用。没有一个能进入最终报告。

教训:如果让智能体缺乏来源,它就会引用它从未读过的页面。这看起来像是幻觉问题。但这是一个检索问题。

我想澄清的一个注意事项:所有 9 次低来源数的运行都使用了相同的 3 条结果配置,因此在这个数据集中无法将广度和配置分开。这表明的是关联性,而非孤立的因果关系,这是关于我的设置的发现,而不是关于 Firecrawl 质量的结论。

Firecrawl 失分的地方

  • p50 延迟慢约 5.6 倍。
  • 每页和每次端到端运行的信用点消耗更多。
  • 在 brickanta.com 上,它丢弃了主标题和段落,同时保留了 YouTube 嵌入控件,这一现象可复现。
  • 更差的样板内容异常值(最大 23% vs 15%)。
  • 上述 Notion 导航栏的权衡取舍。

其他值得了解的信息

使用 Firecrawl 抓取配合 Tavily 搜索(我的“混合”模式)的成本与纯 Tavily 相同,且没有带来任何可衡量的好处。

如果我要给正在做选择的人的建议

  • 如果事实覆盖率对于处理混乱的真实网页页面最为重要,那么 Firecrawl 值得承受其延迟和成本。
  • 如果你需要速度和低成本,Tavily Basic 是一个强有力的选择。
  • 无论哪种情况,都请为你的智能体在每次搜索中提供足够的来源。检索广度对 grounding(事实依据)的影响比供应商本身更大。

局限性

  • 仅包含 10 家公司、20 个页面:样本量较小。
  • 端到端运行跨越两天,因此网站在此期间可能已发生变化。
  • 由于 Gemini 免费层配额限制,部分运行被排除。这些排除项已在结果中按模式分别统计。
  • Tavily 的成本比较使用的是公开定价,而非实际测量的用量。
  • 答案键的措辞在与原始 HTML 进行审计后进行了修正,且是在最终运行之前完成的。所有更改均已记录。
  • 我使用 Firecrawl 自身抓取了 firecrawl.dev。

复现方法

方法、原始结果、答案键和变更日志均位于以下仓库:https://github.com/sravya520/competitor-research-agent/blob/main/docs/firecrawl_vs_tavily.md

欢迎反馈,特别是来自任何为智能体工作负载调整过 Firecrawl 或 Tavily 设置的人员。

译文已达到本站中文翻译的字数上限,剩余内容请查看原文。

阅读原文