Открытый набор данных должен быть максимально доступным. Что мы делаем, когда их нет?

5-звездочная схема качества открытых данных

Как Тим Бернерс-Ли (человек, стоящий за www, на всякий случай, если вы не знаете) заявил в своем посте 2006 года, ценность, добавленная Интернетом, заключается в неожиданном повторении. использование информации. Более того, сама сеть — это не то, что именно есть, а как они связаны. Затем он предлагает 5-звездочную схему развертывания, которая своего рода измеряет, насколько «открыты ваши данные». Идея проста: чем больше подключений, тем лучше, и каждая дополнительная звезда предполагает, что данные соответствуют критериям предыдущих шагов.

  1. 🌐🔓©️ Он находится в сети под публичной лицензией 🌐🔓©️
  2. ️🗄️🤖👁️‍🗨️ Он структурирован и машиночитаем 🗄️🤖👁️‍🗨️
  3. 🆓🗃️🧾️ Его формат непатентованный, и он задокументирован 🆓🗃️🧾️
  4. #️⃣ℹ️📍 Формат RDF #️⃣ℹ️📍
  5. 🛰️🔃🔗 RDF с идентификаторами (url) на полезные источники данных 🛰️🔃🔗

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

Несколько правительств по всему миру придерживаются принципов открытых данных. Например:

Проблемы с беспорядочными полуструктурированными данными

Одним из бразильских проектов по открытым данным является Embrapa’s Digipathos. Это набор данных компьютерного зрения, содержащий изображения болезней растений и их описания.

Бразильская корпорация сельскохозяйственных исследований (бразильская аббревиатура: Embrapa) является государственной исследовательской корпорацией, входящей в состав Министерства сельского хозяйства Бразилии. (Википедия)

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

И тут мне пришлось столкнуться с неприятной правдой: данные не настолько «открыты», как следовало бы (и как я хотел). Реальная картина такова: API нет, глобальной кнопки загрузки нет. Вы просто продолжаете нажимать на все картинки, загружая их пачками одну за другой. Основываясь на обсуждении, начавшемся с этого поста, я бы скорее сказал, что у Digipathos только одна звезда. Я думаю, можно спорить о том, насколько «машиночитаемый» и «структурированный» набор данных. Я не верю, что это настолько «читабельно», насколько могло бы. В эпоху API мы можем упростить доступ к ресурсам. Хорошо, мы можем искать нужные изображения, но это нужно делать вручную (вместо использования инструкций кода). Кроме того, «структура» здесь ограничена пакетами изображений, метаданные больше не найдены (в отличие от агрегированной информации, такой как количество образцов на съедобное или количество образцов на заболевание).

Конечно, это не редкость. Я часто слышу/читаю истории о том, что неструктурированные данные открыты или нет. Любой специалист по данным, желающий внести свой вклад, потратит часть своего времени на выборку/очистку/структурирование/адаптацию образцов (на самом деле шаги, связанные с данными, являются наиболее трудоемкими и важными во всем конвейере).

Навигация по ограниченным ресурсам для загрузки открытых данных

Озадаченный тем, как можно загрузить набор данных, я искал проекты в Github, которые могли бы выполнить эту работу. Я нашел многообещающий, названный digipathos-plant-disease-img-db-downloader, написанный на Python пользователем george-un. Слава ему! Его код отлично справляется со своей задачей.

Предназначенный для использования в CLI, проект содержит сценарии, которые вместе отвечают за извлечение, загрузку и распаковку образцов в папки. «Отлично, — подумал я, — люди по всему миру могут получить доступ к набору данных, используя его». Но CLI мне показался немного странным… Как инженер машинного обучения, я привык получать доступ к Data Lakehouses с помощью кода. Я обычно пишу конвейеры, которые потребляют данные напрямую. По замыслу они должны быть автоматизированы. Взаимодействие с человеком не требуется. Конечно, проект Джорджа Ына великолепен. Наличие ресурса всегда лучше, чем его отсутствие, но использование CLI полезно только на этапе разработки. Если инженеру потребуется предоставлять команды CLI каждый раз, когда необходимо обновить модели машинного обучения, это будет гибель!

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

Рефакторинг: резюме

В этот момент мои мысли были примерно такими: «Чувак, если бы этот проект можно было использовать в коде как библиотеку, это был бы отличный ресурс для тех, кто хочет документировать свои проекты на основе дигипатоса от начала до конца». Для тех, кто хочет загрузить набор данных с помощью кода, пакет имеет основополагающее значение. Затем я решил провести рефакторинг проекта Джорджа, надеясь упростить доступ сообщества к набору данных (а затем, надеюсь, перейти к настоящему открытому набору данных). Более того, предоставление строк документации и тестов сделало бы код более предсказуемым и документированным.

