Представьте, что вы фоторедактор в The New York Times. Ранний вечер, за несколько часов до крайнего срока печати, и начинается рассказ об Александрии Окасио-Кортес. Как можно быстрее выполните поиск по запросу «Александрия Окасио-Кортез» в нашем внутреннем фотоархиве и начните сканировать результаты.

Вы видите несколько фотографий Александрии Окасио-Кортес, но они в основном переполнены фотографиями других людей и, что несколько более странно, такими фотографиями:

Почему, черт возьми, изображение заката над фермой является одним из главных хитов «Александрии Окасио-Кортес»?

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

В данном случае подпись такова: «Солнце садится над фермой в Центральной Айове, недалеко от того места, где кандидат в президенты от Демократической партии Берни Сандерс провел сегодня митинг с членом палаты представителей Александрии Окасио-Кортес».

Фраза «Александрия Окасио-Кортес» дословно встречается в этой подписи, поэтому алгоритм считает фотографию идеальным совпадением.

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

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

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

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

Распознать лицо

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

Во-первых, современные модели распознавания лиц по-прежнему плохо распознают цветных людей. В одном из наших первых тестов широко используемый API распознавания лиц с 95-процентной уверенностью сообщил нам, что портрет Александрии Окасио-Кортес был портретом Мишель Родригес. (Это было неправильно.) Даже если модели улучшились с момента этого A.C.L.U. 2018 года. исследования - а нам было непонятно, есть ли у них - этой технологии еще предстоит пройти долгий путь.

Вторую проблему я начал называть «проблемой Air Force One», потому что ее можно проиллюстрировать этой фотографией Air Force One с президентом Трампом на борту:

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

Школа грамматики

Учитывая ограничения распознавания лиц, мы еще раз взглянули на наши подписи. Раньше я называл эти подписи «неструктурированными», но на самом деле они неструктурированы, только если вы компьютер. Для англоговорящего человека подписи аккуратно структурированы в соответствии с правилами английской грамматики, а грамматические темы каждого предложения могут сразу сказать нам, кто изображен на фотографии. Мы подумали, что если бы мы могли просто заставить компьютер распознавать грамматические предметы так же, как это умеет человек, у нас все было бы готово.

Заставить компьютеры извлекать структурированные данные из необработанного текста - это часть исследования обработки естественного языка (N.L.P.). N.L.P. разбивает сложную проблему извлечения смысла на более мелкие и простые задачи. Каждый шаг в N.L.P. Последовательность вносит небольшие изменения в свою копию текста, прежде чем передать ее следующему шагу. Общая последовательность называется конвейером и может выглядеть примерно так:

  1. Ввод: принимает неструктурированный текст как строку.
  2. Tokenizer: разбивает строку на массив дискретных словоподобных единиц, называемых токенами.
  3. Tagger: помечает каждый токен частью речи, например существительным или глаголом.
  4. Парсер: помечает отношения между помеченными токенами. Существительное перед глаголом может быть подлежащим, прилагательное перед существительным может быть модификатором и т. Д.

Хотя каждый шаг в конвейере может показаться загадочным, здесь нет никакой магии. Можно написать приемлемую реализацию с нуля, используя только язык сценариев, словарь и некоторую статистику использования слов. Мы опробовали несколько библиотек, реализованных таким образом, прежде чем перейти к spaCy, набору инструментов Python с открытым исходным кодом, более сложная реализация которого была более точной для нашего случая использования. (Шаги в конвейере выше - это те шаги, которые spaCy запускает по умолчанию.)

Когда мы запустили заголовок: «Солнце садится над фермой в Центральной Айове, недалеко от того места, где Берни Сандерс провел сегодня митинг с Александрией Окасио-Кортес» через наш N.L.P. конвейер, мы получили это:

Конвейер spaCy делал некоторые причудливые вещи, например рассматривал «Центральную Айову» как один токен и различал «существительное» и «существительное собственное». Что наиболее важно, синтаксический анализатор правильно пометил «Солнце», а не «Александрия Окасио-Кортес» в качестве грамматического субъекта («nsubj») текста. N.L.P. предоставили структурированные данные, необходимые для написания кода для извлечения грамматических предметов из подписи и сохранения их в виде тегов для поиска.

