Что меняется, когда с метрикой можно поговорить

Знания и экспертиза

«Что написано в регламенте?» — понятный вопрос для корпоративного AI.

«Почему мы выполнили план продаж, а заработали меньше?» — вопрос посложнее.

Для первого пригодятся документы и RAG: найти нужные фрагменты, связать их с вопросом, подготовить ответ. Со вторым мы обычно идём к человеку, который хорошо понимает бизнес. Он начинает задавать вопросы, сопоставлять показатели, проверять предположения. Иногда после нескольких минут разговора говорит: «Подождите, сначала посмотрите вот сюда».

Что он знает такого, чего пока не знает наша AI-система?

Эксперт годами изучает зависимости внутри процесса. Он понимает, какие параметры влияют друг на друга, где возникает задержка между действием и результатом, при каких условиях привычное правило перестаёт работать.

Часть этих знаний записана. Но даже если мы подробно опишем их в документах, останется задача применения.

Например, можно зафиксировать правило: при увеличении нагрузки потребуется больше курьеров. А сколько именно? На каких объектах и в какие часы? Что произойдёт, если одновременно увеличить минимальную сумму заказа? Как это повлияет на конверсию, опоздания, затраты и дальнейшее поведение покупателей?

Чтобы ответить, придётся рассмотреть сочетания условий и сравнить последствия решений.

Зависимости здесь могут быть многомерными, нелинейными, с порогами: небольшое изменение входящего потока иногда почти незаметно, а иногда приводит к быстрому росту очереди. Эксперт умеет учитывать такие особенности. Как дать эту возможность AI?

Модели процесса

Я предлагаю начать с формализации самого процесса.

Некоторые зависимости уже описаны уравнениями — в том числе физическими и химическими. Другие можно восстановить по историческим данным с помощью статистических моделей. Где-то пригодятся имитационное моделирование и экспертные правила.

Так мы получаем набор моделей, в которых определены наблюдаемые показатели, управляющие параметры и условия, на которые мы повлиять не можем.

Следующий шаг — сформулировать, какого результата мы хотим добиться и какими средствами располагаем.

Пример: последняя миля

Давайте на примере из понятной области, например последней мили в логистике.

Допустим, у нас есть некий прогноз количества запросов на доставку в разрезе «объект — час», есть история фактических заказов, есть минимальная сумма заказа в каждый момент времени, процент опозданий и затраты на логистику в этот час.

Для того чтобы пойти дальше, нам нужно понять, а какими метриками мы можем охарактеризовать эффективность процесса?

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

Давайте разберёмся, а чем же в этой задаче мы можем управлять?

Количеством курьеров, политикой объединения заказов, минимальной суммой заказов, целевым временем доставки, ставкой в час и т. п.

Понятно, что все параметры между собой связаны, и по данным мы построим несколько моделей, которые из управляющих параметров предсказывают состояние системы, а сверху поставим оптимизатор.

Оставлю пока за рамками то, что же в итоге мы должны оптимизировать. Это неочевидно — длину очереди на одного курьера? Или опоздания? Или количество доставок в час на курьера?

Уменьшим количество курьеров — возможно, снизим затраты на доставку. Но при определённой нагрузке начнут расти очереди. Увеличим минимальную сумму заказа — изменится экономика доставки, одновременно изменится конверсия.

Как во всем этом многообразии искать решение? Однако прежде чем искать лучшее решение, нужно договориться, что считать лучшим. Или хотя бы минимально допустимым.

Какой результат нам нужен? Какой уровень обслуживания обязателен? Какими последствиями допустимо поступиться ради экономии? На каком горизонте оценивать эффект?

Это управленческий выбор. Модель помогает просчитать его последствия.

И вот у нас есть несколько моделей, которые оценивают состояние процесса при разных управляющих параметрах. Над ними запущен оптимизатор, который подбирает допустимые сочетания этих параметров по выбранному критерию.

Получается расчётная система. В ней уже выражена существенная часть профильной экспертизы: зависимости, ограничения, способы оценки результата.

Агент и оптимизатор

Теперь её можно обвязать AI-агентами.

Агенту доступны описания моделей, смысл показателей, допустимые действия и правила работы с оптимизатором. Пользователь формулирует задачу обычными словами:

