Этот пост представляет собой сборник отрывков из статьи «Скрытый технический долг в системах машинного обучения».

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

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

Предположим, мы развернули персонализированную систему уведомлений на основе машинного обучения. Он прогнозирует уведомление на основе прошлой истории пользователя, но отправляется, только если вероятность составляет ›0,5. Резкий скачок продаж после внедрения системы и периодического переобучения модели. Позже продажи начинают падать, хотя в методологию не было внесено никаких изменений.

Что может быть причиной? Ранние уведомления, которые были в ›0.5, теперь предсказывались с‹ 0.5, и только идеальные уведомления получали ›0.5. Меньшее количество уведомлений привело к падению продаж.

Сообщество машинного обучения (ML) продолжает накапливать многолетний опыт работы с живыми системами, и возникла широко распространенная и неудобная тенденция: разработка и развертывание систем ML относительно быстро и дешево, но их обслуживание в течение долгого времени сложно и дорого. Эту дихотомию можно понять через призму технического долга - метафору, введенную Уордом Каннингемом в 1992 году, чтобы помочь осмыслить долгосрочные затраты, связанные с быстрым развитием программного обеспечения.

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

Технический долг можно погасить за счет рефакторинга кода, улучшения модульных тестов, удаления мертвого кода, уменьшения зависимостей, ужесточения API и улучшения документации

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

1. Сложные модели размывают границы

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

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

Запутанность

Системы машинного обучения смешивают сигналы вместе, запутывая их и делая невозможным изолирование улучшений. Например, рассмотрим систему, которая использует в модели элементы x1..xn. Если мы изменим входное распределение значений в x1, важность, веса или использование оставшихся n - 1 функций могут измениться. Это верно независимо от того, полностью ли модель переобучается в пакетном режиме или разрешается адаптироваться в режиме онлайн. Добавление новой функции x (n + 1) может вызвать аналогичные изменения, как и удаление любой функции xj. Никакие входы никогда не бывают независимыми. Это называется принципом CACE: изменение чего-либо меняет все. CACE применяется не только к входным сигналам, но и к гиперпараметрам, настройкам обучения, методам выборки, порогам сходимости, выбору данных и, по сути, ко всем другим возможным настройкам.

Каскады коррекции

Часто бывают ситуации, когда модель ma существует для проблемы A, но требуется решение для немного другой проблемы A ′. В этом случае может возникнуть соблазн изучить модель m'a, которая принимает ma в качестве входных данных и изучает небольшую поправку как быстрый способ решения проблемы.

Однако эта модель коррекции создала новую зависимость системы от ma, что значительно удорожает анализ улучшений этой модели в будущем. Стоимость возрастает, когда модели коррекции объединяются каскадом, когда модель для задачи A ′ ′ изучается поверх ma, и так далее для нескольких немного разных тестовых распределений. Попав в систему, каскад коррекции может создать тупик в улучшении, поскольку повышение точности любого отдельного компонента фактически приводит к ущербу на системном уровне. Стратегии смягчения последствий заключаются в том, чтобы расширить ма, чтобы изучить исправления непосредственно в одной и той же модели, добавив функции, позволяющие различать случаи, или принять затраты на создание отдельной модели для A '.

Незаявленные потребители

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

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

2. Зависимости данных стоят больше, чем зависимости кода

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

Нестабильные зависимости данных

