Локальная LLM собрала объявления через DOM и остановилась после шестого запроса

Обычный парсер сайта объявлений часто ломается ещё до первой полезной строки: сервер отвечает 403, ограничивает частоту запросов или отдаёт страницу, которую собирает JavaScript. Автор эксперимента попробовал другой путь — поручил локальной Qwen класса 7B/8B работать с сайтом через обычный браузер и извлекать данные не по хрупким CSS-классам, а по смысловым признакам.

На простом примере задача выглядела так: найти редкую мобильную рабочую станцию с определённой видеокартой, собрать название, цену, город и ссылку на продавца. Агент открывал выдачу в Edge под управлением Playwright, просматривал DOM и искал знакомые опорные точки: знак валюты, крупный соседний текст и идентификатор объявления в ссылке. Если сведения о продавце находились в другом участке страницы, записи связывались по Item ID.

Почему DOM оказался полезнее CSS

Современный интерфейс может менять имена классов после каждого обновления. Селектор, который работал вчера, завтра возвращает пустой список. Текстовые признаки устойчивее: цена всё ещё содержит обозначение валюты, карточка ведёт на уникальный адрес, а название остаётся рядом с ценой в структуре страницы.

Агент использовал эти признаки как ориентиры. Сначала находил узел с ценой, затем поднимался к контейнеру карточки, извлекал заголовок и ссылку, после чего сопоставлял дополнительные поля по идентификатору. Такой подход напоминает работу человека: мы тоже не знаем имя CSS-класса кнопки, но понимаем её назначение по тексту и положению.

Есть и более интересный результат. В одном объявлении заголовок обещал старшую видеокарту, а описание указывало младшую модель с 16 ГБ памяти. Агент заметил расхождение и пометил карточку для ручной проверки. Для продуктовой команды это важнее красивой демонстрации автономности: модель не просто переносила строки, а проверяла согласованность данных внутри объявления.

Где эксперимент упёрся в реальность

На шестом обращении площадка вернула ошибку 429 — слишком много запросов. Агент прекратил новые обращения и сформировал отчёт из уже сохранённых данных. Это разумное поведение, однако оно одновременно разрушает громкий тезис о «победе» над антифродом. Запуск обычного браузера не делает систему неуязвимой: площадка по-прежнему видит частоту действий и может ограничить доступ.

Заявленная автором стопроцентная точность сопоставления также не подтверждена независимым тестом. Неизвестны размер выборки, число пропущенных карточек и доля ошибок на других страницах. В эксперименте были интерактивная отладка и ручное наблюдение, поэтому называть систему полностью автономной рано.

Есть и правовая граница. Техническая возможность прочитать страницу не означает разрешения на массовый сбор данных. Перед запуском нужно проверить условия площадки, robots.txt, допустимую нагрузку и правила обработки персональных данных. Механизмы защиты нельзя считать досадной помехой, которую следует скрытно обходить.

Что взять разработчику

Ценность работы — не в рецепте обхода блокировок, а в архитектурном приёме. Для разрешённых сценариев браузерный агент может сочетать три уровня: визуальную проверку скриншота, разбор DOM по смысловым маркерам и локальный буфер, позволяющий корректно завершить работу после ошибки.

В продакшене к этому нужны жёсткие лимиты частоты, повторные попытки с увеличивающейся задержкой, журнал действий, проверка полноты выборки и ручное подтверждение спорных результатов. Начинать стоит на собственном сайте или в тестовой среде, где есть явное разрешение на автоматизацию.

Практический вывод простой: небольшая локальная LLM уже способна управлять браузером и собирать структурированные данные с динамической страницы. Но хороший агент определяется не умением любой ценой пройти защиту, а способностью соблюдать ограничения, замечать противоречия и безопасно останавливаться, когда сайт говорит «достаточно».