Умный парсинг сайтов - это когда я не пишу отдельный набор CSS-селекторов под каждую вёрстку, а отдаю нейросети кусок HTML или очищенный текст страницы и прошу вернуть JSON по заданной схеме: название товара, цена, наличие, характеристики. За последний год я перевёл на такую схему несколько проектов по мониторингу цен и сбору каталогов, и разница с классическим парсером на селекторах видна сразу: сайт меняет дизайн, а промпт продолжает работать без правок.
Почему классические парсеры ломаются после каждого редизайна
Обычный парсер на BeautifulSoup или Scrapy держится на разметке страницы. Есть цепочка селекторов вида div.product-card span.price, и пока вёрстка не меняется, всё работает стабильно. Но стоит владельцу сайта обновить дизайн, поменять фреймворк на фронте или просто переставить классы при рефакторинге CSS, парсер начинает возвращать пустые поля или мусор. На моей практике правка одного упавшего парсера под новую вёрстку конкурента занимает от 2 до 6 часов: нужно открыть DevTools, найти новые селекторы, протестировать на десятке страниц, учесть исключения для карточек без скидки или без отзывов.
Если источников десять и они меняются раз в квартал, с этим можно жить. Если источников тридцать, а часть из них - маркетплейсы с частыми обновлениями фронта, поддержка парсеров на селекторах превращается в отдельную статью расходов, которая не видна на старте проекта, но съедает бюджет через полгода эксплуатации.
Как работает интеллектуальный парсинг данных на нейросетях
Схема простая: страница загружается как обычно (через requests для статики или через Playwright, если контент рендерится через JavaScript), из HTML убирают скрипты, стили и навигационный мусор, оставшийся текст или упрощённую разметку отправляют в языковую модель вместе со схемой данных, которую нужно получить. Модель не ищет заданный селектор, она понимает контекст: «вот блок с ценой, зачёркнутая цена рядом - это старая цена, а не текущая» или «в этой таблице характеристик вес указан в граммах, а не в килограммах, привести к одной единице».
На выходе получаю строго структурированный JSON, который проверяю через Pydantic-схему: если модель вернула цену строкой вместо числа или пропустила обязательное поле, запись уходит в лог для ручной проверки, а не портит базу молча. Это ключевое отличие от классического парсинга: там ошибка чаще всего означает пустое поле, а с LLM модель может «дофантазировать» значение, если не ограничить её жёсткой схемой и температурой генерации, близкой к нулю.
Пример запроса на извлечение данных
Вот упрощённый пример вызова Claude API с описанием нужной схемы через tool use, без реального проекта, просто чтобы показать принцип:
import anthropic
client = anthropic.Anthropic()
tool = {
"name": "extract_product",
"description": "Извлечь карточку товара со страницы",
"input_schema": {
"type": "object",
"properties": {
"title": {"type": "string"},
"price": {"type": "number"},
"in_stock": {"type": "boolean"}
},
"required": ["title", "price", "in_stock"]
}
}
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
tools=[tool],
tool_choice={"type": "tool", "name": "extract_product"},
messages=[{"role": "user", "content": page_text}]
)
Модель обязана вернуть данные строго в этом формате, и дальше это уже обычная работа с JSON, без regex и хрупких XPath-выражений.
Инструменты для нейросетевого парсинга сайтов
Набор, который использую чаще всего:
- Playwright - для сайтов с рендерингом на JavaScript, когда данные подгружаются после загрузки страницы
- readability или собственная функция очистки HTML - чтобы не тратить токены на меню, футер и скрипты аналитики
- Claude API со структурированным выводом через tool use - для самого извлечения
- Pydantic - для валидации того, что вернула модель, перед записью в базу
- очередь задач (Celery или простой n8n-воркфлоу) - для регулярного запуска и ретраев при сбоях сети
Отдельно стоит логика повторных запросов: если страница не открылась с первого раза или модель вернула невалидный JSON, скрипт делает вторую попытку с задержкой, а не падает целиком. На объёме в несколько тысяч страниц в сутки без этого не обойтись, сеть и сайты-источники периодически отдают таймауты.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Сколько стоит умный парсинг сайтов: токены против часов разработки
Классический парсер дешевле в расчёте на одну обработанную страницу, но дороже в поддержке. ИИ-парсинг наоборот: настройка занимает меньше времени, а каждая обработанная страница стоит денег за токены.
| Критерий | Парсер на CSS-селекторах | Парсинг через LLM |
|---|---|---|
| Настройка под новый источник | 3-8 часов | 30-90 минут |
| Реакция на редизайн сайта | ломается, нужна ручная правка | обычно продолжает работать без изменений |
| Точность на нестандартной вёрстке | зависит от жёсткости селектора | выше за счёт понимания контекста |
| Стоимость обработки одной страницы | близка к нулю (свои серверные мощности) | от долей рубля до нескольких рублей, зависит от объёма текста |
На практике оптимальная схема гибридная: классический код грузит страницу и вырезает лишнее, а нейросеть достаёт из очищенного текста только структурированные поля. Это снижает расход токенов в разы по сравнению с отправкой сырого HTML целиком.
Если считать в деньгах, разработка парсера на Python у меня начинается от 20 000 ₽ - сюда входит логика загрузки страниц, схема данных и базовая обработка ошибок. Если нужна регулярная переработка данных с уведомлениями и связкой с внешними сервисами, автоматизация в n8n добавляется отдельно и стоит от 25 000 ₽. Полноценная AI-интеграция с Claude API, включая проектирование схемы извлечения и обработку невалидных ответов модели, оценивается от 50 000 ₽. На бирже фриланса подобные проекты часто оценивают в диапазоне 15 000-70 000 ₽, но там редко закладывают в исходную оценку ретраи, логирование ошибок валидации и ротацию IP при большом объёме запросов, поэтому итоговая стоимость нередко вырастает уже в процессе работы.
Практические кейсы: мониторинг цен, объявления и синхронизация каталога
Мониторинг цен конкурентов - самый частый запрос. Скрипт раз в сутки обходит карточки товаров, извлекает цену, наличие и иногда стоимость доставки (у части интернет-магазинов она считается динамически через виджет СДЭК прямо на странице товара), сравнивает с предыдущим значением и при отклонении больше заданного порога отправляет уведомление в Telegram через бота на aiogram. Это удобнее email-рассылки: сообщение приходит сразу в рабочий чат, без задержки на проверку почты.
Сбор объявлений с досок и агрегаторов - вторая частая задача, где вёрстка карточек внутри одного сайта может отличаться между разделами. Классический парсер здесь пришлось бы дробить на несколько наборов селекторов под каждый тип карточки, а модель с одной и той же схемой корректно разбирает и объявления с фото, и без него, и с указанной ценой торга.
Третий сценарий - синхронизация каталога поставщика с интернет-магазином на WooCommerce: поставщик присылает данные в виде страниц без API, скрипт раз в день извлекает структурированные карточки и обновляет товары через WooCommerce REST API, включая остатки и цены. Такие связки с регулярным запуском и интеграцией в существующий магазин обычно оформляю как часть услуг по автоматизации бизнес-процессов, потому что это не разовый скрипт, а работающий процесс с мониторингом ошибок.
Ограничения умного парсинга: блокировки и работа с данными
Нейросеть решает проблему хрупкой вёрстки, но не отменяет остальные ограничения парсинга. Сайты по-прежнему могут ограничивать частоту запросов, поэтому я закладываю паузы между обращениями и соблюдаю robots.txt там, где это применимо к задаче. При больших объёмах использую ротацию IP через прокси-пул и рандомизацию отпечатка браузера в Playwright, чтобы снизить вероятность ложных блокировок при легитимном сборе открытых данных, а не для доступа к закрытым разделам сайтов.
По стоимости токенов имеет смысл кешировать уже обработанные страницы и пересчитывать только те карточки, которые реально изменились с прошлого обхода - сравнение по хэшу содержимого страницы экономит заметную часть бюджета на больших каталогах.
Если в собираемых данных попадаются персональные данные людей, например контакты в объявлениях, храню их на серверах в России и не выгружаю в зарубежные облачные таблицы или базы, это требование 152-ФЗ, а не моя личная перестраховка.
Частые вопросы
Сколько стоит умный парсинг сайта под конкретную задачу?
Базовая разработка парсера на Python у меня начинается от 20 000 ₽. Итоговая цена зависит от числа источников, сложности схемы данных и того, нужна ли регулярная автоматизация запуска через n8n или отдельный сервер с расписанием.
Чем ИИ-парсинг лучше обычного скрапинга с селекторами?
Он не привязан к конкретной вёрстке страницы и продолжает работать после редизайна сайта-источника без правок кода. Минус в обратную сторону - за обработку каждой страницы платите токенами, поэтому на очень больших объёмах гибридная схема (классический парсер плюс LLM только для сложных полей) обычно выгоднее.
Можно ли парсить сайты с JavaScript-рендерингом?
Да, для этого использую Playwright, который дожидается полной отрисовки страницы перед тем, как передать содержимое дальше на извлечение. Для сайтов с ограничением частоты запросов добавляю паузы между обращениями и ротацию IP, чтобы собирать открытые данные без лишних блокировок.
Нужно ли переписывать промпт при каждом обновлении сайта?
Практически нет. Промпт и схема данных завязаны на смысл контента (что такое цена, что такое наличие), а не на теги и классы, поэтому обновление затрагивает только случаи, когда источник меняет саму структуру данных, например добавляет новый тип скидки или переходит на другую валюту.