Мы создаем маршрутизирующий слой, чтобы сократить расходы на ИИ. Это привело к поломке продукта.

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

Делиться

Команда, с которой я работал, сократила свои устройства на вывод ИИ более чем в прошлом квартале. Восемь недель чистой инженерной работы. Это была победа, к которой инженерная команда стремилась весь год. Но это была и неправильная оптимизация. Три месяца спустя удовлетворенность клиентов упала, отток росы, а экономия была структурно связана с потерей качества. Мы не победили. Мы просто перенесли затраты туда, где их не измеряли.

Именно такое воздействие я ожидаю увидеть в процессе развертывания II в производственной среде в течение следующих шести месяцев. Дискуссия об экономике II в 2026 году привела к формированию стандартной альтернативы. Следуйте простым инструкциям к недорогим моделям. О предъявляемых требованиях к мощным моделям. Сократить расходы, сохранить качество. Каждый финансовый директор видел эти расчеты. каждая инженерная команда уже разработала или разработала это.

Математика подтвердила это. Ловушка Парето тоже реальна.

Ниже приведен текст, который я рассказал комиссии после проведения анализа причин страха. В нем описывается построенная ими архитектура, возникший сбой, методология обнаружения, которая позволяет указать его раньше, и архитектурная модель, которую следует использовать вместо этого. Также важно два других развертывания, которые я проверил после этого, и в которых аналогичная ситуация наблюдалась в разных секторах. В получении полученных данных показано, что эффективные по стоимости уровни маршрутизации, в такой форме, которые необходимы в руководстве по консенсусу, структурно уязвимы в производственной среде. SaaS-продукт с примерно 4 миллионами активных пользователей в месяц. Система работала на основе одной проверки функциональной модели — самой высокоуровневой модели логического мышления в их стеке на момент разработки. Объём вычислительной машины был настолько велик, что ежемесячный счётчик от модели поставщика вырос до шестизначной величины и продолжал расти по мере масштабирования развития.

Маршрутизация была концептуально простой. Небольшая модель классификации, специально обученная примерно на 200 000 исторических запросов в службу поддержки с метками качества, располагалась перед главным агентом и помечала каждый входящий запрос как «простой» или «сложный». Простые указания направлялись к более дешевым моделям из тех же источников поставок. Сложные запросы продолжали ориентироваться на более мощные модели. Сам классификатор представляет собой тонкий настроенный кодировщик, достаточно легкий, чтобы работать менее чем за 30 миллисекунд с незначительными затратами.

Классификационная таксономия была построена на основе наблюдения за производственным процессом. Простые запросы — это те, с которыми команда часто встречалась: поиск учетных записей, вопросы о статусе выставления счетов, сброс паролей, отслеживание заказов и вопросы о времени работы. Сложные запросы — это те, которые временно потребовали тонкого, многоэтапного анализа: споры о возврате средств, компромиссы при предоставлении тарифного плана, устранение неполадок и аномалий в цикле выставления счетов. В типичной неделе производственного трафика соотношение выглядит примерно так: 65 процентов простых и 35 процентов сложных запросов.

Выбранная пара, более дешевая модель, стоила примерно четверть от стоимости одного токена в более совершенной модели. Для простых запросов, отправленных классификатором, сравнительная оценка с более совершенной моделью показала эквивалентное качество ответов для 94% из 5000 запросов в контрольной выборке. Разница в 6% была заметна, но команда сочла ее приемлемой, что привело к снижению стоимости. Они отслеживали качество более дешевой модели с помощью существующего конвейера, который отбирал ответы для проверок людей примерно в час процента трафика.

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

К концу восьмой недели ежемесячные расходы на вывод данных сократились примерно на 40% от уровня уровня. Команда инженеров представила результаты работы на общем собрании компании. Финансовый директор отправил благодарственное письмо бюро ИИ. Показатели предоставления агента внутри незначительного уровня или немного повышены. Команда перешла к следующему квартальному приоритету.

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

Потребовалось три месяца, чтобы этот пробел был представлен в бизнес-показателях, и еще месяц, чтобы его правильно отразить. К тому времени, когда они поняли, что происходит, прошло четыре месяца, и влияние на клиентов уже было очевидным.Архитектура оценок, разработанная одной дослойной маршрутизацией, была основана на предположении, что они используют единую модель. Сигнал качества поступал из трех источников. Ежедневная проверка человеком примерно 200 сигналов, измеряемых по точности и полезности. Еженедельно знакомся с офлайн-тестом на регрессионном анализе, включающим около 12 000 размеченных запросов, против рабочих моделей. И сигнализирует об удовлетворенности виджета обратной связи в продукте, где пользователи анализируют ответы, ставя «лайк» или «дизлайк».

