А от чего же тогда "разрушаются" процессы? (не настаиваю на своём мнении, но тогда интересно понять Ваше). Сам ИИ лишь инструмент, из-за него самого ничего происходить не может в процессах. Вопрос в его неверном применении. При верном применении перестройка процессов продумывается внедряющими, они контролируемо изменяются, а у людей не возникает впечатления о их "разрушении".
Вопрос - стоит ли сейчас изучать языки программирования.
Безусловно стоит их изучать. И тем, и другим. Вопрос, скорее, на каком уровне. Я, например, знаю ассемблер. Я на нём ничего не пишу, но писать на C, а особенно искать баги, мне это помогало по сравнению с коллегами, которые его не знали, так как я понимал, "что под капотом". Сейчас мы видим, что при работе с бездумными (по факту такими, я не в уничижительном контексте) LLM фокус смещается с написания кода на его проверку и процессы вокруг написания. Её проводить, не зная языки не получится. Другое дело, что можно знать, а таем более помнить, гораздо меньше мелочей, т.е. изучать на более высоком уровне.
Равно как и вопрос, как оценивать работу, если большую её часть сделал ИИ.
По результату. Вопрос тогда не "как оценивать", а "как проверять". Возможно, надо вообще уйти от разделения на аналитика, разработчика и тестировщика и объединить функции, как когда-то и было (но это уже чистая догадка, скорее на подумать, от чего оттолкнуться).
Наивные рассуждения и поучения без обоснования в стиле: "Все учебники врут, только я знаю реальность". И, сомневаюсь, что автор лично знаком с крупными инвесторами, чтобы так уверенно рассуждать, что у них есть и чего нет. Не вижу смысла в дальнейшем обсуждении.
Вы зря смеялись. Там же не написано, что это единственная задача. При качественном выполнении этой задачи и идёт основной прирост прибыли у компании и инвесторов. Так как без пользы клиентов сложно привлекать и удерживать в течение длительного периода времени. Да и сотрудников мотивировать призывом: "наша главная задача - заработать прибыль боссу" сложнее, чем призывом "мы приносим прибыль людям".
Если честно, то не очень верится, что Вы не понимали заранее, чем завершится эксперимент. Я ещё из одних ранее прочитанных статей на Хабре примерно такого и ожидал результата (будет неплохой прототип, но с кучей ошибок и совершенно ненадёжный с массой неожиданных багов). Предположу, что он Вам нужен был, скорее, чтобы было что клиентам показывать при продлении договоров (на их аргументы "да нам ИИ все напишет, если скидки 90% не будет!".
Хотя статья много кому полезна в таком аспекте может быть, спасибо. Удивился, что карму Вам не подняла до высот заоблачных:-)
И интересно, что сказал (и что будет говорить) неизвестный мне апологет. Что-то сдаётся мне, что сильно это его позицию не изменит. Будет аргумент типа "у зануд, конечно, ничего не заработает".
Все эти замеры мало чего стоят без финального: "компания Х без ИИ выпустила продукт Z с затратами $10 млн, а с ИИ - c затратами $5 млн при сравнимой скорости и сравнимом качестве". Так как иначе это измерение каких-то отдельно взятых KPI в отрыве от результата.
P.s. За статью автору всё равно спасибо, конечно. И за стремление разобраться и пояснить.
Это не "грязь", это верхний средний класс. Родители работали очень хорошо оплачиваемыми преподавателями, а мать Брина - вообще в NASA. "тратил деньги в основном на компьютеры для семьи " - они тогда стоили очень дорого. У подавляющего большинства детей такой возможности просто не было. И учиться обоим в очень престижном дорогом Стендфорде без мощных связей не получилось бы.
У бэкапа периодичность должна быть такой, чтобы суммарная стоимость его снятия была менее стоимости ожидаемых потерь. Т.е. что-то, конечно, пропадет, но это точно не должно быть раз в три месяца, как в случае, указанном в статье.
удалил почти всю боевую базу компании вместе с бэкапами (восстановили из резервной копии трехмесячной давности, на это ушло два дня). Чем больше прав у агента, тем дороже стоит его ошибка
Идея, что агентов контролировать надо, верная, но пример неудачен. Это не стоимость ошибки агента. Это стоимость неверно организованного хранения бэкапа. Что угодно могло случиться с основным носителем. Бэкап для того и есть, чтобы не думать о каждом риске по отдельности.
производитель чипов даёт гарантии под долги своих покупателей, которые берут эти долги, чтобы купить его чипы.
И что тут автору не так? Есть стандартная история, когда производитель оборудования продаёт свои заводы, одновременно гарантируя их загрузку на 100% или определённый уровень. Аналогичные истории с продажей собственных офисов. Ну, а тут он их производит, но знает, что сможет задействовать.
LLM в помощь для ответа на Ваш вопрос. Но ключевым должно являться наличие этого желания разбираться у самого интервьюера, полагаю. Ну, например, разумно выглядит: "Дать задачу с неполными вводными или намеренно использовать библиотеку с багом. Компании смотрят, задаст ли джун уточняющие вопросы или молча сделает неправильно." "Проверить знание того, как работает инструмент под капотом, а не просто синтаксиса (например, не просто «как написать fetch», а «что такое event loop»)." "Проверить интерес к смежным сферам. Фронтендер должен понимать, как устроен CI/CD или база данных, бэкендер — как его данные отображаются пользователю." И т.д.
Я не вижу исследований, которые показывают, что LLM реально дают экономический выигрыш на всей цепи внедрения (E2E) для Еnterprise систем даже если "код всё лучше пишут AI агенты". Не кусочек "написать код", а всё, включая работу в проде и цену рисков ошибки из-за написания без понимания (какового у LLM нет - это его неотъемлемое свойство). Если экономического выигрыша так и не будет, то многое вернётся "на круги своя", и "старая" роль разработчика тоже никуда не денется (что не означает, что не обретёт новых черт). Разумеется, свою нишу LLM всё равно получат, но вот размер этой ниши будет определяться всё той же экономикой.
Спасибо за уточнение. Тогда правильно так: "нет у неё ни большого контекстного окна, ни reasoning, а стоимость не меньше других".
И я не виноват, так и должно было быть. Это всё DeepSeek. И он всё объяснил: "Это не случайность, а системное свойство: LLM не гарантирует логическую согласованность внутри ответа..."
P.s. Это самоирония про мою невиновность. Проверять надо.
Ясно, спасибо. То есть основное - использована оптимизированная под массовые шаблонные бизнес-задачи с генерацией документов очень дешёвая модель (нет у неё ни большого контекстного окна, ни reasoning, зато стоимость почти 0). И в них она действительно лидер.
У Вас название "Почему Алиса выигрывает", но из дальнейшего текста не ясно, а почему, модель, явно уступающая своим конкурентам в целом, внезапно на отдельной задаче выигрывает (что с некоторой вероятностью может быть, но явно требует пояснений). Не успел спросить у Вас, как увидел объяснения @ToxaBes, и вот они как раз выглядят достаточно ясными (правда, объясняют, почему Алиса НЕ выигрывает). В Вашем ответе ему, пояснений выигрыша Алисы тоже нет. Было бы интересно, если бы Вы разобрали этот вопрос. P.s. Не ставлю под сомнение, что задача иметь рабочий вариант на суверенных моделях Вами решена, вопрос о том, действительно ли суверенные модели при этом и лучшие.
Большое спасибо! Интересно. Пара вопросов к автору:
Хотя 10–30ток/с на пользовательской двухканальной DDR5 — все‑таки маловато.
А делать что-то предлагаете с этим? Например, Gemini предлагает так: 1) Разгон RAM и настройка таймингов (XMP / EXPO); 2) Использование кэша экспертов (Expert Caching); 3) Смена бэкенда через флаги потоков (--threads); 4) Частичный оффлоад (GPU Offloading) - перенос слоев модели в VRAM видеокарты; 5) Более жесткое квантование.
Как понимаю, Вы 4 и 5 применяли. А с 1 и 3 не возились?
даже на Q4-Q6-Q8 видно, что квантование модели оказывается далеко не бесплатным по качеству.
и
Q4 уже нельзя считать полностью бесплатным по качеству, особенно на небольших моделях.
немного не сочетаются. Или Q6-Q8 "на глаз" Вам, как пользователю были почти незаметны?
человеку не кажется тревожной - она читается как чья-то пометка, а не как подлог.
Не может быть пометок в подписываемом договоре. Это красный флаг. Человек, кому это тревожным не кажется, вообще не должен никакие серьёзные документы самостоятельно подписывать по уровню своих компетенций. Ему тогда кто-то с лучшими компетенциями нужен в помощь.
встречается она в файле на 95 страниц, где сам договор начинается с 83-й
вообще не понял. А что 82 страницы до договора собой представляют и зачем подписывающему договор их читать?
Внимательное чтение каждой страницы поймает что угодно
Это неверное утверждение. Сложные юридические конструкции или относительно простые, но написанные усложнённым языком, может не понять и достаточно компетентный человек, не являющийся юристом (или являющийся слабым юристом). Тут сервис особо полезен может быть.
С юридической стороны: если человек подписывает договор, не читая (пусть не сам, а глазами своего юриста), а просто потому, что модель его проверила, то "так ему и надо". Модель должна подчеркнуть риски, но 100% гарантию БЯМ всё равно не может дать по причине своей архитектуры. Обнаружение ошибок типа "Пункт 7.4 нарушением не считать, он стандартный для отрасли." человеком и будет поймано при прочтении (а вот в суде ссылаться на недействительность такого пункта вряд ли получится).
Надеюсь, у автора юридическая оговорка относительно возможностей модели присутствует в его сервисе.
Надо это понимать и проверять подозрительные моменты
Тактика проверки именно "подозрительных" моментов вызывает вопросы с точки зрения риск-менеджмента. Всё будет определяться квалификацией человека + его внимательностью в конкретный момент. Более риск-ориентированной является тактика проверки ключевых положений ответа, где определение, что такое "ключевой" зависит от самой задачи (бытовой пример: спрашивая, почему дома обязана служба ЖКУ что-то сделать бесплатно, сразу требовать от БЯМ сослаться на конкретный пункт закона, а далее, независимо от подозрительности ответа, читать этот пункт самостоятельно).
А от чего же тогда "разрушаются" процессы? (не настаиваю на своём мнении, но тогда интересно понять Ваше). Сам ИИ лишь инструмент, из-за него самого ничего происходить не может в процессах. Вопрос в его неверном применении. При верном применении перестройка процессов продумывается внедряющими, они контролируемо изменяются, а у людей не возникает впечатления о их "разрушении".
Безусловно стоит их изучать. И тем, и другим. Вопрос, скорее, на каком уровне. Я, например, знаю ассемблер. Я на нём ничего не пишу, но писать на C, а особенно искать баги, мне это помогало по сравнению с коллегами, которые его не знали, так как я понимал, "что под капотом".
Сейчас мы видим, что при работе с бездумными (по факту такими, я не в уничижительном контексте) LLM фокус смещается с написания кода на его проверку и процессы вокруг написания. Её проводить, не зная языки не получится. Другое дело, что можно знать, а таем более помнить, гораздо меньше мелочей, т.е. изучать на более высоком уровне.
По результату. Вопрос тогда не "как оценивать", а "как проверять". Возможно, надо вообще уйти от разделения на аналитика, разработчика и тестировщика и объединить функции, как когда-то и было (но это уже чистая догадка, скорее на подумать, от чего оттолкнуться).
Наивные рассуждения и поучения без обоснования в стиле: "Все учебники врут, только я знаю реальность". И, сомневаюсь, что автор лично знаком с крупными инвесторами, чтобы так уверенно рассуждать, что у них есть и чего нет.
Не вижу смысла в дальнейшем обсуждении.
Я бы сказал не "из-за ИИ", а "из-за людей, которые его бездумно внедряют. Зачастую даже не очень понимая, что это такое".
Вы зря смеялись. Там же не написано, что это единственная задача. При качественном выполнении этой задачи и идёт основной прирост прибыли у компании и инвесторов. Так как без пользы клиентов сложно привлекать и удерживать в течение длительного периода времени.
Да и сотрудников мотивировать призывом: "наша главная задача - заработать прибыль боссу" сложнее, чем призывом "мы приносим прибыль людям".
P.s. Это не я придумал, это основы менеджмента.
Если честно, то не очень верится, что Вы не понимали заранее, чем завершится эксперимент. Я ещё из одних ранее прочитанных статей на Хабре примерно такого и ожидал результата (будет неплохой прототип, но с кучей ошибок и совершенно ненадёжный с массой неожиданных багов).
Предположу, что он Вам нужен был, скорее, чтобы было что клиентам показывать при продлении договоров (на их аргументы "да нам ИИ все напишет, если скидки 90% не будет!".
Хотя статья много кому полезна в таком аспекте может быть, спасибо. Удивился, что карму Вам не подняла до высот заоблачных:-)
И интересно, что сказал (и что будет говорить) неизвестный мне апологет. Что-то сдаётся мне, что сильно это его позицию не изменит. Будет аргумент типа "у зануд, конечно, ничего не заработает".
Все эти замеры мало чего стоят без финального: "компания Х без ИИ выпустила продукт Z с затратами $10 млн, а с ИИ - c затратами $5 млн при сравнимой скорости и сравнимом качестве". Так как иначе это измерение каких-то отдельно взятых KPI в отрыве от результата.
P.s. За статью автору всё равно спасибо, конечно. И за стремление разобраться и пояснить.
Это не "грязь", это верхний средний класс. Родители работали очень хорошо оплачиваемыми преподавателями, а мать Брина - вообще в NASA. "тратил деньги в основном на компьютеры для семьи " - они тогда стоили очень дорого. У подавляющего большинства детей такой возможности просто не было.
И учиться обоим в очень престижном дорогом Стендфорде без мощных связей не получилось бы.
У бэкапа периодичность должна быть такой, чтобы суммарная стоимость его снятия была менее стоимости ожидаемых потерь. Т.е. что-то, конечно, пропадет, но это точно не должно быть раз в три месяца, как в случае, указанном в статье.
Идея, что агентов контролировать надо, верная, но пример неудачен. Это не стоимость ошибки агента. Это стоимость неверно организованного хранения бэкапа. Что угодно могло случиться с основным носителем. Бэкап для того и есть, чтобы не думать о каждом риске по отдельности.
И что тут автору не так? Есть стандартная история, когда производитель оборудования продаёт свои заводы, одновременно гарантируя их загрузку на 100% или определённый уровень. Аналогичные истории с продажей собственных офисов. Ну, а тут он их производит, но знает, что сможет задействовать.
LLM в помощь для ответа на Ваш вопрос. Но ключевым должно являться наличие этого желания разбираться у самого интервьюера, полагаю.
Ну, например, разумно выглядит: "Дать задачу с неполными вводными или намеренно использовать библиотеку с багом. Компании смотрят, задаст ли джун уточняющие вопросы или молча сделает неправильно."
"Проверить знание того, как работает инструмент под капотом, а не просто синтаксиса (например, не просто «как написать fetch», а «что такое event loop»)."
"Проверить интерес к смежным сферам. Фронтендер должен понимать, как устроен CI/CD или база данных, бэкендер — как его данные отображаются пользователю."
И т.д.
Я не вижу исследований, которые показывают, что LLM реально дают экономический выигрыш на всей цепи внедрения (E2E) для Еnterprise систем даже если "код всё лучше пишут AI агенты". Не кусочек "написать код", а всё, включая работу в проде и цену рисков ошибки из-за написания без понимания (какового у LLM нет - это его неотъемлемое свойство).
Если экономического выигрыша так и не будет, то многое вернётся "на круги своя", и "старая" роль разработчика тоже никуда не денется (что не означает, что не обретёт новых черт). Разумеется, свою нишу LLM всё равно получат, но вот размер этой ниши будет определяться всё той же экономикой.
Спасибо за уточнение.
Тогда правильно так: "нет у неё ни большого контекстного окна, ни reasoning, а стоимость не меньше других".
И я не виноват, так и должно было быть. Это всё DeepSeek. И он всё объяснил: "Это не случайность, а системное свойство: LLM не гарантирует логическую согласованность внутри ответа..."
P.s. Это самоирония про мою невиновность. Проверять надо.
Ясно, спасибо. То есть основное - использована оптимизированная под массовые шаблонные бизнес-задачи с генерацией документов очень дешёвая модель (нет у неё ни большого контекстного окна, ни reasoning, зато стоимость почти 0). И в них она действительно лидер.
У Вас название "Почему Алиса выигрывает", но из дальнейшего текста не ясно, а почему, модель, явно уступающая своим конкурентам в целом, внезапно на отдельной задаче выигрывает (что с некоторой вероятностью может быть, но явно требует пояснений).
Не успел спросить у Вас, как увидел объяснения @ToxaBes, и вот они как раз выглядят достаточно ясными (правда, объясняют, почему Алиса НЕ выигрывает).
В Вашем ответе ему, пояснений выигрыша Алисы тоже нет. Было бы интересно, если бы Вы разобрали этот вопрос.
P.s. Не ставлю под сомнение, что задача иметь рабочий вариант на суверенных моделях Вами решена, вопрос о том, действительно ли суверенные модели при этом и лучшие.
Большое спасибо! Интересно. Пара вопросов к автору:
А делать что-то предлагаете с этим?
Например, Gemini предлагает так:
1) Разгон RAM и настройка таймингов (XMP / EXPO);
2) Использование кэша экспертов (Expert Caching);
3) Смена бэкенда через флаги потоков (
--threads);4) Частичный оффлоад (GPU Offloading) - перенос слоев модели в VRAM видеокарты;
5) Более жесткое квантование.
Как понимаю, Вы 4 и 5 применяли. А с 1 и 3 не возились?
и
немного не сочетаются. Или Q6-Q8 "на глаз" Вам, как пользователю были почти незаметны?
Не может быть пометок в подписываемом договоре. Это красный флаг. Человек, кому это тревожным не кажется, вообще не должен никакие серьёзные документы самостоятельно подписывать по уровню своих компетенций. Ему тогда кто-то с лучшими компетенциями нужен в помощь.
вообще не понял. А что 82 страницы до договора собой представляют и зачем подписывающему договор их читать?
Это неверное утверждение. Сложные юридические конструкции или относительно простые, но написанные усложнённым языком, может не понять и достаточно компетентный человек, не являющийся юристом (или являющийся слабым юристом). Тут сервис особо полезен может быть.
С юридической стороны: если человек подписывает договор, не читая (пусть не сам, а глазами своего юриста), а просто потому, что модель его проверила, то "так ему и надо". Модель должна подчеркнуть риски, но 100% гарантию БЯМ всё равно не может дать по причине своей архитектуры. Обнаружение ошибок типа "
Пункт 7.4 нарушением не считать, он стандартный для отрасли." человеком и будет поймано при прочтении (а вот в суде ссылаться на недействительность такого пункта вряд ли получится).Надеюсь, у автора юридическая оговорка относительно возможностей модели присутствует в его сервисе.
Тактика проверки именно "подозрительных" моментов вызывает вопросы с точки зрения риск-менеджмента. Всё будет определяться квалификацией человека + его внимательностью в конкретный момент. Более риск-ориентированной является тактика проверки ключевых положений ответа, где определение, что такое "ключевой" зависит от самой задачи (бытовой пример: спрашивая, почему дома обязана служба ЖКУ что-то сделать бесплатно, сразу требовать от БЯМ сослаться на конкретный пункт закона, а далее, независимо от подозрительности ответа, читать этот пункт самостоятельно).
Печать в типографии и просмотр на экране наверняка требуют, как минимум, различного форматирования. Цветовая палитра может отличаться и т.д.