Тривіальне датазнавство: класифікатор

[malyj_gorgan]

Нижченаписане -- це як табличка множення для всякої людини, яка хоч колись працювала близько до модної останні чверть століття теми "машинне навчання", ака, Machine Learning (ML). Якщо ви це все знаєте, пропустіть, але комусь може і цікаво буде.

Значить, класифікатор, це така штука, яка рахує відображення з вектора ознак (feature vector) на бінарний (0/1) ярлик (label). (Наприклад, вектор ознак -- це шкільні оцінки абітурієнта Гарварду, його вік, зріст, вага, стать, раса, колір очей, банківський рахунок батьків, кількість сторінок, які читає за рік, кредитний скор і рейтинг продавця на Ебей, а ярлик -- чи поступить абітурієнт в Гарвард, чи ні) Як саме класифікатор це робить -- залежить, є багато алгоритмів, а я вам роповім, як цей класифікатор оцінюють. Більшість класифікаторів (не всі, кластерінг ні, але від банальної лінійної регресії до нейронних мереж) мають проміжний крок, коли ви знаєте якусь одномірну неперервну величину між 0 і 1 як функцію вектора ознак. Найчастіше це -- імовірність, що ярлик з таким вектором ознак буде 1. (Хоча на практиці може бути якась [0,1]->[0,1] функція цеї імовірності, але то вже умняк.) Словом, той самий скор (score) s, про який я недавно писав. Сам ярлик рахують, вибираючи порогове значення, якщо s менше, то ми класифікатор каже "0", інакше "1".
Результат роботи класифікатора оцінюється через так звану матрицю неоднозначностей (confusion matrix): 2×2 матриця, яка для перевіряльного набору даних (validation dataset), тобто, набору даних, де ми знаємо і ознаки, і ярлики, каже нам чотири числа (з лівого верхнього кута за годинниковою стрілкою):
  * правильно відгадані нулі (true negatives або TN)
  * помилки першого роду: те що насправді нуль, а класифікатор обізвав одиничкою (false positives або FP)
  * правильно відгадані одинички (true positives або TP)
  * правильно відгадані помилки другого роду, те, що насправді один, але класифікатор назвав нулем(false negatives або FN))
Відповідно, точність класифікатора міряють за відносною кількістю вгаданих нулів і одиничок. Найпопулярніші метрики:
(a) Повнота, вона ж чутливість (recall=sensitivity) R=TP/(TP+FN) -- яку частину одиничок класифікатор правильно знаходить
(b) Влучність (precision) P=TP/(TP+FP) -- яка частина з того, що класифікатор назве одиничкою, вгадана правильно
(c) Специфічність (specificity) S=TN/(TN+FP) -- яку частину нулів класифікатор правильно знаходить
(d) Хибнопозитивний рівень (false positive rate) FPR=1-S -- яку частину нулів класифікатор хибно оголосить одиницями.

З цим, якщо подумати, все більш-менш ясно. Тільки це вимірює точність остаточного класифікатора, але не дає повною картинки про класифікаційну модель. Памʼятаєте, там був скор і порогове значення? Так от, саме модель і скор є основним результатом машинно-навчального проєкту, а вже вибір порогу і матриця неоднозначностей рахується виходячи з моделі плюс міркувань бізнесу. Тому що у всіх неідеальних випадках є якісь хибні нулі і одинички, відповідно, поріг вибирається з міркувань відносної ціни FP і FN на наявних даних. А сама модель, коли порахована, описується не просто кількома цифрами, а графіком. ВІрніше, навіть двома: якість класифікатора описується ROC-кривою, а доречність класифікатора описується розподілом даних вздовж скора. Нижче -- пояснення на прикладах абсолютно реального класифікатора, який я написав для одної зі своїх робіт, він прямо зараз в продакшені живе.

ROC-curve (ROC-крива, receiver operator characteristic curve),
Крива, яка показує, яка чутливість відповідає різним хибнопозитивним рівням. НИжче -- реальна ROC-крива. Класифікатор дуже точний (такі в продакшні рідко трапляються, я прямо пишаюся), тому картинка з кривою має додаткову вставку, де показують повноту для зовнім низьких значеннях FPR.

