Previous Entry Share Next Entry
2016-01

В теории, теория и практика - это одно и то же, а на практике...

[English version: https://medium.com/@oleksandr_now/in-theory-theory-and-practice-are-the-same-in-practice-however-46fd663f8e7b ]

Во всем этом модном data science есть большая засада.

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

Что-то вроде "мы выкинули все что у нас не отпарсилось", а как насчет того, что "не парсится" - это всегда смещенная неслучайная выборка? Которая смещает остальной датасет тоже далеко не случайным образом?

Ладно, как оно смещает саму статистику - это дело хозяйское и на совести авторов, конечно. Но еще это от входа означает что результаты пейпера, а то и алгоритм в принципе, маловероятно что применим в продакшне.

Например, "мы можем парсить 98% слов из аудио правильно" это звучит замечательно, пока ты не узнаешь что в 2% входят например названия улиц или номера телефонов, потому что они не словарные (out of vocabulary)
И на реальной задаче эти 2% слов превращаются в "70% диалогов не получилось отпарсить".

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

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

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

This entry was originally posted at http://wizzard.dreamwidth.org/482707.html. It has comment count unavailable comments. Please comment there using OpenID.

  • 1
thinker8086 May 9th, 22:15
>> И вот у меня есть хороший программистский бэкграунд, чтобы с этим справляться, но что советовать людям, у которых опыта меньше - как-то пока непонятно совсем. Есть идеи?

Лучшая, на мой взгляд, прямо вытекает из всего текста - говорить таким людям: "Я умею решать такие проблемы, обращайтесь за решением Ваших проблем ко мне".

lus1a_ May 10th, 19:36
Есть еще наставничество.
или просто передача опыта, которая часто сильно нужна передающему

wizzard0 May 11th, 5:59
Да, я именно об этом.

nivanych May 10th, 4:03
> В теории, теория и практика - это одно и то же

Вижу что-то общее с унивалентностью %)

wizzard0 May 11th, 5:50
Тонко :)

maksenov May 10th, 5:18
Сейчас-то уже говорят о том, что подготовка датасета ~70% времени от решения всей задачи, только это действительно превращает задачу в скучную рутину с SQL, ad-hoc скриптами и геморроем. Потенциально проблему могут решать инструменты автоматизированного контроля качества данных, но и там правила нужно настраивать под определенные модели данных.

Если говорить о перспективах то я вижу решением проблемы использовать conditional function dependencies и их автоматический вывод по всему датасету. После этого делить датасет на несколько множеств какой-нибудь классификацией и пытаться вывести правила очистки исходя из того, какое множество мы считаем корректным. Другое дело, что в этой области поле непаханное и прорывов мало - скучно же.

lyuden May 10th, 5:30
Как у человека с небольшим академическим бэкграундом шока эта ситуация у меня вообще не вызывает. Никто не обещал что будет легко :)

swamp_agr May 10th, 8:59
Consultancy свой открывать.

wizzard0 May 11th, 6:22
...в котором надо будет передавать опыт коллегам, и вот как делать *это*?

swamp_agr May 11th, 7:36
1. Описывать бэкграунд через статьи/презентации. Т.е. не столько сам результат, сколько процесс его достижения.
2. Подкреплять его историями. Истории/байки дают более крепкие и устойчивые ассоциации, контент запоминается лучше. Вот, например, "2% слов перекрывают 70% диалогов" - это легко запоминается.

alexott May 10th, 9:27
О, да!!! подписываюсь под каждым словом... Наша PhD тоже выкидывала "неудобные" примеры из dataset, чтобы циферки пошли вверх. После того как я это обнаружил, я сначала начал проверять результаты путем запуска кода, а после того как они не сходились с опубликованными циферками, просто забил на все что оттуда приходит (описав ситуацию директору)

P.S. если не видел, я в прошлом году писал о своем практическом опыте на тему ML: https://alexott-ru.blogspot.de/2016/06/blog-post.html

wizzard0 May 11th, 6:05
Ага, хороший пост :)

Я не читаю блогспот, потому что его JS слишком часто дохнет или просто начинает убийственно тормозить, с мобильника, от адблокера и т.д((

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

fix: попутал типы пространств)

Edited at 2017-05-11 06:06 am (UTC)

kodt_rsdn May 10th, 17:15
В защиту распознавания речи, поскольку занимался этим, скажу следующее.

Из пейперов понятно, что хорошо работает распознавание по словарю (на самом деле, там более сложная структура бигдаты, корпус языка, а не просто каталог слов). А не по словарю, т.е. конструирование слов на слух, - работает плохо.
Кстати, 98% - это именно по словарю, т.е. 2% ошибок всё равно будет - из-за фефектов фикции, из-за невероятных словосочетаний, и т.п.

Отсюда мораль: на практике нужно реализовать эффективное подключение и переключение словарей.
Потому что делать монолитную распознавалку на вообще все случаи жизни - хоть для субтитров чемпионата по шахматам, хоть для подслушивания террористов, хоть для навигации на Рублиштейна 24, - это чертовски накладно:
1) обобщённый корпус будет давать больше ошибок (скажем, путать "Маршала Конева 6" и "мат конём на a6")
2) размер марковской модели и нейросетки распухнет и сожрёт рам и цпу
3) при изменении корпуса придётся перестраивать марковскую модель и переучивать нейросеть
Если же у нас есть каталог улиц родного города или участников чемпионата по шахматам, и мы подверстали его к базовому распознавателю, - и при этом гарантируем, что распознавание со словарём даёт всего 2% WER, - это путь к успеху.
А чтобы обеспечить эти самые 2% WER, для этого академики и трудятся.

Прикладывать же усилия для конструирования слов на слух - это перспективно, но, пока что, теоретично.

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

И, в конце концов, - все эти Рублиштейны, Кузьмы Водолазовы и Заячьи Рощи, а также Вышвихваны Онаны - фиксятся человеческим постпроцессингом, ибо как вот на вот это вот всё натравить искусный интеллект?

kodt_rsdn May 10th, 17:18
Резюме: если в пейпере говорится "а вот эти 2% мы выкинули, потому что намучались с ними", это надо читать "и вы тоже выкидывайте, потому что тоже намучаетесь".
Так работает человечий мозг, так работает здравый смысл, ну и ИИ, как симулятор человечего мозга и смысла, тоже почему бы не должен так работать.

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

wizzard0 May 11th, 5:58
Сцука, жж сьел каммент. Короче, пост сильно упрощен, по практическим нюансам -- я согласен :) но деньги лежат обычно в том, что остальные решают плохо, а не в том, для чего уже есть наработанные инструменты, как-то так.

kodt_rsdn May 11th, 8:47
Деньги там слишком глубоко лежат.
Это как с добычей золота. Некоторые первопроходцы зарабатывают сразу всё, некоторые теряют время и жизнь, а интенданты и промышленники зарубают основные бабки.

  • 1
?

Log in

No account? Create an account