Искусственный интеллект был уверен, но ошибся. Что дальше?

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

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

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

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

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

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

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

Модель, которая ошибается с высокой уверенностью, часто указывает на фундаментальные проблемы в том, как она обучалась. Наконец, мы переходим к интерпретируемости. Для классических методов машинного обучения мы можем отследить данные, которые привели к этой ошибочной, но уверенной реакции (SHAP и LIME — примеры таких методов). В современных больших языковых моделях существуют подходы, такие как механистическая интерпретируемость, которые, хотя технически сильно отличаются от классических, отвечают на схожие вопросы: какие именно токены во входном тексте привели к такому решению.

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

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

Я постоянно наблюдаю эту ситуацию и испытываю определённое понимание к обеим сторонам. Руководители должны принимать решения о закупке технологий, которые развиваются быстрее, чем кто-либо может уследить, и они полагаются на заверения поставщиков, поскольку часто нет другой альтернативы. У них нет внутренней экспертизы, чтобы технически оценить эти системы (а также возможности отслеживать это быстро меняющееся поле).

Тем не менее, фраза «я доверял поставщику» никогда не была убедительной защитой, когда что-то шло не так, и с ИИ будет то же самое. Если вы внедряете систему, принимающую важные решения, и не можете объяснить (даже на высоком уровне) как она работает, на каких данных обучалась и каковы её известные ограничения — это провал в управлении.

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

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

Буду прямолинеен: для многих организаций это начнётся как профанация для соблюдения норм. Закон ЕС об искусственном интеллекте содержит требования, включая прозрачность обучающих данных, документирование ограничений модели, механизмы человеческого контроля для систем высокого риска и так далее. Это разумные требования. Но их надлежащее выполнение требует уровня дисциплины в ML-инженерии и управления, которого у многих компаний (включая крупные) пока нет.

Я ожидаю волну документации, которая на бумаге выглядит исчерпывающей, но на деле никому не помогает понять или проверить систему. Самый простой путь — обернуть операционный «чёрный ящик» в соответствие нормам, чтобы поставить галочки, и таких случаев, я полагаю, будет немало.

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

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

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