Фактично, на цьому графіку ви вибираєте поріг: вирішуєте, що можете собі дозволити один FP на тисячу, після чого бачите: з таким ризиком помилки першого роду, я вгадаю 60% одиничок правильно. Ще раз нагадаю -- це дуже точний класифікатор, в житті доводиться миритися з набагато вищим FPR.

Розподіл даних за скором
Це не характеристика моделі, а вимір того, наскільки дана модель добре підходить для певного набору даних. Ось, все з того ж самого реального прикладу:

Це, знову ж таки -- дуже хороший розподіл. Видно, що більшість зразків матимуть або дуже високий скор, або дуже низький, причому, дані збалансовані (там і справді порядку 60% одиниць... а у світі часто трапляються набори даних, відносна кількість нулів до одиничок або навпаки -- порядку 1000/1 або і більше). Словом, з таким розподілом можна край боронити. Шкода, що вони рідко такі гарні бувають.

От і казочці кінець ;)

Comments

[kondybas]

Коли я займався поштою і воював із спамом, довелося вивчати питання класифікаторів. Та й скоринг доводилося тюнити.

[malyj_gorgan]

Ага, одна з традиційних ML задачок.
Хоча в мене є ідея-фікс, як пофіксити світову проблему спаму -- якось так поміняти систему провайдерства, щоб відсилка кожного емейла у світі коштувала гроші. Хай соту частину цента, але не нуль. Шкода, ніхто мене не слухає...

[kondybas]

Та ж ніби проблему спаму пофіксили. Не принципово, звичайно, бо особливості протоколу. Але ж сукупність доволі простеньких технік дозволяє зарубати 99.999% спаму. Простий байєс-фільтр у спамассассіні працює дуже добре.

[malyj_gorgan]

Це рішення лише на рівні клієнта і часткове -- навіть з найкращими фільтрами маємо false positives і false negatives.

Не вирішена проблема софт спаму, який не віагра/нігерійський принц/і т. п., а в принципі легітимні речі, інфорекламні розсилки, повідомлення про все на світі від всіх на світі організацій, яких просто забагато. Відправляти їх всіх у спам -- перенавчати фільтр так, що буде більше хибних влучань. Не відправляти -- тонути в емейлах. Поки послати емейл на стомільйонів людей нічого не коштує, ця проблема лише зростатиме.

Аналогічно з телефонією, особливо, айпі-телефонією

[kondybas]

Тут головний момент в тому, що є різне сприйняття інфоматеріалів, і те, що для когось є софт-спамом, для іншого - цінна кореспонденція. Це автоматично натякає на рішення - багаторівнева фільтрація. Щось треба фільтрувати безумовно для всіх і всюди, щось треба фільтрувати на рівні вузлового МТА, а щось має фільтруватися персонально, на стадії LDA. Ясне діло - із фідбеком та "м'яким деферром", коли сумнівні листи потрапляють у фолдер "спам" для подальшого вирішення людиною спам/не спам.

Я свого часу саме таке і робив, і воно дуже добре працювало. Як не дивно, найбільш цінним компонентом всієї системи був пул добре відомих спам-ганів, які струячили виключно спам. В поганих системах їм або дають відлуп на стадії HELO, або приймають та одразу дропають їхні листи. В мене був зовсім протилежний підхід. З точки зору спамерів я був лохом, якому можна було слати що завгодно звідки завгодно. Неіснуючий домен? Приймаю! Листи з домена в обхід доменного МТА? Приймаю! Порушуєш DKIM/DMARC? Приймаю! Шлеш з мого ж домену мені ж іззовні без автентифікації? Приймаю! Відправник з чорного списку? Приймаю! Особливо я любив відправників, які починали передачу листа одразу після конекту, оминаючи фазу HELO - просто аж пищав від захвату.

