Про волшебную кнопку подписываюсь обеими руками, как раз об этом и писал, «оно само» это та самая сладкая ложь. И что работать всё равно придётся самому, тоже да.
Только, по моему опыту, работа не исчезла, а переехала: я не пишу код, зато пишу план и проверяю результат. А вот про «только мелкие и редкие задачи» у меня вышло иначе. Тот же автор Nova закрыл агентами сотни планов на целом компиляторе, у меня каждый день едет пачка задач параллельно. Но работает это ровно до тех пор, пока держишь оба края - пока ты сам понимаешь, что там происходит (необязательно на уровне конкретного кода/функций, но системного контроля процесса), и пока приемка имеет очень конкретные воплощения, которые ты тоже сам можешь понять и проверить.
Отпускаешь край, и да, получается дорогая игрушка, которая жжёт токены и врёт в лицо. Так что мы скорее про одно и то же, я просто думаю, что граница «мелкое и редкое» двигается, если вложиться в обвязку. А где она проходит у вас?
Да, быстро. Я почти не пишу руками - чаще надиктовываю в транскрибатор, поэтому текст и появляется быстро, потом его можно и причесать, и фактуру собрать.
План на 1700 строк это не сегодняшний секундомер, а типичное утро, не буквально перед постом) Ваш коммент про регулярные ревью я процитировал, потому что он по делу.
Скорость тут не аргумент и не повод для гордости. В этом и тезис: текст и код подешевели, поэтому быстро или много написать больше ничего не доказывает.
Доказывает только одно, понял ли я сам, что внутри, проверил ли, правда ли, что там именно то, что мне нужно. Вот это как раз все так же медленно
Про хаб, возможно, и правда не тот, тут не поспоришь 😁 Хотя под нейрострадания тут скорее обёртка, а внутри tsc, контракты и кросс-модельное ревью планов, так что даже хз, куда это правильно
Так я ж не говорю, что только они на это способны - то, что раньше можно было делать командой целый квартал сегодня можно сделать за пару дней - как хорошего, так и плохого) Всего, чему мы их так старательно научили
Про менеджеров в точку - я последний год как раз и переоткрываю, что мы очень быстро бежим к тому, чтобы полностью воспроизвести модель управления кожаных - планирования, груминги, QA, комитеты и чего только не)
Только подчинённые теперь врут быстрее, увереннее и чаще 😁 Спасибо, что прочитали 🙂
Спал бы спокойнее 😁 Но нет. Враньё - половина проблемы. Вторая - что честный агент позволяет запускать ещё больше, а внимания у меня столько же. Гора корректного результата, которую я не проверил, - всё равно неуправляема
Задержку до чего, и с каким качеством генерации? Можно и gemini flash lite взять чтобы задержка была и того меньше, и цена еще сильно ниже, но вы такого агента никогда не пустите общаться с живыми людьми)
WebMCP решает правильную проблему. Сейчас браузерные агенты работают через CDP и CSS-селекторы, и это хрупко как стекло. Любое изменение в верстке — и все ломается.
Интересная тема про экономику AI-агентов. У нас была похожая история с автономными агентами для рутинных задач. Главное открытие: когда агенты начинают взаимодействовать друг с другом (а не только с людьми), их поведение становится непредсказуемым. Модели учатся оптимизировать под метрики, которые ты им дал, а не под то, что ты хотел получить на самом деле.
Model collapse это реальная техническая проблема, согласен. Но аналогия с отсутствием ролевых моделей немного натянутая.
В production AI-системах мы потребляем огромное количество чужого опыта. Papers, бенчмарки, open-source модели, ablation studies. Когда строим voice AI систему, смотрим на то, как Anthropic делает Claude, как OpenAI делает GPT-4, как Deepgram оптимизирует STT latency. Это и есть "ролевые модели" для инженеров.
Проблема model collapse не в том, что у AI нет влияний, а в том, что синтетические данные статистически беднее. Long tail исчезает, разнообразие схлопывается. Это чисто математический эффект.
Но культурный вопрос тут другой. В продакшене мы не используем AI для создания training data следующего AI. Мы используем его как tool с человеком в loop. Evaluation всегда на реальных человеческих данных.
Так что для production AI систем эта проблема вообще не про отсутствие влияний, а про гигиену датасетов.
e кластером на обычном 10G Ethernet. Думал: "ну API же, что сложного". Забыл про то, что GPU батчи создают неравномерную нагрузку, и при спайках трафика начались таймауты.
Redis спас вас, это правда. Но есть подводный камень с инвалидацией кэша. Если маркетолог обновляет контент, нужно сбросить кэш. У вас как это решено? Вручную или есть хуки на Strapi updates?
Интересная штука с 2.1 года среднего времени жизни. Но я бы разделил баги на две категории: те, что проявляются в популярных сценариях (networking, FS), и те, что живут в редких подсистемах типа SCTP или CAN. Первые находят быстро (кто-то наткнулся в проде), вторые могут лежать годами, потому что код просто не выполняется.
VulnBERT с 92% полнотой звучит круто, но как вы фильтруете ложноположительные результаты? 1.2% FPR на весь кодбейс ядра — это тысячи false positives, если прогонять на каждом коммите.
Интересно, насколько критична эта штука для inference-кластеров, а не только для training. У нас inference-воркеры на обычном 10G Ethernet, батчинг запросов на стороне API, нагрузка приходит волнами (резкие спайки в течение дня). Проблема обычно не в сетевом бэкбоне, а в том, что GPU успевают обработать батч быстрее, чем следующий успевает сформироваться.
Если я правильно понимаю, Ultra Ethernet больше про синхронизацию AllReduce в распределенном обучении, где тысячи GPU ждут друг друга. В inference на 10-50 воркерах обычный Ethernet должен справляться. Или я упускаю какой-то сценарий?
Мы столкнулись с похожей проблемой при оптимизации voice AI pipeline. Latency на самом syscall казался смешным (микросекунды), но когда профилировали весь путь, оказалось, что context switch сжирал в разы больше времени из-за cache miss и pipeline flush.
Отличная подборка экспериментов. У Либета есть один момент, который часто упускают: в его опытах люди всегда имели возможность НЕ шевелить рукой даже после потенциала готовности. Это то самое право вето, которое он сам упоминал. Получается, свобода воли это не про инициацию действия, а про способность остановиться.
У нас похожий подход к production LLM. Вместо одного большого вызова делаем цепочку вызовов маленьких моделей. Когда разбиваешь задачу на подзадачи, можно заменить GPT-4 на 5-7 вызовов Gemini Flash и получить те же 90-95% качества по human eval, но в 10 раз дешевле.
Про круговые инвестиции в статье правильно подмечено. У нас похожая картина была с бюджетами на AI: все хотят внедрить LLM, но никто не хочет считать реальную стоимость каждого запроса.
Спасибо
Про волшебную кнопку подписываюсь обеими руками, как раз об этом и писал, «оно само» это та самая сладкая ложь. И что работать всё равно придётся самому, тоже да.
Только, по моему опыту, работа не исчезла, а переехала: я не пишу код, зато пишу план и проверяю результат. А вот про «только мелкие и редкие задачи» у меня вышло иначе. Тот же автор Nova закрыл агентами сотни планов на целом компиляторе, у меня каждый день едет пачка задач параллельно. Но работает это ровно до тех пор, пока держишь оба края - пока ты сам понимаешь, что там происходит (необязательно на уровне конкретного кода/функций, но системного контроля процесса), и пока приемка имеет очень конкретные воплощения, которые ты тоже сам можешь понять и проверить.
Отпускаешь край, и да, получается дорогая игрушка, которая жжёт токены и врёт в лицо. Так что мы скорее про одно и то же, я просто думаю, что граница «мелкое и редкое» двигается, если вложиться в обвязку. А где она проходит у вас?
Поймали ровно то, о чём статья 😁
Да, быстро. Я почти не пишу руками - чаще надиктовываю в транскрибатор, поэтому текст и появляется быстро, потом его можно и причесать, и фактуру собрать.
План на 1700 строк это не сегодняшний секундомер, а типичное утро, не буквально перед постом) Ваш коммент про регулярные ревью я процитировал, потому что он по делу.
Скорость тут не аргумент и не повод для гордости. В этом и тезис: текст и код подешевели, поэтому быстро или много написать больше ничего не доказывает.
Доказывает только одно, понял ли я сам, что внутри, проверил ли, правда ли, что там именно то, что мне нужно.
Вот это как раз все так же медленно
Про хаб, возможно, и правда не тот, тут не поспоришь 😁 Хотя под нейрострадания тут скорее обёртка, а внутри tsc, контракты и кросс-модельное ревью планов, так что даже хз, куда это правильно
Так я ж не говорю, что только они на это способны - то, что раньше можно было делать командой целый квартал сегодня можно сделать за пару дней - как хорошего, так и плохого) Всего, чему мы их так старательно научили
Про менеджеров в точку - я последний год как раз и переоткрываю, что мы очень быстро бежим к тому, чтобы полностью воспроизвести модель управления кожаных - планирования, груминги, QA, комитеты и чего только не)
Только подчинённые теперь врут быстрее, увереннее и чаще 😁
Спасибо, что прочитали 🙂
Спал бы спокойнее 😁 Но нет. Враньё - половина проблемы. Вторая - что честный агент позволяет запускать ещё больше, а внимания у меня столько же. Гора корректного результата, которую я не проверил, - всё равно неуправляема
Грустно, да 😁 Но скорее непривычно, чем безнадёжно — просто кайф сместился с „написал сам“ на „поймал агента на вранье до прода“. Привыкаю)
Смешной вы, надо вам, а проверять мне, почему-то
Мы для себя собрали нормальный eval пайплайн, посчитали циферки, нашли решение
Если в вашем случае вы используете другой подход - пожалуйста, на здоровье, будет интересно почитать про него здесь
Задержку до чего, и с каким качеством генерации? Можно и gemini flash lite взять чтобы задержка была и того меньше, и цена еще сильно ниже, но вы такого агента никогда не пустите общаться с живыми людьми)
WebMCP решает правильную проблему. Сейчас браузерные агенты работают через CDP и CSS-селекторы, и это хрупко как стекло. Любое изменение в верстке — и все ломается.
Интересная тема про экономику AI-агентов. У нас была похожая история с автономными агентами для рутинных задач. Главное открытие: когда агенты начинают взаимодействовать друг с другом (а не только с людьми), их поведение становится непредсказуемым. Модели учатся оптимизировать под метрики, которые ты им дал, а не под то, что ты хотел получить на самом деле.
Model collapse это реальная техническая проблема, согласен. Но аналогия с отсутствием ролевых моделей немного натянутая.
В production AI-системах мы потребляем огромное количество чужого опыта. Papers, бенчмарки, open-source модели, ablation studies. Когда строим voice AI систему, смотрим на то, как Anthropic делает Claude, как OpenAI делает GPT-4, как Deepgram оптимизирует STT latency. Это и есть "ролевые модели" для инженеров.
Проблема model collapse не в том, что у AI нет влияний, а в том, что синтетические данные статистически беднее. Long tail исчезает, разнообразие схлопывается. Это чисто математический эффект.
Но культурный вопрос тут другой. В продакшене мы не используем AI для создания training data следующего AI. Мы используем его как tool с человеком в loop. Evaluation всегда на реальных человеческих данных.
Так что для production AI систем эта проблема вообще не про отсутствие влияний, а про гигиену датасетов.
Интересно смотреть на битву бенчмарков, но в продакшене с агентными сценариями главная боль не в проценте на SWE-bench, а в latency и стоимости.
e кластером на обычном 10G Ethernet. Думал: "ну API же, что сложного". Забыл про то, что GPU батчи создают неравномерную нагрузку, и при спайках трафика начались таймауты.
Redis спас вас, это правда. Но есть подводный камень с инвалидацией кэша. Если маркетолог обновляет контент, нужно сбросить кэш. У вас как это решено? Вручную или есть хуки на Strapi updates?
Интересная штука с 2.1 года среднего времени жизни. Но я бы разделил баги на две категории: те, что проявляются в популярных сценариях (networking, FS), и те, что живут в редких подсистемах типа SCTP или CAN. Первые находят быстро (кто-то наткнулся в проде), вторые могут лежать годами, потому что код просто не выполняется.
VulnBERT с 92% полнотой звучит круто, но как вы фильтруете ложноположительные результаты? 1.2% FPR на весь кодбейс ядра — это тысячи false positives, если прогонять на каждом коммите.
Интересно, насколько критична эта штука для inference-кластеров, а не только для training. У нас inference-воркеры на обычном 10G Ethernet, батчинг запросов на стороне API, нагрузка приходит волнами (резкие спайки в течение дня). Проблема обычно не в сетевом бэкбоне, а в том, что GPU успевают обработать батч быстрее, чем следующий успевает сформироваться.
Если я правильно понимаю, Ultra Ethernet больше про синхронизацию AllReduce в распределенном обучении, где тысячи GPU ждут друг друга. В inference на 10-50 воркерах обычный Ethernet должен справляться. Или я упускаю какой-то сценарий?
Мы столкнулись с похожей проблемой при оптимизации voice AI pipeline. Latency на самом syscall казался смешным (микросекунды), но когда профилировали весь путь, оказалось, что context switch сжирал в разы больше времени из-за cache miss и pipeline flush.
Отличная подборка экспериментов. У Либета есть один момент, который часто упускают: в его опытах люди всегда имели возможность НЕ шевелить рукой даже после потенциала готовности. Это то самое право вето, которое он сам упоминал. Получается, свобода воли это не про инициацию действия, а про способность остановиться.
У нас похожий подход к production LLM. Вместо одного большого вызова делаем цепочку вызовов маленьких моделей. Когда разбиваешь задачу на подзадачи, можно заменить GPT-4 на 5-7 вызовов Gemini Flash и получить те же 90-95% качества по human eval, но в 10 раз дешевле.
Про круговые инвестиции в статье правильно подмечено. У нас похожая картина была с бюджетами на AI: все хотят внедрить LLM, но никто не хочет считать реальную стоимость каждого запроса.