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

1656546375 kak ya ispolzoval kraudsorsing chtoby pomoch v spasatelnyh operacziyah v

Арнау Бансал

За ночь я создал веб-сайт, позволяющий людям находить срочные запросы

RTrVKBeZKPcQc5wSd9JCvUgKBNGrPVSM2yut

В августе 2018 года наводнения уничтожили штат Керала. Одна шестая часть населения пострадала непосредственно. Государство нанесло имущественный ущерб на сумму 3 миллиарда долларов.

Я Арнав, 18-летний юноша из Бангалора, окончивший школу в марте этого года. Когда происходили наводнения, я наткнулся на спасательный проект Кералы. Это было движение разработчиков-добровольцев, решавших технические проблемы, связанные с наводнением в Керале, используя Интернет.

Сайт предоставил важные услуги. Он собирал просьбу о помощи от пострадавших. Это помогло волонтерам и спасателям найти их и найти лагеря помощи. Он обеспечивал визуализацию сил реагирования на катастрофы.

Исследуя проект на GitHub и Slack, я нашел конкретную проблему, которую я мог бы решить.

Слишком много запросов

После массового наводнения, раз в 100 лет, было большое количество просьб о помощи.

Я наблюдал, как поступают новые запросы каждый раз, когда я обновляю конечную точку API на веб-сайте спасения. Когда я впервые обнаружил это, я потратил около получаса, просто перечитывая запросы людей.

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

Но тревожные были среди моря запросы, которые, казалось, не были мгновенными или имели мало данных.

И это были только английские. Я не мог прочесть запросы, написанные малаялам (на языке Кералы).

Это заставило меня задуматься: как запросы были определены приоритетами? Я спросил вокруг. Конечно, люди отмечали, что это реальная проблема.

Понимание данных

Я думал о двух подходах к определению срочности запросов.

Обработка природного языка (NLP)

Такие слова, как «Срочно», «Младенец», «Беременная» или «В ловушке», указывают на срочность и могут использоваться для классификации запросов.

Но с данными было несколько проблем: запросы были на английском и малаялам. А иногда малаялам писали по английскому алфавиту.

Многое было написано в спешке.

Некоторые предлагали сначала переводить запросы на английский язык, прежде чем применять НЛП. Но перевод потерян, и я был уверен, что это не сработает.

И, наконец, я почувствовал, что срочность в большинстве своем имеет контекст. Хорошо ли справится с этим НЛП? Существующий анализ настроений может определить, является ли текст положительным, отрицательным, радостным или печальным. Но это не измеряет срочность.

И времени на разработку новой модели не было. Особенно учитывая языковую проблему.

Краудсорсинг

Я был уверен, что люди найдут некоторое время для определения срочных запросов.

Они имели смысл информации, свидетельствующей о срочности, в которой компьютеры плохо умеют.

Я представил себе веб-сайт, который будет получать и показывать запросы с спасаемого веб-сайта. Волонтеры оценивали срочность по соответствующей шкале не срочно к критически (значение от 0 до 3), с опцией спама (–1). Они могли пропускать запросы, если не знали языка.

Поэтому я принялся за работу.

Реализация

Сначала я подумал о том, чтобы создать функцию краудсорсинга в keralarescue.in

Проект был открыт. Многие создавали отдельные, но связанные инструменты на одной платформе. Мне было смысл устроиться прямо у него.

Но у меня были некоторые волнения:

  1. Я не был уверен, удастся ли идея. Я не хотел оставлять мертвый вес на платформе, на которую многие полагались.
  2. Платформа была написана на Django с использованием PostgreSQL. Я мало с ними знаком, и я не хотел экспериментировать-учить.
  3. Система обзора помешала бы быстрому повторению.

Поэтому я решил создать свой инструмент вне зависимости от основной платформы.

Если бы это сработало, я заставил бы их объединить мои данные. Если этого не удалось? Эх

Полное масло

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

Моя идея заключалась в том, чтобы использовать конечную точку API из keralarescue.in для отображения запросов в помощь. Конечно, я кэшировал его на своем конце, чтобы не утруждать основной веб-сайт.

Я стал разрабатывать платформу. Я начал с создания моделей данных. Затем я работал над функциями и конечными точками API. Наконец-то я начал работать над фронтендом. Мой стек включал Firebase и VueJS для быстрого прототипирования.

Я планировал использовать доверительные интервалы Уилсона для оценки баллов. (Используется для сортировки уверенности на Reddit) Они являются улучшением по сравнению с простыми средними, поскольку учитывают количество оценок.

Но я очень торопился, поэтому решил реализовать это позже. Без данных это мало пользы.

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

Около 8 утра мой макет был готов. И я был готов уснуть. Я опубликовал ссылку на GitHub и отправился спать, когда состоялся первый просмотр страницы в Google Analytics.

Я без проблем уснул.

Привлечение людей на борт

У меня были пользователи.

Когда я очнулся в полдень, я прежде всего проверил аналитику. ~30 посещений. И сейчас у меня было два пользователя. Из штата Керала. Вау.

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

  • Я отказался от опции спама. Я узнал, что люди не уверены, какие запросы спам. Многим не хватало информации. Это могут быть вполне действительные запросы от спешащих людей или людей, плохо владеющих техникой.
  • Я реализовал счет Вильсона. Я создал конечную точку API, возвращавшую значение доверия от 0 до 1 на основе всех собранных оценок пользователей. Идея заключалась в том, чтобы вынудить keralarescue.in использовать эту конечную точку для периодического обновления набора данных. Значения можно использовать для сортировки и поиска наиболее срочных запросов
  • Я добавил страницу для отображения срочных запросов. Я хотел поскорее сделать этот инструмент полезным.