Все це добро одразу додавалося до блеклиста, а їхні листи сипалися на навчання байєса. Фактично, спамери самі постачали мене матеріалом для ML. Раз на тиждень мені слало листа із списком 20 найбільш активних спам-доменів, які не були внесені в блеклист. Я його проглядав очима, інколи навіть ходив дивитися, що там і, якщо то був черговий спамхост - додавав його у блеклист. Але кілька разів то були просто погано настроєні МТА, які я допоміг законопатити.

[malyj_gorgan]

> ... те, що для когось є софт-спамом, для іншого - цінна кореспонденція ...
Абсолютно.
І плюс багато до багаторівневої фільтрації.
Просто, навіть фокусуючись на останньому рівні багарівневої фільтрації, персональному, завжди забагато одного, замало іншого. Та навіть з одного джерела: я _хочу_ отримувати емейли з ЛінкедІна, я через нього кілька разів непогані роботи знаходив, з якимись людьми контактував... але зараз він шле просто забагато. А от якби вони платили хоча б по центу за кожну сотню розісланих емейлів, вони би почали рахувати, чи варто їм послати мені сьогодні 15 емайлів, чи трьох вистачить.
Має людина право помріяти :)))

[kondybas]

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

[malyj_gorgan]

Можна.
Мій досвід останніх кількох років: на гуглі такий фільтр працює так собі. На інших сервісах, які в мене були, ще гірше

[ichthuss]

О, хотів принагідно проконсультуватись, якщо це не надто нахабно з мого боку.

У мене є задачка на класифікацію для особистих цілей. Мені регулярно доводиться записувати і оброблювати записи любительських акустичних концертів, і сама занудна частина обробки - це виділити в записі "музику", "конферанс", "оплески". Хочу це діло автоматизувати. Я приблизно уявляю, в який бік рухатись, але, можливо, я щось пропускаю. В цілому задачка геть проста, але є нюанси, що роблять її не цілком тривіальною для людини, далекої від датазнавства.

1. Лейбли не взаємовиключні (оплески можуть накладатись на конферанс чи на музику)
2. Це не зовсім задача класифікації, бо треба не просто віднести запис до однієї з категорій, а знайти початок і кінець. Тобто детекція з класифікацією.
3. Для найкращого результату точність межі має принципове значення, в ідеалі хотілося б точності в межах 10 мс.

