Почему ИИ-отчёты не работают, пока операционные данные лежат в Excel
ИИ-отчётность многие представляют себе очень просто.
Берёте папку с Excel-файлами, PDF, ежедневными отчётами, сводками с объектов и рабочими заметками. Загружаете всё в языковую модель. И пишете: «Сделай мне отчёт для руководителя».
На маленьком примере это выглядит на удивление убедительно. Загрузите один-два файла или данные за пару дней — модель сведёт информацию, найдёт несколько закономерностей и выдаст что-то похожее на отчёт.
Проблемы начинаются, когда ситуация становится настоящей. Не два файла. Не одна неделя. Не одна аккуратная таблица. А сотни файлов от разных подразделений, за разные периоды, в разных форматах и по разным процессам.
Вот здесь подход «просто скормить всё модели» и ломается. Отчёт она, скорее всего, выдаст. Но цифрам станет трудно доверять, расчёты будет трудно проверить, а проследить значение до исходного файла окажется практически невозможно.
Это один из главных уроков, которые мы вынесли, пока делали Logsheet.ai.
Начинали мы с очень простой идеи — производственные журналы. Компания один раз описывает журнал: например, журнал вывоза леса, сменный производственный отчёт, лист учёта простоев оборудования или другой операционный журнал. Дальше команды на объектах заполняют его каждый день. Строка за строкой. Смена за сменой. Участок за участком.
Сначала это выглядит как обычный инструмент сбора данных. Но очень быстро появляется новый вопрос: а можно ли превратить всё это в управленческую отчётность?
Настоящая проблема не в сборе данных
Многие компании операционные данные уже собирают.
- У них есть таблицы.
- У них есть PDF-файлы.
- У них есть бумажные бланки.
- У них есть фотографии с объектов.
- У них есть сменные отчёты.
- У них есть ежедневные сводки.
- У них есть сообщения от мастеров.
Проблема не в отсутствии данных. Проблема в том, что данные разрознены, неоднородны и не подготовлены к анализу.
Одно подразделение присылает таблицу. Другое — PDF. Третье использует слегка другой шаблон. Четвёртое переименовало колонки. В части файлов на одном листе лежит несколько сущностей сразу. Где-то шапка в три уровня. Где-то есть пустые колонки, которые всё равно что-то значат. Что-то структурировано достаточно для человека, но недостаточно для системы.
Со стороны всё это выглядит как отчёты. Для управленческой аналитики это сырьё. А сырьё нужно обработать, прежде чем оно станет надёжной информацией.
Почему сотни файлов в языковой модели не работают
Языковые модели хорошо понимают текст, распознают структуру и помогают человеку работать с информацией. Но они не являются надёжной базой данных. Они не детерминированный расчётный движок. И они не прозрачный источник истины для сотен операционных файлов.
На небольшом наборе документов модель удерживает достаточно контекста, чтобы выдать полезную сводку. Как только объём растёт, появляется несколько проблем.
- Модель теряет детали.
- Она может неверно склеить похожую на вид информацию.
- Она может выдать цифры, которые выглядят правдоподобно, но не совпадают с исходными данными.
- Становится трудно объяснить, откуда взялось каждое значение.
Для бизнес-отчётности это опасно. Отчёт — не просто текстовая сводка. Это объект, на основании которого принимают решения. Если директор видит, что подразделение отстаёт от графика или что по конкретной операции есть задержки, цифра должна быть прослеживаемой.
- Откуда она взялась?
- Какие файлы в неё вошли?
- Какие строки были учтены?
- По какой формуле она посчитана?
- Что было исключено?
Если ответ звучит как «так сказала модель», система недостаточно хороша.
Фундаментом становится база данных
Главный сдвиг для нас был в том, что ИИ не должен быть местом, где живут операционные данные. Данные сначала нужно извлечь, привести к единому виду и загрузить в базу. И только после этого ИИ становится полезен.
Процесс становится гораздо надёжнее:
- Пользователь загружает операционные файлы.
- Система разбирает их структуру.
- Данные раскладываются по журналам и таблицам.
- Записи сохраняются в базу.
- Агрегаты считаются детерминированно.
- Модель помогает спроектировать и объяснить отчёт.
- Итоговый дашборд можно построить повторно и проверить.
Это меняет роль ИИ. Модель больше не пытается «запомнить» всё содержимое исходных файлов. Она становится интерфейсом и слоем рассуждения поверх структурированных данных. Это гораздо более подходящее для неё место.
ИИ полезен при импорте — но только с жёсткими инструкциями
Импорт файлов звучит просто ровно до встречи с настоящими рабочими таблицами.
- В таблице бывают объединённые ячейки.
- Шапка бывает трёхуровневой.
- На одном листе бывает несколько логических таблиц.
- Часть колонок пуста, но осмысленна.
- Часть значений нужно трактовать по положению, а не только по тексту.
- Часть файлов — это разные версии одного и того же процесса.
Если просто сказать модели «разбери этот файл и загрузи в таблицы», она наделает ошибок. Поэтому скрытая часть системы становится крайне важной.
Пользователь видит простое действие — загрузить файл. За ним системный промпт должен объяснить, как обращаться с шапками, пустыми колонками, несколькими сущностями на листе, непонятной структурой, созданием журналов, правилами сопоставления и требованиями к проверке.
Качество результата сильно зависит от этого невидимого слоя. Без него данные теряются. С ним модель становится по-настоящему полезной.
Отчётам тоже нужна скрытая структура
С генерацией отчётов история та же. Пользователь пишет: «Сделай отчёт для директора обо всём, что отстаёт от графика».
Звучит просто, но системе нужно превратить это в куда более точный план отчёта.
- Что считается графиком?
- Где хранятся плановые значения?
- Где хранятся фактические?
- Как считать отставание?
- В каких журналах лежит нужная информация?
- Какие поля определяют статус?
- Что выносить в ключевые показатели?
- Какие графики здесь уместны?
- Что подсветить в выводах?
Пользователь не должен описывать всё это вручную. А система — должна. Поэтому задача модели не только написать красивый отчёт. Ей нужно рассуждать о структуре доступных данных, подготовить план и решить, какие запросы и разделы нужны.
Вот здесь языковые модели по-настоящему полезны: они превращают человеческий запрос на отчёт в структурированную спецификацию отчёта.
Считать цифры мы модели не даём
Одно из главных опасений при отчётности на языковых моделях — галлюцинации. И опасение справедливое. Если разрешить модели придумывать, прикидывать и считать цифры свободно, отчёту нельзя доверять.
Наш подход другой. Модель может решить, что нужно посчитать. Может объяснить, что означает цифра. Может помочь со структурой отчёта. Может написать выводы и подсветить закономерности.
Но сами расчёты происходят вне модели. Суммы, средние, отклонения, проценты и прочие агрегаты считаются детерминированно — как правило, SQL-запросами или другим контролируемым расчётным слоем.
Так возникает очень важная граница. Модель пишет текст. Цифры даёт база.
Именно эта граница делает отчёт проверяемым. Если цифра появилась в дашборде, её можно проследить до запроса и до исходных записей. В этом и есть разница между полезной системой ИИ-отчётности и красивой галлюцинацией.
Многоагентная проверка повышает надёжность
Ещё один урок: одного шага ИИ часто недостаточно. Для сложных импортов и структур отчётов мы применили самопроверку.
- Один агент готовит структуру.
- Второй её проверяет.
- Третий ещё раз просматривает результат.
- Если что-то выглядит неправильно, процесс повторяется, пока результат не станет приемлемым.
Идеальной системы это не даёт, но надёжность повышает. В наших внутренних экспериментах такая проверка улучшила качество распознавания файлов примерно на 10%. Звучит скромно, но в обработке операционных данных 10% значат много — особенно если альтернатива в том, чтобы вручную чистить файлы и проверять каждую импортированную таблицу.
Кеширование промптов важнее, чем кажется
При работе с большим операционным контекстом расходы на токены растут быстро. Система многократно переиспользует одну и ту же структуру базы, описания журналов, стандарты отчётности и инструкции по импорту. Если всё это каждый раз отправлять заново, счёт растёт стремительно.
Кеширование промптов заметно это снижает. За один период внутреннего тестирования мы потратили около 80 долларов и обработали десятки миллионов токенов, при этом экономия на кеше оказалась больше прямых расходов. Конкретные цифры сильно зависят от сценария, но направление понятное: когда контекст повторяется, кеш имеет значение.
Тем, кто строит похожие системы: кеширование не стоит откладывать на потом. Оно влияет на стоимость, на задержки и на экономику продукта в целом.
Настольный ИИ кажется проще, чем ИИ через API
Ещё один практический урок: тестирование в настольных ИИ-приложениях вводит в заблуждение.
Когда мы вручную загружали файлы в десктопные версии ИИ-продуктов, впечатление было очень сильным. Контекст держался хорошо, интерфейс был удобным, результат было легко проверить.
Перенос того же сценария в API — совсем другой опыт. Контекст, лимиты, работа с файлами, промпты, повторные попытки, память, валидация и стоимость ложатся на вас. API даёт контроль, но заодно обнажает всю инженерную сложность, которую десктопный продукт прячет.
Именно здесь ломается множество прототипов. Демо может работать вручную. Продуктовому процессу нужна система.
Вопрос приватности никуда не девается
Если операционные данные обрабатываются внешними поставщиками моделей, приватность становится реальной темой. В производственных данных могут быть объёмы выпуска, проблемы с оборудованием, задержки, внутренние процессы, поставщики, заказы клиентов и другая чувствительная информация.
Подходов несколько. Первый — корпоративные тарифы поставщиков моделей, где условия использования данных прозрачнее, а обучение на них ограничено. Второй — разделить процесс: внешние модели для сложной интерпретации структуры, чувствительные данные — в более контролируемом контуре. Третий — переходить на локальные модели для части этапов.
Идеального варианта нет ни одного. Но архитектура должна учитывать этот вопрос с самого начала.
Идея крупнее: журналы становятся управленческой инфраструктурой
То, что начиналось как простые операционные журналы, может вырасти во что-то гораздо большее. Когда сбор данных, импорт, структура, проверка, отчётность и дашборды связаны между собой, журнал перестаёт быть просто формой. Он становится системой управления.
- Команда на объекте вносит ежедневные операционные данные.
- Файлы из существующих процессов можно импортировать.
- База данных становится источником истины.
- ИИ помогает разобрать структуру и собрать отчёты.
- SQL держит цифры детерминированными.
- Дашборды дают руководителям видимость.
- Пользователи могут задавать вопросы и проваливаться в детали.
В этом мы и видим практическую ценность. Не «ИИ пишет отчёт из случайных файлов», а «ИИ помогает превратить операционные данные в структурированную видимость для руководства».
Что в итоге
Можно загрузить в модель 200 Excel-файлов и попросить отчёт. Можно даже получить что-то впечатляющее на вид. Но если цифры нельзя проверить, данные нельзя проследить, а процесс нельзя надёжно повторить — это не система управленческой отчётности. Это демо.
Более полезный подход меньше похож на магию и больше — на архитектуру:
- извлечь данные из файлов;
- привести их к единому виду;
- сохранить в базу данных;
- считать цифры детерминированно;
- использовать ИИ для структуры, интерпретации, логики отчёта и текста;
- проверять результат;
- кешировать повторяющийся контекст;
- помнить о приватности.
В этом и разница между ИИ как игрушкой и ИИ как частью продукта операционной отчётности.
Урок простой: языковые модели не заменяют структурированные данные. Но когда они стоят поверх структурированных данных, они становятся мощным интерфейсом между ежедневной работой на площадке и управленческими решениями.
