Как выстроить доверие при взаимодействии с системами искусственного интеллекта
Не секрет, что системы искусственного интеллекта глубоко проникли в повседневную жизнь: мы просто используем их и часто даже не задумываемся, как был получен прогноз погоды или предсказание времени в пути по маршруту. Ситуация кардинально меняется, когда вы владеете бизнесом и хотите повысить его эффективность за счет применения таких систем. На практике чаще всего речь идет о рекомендательных системах (для B2C и широкого рынка) либо об экспертных системах и системах поддержки принятия решений (для B2B и нишевых кейсов).
Представим, что вы уже оценили преимущества подхода Data Driven и взяли его на вооружение, то есть описали бизнес-задачу через измеримые бизнес-метрики, провели анализ необходимых исходных данных, а также выстроили инфраструктуру для их сбора и хранения. Если метрики связаны с исходными данными напрямую либо с помощью формализуемых зависимостей, то команда аналитиков строит аналитическую модель, где исходные данные преобразуются, а все необходимые метрики вычисляются на их основе и визуализируются на дашбордах. При этом вы четко понимаете, как какие-либо изменения в исходных данных повлияют на конечный результат, или имеете полное описание, что происходит «под капотом» аналитической системы, и при необходимости можете восстановить все преобразования и вычисления. В конечном счете вопрос доверия к прогнозам, полученным таким способом, сводится к качеству исходных данных и отсутствию ошибок при преобразовании и вычислении метрик, то есть к вопросам Data Governance, к тестированию функционала аналитической системы и выстроенному процессу CI/CD при его обновлении.
Но бывает и так: на этапе построения аналитической модели выясняется, что четких зависимостей между метриками и исходными данными нет, и вам нужно привлекать дата-сайентистов для построения модели машинного обучения. Как понять, решается ли ваша бизнес-задача, если эта модель представляет собой черный ящик, где на входе ваши исходные данные, а на выходе — некие прогнозы, качество которых вы пока не можете оценить? Как в принципе можно доверять рекомендациям и прогнозам, полученным таким путем?
К сожалению, универсального ответа нет. Есть три области, которые раскрывают разные аспекты обозначенной проблемы, и в каждом конкретном случае ответ будет строиться на их сочетании.
Интерпретируемость модели
Первая область — интерпретируемость конкретной модели машинного обучения. На первый план здесь выходит роль того, кто участвует в проекте внедрения ML-модели — ведь у всех будет разное понимание, как именно должна выглядеть эта интерпретируемость. Заказчик смотрит на финансовый эффект от применения ML-модели (ROI либо NPV) и хочет избежать большого ущерба при ее ошибках. Владелец продукта, где используется модель, имеет схожие запросы, но понимает их более широко: насколько полно модель решает бизнес-задачу (какие бизнес-требования полностью удовлетворяются), насколько модель устойчива в практическом использовании. Пользователь модели хочет понимать границы ее применимости, иметь возможность отслеживать их при использовании модели, а также иметь «план Б», если эти границы нарушены. Наконец, разработчик ML-решения может использовать интерпретируемость при создании и улучшении модели — повышении ее внутренних метрик (отличающихся от бизнес-метрик), расширении границ применимости и связи внутренних метрик ML-модели с бизнес-метриками проекта (зачастую неочевидной).
Если рассматривать ситуацию с позиции бизнес-пользователей, где обычно и возникают вопросы доверия, то существует два уровня интерпретируемости: глобальный (как устроен процесс появления прогноза в целом) и локальный (как именно был получен конкретный прогноз). Глобальный уровень ограничен архитектурой модели и математической подготовкой бизнес-пользователя. Если простые регрессии на табличных данных могут быть объяснены с помощью теорем и формул, то нейронные сети в общем случае не поддаются полной интерпретации и могут быть описаны только их отдельные механизмы: как работают фильтры на слоях, каково устройство функции ошибки, кривые обучения и т. д. На локальном уровне вариантов намного больше. Здесь применяются готовые библиотеки: SHAP для табличных данных, Grad-CAM для нейронных сетей, которые показывают влияние исходных данных, так называемых признаков, на прогноз модели. И в каждом конкретном случае вы можете видеть, какие веса для всех признаков использовала модель при принятии конкретного решения. Часто такого понимания бывает достаточно для начального уровня доверия к прогнозам модели и принятия решения об ее использовании.
Причинно-следственный анализ
Вторая область — это причинно-следственный анализ (causal inference). Здесь мы отходим от того, что происходит «под капотом» модели при получении прогноза, и концентрируемся на том, как именно мы можем принимать решения на основе ее прогнозов. При построении прогнозов часто возникает ошибка интерпретации исходных данных, связанная с ложной зависимостью корреляции признаков и прогнозов модели. Например, высокие люди имеют больший вес — однако с увеличением веса конкретного человека его рост обычно не изменяется. Важно, что в общем случае корреляция не подразумевает причинно-следственную связь — каждый случай должен рассматриваться независимо. Для этого проверяется наличие четырех возможных причин расхождений. Первая связана с обратной причинностью — вместо влияния А на B происходит влияние B на A. Наиболее известные примеры таких зависимостей: уровень дохода и счастье, бедность и безработица, курение и депрессия. Вторая по известности — систематическая ошибка измерения, типичная для прогнозов, основанных на опросах общественного мнения, и связанная с методикой получения данных. Третья — смещение или нерепрезентативность обучающей выборки. В этом случае вы обучаете модель на данных, отличных от тех, которые она увидит на практике. И четвертая — пропущенная переменная. В данном случае вы используете корреляцию признаков A и B в своей модели, но упускаете из виду переменную Z, которая их связывает и определяет характер прогноза. Например, при наличии диагностированного заболевания и пониженной частоты смертности от него такой переменной может являться регулярность наблюдений у врача.
Расширение подходов
Третья область — расширение подходов Data Governance и CI/CD на всю предметную область, связанную с эксплуатацией моделей машинного обучения, включая их обновление и мониторинг. Исторически этот подход был назван MLOps, то есть DevOps + ML. В компании «Иннодата» мы немного расширяем это понимание, дополняя его принципами Data Governance: D/MLOps или Data & Machine Learning Operations. В целом подход MLOps опирается на целый набор инструментов с открытым кодом, а также на методологию разработки, внедрения и поддержки пайплайнов данных и моделей машинного обучения. На практике основные проблемы в эксплуатации моделей, если исключить чисто технические моменты в DevOps и ModelOps, возникают из-за изменения характера входных данных – так называемый сдвиг данных, или Data Drift. Например, меняется характер потребления в пандемию COVID-19 или отношение к дорогостоящим покупкам из-за финансового кризиса — и ранее эффективные ML-модели перестают работать с прежним качеством. В этом случае мониторинг сдвига данных позволяет как диагностировать наличие проблемы (падение качества прогнозов), так и предложить метод лечения —дообучение ML-модели на новых данных (часто в полностью автоматическом режиме) либо отказ от ранее используемых подходов и разработка новой модели.
Сейчас уже сложно представить бизнес в конкурентной среде без применения подходов Data Driven и аналитических моделей, включая предиктивную аналитику, рекомендательные и экспертные системы. Главным драйвером развития становится практический опыт применения этих подходов в бизнесе. Поэтому в конечном счете повышение доверия к системам искусственного интеллекта будет связано с практикой внедрения, и здесь важно не наступить на уже известные грабли, а также использовать проверенные методы снижения риска подобных проектов.
Опубликовано 25.01.2023