Який шлях я бачу найпростішим:
- ділимо на 20-мс фрагменти з 10-мс перекриттям (можливо, 50-мс з 25-мс перекриттям)
- в якості фіч беремо перші N частот з log(abs(FFT(signal)) (орієнтовно 0-10kHz)
- засовуємо це в якийсь класифікатор (підозрюю, що там навіть нейронка не знадобиться, щось простіше спрацює). В принципі, класифікатор можна абстрагувати і міняти в процесі експериментів
- будуємо графік "скор(час)" шляхом інтерполяції (лінійно чи кубічним сплайном) і знаходимо точки перетину порогу.

Підозрюю, що достатньо буде класифікувати всі фрейми незалежно (сумніваюсь лише в якості розділення "сольний спів" - "мовлення", там, можливо, знадобиться пам'ять з попередніх фрагментів). Не впевнений, наскільки добре така штука поводитиме себе при комбінації лейблів.

Щось порадите ML-ламеру?

[malyj_gorgan]

Правильний інженер засів би за гугл, знайшов би стопіццот гітхаб-сторінок, розгрібав би чужий код... Ненавиджу такий підхід! Нудно і нецікаво. Тому говоритиму з голови :)

0. Дотичне: я собі слабо уявляю 10-20 мс точність при роботі з сигналами, де частоти починаються з десятків герц. 20 мс - це один період звучання нижньої клавіші фортепіано. імхо, це теоретичний ліміт, оплески і музика починаються-стихають протягом секунд, та одне слово при гучній вокалізованій мові, як при конферансі -- це сотні мілісекунд... Думаю, в результаті доведеться брати довші семпли, через них інтерполювати криву присутності точо чи іншого сигналу, і вибирати поріг, де ту криву обрізати. Власне, це моделює те, що жива людина при звукообробці. Тому я дуже раджу почати з семплів набагато більших, не менше секунди, а то і більше, і вже лише потім якось шукати границі переходу між, скажімо, оплесками і неоплесками. (Що є простішим, якщо розглядати це як окрему задачу.)

1. Задачка більше на signal processing, ніж на машинне навчання. Oсновний челендж буде вибрати правильні ознаки і семпли. Чисто частотні ознаки, може, спрацюють, якщо мати ну дуже великий тренувальний набір даних і запустити багаторівневу нейронку. Deep learning -- це те, що давно для розпізнавання тексту чи слів робитли. Але це самому писати з нуля не вийде, надто багато мороки (я не писав). Плюс, банально цікавіше (і, напевне, швидше) спочатку подумати про трохи кастомізованіші характеристики, базовані на частотах. НУ, типу: присутність музичних гармоній (піки в частотному просторі одбре проявлені і співвідносяться як цілі дроби, в оплесках цього не буде). А то навіть як цілі числа -- це вже обертонів і резонуючі частоти.

1а. Взагалі, правильна квантифікація вхідних даних -- необхідна і критична умова успіху. Минуло дуже багато років з того часу, як я був ближче до signal representation тем, але тоді я ошивався в кругах професіоналів, і те, що осіло в памʼяті, каже мені, що замість чисто фурʼє аналізу треба пробувати або просто sliding window transform, або якісь перетворення з компактною базою, щось з родини вейвлетів (wavelets). 25-30 років тому це лише починалося, впевнений, зараз можна знайти щось готове і прикольне.

2. Оскільки сигнали можуть перетинатися, то треба добре думати, чи нормалізувати гучність семплів і писати класифікатор, чи одразу писати регресор. Перше легше і стабільніше, але я на ходу не готовий дати остаточну відповідь. Думаю, все впиратиметься в то, які тренувальні дані можна буде знайти. Взагалі, підготовка великого, різноманітного і надійного labeled training dataset'а -- друга необхідна і критична частина процесу. По-хорошому, треба спочатку зрозуміти, що ми можемо підготувати в плані інпуту, а лише після того глибше думати про способи розвʼязання :)

3. Власне, я зараз на ходу ліпше не придумаю, але тема прикольна. Якщо вам цікаво можна продовжити, починаючи з того, які тренувальні дані у нас є. Зараз мушу йти працювати, але ще кілька зауважень:
(а) можливо, задачку можна розвʼязати через факторизацію для кожного окремого файла, тобто, не тренувати попередній класифікатор, а працювати з кожним файлом з нуля. Воно ж не обовʼязково, щоби обробка відбувалася моментально?
(б) процес треба починати з очищеної задачки: чистий голос, чиста музика, чисті оплески, і потім викидати непотрібні змінні, бо без зменшення розмірності входу ніц не вийде
(в) таки раджу подивитися на вейвлети

[ichthuss]

Спасибі велике!

Деякі думки на тему.

0. В моєму застосуванні (переважно хоровий спів) важливі для класифікації частоти рідко спускаються нижче 70 Гц, Тому я не бачу особливої проблеми з короткими кліпами. Інтуїтивно мені здається, що якщо включити довільний 50-мс фрагмент запису в нескінченному повторі, людина дуже легко відрізнить оплески від музики і від мовлення. Хоча думка розділити завдання на грубішу (по часу) класифікацію і точне знаходження меж makes sense.

1. Ну, з signal processing'ом я, якраз, дружу добре. З тією його частиною, де йде чітка математика, а не шаманство типу "подаємо щось на вхід, не знаємо, що всередині, отримуємо вихід, міняємо всередині самі не знаємо що". Щодо кастомізованих характеристик - можливо, справді є сенс подумати, хоча мені здається, що сабжеві класи будуть легко відрізнятись тупо по спектрограмі.

1а. ОК, доведеться вникати в те, що таке вейвлети, принаймні щоб оцінити, наскільки воно треба. 20 років назад було нецікаво і ліньки, зараз теж нецікаво і ліньки, але, може, буде корисним.

2. Ну, labeled dataset я самостійно підготую, я все одно майже те ж саме роблю кожен раз при обробці.

3.(а) - не зовсім зрозумів процес. Мова про те, що я починаю аннотувати файл, а програма по ходу діла на цьому тренується і одразу дає класифікацію, яку я потім лише підтверджую або спростовую?
(б) о, це важливий момент. А в яку, орієнтовно, розмірність входу слід цілитись?

[malyj_gorgan]

Цікава задачка, в мені аж бажання погратися з нею проклюнулося :)

