В этом блоге я буду документировать свой прогресс в работе над инструментом обработки естественного языка (NLP) в рамках моего комплексного проекта для старшеклассников в Occidental College.

Мой проект

Скажем, я на вечеринке в пятницу вечером, и кто-то спрашивает меня, над чем я работаю для моего комплексного проекта для старшеклассников (или «композиций», для краткости). Я бы, наверное, сказал что-то вроде: «Я создаю инструмент, который, надеюсь, облегчит жизнь программистам». Большинство людей, вероятно, сказали бы: «О, круто», но я уверен, что вы здесь, чтобы узнать больше о том, над чем я буду работать в этом семестре.

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

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

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

Думая о проекте

Разработка POS-тегера оказалась сложнее, чем я ожидал. Большая часть разработки моего проекта Comps заключалась в том, чтобы подумать о масштабах моего проекта и времени, которое у меня есть для его завершения.

Одна из самых трудоемких частей этого проекта — сбор и подготовка данных. Вы знаете, многие проекты машинного обучения и НЛП в наши дни романтизируются, чтобы быть такими простыми, как: «добавьте кучу данных в свою модель и вуаля, у вас есть идеальная модель». Но это не так. В этом проекте подготовка данных является важным шагом к созданию работающего тегировщика. Например, чтобы подготовить данные, я должен просмотреть отдельные слова в отчете об ошибке и присвоить им тег. Например, я вижу слово «The», я знаю, что это статья, и я назначаю тег «AR». Но это отличается для слов, относящихся к предметной области, таких как «componentFile.java» или «.sendTones()», которые не являются английскими словами. Нет никакого способа обойти это. Мне нужно сесть, придумать теги и тщательно аннотировать свои данные.

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

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

Эти два вопроса охватывают две основные идеи моего проекта comps: 1) как правильно аннотировать данные и 2) насколько хорошо этот метод работает, когда он действительно проверен.

Мой текущий прогресс

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