Чтобы двигаться быстро, часто бывает удобно использовать сигналы в качестве входных характеристик, создаваемых другими системами. Однако некоторые входные сигналы нестабильны, что означает, что они качественно или количественно меняют поведение с течением времени. Это может происходить неявно, когда входной сигнал поступает из самой модели машинного обучения, которая обновляется с течением времени, или из таблицы поиска, зависящей от данных, например, для вычисления оценок TF / IDF или семантических сопоставлений. Это также может происходить явно, когда инженерная собственность на входной сигнал отделена от инженерной собственности на модель, которая его потребляет. В таких случаях обновления входного сигнала могут быть выполнены в любое время. Это опасно, потому что даже «улучшения» входных сигналов могут иметь произвольные пагубные последствия для потребляющей системы, диагностика и устранение которых требует больших затрат. Например, рассмотрим случай, когда входной сигнал был ранее неправильно откалиброван. Модель, потребляющая его, вероятно, соответствует этим ошибкам калибровки, и тихое обновление, которое исправляет сигнал, будет иметь внезапные разветвления для модели.

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

Недостаточно используемые зависимости данных

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

Зависимости недостаточно используемых данных могут закрасться в модель несколькими способами.
* Унаследованные функции. Наиболее распространенный случай - функция F включается в модель на раннем этапе ее разработки. Со временем F заменяется новыми функциями, но это остается незамеченным.
* Объединенные функции. Иногда группа функций оценивается и оказывается полезной. Из-за давления крайних сроков или аналогичных эффектов все функции в пакете добавляются в модель вместе, возможно, включая функции, которые не добавляют ценности или не добавляют никакой ценности.
* e -Features. Как машинное обучение исследователей, возникает соблазн повысить точность модели, даже когда повышение точности очень мало или когда накладные расходы на сложность могут быть высокими.
* Коррелированные функции. Часто две функции сильно коррелированы, но одна является более прямой причинной. Многие методы машинного обучения испытывают трудности с обнаружением этого и в равной степени признают эти две функции или даже могут выбрать не причинную. Это приводит к хрупкости, если позднее поведение мира изменяет корреляции.

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

3. Петли обратной связи

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

Петли прямой обратной связи

Модель может напрямую влиять на выбор собственных будущих обучающих данных. Обычной практикой является использование стандартных контролируемых алгоритмов, хотя теоретически правильным решением было бы использование бандитских алгоритмов. Проблема здесь в том, что алгоритмы бандитов (такие как контекстные бандиты [9]) не обязательно хорошо масштабируются до размеров пространств действий, обычно требуемых для реальных проблем. Эти эффекты можно смягчить, используя некоторую степень рандомизации [3] или изолировав определенные части данных от влияния данной модели.

Скрытые петли обратной связи

Контуры прямой обратной связи дорогостоящи для анализа, но, по крайней мере, они представляют собой статистическую проблему, которую исследователи машинного обучения сочтут естественными для исследования [3]. Более сложный случай - это скрытые петли обратной связи, в которых две системы косвенно влияют друг на друга через мир.

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

4. Антипаттерны ML-системы

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

Клей код

Использование универсальных пакетов часто приводит к шаблону проектирования системы связующего кода, в котором записывается огромное количество вспомогательного кода для передачи данных в универсальные пакеты и из них. Приклеивание кода обходится дорого в долгосрочной перспективе, потому что он может заморозить систему к особенностям конкретного пакета; альтернативы тестирования могут стать чрезмерно дорогими. Таким образом, использование универсального пакета может препятствовать улучшениям, потому что это затрудняет использование свойств, специфичных для предметной области, или настройку целевой функции для достижения цели, зависящей от предметной области. Поскольку зрелая система может в конечном итоге состоять из (максимум) 5% кода машинного обучения и (как минимум) 95% связующего кода, создание чистого нативного решения может оказаться менее затратным, чем повторное использование универсального пакета. Важной стратегией борьбы с клеящим кодом является обертывание пакетов черного ящика в общие API. Это позволяет повторно использовать поддерживающую инфраструктуру и снижает стоимость смены пакетов.

Трубопроводные джунгли

