Три часа ночи. Сижу перед экраном, листаю прайсы пяти магазинов электроники. Завтра руководство хочет отчёт — где мы дороже, где дешевле, на сколько. Ручками переносить данные в таблицу — два часа. И так каждую неделю.
На четвёртой неделе я психанул и написал скрипт.
Ничего особенного — парсер на Requests, bs4, раз в сутки собирает цены, складывает в CSV. Работало. Но через месяц сайты меняли разметку, скрипт падал, я чинил его в шесть утра и тихо ненавидел.
А потом мне надоело чинить. И я построил агент, который чинит сам себя.
Архитектура простого агента: четыре кирпича
Не буду грузить терминологией. Мой агент делает три вещи: собирает данные, понимает, что изменилось, и говорит мне куда смотреть.
Сборщик — здесь всё просто. Requests плюс BeautifulSoup для большинства сайтов. Если конкурент использует React или динамическую загрузку — Playwright, без вариантов. Главная боль: сайты ломают парсинг при каждом обновлении. Я потерял два дня на отладку, когда один магазин перешёл на новую CDN и все мои CSS-селекторы поехали.
Нормализатор — приводит данные к одному формату. Цены у конкурентов могут быть в формате «12 990 ₽», «12.990р.», «12 990 р.», «₽12 990». Нормализатор превращает всё в число. Звучит тривиально, но это первый слой, где всё ломается, если не продумать заранее.
Хранилище — SQLite для начала хватает. История цен, метки времени, статус доступности товара. Если товар пропал с сайта — это тоже важный сигнал.
Анализатор — вот тут начинается ИИ. Не в смысле какой-то магии, а просто код, который смотрит на историю и говорит: «Вчера было 15 000, сегодня 13 500 — уронили на 10%. Может, реагируем?».
Где LLM реально нужен
Долго думал, куда пристроить языковую модель. Первая мысль — пусть сама пишет отчёты. Попробовал. Плохо. Модель врёт с цифрами, даже если данные правильные. Галлюцинирует проценты, путает товары между собой.
Сейчас я использую LLM в двух местах.
Первое — резюмирование. Каждое утро агент отправляет мне не таблицу на 200 позиций, а три-четыре тезиса: «У конкурента X три товара подешевели более чем на 5%. Товар Y пропал из наличия. Ваша наценка на позицию Z выросла до 18% — рекомендую проверить».
Второе — классификация. Иногда конкуренты проводят акции с непонятными условиями вроде «цена по промокоду при первой покупке старым клиентам, которые купили в прошлом году». LLM помогает понять, можно ли эту цену считать регулярной.
Проблема, которую я не предвидел
Сайты меняют разметку — это понятно. Но хуже другое: они меняют структуру данных. Один магазин сначала держал цены в JSON-блоке, потом перенёс их в GraphQL endpoint, потом вообще отдал через Cloudflare, которая требовала JavaScript.
Мой первый скрипт умер три раза за месяц. Я чинил, снова чинил, и в какой-то момент понял, что трачу на поддержку больше времени, чем экономит мне скрипт.
Решение: добавить уровень абстракции между сборщиком и анализатором. Сборщик теперь отдаёт данные в универсальном формате, а что происходит внутри — дело десятое. Когда сайт ломается, я правлю один модуль, а не всё.
Что агент умеет сейчас
Запустил в таком виде месяца три назад. Не идеально, но работает.
Мониторит 47 товарных позиций на шести сайтах. Раз в три часа забирает данные, сравнивает с историей. Если изменение больше 3% — отправляет уведомление в Telegram. Раз в пятницу — сводный отчёт.
Мелочь, но раньше на эту работу уходило часа три в неделю. Теперь — минут десять, чтобы прочитать отчёт и нажать «ок».
Что я понял
ИИ-агент для мониторинга — это не «внедрил и забыл». Это система, которая требует внимания, но в разы меньше, чем ручная работа.
Три вещи, которые сэкономили мне больше всего времени: нормализация данных на входе, универсальный формат между модулями и простой интерфейс уведомлений на выходе. LLM — полезный инструмент, но не замена логике. Резюме — да, анализ структуры цен — можно, а вот сам мониторинг лучше оставить старым добрым парсерам.
И да, если у конкурента Cloudflare — смирись или купи платный прокси. Я потратил неделю, пытаясь обойти его вручную. Зря.
