Детерминированные ИИ-отчёты без ИИ-галлюцинаций: кейс промышленной IoT

Видишь сурка?

Коллеги, я не претендую на истину в последней инстанции. Вся моя жизнь в роли технического директора - это ошибки, ошибки и самописные конструкции. В конце бурных 90-х все верили в UML и Rational Rose, который позволит создать пользовательский интерфейс по описанию, созданному консалтерами по 1000 долларов за час. В начале 2000 были OLAP кубы, которые позволяли создавать любые отчеты несколькими кликами.

Но, ни разу мне не удавалось применить волшебные технологии в прикладной практике. То есть, это все, как бы существует, но потом программист пишет код. А код для отчетов - отдельный занудный мир.

Снова о предметной области

Мы - продуктовая компания. Порядка 50 000 контроллеров, управляющих светильниками по всей стране, через 1 500 базовых станций (они же Устройства Сбора и Передачи Данных) присылают телеметрию о своей работе. Даже простые таблицы с получасовыми данными Приборов Учета Энергии (в простонародье счетчиков) очень быстро превращаются в многомиллионные таблицы. А есть еще таблицы со статусами контроллеров, что прилетают со всей страны от контроллеров раз в 15 минут. Такие таблицы становятся миллионниками раз в 4 часа.

На сервере крутится целая фабрика агрегации, которая в несколько этапов сжимает данные до приемлемых объемов. Но каждое сжатие - потеря сути, а в век ИИ мы могли бы найти инсайты в том, что безжалостно переработали в фарш, обезводили и пустили на корм. Но поиск инсайтов в бигдата - удел пытливых ученых, а тут промка и техпроцессы с максимумом эффективности.

Отчеты отчетов

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

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

Тем более, что эти проблемы, по сути своей - флуктуации на земле:

• Отгорание нуля - 380

• Обрыв линии

• Сторонние подключения

• Авария на 10Квт

• ДТП со сносом опоры освещения

• Пожар в ТП

• И далее со всеми остановками.

Апофеозом процесса стал отчет из 14 отчетов (рисунок 1), в котором я собрал ВСЕ лучшие практики поиска критериев отказов. Тут почти все, кроме физического вмешательства в работу оборудования при открытии дверей шкафов.

Интерпретация отчетов

Давайте представим, что у нас есть осветительная установка в масштабах города размером от 1 000 до 10 000 светоточек. Установив контроль над каждым шкафом управления и каждым светильником, мы получаем данные в таком масштабе и с такой детализацией, которой раньше не было.

Также наша установка всегда идет вразнос: снегопады, дожди, потопы, ДТП, ветер и падающие деревья, 380, выгорающие драйвера, моросящие соединения.

Есть выездные бригады с вышками, которые могут поправить ситуацию. Бригад всегда в 5 раз меньше чем событий.

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

Ничего не напоминает? Кто/что у нас вероятностный догадчик?

Этап LLM

Был момент, когда я осознал, что далеко не в первый раз рассказываю в какой последовательности подходить к контроллерам в таблице и как разбить пуско-наладку с учетом таблиц, чтобы она прошла эффективней, а не просто вошла в замкнутый спин.

В итоге родился супер пропмпт для Claude, в котором были прописаны зависимости 6-7 таблиц, вероятные вызывающие причины и рекомендуемые действия. Промпт писался как вчитанные стихи - высказанная боль. В результате вышел отчет (рисунок 2). Что по мне - так - вполне закономерный результат. А для менеджеров - прорыв.

Конвейер

Основной концепт отчета - список проблем “на земле” с которыми следует поработать для достижения идеала и рекомендации о том как поработать. Например, пониженное потребление светильника - ищи проблему в светильнике. Если у нескольких рядом - ищи оборванный ноль.

Есть нюанс. Перед выдачей отчета мои инженеры причесывают логические нестыковки, грубо говоря - тех долг, оставшийся после принятия пусконаладочных работ.

Менеджеры получили отчет и пропали! Я был доволен - редко когда удается отвязаться о толпы назойливых менеджеров отчетом.

Два месяца спустя - вся толпа менеджеров вернулась:

• Отчет - огонь - позволил сделать мир светлее, количество жалоб жителей - ниже.

• Это продукт, который готовы продавать.

• Но! Отчет нужно сделать системным, ежедневным, еженедельным, ежемесячным и с KPI для обслуживающей организации.

В такой интерпретации суперпромпт для Claude разом перестал выглядеть волшебной таблеткой.

Система

Наверное, неделю я думал как подойти к вопросу. Имеем:

• На входе: данные о событиях/телеметрии с какими-то инсайтами в содержании

• На выходе: отчеты в PDF, повторяемые, легко интерпретируемые, рассылаемые

Вариант запихнуть в контекстное окно промпт и кучу данных было признано нерабочим. По опыту и 10% подобной портянки начинают проседать в середине - какую LLM ни возьми.

Решение пришло в таком виде. Берем n8n (извинте, очень удобно для декомпозиции на блоки). Далее (рисунок 3):

1. Разделил исходные проблемы на блоки: критические, высокой важности, средней, информационные (сюда попадает все где проблем нет)