Как частный случай связующего кода, при подготовке данных часто возникают загромождения конвейеров. Они могут развиваться органически по мере выявления новых сигналов и постепенного добавления новых источников информации. Без должного внимания итоговая система подготовки данных в формате, удобном для машинного обучения, может превратиться в сплошную массу этапов очистки, объединения и выборки, часто с выходом промежуточных файлов. Управление этими конвейерами, обнаружение ошибок и восстановление после сбоев - все это сложно и дорого [1]. Для тестирования таких конвейеров часто требуются дорогостоящие сквозные интеграционные тесты. Все это увеличивает технический долг системы и делает дальнейшие инновации более дорогостоящими.

Трубопроводных джунглей можно избежать, только если мыслить целостным образом о сборе данных и извлечении функций. Клей-код и конвейерные джунгли являются симптомами проблем интеграции, которые могут иметь первопричину в чрезмерно разделенных «исследовательских» и «инженерных» ролях. Когда пакеты машинного обучения разрабатываются в условиях башни из слоновой кости, результат может показаться черным ящикам командам, которые используют их на практике. Гибридный исследовательский подход, при котором инженеры и исследователи объединены в одни и те же команды (и, действительно, часто являются одними и теми же людьми), может помочь значительно уменьшить этот источник трений [16].

Мертвые экспериментальные кодовые пути

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

Однако со временем эти накопленные кодовые пути могут создать растущую задолженность из-за возрастающих трудностей с поддержанием обратной совместимости и экспоненциального увеличения цикломатической сложности. Тестирование всех возможных взаимодействий между кодовыми путями становится трудным или невозможным. Известным примером опасности здесь была система Knight Capital, потерявшая 465 миллионов долларов за 45 минут, по-видимому, из-за неожиданного поведения устаревших экспериментальных кодовых путей [15].

Как и в случае с мертвыми флагами в традиционном программном обеспечении [13], часто бывает полезно периодически пересматривать каждую экспериментальную ветвь, чтобы увидеть, что можно удалить. Часто фактически используется лишь небольшое подмножество возможных ветвей; многие другие могли быть однажды проверены и брошены.

Абстракция долга

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

Общие запахи

В программной инженерии запах дизайна может указывать на основную проблему в компоненте или системе [7].
* Обычный запах старых данных. Богатая информация, используемая и производимая системами машинного обучения, часто кодируется с помощью простых типов данных, таких как необработанные числа с плавающей запятой и целые числа. В надежной системе параметр модели должен знать, является ли он множителем логарифмических шансов или порогом принятия решения, а прогноз должен знать различные фрагменты информации о модели, которая его создала, и о том, как ее следует использовать.
* Многоязычный запах. Часто возникает соблазн написать конкретную часть системы на определенном языке, особенно когда этот язык имеет удобную библиотеку или синтаксис для решения поставленной задачи. Однако использование нескольких языков часто увеличивает стоимость эффективного тестирования и может усложнить передачу права собственности другим лицам.
* Запах прототипа. Новые идеи удобно тестировать в небольшом масштабе с помощью прототипы. Однако регулярное использование среды прототипирования может быть индикатором того, что полномасштабная система хрупка, ее трудно изменить или что ей могут быть полезны улучшенные абстракции и интерфейсы. Поддержание среды для создания прототипов связано с собственными расходами, и существует значительная опасность того, что нехватка времени может подтолкнуть систему прототипирования к использованию в качестве производственного решения. Кроме того, результаты, полученные в мелком масштабе, редко отражают реальность в полном масштабе.

5. Работа с изменениями во внешнем мире.

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

Фиксированные пороги в динамических системах

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

Одна из стратегий смягчения такого рода проблем представлена ​​в [14], в которой пороговые значения изучаются посредством простой оценки данных удерживаемой проверки.

Мониторинг и тестирование

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

