Все алгоритмы оптимизации минимизируют какую-то функцию — она называется «функцей потери», «loss function». Мы выбираем, что это за функция, и выбираем какие-то ограничения на то, какие параметры есть у модели; на основе каких-то данных параметры подбиваются так, чтоб «loss» был минимальным. Так машинное обучение работает прямо сейчас. Вся хитрость в том, как именно считать этот «loss», какие параметры у модели задавать, и как их подбирать за разумное время на основе данных — этим, в общем-то, сейчас все и занимаются. А как называть — «болью» или «целевой функцией» — вопрос второй.
Хранить данных примерно столько же, с UserBalanceChange общий баланс можно точно так же в транзакции обновлять (без агрегаций, через UPDATE… SET balance = balance — 100.00). С UserBalanceChange проще вставить событие «в середину», прошедшим числом, ну и поломать что-то сложнее.
Кроме того, вроде бы BalanceChange сложно заставить работать правильно, если несколько изменений баланса происходят одновременно — мы не можем правильно прочитать текущее значение баланса (его еще может не быть видно) => не можем правильно заполнить поле «balance» (а значит, если отказаться от хранения баланса, то он может стать неверным), и нам надо как-то разрешать конфликты по tsfrom / tsto.
Я бы в нем еще поле reason сделал GFK вместо int, чтоб записи в UserBalanceChange связывать с событиями, которые к измемению баланса привели (например, к подписке или к реферралу).
В mod_wsgi почти каждую неделю коммиты, почти каждый месяц релиз новый, и какие там ограничения? Все то же вроде умеет, что и другие способы развертывания. Может, с mod_python путаете?
Ну смотря что. В данном случае н/нн + ударение позволяет более точно себя выразить, какие-то оттенки смысла передать. Т.е. различие смысловое есть, и хорошо, что его можно выразить в языке. То, что это тут делается именно через н/нн и ударение — видимо, объясняется всякими историческими причинами, особой логики мне тут тоже не видно.
Насчет «варенная / варёная» — мне кажется, что слова немного разное обозначают. «Вареная курица» — это характеристика курицы, как «вкусная» или «зеленая», просто так вышло, что эта характеристика обычно появляется в результате варки. «Варенная в кастрюле курица» — это курица, которую именно что варили — важно, что с курицей происходил процесс варки, а не только/не столько ее вкус и текущая консистенция. Т.е. н/нн — это морфологический способ указать, что именно имеется в виду.
А его как-то можно скачать в машиночитаемом виде? И какая там лицензия?
По ссылке еще разборы немного странные («Толстый» как нормальная форма фамилии «Толстая», несклоняемая фамилия «Жандарева») — это просто особенности интерфейса?
Ага, точно. Метрики не очень удачно выбраны (ну или пример, их демонстрирующий). Тут лучше просто accuracy считать вместо precision/recall/f1/roc auc/… Разве что задача какая-нибудь специфичная, в духе «ищем всех мальчиков, чтоб призвать их в армию», когда «цена» ошибки не одинаковая (например, есои план по призыву не выполняется — важно поменьше людей упустить).
AUC (Area Under Curve) — в области бинарной классификации(,) данный термин (площадь под графиком) используется исключительно в отношении ROC-кривой.
Не совсем так — вместо ROC-кривой часто используется PR-кривая, где по осям откладываются точность и полнота; такая кривая лучше подходит, когда класcы несбалансированы (нулей гораздо больше, чем единиц). PR-кривой соответствует характеристика PR AUC. Лучше поэтому явно писать ROC AUC и PR AUC.
Вцелом все по делу. Но непонятно, зачем тут генетические алгоритмы. Обычная линейная классификация ведь, в чем проблема? Берем логистическую регрессию или svm без ядра и вперед, та же самая функция потерь, та же l2 регуляризация. Если SGD плохо работает (часто бывает, особенно когда данных мало), использовать другой метод оптимизации; в популярных пакетах с линейными моделями SGD и по дефолту-то нечасто.
Еще последнее предложение не понял: ага, вместо вручную проставленных тем (или вдобавок к ним) можно брать вектора LSI или LDA, а что такое «предсказанная оценка записи»?
А в чем ваш опыт расходится с утверждением, если утверждение про почту, а опыт не про почту?
Насчет почты — всегда все слал через почту: макбуки, аймак, муз. оборудование, мелочи разные, никаких проблем не было. Всего десятка три посылок, 2010-2014 годы, несколько разных почтовых отделений. Может, везет, конечно.
Личный опыт: заказывал год назад товар за 2.5K USD: пересылал через shipito, доставку выбрал USPS Express Mail (по России это EMS, насколько помню). Посылку привез курьер, пошлину заплатил ему. Екатеринбург.
Я сам когда начинал pymorphy писать, потоки байт кидал, т.к. питон знал не очень. Иногда не работало. Да и библиотекой пользуются не только программисты, и вот они подобные вопросы задают чаще. Я им рад :) Хорошо, если человек задает вопрос — ему можно чем-то помочь, он не уйдет с молчаливым недовольством. Люди могут быть умные, и хотеть разобраться, но просто базовые знания иметь в другой области. Мое мнение — минусовать простые вопросы не нужно, простые вопросы — это хорошо, они сигнализируют о любознательности и интересе к теме. Ну не знает человек чего-то, и спросил — это же хорошо? Это же лучше, чем если бы человек не спросил — ему бы тогда не ответили, и «сумма знаний» была бы меньше.
В интернет-дискуссиях еще один фактор есть — на десять человек, которым непонятно, один спросит. А дискуссию прочитают (и какую-то информацию получат) все.
А что плохого в том, чтоб спрашивать про основы? Вопрос о математических основах — не такой и простой. Нвпример, на вопрос о математических основах нейросетей Yann LeCun (один из основоположников Deep Learning) вот что пишет:
You have to realize that our theoretical tools are very weak. Sometimes, we have good mathematical intuitions for why a particular technique should work. Sometimes our intuition ends up being wrong.
Every reasonable ML technique has some sort of mathematical guarantee. For example, neural nets have a finite VC dimension, hence they are consistent and have generalization bounds. Now, these bounds are terrible, and cannot be used for any practical purpose. But every single bound is terrible and useless in practice (including SVM bounds).
Градиентный спуск, логистическая регрессия и т.д. — это не математические основы, которые что-то серьезное гарантируют применительно к нейросетям, это просто алгоритмы, которые, как оказалось, хорошо работают на практике. Алгоритм обратного распространения — это не математическая основа, а трюк, позволяющий тренировать много логистических регрессий одновременно за вменяемое время. Все эти dropout-ы — эвристики, которые дали хорошие результаты, и к которым потом «подогнали» кое-какое математическое описание. Вместо «софтмакса» сейчас часто что-то более простое использует, вроде «ступенчатой» функции или просто _/ — никакого особенного мат. обоснования тут нет, просто вычислять это быстрее, и работает не хуже на практике (а часто лучше).
Если битмапы с одним цветом и одного размера, то да, на вход можно передавать битмап «как есть». Да даже если и RGB. Фишка «deep networks» как раз в том, что не нужно битмап преобразовывать самому — контуры выделять и т.д., т.к. первые слои нейросети что-то похожее будут сами делать.
Ошибки, описанные в статье, интересные и неочевидные — нейросеть ошибается не на сложных примерах, а, казалось бы, на простых. Ну и в статье (pdf) пустозвонства никакого нет — хорошая научная статья, довольно интересная.
Так в этом и суть статьи, что методы, которые на MNIST показывают самые лучшие результаты, могут умудриться распознать неправильно цифры, которые для человека выглядят неотличимо. Т.е. ошибаться не в сложных случаях (там, где обычно происходят ошибки), а, казалось бы, в простых.
А откуда сомнения? В статье (в pdf) явно написано, что использовали deep neural networks, и писали это люди, которые в deep-learning сообществе практически «знаменитости».
Я пробовал pymorphy2 натравить на доступную часть НКРЯ (220 тыс токенов) и оценить результаты. Подходы к разметке совпадают не полностью, поэтому некоторые разногласия ошибками не считаются. Ну, например, слова вроде «дальше» в НКРЯ — наречия, а в OpenCorpora (и pymorphy2) — компаративы, но не все компаративы OpenCorpora — это наречия в НКРЯ. Так что 1-к-1 сравнения не получается пока. Но все равно результаты интересные. Если учитывать только части речи, то первый разбор из pymorphy2 правильный в 93-94% случаев, в зависимости от того, как много ошибок мы не учитываем, считая их особенностями подходов НКРЯ и OpenCorpora. При этом pymorphy2 использует только информацию о частоте различных разборов для отдельных слов (оцененную по OpenCorpora), а контекст не использует совсем. Так что часть речи вполне можно определять только по самому слову и получать точность порядка 92%. Без информации о частотности разборов выходит где-то 87% правильных частей речи.
Другое дело, что кроме части речи есть еще падеж, число и т.д., и вот для полного набора граммем, кажется, без контекста уже трудно. Там pymorphy2 выдает 78-80% правильных разборов с использованием частот и 72-73% — без (опять же, в зависимости от того, как оценивать).
Кроме того, вроде бы BalanceChange сложно заставить работать правильно, если несколько изменений баланса происходят одновременно — мы не можем правильно прочитать текущее значение баланса (его еще может не быть видно) => не можем правильно заполнить поле «balance» (а значит, если отказаться от хранения баланса, то он может стать неверным), и нам надо как-то разрешать конфликты по tsfrom / tsto.
UserBalanceChange — это, насколько понимаю, примерно реализация martinfowler.com/eaaDev/AccountingNarrative.html.
Я бы в нем еще поле reason сделал GFK вместо int, чтоб записи в UserBalanceChange связывать с событиями, которые к измемению баланса привели (например, к подписке или к реферралу).
По ссылке еще разборы немного странные («Толстый» как нормальная форма фамилии «Толстая», несклоняемая фамилия «Жандарева») — это просто особенности интерфейса?
Не совсем так — вместо ROC-кривой часто используется PR-кривая, где по осям откладываются точность и полнота; такая кривая лучше подходит, когда класcы несбалансированы (нулей гораздо больше, чем единиц). PR-кривой соответствует характеристика PR AUC. Лучше поэтому явно писать ROC AUC и PR AUC.
Еще последнее предложение не понял: ага, вместо вручную проставленных тем (или вдобавок к ним) можно брать вектора LSI или LDA, а что такое «предсказанная оценка записи»?
Насчет почты — всегда все слал через почту: макбуки, аймак, муз. оборудование, мелочи разные, никаких проблем не было. Всего десятка три посылок, 2010-2014 годы, несколько разных почтовых отделений. Может, везет, конечно.
В интернет-дискуссиях еще один фактор есть — на десять человек, которым непонятно, один спросит. А дискуссию прочитают (и какую-то информацию получат) все.
Градиентный спуск, логистическая регрессия и т.д. — это не математические основы, которые что-то серьезное гарантируют применительно к нейросетям, это просто алгоритмы, которые, как оказалось, хорошо работают на практике. Алгоритм обратного распространения — это не математическая основа, а трюк, позволяющий тренировать много логистических регрессий одновременно за вменяемое время. Все эти dropout-ы — эвристики, которые дали хорошие результаты, и к которым потом «подогнали» кое-какое математическое описание. Вместо «софтмакса» сейчас часто что-то более простое использует, вроде «ступенчатой» функции или просто
_/— никакого особенного мат. обоснования тут нет, просто вычислять это быстрее, и работает не хуже на практике (а часто лучше).Если битмапы с одним цветом и одного размера, то да, на вход можно передавать битмап «как есть». Да даже если и RGB. Фишка «deep networks» как раз в том, что не нужно битмап преобразовывать самому — контуры выделять и т.д., т.к. первые слои нейросети что-то похожее будут сами делать.
Другое дело, что кроме части речи есть еще падеж, число и т.д., и вот для полного набора граммем, кажется, без контекста уже трудно. Там pymorphy2 выдает 78-80% правильных разборов с использованием частот и 72-73% — без (опять же, в зависимости от того, как оценивать).