Пришло время раскошелиться и начать кодировать…

Чтобы понять внутреннюю работу процесса загрузки, я последовательно выполнял каждый шаг. Загрузка запускается при вызове сценария run.py. Здесь можно определить, следует ли загружать все изображения или только обрезанные. Затем run.py вызывает функцию, которая выделяет другие. Затем процесс выглядит следующим образом:

  1. Создайте структуру папок для загрузки и разархивированных образцов (tmp/ и dataset/);
  2. Извлечение метаданных образцов (имя файла, размер, ссылка и формат);
  3. Скачать заархивированные образцы;
  4. Убедитесь, что количество загруженных zip-архивов соответствует количеству извлеченных метаданных (т. е. загрузка была выполнена успешно);
  5. Разархивируйте файлы;
  6. Удалите временную папку (та, в которой хранятся zip-файлы);

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

Я понимаю, что «обрезанный» в этом контексте означает, что изображение увеличено с самой болезнью, а не показывает все растительное тело (лист, ветку, плод и т. д.).

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

  1. Добавьте строки документации. Это помогает пользователю понять, что делает функция и как она работает;
  2. Добавьте тесты, чтобы убедиться в поведении;
  3. Удалите глобальные переменные, чтобы предотвратить конфликт и добавить гибкости использования (это новое). Использование локальных переменных экономит время в случае изменения адреса сайта (изначально это глобальная переменная);
  4. Управляйте зависимостями (в данном случае Requests lib) и упаковкой, чтобы пользователь мог pip установить ее в другом проекте (вместо того, чтобы git клонировал репозиторий);
  5. Создавайте возвраты. Эти возвраты предназначены для предоставления информации о самом процессе. Например, если вы пытаетесь загрузить определенный набор изображений, и некоторые из них не загружаются по неизвестной причине, важно указать, что они недоступны, а не просто печатать в терминале. Если вы работаете с конвейером данных, вы можете утвердить, что функция возвращает значение Нет, что гарантирует наличие всех нужных вам изображений.

Так я и сделал. Прежде всего, я переместил необходимые файлы в папку проекта (в данном случае ./digipathos_downloader/digipathos_downloader/). Это были: download.py, run.py и setup_checks.py. Только первый содержит необходимый код, так как run.py предназначен для CLI, а setup_checks.py вообще не используется.

Я начал проект Поэзия и добавил пакет Запросы. Poetry — это инструмент для управления зависимостями, который также используется для создания виртуальной среды. Всем, кто работает с машинным обучением в производстве, обязательно следует ознакомиться с Poetry и его функциями.

Что касается тестов, то в целом они нацелены на достижение двух целей: убедиться, что код ведет себя так, как ожидается, когда ввод в порядке (проверено с помощью возвратов); убедитесь, что код ведет себя должным образом, когда ввод не в порядке (проверено с помощью возникших ошибок). Для этого я использовал библиотеку Pytest, которая является отличным ресурсом для всех, кто хочет протестировать код Python. Его интеграция с вкладкой тестов VScode делает его использование более простым.

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

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

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

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

Последние слова…

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

Конечно, многое еще предстоит сделать. Например, ближе к концу тестов я понял, что мог бы использовать более удобные функции. Более того, рефакторинг кода — это еще не конец. Можно добавлять дополнительные элементы, чтобы все больше и больше приближаться к настоящему открытому набору данных. Например, на основе проекта может быть создан API. Еще одним улучшением является наличие метаданных (количество образцов, образцов на класс, классы, расширения файлов и т. д.), уже доступных в самом проекте, чтобы пользователь мог выбирать, какие образцы ему нужны. Это сократит время загрузки.

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

Для специалистов по работе с данными и студентов: я хочу, чтобы эта история дала вам представление о том, каково работать с данными в реальном мире. Алгоритмы — это всего лишь часть работы. Вы, вероятно, будете работать с беспорядочными наборами данных, не говоря уже о создании собственных инструментов. Я бы сказал, что довольно длинная часть моих задач по кодированию связана с разработкой инструментов. Под этим я подразумеваю написание кода, тестов и строк документации. Поверьте мне: документация имеет значение. Если у вас нет документации, вам нужно будет все протестировать, чтобы понять, как это работает, а это часто занимает много времени. Тесты необходимы, потому что они гарантируют, что все находится на своих местах, и как только вы изменяете части своего кода, неизмененные части по-прежнему ведут себя так, как вы ожидаете (кроме того, что они являются хорошими примерами использования).

Ключевые выводы:

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