Прототипирование

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

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

Чтобы выяснить это, моя коллега Шэрон Тартароне создала систему оценки в Jupyter, которая позволяет нам сравнивать новый алгоритм со старым. Мы сосредоточились на восьми людях, которые чаще всего искали из наших журналов. Затем для каждого человека мы создали набор данных из результатов, возвращенных старым поиском по субтитрам, и вручную классифицировали каждый результат как релевантный или нерелевантный.

Предварительно классифицировав ожидаемые результаты, мы могли бы искать тех же людей с помощью наших тегов, сгенерированных N.L.P., и позволить фреймворку Шэрон вычислить полноту и точность. Оценки соответствовали нашим субъективным впечатлениям: поиск по тегам действительно отфильтровывал почти 100 процентов нерелевантных результатов, но также отфильтровывал около 40 процентов релевантных результатов.

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

Проблема Air Force One в новом обновлении

Чтобы понять, что происходит, мы внимательно посмотрели на то, как наш N.L.P. конвейер обрабатывал некоторые из недостающих подписей. По совпадению, одна из отсутствующих подписей была «Президент садится в Air Force One», что в конечном итоге стало хорошей иллюстрацией более широкой проблемы.

Токенизатор хорошо работал с этой подписью, но теггер интерпретировал «доски» как существительное, а не как глагол. Эта ошибка распространилась на синтаксический анализатор, где превратилась в бессмыслицу. Согласно нашему конвейеру, «Президент садится в Air Force One» не имеет подлежащего, глагола и объекта - просто набор едва грамматических отношений, которые он назвал составным.

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

Нам было нелегко предотвратить подобные ошибки, но мы нашли способ их обойти. Вместо того, чтобы собирать только токены существительного-подлежащего, мы скорректировали наш алгоритм для сбора всех токенов, кроме существительных-объектов. В простой, правильно разобранной подписи, такой как «Берни Сандерс провел митинг с Александрией Окасио-Кортес», сбор субъектов аналогичен сбору не-объектов, поэтому эта настройка не имеет значения.

Но для предложения вроде «Президент садится на борт Air Force One», где алгоритм вообще не смог идентифицировать субъекты или объекты, сбор субъектов ничего не дал нам, в то время как сбор не-объектов дал нам все предложение. Благодаря этой настройке, даже если мы не могли правильно разобрать заголовок, мы все равно могли сделать что-то доступным для поиска.

Этот косвенный подход привел к 98-процентному отзыву нашего тестового набора данных, и мы смогли достичь точности от 80 до 95 процентов, в зависимости от поискового запроса. Старый алгоритм поиска, который искал простые подписи, имел точность всего 50%, так что это было большим улучшением. Результаты были достаточно впечатляющими, чтобы наша команда и, что более важно, фоторедакторы были взволнованы этим подходом.

Что дальше

Мы постепенно внедряем поиск по тегам в редакцию новостей и по мере продвижения вносим улучшения. Моя подруга по команде Кейт Бреннер улучшила точность, найдя более точный способ определения границ предложений, в то время как мой товарищ по команде Майкл Моффитт улучшил запоминание, работая над длинными названиями должностей, такими как «Спикер Дома Нэнси Пелоси», которые сбивали с толку синтаксический анализатор. Майкл также ввел некоторые преднамеренные исключения из нашей политики фильтрации объектов глагола, после того как заметил, что объекты таких глаголов, как «объятия» и «объятия», обычно присутствуют на фотографиях и не должны быть отфильтрованы.

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

Крис Франк - старший инженер-программист в издательской группе The New York Times и технический руководитель проекта CMS Photo.

Команда фотографов CMS: Фрэнк Борелл, Кейт Бреннер, Уильям П. Дэвис, Крис Франк, Крис Грилло, Шерман Хьюитт, Дженни Хоттл, Майкл Лэйнг, Моника Лэндроув, Джастин Люсенте, Майкл Моффит, Шонта Синглтон и Шэрон Тартароне. . Особая благодарность квасцу Суману Рою, техническому директору.

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