Да, это долго для какого-нибудь продакшн решения. А здесь представлен простейший код с последовательными запросами. Чтобы работать быстро, нужно использовать асинхронные запросы и прокси.
Это к вопросу про НЕ блокировку ютуба в России. Одним из аргументов когда-то был такой: ютуб гнет свою политическую повестку и массово влияет на мнение граждан из рф. По графикам видно, какую долю занимает политика в интересах этих граждан на ютубе .
Спасибо за развёрнутый комментарий! Ваши аргументы про необходимость поддержки кода и детерминированность работы справедливы. Но я бы хотел внести ясность в несколько моментов. Во-первых, подход, предложенный в статье, вовсе не означает отказ от традиционного парсинга. Скорее, это дополнение, которое облегчает задачи, где изменения верстки происходят часто или непредсказуемо, а написание и поддержка десятков селекторов и регулярных выражений становится затруднительной. Да, код нужно поддерживать и грамотно структурировать, но бывают сценарии, где скорость разработки и гибкость важнее строгой стабильности.
Во-вторых, вы правильно отметили, что данные должны не только извлекаться, но и корректно ложиться в БД. Именно здесь задачу решает structured outputs. Я сделал дополнение про этот формат в статье. Прошу вас ознакомится с ним. Используя такой подход, модель не просто возвращает текст, а выдает данные строго по заданной схеме, что автоматически проверяется и валидируется. Вы можете строго задать модель данных, совместимую с вашей БД.
В-третьих, уже существуют коммерческие ai парсеры, например, browse ai, octoparse, scrapegraphai, которые успешно решают задачи парсинга с помощью нейросетей и гибридных подходов, применяя LLM. Такие сервисы популярны среди маркетологов, аналитиков. Они снижают порог входа, потому что позволяют людям без глубокого опыта в разработке быстро решать задачи по извлечению данных с веб-ресурсов.
В-четвертых, подход с использованием LLM активно применяется не только для непосредственного парсинга, но и для подготовки качественных датасетов, которые затем используются для дообучения и файнтюнинга тех же самых языковых моделей.
Ну конечно, вы можете сгенерировать код парсера с помощью любой нейросети. Если у вас действительно есть такая проблема, как изменчивость верстки, то в данном случае вам нужно будет постоянно мониторить изменения верстки и обращаться за дебаггингом к модели.
Это интересная идея. В этом случае нужно подключать какой-то инструмент, который будет эти скрины делать. Нужно тестировать, считать затраты и смотреть на точность распознавания.
"Ломаются парсеры при смене кода верстки" - имеется ввиду, что они, пытаясь вытащить элемент которого уже нет (изменился) отдают некорректные данные. Сам код парсера никак не меняется при этом. Но я не уверен, что точно понял ваш вопрос. Можете пример привести?
structured outputs, безусловно, более продвинутый, но требует подключения дополнительных библиотек, типа pydantic и написания дополнительного кода. Мне показалось, что это будет перегружать статью для тех, кто только осваивается в теме. Потом, structured outputs поддерживается не всеми моделями gpt, например для gpt-3.5 он не поддерживается. Спасибо за дополнение, возможно действительно стоит упомянуть про такой формат в статье.
Спасибо. На самом деле в статье я привел старые данные по ценам. Сейчас стоимость gpt-4o в 2 раза меньше. Нужно будет поправить. Целью было показать возможности такого метода.
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Да, это долго для какого-нибудь продакшн решения. А здесь представлен простейший код с последовательными запросами. Чтобы работать быстро, нужно использовать асинхронные запросы и прокси.
Это к вопросу про НЕ блокировку ютуба в России. Одним из аргументов когда-то был такой: ютуб гнет свою политическую повестку и массово влияет на мнение граждан из рф. По графикам видно, какую долю занимает политика в интересах этих граждан на ютубе .
Спасибо за развёрнутый комментарий! Ваши аргументы про необходимость поддержки кода и детерминированность работы справедливы. Но я бы хотел внести ясность в несколько моментов. Во-первых, подход, предложенный в статье, вовсе не означает отказ от традиционного парсинга. Скорее, это дополнение, которое облегчает задачи, где изменения верстки происходят часто или непредсказуемо, а написание и поддержка десятков селекторов и регулярных выражений становится затруднительной. Да, код нужно поддерживать и грамотно структурировать, но бывают сценарии, где скорость разработки и гибкость важнее строгой стабильности.
Во-вторых, вы правильно отметили, что данные должны не только извлекаться, но и корректно ложиться в БД. Именно здесь задачу решает structured outputs. Я сделал дополнение про этот формат в статье. Прошу вас ознакомится с ним. Используя такой подход, модель не просто возвращает текст, а выдает данные строго по заданной схеме, что автоматически проверяется и валидируется. Вы можете строго задать модель данных, совместимую с вашей БД.
В-третьих, уже существуют коммерческие ai парсеры, например, browse ai, octoparse, scrapegraphai, которые успешно решают задачи парсинга с помощью нейросетей и гибридных подходов, применяя LLM. Такие сервисы популярны среди маркетологов, аналитиков. Они снижают порог входа, потому что позволяют людям без глубокого опыта в разработке быстро решать задачи по извлечению данных с веб-ресурсов.
В-четвертых, подход с использованием LLM активно применяется не только для непосредственного парсинга, но и для подготовки качественных датасетов, которые затем используются для дообучения и файнтюнинга тех же самых языковых моделей.
Почитайте на сайте jina.ai. Там вроде до 1 млн. они предлагают бесплатно.
Попробуйте, Reader api + url загрузить в любую модель в режиме чата и попросите вытащить интересующие вас элементы. С etsy пример товарной карточки: https://r.jina.ai/https://www.etsy.com/de-en/listing/1806680100/personalized-baby-basket-rope-cotton
Ну конечно, вы можете сгенерировать код парсера с помощью любой нейросети. Если у вас действительно есть такая проблема, как изменчивость верстки, то в данном случае вам нужно будет постоянно мониторить изменения верстки и обращаться за дебаггингом к модели.
Это интересная идея. В этом случае нужно подключать какой-то инструмент, который будет эти скрины делать. Нужно тестировать, считать затраты и смотреть на точность распознавания.
"Ломаются парсеры при смене кода верстки" - имеется ввиду, что они, пытаясь вытащить элемент которого уже нет (изменился) отдают некорректные данные. Сам код парсера никак не меняется при этом. Но я не уверен, что точно понял ваш вопрос. Можете пример привести?
structured outputs, безусловно, более продвинутый, но требует подключения дополнительных библиотек, типа pydantic и написания дополнительного кода. Мне показалось, что это будет перегружать статью для тех, кто только осваивается в теме. Потом, structured outputs поддерживается не всеми моделями gpt, например для gpt-3.5 он не поддерживается. Спасибо за дополнение, возможно действительно стоит упомянуть про такой формат в статье.
Спасибо. На самом деле в статье я привел старые данные по ценам. Сейчас стоимость gpt-4o в 2 раза меньше. Нужно будет поправить. Целью было показать возможности такого метода.