0. Звужений діапазон музичних стилів -- це добре, дає надію на успіх. Хоровий спів + ф-но -- хороша музика для аналізу. З перкусією можуть бути проблеми, відділити деяку перкусію від деяких оплесків на короткому промiжку може бути концептуально неможливо (з глибини підсвідомості: "we will we will rock you!" :)) Але це крайні випадки, я лише від занудства згадав.

1. Як на мене, якраз signal processing -- чистої води шаманство. Особливо, на рівні електроніки.
При цьому, наче вчився, фізик -- не псячий хвіст, а все-одно шаманство, гірше швейної машинки (в котрій я розібрався лише відносно недавно :)) Але це мої психологічні заморочки, поскаржився, і доста :)
Так-то я не знаю, чи потрібні додаткові зусилля в формуванні ознак, можу пояснити, чого я пробую уникнути. Це міркування ближче до кластерінга, але воно корисно так думати і в простій Я думаю про подібність між семплами. Допустім ,у нас є один шматок запису, де звучить до-мі-соль і другий, де звучить ре-фа-ля. Частоти різні, тому від тривіального класифікатора легше очікувати, що він по умовчанню буде міряти відстань як неподібну. Тобто, вичленити характеристику "ізольовані частоти, які гармонійно між собою співвідносяться" хороший класифікатор зможе, але це буде довго і неочевидно -- якщо колись бачили, як працюють нейронні мережі, коли вчаться розпізнавати букви, там досить помітний шматок навчання іде всього лиш на те, щоби не плутати букви різного розміру, орієнтації, і в різних частинах поля зору. В кінці-кінців, мережа це робить, але треба кілька шарів нейронів лише на те, що можна би було зробити грамотним pre-processing'ом. СЛовом, я думаю про таке
1а. Тому і про вейвлети -- вони частотні і часові зсуви, наче, добре описують.
Але я не кажу глибоко в них розбиратися. Я раджу пошукати готові фільтри (в кінці кінців, перетворення Фурʼє -- теж черговий готовий фільтр) з різних сімейств вейвлетів для змінних.

2. (воно ж 3б) При обробці таки не то. Але в цілому я б радив взяти всі файли, де уже відомо, де музика, де розмова, де оплески, і нарізати з них _дофіга_ семплів. ТОбто, якщо у нас є годин десять музики, то їх поділити на кількадесят тисяч семплів, більше 36000, бо можна зі зміщеннями. Тренувати окремо оплески/неоплески, голос/все інше, музика/все інше

3(а) Я прямо зараз не встигну пояснити толком. Концепція: всякий шматок звуку є комбінацією оплесків, голосу, кількох стилів музики і просто шуму. Розкладаємо на компоненти, виділяємо потрібне. Довше -- пізніше. Non-negative matrix decomposition , але з попердньою обробкою в частотоному просторі.
Пардон, мушу бігти

[sassa_nf]

А чи включає в себе термін "музика" барабани? Бо ритм може бути кілька beats per second, і сампли десятки мс довжиною просто не в змозі їх зловити.

Те ж і про оплески. Ритм оплесків низькочастотний за побудовою. Звісно, кожен окремий ляпас видасть багато різних частот, але сукупно це ж низькочастотний сигнал.

[ichthuss]

Конкретно в моєму випадку "музика" - це на 90% акапельний хоровий спів, інколи з додаванням перкусії, решта 10% - теж хоровий спів, але з інструментальним супроводом (найчастіше фортепіано).

