Да, “быстрее” не должно значить “хуже”. Но научная статья и пост на Хабре - разные жанры. На Хабре ценность часто в практическом опыте: что пробовали, где ошиблись, какие выводы сделали. И постить апдейты статей, которые появляются в процессе - тоже ок. Поэтому такой формат интереснее и аудитория Хабра шире, чем у научных журналов.
Само собой 1 хорошая статья лучше 10 проходных. Цель не в том, чтобы писать больше, а в том, чтобы быстрее доходить до нормального качества: собрать фактуру, не потерять мысль, убрать воду. Если на выходе посредственно — виноват не ИИ, а косячит процесс и значит, что его нужно дорабатывать дальше. Даже чисто для эксперимента
Согласен, обмен сгенерированными полотнами текста вместо нормальной коммуникации — плохой сценарий. Поэтому LLM — это не замена мышления, а помощник, чтобы структурировать, проверить слепые зоны. Ответственность за смысл и решения все равно на человеке.
Джун он пайтон разработчик и не знает как создавать LLM-приложения. Соответственно в этом и заключается смысл – быстро переквалифицировать его в этом направлении
Mac Studio — ок вариант, согласен. Для локальных экспериментов, пэт проектов и маленьких команд удобно и выгодно. Но в статье у меня другой сценарий на ~100 000 диалогов в день. Тут и требования по SLA, отказоустойчивости, масштабированию. Там не столько "настроить за 5 минут" надо, а параллельность, управляемость и стоимость токена при росте трафика обеспечить.
4090/5090 дешевле, но это другой класс железа уже. Памяти меньше, нужен шардинг по нескольким GPU и больше компромиссов по надёжности. Поэтому в табличку сознательно не добавил
Да, “быстрее” не должно значить “хуже”. Но научная статья и пост на Хабре - разные жанры. На Хабре ценность часто в практическом опыте: что пробовали, где ошиблись, какие выводы сделали. И постить апдейты статей, которые появляются в процессе - тоже ок. Поэтому такой формат интереснее и аудитория Хабра шире, чем у научных журналов.
Само собой 1 хорошая статья лучше 10 проходных. Цель не в том, чтобы писать больше, а в том, чтобы быстрее доходить до нормального качества: собрать фактуру, не потерять мысль, убрать воду. Если на выходе посредственно — виноват не ИИ, а косячит процесс и значит, что его нужно дорабатывать дальше. Даже чисто для эксперимента
Согласен, обмен сгенерированными полотнами текста вместо нормальной коммуникации — плохой сценарий. Поэтому LLM — это не замена мышления, а помощник, чтобы структурировать, проверить слепые зоны. Ответственность за смысл и решения все равно на человеке.
Брали gpt5.4-mini и дотюнили ее через их ЛК
Джун он пайтон разработчик и не знает как создавать LLM-приложения. Соответственно в этом и заключается смысл – быстро переквалифицировать его в этом направлении
В нашем случае потребовалось полтора месяца до момента, когда он смог приносить коммерческую выгоду. Речи о благотворительности в статье не было)
Mac Studio — ок вариант, согласен. Для локальных экспериментов, пэт проектов и маленьких команд удобно и выгодно. Но в статье у меня другой сценарий на ~100 000 диалогов в день. Тут и требования по SLA, отказоустойчивости, масштабированию. Там не столько "настроить за 5 минут" надо, а параллельность, управляемость и стоимость токена при росте трафика обеспечить.
4090/5090 дешевле, но это другой класс железа уже. Памяти меньше, нужен шардинг по нескольким GPU и больше компромиссов по надёжности. Поэтому в табличку сознательно не добавил