Когда инструкция без телеметрии не отвечает на главный вопрос

FreezerData — нидерландская микрокомпания с 1–9 сотрудниками. В официальном кейсе European Digital Innovation Hubs она описывает «виртуального сервисного механика» для холодильного оборудования. Задача возникла из дефицита квалифицированных техников: опытные специалисты тратили время на вопросы коллег, а задержка диагностики могла обернуться простоем и порчей продукции у клиентов.

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

Проект дошёл до Proof of Value, а не до доказанной массовой эксплуатации. По данным EDIH, хаб вложил €10 тыс., сама FreezerData — €50 тыс. Эти суммы относятся к созданию демонстратора и партнёрской работе, а не к гарантированной цене внедрения для другого бизнеса. В источнике нет подтверждённых показателей окупаемости, точности ответов или сокращения выездов — и это важное ограничение кейса.

Что именно соединили в прототипе

У решения два разных источника истины.

  • **Статические знания:** инструкции, схемы, правила обслуживания и описания неисправностей.
  • **Динамические данные:** температура, давление, влажность, состояние двери и другие сигналы конкретной установки.

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

На текущем сайте FreezerData заявлено, что платформа получает данные каждую минуту, поддерживает внешние датчики 4–20 мА и хранит показания в облачной базе. Это описание коммерческого продукта самой компании, а не независимая проверка. Для российского предприятия важен не конкретный стек, а разделение обязанностей: контроллер и пороговые правила защищают оборудование, аналитика обнаруживает отклонения, а языковая модель объясняет данные и находит процедуру.

Архитектура без магии

Практичный контур можно построить из шести слоёв.

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

**2. Телеметрия.** Шлюз собирает сигналы, ставит время, проверяет единицы измерения и буферизует поток при потере связи. Сырые данные хранятся отдельно от агрегатов. Пропуск показаний обозначается как пропуск, а не превращается в ноль.

**3. Детерминированные правила.** Критические пороги, блокировки и аварийные сценарии остаются в контроллере или специализированной системе мониторинга. LLM не должна решать, отключать ли компрессор, только на основании свободного текста.

**4. RAG по документации.** В индекс попадают утверждённые руководства с метаданными: модель, версия, язык, дата действия, раздел и номер страницы. Ответ показывает источник и фрагмент, а устаревший документ исключается из поиска.

**5. Инструмент чтения телеметрии.** Модель не получает бесконечный поток значений в промпт. Она вызывает типизированную функцию: установка, метрика, интервал, агрегирование. Функция возвращает проверенный JSON с временем, единицами и признаком качества данных.

**6. Рабочий процесс.** Ассистент формирует гипотезу и чек-лист проверки. Техник подтверждает диагноз, решение о выезде и результат ремонта. Обратная связь попадает в журнал случаев, но не становится автоматически «истиной» без проверки ответственным инженером.

Такой дизайн позволяет локализовать чувствительные части. Документы, журнал ремонтов и телеметрия могут оставаться в контуре предприятия; наружу при необходимости уходит только обезличенный запрос. Локальная модель особенно уместна, когда инструкции содержат закрытые схемы, а история поломок раскрывает режимы работы оборудования. Но локальность сама по себе не исправляет плохие права доступа, устаревшие документы и неверные датчики.

Какие данные нужны до выбора модели

Для полезного пилота нужны не тысячи PDF, а небольшой управляемый набор:

  • 20–50 утверждённых руководств и сервисных бюллетеней;
  • реестр установок и соответствие каждой документации;
  • словарь метрик, единиц и допустимых диапазонов;
  • 30–50 обезличенных историй диагностики с подтверждённой причиной;
  • перечень вопросов первой линии и правила эскалации;
  • роли доступа: оператор, техник, старший инженер, администратор;
  • эталонный набор вопросов с ожидаемым источником и допустимым действием.

Качество телеметрии надо проверять отдельно. Датчик может зависнуть, дрейфовать, потерять связь или передавать значение с неверной временной зоной. Если ассистент уверенно объясняет плохой сигнал, красивый ответ лишь ускоряет неверное решение.

Где проходит граница ответственности

«Виртуальный механик» должен оставаться помощником, а не автономным диспетчером критичного оборудования.

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

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

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

Четвёртый риск — утечка через документы и запросы. Руководства, сервисные записи и данные клиента разделяются по организациям и объектам. Фильтр доступа применяется до поиска, а не после генерации ответа. Все обращения к телеметрии журналируются.

Экономика: считать принятые решения, а не ответы чат-бота

Сделаем модельный расчёт, не относящийся к FreezerData. Допустим, первая линия задаёт старшему инженеру 15 вопросов в неделю, на каждый уходит 20 минут. При полной стоимости часа специалиста 1 500 рублей это около 30 тыс. рублей в месяц. Если ассистент снимает половину вопросов и помогает избежать одного лишнего выезда стоимостью 12 тыс. рублей, валовый эффект составит примерно 27 тыс. рублей в месяц.

При пилоте стоимостью 350 тыс. рублей и поддержке 40 тыс. рублей в месяц такая схема не окупается: ежемесячный эффект ниже операционных затрат. Чтобы вернуть 350 тыс. за год при той же поддержке, нужен подтверждённый эффект примерно 69 тыс. рублей в месяц. Его могут дать больше объектов, дорогие аварийные выезды, снижение порчи продукции или сокращение времени простоя — но каждую статью надо измерить.

Главные метрики пилота:

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

Шестинедельный пилот без доступа к управлению

**Неделя 1.** Выберите один класс оборудования и один процесс — например, первичную диагностику температурного отклонения. Соберите 30 реальных вопросов и зафиксируйте текущие время ответа, эскалации и выезды.

**Неделя 2.** Очистите реестр установок и загрузите только действующие руководства. Для каждого фрагмента сохраните модель, версию и страницу.

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

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

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

**Неделя 6.** Откройте подсказки ограниченной группе, сохранив подтверждение человека. Решение о расширении принимайте по стоимости принятого результата, а не по числу диалогов.

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