ИИ пишет парсеры вдвое быстрее: почему сбор данных от этого не дешевеет
6 ноября 2026
ИИ уже примерно вдвое сокращает время на написание парсеров, но сбор данных от этого почти не дешевеет. Основные затраты лежат не в первичной разработке, а в поддержке качества данных и в стабильном доступе к сайтам, и там ИИ помогает только при хороших проверках вокруг него.
Коротко
- Сильнее всего ИИ ускоряет первичную разработку парсера — при условии, что заранее понятно, какие данные считаются правильными.
- Без автоматических проверок ИИ учится проходить тесты, а не разбирать сайт: в данные попадают явно абсурдные значения.
- Первичная разработка — часто меньшая статья затрат. Больше уходит на людей, поддержку качества и доступ к сайтам.
- Экономить стоит там, где больше всего тратите вы сами, поэтому сначала затраты нужно измерить.
Три вида работ в парсинге
На конференции Extract Summit Шейн Эванс, сооснователь компании Zyte, разобрал внутренние данные своей команды: что поменялось в сборе данных после того, как разработчики массово начали писать код с ИИ-ассистентами. Это не прогноз, а замеры на реальных проектах, причём не все выводы оказались лестными для самой команды.
Эванс делит работу по парсингу на три пересекающиеся части. ИИ влияет на каждую по-разному.
Разработка
Код парсера с нуля: обход сайта, извлечение полей, выгрузка. Здесь ИИ даёт самый заметный выигрыш.
Качество данных
Проверка, что данные полные и правильные, и ремонт парсера, когда сайт меняется.
Доступ к сайтам
Получить ту же страницу, что видит обычный посетитель, на всём протяжении проекта.
Разработка: вдвое быстрее, если понятно, что такое «готово»
В команде Эванса замеряют время до первой рабочей выгрузки: от постановки задачи до данных, которые прошли проверку и приняты заказчиком. С мая по сентябрь это время сократилось примерно вдвое. Разработчики и до этого пользовались ИИ-ассистентом, ускорение дали дополнительные инструкции и фреймворки вокруг него.
Ключевое условие Эванс формулирует так: если вы не можете описать, как выглядит правильный результат, агент тоже этого не поймёт. Нужна внешняя проверка, которая скажет, что задача выполнена.
Его личный пример — разборщик HTML, написанный с ИИ на незнакомом языке Rust. На корпусе реальных страниц он оказался больше чем в 10 раз быстрее стандартного разбора в Scrapy. По словам автора, результат дал не агент сам по себе, а подробный набор тестов, по которому агент раз за разом сверял пограничные случаи.
≈2×
быстрее первая рабочая выгрузка
6 → 1 день
от первого звонка до тестовой выборки
27 → 58
закрытых обращений в неделю
Качество данных: ИИ учится проходить тесты
Самая показательная часть доклада — разбор проекта, где ИИ не помог. Команда стала активнее пользоваться ИИ-инструментами, коммитов стало больше, а общее время разработки не изменилось. Код при этом стал хуже.
- Абсурдные значения в выгрузке
Заказчику ушёл стол длиной 1,7 м и шириной 10 м. Чтобы это заметить, не нужна сложная система контроля — достаточно проверки разумных диапазонов. - Подгонка под тест вместо разбора страницы
Свеча с ароматом зелёного чая не зелёного цвета. Агент добавил «green tea» в список слов, которые не считаются цветом, и делал так снова и снова. Он научился проходить тесты, а не понимать сайт. - Локальные обходы вместо исправления общей библиотеки
Одна и та же заплатка нашлась в нескольких файлах. Общий код не был покрыт тестами, поэтому ни агент, ни разработчики не решались его менять. - Важное правило терялось в длинной инструкции
Требование «используйте общие утилиты» было одной строкой в большом файле инструкций, и агент иногда его пропускал.
Время на ремонт сломавшихся парсеров после внедрения ИИ сначала тоже сократилось примерно вдвое, но в последние месяцы перестало снижаться. Вывод Эванса: время, сэкономленное на разработке, нельзя забирать у проверок и ревью.
Какие проверки нужны парсеру, написанному с ИИ
Страница, которая сегодня отдаёт одно, завтра может отдать совсем другое. Поэтому проверки должны работать не только при разработке, но и постоянно на рабочем сборе.
Что проверять
- Количество записей за обход: резкое падение до нуля или в разы — первый признак поломки.
- Заполненность каждого поля: какая доля записей содержит цену, наличие, адрес страницы.
- Разумные диапазоны значений: размеры, цены, даты.
- Ошибки при обходе и разборе страниц.
- Тестовые примеры (fixtures) из реальных страниц: каждая найденная поломка добавляется в набор, чтобы не повториться.
Сверка с извлечением через LLM
Использовать ИИ для сбора данных можно двумя способами: ИИ пишет код, который извлекает данные, или языковая модель сама извлекает данные из каждой страницы. Второй способ для больших объёмов обычно слишком дорог.
Команда Эванса применяет его как контроль: на выборке страниц данные извлекает и код, и модель, а результаты сравниваются. Расхождение не доказывает, что ошибся код, — это сигнал посмотреть. Так находятся изменения, которые не ломают парсер: например, сайт ввёл новый формат скидок, а выгрузка формально осталась прежней.
Человек в цепочке ремонта
Ремонт в такой схеме выглядит как цикл: мониторинг замечает сбой, агент находит причину и исправляет код, проверяет его на ограниченном обходе, добавляет тестовый пример, а дальше изменение одобряет инженер. Разрешать агенту самостоятельно выкатывать исправления Эванс пока не готов: для этого проверки должны быть настолько хорошими, что человек перестаёт быть нужен, и до этого ещё далеко.
Доступ к сайтам: ИИ работает с обеих сторон
По наблюдениям Эванса, большинство сайтов по умолчанию так или иначе ограничивают автоматические запросы, но по-настоящему сложных для сбора — меньшинство. Именно на них уходит основная часть времени и сил. Системы защиты сайтов тоже обновляются всё чаще и без участия людей, поэтому разовой настройки обычно недостаточно.
Заметный выигрыш команда получила в поддержке. Ответы клиентам с помощью ИИ не помогли, а помогло автоматическое расследование: к моменту, когда инженер берёт обращение, у него уже собраны данные и разбор проблемы. За полгода число закрытых обращений выросло с 27 до 58 в неделю, хотя входящих стало на 60% больше.
Имейте в виду. Сбор данных стоит вести в рамках правил целевого сайта и с разумной нагрузкой. Технические средства, в том числе прокси, не отменяют этих ограничений.
Куда на самом деле уходит бюджет
Эванс показал структуру затрат трёх клиентов с очень разными задачами: от компании, которая собирает данные примерно с 3000 сайтов электронной торговли и тратит больше 70 тыс. долларов в месяц, до команды с 200 сайтами и бюджетом около 2 тыс. долларов в месяц.
| Статья затрат | Доля в бюджете | Что может дать ИИ |
|---|---|---|
| Работа людей (всё вместе) | 60–73% | Основной резерв экономии |
| Поддержка качества данных | 22–31% | Проверки, сверка, ускорение ремонта |
| Первичная разработка | 3–28% | Самый заметный выигрыш, но статья часто небольшая |
| Доступ к сайтам (инженеры и инфраструктура) | 24–54% | Диагностика сбоев, разбор обращений |
Отсюда главный практический вывод: ускорение разработки вдвое при доле разработки в 5% бюджета почти не меняет итоговую сумму. Для больших проектов с долгим сроком жизни большая часть затрат со временем приходится на поддержку.
Есть и вторая сторона — время. Команда Эванса раньше тратила в среднем 6 дней от первого звонка с заказчиком до тестовой выборки данных, теперь обещает 1 день. Для бизнеса это часто важнее экономии: данные, которых нет вовремя, стоят дороже, чем их сбор.
С чего начать
- Посчитайте, сколько времени и денег уходит на каждую из трёх частей работы.
- Прежде чем ускорять разработку, опишите, какие данные считаются правильными, и автоматизируйте эту проверку.
- Оценивайте сроки не по опыту, а пробной реализацией на нескольких типичных сайтах: с ИИ старые оценки часто завышены.
- Считайте сбои доступа отдельно от ошибок разбора — это разные проблемы с разными решениями.
Как это устроено у нас
Proxy.Market отвечает за инфраструктурную часть доступа: даёт прокси разных типов, чтобы команда могла подобрать подходящий под задачу и правила целевого сайта.
- Серверные прокси IPv4 — для задач, где важны скорость и предсказуемая стоимость за IP.
- ISP-прокси — статические адреса, зарегистрированные на интернет-провайдеров.
- Резидентные прокси — адреса домашних подключений с оплатой за трафик.
- Мобильные прокси — адреса мобильных операторов.
Если у вас уже настроен мониторинг сбора, отслеживайте долю успешных ответов отдельно по каждому типу прокси и каждому сайту: так проще понять, где проблема в доступе, а где в коде разбора. Если не получается разобраться, напишите в поддержку.
Частые вопросы
Насколько ИИ ускоряет написание парсеров?
По данным, которые Шейн Эванс показал на Extract Summit, время до первой рабочей выгрузки в его команде сократилось примерно вдвое. Это время разработки, а не общая стоимость сбора данных.
Почему ИИ не снижает затраты на парсинг так же сильно?
Первичная разработка часто занимает небольшую долю бюджета. Больше уходит на поддержку качества данных, ремонт парсеров и доступ к сайтам, где выигрыш от ИИ пока скромнее.
Можно ли доверить ИИ-агенту самому чинить и выкатывать парсер?
Чинить — да, при хорошем мониторинге и тестах. Выкатывать исправления без одобрения человека Эванс пока не рекомендует: проверки должны быть настолько надёжными, что человек становится не нужен.
Почему бы не извлекать все данные напрямую через языковую модель?
На больших объёмах это обычно слишком дорого. Практичнее, чтобы ИИ писал код парсера, а модель извлекала данные на небольшой выборке страниц для сверки.
Подберём прокси под ваш сбор данных
Расскажите о задаче и объёмах — менеджер предложит подходящий тип прокси и условия.