* Смещение прогноза. В системе, которая работает по назначению, обычно должно быть так, чтобы распределение предсказанных меток было равно распределению наблюдаемых меток. Это ни в коем случае не исчерпывающий тест, так как ему может соответствовать нулевая модель, которая просто предсказывает средние значения вхождений меток без учета входных характеристик. Тем не менее, это удивительно полезная диагностика, и такие изменения показателей часто указывают на проблему, требующую внимания. Например, этот метод может помочь обнаружить случаи, когда поведение в мире внезапно меняется, в результате чего обучающие распределения, полученные на основе исторических данных, больше не отражают текущую реальность. Разделение предвзятости прогноза по различным параметрам позволяет быстро изолировать проблемы, а также может использоваться для автоматического оповещения.
* Ограничения на действия. В системах, которые используются для выполнения действий в реальном мире, таких как назначение ставок для элементов или пометки сообщений как спама, может быть полезно установить и применить ограничения на действия в качестве проверки работоспособности. Эти пределы должны быть достаточно широкими, чтобы не срабатывать ложно. Если система достигает предела для определенного действия, должны срабатывать автоматические предупреждения и инициировать ручное вмешательство или расследование.
* Производители Up-Stream. Данные часто поступают в обучающую систему от различных производителей. Эти восходящие процессы должны тщательно контролироваться, тестироваться и регулярно соответствовать цели уровня обслуживания, которая учитывает потребности нисходящей системы машинного обучения. Кроме того, любые восходящие предупреждения должны распространяться на уровень управления системы машинного обучения, чтобы гарантировать ее точность. Точно так же любой сбой системы машинного обучения в соответствии с установленными целями уровня обслуживания также распространяется вниз по потоку для всех потребителей и непосредственно на их плоскости управления, если это вообще возможно.

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

6. Прочие области задолженности, связанной с отмыванием денег

Задолженность по тестированию данных.

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

Долг воспроизводимости

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

Долг по управлению процессами

В большинстве случаев использования, описанных в этой статье, говорится о стоимости поддержки одной модели, но в зрелых системах могут одновременно работать десятки сотен моделей [14, 6]. Это поднимает широкий спектр важных проблем, включая проблему безопасного и автоматического обновления многих конфигураций для многих похожих моделей, как управлять и распределять ресурсы между моделями с разными бизнес-приоритетами, а также как визуализировать и обнаруживать блокировки в потоке данных в производственный конвейер. Также очень важна разработка инструментов для восстановления после производственных инцидентов. Важный запах системного уровня, которого следует избегать, - это обычные процессы, выполняемые вручную.

Культурный долг

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

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

Несколько полезных вопросов, которые следует учитывать при проверке текущего долга:

  • Насколько легко можно полностью протестировать совершенно новый алгоритмический подход?
  • Что такое транзитивное закрытие всех зависимостей данных?
  • Как точно можно измерить влияние нового изменения на систему?
  • Ухудшает ли улучшение одной модели или сигнала другие?
  • Насколько быстро можно обучить новых членов команды?

Первоначально опубликовано на http://ml-dl.com 26 мая 2019 г. Исходный документ доступен по адресу https://papers.nips.cc/paper/5656-hidden-technical- долг-в-машинном-обучении-системах.pdf

использованная литература

