Примечание: эта статья первоначально появилась в моем собственном блоге по этой ссылке.
Прошел почти год с тех пор, как я начал работать инженером по машинному обучению на ранней стадии стартапа. Это была поездка на американских горках, если не сказать больше. И я так многому научился за тот же период. Сегодня я подумал о том, чтобы поразмышлять над извлеченными уроками и подвести итоги в своем блоге. Список определенно не исчерпывающий, но я постарался охватить самые важные из них. Поскольку список получился длинным, я решил разбить его на две части. Первая часть содержит некоторые уроки, которые более специфичны для применения ML в бизнес-сценариях, а вторая часть будет содержать некоторые уроки гораздо более общего характера. Некоторые из них могут показаться очень тривиальными, но даже в этом случае удивительно, как часто мы склонны упускать из виду или принимать как должное самые тривиальные шаги.
1.Понять проблему (экономическое обоснование): это один из шагов, который кажется очень очевидным, но в то же время этому шагу уделяется недостаточно внимания. Мы должны помнить, что даже если мы создадим модель State of The Art (SOTA) для конкретной задачи, но по какой-то причине она не работает для нашего варианта использования, то она почти бесполезна. Важно, чтобы мы понимали бизнес-кейс, который мы пытаемся автоматизировать или решить с помощью машинного обучения, и пытаемся понять уникальные требования этой проблемы. На этом этапе также важно принять во внимание ожидаемую производительность этой модели. Хотя вы можете захотеть создать наилучшую из возможных моделей, вы должны понимать, что в бизнес-среде существует множество ограничений, которые вам, возможно, придется учитывать. Это может включать в себя наличие ресурсов, времени, и вы должны построить свое решение в рамках этих ограничений.
2. Учет усилий по сбору данных. Если вы участвуете в конкурсе Kaggle, набор данных обычно собирается, обрабатывается и передается вам в надлежащем формате. Но это редко бывает, когда вы пытаетесь что-то решить в реальном бизнес-сценарии. Возможно, вам придется потратить много времени на сбор данных, извлечение данных из разных источников. Вдобавок ко всему, вы можете выполнять какую-то контролируемую обучающую задачу, для которой существуют данные, но нет достоверной информации. Там вам, возможно, придется использовать человеческие ресурсы внутри вашей компании или за пределами вашей компании, чтобы установить истину. Это достаточно затратно как по времени, так и по усилиям. Мало того, довольно часто люди могут по-разному интерпретировать то, что должно быть правильной основной истиной для конкретной точки данных. В таких случаях важно, чтобы инструкции для аннотаций были четкими и актуальными, чтобы не было много места для двусмысленности. В идеале также должен быть надлежащий канал, по которому человеческие ресурсы, создающие наземные истины, могут искать разъяснения, если они не полностью уверены в наземных истинах для конкретной точки данных. Чтобы получить лучшую отдачу от человеческих ресурсов, у нас могут быть методы, которые облегчат их работу (см. пункты 6 и 7).
3. Важность набора тестов. Набор тестов (или, точнее, набор HoldOut) играет очень важную роль в построении модели машинного обучения. Набор тестов — это то, что мы фактически используем для измерения производительности модели. Если тестовый набор не является хорошим представлением фактического распределения образцов, с которыми мы, как ожидается, столкнемся в производственной среде (хотя это может быть довольно сложно предвидеть ранее), то мы не сможем получить хорошую оценку истинная производительность нашей модели. Если нам нужен более глубокий контроль, мы можем создать более одного набора тестов, каждый из которых представляет отдельный аспект модели, которую мы хотим протестировать.
Например, если мы создаем классификатор для прогнозирования модели на основе текста, у нас могут быть разные наборы тестов, один из которых содержит короткие тексты, другой — длинные тексты и так далее. Затем мы можем обнаружить, что модель хорошо работает для коротких текстов и не так хорошо работает для длинных текстов.
4. Выбор архитектуры. Архитектура модели, которую вы выбираете для своей задачи, должна определяться с учетом бизнеса и других ограничений, которые могут возникнуть у вас.
Например, если вы тренируете модель для задачи, требующей времени логического вывода со сверхнизкой задержкой, вы должны помнить об этом, прежде чем использовать модель SOTA со сверхбольшими размерами, которая не сможет дать вам такое время логического вывода с учетом ограничений, которые у вас будет, когда вы развернете его в производстве.
5. Понимание конвейера: понимание потока бизнес-процесса от начала до конца. Вполне вероятно, что ваша модель является частью всего процесса, который зависит от некоторых вышестоящих задач. Таким образом, теоретическая наилучшая производительность зависит от производительности восходящих задач. Если вышестоящие задачи не работают хорошо, нижестоящие задачи тоже пострадают.
Например, у вас может быть бизнес-процесс, в котором есть компонент OCR, за которым следует компонент модели ML. Если производительность OCR составляет 60 %, а производительность модели ML — 95 %, общая производительность конвейера все равно будет составлять 60 % * 95 % ~ 57 %. Короче говоря, низкая производительность восходящих задач полностью обесценивает производительность нижестоящих задач. Таким образом, в этом сценарии тратить больше времени на попытки улучшить производительность модели ML не поможет, здесь вам придется сосредоточиться на процессе OCR.
6. Превращение процесса комментирования в петлю обратной связи: как упоминалось в пункте №. 2, использование человеческих ресурсов для аннотирования наземной истины дорого обходится как с точки зрения времени, так и с точки зрения усилий. Так что, если мы сможем облегчить им задачу и добиться от них лучших результатов, это того стоит. Одна из вещей, которую мы можем попробовать, — это сделать процесс аннотирования более похожим на петлю обратной связи.
Попробуем понять это на примере. Допустим, для конкретной задачи нам нужно собрать 1000 точек данных для обучения. Допустим, аннотаторы аннотируют первые 200 точек данных с нуля. Затем мы обучаем модель (которая может работать не очень хорошо, но, возможно, будет иметь приличный результат) на этих точках данных. Затем для следующей партии образцов мы не просим аннотаторов аннотировать с нуля. Вместо этого мы даем им выходные данные по остальным образцам, используя обученную модель, и просим их просмотреть выходные данные и изменить то, что они считают неправильным. Таким образом, они не аннотируют с нуля, а только предоставляют отзывы о тех, которые они считают неправильными, что сэкономит время. Представьте, например, что всего с 200 примерами мы получаем производительность 80%. Это означает, что из 100 сэмплов аннотатор должен будет изменить только 20 сэмплов, что сэкономит им много времени.
7. Использование потерь для проверки аннотаций: Аннотаторы-люди могут ошибаться. Несмотря на то, что существует много способов попытаться свести к минимуму то, что требует дополнительного ручного труда и, следовательно, является дорогостоящим (например, гарантируя, что более одного человека просматривает каждую аннотацию), более простой и дешевый способ — использовать значение потерь модель. Обратите внимание, что это можно использовать только тогда, когда у нас уже есть достойная модель для задачи, и мы добавляем больше аннотаций для дальнейшего улучшения модели. Здесь новый набор точек данных, аннотированных в последнем спринте, можно просто передать в модель, а значение потерь можно рассчитать для каждой точки данных отдельно. Поскольку потери дают количественную оценку того, насколько запутана модель для конкретной точки данных, мы можем повторно проверить точки данных, для которых потери довольно высоки (скажем, на порядок или два значения выше, чем медианные потери). Предполагая, что к этому моменту модель хорошо понимает задачу, это может помочь указать на неправильные аннотации без каких-либо дополнительных ручных усилий.
8. Наблюдение за моделью: во время бета-тестирования рекомендуется иметь какой-либо процесс контроля качества и цикл обратной связи, чтобы получить представление о том, как работает модель, и точно настроить модель в соответствии с этими данными. Обратная связь. Даже после того, как мы развернули модель в продакшене, мы не должны просто вздохнуть с облегчением и перестать следить за ней. Это связано с тем, что распределение тестового набора (или контрольного набора), на котором мы сравнивали модель, может сильно отличаться от распределения данных, которые она предсказывает в производственной среде. В идеале у нас также должен быть своего рода контроль качества на этапе производства, чтобы гарантировать, что выводы, которые модель делает в производстве, действительно хорошего качества или находятся в пределах уровней производительности, ожидаемых от модели. Если нет, мы должны изучить его, возможно, переобучить его с большим количеством образцов, представляющих случаи, для которых он не работает хорошо.
Список ни в коем случае не является исчерпывающим. Кроме того, важно помнить, что некоторые вещи могут работать хорошо для одного проекта и не очень хорошо для другого проекта. Ждите второй части этой серии статей, в которой я расскажу еще о некоторых уроках, которые я усвоил.
Об авторе: Рвик — инженер по машинному обучению, специализирующийся на глубоком обучении и работающий на ранней стадии стартапа (домен НЛП). Он имеет опыт использования глубокого обучения для автоматизации критически важных бизнес-процессов в производственных условиях и создания пользовательских конвейеров ETL. Свяжитесь с ним в LinkedIn, Medium или напишите по адресу [email protected]. Вы также можете найти больше о нем на https://rwikdutta.me.
