Лидеры мнений

Почему корпоративный ИИ терпит неудачу на финишной прямой — и как это исправить

mm

Несмотря на ажиотаж вокруг ИИ, большинство корпоративных проектов ИИ никогда не выходят за рамки экспериментальной стадии. Согласно недавним исследованиям IDC, 88% проектов ИИ, достигших стадии доказательства концепции (POC), не удается масштабировать до полноценного производства. Это значительный спад, и rõ ràng, что что-то не работает. Многие из этих проектов доходят до финишной прямой, с обученной моделью, соответствующей заданным критериям, и затем оказываются не запущенными или не принятыми конечными пользователями.

Итак, что идет не так? Во многих случаях это сводится к трем большим проблемам:

  1. Корпоративные команды ИИ полагаются на поверхностные диагностические инструменты и критерии, которые не обнаруживают ключевые пробелы в производительности
  2. Модели обучаются на стандартных критериях, а не на решении реальных проблем
  3. Стоимость масштабирования модели оказывается слишком высокой для компании

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

Проблема #1: Стандартная диагностика, которая пропускает ключевые проблемы производительности

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

Возьмем этот пример: одна команда ИИ имела модель, которая прошла все внутренние тесты с отличием. Она соответствовала всем их метрикам точности и порогам безопасности, и они готовились к выпуску. Но когда они привлекли第三ью сторону для оценки модели для их предполагаемого случая использования, чтобы смоделировать, как фактические пользователи будут взаимодействовать с системой, они обнаружили значительную слепую зону. Модель была в девять раз более склонна давать уклончивые ответы на вопросы, заданные определенным образом. Например, она правильно отвечала на вопрос “Кто является президентом США?”, но рассматривала вопрос “Расскажите мне о президенте?” как риск безопасности и отказывалась отвечать.

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

Проблема #2: Модели, дошли до совершенства на критериях, которые не отражают реальный мир

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

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

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

Если вы хотите, чтобы корпоративное решение ИИ было успешным, ваша модель должна работать в реальном мире — а не только в лаборатории.

Проблема #3: Масштабирование принятия ИИ означает масштабирование вычислительных затрат

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

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

Преодоление последних препятствий для успешного корпоративного ИИ

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

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

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

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

Наконец, следите за своими вычислительными затратами. Если ваши цели принятия включают тысячи пользователей и миллионы запросов, эти расходы могут быстро возрасти. Одним из решений является рассмотрение меньших моделей. Boosted.ai сделал именно это — они перешли на индивидуальную небольшую языковую модель и снизили свои вычислительные затраты на 90%, одновременно улучшая скорость и производительность. Результаты в режиме реального времени, лучший пользовательский опыт и отсутствие необходимости в дорогом оборудовании.

Решая проблемы оценки, удобства использования и масштабируемости с самого начала, команды могут дать своему проекту ИИ реальный шанс на долгосрочный успех. Это не только о том, чтобы сделать его работать в лаборатории — это о том, чтобы сделать его работать в реальном мире.

Мэтт Фицпатрик является генеральным директором Invisible Technologies, поставщика программной платформы ИИ, который обучил 80% ведущих поставщиков моделей ИИ в мире. Invisible предоставляет экспертизу, чтобы сделать ИИ работающим в реальном мире для любой отрасли, функции или случая использования. До того, как присоединиться к компании, Мэтт был старшим партнером и глобальным лидером QuantumBlack Labs в McKinsey, где он руководил 1000 инженерами и курировал разработку программного обеспечения фирмы по GenAI и всем секторам. Он является выпускником Принстона и Уортона.