Ваша семантична модель — це 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. Класичний операція JOIN все одно може дати неправильну відповідь для рішення, від якого залежить результат.
Інвентар також поводиться аналогічно. Наявні запаси не є тими, що можна обіцяти клієнту, а те, що можна обіцяти, — це не те, що двигун розподілу насправді відпустить для електронної комерції сьогодні ввечері. Агент, який відповідає «чи можемо ми пообіцати доставку у п’ятницю», спираючись на кількість товару на складі, може здаватися професійним, але все одно залишити клієнта у скрутному становищі.
У одному випадку агент запевнив керівника складу щодо певного стилю товару, оскільки підсумував значення qty_on_hand у всіх місцях зберігання, включаючи пошкоджені контейнери, хоча планувальники вже позначили ці контейнери як непридатні до використання. SQL-запит був бездоганним, але його зміст був лише припущенням. Керівник особисто перевіряв ці контейнери раніше того ж дня, тоді як у агента була лише таблиця з даними.
Тимчасові звіти показують ту саму різницю. Відділ магазинів хоче отримати дані про ті операції, які були здійснені до 16:00, а фінансовий відділ — інформацію про визнані доходи після зняття кредитів. На нараді обидві сторони кажуть „вчорашні продажі“. Працівник, отримавши цю фразу, обирає стовпець з часом та стовпець з сумою грошей та зупиняється, а суперечка починається після того, як з’являється діаграма.
Планування асортименту також містить таку саму підступність. Попит відрізняється від даних з точок продажу, а дані з точок продажу відрізняються від чистих продажів після врахування повернень. Той чи інший стиль може відображатися як розпроданий у системі обіцянок електронної комерції, тоді як таблиця, видима для агента, все ще вказує на наявність запасів, адже вона також враховує одиниці, що знаходяться у транспортуванні, товари, що знаходяться на контролі якості, та кількість, призначену для пакування та зберігання з метою подальшої оптової реалізації. Якщо агент відповість на запитання „Чи є у нас цей товар?“ на основі неправильних даних, компанія до ранку дасть неправдиві обіцянки, а потім проведе весь день, пояснюючи брак запасів, якого ніколи не відображала таблиця.
Називати це невдачею запиту — це не враховує суті справи, адже запит „Чи у нас це є?“ був у порядку. Бракувало об’єкта available_to_promise із чітко визначеними параметрами: набір місцезнаходжень, типи заборонених замовлень, підрахунок запасів у процесі транспортування та час зрізу, який він відображає. Без цього кожен користувач самостійно створює власну ланцюгову структуру постачання.
Ось чому старий комфорт самообслуговування в BI більше не діє. Десять людей, які дивляться один панельний інтерфейс, принаймні мають однакові неточні цифри. Десять співробітників, які пишуть по десять приватних запитів кожен, здаються локально обґрунтованими, але в результаті організація залишається з хаосом розбіжностей та відсутністю точних даних.
Аналітик, якому бракує контексту, ставить додаткове запитання. Агент, якому бракує контексту, доповнює речення. У демо-версіях це було цікавим явищем, але в реальних умовах це становить небезпеку, адже та сама інфраструктура, яка полегшувала доступ до даних, також полегшувала їх запитування без необхідності узгодження чогось.
Два десятиліття було витрачено на те, щоб зробити дані доступними через віртуальні сховища, ELT, нотбуки та API, тож тепер вузьке місце знаходиться в іншому. Питання про те, чи може програмне забезпечення бачити таблицю, вже вирішене. Проте питання про те, чи може програмне забезпечення вирішувати, що означає таблиця, — ні.
Що передбачає контракт значення
Глосарій є недостатнім, оскільки його можна просто неправильно прочитати, тоді як контракт або виконується, або відхиляється. Операції, які називає придатна семантична модель, — це ті, щодо яких бізнес вже досяг узгодження:
- Уявлений дохід має точне визначення, і певні рядки ніколи не є його частиною.
- Активного клієнта визначають за правилом, а не за інтуїцією.
- Саме стосунки між клієнтом та регіоном є тими, за які фінансовий відділ готовий відповідати.
- Для цього KPI період визначається за датою інвойсу, а не за датою замовлення.
- Деякі параметри дозволені до використання для аналізу, а решта є лише декоративними.
Під цим лежать показники, параметри, ієрархії, обчислювані поля, метадані та фільтри рядків, і не має значення, у файлі якого постачальника вони знаходяться. Функціонально це є частиною бізнес-мови, яку може використовувати програмне забезпечення. До недавнього часу основним інструментом для її використання був звіт. Новий інструмент ніколи не набридає, ніколи не звертається до аналітика та не відчуває сорому через помилки.
Обробка даних про зерно — це те, що команди ігнорують, оскільки це нагадує домашнє завдання з моделювання, проте саме це є ключовою частиною 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 %], якщо саме це було опубліковано.
Безголові системи BI вже проходили через це. Команди створювали простий 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 %] для позначення чистих продажів, скоригованих, за минулий рік, у відсотках, з вирахуванням оптових продажів та фінансових факторів, які не подобаються магазинам типу pop-up. Його могли розшифрувати троє людей, а четвертий читач був агентом, який розумів NS як чисті продажі та не продовжував аналізувати далі.
Цей чек-лист не є чимось екзотичним. Це стара практика BI з вищою ціною за недбалість:
- Чесні назви. Використовуйте термінологію, якою вже користується бізнес, тож
recognized_revenueбуде кращим варіантом, ніжNS_Adj. Якщо дві команди використовують різні слова, оберіть одне для моделі та задокументуйте інше як псевдонім у описі, замість того щоб приховувати розбіжності за допомогою скорочень. - Умови використання. Вкажіть, де застосовується показник — наприклад, примітку про те, що він підходить для звітів ради директорів, не підходить для тимчасових даних про магазини та не враховує оптові продажі. Раніше цей пункт був необов’язковим, але тепер він допомагає відрізнити точні дані від припущень.
- Оголошені зв’язки. Клієнт, рахунок-фактура та підписка мають бути прямо пов’язані, щоб агент не мусив шукати способи об’єднання даних через те, що два ідентифікатори називаються
cust_id. - Невелика поверхня. Кожен видимий технічний стовпець — це можливість пропустити певну метрику. Приховайте первинні дані, які абоненти не повинні знову обробляти. Це складно з політичної точки зору, але варто це робити, адже API, яке відкриває доступ до кожного приватного поля, не є справжнім API.
- Власники та версії. Вкажіть, які метрики є офіційними, а які — експериментальними, хто їх змінює, та що означає „v3“, якщо у листі правління минулого кварталу використовувалась версія v2.
- Безпека під час передачі даних. Агент ніколи не повинен мати можливості отримати доступ до більшого набору рядків, ніж бачить користувач у стандартному звіті. Коли правила на рівні рядків існують лише у сервісі BI, тоді як агент звертається безпосередньо до сховища даних, це призводить до обхідних шляхів, а не до функцій помічника.
Розглянемо recognized_revenue у ритейлері. Його формула — це сума рахунку-фактури за вирахуванням кредитів, перерахована з валюти операції за курсом бухгалтерського обліку на дату видачі рахунку-фактури. Важливою є дата рахунку-фактури, а не адреса отримувача. Цей показник не враховує магазини, що належать співробітникам, оптові продажі, тестові замовлення та міжкомпанійські продажі. Законодавчі критерії — це організація-продавець, ієрархія продуктів та канал, визначені типом замовлення; таблиця маркетингових даних «останній клік» не враховується. Відповідальним за цей показник є фінансовий керівник, а версія — та, яка була надана у листі до ради директорів минулої п’ятниці.
Припустимо, агент просить інформацію про „продажі через Instagram“. Цього показника немає в цій метриці, тому правильною відповіддю є відмова або передача запиту на розгляд іншої сертифікованої метрики, якою керує відділ маркетингу. Фахівець з аналізу даних міг би використати таблицю останнього кліку та позначити отриманий результат як корисну інформацію. Таке поєднання може навіть бути технічно коректним, проте воно описує ситуацію в іншій компанії.
Відмова краща за мовчання, а мовчання — краще за приватне визначення. Командам не подобається створювати відмови, оскільки це погіршує вигляд демонстрацій, але демонстрації, які провалюються, точно відображають реальну роботу компанії.
Тут не використовуються жодні трюки ШІ. Усю роботу виконує стара практика аналітики даних, та сама, яка раніше виправдовувала наявність певних структур та керувала моделями даних. Змінився лише споживач: раніше недбалість призводила до створення неправильних панелей керування, які хтось міг помітити, а тепер — до неправильних дій зі швидкістю машини.
Робота, яка не зникає
Якщо це спрацює, частина черги з заявками дійсно скоротиться. Запит на розділення даних за регіоном може бути оброблений агентом, якщо регіон є законною вимірною характеристикою цього показника. Запит на додавання даних за минулий рік є питанням аналізу часових даних, яке або вже було опрацьоване раніше, або взагалі не існує.
Було б неправильно казати команді з аналітики даних, що її робота зникла, адже вона лише перемістилася. Хтось все одно має визначати, що означає кожен KPI та яка є офіційна версія даних. Хтось має вирішувати, які зв’язки є правильними, які джерела заслуговують на довіру та які є винятки. Також хтось відповідає за те, хто бачить які рядки, які моделі вважаються авторитетними, як перевіряються зміни та як у процесі перевірки відображаються ланцюжки залежностей та власники даних.
Ця робота менш цікава, ніж гарно оформлений візуальний елемент, і більшість тижнів більше спокушає надіслати графік. Проте її кумулятивна цінність залишається низькою. Візуальні елементи є одноразовими, тоді як визначення, яке можуть використовувати як члени ради, так і агенти, є цінним активом.
Очікуйте менше запитів у стилі „будь ласка, створіть GUI“ та більше суперечок у форматі „будь ласка, дійте як законодавчий орган“. Люди, які хотіли лише створювати графіки, можуть вважати цей період зниженням у посаді. Ті, хто хотів, щоб цифри залишалися точними під час роботи програмного забезпечення, побачать, що ця невдячна робота стала основною обов’язком.
Способи збоїв, які постійно повторюються
Їх постійно фіксують як проблеми з якістю моделі, і її структуру варто перевірити перед тим, як хтось замінить модель.
- Збирач стовпців. Агент бере перше поле з іменем
rev. Жодна метрика не викликається, хоча трек виглядає активним. - Приватне зерно. Кожен користувач обирає власну дату та переконаний, що правильно відповів „минулого місяця“.
- Контракт wiki. Фактичне правило записане на сторінці Confluence, до якої ніхто не торкався з моменту реорганізації, а сама модель має лише примітку до стовпця з написом „sales“.
- Сувенір стеку. Єдина сертифікована метрика знаходиться у файлі BI, і агент спілкується з складом, оскільки це був найпростіший шлях для демонстрації.
selling_org. Дашборд у понеділок, який менеджер зазвичай використовував, відхилив би це запитання. Агент здавався більш здатним, оскільки зміг обійти єдиний механізм контролю, який враховував дані.Якщо два з цих пунктів здаються вам знайомими, оцінка за допомогою чат-ботів не повинна бути першим кроком. Спочатку необхідно визначити показник та вказати його рівень деталізації в моделі, потім зажадати від агента, щоб він його використовував, і лише після цього починати вимірювання.
Швидкий тест для перевірки: запитайте про дохід минулого місяця, а потім дізнайтеся деталі. Яку колонку дат воно обрало? Які ексклюзії були включені? Чи були враховані покупки співробітників? Агент, який змушений вигадувати відповіді, — це генератор SQL, який випадково має доступ.
Другий тест полягає у редагуванні офіційного списку ексклюзій, наприклад, шляхом остаточного видалення покупок співробітників із списку визнаного доходу, а потім перевірки, хто оновлює дані в той самий день. Якщо панель керування змінюється, а агент залишається нерухомим, це означає, що справжнім API є ручно скомпільований файл, а агент — лише турист.
Також зверніть увагу на „корисного“ агента, який тихо додає параметр приєднання, коли сертифікована метрика не має виміру. Саме в цю мить контракт втрачає силу. Правильною поведінкою є повідомлення про те, що ця метрика не має відповідного виміру. Менеджерам продуктів не подобається така формулювання, але це краще, ніж лист до ради директорів, який доведеться відкликати.
Не починайте з чат-бота
Більшість програм починаються з очевидних інструментів: яка модель, яка база даних векторів, чи використовувати MCP, які місця для копілота купувати. Якщо метою є надійні відповіді щодо конкретної компанії, краще використовувати більш прямолінійний підхід.
Де визначається дохід у програмному забезпеченні для форм? Яка класифікація клієнтів є авторитетною? Де зараз знаходиться логіка валової маржі: у SQL-перегляді, мірці DAX, виразі Qlik, нотатках чи в пам’яті окремої особи? Відповідь «кілька з цих варіантів» означає, що основна проблема полягає не у генерації даних. Інтерфейс, з яким має працювати програмне забезпечення, ніколи не створювався.
Практична послідовність дій виглядає так:
- Визначте проблему. Виберіть один показник, щодо якого вже існують суперечки між двома командами, без необхідності створення складної онтології.
- Складіть контракт: формулу, деталізацію, виключення, власника та допустимі параметри.
- Забезпечте доступ до цих даних через єдиний захищений шлях запиту, який можуть використовувати як звіти, так і агенти.
- Додайте особу, яка викликає запит, і лише тоді додайте помічника чи агента для роботи з цим показником.
Без посилання на офіційну процедуру обліку доходів чат-бот рекламує проблему семантики, яку ніхто не назвав.
Одній команді довелося підготувати копілот для планування перед наступним комітетом керування, і протягом перших двох тижнів вони навмисно відклали його вбік. Робота була внесена до поля available_to_promise, а його правила були записані на одній сторінці. Запаси, що знаходились на контролі якості, не були враховані, так само як і пошкоджені коробки. Кількості товару для пакування враховувалися лише для оптових замовлень, а одиниці, що перебували у транспортуванні, — лише після отримання ASN. Ці правила були включені до моделі, яку вже використовувала складська служба, і при відповідях на запитання щодо запасів копілот міг використовувати саме цей показник, а ніякий інший. Під час першої демонстрації все було тихіше. До другого тижня ніхто більше не вносив третю цифру під час нарад, що було успіхом, а постачальник моделі залишився незмінним.
Панелі керування залишаються. Добре спроєктований візуальний елемент все ще краще передає тижневу структуру, ніж чат-бульбашка. Вони просто перестали бути єдиним місцем отримання інформації, і тепер один і той самий контекст має бути зрозумілим як при зверненні людини, так і при отриманні звіту чи автоматизованого процесу, який не помітить, якщо дані будуть неправильними.
Інтерфейс, який вже існує
Брифінг із двома офіційними цифрами пояснює все. Моделі не були заплутані у жодному цікавому сенсі. Заплутаною була організація, і співробітники перенесли цю плутанину у речення, які звучали як знання.
Коли програмне забезпечення починає використовувати сертифікований опис того, як компанія сприймає свої дані, таблиці перестають бути інтерфейсом, а замість них з’являються позначені показники.
Запит до співробітника про обережність із доходами швидко зникає. Те, що залишається, — це модель, яка ніколи не дозволяє доходи відновлювати спонтанно.
Усе, що оприлюднюється, — це те, що буде названо агентом. Якщо оприлюднити сирі таблиці, це стане основою бізнесу; якщо оприлюднити названу операцію, можливо, нарешті буде обрана та, яку вже обрали аналітики.
Яскраві інструменти все ще мають привабливість: ко-пілот, який відстежує аномалії о 6 ранку, або агент, який створює заявку, коли рівень доступності знижується. Вони залишаються чесними лише щодо тих самих операцій, які вже були схвалені людьми.
Почніть з показника, щодо якого вже ведуться суперечки, та сформулюйте чотири запитання щодо нього. Направте один панельний інструмент та одного агента на цей об’єкт, залишивши решту недоторканою, доки обидва інструменти не домовляться протягом місяця. Пізніше розширюйте каталог.
Пов’язана література
- Що насправді керує нейронною мережею: компілятори ШІ під Python — Простежте шлях моделі від виразу на Python через графи обчислень, злиття операторів, IR у стилі MLIR та перетворення на код для CPU, GPU та прискорювачів.
- Семантичний пошук у PostgreSQL за допомогою pgvector та Node.js без необхідності LLM — Створіть пошук, заснований на значеннях, усередині PostgreSQL за допомогою pgvector, ембеддингів MiniLM та Node.js: токени, фрагменти, вектори, індекс IVFFlat, оператори відстані та способи читання оцінок.