Самовосстанавливающийся парсер: как LLM-агент чинит сбор данных и при чём здесь прокси
23 октября 2026
Самовосстанавливающийся парсер сам замечает, что сайт изменил вёрстку, вызывает LLM-агента, получает от него исправленный код извлечения данных и продолжает сбор без остановки. Прокси в такой схеме — один из параметров инфраструктуры, который агент может перенастроить, но только в пределах правил целевого сайта.
Коротко
- Идея: парсер хранит историю своего состояния, замечает отклонения и чинит код извлечения прямо во время обхода.
- Агенту нужны жёсткие рамки: изолированная среда, лимиты по времени и числу действий, журнал и откат.
- LLM вызывается только при поломке, поэтому основная статья расходов на сбор — по-прежнему трафик и прокси.
- Ограничение доступа со стороны сайта — сигнал снизить нагрузку и пересмотреть сценарий, а не повод искать обход.
Почему парсеры ломаются
Классический парсер — это набор правил: «цена лежит в элементе с таким-то классом», «следующая страница — по такой-то ссылке». Сайт меняет вёрстку, и правило перестаёт работать. Хуже всего, когда поломка тихая: парсер не падает, а просто отдаёт пустые поля или данные не из того блока.
Обычно дальше всё идёт по одному сценарию: мониторинг замечает провал, разработчик открывает страницу, правит селекторы, перезапускает обход. Если обход длинный, часть данных за это время теряется или устаревает.
На конференции Extract Summit руководитель исследований и разработки Zyte Константин Лопухин показал доклад «Паук, который переписывает сам себя». Это попытка убрать человека из этого цикла там, где поломка типовая.
Как работает самовосстанавливающийся парсер
Для демонстрации автор собрал прототип Scrapy Phoenix на базе фреймворка Scrapy и библиотеки web-poet. Ключевой приём — разделить код обхода (какие страницы открывать) и код извлечения (что забирать со страницы). Тогда агенту достаточно переписать небольшой объект страницы (page object), не трогая остальную логику.
- Парсер замечает отклонение.
Не найден нужный элемент, поле пришло пустым, доля заполненных полей резко упала по сравнению с прошлыми запусками. - Обход приостанавливается на проблемном типе страниц.
Остальные части сбора продолжают работать. - Агент получает контекст.
HTML страницы, ожидаемую схему данных, прошлые версии кода извлечения, журнал и статистику обхода. - Агент пишет новую версию объекта страницы.
Например, код для новой раскладки карточки товара. - Исправление проверяется тестами.
Старые сохранённые страницы должны разбираться как раньше, новая — корректно. - Код перезагружается на лету.
Парсер продолжает обход с того же места, без перезапуска всего процесса.
Имейте в виду. Scrapy Phoenix — исследовательский прототип из доклада, а не готовый продукт. Ценность здесь в подходе, который можно повторить на своём стеке.
Где агент ошибается
В докладе честно разобраны случаи, когда автоматическое исправление идёт не туда:
- Поле попадает не туда
Например, цвет товара оказывается в «дополнительных свойствах», а не в своём поле. Формально данные есть, по сути схема нарушена. - Неверно понята логика сайта
Агент может неправильно интерпретировать постраничную навигацию и пропустить или задвоить часть страниц. - Сайт сменил дизайн целиком
Переписать всё за один шаг сложно. Надёжнее чинить раскладки по одной. - Необязательные элементы
Если подкатегории есть только на части страниц, агенту трудно понять, поломка это или норма.
Отсюда главные приёмы: исправлять поэтапно, хранить историю прошлых состояний для сравнения и следить за статистикой, а не только за ошибками. Например, если доля товаров с ценой упала с почти всех до половины — это повод разбираться, даже если ничего не упало.
Какие ограничения нужны агенту
Агент, который меняет код в работающей системе, — это риск. Без рамок он может долго «чинить» не то, тратить ресурсы или сломать соседние части.
- Изолированная среда выполнения, без доступа к лишним системам.
- Никаких API-ключей и учётных данных в доступе агента сверх необходимого.
- Лимиты по времени работы и числу попыток исправления подряд.
- Журнал всех действий: запрос к модели, сгенерированный код, результаты тестов.
- Откат к предыдущей версии, если исправление не прошло проверку.
- Передача задачи человеку, если агент не справился за отведённые попытки.
Не менее важна наблюдаемость. Агент чинит то, что видит, поэтому ему нужен доступ к журналам, статистике и текущему состоянию обхода — в машиночитаемом виде.
Причём здесь прокси
В основной части доклада прокси почти не упоминаются. Тема всплывает в ответах на вопросы: по словам докладчика, иногда проблему решает другая конфигурация прокси, а иногда — изменение логики обхода. То есть прокси — один из параметров, которые агент учитывает наравне с темпом запросов и порядком навигации.
Важно. Если сайт начал ограничивать доступ (ошибки 403, 429, CAPTCHA), правильная реакция агента — снизить нагрузку, увеличить паузы и проверить, допускают ли правила ресурса такой сбор. Смена прокси не должна использоваться для превышения ограничений, установленных сайтом для пользователя, аккаунта или задачи.
Подробнее о том, почему сайты ограничивают доступ, — в статье «Почему сайт ограничивает доступ», а о правовой стороне сбора данных — в материале «Легальность парсинга».
Для самовосстанавливающейся схемы от прокси-инфраструктуры важно другое:
- Управляемость из кода. Агенту и вашему коду удобнее, когда тип прокси, регион и режим ротации задаются параметрами подключения, а не ручными действиями в личном кабинете.
- Понятные ошибки. Отличить сбой прокси от изменения вёрстки — первая задача агента. Ошибка подключения и пустой блок на странице чинятся по-разному.
- Стабильность. Чем реже сбоит транспорт, тем реже агент тратит попытки на проблемы, которые не связаны с кодом извлечения.
Чтобы транспортные сбои не маскировались под поломку парсера, стоит заранее настроить таймауты и повторы — см. «Таймауты и повторные запросы при работе через прокси».
Сколько это стоит
Точной цены за запрос нет: всё зависит от сайта, частоты изменений вёрстки и выбранной модели. Но структура затрат понятна.
| Статья затрат | Когда возникает | От чего зависит |
|---|---|---|
| Вызовы LLM | Только при поломке | Частота изменений вёрстки, размер HTML, модель |
| Прокси и трафик | На каждой странице | Объём страниц, тип прокси, вес страницы |
| Серверы и хранение | Постоянно | Масштаб обхода, объём журналов и истории |
Агент вызывается, когда сайт изменился, а не на каждый запрос. Поэтому в пересчёте на тысячи страниц расходы на модель обычно заметно меньше расходов на трафик. Как посчитать трафик, разобрано в статье «Сколько трафика нужно для парсинга через прокси».
Главная экономия — в простоях. Если раньше поломка ждала разработчика несколько часов, а теперь типовой случай закрывается автоматически, данные приходят без провалов.
Как это устроено у нас
Proxy.Market отвечает за транспортный слой: через какие адреса парсер обращается к сайтам. Код извлечения и агент остаются на вашей стороне. Тип прокси подбирается под задачу:
- Серверные прокси IPv4 — для сайтов без жёстких ограничений и больших объёмов с оплатой за IP.
- ISP-прокси — когда нужны стабильные адреса с выходом через интернет-провайдера.
- Резидентные прокси — когда нужны адреса из пула домашних подключений и ротация.
- Мобильные прокси — для сценариев, где важны адреса мобильных операторов.
Если не уверены, какой тип подойдёт под ваш сценарий сбора, подберёт менеджер.
Частые вопросы
Что такое самовосстанавливающийся парсер?
Это парсер, который сам замечает изменения на сайте, вызывает LLM-агента для исправления кода извлечения и продолжает сбор без перезапуска и без участия разработчика.
Можно ли полностью убрать разработчика?
Нет. Агент закрывает типовые поломки, а сложные случаи — смену дизайна целиком, неочевидную логику сайта — всё равно стоит передавать человеку.
Дорого ли использовать LLM в парсинге?
Обычно нет: модель вызывается только при поломке, поэтому основные расходы остаются на трафике, прокси и серверах.
Должен ли агент сам менять прокси?
Агент может менять параметры подключения, например регион или тип прокси, если этого требует задача и правила сайта. Использовать смену адресов, чтобы превысить ограничения ресурса, нельзя.
Подберём прокси под ваш сбор данных
Расскажите, какие сайты и в каком объёме вы обрабатываете, — менеджер предложит подходящий тип прокси и тариф.
