Firecrawl ускоряет сбор данных для ИИ на 33%
Данные — это краеугольный камень успеха корпоративного ИИ, однако инициативы в области корпоративного ИИ часто сталкиваются с неожиданным инфраструктурным препятствием: получением чистых и надежных данных из интернета.
За последние два десятилетия веб-краулеры помогли справиться с трудностями сбора веб-данных. Веб-краулеры, которые автоматически извлекают контент с веб-сайтов, отлично работали в до-искусственно-интеллектуальную эпоху, когда люди обрабатывали неструктурированный HTML-вывод. Однако системы генеративного ИИ требуют данные в определенных форматах с постоянной надежностью в масштабах предприятия. Традиционные скраперы, выдающие «сырой» HTML, битые ссылки и неконсистентное форматирование, приводят к каскадным сбоям в конвейерах ИИ. Когда ИИ-агент не может надежно получить доступ к актуальной веб-информации, его полезность для реальных бизнес-приложений значительно снижается.
Эта проблема породила ИИ-нативные решения для веб-скрейпинга, такие как Firecrawl, которые появились, когда команда их основателей разрабатывала ИИ-системы чатов.
«Очень быстро мы столкнулись с проблемами с данными», — рассказал VentureBeat Калеб Пеффер (Caleb Peffer), основатель и генеральный директор Firecrawl. — Данные были неструктурированными, к ним было трудно получить доступ, и каждый из наших клиентов хотел, чтобы мы брали их веб-сайты, документацию компании, интрасети, а затем превращали это во что-то, что мог бы использовать их ИИ».
Это осознание привело к разработке проекта с открытым исходным кодом Firecrawl, который на сегодняшний день привлек более 50 000 звезд на GitHub и 350 000 разработчиков, а среди его клиентов числятся Shopify, Replit и Zapier. Недавно компания объявила о привлечении инвестиций в размере 14,5 млн долларов и выпуске новой версии программного обеспечения, призванной еще больше ускорить подготовку веб-данных для использования ИИ. Firecrawl утверждает, что ее веб-скрапер способен передавать структурированные веб-данные в системы ИИ на 33% быстрее конкурирующих решений.
Ставки высоки. Компании, инвестирующие миллионы в инициативы в сфере ИИ, обнаруживают, что ненадежный доступ к веб-данным может сделать сложные языковые модели практически бесполезными для реальных задач. Организации, которые решают эту инфраструктурную задачу на раннем этапе, получают возможность развертывать более совершенные ИИ-агенты, опирающиеся на актуальную и всеобъемлющую веб-информацию.
Проблема выбора: покупать или создавать скрапер данных
Инфраструктурная задача проявляется как классическая дилемма «создать своими силами или купить у стороннего разработчика», но со ставками более высокими, чем при выборе традиционного корпоративного ПО. Несколько корпоративных команд, с которыми побеседовал VentureBeat, выяснили, что создание надежного веб-скрейпинга для ИИ-приложений требует гораздо большей сложности, чем предполагалось.
Дэвид Чжан (David Zhang), генеральный директор компании Aomni, столкнулся с этой сложностью на собственном опыте при создании глубоких исследовательских агентов для отделов продаж.
«Я использовал трех разных поставщиков для краулинга, чтобы иметь возможность обрабатывать все те различные типы веб-сайтов, которые мне были нужны», — рассказал Чжан VentureBeat.
Команде Чжана пришлось искать баланс между скоростью и надежностью.
«Для служб веб-краулинга всегда приходится идти на определенный компромисс между этими двумя параметрами, и я думаю, что Firecrawl нашла наилучший компромисс: сохраняя очень и очень высокую скорость, она также способна успешно сканировать, пожалуй, 95% всех различных веб-сайтов, которые мне нужны», — отметил он.
Команда юридического ИИ из компании GC AI столкнулась с еще более сложными требованиями, когда попыталась создать собственное решение.
«Мы пытались создать собственный веб-скрапер. Но с этим связано множество трудностей, — рассказал VentureBeat Бардия Пурвакил (Bardia Pourvakil), соучредитель и генеральный директор GC AI. — Это не наш бизнес. Наш бизнес — это не скрейпинг, верно?»
Собственный скрапер GC AI давал сбои настолько часто, что компании пришлось также создать систему валидации на базе LLM для проверки качества сбора данных.
«У нас есть эта LLM, которая проверяет, был ли скрейпинг успешным или нет, и с нашим собственным скрапером мы часто терпели неудачу», — сказал Пурвакил.
Юридическая отрасль столкнулась с уникальными техническими проблемами, с которыми не могли справиться универсальные инструменты скрейпинга. Пурвакил отметил, что его команде требовалась возможность сканировать файлы docx в сети и общие PDF-файлы с Google Диска, с чем большинство скраперов не справлялись.
Конкурентная среда веб-скрейпинга
Рынок веб-скрейпинга вышел за рамки традиционных инструментов, сформировав четкие категории, в которых должны ориентироваться корпоративные команды.
Существуют традиционные фреймворки автоматизации браузеров, такие как Puppeteer, Scrapy, Playwright и Selenium, которые обычно появились еще до наступления современной эпохи ИИ и не созданы специально для удовлетворения потребностей генеративного ИИ. Существует также ряд современных скраперов, включая Browse AI, Bright Data, Browserbase и Exa.
Техническая команда GC AI оценила несколько решений для скрейпинга, ориентированных на ИИ, в процессе выбора поставщика.
«Мы действительно провели тестирование на целом ряде граничных случаев, пропуская их через наше собственное решение для скрейпинга, затем через Firecrawl, а также через другое решение, которое мы попробовали, — Exa», — поясняет Пурвакил.
Оценка выявила значительные различия в надежности и качестве результатов.
EXA зарекомендовала себя как заметный конкурент в сфере ИИ-скрейпинга, однако различия в форматировании создали проблемы при интеграции.
Решения на уровне протоколов, такие как llms.txt, представляют собой еще один подход к решению проблемы доступа к данным для ИИ. Тем не менее, эти протоколы все еще требуют инфраструктуры для перевода удобного для человека веб-контента в машиночитаемые форматы.
«Что касается LLMs dot text, то у нас фактически работает один из самых популярных генераторов LLMs dot text, потому что даже если у вас есть этот протокол, вам все равно нужен какой-то слой, способный перевести привычный для человека сегодняшний веб в этот машиночитаемый формат», — поясняет Калеб.
Firecrawl v2: Расширенные возможности для корпоративного ИИ
Второй крупный релиз Firecrawl решает основные задачи предприятий за счет значительных архитектурных улучшений и новых функций, ориентированных на ИИ.
Это обновление преобразует то, как организации осуществляют извлечение веб-данных для ИИ-приложений.
Интеллектуальное кэширование и индексация: Самым значительным достижением в версии v2 является гибридная система кэширования, которая кардинально повышает производительность при сохранении актуальности данных.
«Мы фактически кэшируем все эти страницы, — сказал Пеффер. — Мы по сути строим индекс интернета и сохраняем его в нашей системе».
Режим JSON для структурированного извлечения: Версия 2 представляет извлечение данных на основе промптов, что позволяет командам точно указывать, какая информация им нужна и в каком формате.
«Это позволяет вам с помощью промпта ввести именно ту информацию, которую вы хотите получить с сайта, и в каком формате, а затем Firecrawl выполняет работу по извлечению всего содержимого сайта и предоставлению вам этой точной информации в нужном формате, почти как по волшебству», — сказал Пеффер.
План принятия решений для корпоративных команд
Корпоративным командам, оценивающим решения для веб-скрейпинга для ИИ-приложений, следует расставить приоритеты в четырех ключевых областях:
Тестирование на надежность: Тестируйте решения на ваших конкретных целевых веб-сайтах, а не только на распространенных сайтах вроде Википедии. Различные поставщики демонстрируют значительные различия в показателях успеха для разнообразных веб-ресурсов.
Совместимость форматов: Убедитесь, что выходные форматы легко интегрируются с вашей инфраструктурой LLM и векторных баз данных. «Сырой» HTML часто требует серьезной предварительной обработки, прежде чем системы ИИ смогут эффективно его использовать.
Обработка граничных случаев (edge cases): Оцените, как поставщики справляются со сложными сценариями, такими как iframe, динамический контент и аутентификация. Эти граничные случаи часто определяют показатели успешности в реальных условиях.
Операционная поддержка: Учитывайте оперативность реагирования поставщика на новые нестандартные ситуации по мере масштабирования вашего приложения.
«С любой проблемой, возникшей на любом сканируемом сайте, мы обращались к команде, и они могли отладить и выпустить исправление в тот же день», — сказал Пурвакил.
Для предприятий, стремящихся лидировать в развертывании ИИ, инвестиции в надежную инфраструктуру веб-данных не являются опциональными. Это основа. Компании, решающие эту инфраструктурную задачу сегодня, закладывают фундамент для развертывания более сложных ИИ-агентов завтра.
Для предприятий, внедряющих ИИ на более позднем этапе цикла, это развитие означает, что проверенные инфраструктурные решения будут доступны в готовом виде. Команды смогут сосредоточиться на более ценных ИИ-приложениях, а не на переделке базовых возможностей скрейпинга.
