dev.to #ai短讯
Firecrawl vs Tavily:AI Agent 检索广度决定事实召回率(97% vs 82%)
作者构建了一个基于 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) |
| 延迟 p50 | 250 毫秒 | 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.com | 12% / 19% | 1/1 / 1/1 |
| composio.dev | 10% / 16% | 2/2 / 2/2 |
| composio.dev/pricing | 4% / 18% | 2/2 / 2/2 |
| notion.com | 13% / 45% | 0/1 / 1/1 |
在三个页面上它是免费的。在 notion.com 上,它移除了导航菜单中的产品名称,而这正是我需要的那个事实。要找回它意味着接受 45% 的样板内容。通常是免费的,偶尔很昂贵。
实验 B:检索广度决定接地能力
惊喜来自端到端的运行结果。根据智能体咨询的来源数量对所有模式进行汇总:
| 咨询来源数 | 运行次数 | 被拒绝的引用 | 每次运行平均 |
|---|---|---|---|
| 10 个或更少 | 9 | 48 | 5.3 |
| 超过 10 个 | 42 | 12 | 0.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 设置的人员。
译文已达到本站中文翻译的字数上限,剩余内容请查看原文。