В настоящее время большинство компаний заинтересованы в использовании статистики, машинного обучения и глубокого обучения. Если бы они могли создавать многообещающие услуги с помощью этих технологий, они могли бы быть более конкурентоспособными, чем раньше. Эти типичные примеры — Google и Amazon.
Тем не менее, большинство компаний также не являются зрелыми в этой теме. На самом деле, некоторым компаниям предстоит решить большую проблему, не используя машинное обучение или искусственный интеллект. Например, если вы хотите разработать систему часто задаваемых вопросов, сначала вам следует создать шаблоны с помощью основных методов обработки текста, таких как токенизация, теги POS (частей речи) и Bag-of-Words. Они не привлекательны, но надежны и понятны. Затем мы делимся отчетами и быстро доставляем информацию пользователям в виде списка часто задаваемых вопросов и чат-бота, основанного на сопоставлении ключевых слов.
После того, как вы добьетесь небольшого успеха, возможно, вы создадите команду и будете работать над более сложными задачами. Кто-то использует решения машинного обучения, другие исследуют передовые методы НЛП. На этом этапе сложнее всего поделиться своими знаниями и кодами в команде.
Команда по науке о данных, как правило, зависит от способностей и интеллекта каждого члена. Это связано с тем, что наш рабочий процесс нелегко разделить на небольшие подзадачи, такие как разработка приложений. Обычно мы работаем от извлечения данных до проверки модели или разработки API. Поскольку наша работа сложна и требует нескольких навыков, мы должны приобретать новые навыки и знания.
Однако мы не можем знать всего в жизни. Конечно, мне есть что изучить в области науки о данных. Другие члены также. Например, я плохо разбираюсь в обработке сигналов и акустическом распознавании, но понимаю и развиваю обработку естественного языка. А сотрудники команды уже разработали звуковые задания. Когда мне поручают задачу по распознаванию голоса, я с удовольствием использую коды, написанные членом моей команды. В этой ситуации все, что мне нужно сделать, это добавить новые коды, относящиеся только к моим задачам.
Чтобы реализовать эту идею, я начал создавать два шаблона cookiecutter, вдохновленные cookiecutter-data-science. Они все еще бета-версии, но доступны cookiecutter. Если вы пытаетесь,
Основная концепция следующая,
- Простой
- Общий код
- Явный
У каждого проекта есть предполагаемая ситуация. Простая версия — это более минимальная версия науки о данных cookiecutter. Этот шаблон подходит для одного репозитория проекта или службы машинного обучения с разработкой API.
С другой стороны, шаблон на основе проекта предполагает, что несколько аналитиков работают над несколькими проектами, потому что обычный проект по науке о данных имеет несколько подпроектов. Например, служба ЕС. Если вы анализируете страницу продукта продавца, вы можете попробовать темы, посвященные анализу текста, прогнозированию цен, тегам изображений и так далее. В этом случае удобно собрать эти проекты в один репозиторий, потому что этот проект — это предметно-ориентированные задачи.
Давайте посмотрим на пример, чтобы начать проект EC с анализа текста,
pip3 install cookiecutter cookiecutter https://github.com/hayata-yamamoto/cookiecutter-project-based-data-science
Вы должны ввести несколько фрагментов информации,
- имя репозитория напр.) продавец_аналитика
- название проекта напр.) текст
- описание репозитория
Тогда вы получите следующую структуру.
seller_analytics/
├── docs
└── seller_analytics
├── core
│ ├── __pycache__
│ ├── config
│ ├── datasets
│ ├── features
│ └── models
├── data
│ └── text
│ ├── interim
│ ├── processed
│ └── raw
├── modules
├── tests
│ ├── core
│ └── text
└── text
├── notebooks
│ ├── exploratory
│ └── predictive
└── src
├── datasets
├── features
├── models
└── tasks
Через некоторое время вы хотите добавить новый проект о цене_предсказания,
python3 manage.py start-project price_prediction
Затем вы получаете,
seller_analytics/
├── docs
└── seller_analytics
├── core
│ ├── __pycache__
│ ├── config
│ ├── datasets
│ ├── features
│ └── models
├── data
│ ├── price_prediction <- created
│ │ ├── interim
│ │ ├── processed
│ │ └── raw
│ └── text
│ ├── interim
│ ├── processed
│ └── raw
├── modules
├── price_prediction <- created
│ ├── notebooks
│ │ ├── exploratory
│ │ └── predictive
│ └── src
│ ├── datasets
│ ├── features
│ ├── models
│ └── tasks
├── tests
│ ├── core
│ ├── price_prediction <- created
│ └── text
└── text
├── notebooks
│ ├── exploratory
│ └── predictive
└── src
├── datasets
├── features
├── models
└── tasks
Как вы знаете, manage.py вдохновлен Django. Если вы добавляете новые команды, вы можете отредактировать файл core/commands.py.
from typing import NoReturn import click from .path_manager import PathManager @click.group() def cmd(): pass @cmd.command() @click.argument('name', type=str) def start_project(name: str) -> NoReturn: PathManager(project=name).create_project()
И я создал path_manager на core/, чтобы легко получить доступ к пути проекта.
>>> from seller_analytics.core.path_manager import PathManager
>>> manager = PathManger(project='text')
>>> manager.SRC PosixPath('/user_directory/seller_analytics/seller_analytics/text/src')
Явно разделяя проекты, мы можем избежать неожиданных конфликтов при слиянии веток. Кроме того, управление прогрессом также легко, потому что мы можем управлять несколькими проектами в одном репозитории.
Когда вы найдете общие операции, основной каталог будет полезен. Этот репозиторий предназначен для хранения кодов, которые являются общими в проекте. Во-первых, вы разрабатываете подпроекты. Найдя общие функции, переместите коды в основной каталог.
Если вы хотите построить эффективную и продуктивную команду аналитиков, рекомендую использовать mypy, autoflake, autopep8, Sphinx (api-doc). Коды становятся более явными для mypy, читаемыми для autoflake, autopep8 и доступными для Sphinx. Эти библиотеки будут добавлены в мои шаблоны в будущем.
Эта работа имеет много улучшений. Если вас заинтересовала моя работа, давайте примерим ваш проект и отправим запросы на добавление функций. Жду соавторов.
Спасибо за чтение.