Оскільки виступи в більшості випадків відбуваються в залах з непоганою акустикою, то реверберація після оплесків ще деякий час (навряд чи менше секунди) буде зберігати приблизно ту ж саму частотну структуру, тому конкретно тут я великої проблеми не бачу.

[sassa_nf]

Дякую. А є якась інтуїція що як називають? Бо я завжди плутаю, хто precision, хто sensitivity, а хто specificity?

А, а ще можна згадати, що коли кажуть, який точний, скажімо, сканер відбитків пальців на айфоні, то називають одну цифру. І що то є повний б..., тобто, маркетинг. Бо одним числом якість класифікатора описати неможливо.

[malyj_gorgan]

Sensitivity і specificity я вивчив, ще коли був не датазнавцем, а займався діагностичною медициною. (А от семантичного навантаження слова recall я інтуїтивно не відчуваю, тому вживаю його просто так, вслід за іншими)

Sensitivity -- how sensitive you are to the disease, наскільки добре ти хворобу відчуваєш, тобто, з усіх хворих, скількох діагностуєш правильно = diagnosed positives / all positives

Specificity -- how specific you are to the disease, наскільки добре ти хворобу ізолюєш, тобто, з усіх здорових, скількох діагностуєш правильно = diagnosed negative / all negativеs.

Precision -- про зовсім інше, вона описує не модель, а модель+семпл, тобто, це прямий переклад -- відносна точність вимірювання, яка залежить не лише від того, чим ти міряєш, а і від того, що ти міряєш, навіть чисто в плані масштабу: лінійкою ти краще поміряєш довжину від кількох до десятків сантиметрів, але не меншу і не більшу, і так для всякого приладу. Ну а в машинному навчанні це просто екстраполяція концепції, прецизія, це наскільки багато правди в тому, що ти наміряв

Єдиний вимір точності, accuracy, існує, і часом, для добре збалансованих даних, він цілком має смисл: коли ти знаєш, що у тебе розподіл 0 vs 1 приблизно пополам, і тобі кажуть, що ти вгадав/не вгадав досить з високою точністю, в більшості ситуацій цього достатньо, не треба думати, чи існує різниця 1-2% між точністю вгадання нулів і одининок. Наприклад, прилад, який за відбитком пальця каже, чи це чоловік, чи жінка -- нормальний юзкейс в середньому. Лажі починаються в розбалансованих розподілах, наприклад, я тобі легко напишу ідентифікатор, який з точністю вище 99% вгадає стать людини за чим завгодно, якщо вгадувати серед вʼязнів каліфорнійської тюрми Сан Квентін :)
Якщо дані все ще в міру збалансовані, але абсолютна точність не надто висока, то доречним є так званий F1 score, гармонійне середнє sensitivity and precision. Правда, я жодного разу не стикався з ситуаціями, де від цього F1 була б якась користь :)

[sassa_nf]

> Specificity -- how specific you are to the disease, наскільки добре ти хворобу ізолюєш, тобто, з усіх здорових, скількох діагностуєш правильно = diagnosed negative / all negativеs.

От оце один із моїх спотикачів. Інтуїтивно хочеться сказати "наскільки вірно знаходить хворих саме на цю хворобу серед усіх хворих", а ділять негативи. Хоча звісно, це не про те, а про чи ти роздаєш діагноз всім підряд, чи ні.

А є якийсь layman's термін для FPR чи якийсь показник схожий на ROC? Я малюю ROC, а люди скаржаться, що вони "не математики", і їм не зрозуміло, як цим користуватись. (Задача така: автоматично знайшов комбінації параметрів, які "пояснюють" походження проблеми, і треба показати, на які комбінації слід звернути увагу. Для цього малюю TPR, FPR, Lift, ROC - мені зрозуміло, але як пояснити не спеціалістам?)

[malyj_gorgan]

ROC я сам собі розумію і іншим показую в динаміці.
Малюю якусь фігуру "всі семпли" і вертикальною лінією ділю на дві частини, зліва -- нулі (здорові), справа -- одинички (дійсно хворі)
Потім малюю через цю фігуру якусь не-зовсім-вертикальну лінію, яка ділить всю площину на зліва нулі, справа одинички, але це -- модель. (ідеальна модель би теж була вертикальною лінією). Виходить ось такий простір, де семпли попадають в чотири категорії:

