Если конечная цель это количество картинок, то почему выбрали классификатор на два класса, а не регрессию на количество картинок? Так модель должна обучится лучше. А отсечение (кому слать пуши) можно потом выбрать.
Есть версия что эти «ошибки» и не ошибки вовсе и сильно помогли в эволюции и т.п.
То есть можно смеяться над карго культом у всяких папуасов — выглядит смешно. По факту это длительное сохранение поведения при отсутствии подкрепления. Человекообразные обезьяны такого не демонстрируют (ну очень слабо — есть известный эксперимент).
И кто в итоге придумал рыбалку? И как эта практика выжила периоды, когда нет клёва?
Поэтому слово «ошибка» уж больно сильнО.
Представьте себе, для меня ваше утверждение звучит как:
«Тоесть, вы безапеляционно считаете, что 2+2=4? Ок, ваше право».
Как Вас переубеждать даже не понятно.
Давайте попробуем так — в районе 1 года у детей происходят следующие «события»:
— по расписанию ставят первую прививку MMR
— проявляются первые диагностируемые признаки аутизма
— дети начинают ходить и говорить
Это только когнитивное искажение заставляет всех думать что первое является причиной второго, но не третьего. Подумайте об этом.
Я не вижу проблемы в части аналитики. Но интуитивно чую, что при требовании трансакционности оно не взлетит. Где-то вылезет косяк.
Что мы делаем с трансакциями: первоисточник хранится в MySQL, там всё трансакционно. Затем мы копируем все данные сразу в BigQuery и там фигачим аналитику. Избыточность копирования есть (в течение дня тянем каждые 10 минут все трансакции за день), но зато не мучаемся с синхронизацией. Мы ж не гугл, у нас не столько покупок в день чтобы здесь оптимизировать.
Но юзер свои личные трансакции смотрит из MySQL напрямую.
У нас как средство борьбы с летним «разрывом» ещё неплого работала отсрочка и даже скидка по аренде. Удавалось договариваться с собственником. Впрочем, у нас услуги и доля аренды в расходах выше.
Конкуренты толи не договаривались толи не пытались даже… и результат похожий. Конкурент начинает на лето закрывать «неприбыльные группы», у преподавателей же почасовая оплата и они бегут к нам. В итоге к сентябрю у нас весь ассортимент в расписании. А конкурент только пытается перезапуститься. Добирать учеников в работающую группу проще. Так же история вобщем.
Я в целом согласен, идеального в мире ничего нет. Но думается, что время не так часто переводится. В большой картине эти выбросы должны будут усредниться.
Не понимаю как можно сравнивать ценность постов и комментариев. Это как сравнивать ценность фазы сжатия и фазы рабочего хода в двигателе внутреннего сгорания. Не будет одного — не будет и другого.
Вот я — не особо ценный автор, но автор. Не за деньги, от души. Последний пост здесь — 0 комментариев. Сейчас выкладываю пост в бложике, но переводить на русский просто тупо лень.
Спасибо. Всё так и есть, тоже налетал на резкие изменения. Но с другой стороны, продукт быстро развивается, на stackoverflow на половину вопросов по BigQuery отвечают разработчики и очень быстро реагируют. Думаю тут должна появиться какая-то комьюнити, которая будет заниматься оборачиванием продукта в хорошую обёртку. Я помню как пытался дружить python pandas (где я делают все сложные модели) и BigQuery. Стандартная процедура из pandas не завелась (наверное, это у меня руки кривые, но и не должно это быть сложно!). Скачал другую c github, заработала, но не делает всего, что нужно мне. В итоге проще оказалось написать самому по туториалу из гугла. Но эта процедура поломается, если гугл поменяет API, а чинить только мне. Понимаю, что нужно класть такие вещи в оперсорс, но нет времени, да и засмеют — писалось же под себя.
Нет, к сожалению, это не я придумал. Это нужно было лет на сто раньше родиться, наверное :)
Смысл в том, что если мы делаем предположение о cвязи между переменными по корреляции, мы нагенерим много таких левых гипотез, если не позаботимся о трендах. Обычно это проявляется в форме введения переменной «время» в моделях множественной регрессии. Так учит делать любой учебник по эконометрике. Но здесь, я считаю, та же идея, только в профиль.
Если хочется харкора и почитать источники, википедия ведёт сюда, тема очень древняя — www.math.mcgill.ca/~dstephens/OldCourses/204-2007/Handouts/Yule1926.pdf
Но согласен, что никакой строгой теории тут нет, корреляция не обязательно значит причинность.
Безбожники финансисты ещё часто смотрят на корреляцию приростов показателей по отношению к предыдущему периоду. Так тренд тоже уходит. С линейной регрессией результаты похожи, но для меня этот метод более наглядный и понятный.
Ещё можно убирать циклы из данных, но на 11 точках это мало что даст. Это можно использовать когда у всех показателей есть какой-то годовой (или месячный) цикл, не связанный напрямую с показателем. Прекрасный пример — поисковые запросы из комментариев сверху. Наверняка там многие циклы объясняются выходными днями и отпусками. Ну и все мы помним, что «весной и осенью у шизофреников обостряется активность».
А когда нет свободы выбора? У Вас данные секретные и их нельзя в облако лить? Тогда, конечно, сложнее.
У Big Query, конечно, много альтернатив. Меня привлекла именно лёгкость интеграции хранилища данных с другими частями системы, получилось собрать готовый продукт.
Данные можно сохранить на диск в виде текстового файла. Сохраняет Big Query в Storage проекта, а уже от туда можно скачать на диск.
Иногда операторы просят дампы логов по определённым критериям и Big Query удобен, чтобы сделать выборку (например, по определённому списку телефонных номеров) и отдать в виде csv файла. Но такие вещи как биллинг, которые нужно хранить по договору, мы конечно бэкапим и в виде лог-файлов. Это на случай проблем с Big Query.
Канала хватает. У нас распределённая система. Сервера стоят в куче дата-центров на стороне операторов. Звонки по другому не принять.
Есть такая буква в этом слове. Подозреваю что Google Sites настигнет эта участь в первую очередь. Но замену найти не сложно, не заплачу. Что касается ключевых технологий, то я вижу как они пилят Big Query прямо на глазах, не похоже, что убьют в ближайшие пару тройку лет (это при плохом сценарии). А там уже не важно, вечного ничего нет.
Пару терабайт уже. Какой предел y MySQL по вашему мнению? Мне правда интересно.
Может sql это и потянет, но постоянно появляется желание лить туда больше и больше, причём в разы. Поэтому я всё-таки боюсь за масштабируемость в sql мире.
То есть можно смеяться над карго культом у всяких папуасов — выглядит смешно. По факту это длительное сохранение поведения при отсутствии подкрепления. Человекообразные обезьяны такого не демонстрируют (ну очень слабо — есть известный эксперимент).
И кто в итоге придумал рыбалку? И как эта практика выжила периоды, когда нет клёва?
Поэтому слово «ошибка» уж больно сильнО.
«Тоесть, вы безапеляционно считаете, что 2+2=4? Ок, ваше право».
Как Вас переубеждать даже не понятно.
Давайте попробуем так — в районе 1 года у детей происходят следующие «события»:
— по расписанию ставят первую прививку MMR
— проявляются первые диагностируемые признаки аутизма
— дети начинают ходить и говорить
Это только когнитивное искажение заставляет всех думать что первое является причиной второго, но не третьего. Подумайте об этом.
Я не вижу проблемы в части аналитики. Но интуитивно чую, что при требовании трансакционности оно не взлетит. Где-то вылезет косяк.
Что мы делаем с трансакциями: первоисточник хранится в MySQL, там всё трансакционно. Затем мы копируем все данные сразу в BigQuery и там фигачим аналитику. Избыточность копирования есть (в течение дня тянем каждые 10 минут все трансакции за день), но зато не мучаемся с синхронизацией. Мы ж не гугл, у нас не столько покупок в день чтобы здесь оптимизировать.
Но юзер свои личные трансакции смотрит из MySQL напрямую.
Конкуренты толи не договаривались толи не пытались даже… и результат похожий. Конкурент начинает на лето закрывать «неприбыльные группы», у преподавателей же почасовая оплата и они бегут к нам. В итоге к сентябрю у нас весь ассортимент в расписании. А конкурент только пытается перезапуститься. Добирать учеников в работающую группу проще. Так же история вобщем.
Вот я — не особо ценный автор, но автор. Не за деньги, от души. Последний пост здесь — 0 комментариев. Сейчас выкладываю пост в бложике, но переводить на русский просто тупо лень.
Нет, к сожалению, это не я придумал. Это нужно было лет на сто раньше родиться, наверное :)
Смысл в том, что если мы делаем предположение о cвязи между переменными по корреляции, мы нагенерим много таких левых гипотез, если не позаботимся о трендах. Обычно это проявляется в форме введения переменной «время» в моделях множественной регрессии. Так учит делать любой учебник по эконометрике. Но здесь, я считаю, та же идея, только в профиль.
Если хочется харкора и почитать источники, википедия ведёт сюда, тема очень древняя — www.math.mcgill.ca/~dstephens/OldCourses/204-2007/Handouts/Yule1926.pdf
Но согласен, что никакой строгой теории тут нет, корреляция не обязательно значит причинность.
Ещё можно убирать циклы из данных, но на 11 точках это мало что даст. Это можно использовать когда у всех показателей есть какой-то годовой (или месячный) цикл, не связанный напрямую с показателем. Прекрасный пример — поисковые запросы из комментариев сверху. Наверняка там многие циклы объясняются выходными днями и отпусками. Ну и все мы помним, что «весной и осенью у шизофреников обостряется активность».
У Big Query, конечно, много альтернатив. Меня привлекла именно лёгкость интеграции хранилища данных с другими частями системы, получилось собрать готовый продукт.
Иногда операторы просят дампы логов по определённым критериям и Big Query удобен, чтобы сделать выборку (например, по определённому списку телефонных номеров) и отдать в виде csv файла. Но такие вещи как биллинг, которые нужно хранить по договору, мы конечно бэкапим и в виде лог-файлов. Это на случай проблем с Big Query.
Канала хватает. У нас распределённая система. Сервера стоят в куче дата-центров на стороне операторов. Звонки по другому не принять.
Может sql это и потянет, но постоянно появляется желание лить туда больше и больше, причём в разы. Поэтому я всё-таки боюсь за масштабируемость в sql мире.