Пратьюша Дуввури (Pratyusha Duvvuri) — технический руководитель команды инженерного обеспечения ИИ в Cisco, которая разрабатывает архитектуры токеномики и наблюдаемости, помогающие корпоративным командам масштабировать использование ИИ с обеспечением прозрачности и подотчетности.
В предыдущей статье мы показали, как токеномика стала неотъемлемой частью управления расходами на ИИ в масштабе предприятия. Вот как мы внедрили ее на практике, ориентируясь на людей, которые действительно ею пользуются.
Проблемы обеспечения видимости расходов на ИИ
По мере ускорения внедрения ИИ в Cisco обеспечение видимости расходов стало критически важным. Нам потребовалось более четкое представление о том, куда уходят средства и кто стимулирует внедрение ИИ, с финансовым контролем, подотчетностью по бюджетам и меньшим количеством неожиданностей по мере роста использования. Сотрудники пробовали новые инструменты для написания кода, команды находили новые способы их применения, а расходы росли у нескольких провайдеров. Мы видели, как быстро расходуются бюджеты, но не могли увидеть полную картину, стоящую за этими затратами. Именно поэтому токеномика является для нас ключевым приоритетом в Cisco, и именно поэтому статус «клиента ноль» для Splunk Agent Observability имеет столь важное значение.
Чтобы внедрить токеномику на практике, нам нужно было решить несколько фундаментальных проблем. У каждого провайдера была собственная панель управления, показывающая лишь один срез нашего использования. Мы не могли надежно связать изменения затрат с людьми, командами или бизнес-группами, которые их вызывают, из-за чего было сложно объяснить скачок расходов, спланировать следующий бюджет или понять рост внедрения. Настоящей проблемой была атрибуция: отслеживание каждого доллара до конкретного человека, команды и бизнес-функции.
- Кроме того, провайдеры отчитываются по-разному. Некоторые из наших провайдеров используют прямые затраты и подсчет токенов; другие используют кредиты, рабочие места или лимиты. Кроме того, данные о затратах и внедрении часто поступали из разных API с разными отчетными периодами, из-за чего общая сумма на панели управления провайдера временно отличалась от суммы, доступной через его API, пока данные сверялись.
- Cisco предоставляет нам сложную среду «клиента ноль» с глобальным штатом примерно в 90 000 сотрудников и тысячами инженеров, использующих инструменты ИИ для написания кода у пяти провайдеров. Такой масштаб влечет за собой более сложные иерархии управления и финансов, большее разнообразие удостоверений личности и вопросы отчетности, которые могут не возникать в ходе контролируемого пилотного проекта.
- Фрагментированные и разнообразные источники данных из различных функций и ролей. Токеномика — это ответственность не какой-то одной роли, а поистине совместная работа, в которой задействованы несколько участников. Проблема заключалась не только в фрагментации; дело было в том, что разнообразные источники данных нужно было не просто централизовать, но и предоставить в таком виде, который был бы удобен для каждой конкретной функции и роли. Например, аналитика, необходимая финансовому аналитику, управляющему центром затрат, сильно отличается от аналитики руководителя инженерного подразделения, стимулирующего внедрение ИИ.
Три роли, необходимые для токеномики
Чтобы создать решение, которое адекватно обслуживает людей, использующих его, нам нужно было начать с основ: кому нужны эти данные и зачем они им нужны?
Мы определили три основные роли, каждая из которых имеет свои отличительные потребности и требования:
- Сотрудникам необходимо знать, сколько они лично используют у разных провайдеров, на какие инструменты и модели они опираются и как меняется это использование. Личная видимость помогает сотрудникам планировать собственное использование и делать выводы на основе своих привычек.
- Менеджерам необходим обзор, который позволяет ответить на вопросы, ориентированные на команду: внедряет ли ИИ вся команда или только несколько человек? Какие провайдеры приводят к затратам, и приносит ли это использование измеримую ценность с точки зрения производительности? Нужен ли кому-то дополнительный доступ или части команды требуется больше рекомендаций о том, с чего начать? И что немаловажно, трансформируются ли расходы на токены в бизнес-результаты?
- Финансовому отделу нужен совершенно иной ракурс, поскольку их организационные структуры редко совпадают с линиями отчетности инженерных менеджеров. Чтобы преодолеть этот разрыв, финансовому отделу требуется специальное представление, позволяющее видеть, какие части бизнеса стимулируют расходы на ИИ, как затраты соотносятся с существующими бюджетами, а также атрибуция, необходимая для оценки инвестиций в ИИ и объяснения непредвиденных колебаний.
Эти конкретные роли и их требования определили то, как мы создавали решение.
Создание продукта для реальных пользователей в реальном времени
При создании решения мы не начинали с многомесячного сбора требований или контролируемого лабораторного пилотного проекта. Мы провели стресс-тестирование работающего программного обеспечения с IT-отделом и финансовым департаментом Cisco с двухнедельными интервалами. Их отзывы помогли нам понять, что нужно каждой роли, и сформировали как сам пользовательский опыт, так и стоящую за ним технологию.
Такой итеративный подход, ориентированный на обратную связь, позволил нам проверить, выдерживает ли продукт реальные корпоративные ограничения. Полученные уроки легли в основу приведенных ниже этапов.
Этап первый: Унификация данных провайдеров
Наш первый этап был сосредоточен на создании консолидированного представления по пяти провайдерам, что позволяло пользователю переключаться между затратами и внедрением, отслеживать тенденции затрат за выбранный период, сравнивать провайдеров и модели, а также исследовать пользователей, стоящих за изменениями. Это дало нам централизованный способ ответить на вопросы: сколько мы тратим и используют ли люди доступные им инструменты?
Объединение пяти провайдеров в одно представление было только началом. Каждый провайдер по-своему определяет использование. Например, один может сообщать о токенах и прямых затратах, другой — о кредитах или рабочих местах, а третий может вообще отделять активность от выставления счетов. Их отчетные периоды не всегда совпадают, и итоговые суммы могут продолжать меняться по мере того, как провайдеры сверяют свои собственные данные. Таким образом, цифра может быть точной на панели управления одного провайдера и при этом вводить в заблуждение, если поставить ее рядом с цифрой другого провайдера.
Нам нужен был общий обзор, который делал бы возможным сравнение, не стирая при этом различий, объясняющих смысл этих цифр. Затраты и внедрение остаются раздельными, поскольку активность провайдера не всегда приводит к дополнительному начислению платы. Мы также публикуем отчетный период только после того, как поступили ожидаемые ответы и каналы от провайдеров, а результат прошел проверки на полноту. Панель управления продолжает обслуживать последний завершенный период. Задержка ответа или частичная синхронизация с провайдером не должны выглядеть как реальное падение использования.
Этап второй: Связь использования с людьми и организационными иерархиями
Данные провайдеров описывают учетные записи. Cisco работает через людей, команды, отношения отчетности и границы доступа. Эти миры не выстраиваются в аккуратные ряды. Один сотрудник может фигурировать под несколькими учетными записями провайдеров, в то время как другая учетная запись может вообще не соответствовать каталогу персонала. Команды реорганизуются, люди меняют руководителей, и организация продолжает двигаться вперед, пока накапливается использование.
Это обеспечивает четыре ключевые возможности:
- Видимость на уровне команды: Менеджер может видеть всю разрешенную команду в одном представлении, включая прямых и косвенных подчиненных, сохраняя промежуточные итоги для каждой ветки. На тепловой карте Splunk Agent Observability авторизованные руководители могут сравнивать затраты или внедрение у разных провайдеров и детализировать данные, чтобы увидеть, где возникли изменения.
- Разрешение идентификаторов: Слой разрешения идентификаторов сопоставляет известные учетные записи провайдеров с одной записью сотрудника, предотвращая искажение показателей внедрения из-за нескольких учетных записей. Уровенек запросов использует эту карту идентификаторов для формирования управленческих сводок в рамках разрешенной для пользователя зоны видимости. Если учетную запись сопоставить не удается, ее использование остается видимым как неатрибутированное. Это позволяет сохранять достоверность общих данных компании и одновременно делать пробел в атрибуции очевидным.
- Контроль доступа: Представления на уровне отдельного сотрудника, команды и всей организации имеют разные границы доступа. Руководитель видит только разрешенную ему ветку отчетности, в то время как доступ в масштабе всей организации требует отдельной авторизации. Интерфейс отражает эту область видимости, а служба принудительно применяет ее для каждого запроса.
- Управление изменениями: Представление отчетности должно оставаться внутренне согласованным, даже когда структура каталога меняется. Мы рассматриваем каждое обновление каталога как полный снимок. Новая версия проверяется перед активацией, а если ее невозможно использовать, продолжает обслуживать запросы предыдущий действительный снимок. Для первого выпуска исторические данные об использовании следуют текущей иерархии. В ответ на запросы клиентов мы изучаем возможность отслеживания иерархии с указанием дат вступления в силу, чтобы показатели использования можно было просматривать в сопоставлении с той структурой организации, которая существовала в момент совершения активности.
Этап три: Создание финансового представления
Финансы привносят еще один уровень сложности. Управленческая иерархия отвечает на вопрос, кто кому подчиняется. Финансовая иерархия отвечает на вопрос, к какому бюджету относятся средства. Эти структуры могут пересекаться, но они не взаимозаменяемы и могут меняться по разным графикам.
Поэтому для одной и той же активности ИИ необходимы две корректные организационные интерпретации: одна для руководителей, понимающих свои команды, а другая для финансового отдела, понимающего структуру владения расходами. Мы используем информацию об отделах для связи этих представлений, сохраняя их при этом как раздельные структуры. Подразделения Cisco IT и финансов используют это внутри компании по мере нашей подготовки к общедоступному релизу (General Availability).
Сложность этой задачи обусловлена их сочетанием: несогласованный учет у провайдеров, идентификаторы, которые не удается четко сопоставить с конкретными людьми, постоянно меняющиеся организационные структуры, различные границы доступа и финансовая модель, которая не следует за управленческим деревом.
Cisco предоставляет нам масштаб и реальные производственные условия для совместного решения этих проблем в рамках Splunk Agent Observability.
Прозрачность — это расширение возможностей, а не контроль
В масштабах предприятия управление расходами на ИИ — это не бухгалтерская проблема, а задача расширения возможностей. Необработанные данные о токенах показывают стоимость API, но не говорят о том, действительно ли ваша стратегия в области ИИ создает ценность. Если отслеживание воспринимается как слежка, внедрение буксует. Если затраты остаются невидимыми, бюджеты трещат по швам.
Прорыв происходит тогда, когда данные о затратах предоставляются в контексте реальной работы людей. Сопоставляя фрагментированные метрики провайдеров напрямую с реальными организационными иерархиями, мы превращаем неуправляемый поток данных об использовании в четкую и применимую на практике аналитику для всех трех ролей:
- Для инженеров: Прозрачная индивидуальная видимость, которая формирует понимание моделей и помогает выбирать более умные инструменты, позволяя разработчикам свободно экспериментировать без страха получить загадочные счета.
- Для руководителей: Четкая атрибуция на уровне команд, отделяющая намеренный прирост производительности от праздного простоя, что дает инженерным лидерам эмпирические данные для обоснования выделения больших бюджетов на ИИ.
- Для финансового отдела: Прямое и непрерывное соответствие между динамичным техническим использованием и жесткими статьями бюджета, заменяющее шок от счетов в конце квартала предсказуемой атрибуцией.
Внутри Cisco наш опыт работы в качестве Customer Zero доказывает, что не нужно выбирать между финансовой дисциплиной и скоростью работы разработчиков. Когда вы заменяете грубые ограничения на использование надежной и ориентированной на человека атрибуцией, ИИ перестает быть нестабильной статьей расходов — он превращается в подотчетный и масштабируемый двигатель инноваций.
По мере расширения нашего развертывания на новые модели и рабочие процессы мы продолжим делиться опытом, полученным в производственной среде.
Ресурсы
- Изучите больше историй о внедрении Cisco в Cisco
- Splunk Agent Observability
