Research Instruction

Инструкция по разработке гипотез анализа текста

Ремарки

Устройство задач

Если Вы не ознакомились с устройством нашей системы labels для issues, крайне рекомендуется это сделать.

Подготовка к началу работы

Перед Вами, как перед исследователем, стоит несколько задач. Назовем их:

• Поиск гипотез;
• Изучение гипотезы на предмет принципиальной применимости;
• Анализ эффективности применения гипотезы в проекте.

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

1. Достаточно универсальны, чтобы быть применимыми к широкому кругу гипотез;
2. Достаточно полными, чтобы предоставлять возможность адекватно ранжировать по ним гипотезы.

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

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

Как исследователь, Вы работаете с гипотезой, которая представляет собой идею о решении/методе решения задачи. Вашей целью является переработать эту идею в то, что называется отчётом исследователя. Отчёт включает в себя:

• Краткое описание гипотезы;
• Характеристики по метрикам;
• Рекомендации по применению, желательно вместе с сравнением с теми решениями, которые применяются в "продакшене" в данный момент, если таковые есть;
• Чёткое описание алгоритма реализации решения, порождённого гипотезой (этот пункт опционален, но крайне желательно его иметь хотя бы в кратком виде).

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

Инструкция

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

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

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

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

5. Составление отчета. В итоге Вам необходимо придать Вашей работе законченный вид, т.е. составить отчет, строго следуя пунктам. В качестве инструмента для составления отчета рекомендуется Jupyter Notebook.

6. Презентация отчета. Этот страшно называющийся пункт всего лишь просит Вас показать Ваш отчёт кому-то из продакшн-команды, чтобы результаты Вашей работы быстрее обработали. Отчёт предоставляется в виде Pull Request, а запросить проверку можно посредством функционала "Request review" в правой части GitHub интерфейса, указав конкретных разработчиков.

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