Комментарии 25
Другие модели попробуй. Gemini flash lite стоит в 33 раза дешевле gpt 4o, кроме текста может еще и скриншоты сайтов разглядывать.
а чего вы structured output не используете? Он же для выделения данных и придуман.
structured outputs, безусловно, более продвинутый, но требует подключения дополнительных библиотек, типа pydantic и написания дополнительного кода. Мне показалось, что это будет перегружать статью для тех, кто только осваивается в теме. Потом, structured outputs поддерживается не всеми моделями gpt, например для gpt-3.5 он не поддерживается. Спасибо за дополнение, возможно действительно стоит упомянуть про такой формат в статье.
Наивный вопрос, который напросился по прочтении.
Если есть "классические" библиотеки парсинга, их функционала во многих случаях оказывается достаточно, но они ломаются при смене верстки, то не будет ли эффективнее использовать LLM для исправления кода сломавшегося парсера, чем для парсинга сайта непосредственно с помощью LLM?
"Ломаются парсеры при смене кода верстки" - имеется ввиду, что они, пытаясь вытащить элемент которого уже нет (изменился) отдают некорректные данные. Сам код парсера никак не меняется при этом. Но я не уверен, что точно понял ваш вопрос. Можете пример привести?
LLM умеет не только парсить сайты, но и генерировать код.
Можно ли попросить LLM сгенерировать скрипт-парсер под конкретный сайт?
Можно ли добиться от LLM, чтобы она подогнала скрипт-парсер под новую верстку сайта?
Ведь в таком случае мы условно разово пользуемся платными услугам LLM as a Service для генерации скрипта, а затем безлимитно парсим сайт, пока сгенерированный скрипт работает.
Насколько такой подход на данном этапе развития осуществим?
Ну конечно, вы можете сгенерировать код парсера с помощью любой нейросети. Если у вас действительно есть такая проблема, как изменчивость верстки, то в данном случае вам нужно будет постоянно мониторить изменения верстки и обращаться за дебаггингом к модели.
Ну так наверное будет целесообразно научить ллм мониторить работу сгенерированных скриптов и в случае обнаружения сбоя брать скрипт в ремонт и запускать обновленный скрипт. Так можно автоматизировать весь процесс и взять лучшее от обеих миров. В любом случае, каждый раз парсить однотипный контент через ллм экономически и технологически менее эффективно , чем запускать скрипт, сгенериррванный сеткой один раз в результате автоматического аеализа сируктуры текстового контента. А предложенное тут распознавание образов на скриншотах может быть приемлемо только для поистине уникального контента на каждой странице, но это сравнителтно редкое явление в сфере массового парсинга. Антиботы и капчи - основная боль, но нейронки публичные стесняются этим заниматься легально. 😂
Я занимаюсь сейчас проектом парсинга документации из pdf, реализовал проект, который разбивает документ на скрины и отправляет в мультимодальную llm, на выходе идеальный документ в markdown с таблицами. Может стоит парсить не код, а скрины контента? Кстати стоимость небольшая, используя qwen 2.5vl-70b 90 страниц стоят примерно 0.3$, плюс есть функционал перевода документа налету.
Вы выбрали какой-то странноватый пример. Спарсите лучше что-нибудь скажем с etsy. Ну там где несколько мегабайт каждый документ и сотни ошибок в нём.
Ну и как правило проблема не в том, чтобы из html получить ключи. Проблема как этот html получить. В товарном количестве, не отдает обычно никто...
Попробуйте, Reader api + url загрузить в любую модель в режиме чата и попросите вытащить интересующие вас элементы. С etsy пример товарной карточки: https://r.jina.ai/https://www.etsy.com/de-en/listing/1806680100/personalized-baby-basket-rope-cotton
При парсинге, по мне так, основная проблема сейчас - это обход защиты от скраббинга / капчи. Причем защиту совершенствуют. Парсер, который писался пару месяцев назад уже сейчас может не работать.
Тут какуй-нибудь нейросеть, которая будет ходить по сайту как пользователь в браузере с рендером всякого яваскрипта и тыкать капчи, если вылазят. А сайт бы просто в html сохраняло. Короче делала бы локальное отренденое html зеркало.
Потом html распарсить каким нибудь способом не проблема.
Посмотри в сторону сервиса Bright data, на Scraping Browser продукт. В целом очень крутой сервис и продукты замечательные.
Тут ещё Cloud flare анонсировал защиту от ботов ии для сайтов, которая при их распознавании начинает генерировать искусственный контент - интересно было бы посмотреть на такую битву ии-парсера и ии-защиты
Есть ещё apache tika кстати, отлично справляется со своей задачей, в комбинации с webdriver тоже вполне себе полёт нормальный. Парсинг html давно не проблема, я как-то нарыл около 50 открытых проектов в этой проблематике.. А вот обход всяких защит от роботов далеко не прост, на сколько знаю только puppeteer имеет встроенное платное решение для обхода капчей, и то далеко не всех мастей
Если нет необходимости в актуальной версии сайта и достаточно кешированной из поисковиков, то можно сервисы по типу perplexity использовать.
У OpenAI API не скоро появится поиск (а может вообще не появится) из-за сотрудничества с bing.
Ни в коем случае не делайте так, как предлагает автор. Аргументы "а что, если верстка поменяется, да причем сразу у всех сайтов, это ж править код надо!" некорректны по природе своей - во-первых да, код нужно поддерживать, это часть нормального жизненного цикла ПО, во-вторых код надо писать так, чтобы каждый участок кода выполнял ровно одну свою задачу и должен быть простой способ локализовать проблему (Логирование). Дальше - мало спарсить сайт, его нужно ещё положить в БД чаще всего, если изменится структура, то загрузка в БД сломается тоже. Код загрузки в БД тоже нейросеть будет на лету придумывать? Учтите, что нейросеть не работает детерминированно, вам может повезти с кодом на деве, он сработает, а на проде может появиться другой код, и вы замучаетесь на проде дебажить его.
Нейросеть - это способ ускорить разработку, в которой разработчик валидирует код от нейросети, включая прохождение тестовых кейсов, но никак не волшебная пилюля, особенно в задачах парсинга.
Спасибо за развёрнутый комментарий! Ваши аргументы про необходимость поддержки кода и детерминированность работы справедливы. Но я бы хотел внести ясность в несколько моментов. Во-первых, подход, предложенный в статье, вовсе не означает отказ от традиционного парсинга. Скорее, это дополнение, которое облегчает задачи, где изменения верстки происходят часто или непредсказуемо, а написание и поддержка десятков селекторов и регулярных выражений становится затруднительной. Да, код нужно поддерживать и грамотно структурировать, но бывают сценарии, где скорость разработки и гибкость важнее строгой стабильности.
Во-вторых, вы правильно отметили, что данные должны не только извлекаться, но и корректно ложиться в БД. Именно здесь задачу решает structured outputs. Я сделал дополнение про этот формат в статье. Прошу вас ознакомится с ним. Используя такой подход, модель не просто возвращает текст, а выдает данные строго по заданной схеме, что автоматически проверяется и валидируется. Вы можете строго задать модель данных, совместимую с вашей БД.
В-третьих, уже существуют коммерческие ai парсеры, например, browse ai, octoparse, scrapegraphai, которые успешно решают задачи парсинга с помощью нейросетей и гибридных подходов, применяя LLM. Такие сервисы популярны среди маркетологов, аналитиков. Они снижают порог входа, потому что позволяют людям без глубокого опыта в разработке быстро решать задачи по извлечению данных с веб-ресурсов.
В-четвертых, подход с использованием LLM активно применяется не только для непосредственного парсинга, но и для подготовки качественных датасетов, которые затем используются для дообучения и файнтюнинга тех же самых языковых моделей.
Пока что, на мой взгляд, это очень дорого за такого рода задачу. 20 товаров за 2 рубля. Цены на товары меняются иногда по нескольку раз в день. Товаров скорее всего не 20 и наверно даже не 1000. В общем, при похожим к боевым условиям эти 2 рубля превращаются в несколько десятков тысяч в день. Плюс скорость обработки запросов у llm очень низкая (по сравнению с закодированным паркингом) - такого рода парсинг будет занимать часы, если вообще не дни.
А что так можно было что ли 😱
Я хотел так сделать, но почему то подумал что это будет дорого ахахаза
Вот мое предложение для удешевления процесса:
Мы отправляем хтмл ,и просим нейронку сделать парсер.
Парсим страницу, тем парсером что написала нейросеть.
Если мы хотим обновить данные по "спаршеному" сайту, мы берём страницу, делаем снова парсер, сохраняем , и далее парсим уже новым парсером.
Плюсы:
Меньше запросов к неронки
Дешевле
Минусы
Нейросеть может изменить парсер по своему усмотрению, но это относится ко всем вариантам. Но тут уж просто нужно прогнать несколько раз и уточнить запрос ещё точнее
Парсинг с помощью LLM: зачем, как и сколько стоит?