Что нам стоит «умный» продукт построить?

в 20:57, , рубрики: машинное обучение, машинный перевод, Программирование, стартапы

В последнее время словосочетание «машинное обучение» (Machine Learning, ML) стало невероятно модным. Подобно любой распиаренной технологии, энтузиазм здесь превосходит уровень реализации конкретных продуктов. Можно спорить, но мало какие алгоритмические технологии со времен потрясающих инноваций от Google 10-15 лет назад привели к появлению продуктов, широко распространившихся в массовой культуре. Не то, чтобы с тех пор не было прорывов в машинном обучении, не было столь потрясших и имевших в основе вычислительные алгоритмы. Netflix может использовать умные рекомендации, но он и без этого Netflix. А вот если бы Брин и Пейдж не анализировали в своих корыстных целях графовую структуру веба и гиперссылки, у нас не было бы Google.

Почему так? Ведь пытались же. Немало стартапов хотели нести технологии машинной обработки естественного языка в массы, но все по очереди канули в Лету, после того, как люди, собственно, пробовали их использовать. Сложность получения хорошего продукта с использованием машинного обучения не в понимании основной теории, но в понимании сферы деятельности и поставленной задачи. Понимании столь глубоком, чтобы на интуитивном уровне видеть, что будет работать, а что нет. У интересных задач нет готовых решений. Наш текущий уровень в каких-либо прикладных областях, например, той же обработке естественного языка, сильнее движут вперед откровения, относящиеся к этой области, чем новые техники решения общих задач машинного обучения. Часто отличие программы, используемой каждый день, от полуработающей курсовой — это особый взгляд на проблему и хорошая модель решения.

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

Прогресс в машинном обучении.

Машинное обучение прошло долгий путь за последний десяток лет. Когда я поступал в аспирантуру, обучение линейных классификаторов для классов объектов с большими отступами (т.е. SVM, метод опорных векторов) выполнялось алгоритмом SMO. Алгоритм требовал доступ ко всем данным сразу. Время обучения увеличивалось до неприличия с ростом обучающей выборки. Чтобы просто реализовать этот алгоритм на компьютере надо понимать нелинейное программирование, а для выделения существенных ограничений и тонкой настройки параметров — и черную магию. Сейчас мы знаем, как обучать почти такие же по эффективности классификаторы за линейное время в онлайн-режиме относительно простым алгоритмом. Схожие результаты появились и в теории (вероятностных) графических моделей: Markov-chain Monte-Carlo и вариационные методы упрощают вывод сложных графических моделей (хотя MCMC довольно давно эксплуатируется статистикой, в крупномасштабном машинном обучении эту технику стали применять совсем недавно). Доходит до смешного — сравните топовые статьи в proceedings of the Association for Computational Linguistics (ACL) и увидите, что используемые техники машинного обучения в последнее время (2011) стали куда более изощренными, по сравнению с использовавшимися в 2003.

В сфере образования прогресс также колоссален. Обучаясь в Стенфорде в первой половине 2000-х, я осваивал курсы Andrew Ng по машинному обучению и Daphne Koller по вероятностным графическим моделям. Оба этих курса относятся к лучшим из тех, что я брал в Стенфорде. Тогда они были доступны примерно сотне человек в год. Курс Koller, пожалуй, не просто лучший из стенфордских. Он научил меня и многому в преподавании. Сейчас эти курсы доступны для всех в Сети.

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

Готовые решения не подходят для интересных задач

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

Качество машинного перевода последние десять лет росло не по дням, а по часам. Я думаю, что так получилось в основном благодаря ключевым прозрениям именно в области перевода, хотя общие улучшения алгоритмов тоже сыграли свою роль. Статистический машинный перевод в его нынешнем виде восходит к замечательной работе "The mathematics of statistical machine translation", которая ввела архитектуру зашумленного канала, на которой будут впоследствии основаны переводчики. Если объяснять на пальцах, это работает так: для каждого слова есть возможные его переводы на наш язык (включая пустое слово, на случай, если в нашем языке нет эквивалента переводимому). Представим это как вероятностный словарь. Полученные слова переставляются, чтобы получить предложение, которое благозвучно уже на нашем языке. В этом объяснении упущено много деталей — как работать с предложениями-кандидадтами, перестановками, как обучать модели стандартных перестановок с некоторого языка на целевой, как оценивать благозвучность результата, в конце концов.

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

Франц Ох (Franz Och), один из авторов подхода к переводу по фразам, пришел в Google и стал ключевой фигурой в группе Translate. Хотя фундамент этого сервиса и был заложен еще в пору работы Франца исследователем в Information Sciences Institute (и, до этого, в аспирантуре), много идей, позволивших шагнуть дальше перевода по фразам, пришли из инженерной работы, связанной с масштабированием этих идей в веб. Эта работа породила потрясающие результаты в крупномасштабных языковых моделях и других областях NLP. Важно отметить, что Ох не только высококлассный исследователь, но также, по общим отзывам, и выдающийся хакер (в хорошем смысле этого слова). Это редкое сочетание скиллов и позволило пройти весь путь от исследовательского проекта до того, чем сейчас является Google Translate.

Определение задачи.

Но мне кажется, что создание хорошей модели — еще не вся проблема. В случае машинного перевода или распознавания речи задача поставлена четко, а критерии качества просты для понимания. Много технологий NLP, которые выстрелят в приложениях в следующие десятилетия, размыты гораздо сильнее. Что именно должно содержать идеальное исследование в области моделирования тематических статей, разговоров, характеризации отзывов (третья лаба в nlp-class.org)? Как на основе этого сделать массовый продукт?

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

Или, напримре, анализ отзывов. Нужна ли людям черно-белая «хорошо/плохо» оценка? Или нужна более полная картинка (т.е. «еда клевая, обстановка отстой»)? Клиентам интересно отношение каждого конкретного посетителя или точный анализ совокупности отзывов?

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

Подводя итог, если вы хотите сделать действительно классный продукт с помощью машинного обучения, вам нужна команда крутых инженеров/проектировщиков/исследователей. Во всех областях, начиная от базовых теорем машинного обучения до построения систем, знания предметной области, техники взаимодействия с пользователем и графического дизайна. Предпочтительно, специалисты мирового уровня в одной из этих областей и неплохо разбирающиеся при этом в других. Маленькие талантливые команды с полным комплектом перечисленного будут хорошо ориентироваться в полном неопределенностей мире дизайна и продвижения продукта. У больших компаний, где R&D и маркетинг расположены в разных зданиях, такого не выйдет. Крутые продукты будут создаваться командами, в которых у каждого горят глаза, которые видят контекст полностью, и которым вполне хватит места в пресловутом гараже.

Автор: AlexErofeev

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js