«Снизить затраты на доставку, сохранив текущий уровень опозданий».

Агент уточняет неоднозначности, переводит запрос в формальную постановку, задаёт параметры оптимизатора и запускает расчёт. Затем проверяет ограничения, разбирает результат и объясняет, какие изменения предлагаются и на каких основаниях.

Пользователь может продолжить:

«А если количество курьеров менять нельзя?»

Или:

«Почему ты предлагаешь увеличить ресурс на этом объекте, хотя заказов там меньше?»

Система возвращается к моделям и расчётам. Так появляется возможность обсуждать решение и исследовать альтернативы.

Для проверки этой гипотезы мы взяли данные из другой сферы — непрерывного производственного процесса, подготовили модели и оптимизатор и добавили агентный интерфейс для постановки задач и разбора результатов. Эксперимент работал на архивных данных. Он позволил предметно обсуждать, что требуется от такой системы: как формализовать намерение пользователя, какие проверки нужны и что именно можно утверждать по результатам расчёта.

Разговор с метрикой

Но самый интересный эффект — сама метрика становится доступной для разговора.

Мы часто стараемся сделать показатель простым, чтобы его было легче объяснить сотрудникам. Однако результат сложного процесса может требовать сложной оценки — с учётом множества показателей, например качества обслуживания, использования ресурсов. При этом ряд изменений может иметь отложенный эффект.

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

Руководитель сможет обсуждать общий результат. Логистика — влияние загрузки и маршрутов. Маркетинг — последствия изменения спроса. Команда объекта — свои доступные действия.

Каждое подразделение получает возможность задать вопросы со своей позиции, сохраняя связь с общей картиной:

«За счёт чего изменился показатель?»

«Как на него повлияет наше решение?»

«Почему улучшение в нашей зоне ответственности создаёт проблему у соседей?»

Ответы могут оказаться неожиданными. Поэтому важно иметь возможность проследить их основания: какие данные использованы, какие предположения приняты, что рассчитано и насколько вывод чувствителен к этим предположениям.

Согласование участков

Длинный процесс при этом может состоять из нескольких участков со своими моделями и оптимизаторами.

В e-commerce продвижение влияет на спрос, спрос — на запасы и загрузку склада, исполнение заказов — на доставку и обращения в поддержку. Решения проходят через всю цепочку.

Агенты могут помогать согласовывать работу этих частей: передавать прогнозы и ограничения, уточнять доступные ресурсы, запускать пересчёты и сопоставлять варианты по общей цели.

Для этого нужны согласованные определения данных и механизм координации. Сам обмен сообщениями между агентами ещё не улучшает процесс. Но такая архитектура даёт возможность учитывать последствия решений за пределами отдельного участка и искать улучшение общего результата.

Контроль и адаптация

Остаётся ещё один вопрос: что произойдёт, когда изменится сам процесс?

В промышленности могут поменяться свойства сырья, оборудование или измерительная система. В доставке — структура спроса, доступность курьеров, дорожные условия, правила обслуживания, состояние рынка.

Хорошая рекомендация постепенно теряет применимость. Поэтому контроль должен быть встроен в систему с самого начала.

Нужно сравнивать прогноз и фактический результат, замечать расхождения и проверять возможные объяснения. Изменились условия? Появилась ошибка в данных? Модель перестала описывать существенную зависимость? Решение было исполнено иначе, чем предполагалось?

От ответа зависит способ адаптации.

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

Самоадаптация в такой системе — последовательность проверяемых изменений. Обнаружить отклонение, разобраться в нём, предложить корректировку, проверить её и оценить результат. Степень самостоятельности системы задаётся в зависимости от задачи.

Как собрать систему

Так вокруг моделей процесса появляется полноценный агентный контур: постановка задачи, расчёт, проверка, объяснение, наблюдение за результатом и адаптация.

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

Скорость здесь появляется за счёт сокращения ручной работы между этапами: подготовкой постановки, запуском расчётов, сравнением сценариев и объяснением результата. А доверие опирается на возможность воспроизвести расчёт и проверить основания рекомендации.

У каждого подразделения появляется собеседник, который помогает разобраться в своей части процесса и её связях с остальными.

И вопрос к метрике меняется. Кроме «сколько получилось?» можно спросить: «почему?», «при каких условиях?» и «что мы можем изменить?»