2. Берем список через API - программисты пошли дописывать функционал API

3. Форматируем JSом в JSON

4. Создаем секцию отчета:

   1. Описание

   2. Таблица с данными (в общем они разные)

   3. Возможные причины (список)

   4. Что следует сделать (список)

   5. Краткое резюме раздел в цифрах.

   6. Отдельная секция если проблем в категории не выявлено и уровень Информация.

Обратите внимание! Никаких агентов с ИИ - все исключительно детерминированный и повторяемый процесс. Хотел вставить в конце некое общее заключение, которое подготавливает LLM - но не стал.

• Все типовые секции отчета собираются в один общий JSON

• Форматируются в HTML

• Конвертируется Gotenbergом в PDF

• Отправляются адресатам Телеграммами.

Плюсы системы:

1. Все детерминировано и повторяемо. Если вернуться назад в любой день - получается тот же отчет что был сгенерирован тогда. Возможно, кажется диким, что я поставил это в плюс. Но, поверьте, если имеешь дело с ИИ бывает и не такая дикость.

2. Взглянул на API по новой - сделав его полезным, а не лоскутным одеялом под запросы.

Минусы:

1. Утомительно создавать и поддерживать. Успокаивает то, что в виде одеяла кода это поддерживать еще более утомительно.

2. На картинке только один из 4 отчетов, готовый на 60-70%. Другие имеют сравнимый размер.

Ключевой архитектурный принцип

Так как отчеты огромные (до 15 секций) и их много, то единственным вариантом видится декомпозиция до кубиков, каждый из которых легко осознать (рисунок 4). А, с учетом того, что код набрасывает ИИ, в маленьких блоках он идеален и код практически человекочитаем.

Где же тут ИИ?

Когда нужно много, разного, повторяемого быстро - используй ИИ (с) народная мудрость.

Изначально я исходил из того, что нужно будет создавать длинные отчеты с запросом кучи таблиц - неизбежны ошибки, да и код я писать не умею. Поэтому сделал живое ТЗ по шаблону. Сами инструкции длиннее, тут compose:

Роль и задача

Подготовка JS-скриптов для узлов n8n, форматирование данных для визуализации и отчётов.

Стиль ответов

Только по запросу, без лишних предложений.

Архитектура воркфлоу

Триггер → API объектов → UUID → запросы → анализ агентом → JSON → HTML → PDF (Gotenberg).

MCP и skills

Воркфлоу доступен через коннектор n8n.svetosystem.ru, ID: KGRвымысел8HY.

Требования к коду

JS для нод CODE, абсолютная адресация нод, экранирование символов Telegram-разметки.

Паттерн узлов

HTTP Request → _JS (парсинг) → Секция (формирование JSON структуры отчёта).

Структура секции отчёта

JSON с полями: id, title, level, description, table, possibleCauses, necessaryActions, conclusions.

Правила HTML

Инлайн-стили таблиц, текст заголовков заглавными, экранирование HTML-спецсимволов, separator между блоками.

Контекст файлов

API Sunrise — список эндпоинтов; workflow_map.md — архитектура и ноды воркфлоу.

В результате:

1. Получаю идеальные тройки нодов АПИ - JSON - Секция

2. Были попытки запросить данные с неправильными фильтрами - документация на АПИ не дала креативить

3. Самое главное, на мой взгляд, сначала отчеты в HTML получались каждый раз своего вида/цвета/конфигурации. Разозлился - попросил Клода написать блок в инструкции на примере понравившегося отчета. Теперь все отчеты на одно лицо.

4. Клод имеет навыки JS кода для n8n, то есть, ни разу не ошибался в синтаксите

5. Имеет доступ к Воркфлоу и видит его актуальную версию - удобно, когда просишь сделать подобное.

Создание отчетов - проект в Claude (рисунок 5).

Инсайты

1. Очень удобно описывать секции отчетов, особенно, описание, возможные причины и рекомендуемые работы.

2. Если внимательно посмотреть на рисунки 3 и 4, то видны Notes и Workflow_map - это сущности, которые порекомендовал создать Claude. Ему стало понятнее, но и человек тоже понимает о чем речь.

3. Документация по SUNRiSE API - это боль. Во-первых, ее нужно поддерживать и программисты пыхтят. Во-вторых, она разная в разных проектах в связи с тем, что, пока, динамична из-за появления множества новых функций и полей. Уже взял за правило - начал движение в новом проекте - обнови документацию по API. Вывод: мечты о swagger или MCP сервере с описанием.

Заключение

В целом, получился интересный кейс с ИИ без ИИ. Или наоборот.

Получилось взять контроль над сложными отчетами, над интерпретацией данных для простых людей. То есть, программисты реализуют API - уровень данных, а содержательная часть - это мое и инженеров, которые могут понять структуру n8n и дополнить ноды кейсами.

Для обновления отчета теперь не надо ждать следующего спринта.

Все детерминировано, отчет повторяется из раза в раз. Но! Подобное было бы невозможно без современных технологий (n8n, Claude).

Как вы решаете задачу интерпретации данных для нетехнических пользователей — пишете отдельный слой логики или идёте в сторону промптов и ИИ?"