Приблизительно в 16:00 я решил объявить об этом на Slack и Github.

Это оказалось переломным моментом, и в течение следующих нескольких часов у сайта было 20–30 пользователей онлайн. Они были из всей Индии, а также из США. Пользователи из Кералы продолжали работать до поздней ночи, сортируя запросы в два часа ночи.

Я заметил, что люди медленнее относились к запросам на оценку, чем я ожидал.

На следующий вечер я бы узнал почему.

Триажная группа

На следующий день я закончил большинство работ по разработчику. Многие начали связываться со мной. Им понравился мой проект – особенно простой интерфейс.

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

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

Они активно звонили запросчикам и получали обновления по их ситуации. Они оценивали срочность не по содержанию текста, а по на самом деле общаясь с пострадавшими людьми. ВАУ

Я понял, что моя база данных содержит более ценную информацию, чем я думал. Мы непосредственно помогали волонтерам добраться до жертв. На телефон поступали сообщения с благодарностью за работу.

Утрата источника данных

Еще в основном проекте люди готовились к большому событию. Правительство Кералы собиралось публично объявить спасательный веб-сайт. Следовало ожидать интенсивного движения.

Основной сайт предоставлял много функций. Тепловые карты запросов, пожертвований, помощи лагерей, координации волонтеров, объявлений, вы понимаете суть.

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

Вроде бы все работало, за исключением одной вещи: они сняли конечную точку API, от которой я зависел.

Теперь я знал, что конечная точка, которую я использовал, не будет масштабироваться. Он вернул все запросы сразу. Ближе к концу его life, он возвращал набор данных размером 10 МБ. Он создан для разработки, а не для производства.

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

Я связался с командой. Они строили альтернативу. Но им осталось многое построить, поэтому я старался не толкать.

Мой сайт продолжал работать без проблем, а группы сортировки (тогда их было несколько) продолжали работать, хотя и без новых данных.

Новые возможности?

В этот момент я стал думать о путях улучшения.

Непосредственной проблемой стал приток большого количества новых данных, когда альтернативный маршрут стал доступен. И какие еще улучшения я мог бы сделать?

Я продумал некоторые особенности.

  • Когорты по времени: назначьте определенный процент пользователей для обработки только новейших запросов. Также назначьте пользователей в разделы старых запросов.
  • Фильтры Bloom: Это эффективный способ проверить членство в наборе. Я мог бы использовать цветочные фильтры для многих вещей: убедиться, что мы исчерпали все запросы, и ограничить повторные посещения.
  • Обновление статуса: Я мог бы создать функцию, чтобы люди обновляли статус запросов Это была тривиальная конструкция и люди ее просили. Но люди, работающие на главной платформе, сказали мне, что они уже ее строят.
  • Веб-сокеты: Я мог передавать новые запросы на сайт в режиме реального времени, когда они поступали. В сочетании с обновлениями статуса и временными когортами мы получим подробную информацию о запросах, как только они поступают.

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

Подведение итогов

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

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

Когда день закончился, люди из сортировочных групп почувствовали смену.

Большинство жертв, которым они звонили, сообщили, что их недавно спасли. Оказывается, начались спасательные миссии на земле.

Это была отличная новость. Приблизительно в 5 утра я позвонил Нишанту. Он поддерживал связь с чиновниками, контролировавшими спасательные операции. Мы упаковали данные с веб-сайта и электронных таблиц и передали.

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

Уроки

  • Простота: Многие люди писали мне, что им нравится мой сайт Я не дизайнер, но мое решение оставить UX просто помогло людям быстрее присоединиться.
  • Компьютер дешевый: Все это было размещено в Google Cloud Platform. Это стоило мне меньше одного доллара, учитывая мои бесплатные кредиты уровня. Если бы я знал, насколько это будет дешево, я бы создал программу, которая тяжела на сервере.
  • Возвратный: Я хотел бы полностью перейти на подробную платформу сортировки Волонтеры придумали импровизированное решение, но задним числом я бы скорее поставил платформу с этими функциями.
  • Сети важны: Люди хотели помочь Начальная группа из 30 человек выросла за два дня в группу из 230, когда люди обращались к своим друзьям и знакомым. Люди присоединились из Кералы, остальной части Индии и со всего мира.

Я встретил много удивительных людей. Я многому научился, техническому и другому. Во всем этом самым невероятным было чувство быть на одной странице с тысячами других людей.

Если моя работа заслуживает статьи, то проект, в котором я был, заслуживает книги.

Что касается меня, то я общаюсь с людьми, которые участвуют в реагировании на стихийные бедствия, чтобы поучиться на их опыте и знаниях.

Чуть больше обо мне: у меня год перерыва, чтобы углубиться в криптоэкономику. Я получил навыки веб-разработки еще в 10 классе, когда проводил хакатон в школе.

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

  • Энн Томас, волонтер из групп сортировки, написала здесь о своем опыте
  • Спасибо доктору Харикришнану, доктору Нишанту, Аджиту Чандрану, Прасаду Пиллаю, которые помогли организовать группы сортировки

Добавить комментарий

Ваш адрес email не будет опубликован.