Принципы основ
Системы машинного обучения подчиняются эвристике, которая выглядит простой: сложность часто переходит из одного места в другое, а не исчезает, хотя хорошее проектирование способно убрать случайную сложность. Сложность перетекает между тремя областями таксономии D·A·M: данными как информацией, алгоритмом как логикой и машиной как физикой. Упрощение одной области может перегрузить другие. Конвейер признаков, созданный вручную, уменьшает алгоритмическую сложность, но требует больше усилий инженерии данных. Более крупная модель поглощает беспорядочные данные, но перекладывает сложность на аппаратуру, которая должна ее обучать и обслуживать. Эта эвристика сохранения сложности лежит в основе всей книги. Количественные границы, модели и принципы, введенные в книге, описывают ограничения, которые возникают там, где сейчас находится сложность.
Архитектуры, фреймворки и оптимизации успешны только тогда, когда учитывают ограничения, которые накладывают аппаратура, математика и теория информации. Как инженер-строитель не может игнорировать гравитацию, так и инженер ML не может игнорировать физические законы, управляющие данными, вычислениями и пропускной способностью системы. Часть I закладывает эти основы: не набор лучших практик, которые меняются вместе с фреймворками, и не мнения, которые расходятся между командами, а устойчивые физические ограничения и количественные модели инженерии ML. Первое ограничение начинается с самих данных, где привычная граница между программой и входом начинает исчезать.
Принцип «данные как код»
Инвариант: данные функционируют как исходный код ML-системы. Изменение обучающего набора может изменить выученное поведение системы. Здесь выученное поведение означает обученное отображение входов в выходы; обозначает процесс обучения, а отмечает качественную зависимость, а не предсказательное равенство. Архитектура модели, инициализация, конфигурация оптимизатора и стохастичность обучения входят в процедуру обучения.
Следствие: инженерия данных требует той же строгости, что и программная инженерия. Наборы данных следует версионировать (как в Git), покрывать модульными тестами (проверки качества данных) и отлаживать. Удаление строки обучающих данных может изменить пересобранную модель так же, как удаление строки кода может изменить скомпилированный артефакт.
Если данные функционируют как исходный код, то они не просто логический артефакт: у них есть и физические свойства, которые ограничивают архитектуру системы, когда данные и вычисления находятся в разных местах.
Принцип гравитации данных
Инвариант: по мере роста объема данных () перенос набора данных может стоить больше, чем отправка гораздо меньшего запроса или кода по тому же ограниченному каналу (McCrory, 2010).
Здесь стоимость означает одну метрику переноса за раз — например, затраченное время передачи или число переданных байтов — при одинаковых условиях канала; она не объединяет задержку и пропускную способность в одну величину.
Следствие: большие наборы данных могут стать гравитационным центром архитектуры. Системы могут переносить вычисления к данным, отправляя запросы или код на уровень хранения, а не переносить данные к вычислениям, многократно скачивая большие наборы.
Вместе эти два принципа показывают, что данные могут быть одновременно логической программой и физическим якорем ML-системы. Часть I развивает эти следствия как цепочку зависимостей. Ограничения развертывания определяют, где система может исполняться; жизненный цикл переносит эти ограничения через постановку задачи, данные, моделирование, валидацию и эксплуатацию; а инженерия данных делает их обязательными в версионируемых и протестированных артефактах конвейера. Игнорирование любого звена возвращает сложность в виде издержек интеграции: точная модель, которую нельзя запустить, рабочий процесс, который не может воспроизвести свои входы, или конвейер, выходы которого больше не соответствуют условиям развертывания.