Мне кажется, есть два варианта: 1) считать правильным тот ответ, который посчитало правильным большинство экспертов. 2) тестировать на искусственном датасете, из которого убрали заранее известные буквы.
Deepmind использовали второй подход, тем более у них было всего 2 phd студента.
Consequently, in order to generate a ground-truth sequence, we artificially removed part of the input text and treated this as the ground-truth sequence.
...with the help of two doctoral students with epigraphical expertise...
Ну это если знать такие `if`, то проблем закодить нет.
А вот если нужно найти эти `if` среди кучи факторов (в т.ч. погода и время суток) — то это совсем другая задача. Это как говорить, что гугловский алгоритм ранжирования легко на if-ах в пятом классе написать, ведь что тут сложного выводить habr.com по запросу хабр.
Для того, что бы показывать то, что человек хотел бы видеть — не нужно вручную модерировать контент — достаточно рекомендательной системы и она там есть. То, что большинствy не нравится в тренды не попадет.
Поэтому официальная версия — не провоцировать комментарии вроде вашего примера — гораздо логичнее, чем (дорогая) ручная фильтрация для повышения прибыли.
Да, питч такой, что разработать понятную 2d инструкции намного сложнее. У людей сложно с переводом из 2d в 3d в гоове. Сама инструкция создается из уже существующих моделек. Плюс она интерактивная — сделай это, проверь чекбоксы, сделай фото, приступи к следуещему шагу. Все это быстро окупаеться сэкономленным временем, скоростью обучения и возможностью проверить работу другим человеком (онлайн или через скриншоты).
Когда есть выбор, всегда выбирайте существующие HTML-механизмы.
HTML механизмы отлично подходят для (полу)статических страниц. Делать на них приложения, сравнимые по UX с нативными, огромная боль. История написана в 2016, и возможно твиттер тогда был ужасным веб приложением, но с тех пор они стали использовать еще больше JS технологий и стало лучше — теперь это PWA c кешированием кода в воркерах, пуш нотификациями, отложенной загрузкой, обновлениями в реальном времени. И все работает на слабых смартфонах с плохим интернетом.
Так, что дело не в том, что разработчики усложняют веб, а в том, что требования к сайтам выросли и нужно делать из говна и палок HTML+CSS+JS что-то сравнимое с нативными приложениями. И призывать нужно к ускорению JS, а не к его устранению.
Ну для gmail — есть html версия — попробуйте вместо обычного, увидите насколько это «быстрее».
На каждое изменение (как mark as read), вы будете ждать полной перезагрузки страницы. Не будет autocomplete, drag&drop, работы в offline, выпадающих меню и кучи всего, к чему мы привыкли в нативных приложениях.
Без этого всего, веб проигрывает закрытым экосистемам.
Согласен, в консоли видно, что они из API кэшируют только feature флаги и a/b тесты.
Тем не менее, в отличи от натива, они могут делать релизы по «несколько раз в день» и запускать много a/b тестов. Мне кажеться, что такой подход — совмещение лучшего из двух миров: быстрые обновления из мира веба, и быстрый запуск из мира натива.
Они уменьшали задержку на сеть, а не оверхед на electron.
В натив будет такая же проблема кеширования данных из сети и магическим образом она не исчезнет. Возможно, ее даже будет сложнее решать.
Последний слак довольно шустрый и теперь понятней почему.
Понятная проблема виртуальной примерки в создании и поддержании 3d контента для примерки.
Не очевидная проблема — в желании людей видеть или представлять более лучшую версию себя. А точный скан тела, да еще и в публичном месте может и настроение испортить и по конверсии ударить.
А вот в фитнесе, где можно наглядно показывать прогресс-прогноз и где не нужен 3d контент, мне кажется есть хорошая возможность.
Интересно, что случилось в последнем матче. Новый агент с движимой камерой, по метрикам был не сильно хуже, чем предыдущие, тем не менее проиграл. Мана нашел слабое место агента и эксплуатировал ее: отвлекал армию и наносил ущерб 2:39:31. Хотя один из предыдущих агентов умел разбивать армию и держать защиту от похожих атак 2:05:37. Мне кажеться AlphaStart не был знаком с Warp Prism микро и критическую роль сыграло уменее человека обучаться по ходу дела и не повторять или эксплуатировать ошибки.
Я имею в ввиду не случайный шум, а перевод картинки без потери информации в новую форму. Научить человека читать QR коды проблематично, а для сетки приципиальной разницы нет. Потому что, сетка обучается с нуля, а мы нет.
Можно провести такой мысленный эксперемент — перемешать выходную картинку случайной, но фиксированой функцией — никакой человек, даже за 15-20 лет, не научится адекватно играть — он не будет ничего видеть. А для AI разницы, вообще, не будет.
А они же как раз и стали в качестве метрики «любопытства» использовать «надоедание от повторения».
До этого они считали «любобытными» те действия, результат которых отличался от ожиданий предсказателя. Но шумный телевизор ставит такую метрику в тупик.
В этом же подходе, «любобытными» считаются те действия, которые приводят в «редкое» состояние. Для этого генерируется неизвестная для предсказателя функция от состояния. Чем лучше он ее предсказывает, тем чаще он был в этом состоянии, тем менее интересно. В качестве неизвестной функции используется такая же сетка, как и предсказатель, но с рандомными весами.
Deepmind использовали второй подход, тем более у них было всего 2 phd студента.
А вот если нужно найти эти `if` среди кучи факторов (в т.ч. погода и время суток) — то это совсем другая задача. Это как говорить, что гугловский алгоритм ранжирования легко на if-ах в пятом классе написать, ведь что тут сложного выводить habr.com по запросу хабр.
Поэтому официальная версия — не провоцировать комментарии вроде вашего примера — гораздо логичнее, чем (дорогая) ручная фильтрация для повышения прибыли.
HTML механизмы отлично подходят для (полу)статических страниц. Делать на них приложения, сравнимые по UX с нативными, огромная боль. История написана в 2016, и возможно твиттер тогда был ужасным веб приложением, но с тех пор они стали использовать еще больше JS технологий и стало лучше — теперь это PWA c кешированием кода в воркерах, пуш нотификациями, отложенной загрузкой, обновлениями в реальном времени. И все работает на слабых смартфонах с плохим интернетом.
Так, что дело не в том, что разработчики усложняют веб, а в том, что требования к сайтам выросли и нужно делать из
говна и палокHTML+CSS+JS что-то сравнимое с нативными приложениями. И призывать нужно к ускорению JS, а не к его устранению.На каждое изменение (как mark as read), вы будете ждать полной перезагрузки страницы. Не будет autocomplete, drag&drop, работы в offline, выпадающих меню и кучи всего, к чему мы привыкли в нативных приложениях.
Без этого всего, веб проигрывает закрытым экосистемам.
Но даже, если б и не было, принцип не поменялся бы, если бы добавился новый источник данных.
Тем не менее, в отличи от натива, они могут делать релизы по «несколько раз в день» и запускать много a/b тестов. Мне кажеться, что такой подход — совмещение лучшего из двух миров: быстрые обновления из мира веба, и быстрый запуск из мира натива.
В натив будет такая же проблема кеширования данных из сети и магическим образом она не исчезнет. Возможно, ее даже будет сложнее решать.
Последний слак довольно шустрый и теперь понятней почему.
Возможно в их lense studio можно что-то подобное создать.
Справедливости ради, он восторгается, как в общем-то и сын. Видео впечатляющее.
Не очевидная проблема — в желании людей видеть или представлять более лучшую версию себя. А точный скан тела, да еще и в публичном месте может и настроение испортить и по конверсии ударить.
А вот в фитнесе, где можно наглядно показывать прогресс-прогноз и где не нужен 3d контент, мне кажется есть хорошая возможность.
До этого они считали «любобытными» те действия, результат которых отличался от ожиданий предсказателя. Но шумный телевизор ставит такую метрику в тупик.
В этом же подходе, «любобытными» считаются те действия, которые приводят в «редкое» состояние. Для этого генерируется неизвестная для предсказателя функция от состояния. Чем лучше он ее предсказывает, тем чаще он был в этом состоянии, тем менее интересно. В качестве неизвестной функции используется такая же сетка, как и предсказатель, но с рандомными весами.