Після чого пояснюю ці чотири категорії: вгадані нулі одинички і два види помилок. Люди, зазвичай, розуміють добре.
А після цього як кажу, що, між іншим, модель не статична, а цю невертикальну лінію можна рухати вліво-вправо за рахунок вибору порогу, в результаті, _та сама_ модель може дати різні відповідні кількості вгаданого і помилок. Часом нам важливо якнайменше FN i якнайбільше TP, тоді ми рухаємо цю криву вліво. Часом, нам дуже важливо не мати FP, ми рухаємо модель вправо, отримуючи менше вгаданих TP. Відповідніть між вгаданими TP vs FP -- це і є ROC крива.
Ще на цьому самому графіку можна показати, що таке влучність, як за рахунок руху міняється і вона, і виходить precision-recall curve

[sassa_nf]

Прикольно. Я таке роблю, але малюю фігури різної форми: коло перетинається із квадратом. Щоб не виникало спокуси, що похилу можна відкалібрувати, "виструнчити" вертикально. Тоді також наочніше питання різного розміру класів.

Але цього разу у мене задача зовсім інша, то треба подати інформацію про якість кількох класифікаторів - типу, чим якість одного відрізняється від іншого. Я малюю щось на зразок ROC кривої, хоча звісно виходить не суцільна крива, а просто точки на площині. І треба пояснити користувачам, на що це вони дивляться.

Так би мовити, автомат знаходить пів сотні початкових кроків до аналізу, а сам аналіз потрібно виконувати вручну. Ну, так щоб розуміти, з яких кроків починати, треба розуміти, що кожна точка означає. Скажімо, "класифікатор" x=y має такий-то показник TP та FP, а "класифікатор" x=y ∧ p=q - отакі-то. Додаючи p=q ми зменшуємо TP, але і значно зменшуємо FP.

Щось таке.

Так от, як назвати TP я розумію, а як назвати FP я не придумаю.

[malyj_gorgan]

