Сентябрь 2025: библиотека или самодельные книги, Ditto и Launchbar, широкое и глубокое чтение
Делиться
Большинство дней в машинном обучении одинаковы.
Пишу код, жду результатов, осмысливаю их, возвращаюсь к написанию. Плюс промежуточные презентации о своём прогрессе. Но то, что всё в целом остаётся неизменным, не означает, что нечему учиться. Совсем наоборот! Два-три года назад я выработал привычку ежедневно записывать уроки, которые извлёк из своей работы с машинным обучением. Оглядываясь на некоторые уроки этого месяца, я выделил три особенно важных практических урока:
- Для новых проектов выбирайте библиотеки с умом
- Используйте менеджер буфера обмена для сохранения ваших клипов.
- Читайте широко, чтобы читать глубоко
Выбор между библиотеками и самописным кодом
Проекты машинного обучения часто начинаются с одного и того же вопроса: стоит ли разрабатывать все самостоятельно или полагаться на существующие библиотеки?
На самом фундаментальном уровне это может означать выбор между фреймворками, такими как PyTorch или TensorFlow. Когда Towards Data Science ещё выходил на Medium, я был ярым сторонником TensorFlow. Сегодня я гораздо больше склоняюсь к PyTorch. Но этот раздел не о выборе фреймворка на этом уровне.
Вместо этого я хочу сосредоточиться на выборе на уровне проекта.
Представьте, что вам поручено создать новый проект машинного обучения. Требования специфичны: данные с небольшим количеством меток, входные данные — изображения, а также некоторые архитектурные ограничения. Что вам следует сделать?
Хорошей отправной точкой будет поиск проектов на GitHub, которые, возможно, уже отвечают большинству ваших потребностей. Если найдёте тот, который соответствует на 100%, отлично — используйте его. Если ничего похожего не найдёте, это тоже отлично, ведь теперь решение очевидно: вам придётся собрать его самостоятельно.
Более сложный случай — когда вы что-то находите, но оно не совсем подходит. Стоит ли патчить существующую кодовую базу, пока всё не заработает? Или быстрее реализовать собственное решение с нуля?
Однозначного правильного ответа не существует, но я нашел несколько полезных практических правил:
Если вам нужен точный контроль над каждым аспектом конвейера машинного обучения → создайте его самостоятельно.
Если вам нужен просто стандартный процесс обучения → воспользуйтесь библиотекой.
Если вы хотите изменить существующий метод → начните с библиотеки, в которой он уже есть.
Если вы внедряете свой собственный метод → делайте это сами.
Ещё один фактор, который стоит учитывать, — это долговечность. Код, который вы пишете сами, находится под вашим полным контролем: никаких внезапных критических изменений, никаких скрытых ошибок, скрытых в сторонних репозиториях. С другой стороны, библиотеки могут предоставить вам годы накопленного опыта тестирования и оптимизации, то, что вам было бы сложно воспроизвести самостоятельно. Искусство заключается в том, чтобы найти баланс между скоростью разработки сейчас и удобством поддержки в будущем.
Иногда я даже обнаруживал, что лучший баланс достигается, когда начинаешь с библиотеки для быстрого прототипирования, а затем самостоятельно переписываешь ключевые части, как только понимаешь, что работает. Таким образом, я получаю быструю обратную связь на ранних этапах, но при этом сохраняю полный контроль над наиболее важными частями. По моему опыту, лучшие библиотеки, по крайней мере для проектов, требующих серьёзных исследовательских усилий, — это те, которые воспринимаются как исследовательский код.
Два противоположных примера — библиотеки Avalanche и Mammoth. Avalanche гораздо более полноценна, и всё в ней хорошо абстрагировано. С другой стороны, Mammoth больше похожа на расширенный исследовательский проект, где вы по-прежнему можете напрямую контролировать методологическую часть. Такие библиотеки, как Mammoth, могут объединить лучшее из обоих миров.
Вышеуказанные рекомендации не решат дилемму «я против библиотеки» каждый раз, но они позволили мне подойти к ней более системно. С годами, и в этом сентябре, они избавили меня от дней нерешительности.
Преимущества менеджеров буфера обмена
Предположим, вы управляете проектом машинного обучения из командной строки. Вы запускаете его так: python3 run.py —param1 —param2
Затем ещё один, с другими параметрами. И ещё один. Вскоре вы проводите несколько заходов и хотите сравнить результаты.
Наивный способ — вручную копировать каждый вывод в централизованное хранилище: копировать, вставлять; копировать, вставлять; копировать, вставлять. Пока в какой-то момент вы не перезапишете неправильный результат и не придётся начинать заново.
Именно такая ситуация возникла у меня в начале этого месяца. Когда я настраивал новый проект (решив сделать это самостоятельно, а не использовать библиотеку; см. выше), я также провёл тестирование кода. Мне хотелось проверить, всё ли работает без ошибок. Поэтому я проверил несколько настроек параметров, часто меняя один-два аргумента от запуска к запуску. Поскольку мой проект был проектом машинного обучения (ML), а значит, включал обучение моделей машинного обучения, выполнение скрипта занимало некоторое время, и мне приходилось ждать, пока я смогу протестировать следующий параметр. Запуск отдельных запусков был невозможен из-за загруженности кластера.
Таким образом, между тестированием двух параметров я сосредоточился на настройке проекта и исправлении ошибок. Затем, убедившись, что параметр успешно протестирован, я запланировал следующий тест и продолжил настройку проекта.
Как вы можете себе представить, эта стратегия работает только до определённого момента. Повторив это несколько раз, я потерял счёт уже протестированным комбинациям параметров. Поскольку это был всего лишь этап настройки, я ещё не реализовал полноценное тестирование и сбор результатов; обычно я делаю это позже. К счастью, моя привычка копировать команды, вставлять их и затем изменять аргументы избавила меня от необходимости запускать тест дважды. Это, в сочетании с использованием менеджера буфера обмена, избавило меня от необходимости запускать тест дважды.
Эти инструменты не только сохраняют последний элемент, но и ведут историю всех скопированных вами файлов. В любой момент вы можете вернуться к списку и выбрать нужный клип*.
Настоящее преимущество менеджеров буфера обмена заключается в том, что они снижают когнитивные издержки. Вместо того, чтобы постоянно беспокоиться: «Не перезаписал ли я последнюю копию?» или «Где сохранил этот фрагмент?», вы освобождаете ресурсы мозга для решения текущей задачи. Это один из тех небольших инструментов**, который выглядит неказисто, но со временем становится всё эффективнее.
И, что важно, речь идёт не только об экспериментах. То же самое касается подготовки доклада, написания черновика статьи или сбора данных из разных источников. Попробовав менеджер буфера обмена достаточно долго, вы удивитесь, как раньше обходились без него.
Могу подтвердить это по собственному опыту. На своих Mac я годами пользуюсь менеджером буфера обмена Launchbar (хотя он гораздо шире!), а на Windows установил бесплатную утилиту Ditto. Она часто помогала мне, когда я что-то вырезал, а затем удалял исходный контент (из которого я хотел что-то вырезать). При этом последние фрагменты всегда были доступны по одной команде, мгновенно предоставляя мне необходимую информацию.
Глубина и широта чтения
Этот же проект также напомнил мне о чтении статей. Его реализация требовала объединения последних методологических достижений с табличными данными. Как всегда, потенциально релевантных работ было море. Вопрос был в том, что читать, а что можно пропустить.
На этот раз решение далось легче, чем ожидалось. Последние несколько месяцев я регулярно читал статьи — не слишком усердно, но постоянно, с перерывами. Это дало мне чёткое представление о моей области исследований. Что ещё важнее, я также читал смежные работы, то есть статьи, которые не полностью относятся к моей области, но решают очень похожие задачи.
Обширное чтение помогло мне выявить связи между областями знаний и понять, какие методы действительно актуальны. Вместо того чтобы чувствовать себя подавленным, я мог быстро определить, какие статьи заслуживают моего внимания, а какие можно спокойно проигнорировать.
Но польза выходит за рамки эффективности (и знаний, которые являются главной целью чтения). Взгляд за пределы своей основной области часто рождает идеи, которые иначе бы не пришли вам в голову. Для меня идеи из смежных областей иногда в конечном итоге формируют основу моих собственных проектов. Другими словами, широта — это не просто подготовка к глубине, это ещё и источник творчества.
Со временем практика чтения с близкого расстояния развивает устойчивость. Области исследований быстро меняются, и методы, модные сегодня, завтра могут быть забыты. Но если вы развиваете широту взгляда, вам легче адаптироваться: вы уже знаете смежные области и можете двигаться вместе с ними, а не быть увлекаемыми ими.
Источник: towardsdatascience.com
