Ваша семантическая модель — это API: предоставление агентам сертифицированных метрик
Почему ИИ-агенты создают собственные определения доходов и запасов, и как управляемая семантическая модель с детализацией, владельцами и отказами обеспечивает их единым контрактом.
Два числа, оба официальных
Собрание по планированию началось с слайда под названием «Продажи за прошлую неделю». Накануне двум помощникам был задан один и тот же вопрос, и оба предоставили графики с приложенными SQL-запросами. Одно значение оказалось на 4% выше плана, а другое — на 3% ниже.
Никто в комнате не винил во всем мнимые столбцы. На самом деле в базе данных действительно существовала таблица sales с столбцом net_amt и датами. Запросы компилировались, ключи соединения были присутствовали, и с точки зрения базы данных оба результата считались корректными.
Затем финансовый отдел предоставил третий вариант расчетов, который уже был готов для еженедельного письма совету директоров. В нем учитывались подтвержденные доходы по дате счета-фактуры, вычитались кредитные записи, а также исключались покупки сотрудников и оптовые продажи. Вариант Copilot one использовал дату заказа и включал данные о покупках в магазинах для сотрудников. Вариант Copilot two использовал дату отгрузки и брал регион из адреса назначения, а не из организации-продавца.
В том же обсуждении был задан вопрос о том, какую дату использовал каждый вариант; один из них указал на order_dt, а другой — на ship_dt. Ни один из них не упомянул кредитные записи. Что касается включения покупок сотрудников, один из ответчиков сказал, что не видел фильтра для них, а другой придумал историю о флаге channel, который оказался полем для определения источника маркетинговых активностей и не имел связи с магазинами для сотрудников.
Здесь проблемой было послушание. Оба агента вели себя как компетентные аналитики, у которых был трудный день: они нашли столбец, название которого напоминало вопрос, и подсчитали его значение. Обычно человек бы остановился и спросил, какой именно номер продаж требуется, тогда как агент воспринимает подходящий по названию столбец как сигнал к завершению работы.
Позже в треде Slack были три графика и один финансовый показатель. Никто не указал названия метрики, только скриншоты, и это является полезным предупреждающим знаком. Когда споры касаются изображений, контракт так и не вызывается.
Дайте агенту склад и понятное указание, и он сам придумает бизнес-модель. Эта модель выглядит как профессионализм и попадает в Slack, где люди спорят о весах моделей, вместо того чтобы обсуждать отсутствующий контракт. Такие споры легко можно отнести к проблемам культуры, однако они возникают из-за отсутствия правильного интерфейса, а проблемы становятся заметными лишь во время ежедневных собраний.
Удобный способ представить семантическую модель — рассматривать её как API, но не в смысле тенденции REST. Представьте себе интерфейс, исключающий личную интерпретацию. Когда кто-то запрашивает данные о продажах прошлой недели, запросчик не может сам выбирать, какую колонку с датами использовать. Система выполняет функцию recognized_revenue в указанном формате, иначе возвращается отказ. Инженеры всё ещё могут генерировать SQL-запросы, но агент их не пишет.
Можно представлять себе конечные точки и ключи API, если это помогает. Важнее нечто более конкретное: операция с именем и четко определенным значением, которую может вызвать любой разрешенный пользователь.
API также имеют владельцев, версии и правила изменений, влияющих на работу системы. Показатель без владельца — это лишь слух, который случайно совпадает с реальностью. Когда финансовый отдел меняет способ обработки кредитных накладных, это должно сопровождаться обновлением версии, которое почувствует каждый пользователь; в противном случае возникают проблемы. Печатать информацию о версии показателя в подвале еженедельного отчета в течение месяца может показаться педантичным, но это превращает вопрос «какой доход» из конфликта личностей в вопрос версии.
Запрос был идеальным, но значение — нет
Если дать современной модели схему данных вместе с вопросом о доходе, SQL-запрос обычно получается настолько аккуратным, что десять лет назад он показался бы впечатляющим. Однако риск уже не заключается в этом аспекте.
Доход не является отдельной столбцовой строкой. Даже одна компания может иметь зарегистрированные, выставленные счетами, доставленные и учтенные доходы, а также суммы, зафиксированные кассами до возвратов товаров. Кредитные записи могут компенсировать эти суммы, а могут и нет. Внутрикорпоративные продажи могут учитываться, а могут и не учитываться. «Нидерланды» могут означать страну выставления счета, страну доставки или организацию, ведущую учет по данному счету, а «прошлый месяц» — календарный месяц или финансовый период, заканчивающийся в воскресенье.
Ничто из сказанного не связано с синтаксисом JOIN. Даже стандартное объединение данных может дать неверный результат для принятия решений, от которых зависит дальнейшая деятельность.
Инвентарь ведет себя аналогичным образом. Наличные запасы не считаются запасами, которые можно обещать поставить, а запасы, которые можно обещать, не всегда становятся теми, что движок распределения фактически отпустит в электронную коммерцию сегодня вечером. Сотрудник, отвечающий «можем ли мы пообещать поставку в пятницу» на основе наличных количеств, может казаться компетентным, но всё равно оставить клиента в затруднительном положении.
В одном случае сотрудник заверил руководителя склада относительно определенного товара, поскольку суммировал значение qty_on_hand для всех складских мест, включая поврежденные контейнеры, хотя в планах уже было отмечено, что эти контейнеры непригодны для использования. SQL-запрос был корректным, но выводы были основаны на догадках. Руководитель сам проверял контейнеры ранее в тот же день, а у сотрудника была лишь таблица с данными.
Результаты мгновенной отчетности показывают ту же проблему. Отдел управления магазинами требует данные о тех сотрудниках, которые заканчивали работу у кассы до 16:00, а финансовый отдел — информацию о зафиксированных доходах после учета всех вычетов. На совещании обе стороны говорят «вчерашние продажи». Сотрудник, получив эту фразу, выбирает столбец с временной меткой и столбец с суммами и останавливается на этом, а споры начинаются уже после того, как появляется график.
Планирование ассортимента также сталкивается с аналогичными проблемами. Запросы клиентов отличаются от данных точек продаж, а данные точек продаж отличаются от чистых продаж после учёта возвратов. Тот или иной товар может отображаться как распроданный в системе планирования электронной коммерции, в то время как таблица, видимая для менеджера, всё ещё показывает наличие товара, поскольку в ней учитываются единицы, находящиеся в пути, единицы, находящиеся на контроле качества, а также количество товара, зарезервированное для оптовых поставок. Если менеджер будет отвечать на вопрос «У нас есть этот товар?» на основе неверных данных, компания к утру может дать чрезмерные обещания, а затем провести весь день, объясняя отсутствие товара, которого никогда не показывала таблица.
Называть это сбоем запроса — значит упускать суть, ведь запрос «У нас это есть?» был в порядке. Отсутствовал объект available_to_promise с четко определёнными параметрами: перечень мест хранения, типы запасов, исключаемые из учёта, количество запасов в процессе транспортировки и время, к которому ведётся отчёт. В отсутствие этого каждый пользователь вынужден самостоятельно организовывать свою цепочку поставок.
Именно поэтому привычный комфорт самообслуживающихся систем аналитики больше не работает. Десять человек, смотрящих один панельный инструмент, по крайней мере, имеют одни и те же неточные цифры. Десять сотрудников, каждый из которых формирует свой собственный запрос, кажутся логичными на местном уровне, но в итоге в организации возникает хаос из-за разногласий и отсутствия единой цифры.
Аналитик, не имеющий контекста, задаёт дополнительный вопрос. Сотрудник, не имеющий контекста, завершает предложение. На демо-версиях это казалось любопытным, но в реальных условиях это представляет опасность, поскольку та же самая инфраструктура, которая облегчала доступ к данным, также облегчала их запрос без необходимости согласования чего-либо.
За два десятилетия были созданы способы доступа к данным через хранилища, lakehouses, ELT, ноутбуки и API, поэтому теперь узкое место находится в другом. Вопрос о том, может ли программное обеспечение видеть таблицу, уже решён. Однако вопрос о том, может ли программное обеспечение самостоятельно определять смысл таблицы, остаётся открытым.
Что включает в себя контракт смысла
Глоссарий недостаточен, поскольку его можно просто неправильно интерпретировать, тогда как контракт либо выполняется, либо отклоняется. Операции, которые определяет пригодная для использования семантическая модель, — это те, по которым бизнес уже договорился:
- У признанной выручки есть точное определение, и определённые строки никогда не входят в её состав.
- Активным клиентом считается тот, кого определяет правило, а не интуиция.
- Отношения между клиентом и регионом — именно они являются основой для финансовой поддержки.
- Для этого показателя эффективности период определяется по дате счета, а не по дате заказа.
- Некоторые измерения допускаются к анализу по законным критериям, а остальные служат лишь декоративными элементами.
Под этим лежат показатели, измерения, иерархии, вычисляемые поля, метаданные и фильтры строк; не имеет значения, в файле какого поставщика они хранятся. Функционально речь идет о форме бизнес-языка, которую может использовать программное обеспечение. До недавнего времени основным инструментом использования был отчет. Новый инструмент никогда не устает, никогда не обращается к аналитику за помощью и не чувствует стыда за то, что может ошибаться с уверенностью.
Работа с данными о зерне — это то, что команды обычно пропускают, считая её чем-то вроде домашнего задания по моделированию, хотя на самом деле это ключевая часть API. Если ничего не определить, каждый пользователь будет создавать свои правила. Всё сводится к четырем вопросам, на которые необходимо ответить в одном месте:
- Какая дата завершает период.
- Какой объект описывается числом: организация-продавец, адрес доставки или адрес выставления счета.
- Какие строки исключаются: сотрудники, оптовые заказы, внутрикорпоративные заказы и тестовые заказы.
- Какие правила безопасности продолжают действовать, когда пользователем является агент.
Если эти ответы отсутствуют в модели, они оказываются в треде в Slack, то есть вообще нигде.
Показатель маржи показывает, как обстоят дела. Формула была правильной, но с датой были ошибки. Один из операторов использовал дату заказа, поскольку таблица фактов по умолчанию использовала именно её, а другой — дату счёта, так как финансовый отчёт тоже опирался на неё. Оба указывали «маржу», и их значения отличались на два пункта в течение недели из-за резкого повышения стоимости транспортировки. Вина возложили на оператора, хотя настоящей причиной была отсутствующая информация. Добавление даты счёта, правила учёта транспортных расходов и указание ответственного лица решили проблему, и показатели в следующей неделе совпали. Никто не поблагодарил модель, но сообщения прекратились.
Предусмотренный путь выполнения задачи по своей сути скучен: намерение, связывание, применение правил, выполнение, ответ. Модель ни в коем случае не принимает решение о том, что означает доход. Выбор подходящей сертифицированной метрики для ответа на вопрос допустим, поскольку это классификация. Сборка метрики из сырых данных представляет собой интерполяцию, и именно благодаря интерполяции появляются два официальных числа до того, как будет выпит первый кофе.
Логи операций рассказывают всю историю. Если агент выбирает столбцы по сходству названий, это значит, что он действует как собиратель информации. Если он вызывает функцию recognized_revenue с указанием периода и региона, это означает, что он использует официальные данные. Второй вариант логов менее «кинематографичен», но именно его следует предоставить при аудите.
Метаданные перестали быть документацией
Раньше описания добавлялись уже в последний момент, после выпуска панели управления, и только тогда, когда в спринте ещё оставались часы, что бывало редко. Метрика с названием [NS Adj LY %] считалась приемлемой, поскольку трое человек, редактировавших файл, знали его историю.
Агент не знаком с этими особенностями. В руководстве Microsoft по подготовке семантических моделей для данных агентов прямо говорится об этом: названия, описания, связи и снижение неоднозначности определяют качество ответа, и это верно даже вне данной технологической стека. Теперь именно эти строки являются обязательными входными данными. Отсутствие описания не мешает агенту дать ответ — оно просто связывается с какой-либо слухом.
Эти изменения легко недооценить, поскольку файл выглядит идентично: в нем по-прежнему есть модель с метриками. Изменился только потребитель: человек-разработчик делает выводы, тогда как агент связывает данные, причем даже небрежное связывание все равно приводит к ответу с приложенной диаграммой.
Теперь загадочное название метрики считается дефектом производства, так же как и недокументированная публичная функция. Никто бы не стал использовать fn_x3() в качестве API для выставления счетов, однако в течение десяти лет она считалась API для сбора метрик, потому что её просто использовали.
Платформы сделали одинаковую ставку
Если убрать брендовые цвета с страниц продуктов, проявляется определенный паттерн. Microsoft, Snowflake, Databricks и ThoughtSpot вкладывают средства в семантические слои, механизмы управления и то, что они называют надежным бизнес-контекстом. Их предложение — это не яркая демонстрация модели, генерирующей SQL-запросы.
Все они уверены, что модель должна рассуждать на основе сертифицированного значения, а не на основе той колонки, которая случайно находится ближе всего к слову в вопросе. Инструменты обработки данных в стиле Fabric, работающие в складских системах, lakehouse-решениях и семантических моделях Power BI, отражают эту точку зрения. То же самое касается аналитиков в стиле Cortex, которые предпочитают семантический подход вместо простого экспорта схемы, а также метрических показателей и каталогов, которые превращают KPI в объект платформы. Компания ThoughtSpot уже много лет продвигает концепцию «задавайте вопросы данным» через моделированный слой, и остальной рынок понял причины этого, как только программное обеспечение стало возможным инструментом для таких запросов.
Стратегия выбора самой умной модели и направления её работы на озеро противоречит направлению развития уже оплачиваемых платформ. Они вводят слой смыслового анализа перед озером, поскольку модели стали хорошо справляться с SQL; повышение уровня владения этим языком увеличивает стоимость возникновения разногласий, не устраняя их. Покупка ещё одного копилота не определяет понятие клиента — она создаёт лишь дополнительные поверхности, способные приводить к разногласиям.
Протокол не определяет доход
MCP также упоминается в этих же обсуждениях, и этот протокол иногда путают со стратегией. Однако он действительно имеет ценность. Возьмем, к примеру, агента данных Fabric, выпущенного в качестве сервера MCP — на момент последнего прочтения документации он все еще находился в предварительной версии: это показывает, что место, где вводится вопрос, не обязательно должно совпадать с местом, где хранится логика. Qlik и другие поставщики движутся в том же направлении, предоставляя управляемый аналитический инструмент помощникам, которые никогда не запускают оригинальное приложение. Место для задания вопросов и место для обработки информации могут быть разными.
Тем не менее сочетание протокола с каким-либо решением является неразумным, поскольку протоколы могут быть заменены. Основной принцип заключается в том, что смысл представляет собой сервис, а чат-бот — клиент.
Предоставление неструктурированного файла Power BI через MCP лишь перемещает эту беспорядочность в удаленное пространство. Агент в Claude, Copilot или внутреннем инструменте все равно будет подключаться к [NS Adj LY %], если именно это было опубликовано.
Безголовые системы аналитики уже сталкивались с этой проблемой. Команды создавали простой SQL-интерфейс над теми же недокументированными показателями, а затем винили нового клиента, когда цифры менялись. Протокол выполнял свою функцию, но то, что он передавал, представляло собой лишь народные представления, сопровождаемые сетевым маршрутом.
Поэтому протокол остается частью внутренних механизмов: поиска инструментов, передачи контекста, вызовов между процессами. Значение обрабатывается отдельно путем связывания показателей, отклонения недопустимых значений и применения механизмов безопасности строк. Отличные внутренние механизмы, основанные на определениях, которые никто не станет защищать перед финансовым отделом, по-прежнему остаются лишь народными представлениями, только с URL-адресом.
В прошлых дискуссиях по BI вопрос заключался в том, какой инструмент стоит стандартизировать. Когда агенты выступают в роли пользователей, более актуальным вопросом становится местоположение надежного аналитического контекста и кто из пользователей им может пользоваться. Отчетность может оставаться в одном продукте, в то время как агенты получают данные из управляемой модели, расположенной ближе к хранилищу, или наоборот. Неэффективно позволять каждому пользователю хранить собственную копию данных о доходах, а затем удивляться, когда цифры расходятся.
Панели управления стали лишь одним из пользователей среди многих
Раньше панели управления были единственными серьезными потребителями данных, но сейчас это уже не так. Долгое время считалось, что семантическая модель принадлежит только одному инструменту BI: модели Power BI использовались для формирования отчетов в Power BI, а модели LookML — для отчетов в Looks. Такой подход был разумным, пока единственными аудиториями были люди, а отчетами — конечным продуктом.
Сегодня один контракт может обслуживать панели управления, Excel, операционные приложения, помощников, чаты, агентов, а также функцию формирования заявок при выходе показателя за установленные границы. Панели управления остаются полезными, но уже не являются основной целью модели, поскольку график — это лишь один из пользователей этих определений.
Это полезное изменение. Графики быстро устаревают, тогда как определения дохода, маржи, заполненности и уровня оттока клиентов должны меняться медленно. При правильном управлении этими определениями новый помощник в следующем квартале не будет перезапускать процесс обработки данных, а агент, ищущий аномалии, сможет снова использовать тот же показатель для еженедельных отчетов. Именно в таком повторном использовании и кроется польза. Красивая панель управления, логика которой скрыта в визуальных показателях, бесполезна, поскольку к визуальным элементам невозможно обратиться напрямую.
Каждый отзыв вызывает возражения: если модели могут писать SQL, зачем тогда продолжать финансировать соответствующие меры, и почему бы не оставить это агентам? Агенты всё чаще способны справляться с этой задачей. Однако с бизнес-точки зрения именно эта способность приводит к проблемам. Доступ к данным стал дешевым, в то время как получение согласованных данных остаётся дорогостоящим. Десять сотрудников, наблюдающих один панель управления, делятся одним и тем же числом, даже если оно неверно, тогда как десять агентов, работающих на складе, формируют по десяти своих локальных версий фактов, каждая из которых представляется с такой же уверенностью.
Дешевая версия этого эксперимента наглядно это демонстрирует. Возьмем один склад, один вопрос и три конфигурации агентов без общих показателей — в результате получаем три цифры дохода и три объяснения того, почему именно они являются правильными. Один из подходов использовал информацию о бронированиях, поскольку в названии таблицы было слово order. Другой пересчитал наборы, ошибочно приняв структуру строк за заголовки. Третий приблизился к финансовым данным, используя дату счета, но все равно учел оптовые продажи. Любой из таких отчетов, опубликованный в треде для вице-президентов, привел бы к неделе споров о чат-боте, а не о самом определении.
Дешевый доступ без контракта позволяет большему числу людей, а теперь и агентам, создавать собственные «частные истины». Это объясняет, почему моделирование стало еще более важным, а не менее, особенно с улучшением генерации SQL-запросов.
Одной технологической стековой сборки недостаточно
Следующая ловушка, на которую стоит обратить внимание, — это семантический слой сувениров: сертификация в одном инструменте и фольклор во всех остальных. Команда может потратить год на создание отличной модели внутри BI-продукта, который все демонстрируют, а затем подключить агента непосредственно к складу, ссылаясь на то, что склад является источником истины. В итоге неопределенность просто переместилась. Дашборд отображает зафиксированный доход, агент сообщает значение net_amt, а финансовый отдел сохраняет свою таблицу. Организация приобрела еще один диалект, но без дополнительной ясности.
Проверить это легко: когда определение метрики не переносится от склада к BI-инструменту, а затем к агенту, просто меняется название метки, но спор остается актуальным.
Переносимость не требует наличия четвертой платформы. Важно лишь то, чтобы пользователь, находящийся вне исходного файла, мог выполнять ту же операцию и получать те же данные. Этим объектом может быть метрический объект, специфичный для конкретного хранилища и поддерживаемый всеми движками, безголовый сервис метрик или строго регулируемая семантическая модель, к которой можно получить доступ через API-запрос или адаптер MCP. Простой тест поможет разобраться: измените определение один раз и посмотрите, будет ли каждый пользователь его соблюдать. То, что остается без изменений, является копией.
Метрики, специфичные для хранилища, кажутся привлекательными, когда большая часть данных находится на одной платформе, но у них есть известный недостаток. Определение сертифицировано именно для этого места, и агент, работающий с другим хранилищем или репликой, никогда с ним не столкнется. Федеративные подходы пытаются сохранить единое значение во всех движках, но они терпят неудачу, когда так называемый универсальный слой превращается в еще одну копию с более красивым форматом YAML.
Немного уродливый портативный метрический инструмент лучше красивого, находящегося в файле, который могут скомпилировать только три разработчика, потому что агенты не будут ждать этого файла. Они будут искать альтернативы.
Как выглядит модель, готовая к использованию агентами
Большинство моделей, которые наследуются, были созданы для людей, уже знакомых с корпоративными сплетнями. Разработчик понимает, почему выражение типа set-analysis приводит к потере канала; агент, видящий только результат, этого не понимает. Мера DAX с смешным названием может служить своего рода личным сигналом, но для того, кто пытается её использовать, она кажется шумом. В одном реальном файле использовалось обозначение [NS Adj LY %] для обозначения чистых продаж с корректировками за прошлый год, процентного изменения, за вычетом оптовых продаж и факторов, неприемлемых для финансового отдела временных магазинов. Трое человек могли расшифровать это обозначение, а четвертый читатель был агентом, который интерпретировал NS как чистые продажи и не продолжал анализа дальше.
Этот чек-лист не является чем-то необычным. Это традиционные методы BI с более высокими последствиями за небрежность:
- Четкие названия. Используйте термины, которые уже применяются в компании, поэтому
recognized_revenueпредпочтительнееNS_Adj. Если две команды используют разные термины, выберите один для модели и укажите другой в описании в качестве алиаса, вместо того чтобы скрывать разногласия с помощью аббревиатур. - Положения об использовании. Укажите, в каких случаях применима данная метрика — например, что она подходит для отчетов совета директоров, не подходит для данных о продажах в одних и тех же магазинах и не учитывает оптовые продажи. Раньше это было необязательно, но теперь такой пункт помогает отличить точные данные от догадок.
- Заявленные связи. Клиент, счет-фактура и подписка должны быть явно связаны между собой, чтобы сотрудник не пытался самостоятельно установить связь, если два идентификатора называются
cust_id. - Небольшая площадь отображения. Каждая оставленная видимой техническая колонка — это возможность пропустить соответствующий показатель. Необходимо скрывать первоначальные данные, которые звонящие не должны повторно агрегировать. Это сложно с политической точки зрения, но это стоит делать, потому что API, который открывает доступ ко всем приватным полям, не является настоящим API.
- Владельцы и версии. Необходимо указать, какие показатели являются официальными, а какие — экспериментальными, кто их изменяет, и что означает «v3», если в письме совета директоров прошлого квартала использовалась версия v2.
- Безопасность при передаче данных. Агент никогда не должен иметь возможности получить доступ к более широкому набору строк, чем тот, который виден при использовании стандартного отчета. Когда правила на уровне строк существуют только в сервисе BI, в то время как агент обращается непосредственно к хранилищу данных, это приводит к обходу правил, а не к их исполнению.
Рассмотрим показатель recognized_revenue у ритейлера. Его формула заключается в сумме счета-фактуры за вычетом кредитов, пересчитанной из валюты операции по учетному курсу на дату выставления счета-фактуры. Основой для расчета является дата счета-фактуры вместе с информацией о организации-продавце, а не о месте доставки. В его расчет не включаются магазины, находящиеся в собственности сотрудников, оптовые продажи, тестовые заказы и внутрикорпоративные продажи. Законодательно определяемыми параметрами являются организация-продавец, иерархия продуктов и канал продаж в соответствии с типом заказа; таблица маркетинговых параметров «последний клик» не используется. За этот показатель отвечает финансовый контролер, причем используется та версия, которая была предоставлена в письме для совета директоров в прошлую пятницу.
Предположим, агент запрашивает «продажи через Instagram». Такой показатель в этой метрике отсутствует, поэтому правильным ответом является отказ или передача запроса на рассмотрение другой сертифицированной метрики, находящейся в ведении отдела маркетинга. Специалист по обработке данных мог бы объединить эти данные с таблицей последнего клика и оформить полученный результат в виде аналитической информации. Такое объединение может быть технически корректным, однако оно отражает ситуацию другой компании.
Отказ лучше, чем молчание, а молчание — лучше, чем личное определение показателей. Командам не нравится создавать отказы, потому что это ухудшает внешний вид демонстраций, но демонстрации, в которых возникают сбои, более точно отражают реальную работу компании.
Здесь не используется никаких трюков с ИИ. Всю работу выполняют старые методы аналитики данных, те самые, которые раньше использовались для формирования структуры данных и управления ими. Изменился лишь потребитель: раньше небрежность приводила к созданию некорректных панелей управления, которые кто-то мог заметить, а теперь она приводит к неправильным действиям с высокой скоростью.
Работа, которая не исчезает
Если всё будет работать, очередь заявок действительно сократится. Запрос на разделение данных по регионам может быть обработан сотрудником, если регион является законной категорией для данного показателя. Запрос на добавление данных за прошлый год относится к вопросам анализа временных рядов, которые либо уже были учтены ранее, либо вообще не учитывались.
Было бы неправильно говорить команде BI, что у неё исчезла работа, ведь она лишь переместилась. Кто-то всё равно должен определять, что означает каждый KPI и какова его официальная версия. Кто-то должен решать, какие связи являются корректными, каким источникам можно доверять и какие исключения применимы. Также кто-то отвечает за то, кто может просматривать те или иные строки, какие модели считаются авторитетными, как проверяются изменения, а также как в процессе анализа отражаются цепочки зависимостей и ответственность.
Эта работа менее увлекательна, чем создание качественных визуальных элементов, и большинство недель более соблазнительно заниматься публикацией графиков. Тем не менее её долгосрочная ценность остаётся невысокой. Визуальные элементы можно использовать один раз, тогда как определение, которое могут понять как сотрудники руководства, так и агенты, работающие ночью, является ценным активом.
Ожидайте меньшего количества запросов в духе «пожалуйста, сделайте интерфейс графическим» и большего количества споров в духе «пожалуйста, действуйте как законодательный орган». Те, кто хотел лишь создавать графики, могут посчитать этот период понижением в должности. Те же, кто хотел, чтобы цифры оставались точными при взаимодействии с программным обеспечением, обнаружат, что эта непризнанная работа стала основной задачей.
Часто встречающиеся способы сбоев
Эти проблемы постоянно регистрируются как проблемы качества модели, и перед заменой модели необходимо проверить её качество.
- Сборщик данных из столбцов. Агент берет первое поле с именем
rev. Никакие метрики не вызываются, хотя визуально процесс кажется активным. - Приватные данные. Каждый вызывающий выбирает свою дату и уверен, что правильно указал «прошлый месяц».
- Контракт вики. Фактическое правило записано на странице Confluence, к которой никто не притрагивался с момента реорганизации, а сама модель содержит лишь комментарий к столбцу с надписью «sales».
- Сувенир из стека. Единственная сертифицированная метрика хранится в файле BI, и агент взаимодействует с складом, поскольку это был самый простой способ демонстрации.
selling_org. Дашборд, который обычно использовал этот менеджер, отклонил бы такой запрос. Агент казался более эффективным, поскольку смог обойти единственный механизм контроля.Если два из этих примеров кажутся вам знакомыми, использование чат-ботов для оценки не должно быть первым шагом. Сначала определите метрику и укажите её уровень детализации в модели, затем потребуйте от агента её использования, и только после этого начинайте сбор данных.
Краткий тест для проверки: запросите данные о доходах прошлого месяца, затем уточните детали. Какой столбец с датами был использован? Какие исключения были применены? Учитывались ли покупки сотрудников? Агент, который вынужден выдумывать ответы, на самом деле является генератором SQL, имеющим к этим данным доступ.
Второй тест заключается в изменении официального списка исключений, например, путем окончательного исключения покупок сотрудников из списка признанных доходов, после чего проверяется, кто в тот же день вносит изменения. Если панель управления меняется, а агент остается без изменений, это означает, что на самом деле API представляет собой вручную скомпилированный файл, а агент — всего лишь посетитель.
Также обратите внимание на «полезного» агента, который тихо добавляет элемент объединения, когда у сертифицированной метрики отсутствует измерение. Именно в этот момент контракт теряет силу. Правильным подходом будет указать, что такого измерения у данной метрики нет. Менеджерам продуктов не нравится такая формулировка, но это лучше, чем письмо совету директоров, которое придётся отозвать.
Не начинайте с чат-бота
Большинство программ начинаются с очевидных вопросов: какая модель, какая база векторных данных, следует ли использовать MCP, сколько мест для копилотов нужно купить. Если цель — получение надёжных ответов о конкретной компании, лучше использовать более прямолинейный подход к началу работы.
Где определяется доход в программном обеспечении для форм? Какая классификация клиентов считается авторитетной? Где сейчас находится логика расчёта валовой маржи: в SQL-просмотре, метрике DAX, выражении Qlik, в блокноте или в памяти отдельного человека? Ответ «несколько из перечисленного» означает, что основная проблема не в генерации данных. Интерфейс, с которым будет работать программное обеспечение, так и не был создан.
Практическая последовательность действий выглядит следующим образом:
- Выявите спорный момент. Выберите одну метрику, по которой уже спорят две команды, без необходимости в сложной онтологии.
- Составьте контракт: формулу, уровень детализации, исключения, ответственного лица и допустимые размерности.
- Обеспечьте доступ к этой информации через единственный защищённый путь запросов, который могут использовать как отчёты, так и агенты.
- Добавьте пользователя-запрашивающего, и только на этом этапе внедрите помощника или агента для работы с этой метрикой.
Без указания на официальную процедуру учета доходов чат-бот создает проблему семантики, название которой никто не выдвинул.
Однажды команде нужно было представить инструмент планирования перед следующим советом управления, и в течение первых двух недель они намеренно откладывали его использование. Работа по этому инструменту была включена в параметр available_to_promise, правила которого были записаны на одной странице. Запасы, находящиеся на контроле качества, не учитывались, как и поврежденные коробки. Количество единиц, готовых к хранению, учитывалось только для оптовых заказов, а единицы в пути — только после получения ASN. Эти правила были включены в модель, уже используемую на складе, и при ответах на вопросы об запасах чат-боту разрешалось использовать именно этот показатель, ничего более. Первая демонстрация прошла тише. Ко второй неделе никто больше не приводил третьи цифры на собраниях, что считалось успехом, а поставщик модели остался прежним.
Панели управления остаются в использовании. Хорошо спроектированное визуальное представление по-прежнему лучше передаёт еженедельную картину, чем сообщение в формате чат-буллы. Они просто перестали быть единственным инструментом для отображения информации, и теперь один и тот же контекст должен оставаться актуальным при обращении к нему как человеком, так и в рамках отчёта, а также автоматизированным процессом, который не сможет заметить, если данные неверны.
Существующий интерфейс
Брифинг с двумя официальными цифрами объясняет всё. Модели не путались в каком-либо значимом смысле. Путались сами организации, и сотрудники переносили эту путаницу в формулировки, которые казались проявлением знаний.
Когда программное обеспечение начинает использовать сертифицированное описание того, как компания воспринимает свои данные, таблицы перестают быть интерфейсом, и их заменяют указанные показатели.
Просьба к сотруднику быть осторожным с показателями дохода быстро забывается. Остаётся модель, которая никогда не позволяет воссоздавать данные дохода ad hoc.
То, что будет опубликовано, — это то, что выберет агент. Если предоставить необработанные таблицы, это станет основой бизнеса; если указать конкретную операцию, возможно, в итоге будет выбрана та, которую уже определили аналитики.
Яркие решения по-прежнему привлекательны: например, помощник, отслеживающий аномалии в 6 утра, или агент, создающий заявку, когда уровень готовности снижается. Они остаются надежными лишь в том случае, если работают с теми же операциями, которые уже согласовали люди.
Начните с показателя, по которому уже идут споры, и сформулируйте четыре вопроса, связанных с ним. Настройте один панель управления и одного агента для работы с этим объектом, оставив остальное без изменений, пока оба инструмента не согласятся на его использование в течение месяца. Затем расширяйте каталог.
Связанные материалы
- Что на самом деле запускает нейронную сеть: компиляторы ИИ, скрытые за Python — Проследите путь модели от выражения на Python через графы вычислений, слияние операторов, представления в стиле MLIR и преобразование в код для CPU, GPU и ускорителей.
- Семантический поиск в PostgreSQL с использованием pgvector и Node.js без необходимости в LLM — Создайте поиск, основанный на смысле, внутри PostgreSQL с помощью pgvector, эмбеддингов MiniLM и Node.js: токены, фрагменты, векторы, индекс IVFFlat, операторы расстояний и способы чтения оценок.