Так наоборот, я говорю, что все дураки как я сам, и смотрят как бы попроще. А вы делаете как посложнее.
Проще: открыть карточку проекта быстрым взглядом посмотреть и оценить пригодность по популярности и качеству вложенных сил автором в эту карточку
Сложнее: провести глубокий анализ, пройтись по всем ссылкам, поспорить с автором, найти где-то в дебрях бенчмарк, и тд и тп что требует недюжей мотивации
спуститесь с Олимпа, подробно распишите свою проделанную работу по общепринятым стандартам и наступит счастье
А от того, что язвите, вы себя профессионалом не делаете
Да, это прокси метрика, но она показывает популярность. А популярность это выбор, который основан на предпочтениях по перформансу/простоте документации/etc. Условно, каждый смотрит на ваш пакет и комплексно оценивает ваше решение по этим критериям, если вы лучше то скачивает ваш пакет, если другой лучше, то скачивает его.
Поэтому, на мой взгляд, это годится для оценки субъективных критериев. В том числе того насколько хорошо вы оформили карточку вашего пакет.
Вам бы не в конфронтации со всеми быть, а спокойно почитать, что вам тут понаписали. Отделите безосновательное и проведите работу над ошибками.
Поясню.
Когда я выбираю пакет или фреймворк, то уже имею сформированные привычки/паттерны по которым их выбираю. И если паттерн отличается, то я: 1) или испытываю фрустрацию, но разбираюсь 2) пробую альтернативный вариант, благо часто выбор есть.
Отвечая на вопрос из статьи:
Что мотивирует людей довольствоваться не самым лучшим решением в индустрии?
Ответ: Они решили, что самое лучшее решение другое.
Так вот, ваше решение по метрике, которая явно показывает общее суммарное качество - "Количество еженедельных скачиваний", не лучшее.
И вы можете или смириться и идти в сторону честного улучшения этого показателя, или можете доказывать здесь, что вы "не дурак", лучше никому от этого не станет.
Если смириться, то внезапно оказывается, что не только мне небыстро разбираться, а ещё десяткам комментаторов и минусующих вас. Так может всё таки провести работу над опубликованными решениями, довести до состояния когда даже Джун всё поймет?
Будете сидеть с розовыми очками, то так и останетесь недопонятым гением.
Ps: извините за сумбур, но честно говоря уже лень вести конструктивный диалог, учитывая, что вам самим это не интересно
Вы не поверите, но дока на английском с бенчмарками есть на гитхабе
Не поверю, из-за того, что вы плохо прописали метаинформацию, то ссылку на гитхаб найти не тривиально
Просто сравните:
Вот может я слепой, но в упор не вижу
UPD: нашел
В общем, да, мой наброс формально не актуален - ссылки то есть, НО... блин, как же не удобно вы сделали UX, я как человек который откровенно слаб в инфре JS сразу разобрался в Moment - всё стандартно, а над вашей библиотекой пришлось разбираться и с автором в комментариях спорить
Что мотивирует людей довольствоваться не самым лучшим решением в индустрии? Я, наверно, странный, но я не могу этого понять.
Вы просто в первую очередь задаетесь подобным вопросом, а нужно делать документацию (например, можно сделать понятную мини документацию прям в описании пакета), писать статьи о том как хорошо на практике ваш фреймворк решает от простых до сложных задач, в том числе или даже в первую очередь на английском языке
Показать таблицу с перформансом против лидеров было бы здорово
Очень плохо, что явно не прописана лицензия:
Ещё вам бы поработать над SEO:
ваш пакет
moment
Имхо, из ключевых слов у moment сразу понятно для чего нужен пакет, а у вас - нет
В общем, метаинформация пакета важна и обычный разработчик будет в тупую искать библиотеку в поисковике, а на ваш пакет он выйдет одним из последних (если вообще найдет)
Если хотите - могу ещё понабрасывать, благо есть за что. И удачи вам в популяризации ваших решений, только рад хорошо написанному и быстрому фронтенду
Начнем с того, что там на каждом шаге случайный выбор следующего токена
Это можно нивелировать, скрутив температуру в ноль, будет просто выбор наиболее вероятного токена. Задачи, где не требуется креатив, после такого обычно решаются лучше и стабильно (из минусов, правда, модель может зациклиться, но это в целом решаемая проблема).
Есть страны, которые пускают по внутреннему паспорту РФ (Армения/Беларусь, например), поэтому немного смысла до сих пор остается, другое дело, что их не шибко много, поэтому загранпаспорт необходим.
Мне казалось, что это китайцы в обход санкций делают такие карточки, перепаивая/допаивая память. Возможно, путаю с какой-то карточкой, но, кажется, нет. Но вроде кроме того, что это полуофициальщина, минусов нет, по крайней мере из того, что слышал: народ вроде учит модели и с ними всё ок.
Тем не менее я сомневаюсь, что JS медлителен от природы, или что мы исчерпали все возможности его улучшения.
Вообще странно слышать подобное, учитывая, что JS именно медлителен от природы), а то, что имеем сейчас с JIT и подобным, это именно попытка ускорить и выжать из него больше.
При этом как-то в статье не упоминается, что JS-приложения как-то неприлично много потребляют ОЗУ :( Вероятно, что даже среда разработчиков под JS-инфраструктуру ломанулась переписывать всё на Rust/любой другой язык именно из-за этого.
В целом читается так, будто это грусть JS-разработчика, который рассчитывал, что, выучив один язык, ему этого хватит для всего, но разочарование, что инфраструктурные проекты для языка пишутся на других, — понимаемо.
А, да. Перечитал, действительно. В голове, то я помнил, что в старой версии нельзя было перемещаться по воде, из-за этого титаны на островных картах были бесполезны.
Ухх, очень круто что этот обзор появился тут, ремейк прошел мимо меня, оригинальную игру очень люблю - игра детства.
С первого взгляда показалось что визуал сильно прокачали, но стилистика как будто стала чуть более мультяшной (на зданиях заметнее всего). Но как же чертовски это круто выглядит!
Интересно, что именно тут спустя 20лет я узнал, что оказывается в оригинале титаны могли ходить по воде)
Интересный вопрос... Если я правильно понял, суть следующая: "Почему решили сделать классификатор, вместо того чтобы сделать честный MoE?"
Чисто формально у нас не MoE, хотя, если смотреть на это с точки зрения архитектуры, то мы близки к нему, но есть важные нюансы.
Идти в сторону честного MoE, на мой взгляд, нужно, если хочется иметь одну универсальную модель. В нашем случае нет продуктовой потребности иметь именно одну модель, но есть потребность держать относительно высокую нагрузку в условиях ограниченных ресурсов.
Предположим, что мы сделаем микс и получится что-то вроде Mixtral 8x7B, тогда с такой постановкой MoE проигрывает, тк в проде его держать дороже: он требует больше памяти на gpu и активных параметров будет не 7B, а 12B, то есть увеличится время ответа.
Если вопрос с перфомансом и потреблением памяти отбросить, то MoE выглядит перспективно, да.
Привет, можешь накинуть больше деталей, пожалуйста, чтобы мы могли исправить недочеты. Насчёт абзацев: это повторяется с конкретным действием или со всеми и только на конкретном сайте или на любом?
Правильно я понимаю, что YaGPT тут для дописывания, генерации и фактчека, а для парафразы, исправления и улучшения энкдек?
Формально все модели YaGPT, но да, исправление/улучшение и сокращение сейчас — это enc-dec. Остальное dec из-за того, что пока не дошли руки либо на них есть просадка в качестве, которую только предстоит побороть.
Есть ли подробности об архитектуре энкдека? Учили полностью своё, резали mt0/aya-101, тюнили FRED-T5? Есть ли итоговые метрики?
Своё, вдохновлялись T5.
Будет ли модель где-то доступна, кроме внутреннего продукта (подозреваю, что я уже знаю ответ, но чем чёрт не шутит)?
Жаль что англицизм оказался неудобным для чтения, для меня это привычный термин поэтому так и написал.
Если говорить о том абзаце, под «заинферить» я имел в виду процесс предсказания результатов моделью, то есть тот момент, когда мы уже загрузили веса модели в память GPU и начали проводить вычисления с целью получить решение задачи от модели, которую мы до этого обучили.
Так вот, модели из семейства YandexGPT разные, и в основном разница заключается в том, как хорошо модели решают широкий спектр задач, и в том, сколько ресурсов требуется для того, чтобы решить такую задачу. Для нас важно иметь относительно низкое потребление ресурсов, поэтому выбрали модель с суффиксом Light. Она попроще, и Pro лучше и точнее следует командам, но в обмен тратится сильно больше ресурсов, разница примерно на порядок. Поэтому мы решили сфокусироваться на ограниченном спектре решаемых задач и за счёт этого хорошо их решаем, минус такого подхода, что какие-то задачи мы, в отличие от Pro, не умеем решать вовсе.
Так наоборот, я говорю, что все дураки как я сам, и смотрят как бы попроще. А вы делаете как посложнее.
Проще: открыть карточку проекта быстрым взглядом посмотреть и оценить пригодность по популярности и качеству вложенных сил автором в эту карточку
Сложнее: провести глубокий анализ, пройтись по всем ссылкам, поспорить с автором, найти где-то в дебрях бенчмарк, и тд и тп что требует недюжей мотивации
спуститесь с Олимпа, подробно распишите свою проделанную работу по общепринятым стандартам и наступит счастье
А от того, что язвите, вы себя профессионалом не делаете
А что не нравится?
Да, это прокси метрика, но она показывает популярность. А популярность это выбор, который основан на предпочтениях по перформансу/простоте документации/etc. Условно, каждый смотрит на ваш пакет и комплексно оценивает ваше решение по этим критериям, если вы лучше то скачивает ваш пакет, если другой лучше, то скачивает его.
Поэтому, на мой взгляд, это годится для оценки субъективных критериев. В том числе того насколько хорошо вы оформили карточку вашего пакет.
Вам бы не в конфронтации со всеми быть, а спокойно почитать, что вам тут понаписали. Отделите безосновательное и проведите работу над ошибками.
Поясню.
Когда я выбираю пакет или фреймворк, то уже имею сформированные привычки/паттерны по которым их выбираю. И если паттерн отличается, то я: 1) или испытываю фрустрацию, но разбираюсь 2) пробую альтернативный вариант, благо часто выбор есть.
Отвечая на вопрос из статьи:
Ответ: Они решили, что самое лучшее решение другое.
Документированное/Понятное/Производительное/etc, неважно показателей много.
Так вот, ваше решение по метрике, которая явно показывает общее суммарное качество - "Количество еженедельных скачиваний", не лучшее.
И вы можете или смириться и идти в сторону честного улучшения этого показателя, или можете доказывать здесь, что вы "не дурак", лучше никому от этого не станет.
Если смириться, то внезапно оказывается, что не только мне небыстро разбираться, а ещё десяткам комментаторов и минусующих вас. Так может всё таки провести работу над опубликованными решениями, довести до состояния когда даже Джун всё поймет?
Будете сидеть с розовыми очками, то так и останетесь недопонятым гением.
Ps: извините за сумбур, но честно говоря уже лень вести конструктивный диалог, учитывая, что вам самим это не интересно
Не поверю, из-за того, что вы плохо прописали метаинформацию, то ссылку на гитхаб найти не тривиально
Просто сравните:
Вот может я слепой, но в упор не вижу
UPD: нашел
В общем, да, мой наброс формально не актуален - ссылки то есть, НО... блин, как же не удобно вы сделали UX, я как человек который откровенно слаб в инфре JS сразу разобрался в Moment - всё стандартно, а над вашей библиотекой пришлось разбираться и с автором в комментариях спорить
PS: минус не я вам поставил
Вы просто в первую очередь задаетесь подобным вопросом, а нужно делать документацию (например, можно сделать понятную мини документацию прям в описании пакета), писать статьи о том как хорошо на практике ваш фреймворк решает от простых до сложных задач, в том числе или даже в первую очередь на английском языке
Показать таблицу с перформансом против лидеров было бы здорово
Очень плохо, что явно не прописана лицензия:
Ещё вам бы поработать над SEO:
Имхо, из ключевых слов у moment сразу понятно для чего нужен пакет, а у вас - нет
В общем, метаинформация пакета важна и обычный разработчик будет в тупую искать библиотеку в поисковике, а на ваш пакет он выйдет одним из последних (если вообще найдет)
Если хотите - могу ещё понабрасывать, благо есть за что. И удачи вам в популяризации ваших решений, только рад хорошо написанному и быстрому фронтенду
Это можно нивелировать, скрутив температуру в ноль, будет просто выбор наиболее вероятного токена. Задачи, где не требуется креатив, после такого обычно решаются лучше и стабильно (из минусов, правда, модель может зациклиться, но это в целом решаемая проблема).
либо в пользу TDD, учитывая что LLM может сама набросать тест-кейсы, то оно даже становится осмысленным и не ресурсозатратным
Интересно, что за нейронки использовались и почему сломалось, обычно все модели оттуда работают локально и не ломаются одним днем.
Насчет качества тоже интересно, в целом языковые нейронки — они для тех, кто имеет видеокарточку, иначе качество будет паршивым, да.
Есть страны, которые пускают по внутреннему паспорту РФ (Армения/Беларусь, например), поэтому немного смысла до сих пор остается, другое дело, что их не шибко много, поэтому загранпаспорт необходим.
Скорее случайным и не постоянным, но таким, чтобы птицы периодически прилетали проверить наличие корма и порадовать мецената своим видом.
Мне казалось, что это китайцы в обход санкций делают такие карточки, перепаивая/допаивая память. Возможно, путаю с какой-то карточкой, но, кажется, нет. Но вроде кроме того, что это полуофициальщина, минусов нет, по крайней мере из того, что слышал: народ вроде учит модели и с ними всё ок.
Вообще странно слышать подобное, учитывая, что JS именно медлителен от природы), а то, что имеем сейчас с JIT и подобным, это именно попытка ускорить и выжать из него больше.
При этом как-то в статье не упоминается, что JS-приложения как-то неприлично много потребляют ОЗУ :( Вероятно, что даже среда разработчиков под JS-инфраструктуру ломанулась переписывать всё на Rust/любой другой язык именно из-за этого.
В целом читается так, будто это грусть JS-разработчика, который рассчитывал, что, выучив один язык, ему этого хватит для всего, но разочарование, что инфраструктурные проекты для языка пишутся на других, — понимаемо.
Если расскажете детали (можно в лс), то разберёмся и исправим, чтобы такие досадные ошибки ни у кого не возникали.
А, да. Перечитал, действительно. В голове, то я помнил, что в старой версии нельзя было перемещаться по воде, из-за этого титаны на островных картах были бесполезны.
Ухх, очень круто что этот обзор появился тут, ремейк прошел мимо меня, оригинальную игру очень люблю - игра детства.
С первого взгляда показалось что визуал сильно прокачали, но стилистика как будто стала чуть более мультяшной (на зданиях заметнее всего). Но как же чертовски это круто выглядит!
Интересно, что именно тут спустя 20лет я узнал, что оказывается в оригинале титаны могли ходить по воде)
Интересный вопрос... Если я правильно понял, суть следующая: "Почему решили сделать классификатор, вместо того чтобы сделать честный MoE?"
Чисто формально у нас не MoE, хотя, если смотреть на это с точки зрения архитектуры, то мы близки к нему, но есть важные нюансы.
Идти в сторону честного MoE, на мой взгляд, нужно, если хочется иметь одну универсальную модель. В нашем случае нет продуктовой потребности иметь именно одну модель, но есть потребность держать относительно высокую нагрузку в условиях ограниченных ресурсов.
Предположим, что мы сделаем микс и получится что-то вроде Mixtral 8x7B, тогда с такой постановкой MoE проигрывает, тк в проде его держать дороже: он требует больше памяти на gpu и активных параметров будет не 7B, а 12B, то есть увеличится время ответа.
Если вопрос с перфомансом и потреблением памяти отбросить, то MoE выглядит перспективно, да.
Привет, можешь накинуть больше деталей, пожалуйста, чтобы мы могли исправить недочеты. Насчёт абзацев: это повторяется с конкретным действием или со всеми и только на конкретном сайте или на любом?
Формально все модели YaGPT, но да, исправление/улучшение и сокращение сейчас — это enc-dec. Остальное dec из-за того, что пока не дошли руки либо на них есть просадка в качестве, которую только предстоит побороть.
Своё, вдохновлялись T5.
О таких планах мне не известно, к сожалению.
Жаль что англицизм оказался неудобным для чтения, для меня это привычный термин поэтому так и написал.
Если говорить о том абзаце, под «заинферить» я имел в виду процесс предсказания результатов моделью, то есть тот момент, когда мы уже загрузили веса модели в память GPU и начали проводить вычисления с целью получить решение задачи от модели, которую мы до этого обучили.
Так вот, модели из семейства YandexGPT разные, и в основном разница заключается в том, как хорошо модели решают широкий спектр задач, и в том, сколько ресурсов требуется для того, чтобы решить такую задачу. Для нас важно иметь относительно низкое потребление ресурсов, поэтому выбрали модель с суффиксом Light. Она попроще, и Pro лучше и точнее следует командам, но в обмен тратится сильно больше ресурсов, разница примерно на порядок. Поэтому мы решили сфокусироваться на ограниченном спектре решаемых задач и за счёт этого хорошо их решаем, минус такого подхода, что какие-то задачи мы, в отличие от Pro, не умеем решать вовсе.
Надеюсь, прояснил.