Когда был запущен уровень маршрутизации, расширилась команда выбора проверок для людей, сохраняя общее количество отзывов около 200 в день, но не разделяя их по уровням маршрутизации. Они добавили более дешевую модель в набор тестов для оффлайн-регрессии, где она показала результаты, соответствующие их пороговому результату. Виджет обратной связи в продукте остался без изменений, поскольку он не изменил определение, какая модель обработала ответ.

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

То, чего они не заметили, проводилось на трех разных уровнях.

Выборка отзывов, полученных от людей без учета уровней сложности, на самом деле представляет собой взвешенное среднее, где 65 процентов отзывов относились к дешевым моделям, а 35 процентов — к высокопроизводительным. Поскольку дешевая модель была эквивалентом простых примеров (центральное распределение запросов с большим объемом работы), она подняла общий результат. Проблемы с качеством более сложных участков распределения запросов были настолько размыты, что стали незаметны в целом. Они были созданы за шесть месяцев до развертывания, когда у вас еще не было представления о маршрутах. Тест отражает идеализированное финансирование, а не фактическое значение в производственной среде, с которым теперь должна была работать упрощенная модель. Упрощенная модель прошла статическое тестирование, но показала снижение производительности в рабочей среде.

В продукте виджет обратной связи имелась структурная проблема, о которой команда знала более года, но не уделяла приоритетного внимания ее устранению. Отзывы клиентов были скудными. Типичная сессия оценивает ноль оценок. Клиенты ставили дизлайки примерно в 3 раза на 1000 взаимодействий, и эти дизлайки были в основном от клиентов, которые уже были недовольны чем-то совершенно другим. Соотношение сигнала/шума в виджете было слишком низким, чтобы характеризовать какие-либо изменения, меньшие, чем существенная регрессия.

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

Именно тогда мне позвонила команда.

Что сломалось и как мы это обнаружили

Диагностика заняла две недели. Мы разработали решения по маршрутизации из журнала «Диптихи», связали их с событиями обратной связи внутри продукта и представили представление о том, как по каждому направлению, которое команда ранее не видела.

Закономерность сразу же была реализована на уровне бюджетной модели. Бюджетная модель хорошо работала примерно с 80-процентными запросами, отправленными ей классификатором, что позволило получить результаты последовательного качества, полученные в результате выборки из 5000 запросов. Но остальные 20 процентов веществ в эксплуатации структурно отличались от методов контрольной выборки, которые классификатор не могли повлиять на этап принятия решений.

Наиболее наглядными были запросы по выставлению счетов. Классификатор был обучен распознавать такие шаблоны, как «откуда мой платеж» или «мне выставили счет дважды», как простой запрос, исходя из предположения, что поиск учетной записи плюс получение счета-фактуры — это надежный шаблон для дальнейшего анализа. В контрольном тестировании это подтвердилось. В ходе производственного процесса часть этих запросов по выставлению счетов покрывала более сложную задачу. Пользователь, спрашивающий «откуда мой платеж», иногда думал о первом мошенническом платеже, иногда о задержке в сверке между двумя цепями, а иногда об сохранении расчетного цикла, о котором его не ведомили. Эффективная модель незаметно и правильно обработала вложенные намерения, поскольку у нее был запас для дальнейшего анализа сложной ситуации. Дешевая модель рассматривала каждое из них как внешнее намерение и проверяла вопрос, который клиент на самом деле не задавал.

Клиенты, получившие неверные ответы, не всегда ставили дизлайк. Многие из них просто проигнорировали оператора и позвонили в службу поддержки. Таким образом, дизлайк не отражает реальную проблему. Стоимость этой проблемы пересчитывается в службу поддержки сотрудников, которые обрабатывают тот же запрос во второй раз, когда эти затраты на персонал оплачиваются из другого бюджета. В результате эффективная сторона переадресации запроса со стороны ИИ-операторов стабильно стабильна, в то время как поддержка реального объема обращений в сервисы, обрабатываемые люди, начало роста. Диптихи.

Совместное влияние на удовлетворение клиентов было сложнее точно измерить, но в конечном итоге оно применяло два метода. Во-первых, группа клиентов, взаимодействовавших с агентом в период разработки маршрутной обработки, показала заметные более низкие показатели удовлетворенности в ходе опроса через 90 дней после взаимодействия по сравнению с определением уровня развития. Во-вторых, удержание клиентов через 6 месяцев привело к снижению по сравнению с основным базовым уровнем, при этом наиболее резко падение наблюдалось в сегментах, наиболее динамичных влияний сбоев в маршрутизации. Команда сократила затраты на обработку данных примерно на 100 000 долларов в месяц, затраты на удержание клиентов и поддержку составили от 400 000 до 500 000 долларов в месяц. Расчеты, если их настроить полностью, были однозначны.

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

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