[1] Р. Анантанараянан, В. Баскер, С. Дас, А. Гупта, Х. Цзян, Т. Цю, А. Резниченко, Д. Рябков, М. Сингх и С. Венкатараман. Photon: отказоустойчивое и масштабируемое объединение непрерывных потоков данных. В SIGMOD ’13: Proceedings of the 2013 International Conference on Management of Data, pages 577–588, New York, NY, USA, 2013.
[2] A. Anonymous. Машинное обучение: кредитная карта технического долга с высокими процентами. SE4ML: Разработка программного обеспечения для машинного обучения (семинар NIPS 2014).
[3] Л. Ботту, Дж. Петерс, Дж. Куинонеро Кандела, Д. Х. Чарльз, Д. М. Чикеринг, Э. Португали, Д. Рэй, П. Симард , и Э. Снельсон. Системы контрфактического мышления и обучения: пример вычислительной рекламы. Journal of Machine Learning Research, 14 (ноябрь), 2013 г.
[4] У. Дж. Браун, Х. У. Маккормик, Т. Дж. Моубрей и Р. К. Мальво. Антипаттерны: рефакторинг программного обеспечения, архитектур и кризисных проектов. 1998.
[5] Т. М. Чилимби, Ю. Сузуе, Дж. Апасибл, К. Кальянараман. Проект адам: создание эффективной и масштабируемой системы обучения глубокому обучению. На 11-м симпозиуме USENIX по разработке и внедрению операционных систем, OSDI '14, Брумфилд, Колорадо, США, 6–8 октября 2014 г., страницы 571–582, 2014 г.
[6] Б. Далессандро, Д. Чен , Т. Редер, К. Перлих, М. Хан Уильямс и Ф. Провост. Масштабируемое обучение с переносом громкой связи для интернет-рекламы. В материалах 20-й международной конференции ACM SIGKDD по открытию знаний и интеллектуальному анализу данных, страницы 1573–1582. ACM, 2014.
[7] М. Фаулер. Используйте запах. Http: // http: //martinfowler.com/bliki/CodeSmell.html.
[8] М. Фаулер. Рефакторинг: улучшение дизайна существующего кода. Pearson Education India, 1999.
[9] Дж. Лэнгфорд и Т. Чжан. Жадный по эпохе алгоритм для многоруких бандитов с дополнительной информацией. В Достижения в системах обработки нейронной информации, страницы 817–824, 2008 г.

[10] М. Ли, Д. Г. Андерсен, Дж. У. Парк, А. Дж. Смола, А. Ахмед, В. Йосифовски, Дж. Лонг, Э. Дж. Шекита и Б. Су. Масштабирование распределенного машинного обучения с помощью сервера параметров. На 11-м симпозиуме USENIX по разработке и внедрению операционных систем, OSDI '14, Брумфилд, Колорадо, США, 6–8 октября 2014 г.,
страницы 583–598, 2014 г.
[11] Дж. Линь и Д. Рябой. Масштабирование инфраструктуры интеллектуального анализа больших данных: опыт твиттера. Информационный бюллетень ACM SIGKDD Explorations, 14 (2): 6–19, 2013.
[12] HB McMahan, G. Holt, D. Sculley, M. Young, D. Ebner, J. Grady, L. Nie, Т. Филлипс, Э. Давыдов, Д. Головин, С. Чиккерур, Д. Лю, М. Ваттенберг, А. М. Храфнкельссон, Т. Булос и Дж. Кубица. Прогнозирование кликов по рекламе: вид из окопов. На 19-й Международной конференции ACM SIGKDD по знаниям
Открытие и интеллектуальный анализ данных, KDD 2013, Чикаго, Иллинойс, США, 11–14 августа 2013 г.
[13] JD Morgenthaler, M. Gridnev, Р. Сочук и С. Бхансали. В поисках долга сборки: опыт управления техническим долгом в Google. В материалах третьего международного семинара по управлению техническим долгом, 2012 г.
[14] Д. Скалли, М. Э. Оти, М. Поль, Б. Спицнагель, Дж. Хейнсворт и Ю. Чжоу. Обнаружение враждебной рекламы в дикой природе. В материалах 17-й Международной конференции ACM SIGKDD по открытию знаний и интеллектуальному анализу данных, Сан-Диего, Калифорния, США, 21–24 августа 2011 г.
[15] Ценные бумаги и E. Комиссия. SEC обвиняет Knight Capital в нарушении правила доступа к рынку, 2013 г.
[16] А. Спектор, П. Норвиг, С. Петров. Гибридный подход Google к исследованиям. Коммуникации ACM, 55, выпуск 7, 2012.
[17] А. Чжэн. Проблемы создания массовых инструментов машинного обучения. SE4ML: Разработка программного обеспечения для машинного обучения (семинар NIPS 2014).