ChatGPT в n8n для парсинга недвижимости: где нужен ИИ
В этой заметке разбирают схему мониторинга объявлений недвижимости в n8n и обсуждают, нужен ли здесь отдельный слой решений вроде Luna Decisions от OpenAI. Автор показывает, где обычного кода уже хватает, а где хочется, чтобы модель не просто писала текст, а помогала решать, какое изменение важно для уведомления.
Что именно собрано в схеме
Проект устроен как мониторинг объявлений: система регулярно забирает выдачу, нормализует данные и сравнивает их с предыдущим состоянием. Запуск может идти по расписанию, вручную из Telegram-бота или через алерт при ошибке воркфлоу — все ветки сходятся в одну цепочку обработки.
Внутри используются n8n, Google Sheets и JavaScript-логика сравнения. Таблица здесь играет двойную роль: это и витрина для человека, и хранилище прошлого состояния. Но такой подход не закрывает вопросы пересечений запусков, дедупликации и атомарного обновления, если ручной старт совпадёт с плановым.
Почему автор смотрит в сторону Decisions API
Главный вопрос не в том, как собрать данные, а в том, какое изменение стоит превращать в отдельное уведомление. Одно дело — положить событие в журнал, другое — сразу отправить сообщение человеку. Именно эта граница и интересует автора заметки.
На фоне этого он обратил внимание на Luna Decisions: подход, где модель выдаёт не свободный текст, а типизированную оценку, которую можно проверить и сравнить с порогом. Это удобно, если нужно не просто описание, а решение для дальнейшего действия. При этом автор честно оставляет открытым вопрос, не окажется ли в его случае достаточно обычных условий в Code-ноде без отдельного API.
Что уже умеет код без ИИ
В текущей логике JavaScript сам находит изменения, а нормализатор извлекает ad_id, ссылку, цены, комнатность, площадь, этаж, этажность, год постройки, район, адрес и время публикации. При этом отдельно подчёркивается, что цены из калькулятора — это не исходная валюта продавца, а значит по ним нельзя уверенно объяснить причину изменения.
До любой модели автор предлагает базовые проверки: не считать пустую цену нулём, не использовать отсутствующую площадь в расчётах, проверять дату публикации как дату, а не подставлять вместо неё ID, и сохранять null, если ссылка не пришла. В приведённом фрагменте также видно, что снижение цены считается в долларах, а причина падения кодом не определяется. Для журнала используется поле log_event, а прошлое состояние хранится отдельно в last_event.