В любой производственной среде клиенты подчиняются степенному закону распределения сложности. Большая масса запросов сосредоточена вокруг легкого центра. Меньшая протяженность формируется в длинном хвосте более сложных, неоднозначных и контекстно-зависимых запросов. Модели Frontier имеют резервные ресурсы для легкого центра. Их возможности значительно превосходят возможности для ответа на вопрос «в какое время вы работаете?». Именно это избыточное выделение ресурсов и является причиной появления возможностей оптимизации затрат. Перенаправление легкого центра на более дешевую модель может обеспечить реальную экономию без ущерба для качества этих запросов.

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

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

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

Третий механизм — дрейф. Распределение запросов в производственной среде меняется. Для производства новых продуктов. Появляются новые группы клиентов. Возникают новые режимы отказов. Классификатор, изучаемый на данных о трафике в течение шести месяцев, постепенно неправильно маршрутизирует все большую часть запроса по мере того, как распределение отклоняется от обучающего набора. Затраты на экономику остаются стабильными, поскольку уровень маршрутизации продолжает направлять трафик на более дешевые модели с той же скоростью. Стоимость незначительного качества растет, поскольку классификатор все чаще ошибается в результате того, что запросы на самом деле являются простыми.

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

После этого я проверил еще две команды.

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

Первая компания, работающая в сегменте SaaS и использующая ИИ-помощник для обеспечения успеха клиентов, была меньше по масштабу, чем первая команда, ежемесячные затраты на разработку составляли всего несколько сотен тысяч долларов, а не шесть. Архитектура была та же. За четыре месяца до этого они создали маршрутизирующий слой, который отправлял простые запросы (определяющие классификатор сходства встраивания, а не тонко настроенным кодировщиком) более дешевые модели. Экономика сложилась около пятидесяти процентов. Показатели качества на их внутренней панели были развиты.

Когда мы сегментировали их связь по уровням маршрутизации, выяснилось, что уровень с более дешевой моделью показал значительно более низкий уровень удовлетворенности для запросов с длинным хвостом, который классификатор встраивания пометила как простой. Команда не заметила этого разрыва, поскольку сводная панель Диптихов объединила два уровня в одном ряду. Они оценили влияние на доверие клиентов примерно в два с половиной-три раза больше, чем экономия затрат, хотя их измерение было менее точным, чем у первой команды. За месяц после аудита они вернули уровень маршрутизации на гораздо меньшую долю.

Этот случай касался регулируемой области в сфере финансовых технологий. Ежемесячные затраты на обработку данных исчислялись шестизначными частями. Они создают более консервативный маршрутный уровень, который отправляет только те запросы, которые они традиционно называют «информационными» (балансовый счет, история транзакций, основная информация о продукте), на более дешевой модели, которая обеспечивает все, что касается соблюдения нормативных требований или финансовых решений, на основных моделях.

Данная ситуация произошла по другому сценарию. Затраты на экономику были ниже, поскольку доля маршрутизации была более консервативной и составляла около 20%. Но сбой в работе «длинного хвоста» на уровне дешевых моделей имел последствия для соблюдения нормативных требований, поскольку некоторые запросы, которые воспринимались как указания, на самом деле имели регуляторную силу. У клиента, спрашивающего «какова моя процентная ставка», иногда возникал дополнительный вопрос, который зависел от точности первого ответа, чего дешевая модель не могла быть надежно обеспечена. Команда по соблюдению нормативных требований выявила, что в ходе ручной проверки до того, как это стало проблемой для регулирующих органов, но этот инцидент привел к их полной отмене маршрутизации.

Пример с финтех-компанией оказался особенно показательным. Он ясно показал, что компромисс между затратами и качеством не симметричен в разных отраслях. В сфере поддержки клиентов неправильный ответ можно исправить. В регулируемой отрасли неправильный ответ может быть нарушен. Ловушка Парето переходит в любое десятилетие, когда затраты на долгосрочные расходы высоки или ограничены.

Во всех трех случаях наблюдалась устойчивая закономерность. Экономия затрат была наблюдаемой и измеримой. Потеря качества была обнаружением и не поддавалась измерению с помощью сравнительной конструкции. Команды, которые заметили этот пробел, выявили его спустя месяцы, после того как бизнес-показатели уже скорректировались. Команды, которые этого не заметили, продолжали проводить оптимизацию с низким результатом для своей клиентской базы до тех пор, пока показатели на панелях Диптихов не заметили.Методика диагностики, которая позволяет выявить любую из проблем на ранней стадии, проста, но требует изменения конфигурации измерений для запуска маршрутов этих уровней. Три представителя подключены к стеку.