Я до кінця не зрозумів, що там в тебе за юзкейс, але впенвнеий, що всяку ситуацію з класифікатором, у якого є одномірний score можна представити саме так: простір семплів (якась заповнена фігура, розділена прямою на частини (далеко не завжди співрозмірні -- баланс рідко хороший) відгаданих 0 і 1, і інша пряма, яка перетинає це діло під кутом і рухається залежно від вибору порогу. Заповненість фігури, звичайно, не рівномірна (густина самплів різна, можна, просто, якийсь розподіл крапочок. Зате, якщо вже зповнювати крапочками, то фігура може бути хоч колом, хоч квадратом.

[sassa_nf]

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

Це не те саме, для чого ROC curve винайшли, але оскільки порівняльні характеристики класифікаторів - це TPR та FPR, то я їх порівнюю на такій самій площині, як і ROC curve. І замислююсь, як пояснити, що таке FPR.

Так то я можу пояснити, що звертати увагу варто на лівий верхній кут, а решта для контексту - тобто, наскільки гірші інші класифікатори, і ща якими ознаками. Але ж люди питають, що за осі Х та У

[malyj_gorgan]

> TPR та FPR, то я їх порівнюю на такій самій площині, як і ROC curve.
TPR (sensitivity) i FPR для даного набору даних -- це одна точка на ROC кривій.
Якщо у тебе є кілька класифікаторів, то для їх порівняння вибираєш reasonable FPR, фіксуєш його і міряєш чутливість (хоча б і підглядаючи ROC кривій) для всіх класифікаторів. І кажеш: ось, якщо ми дозволимо собі хибно діагностувати 4% здорових кандидатів, то класифікатор А правильно діагностує 52% хворих, класифікатор Б -- 65% хворих, а класифікатор В -- 73% хворих і т. д.
А потім: або можна зафіксували чутливість. Якщо нам потрібно досягнути TPR 80%, то модель В дозволить це зробити, але при цьому буде 8% false positives, модель Б згенерує 27% false positives, а модель А видасть 70% false positives, бу, погана модель.


на кажеш, що ось, ми

[sassa_nf]

Ок, це згодиться для однієї хвороби.

У нас - а ну, що сталося за минулий місяць? 100500 хворих загалом, 20800 перехворіли та видужали, 50200 хронічно хворі.

Із них: виглядає як 10% - жертви епідемії А, 12% - новий штам Б, 30% аутоімунні через ген В, решту не можемо пояснити.

[malyj_gorgan]

Почекай, ти говориш про багатокатегорійний класифікатор, а не про порівняння різних класифікаторів для одного і того і самого бінарного ярлика?
Тобто, якщо я правильно розумію, у тебе є кілька потенційних outcomes: діагноз А, діагноз Б, діагноз В + здорова людина, діагноз не придумали. І для кожного діагноза свій класифікатор, так?

[sassa_nf]

Типу того, так.

Маємо 100500 хворих. Які пояснення?

Один каже: епідемія А
Другий каже: хибна комбінація генів Б
Третій каже....

Набір діагнозів не фіксований. Далі, треба зобразити їх сукупність, щоби можна було якось звітувати. Тобто, потрібно показати всі зі значним TPR, але також показати, чи це випадковість, чи фактори, які цей класифікатор бере до уваги, провокують занедужання.

TPR=FPR - значить, нічого особливого, просто випадковість, раз пропорція хворих і здорових із тими факторами однакова.

[malyj_gorgan]

Маємо 100500 хворих, чи 100500 недіагностованих?
Перше уже накладає додаткову умову.
Взагалі, звучить як задача не просто для пачки класифікаторів, а для Байєсівської мережі: маємо людину з набором симптомів, маємо набір спостережених симптомів і життєвих умов, маємо імовірності тих чи інших захворювань, взагалі і на даний момент в даній популяції, рахуємо розподіл імовірностей захворювань.

[sassa_nf]

100500 хворих. Так, розподіл ймовірностей.

А Баєсівська мережа потребує догляду? Я б волів щось на зразок моделі, де я можливо поглядав би раз чи інколи, а воно само регулярні пояснення показувало, чим можна пояснити картину захворювань на сьогодні.

[malyj_gorgan]

Можна придумати з self-update'ами

Дисклеймер: це щось, що я робив професійно давно (хоч і в міру успішно), можливо, зараз воно все імплементовано в готових пакетах, або, навпаки, доказано, що інші підходи працюють краще, але ось як я б це робив.
1. Це граф/мережа. В принципі, можеш вважати її нейронкою, різниця в тому, що трохи вдумливіше прописуєш звʼязки
2. Перший ряд точок -- симптоми і метадані юзера (вік, стать)
3. Другий ряд проміжний -- агрегація симптомів по популяції.
4. МОжливо є ряд 2(а) для додаткової логіки на перший ряд (типу всяких XORів)
5. Останній ряд вираховує імовірність кожної хвороби за формулою Байєса, враховуючи всі попередні ряди.
5. Коефіцієнти -- умовні імовірності певних хвороб за певних обставин (пряд другий з пункту 3 тут важливий,повинен буде порахований окремо, він каже нам безумовну імовірність того чи іншого захворювання).
6. Тренувати мережу - пропускати через неї всі відомі симптоми і діагнози, щоби краще вичисляти умовні імовірності.
4. Третій ряд має ребра на другий і на перший.

[sassa_nf]

Дякую. Треба буде попрацювати над цим ретельніше.

Думаю, тут ще треба буде спочатку почистити дані як слід. Бо у нас timeline, а треба визначити "ось один випадок захворювання". А, і ще треба почитати, як безперервні показники побити на категоричні. (Ха, або навпаки)

Тоді на цю мережу подавати симптоми разом.

Гм, не зовсім розумію, де тут етап тренування. У нас із відомими діагнозами поки що швах. Тобто, вони існують, але не прив'язані до симптомів.