Пока не начнёт тупить и с уверенным тоном рассказывать полную околесицу. Может, с английским не так заметно, но с японским что Grok, что ChatGPT полностью проваливаются на некоторых грамматических оборотах.
Я с месяц назад переехал на CachyOS. Первые пару дней печалило, а потом я поковырялся пару часов в настройках, освоился - и теперь даже Win10 кажется неудобным кирпичом. В целом переход был практически безболезненным.
Если нужен эксклюзивный виндовый софт или игры с анти-читом, не работающем под Линуксом, то можно оставить Винду в какой-нибудь резервации на ссд и перезагружаться сугубо по необходимости.
Из увлажняющих капель рекомендую Оптинол мягкое восстановление и Хилокомод. Это на основе врачебных рекомендаций, которые сам получил в ходе лечения глаз.
Если интересно, могу в своих бумажках посмотреть остальные варианты, которые мне советовали.
По текущей классификации, LLM - это ИИ, он же AI. То, с чем Вы пытаетесь его сравнить, опять же по текущей классификации называется сильный ИИ, или AGI, который сильно отличается по выдвигаемым к нему требованиям.
И просто потому что используется интервальное обучение - это работать не будет, если карточки сделаны без души.
Это сработает, но эффект будет примерно такой же, как просто при прочтении случайной страницы словаря или как при зубрёжке стихотворений. Рано или поздно слова выучатся, но усилий придётся приложить гораздо больше.
Получается, что процесс обучения с помощью Anki состоит из 2-х основных этапов: создание карточек и повторение.
Всё правильно, и об этом говорят практически все нормальные руководства по использованию программы. Они так же говорят, что чужими наборами лучше не пользоваться.
А так, чтобы приходилось подбирать нужное слово под карточку, прям вспоминать, заставляя мозг работать.
Для подавляющего числа случаев начального или среднего уровня вполне достаточно перевода и полного предложения (или нескольких, если очень хочется), из которого слово взято. На высоком уровне уже лучше переходить на монолингвальные словари, где определение слова даётся на том же языке, что и само слово. Тратить слишком много усилий на создание карточек тоже смысла нет.
Безусловно, можно выучить язык по множеству методик. SRS просто является одной из самых эффективных на сегодняшний день, т.к. позволяет запомнить наибольший объём за наименьшие усилия.
Использование слова в контексте, естественно, улучшает запоминаемость. Поэтому обычно анки рекомендуют использовать для повторения слов, встреченных в книге/фильме/игре ранее, и сохранять вместе с контекстом, например, брать целое предложение, в котором было слово, и показывать в ответе. Это особенно актуально для японского, где очень много похожих слов, использующихся в немного разном контексте.
90% кажется очень грубым преувеличением - в тексте Вы видите слова, как в Анки, плюс контекст, который в подавляющем большинстве случаев помогает, а не мешает. Очень сомнительно, что в такой ситуации вспоминаемость слова хуже, чем в SRS программе.
То, что Вы описываете под симуляцией - обиходное значение. В научном контексте она используется именно для обозначения моделирования.
Мейнтейнер - на данный момент всем понятный термин, имеющий конкретное значение. Предлагаемые же Вами варианты более размыты. "Разработчик" - наверное, самое широкое понятие в разработке софта, не дающий вообще никаких деталей. "Специалист, поддерживающий программный продукт" может обозначать что угодно от мейнтейнера до сотрудника первой линии колл-центра поддержки.
Любое предложение замены в угоду пуризму должно сохранять изначальный смысл. Почему такое предложение заплюсовано, несмотря на вред в отношении понятности текста - загадка.
Это не противоречит антипаттерну, но это всё ещё мешает как писать, так и читать код, когда половина кода - это возвращения ошибок, которые уровнем выше пробрасываются дальше, и дальше, и дальше - и так до возвращения кода 500 по всему стеку вызовов. У них нет отдельного обработчика, результат одинаковый, а текст нужен только для чтения логов.
Таких или подобных ситуаций очень много, и какой-нибудь классический try/except как в Питоне гораздо удобнее, когда обработку исключений можно централизовать, и не быть вынужденным размазывать обработку ошибок для КАЖДОГО вызова функции.
У нас в компании вроде довольно строгие линтеры, но они на такое не ругаются. И нам, в целом, не нужна вся эта тягомотина с типами ошибок и т.д., потому что обрабатываются они в бекэнде одинаково, поэтому мы пользуемся более простым алгоритмом - добавляем какой-то описательный текст и выбрасываем ошибку в ответе сервера. Этого УЖЕ достаточно чтобы понять, какая ошибка и где произошла, однако, если посмотреть на одну из функций, то там одних if err != nil {return fmt.Errorf(...)} получается 20 строк в функции на 65 строк в сумме (один из примеров). Если много вызовов в сторонние API, то порой больше половины строк - возврат разнообразных ошибок.
То, что Вы описываете на этот раз - идеальный случай, где везде нужен контекст, на него разные реакции и т.д. - и даже в этом случае обработка ошибок размазывается на 1000 мест в коде, и за всем этим следить совершенно неудобно.
Пока не начнёт тупить и с уверенным тоном рассказывать полную околесицу. Может, с английским не так заметно, но с японским что Grok, что ChatGPT полностью проваливаются на некоторых грамматических оборотах.
Разрешают. Когда там работал, у нас по полгода людей в команду искали.
Было когда-то видео от Gotham Chess с Хикару Накамурой.
https://www.youtube.com/watch?v=1P35o2pAGws
Я с месяц назад переехал на CachyOS. Первые пару дней печалило, а потом я поковырялся пару часов в настройках, освоился - и теперь даже Win10 кажется неудобным кирпичом. В целом переход был практически безболезненным.
Если нужен эксклюзивный виндовый софт или игры с анти-читом, не работающем под Линуксом, то можно оставить Винду в какой-нибудь резервации на ссд и перезагружаться сугубо по необходимости.
Предварительно поставив Яндекс-браузер
с нейросетями,чтоб наверняка?Вау, как остроумно. Хорошо, перефразирую: по каким признакам сериал лучше?
Чем именно сериал лучше?
Интернет-опрос показал, что 100% людей пользуется интернетом? :)
Из увлажняющих капель рекомендую Оптинол мягкое восстановление и Хилокомод. Это на основе врачебных рекомендаций, которые сам получил в ходе лечения глаз.
Если интересно, могу в своих бумажках посмотреть остальные варианты, которые мне советовали.
Я не знаю, какой классификацией Вы пользуетесь, но в классической она является ИИ.
Интереса ради, можете выделить признаки, по которым Вы определяете, что является ИИ, а что нет?
Даже игровые боты являются ИИ.
По текущей классификации, LLM - это ИИ, он же AI. То, с чем Вы пытаетесь его сравнить, опять же по текущей классификации называется сильный ИИ, или AGI, который сильно отличается по выдвигаемым к нему требованиям.
Взрыв тестового прототипа и взрыв полноценного пуска с настоящей полезной нагрузкой - в корне разные вещи.
У меня сейчас есть HDD на 10 терабайт под видео, и он на 85% заполнен. Но я как дракон - свою аудио- и видеоколлекцию храню на локальном диске.
После прочтения всё-таки остаётся вопрос, а при чём тут, собственно, японский бенто?
Это сработает, но эффект будет примерно такой же, как просто при прочтении случайной страницы словаря или как при зубрёжке стихотворений. Рано или поздно слова выучатся, но усилий придётся приложить гораздо больше.
Всё правильно, и об этом говорят практически все нормальные руководства по использованию программы. Они так же говорят, что чужими наборами лучше не пользоваться.
Для подавляющего числа случаев начального или среднего уровня вполне достаточно перевода и полного предложения (или нескольких, если очень хочется), из которого слово взято. На высоком уровне уже лучше переходить на монолингвальные словари, где определение слова даётся на том же языке, что и само слово. Тратить слишком много усилий на создание карточек тоже смысла нет.
Безусловно, можно выучить язык по множеству методик. SRS просто является одной из самых эффективных на сегодняшний день, т.к. позволяет запомнить наибольший объём за наименьшие усилия.
Использование слова в контексте, естественно, улучшает запоминаемость. Поэтому обычно анки рекомендуют использовать для повторения слов, встреченных в книге/фильме/игре ранее, и сохранять вместе с контекстом, например, брать целое предложение, в котором было слово, и показывать в ответе. Это особенно актуально для японского, где очень много похожих слов, использующихся в немного разном контексте.
90% кажется очень грубым преувеличением - в тексте Вы видите слова, как в Анки, плюс контекст, который в подавляющем большинстве случаев помогает, а не мешает. Очень сомнительно, что в такой ситуации вспоминаемость слова хуже, чем в SRS программе.
То, что Вы описываете под симуляцией - обиходное значение. В научном контексте она используется именно для обозначения моделирования.
Мейнтейнер - на данный момент всем понятный термин, имеющий конкретное значение. Предлагаемые же Вами варианты более размыты. "Разработчик" - наверное, самое широкое понятие в разработке софта, не дающий вообще никаких деталей. "Специалист, поддерживающий программный продукт" может обозначать что угодно от мейнтейнера до сотрудника первой линии колл-центра поддержки.
Любое предложение замены в угоду пуризму должно сохранять изначальный смысл. Почему такое предложение заплюсовано, несмотря на вред в отношении понятности текста - загадка.
Это не противоречит антипаттерну, но это всё ещё мешает как писать, так и читать код, когда половина кода - это возвращения ошибок, которые уровнем выше пробрасываются дальше, и дальше, и дальше - и так до возвращения кода 500 по всему стеку вызовов. У них нет отдельного обработчика, результат одинаковый, а текст нужен только для чтения логов.
Таких или подобных ситуаций очень много, и какой-нибудь классический try/except как в Питоне гораздо удобнее, когда обработку исключений можно централизовать, и не быть вынужденным размазывать обработку ошибок для КАЖДОГО вызова функции.
У нас в компании вроде довольно строгие линтеры, но они на такое не ругаются. И нам, в целом, не нужна вся эта тягомотина с типами ошибок и т.д., потому что обрабатываются они в бекэнде одинаково, поэтому мы пользуемся более простым алгоритмом - добавляем какой-то описательный текст и выбрасываем ошибку в ответе сервера. Этого УЖЕ достаточно чтобы понять, какая ошибка и где произошла, однако, если посмотреть на одну из функций, то там одних if err != nil {return fmt.Errorf(...)} получается 20 строк в функции на 65 строк в сумме (один из примеров). Если много вызовов в сторонние API, то порой больше половины строк - возврат разнообразных ошибок.
То, что Вы описываете на этот раз - идеальный случай, где везде нужен контекст, на него разные реакции и т.д. - и даже в этом случае обработка ошибок размазывается на 1000 мест в коде, и за всем этим следить совершенно неудобно.