Мониторинг качества на каждом уровне является основополагающим. Каждое качество сигнала в отдельной архитектуре должно быть разделено по уровням маршрутизации, при этом метка уровня должна передаваться от начала до конца через измерительную систему. Выборки для проверок люди должны быть стратифицированы таким образом, чтобы каждый уровень получал пропорциональную или избыточную проверку. Наборы регрессионных моделей в автономном режиме должны быть разделены на подмножества, специфичные для каждого уровня, и оцениваться отдельно. События обратной связи внутри продукта должны быть объединены с журнальными решениями по маршрутизации, чтобы соответствие уровням стало агрегированным параметром. Совокупный показатель качества сам по себе структурно не редко встречается дрейф качества на уровне отдельных продуктов.

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

Третьим обеспечением является дрейф уверенности в маршрутизации. Сам классификатор является сигналом о качестве, который большинство команд не отслеживают. Распределение оценок достоверности в производственном трафике следует сравнивать с показателями, наблюдаемыми во время обучения. Когда условия в производственной среде смещаются, классификатор работает с учетом особенностей калиброванной сети, и решения по маршрутизации становятся все более ненадежными. Сигнал дрейфа предшествует сигналу качества на несколько недель, что является временем, графиком для корректировки курса.

Эти три дополнения — не контрольный список для оценки их результатов. Это архитектурное решение, в котором каждый компонент демонстрирует классы, невидимые для других. Вместе они делают ловушку Парето, которая случается раз в несколько дней, а не в месяцы. Стоимость их учета с точки зрения инженерного времени намного ниже, чем стоимость проведения заметной регрессии качества в квартале.

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

Как выглядит альтернатива

Если общеевропейская предварительная маршрутизация по классификатору представляет собой ловушку Парето, то возникает очевидный вопрос: какова альтернативная модель? Она существует, и она значительно лучше, хотя и имеет свои недостатки.

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

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

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

Каскадный подход имеет свои компромиссы, в отличие от консенсуса с предварительной маршрутизацией. Задержка при выполнении запроса повышенной сложности примерно равна сумме затрат для дешевых моделей и задержки для функциональных моделей, что значительно хуже, чем было бы при предварительной маршрутизации. Стоимость сложнее предсказать заранее, поскольку она зависит от распределения достоверности в производственной среде. Сложность реализации несколько выше, поскольку калибровка точности самой дешевой модели сама по себе является нетривиальной частью.

Эти компромиссы реальны и заслуживают внимания. Но этот компромисс по отношению к минимальному уровню качества, который обеспечивает каскадный подход, но отсутствует при предварительной маршрутизации. В производственных условиях, где длинный хвост трафика принимается за дополнительное решение для клиентов, каскадная модель является обоснованным выбором. Для команды разработчиков ИИ-агентов для автоматизации бизнес-процессов в масштабах, соответствующих производственных условиях, каскадная модель с выводом Диптихов — это та, которая выдерживает четверть реального трафика.Первая, описанная в этой статье, в конечном итоге достигла стабильной структуры, которая приводит к созданию маршрутов с учетом неопределенности с мониторингом на каждом уровне. Их ежемесячные затраты на вывод данных сократились примерно на 35% по сравнению с базовым уровнем до оптимизации, что, по сути, меньше, чем экономия, достигнутая при использовании режима маршрутизации. Удовлетворенность клиентов вернулась к коллеге, предшествовавшему эксперименту. Чистая ценность продукта после развертывания, с учетом каждого уровня, оказалась положительной.

Урок, который извлекла из этого опыта команду, заключился не в том, что оптимизация затрат — это неправильно. Урок заключался в том, что оптимизация затрат — это выбор того, какому слою системы вы доверяете, чтобы он достиг надлежащего компромисса. Предварительная маршрутизация доверяет классификатору, который не видит того, что имеет значение. Каскадная модель доверяет самой модели, осознавая, чего она не знает.

Дешевая оптимизация незаметно нарушает продукт. Архитектурно обоснованная оптимизация — это та, которая выживает в длинном хвосте. В производстве ИИ разница обычно составляет четверть удовлетворенности клиентов.

Пратик К. Рупарелия — соучредитель и руководитель отдела стратегии компании Intuz. Более 18 лет он занимается внедрением корпоративных платформ искусственного интеллекта, интернет-вещей и облачных технологий в производстве в рамках более чем 700 проектов. Он пишет статьи об экономике масштабируемого ИИ для специалистов-практиков: что работает, что не работает и куда на самом деле уходят средства. Живет и работает в Сан-Франциско и Ахмедабаде.

Пратик Рупарелия Посмотреть все Пратик Рупарелия

Источник: towardsdatascience.com