GITHUB每日最佳：大模型时代的爬虫框架——Firecrawl（2024-09-08）

原创 | Char

公众号 | IT武库

   爬虫一直是获取数据的重要方法，而以数据作为驱动的大模型技术，一方面对爬虫技术提出了更多要求，一方面也促进了爬虫技术的发展。Firecrawl就是一个在这样的背景下，诞生的开源爬虫项目。

    Firecrawl可以将整个网站转换为能直接作为 LLM 训练语料的 markdown 或结构化数据，具有强大的抓取、爬取和数据提取能力。用户可以通过 API 使用它，包括使用 Crawling 功能爬取 URL 及所有可访问的子页面，使用 Scraping 功能抓取 URL 并获取指定格式的内容，使用 Map 功能获取网站的 URL，使用 LLM Extraction 功能从抓取的页面中提取结构化数据等。此外，它还提供了 Python SDK 和 Node SDK，方便开发者在不同语言中使用。该项目仍处于早期开发阶段，部分功能可能尚未完全准备好，但可以在本地运行。在使用时，用户需要遵守网站的政策和适用的隐私政策及使用条款，默认情况下 Firecrawl 会尊重网站的 robots.txt 文件中的指令。该项目主要遵循 AGPL - 3.0 许可证，部分组件遵循 MIT 许可证。

    Firecrawl提供了一个线上运行环境：Playground - Firecrawl，笔者在这里尝试爬取了CSDN的首页。由于需要注册账号才能爬取全部页面，这次实验只爬取了首页和首页上的4个子页面。以下是本次爬取效果：

CSDN站点首页

获取导航栏文本

获取头条新闻

获取页面外链

获取网页元数据

同时给出了4个子页面的爬取数据

    这个效果笔者认为是比较可圈可点的，除开作为项目主打的为LLM提供语料知识这个场景，还能用来做很多事情：比如站点分析与治理、互联网舆情分析、商品分析等任务场景中均可应用。但凡在需要爬虫的场合，Firecrawl都有广阔的用武之地。

    说完效果和应用，我们来看看项目本身实现。Firecrawl目前已为JavaScript、Python、Rust语言提供SDK，用户可以通过SDK快速地调用Firecrawl的云端服务。不过通过这种方式调用，需要首先在官网注册账号并且取得API key。Github仓库的代码中还提供了一个用React编写的UI界面。不过从代码上看，使用这个UI发送的请求也是调用云端服务，同样需要API key。

SDK初始化类，要求Firecrawl API key

UI界面中的请求目的仍是云端服务

    这样的开源项目其实比较类似AWS等云服务厂商，将自己产品的API调用封装成SDK，发布在开源站点供用户下载，以方便用户使用自家产品。推测Firecrawl的运营有按照这个方向孵化的打算。

    不过，Firecrawl开源项目的代码中目前还是包含了爬虫逻辑的源码。在本开源项目目录中，除了上文提到的3个SDK以及对Playwright（一个自动化框架，也可以用作爬虫框架）调用的封装外，www目录目前没有内容，test-suite包含一些测试用例与数据，redis目录放置一些redis操作脚本（redis在项目中主要用于设置任务队列，以支持对站点子页面内容的爬取），而api目录放置Firecrawl爬虫的源码。

项目目录

    Firecrawl的后台源码使用typescript编写，通过node运行。从源码来看，Firecrawl对单个url的爬取逻辑大致如下：

1、尝试对爬取目标url使用指定的抓取工具获取其html。代码中支持四种爬虫框架：Fetch、ScrapingBee、PlayWright，此外还有Firecrawl自己实现的FireEngine。不过除了Fetch方式之外，使用其他三种方式都需要提供API key，代码中也仅仅能看到给这些API发送请求，并无具体实现，故我们从Fetch方式的路径开始分析；

2、对目标url发送get请求，获取html；

3、判断有无pdf，若有则用pdf-parse库分析并生成pdf文字摘要；

4、清理不必要的元素；

5、调用处理markdown函数；

2-5步的外层调用

6、提取html中的全部超链接；

7、将html转化为markdown有几种实现，其中一种是使用go parser动态链接库go-html-to-md/html-to-markdown.so中，无法看见具体逻辑；

Html转markdown由这个so文件实现

    另一种是使用turndown库，由用户选择或者前者失败后启用；

用户不选择go parser或go parser失败则调用turndown

    关于站点、子链接的爬取本文不再赘述。通过对首页url html中全部子链接的分析，辅以任务调度和管理代码可以比较容易地进行实现。

    代码里还有个比较有意思的点，项目作者积极地试图将LLM应用到这个项目中，事实上，在处理PDF的部分，作者确实使用了LLM。不过，项目中有一个函数，是通过大模型对图片进行描述，生成图片的文字摘要用来代替图片以节省markdown的体积

    不过这个函数最外层的调用被注释掉了。是因为LLM读图的效果不稳定还是性能问题？

    另外，有一部分代码和测试用例中呈现了用户使用大模型对markdown进行问答的功能。这块能力在官方的playground上没有体现，严格来说也不属于爬虫部分的能力。

    结合官方文档，这部分代码应该是Firecrawl作为插件集成进如Dify、Langflow等其他LLM产品时使用的。

    Firecrawl是一个积极拥抱大模型技术的爬虫开源项目。从爬虫的角度看，它整合了其他的一些爬虫框架和各类工具库，并在许多地方进行了冗余实现，以防单个工具无法兼容目标站点，有很强的系统鲁棒性，且集成度比较高，但其输出格式过于固定，也导致其和其他一些传统的爬虫框架相比，缺少定制化能力从而难以满足一些精确爬取的需求。然而从大模型的角度来看，Firecrawl很好地适配了当前的大模型环境，能够作为插件为大模型提供互联网上各类站点的全量信息，使得大模型在回答用户问题时能够对网页进行全面地了解，这点具有十分重要的意义。