Какая задача стояла у небольшой компании

Нидерландская FreezerData работает с мониторингом холодильного оборудования. По опубликованному European Digital Innovation Hubs Network (EDIH) кейсу 2024 года, это микрокомпания с 1–9 сотрудниками. Её заказчикам важно быстро понимать, когда холодильная система работает нестабильно и надо ли отправлять техника. При этом опытные специалисты отвлекаются на вопросы менее опытных коллег, а показания датчиков и инструкции к оборудованию обычно живут в разных местах.

Компания вместе с партнёрами сделала «виртуального сервисного механика»: прототип помощника, который отвечает на технические вопросы, используя руководства и текущие данные датчиков. Особенно важным оказался выбор источника: вопрос об устройстве узла требует инструкции, вопрос о текущем состоянии конкретной установки — телеметрии. EDIH сообщает о Proof of Value, то есть демонстраторе ценности, и о вложениях €10 000 со стороны программы и €50 000 со стороны FreezerData. Это не цена типового внедрения в России и не подтверждённая экономия. В кейсе нет измеренных данных о снижении времени ремонта, числе предотвращённых аварий или окупаемости.

На собственном сайте FreezerData описывает облачную платформу мониторинга температуры и других параметров. Это заявление поставщика о продукте, а не независимый результат проекта «виртуального механика». В статье ниже архитектура для российского предприятия — редакционное предложение, а не раскрытая техническая схема FreezerData.

Почему одного RAG недостаточно

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

Практический ответ полезно строить из трёх отдельных слоёв:

  • **Документ**: модель и версия руководства, страница, процедура, допустимые пределы и дата актуальности.
  • **Факт объекта**: идентификатор установки, время последнего показания, единицы измерения, качество связи и последние тревоги.
  • **Решение**: что проверить, насколько срочно и кто принимает решение о выезде или остановке.

Если телеметрия устарела, система должна прямо сказать об этом. Если в инструкции нет нужной процедуры, честнее передать запрос старшему инженеру, чем достраивать ответ правдоподобными словами. Генеративная модель может написать понятное объяснение, но не должна сама «назначать» порог безопасности: порог берётся из утверждённой документации и правил эксплуатации.

Минимальная архитектура пилота

Для малого бизнеса первая версия не требует автономного агента с доступом ко всем системам. Нужны небольшой каталог оборудования, хранилище проверенных руководств и безопасный интерфейс чтения показаний. Каждому устройству присваивают постоянный ID и связывают его с моделью, серийным номером, датчиками, объектом, сервисной историей и актуальной документацией. Руководства размечают по модели и ревизии; в индекс нельзя без проверки отправлять случайно найденный PDF для похожей установки.

Запрос «Почему камера 17 набирает температуру?» сначала разрешается в конкретный объект. Сервис телеметрии возвращает последние показания с временными метками и признаком отсутствующих данных. Поиск по документации получает только подходящие этому оборудованию разделы. Затем правило или маршрутизатор определяет, достаточно ли данных для ответа. Модель формирует черновик с раздельными ссылками на руководство и показания; инженер подтверждает вывод и действие. Если вопрос касается работы компрессора, отключения питания или продукции с обязательным температурным режимом, нельзя делать автоматическое управляющее действие из одного текстового ответа.

Локальный контур здесь уместен, если телеметрия не должна уходить наружу, связь с облаком ненадёжна или объекту нужен автономный доступ к инструкции. Можно держать индекс и модель на собственном сервере, а данные датчиков получать через шлюз только на чтение. Но локальность сама по себе не решает задачу: нужны обновление руководств, резервирование, контроль доступа по объектам и журнал ответов. Если нагрузка мала, модель может работать на CPU или общем сервере; мощный GPU покупают только после измерения задержки и числа одновременных запросов.

Проверка качества и безопасности

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

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

Особое внимание нужно уделить доступу. Техник одного заказчика не должен увидеть показания или сервисную историю другого. Поиск по документам и чтение телеметрии должны проверять права до передачи контекста модели. Запись в контроллер, изменение уставки и закрытие заявки — отдельные операции с явным подтверждением и аудиторским следом, если их вообще включат позднее.

Экономика без чужих обещаний

В опубликованном кейсе указаны затраты на разработку демонстратора, но не итоговая экономия у клиентов. Для российского МСП бизнес-расчёт начинается с собственных величин: сколько обращений в месяц отнимает время старшего инженера; как часто требуется повторный выезд; сколько стоит час простоя и насколько рано поступает достоверный сигнал. Не переносите €60 000 в локальный бюджет и не записывайте гипотетически спасённый товар в выручку.

Пример **модельного** расчёта: если 40 обращений в месяц сокращаются на 10 минут участия старшего специалиста, высвобождается около 6,7 часа в месяц. При условной полной стоимости часа 1 500 рублей это примерно 10 000 рублей в месяц валовой ценности времени до расходов на внедрение, поддержку и контроль качества. Это не результат FreezerData. Если помощник регулярно ошибается и требует перепроверки, экономия исчезнет; если же предотвращает один дорогой инцидент, главный эффект может лежать совсем в другой строке. Последнее надо доказывать журналом фактических событий, а не презентацией.

Следующий шаг

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

Кейс FreezerData показывает полезный принцип: ИИ-помощник в сервисе становится ценным, когда умеет различать «что написано в руководстве» и «что происходит с этой установкой сейчас». Подтверждён пока демонстратор, а не универсальная экономия — для бизнеса это важная граница обещаний.