Критический Путь К Автоматизации Разработки Моделей

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

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

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

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

Три Барьера, Стоящих на Пути

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

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

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

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

Что Требует Реальное Решение

История автоматизации ML – это история частичных решений. AutoML решила узкую задачу настройки гиперпараметров, но не могла справиться с несоответствиями целей или рассуждать об организационных намерениях. MLOps сделала производственные конвейеры более прочными и легкими в мониторинге, но инструменты MLOps выполняют стратегию, а не определяют ее. Более недавние кодовые агенты представляют собой настоящий шаг вперед, но они унаследовали тот же слепой пяток. Они хорошо генерируют код, работая без организационного контекста или институциональной памяти.

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

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

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

Что Становится Возможным

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

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