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

В 99P Labs мы понимаем, что технологии меняются быстрыми темпами, и в большинстве случаев становится трудно разработать или приобрести соответствующие наборы навыков (например, бюджет, время, ресурсы и т. д.), чтобы исследовать эти чрезвычайно большие и сложные наборы данных в то время. необходимости. Мы хотели решить эту проблему пробела в навыках. Вдохновением послужила простая идея, т. е. способ уменьшить трение при опросе этих наборов данных, а также предоставить опыт, который дал бы возможность прикладного обучения. Из этого тезиса был сформирован проект под названием «Аналитик данных в коробке».

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

Затем мы погрузились в функции, рабочий процесс и взаимодействие с пользователем и использовали Google Search и Amazon Alexa в качестве вдохновения для создания концепции нашего приложения. Мы хотели, чтобы это приложение делало 3 вещи:

  1. Возьмите простой вопрос на английском языке в качестве входных данных
  2. Показать визуализацию и вывод данных
  3. Предоставьте возможность обучения технологии SQL на месте

Мы представили эту концепцию партнеру по запуску нашего университета (Университета штата Огайо) — компании Transity, чтобы провести мозговой штурм по разработке, которая войдет в концепцию этого проекта. Прежде чем мы углубимся в инженерные детали, посмотрите небольшой GIF-файл приложения и того, как оно работает:

Основной инженерной мыслью и временем, затраченным на это приложение, была модель обработки естественного языка (NLP). В следующем разделе Райан В. (соучредитель Transity) объясняет сложные детали используемой модели НЛП:

«Чтобы более подробно остановиться на некоторых проблемах обработки естественного языка, подумайте о некоторых его особенностях. Вероятно, вы можете передать одну и ту же информацию, используя в основном одни и те же слова, по крайней мере, четырьмя различными способами, просто изменив порядок. Добавьте к этому синонимы, и теперь вы, вероятно, сможете сказать одно и то же сотней разных способов. Взять эту обширную неоднозначную область и перевести ее на жестко структурированный конкретный язык SQL, который базы данных используют для обработки запросов, было нелегко. Первоначальные концепции проекта основывались на подходе «снизу вверх», когда столбцы и базовая табличная информация объединялись, а затем объединялись в справочную таблицу с простыми вопросами и сгенерированным SQL. После разработки этой таблицы поиска естественный язык можно было сравнить с сгенерированными вопросами, чтобы найти наиболее похожий. Этот запрос может быть выполнен, и результаты будут отображаться в приложении. Однако мы быстро поняли, что в этом подходе есть недостатки — во-первых, этот метод делает соединения почти невозможными, а во-вторых, сложность проблемы экспоненциально зависит от количества столбцов. Этот метод породил бы огромное количество потенциальных вопросов в таблице поиска, и очень немногие из них представляли бы реальные вопросы.

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

Мы определили два набора данных, которые часто используются в качестве ориентиров в этой области: WikiSQL [link] и Spider [link]. WikiSQL фокусируется на более простых запросах, состоящих из предложения select (с функциями агрегирования) и предложения where. Это решает множество основных вопросов, таких как у скольких автомобилей громкость радио превысила 15?. С другой стороны, набор данных Spider гораздо более обширен по типам запросов, которые он содержит, начиная от простых вопросов, подобных тем, которые можно найти в наборе данных WikiSQL, и заканчивая теми, которые требуют вложенных подзапросов и сложных соединений таблиц для ответа. .

Чтобы реализовать генерацию запросов, мы приняли две разные высокопроизводительные модели и развернули их параллельно, чтобы сравнить точность и ограничения каждой из них. Это модели SQLova [ссылка] и IRNet [ссылка]. На момент внедрения эти модели являются лидерами по точности в данной области.

Хотя обе эти модели показали хорошие результаты на своих тренировочных наборах, каждая из них решает две немного разные задачи и, как таковые, имеет компромиссы. SQLova очень хорошо справляется с созданием простых вопросов и определением правильных столбцов, но ограничена отсутствием объединений и сложных агрегатов. IRNet поддерживает гораздо более сложные вопросы и генерацию запросов, но его производительность немного снижается в некоторых из более простых комбинаций. Мы обнаружили, что использование обеих моделей в одной и той же среде позволяет вам создать ансамбль практически «человек в цикле», где интуиция подсказывает вам, какой из сгенерированных SQL-запросов даст наилучшие результаты».

Сгенерированные запросы отправляются в наш Presto Engine поверх Apache Hive, чтобы обеспечить производительность и время отклика для очень больших и сложных наборов данных. Затем результаты и визуализация отображаются во внешнем приложении, созданном с использованием фреймворка Angular.

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

Мы надеемся вскоре сделать это приложение общедоступным на вашем портале разработчиков 99P Labs [ссылка] , но пока что, если вы еще не зарегистрировались, мы будем рады, если вы присоединитесь к нашему исследовательскому сообществу. Если у вас есть идеи, отзывы, вопросы или возможности для совместных исследований, обращайтесь сюда [https://developer.99plabs.io/contact/].