YADRO запретила LLM трогать цифры и выпускает 10+ отчётов в день без людей

В YADRO команда, которая управляет парком IT-оборудования, за три месяца построила сервис, ежедневно выпускающий больше десятка аналитических отчётов для пяти департаментов. Люди в процессе не участвуют. Главное инженерное правило: все числа считает код, а языковая модель пишет только текстовые комментарии и ни одного показателя не видит в сыром виде. Проект сделали старший бизнес-аналитик Егор Шлюпиков и его коллега Егор Катаев, причём промышленной разработки в команде GRID до этого никто не вёл.

От эксперимента с выгрузкой до отдельного сервиса

Всё началось с апрельской задачи: оценить остатки на одном из складов и предложить, как разобрать залежавшуюся технику. Тогда в компании следили за метрикой aged, то есть долей активов, которые лежат больше одного-двух лет. Шлюпиков взял выгрузку из Naumen.ITAM, вычистил чувствительные данные (юрлица, названия складов) и попросил нейросеть собрать HTML-отчёт. Разрезов получилось много, каждый по отдельности малоценный, но вместе они закрывали массу вопросов. Руководитель одобрил развитие идеи в контуре компании.

Первая версия жила на low-code платформе Dify: туда подключили бизнес-контекст как базу знаний, а из-за ограничений по контексту стали передавать не сырые данные, а сводку, подготовленную Python-скриптом. Но и со сводкой модель ошибалась. Она переносила числа в текст по правилам промпта, и в комментариях всплывали одни и те же цифры не к месту. Выяснилось, что это значения из среза активов в день подключения базы знаний, а не актуальные данные.

Метки вместо чисел

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

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

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

Trino как склейка по времени и между системами

Когда источников стало больше, весь слой данных переехал на отдельную виртуалку с Trino. Авторы признают, что на тот момент это было избыточно, но заложили запас прочности. Trino решает две задачи.

• Склейка по времени. В Naumen.ITAM текущее состояние лежит в реплике боевой базы, а история приходит в ClickHouse суточными слепками. Один федеративный запрос берёт сегодняшнюю точку из реплики, а вчера и всю историю из ClickHouse. Ограничение: шаг истории равен суткам, статусы, менявшиеся в течение дня, не видны, поэтому скорость процессов считают осторожно.
• Склейка между системами. Naumen.ITAM знает, за какой командой числится сервер, NetBox знает стойку в ЦОДе. Запрос соединяет их и показывает, как расходы на стойку распределяются по командам.

Генераторы отчётов не знают, откуда пришли данные, поэтому подключение нового источника не требует переписывать отчёты. Источники сейчас: Naumen.ITAM, ClickHouse DWH, 1C, BI/CPM-платформа (число новых сотрудников и бюджет), Jira (заявки на оборудование) и NetBox.

Конвейер и защита от собственных ошибок

Цепочка такая: Airflow (ушли с cron) запускает DAG, данные читаются через Trino, Python считает показатели, Dify возвращает комментарии, шаблон рендерит HTML, отчёт сохраняется с меткой времени, ссылка на последнюю версию переставляется. Доступ идёт через корпоративный Keycloak и проверку прав в validator, есть роли владельцев, администраторов, пользователей и суперпользователей. Через Mattermost можно запросить доступ, обновить отчёты и посмотреть статистику.

Код лежит в корпоративном GitLab, изменения принимаются только через merge request не автором. Каждое обновление сутки работает на отдельном стенде, при провале приёмки откат автоматический.

Данные, которых не было

Появление сервиса вскрыло пустоты в данных. Оперативной стоимости складских остатков раньше никто не считал, а цена в Naumen.ITAM заполнена не у всех позиций. Решение: импутация по когортам (тип техники, модель, производитель, год выпуска). Средняя цена по позициям с ценой распространяется на остальные. В отчёте фактическая стоимость и оценка показаны отдельно. Если в когорте цен нет вовсе, её укрупняют или оставляют без оценки с пометкой. Сверка с бухгалтерией дала сопоставимые цифры.

Что можно взять в работу

Паттерн переносится на любую отчётность: считает детерминированный код, модель получает агрегаты и возвращает текст с плейсхолдерами. Это дешевле по токенам, проще в аудите и не ломает отчёт при сбое модели. Следующий шаг команды: конструктор отчётов, где пользователь описывает разрез словами, модель формирует описание метрик, а SQL генерирует семантический слой Cube по заранее заданным мерам. Модель и здесь не трогает ни запросы, ни числа.