Искусственный интеллект - Мередит Бруссард

Эндрю Шивашман, журналист, пишущий об индустрии туризма для сайта Skift, иначе видел ситуацию. Он использовал данные в статье «Клинтон против Трампа: где кандидаты в президенты тратили свои доллары». В рамках статьи он анализирует то, как, пользуясь средствами избирательной кампании, Трамп платит собственной фирме TAG Air за перелеты[161]. Это не незаконно, но примечательно. Это также представляет почву для обсуждения множества вещей, которые не являются незаконными, но едва ли уместны. И журналистские расследования – единственный способ придать таким обсуждениям начальный импульс. Ведь истории помогают понять мир. Кроме того, не существует простых ответов. Чтобы разрешить эти вопросы в демократической манере, необходима социальная дискуссия, в которой бы присутствовали разные мнения.

Story Discovery Engine – это, скорее, система с оператором в контуре управления, нежели автономная система. Разница между ними подобна разнице между дроном и реактивным ранцем. И эта разница имеет значение в случае проектирования программного обеспечения. Если вы ждете от компьютера всевозможных чудес, то будете разочарованы. Однако если вы ожидаете, что он ускорит выполнение рутинных задач, то все будет хорошо. Позиция в пользу машинной поддержки человека набирает популярность в хедж-фондах с оборотом $2,9 млн – а они всегда были показательны с точки зрения внедрения новых количественных методов. Миллиардер Пол Тюдор Джонс, глава Tudor Investment Group, как-то произнес свою легендарную фразу: «Ни один человек не лучше машины, и ни одна машине не лучше человека»[162].

Другой способ разобраться в том, как работает движок, – это представить, что он отражает разницу между что есть и чем должно быть. Что должно быть: административные расходы не должны превышать 20 % от общих расходов. Что есть: независимо от процентов ежегодные расходы относятся к административным – согласно отчетам, передаваемым в Федеральную избирательную комиссию. И, если обнаруживается аномалия – если административные расходы превышают 20 %, тогда появляется почва для журналистского расследования.

Что я имею в виду под почвой для расследований? Нельзя гарантировать, что в каком-то случае совершенно точно есть готовая история, поскольку для больших объемов административных расходов в определенном квартале есть причина. И мы не хотим создавать механизм, который будет констатировать, что существует вероятность, равная 47 %, что та или иная политическая группа действует нелегитимно, ведь ее административные расходы в этом месяце превышены на 2 %. Это абсурд – и, вероятно, клевета.

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

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

Я также внесла одну важную правку в Story Discovery Engine. Когда я пыталась объяснить людям, что делает программа, они часто спрашивали: «Ты хочешь сказать, что создала программу, которая фонтанирует идеями для расследований?» Я объясняла, что это не так и что все сложнее, и рассказывала об автоматизации. Постепенно глаза моих слушателей стекленели. Поэтому для второй версии программы я решила придумать систему, представляющую настоящие идеи для историй. На рисунке 11.5 показан обновленный интерфейс программы.

Замечу, что это дополнение в данных является так называемым «минимально жизнеспособным продуктом» (Minimum Viable Product, MVP). Оно работает, вы видите результаты его работы – однако только для одного случая, а не для всех сразу, которые вы запланировали. И это упомянуто в справочной документации. Как по мне, дополнение работает достаточно хорошо, чтобы утверждать, что оно действительно работает. С моей точки зрения, с позиции разработчика, проблема решена. Однако с точки зрения компьютера, чтобы что-то работало, этому «что-то» необязательно работать хорошо. Это не бинарное понятие. Человек не может быть слегка беременным, в то время как софт, может немного работать. Так, суть минимально жизнеспособного продукта заключается в достаточном уровне функциональности для демонстрации заказчикам – чтобы получить новые заказы или финансирование для следующего круга разработки. Это не пример хорошей разработки, продукт неэффективен для пользователей, и уж тем более практика представления на рынок полифункционального продукта не является хорошим делом, но при этом такой подход стал обычным делом. Мне кажется, мы способны на большее. Ведь в большинстве случаев проблема одинакова для всех, и я столкнулась с ней, создавая «Бейливик»: у команды закончились деньги и время на разработку до того, как проект был завершен.

Есть и другой пример типичной проблемы, которая может принимать разные формы. Однажды код выдал ошибку, я не могла понять ее природу. Я решила создать новую базу данных и протестировать код на всех моих 3,5 млн записей – тот же результат. Первые 10 секунд все работало, затем появилась другая ошибка. Я исправила то, что – как мне казалось – стало ее причиной, и затем пыталась загрузить данные снова. Не сработало. Я что-то еще поменяла в коде, и все стало только хуже. Я переключилась на первую базу данных и попыталась воссоздать первую ошибку. Не вышло – вылезла новая ошибка. Тогда я поняла, что не смогу поправить первую базу данных, и перешла ко второй. У меня было плохое предчувствие; другие члены моей команды пользовались первой базой данных, и тот факт, что она была доступна и при этом содержала ошибки, мог сильно повлиять на результат их работы. На самом деле это была обычная ошибка контроля версий ПО, однако в связи с тем, что в программировании важную роль играет точность, получилось, что ошибки, спровоцированные мной, привели к каскаду новых неисправимых ошибок, затрагивавших работу других разработчиков.