К задаче про два потока: как-то не элегантно с этим numberTurn. Я особо не думал, но первая мысль была сделать два лока (по одному на поток) - ждать свой и будить чужой.
>то теперь очевидно: будущее технологий лежит в разработке более эффективных алгоритмов, а не в безграничном наращивании вычислительных мощностей. Это открывает новые перспективы для конкурентов и ставит под сомнение долгосрочные прогнозы NVIDIA.
Будущее лежит и там и там. Это и так было очевидно всем, кто следит за новостями в сфере GenAI. Новые алгоритмы появлялись все это время и куча моделей (в том числе от небольших компаний) догоняли топовые модели. Что до железа - без него никак, так или иначе это ещё один способ скейлинга.
Резюмируем — преподавание английского это практически БЕЗальтернативный метод. Его жалкие конкуренты — это погружение (поехать в страну, где говорят на английском) или самостоятельное обучение (что чаще всего СИЛЬНО результативнее по статистике).
Если человеку настолько НАДО выучить язык, что он берется за самостоятельное обучение, то логично ожидать бОльшую вероятность успеха, чем у тех, кому просто "надо" (по типу заставили в школе или дают бесплатные курсы на работе). Банальный вопрос мотивации.
За 1.5 года жизни в Сербии я встретил ТРЁХ людей, кто не говорит на англе. Среди прохожих, продавцом в магазине, леди на почте.. Знаете сколько я встретил в РФ говорящих на англе за 28 лет жизни? Тоже троих.
Я живу в Сербии уже почти 3 года. Именно говорит по-английски тут в основном молодежь. Люди среднего возраста (30-50 лет) либо не знаю совсем, либо знают на уровне базовой школьной программы РФ. Причем доходило до абсурда, когда в центральном городском бизнес-отделении банка никто не говорит на английском вообще.
Во-первых, не символов, а токенов (это немного другое)
Во-вторых, уже довольно давно это 128000 токенов
В-третьих, есть модели и с большим context size. (Google Gemini Pro - 2 миллиона токенов)
Но обычно используется RAG (или его модификации), поэтому нет нужды запихивать все целиком
Мы проводили эксперименты с запихиванием умеренного проекта в контекст целиком - в целом это работает, но нужно очень четко ставить задачу, чтобы LLM не потерялась в контекесте. Ну и цена не маленькая.
Кроме того, если есть мануал — быстрее и проще самому его прочитать и написать соответствующий код, а если нет — у нас для вас плохие новости.
Мы обсуждали не "проще", а возможности LLM.
Задачи с нечеткой постановкой, когда заранее непонятно, лучше заколачивать, или завинчивать, — вот настоящая ахиллесова пята генеративных моделей. Потому что правильный ответ очень часто заключается вне исходной постановки (приклеивать в варианте выше).
Задачи с нечеткой постановкой в принципе штука спорная. Вам и человек не факт что решит ее так, как надо вам, чего уж говорить про LLM. И, кстати, приведенный Вами пример вполне себе решается LLM, если сформулировать задачу не как указание к действию, а спросить про альтернативные решения.
Я не являюсь большим фанатом LLM, но нужно трезво смотреть на вещи. LLM принципиально могут решать даже тяжелые инженерные задачи, если решить вопрос с "мышлением программиста".
Я как-то проводил эксперимент - взял одну задачу на работе (простенькую, немного подебажить и поправить несколько десяток строк кода в нескольких файлах) и полностью решил ее с помощью LLM, выступая в роли интерфейса (запустить команды/скопировать файлы/внести изменения/и т.д.) и задавая вопросы, которые в критических местах "подталкивали" LLM в нужную сторону. Примерно как ребенка направляют, когда он делает уроки, но хочется что он думал сам ("Вот тут ты о чем не подумал? А вот это изменение какой еще эффект может оказать? А что еще надо посмотреть?" и т.д.). Коненчно это заняло гораздо больше времени, чем я бы это сделал без LLM, но это был просто эксперимент.
Это показывает, что LLM, в принципе, обладает достаточным "умением" выполнить задачу, если кто-то до этого проведет грамотную декомпозицию на подзадачи. Но ведь эта декомпозиция это тоже часть решения задачи, в этом и загвоздка.
Проблема, с моей точки зрения, в том, что LLM обучаются на том "как написать", но не обучаются "почему написать именно так". Мы ведем разработку именно так, потому что это результат нашего опыта, а не потому что мы прочитали мануал. Именно этот опыт и нужен LLM, чтобы самой решать задачи без помощи - а его нет, ведь программисты не пишут мемуары "Почему я пишу данную строчку кода именно так - мои мысли и идеи".
CoT делает шаг в этом направлении, multi-agent сетапы показали неплохие результаты с подобным подходом, но это все слишком мало, это не работает "в общем", только для конкретной задачи и кодовой базы/и т.д., где ты подстелил для LLM соломку.
Поэтому я довольно скептически отношусь к идее, что разработчиков (не кодеров) внезапно заменят на LLM. Тут нужно как минимум решить концептуальную проблему "опыта" - а это значит либо тренировать модель на данных, которых нет, либо описать целиком и полностью алгоритм что нужно делать в любой ситуации и сделать это вне LLM (это кстати подход всех стартапов "AI-разработчиков" типо Devin'a) - а это тоже очень, очень сложно.
Они (по своему устройству) никогда не смогут написать код, который не повторяет что-то существующее или не является прямым продолжением оного.
Ну, это не совсем верно с практической точки зрения. Можно скормить LLM мануал, который она не видела (не обучалась на нем), и указания, и получить требуемый код. Это можно довольно легко проверить работая с вещами (технологии/библиотеки/новые версии), которые появились после knowledge cutoff.
Ограниченность скорее применима к ситуациям, когда LLM в принципе не обучалась этому классу задач и не знает как к ним подойти.
Ну это его задача - разгонять акции своей компании. Поэтому говорит он много, как и большая часть публичных людей. Под это еще и layoff'ы бесполезного персонала наверняка можно легко протолкнуть.
И даже в указанной цитате он очень осторожно говорит "Что-то типо мид-левел кодописателя" - в целом топовые LLM уже на данном уровне находятся, даже не нужно ничего изобретать (хотя наверное он конкретно про свою LLM говорит, а не про топовые)
Это правда, изолированные куски кода отлично генерируются и уже довольно давно. Но есть очень много задач помимо указанной, которые делает программист (особенно если он отвечает не только за код)
ELO 2727 ставит o3 в число 200 лучших программистов в мире. Если вы ещё не беспокоитесь о своей работе как разработчика, то пора начать это делать
Как показывает практика - решение небольшого набора псевдо-олимпиадных задачек в тепличных условиях не слишком много общего имеет с работой программиста (не кодера). Только недавно Девина разоблачали и вот опять.
А она была? Я думал она исчезла в тот момент, когда телегу сначала блокировали в РФ, а потом резко перестали, и всякие гос чиновники резко вернулись в нее обратно.
Я уверен, что "домашний реактор" всегда будет проигрывать по стоимости энергии нормальным стационарным решениям, об этом я и написал в посте выше. Поэтому никаких предпосылок для адаптации "бытовых реакторов" не видно - дешевле просто покупать энергию у сетей, которые построят "большой" и выбросят в электросеть.
Ну, конечно, кроме случаев, когда экономически выгоднее свой личный источник (удаленная география), но тут уж я даже не знаю, дешевле наверное будет газовый баллон возить или камаз дров, чем ядерную батарейку
Прослеживается четкая тенденция к децентрализации экономики
Что это вообще значит? Можете привести какие-то примеры?
Тенденции к деглобализации я вижу, но они никаким боком не относятся к "ядерному реактору в каждый дом".
Наоборот, есть вполне четкие соотношения между свойствами устройств генерации. Эффективность, компактность, безопасность, долговечность, и т.д. - нельзя сделать все сразу, что-то будет страдать. Если получится сделать 10-летнюю безопасную ядерную батарейку, значит сздоровый стационарный реактор за городом будет в 100 раз мощнее и энергия с него будет в 10 раз дешевле.
Ее и производят в том числе и атомными реакторами, только для этого не нужно тащить "реактор в каждый дом". Есть много проблем, которые можно и нужно решать, но "компактные бытовые ядерные батарейки для массвого использования" - не одна из них.
Очень сомневаюсь что это будет в таком виде. Раздавать радиоактивные элементы направо и налево - самый быстрый шаг к катастрофе. Какой-нибудь дурак кинет по приколу подобную штуку в костер посреди города, и что дальше будет?
Прогресс идет в направлении электроэнергии, как основного и единственноого топлива. И этому есть хорошая причина - это прекрасно ложится на существущую инфраструктуру, позволяя при этом обеспесчивать контроль и безопасность
К задаче про два потока: как-то не элегантно с этим numberTurn. Я особо не думал, но первая мысль была сделать два лока (по одному на поток) - ждать свой и будить чужой.
Что, думаете будет хуже, чем сейчас? Я вот сомневаюсь, если честно
Я думаю это верно относительно конкретного упомянутого примера. Он не подходит, если сигмами считать гиков и нердов.
Можно было бы хотя бы прочитать после автоперевода. Местами совсем уж кринж.
Интересно, чем автора не устроил log4js, стабильная известная библиотека с теми же фичами и 4 миллионами инсталлов в неделю
>то теперь очевидно: будущее технологий лежит в разработке более эффективных алгоритмов, а не в безграничном наращивании вычислительных мощностей. Это открывает новые перспективы для конкурентов и ставит под сомнение долгосрочные прогнозы NVIDIA.
Будущее лежит и там и там. Это и так было очевидно всем, кто следит за новостями в сфере GenAI. Новые алгоритмы появлялись все это время и куча моделей (в том числе от небольших компаний) догоняли топовые модели. Что до железа - без него никак, так или иначе это ещё один способ скейлинга.
Если человеку настолько НАДО выучить язык, что он берется за самостоятельное обучение, то логично ожидать бОльшую вероятность успеха, чем у тех, кому просто "надо" (по типу заставили в школе или дают бесплатные курсы на работе). Банальный вопрос мотивации.
Я живу в Сербии уже почти 3 года. Именно говорит по-английски тут в основном молодежь. Люди среднего возраста (30-50 лет) либо не знаю совсем, либо знают на уровне базовой школьной программы РФ. Причем доходило до абсурда, когда в центральном городском бизнес-отделении банка никто не говорит на английском вообще.
Во-первых, не символов, а токенов (это немного другое)
Во-вторых, уже довольно давно это 128000 токенов
В-третьих, есть модели и с большим context size. (Google Gemini Pro - 2 миллиона токенов)
Но обычно используется RAG (или его модификации), поэтому нет нужды запихивать все целиком
Мы проводили эксперименты с запихиванием умеренного проекта в контекст целиком - в целом это работает, но нужно очень четко ставить задачу, чтобы LLM не потерялась в контекесте. Ну и цена не маленькая.
Мы обсуждали не "проще", а возможности LLM.
Задачи с нечеткой постановкой в принципе штука спорная. Вам и человек не факт что решит ее так, как надо вам, чего уж говорить про LLM. И, кстати, приведенный Вами пример вполне себе решается LLM, если сформулировать задачу не как указание к действию, а спросить про альтернативные решения.
Я не являюсь большим фанатом LLM, но нужно трезво смотреть на вещи. LLM принципиально могут решать даже тяжелые инженерные задачи, если решить вопрос с "мышлением программиста".
Я как-то проводил эксперимент - взял одну задачу на работе (простенькую, немного подебажить и поправить несколько десяток строк кода в нескольких файлах) и полностью решил ее с помощью LLM, выступая в роли интерфейса (запустить команды/скопировать файлы/внести изменения/и т.д.) и задавая вопросы, которые в критических местах "подталкивали" LLM в нужную сторону. Примерно как ребенка направляют, когда он делает уроки, но хочется что он думал сам ("Вот тут ты о чем не подумал? А вот это изменение какой еще эффект может оказать? А что еще надо посмотреть?" и т.д.). Коненчно это заняло гораздо больше времени, чем я бы это сделал без LLM, но это был просто эксперимент.
Это показывает, что LLM, в принципе, обладает достаточным "умением" выполнить задачу, если кто-то до этого проведет грамотную декомпозицию на подзадачи. Но ведь эта декомпозиция это тоже часть решения задачи, в этом и загвоздка.
Проблема, с моей точки зрения, в том, что LLM обучаются на том "как написать", но не обучаются "почему написать именно так". Мы ведем разработку именно так, потому что это результат нашего опыта, а не потому что мы прочитали мануал. Именно этот опыт и нужен LLM, чтобы самой решать задачи без помощи - а его нет, ведь программисты не пишут мемуары "Почему я пишу данную строчку кода именно так - мои мысли и идеи".
CoT делает шаг в этом направлении, multi-agent сетапы показали неплохие результаты с подобным подходом, но это все слишком мало, это не работает "в общем", только для конкретной задачи и кодовой базы/и т.д., где ты подстелил для LLM соломку.
Поэтому я довольно скептически отношусь к идее, что разработчиков (не кодеров) внезапно заменят на LLM. Тут нужно как минимум решить концептуальную проблему "опыта" - а это значит либо тренировать модель на данных, которых нет, либо описать целиком и полностью алгоритм что нужно делать в любой ситуации и сделать это вне LLM (это кстати подход всех стартапов "AI-разработчиков" типо Devin'a) - а это тоже очень, очень сложно.
Ну, это не совсем верно с практической точки зрения. Можно скормить LLM мануал, который она не видела (не обучалась на нем), и указания, и получить требуемый код. Это можно довольно легко проверить работая с вещами (технологии/библиотеки/новые версии), которые появились после knowledge cutoff.
Ограниченность скорее применима к ситуациям, когда LLM в принципе не обучалась этому классу задач и не знает как к ним подойти.
Зачем изобретать отдельный язык для LLM? Вся сила LLM как раз в natural language processing.
Ну это его задача - разгонять акции своей компании. Поэтому говорит он много, как и большая часть публичных людей. Под это еще и layoff'ы бесполезного персонала наверняка можно легко протолкнуть.
И даже в указанной цитате он очень осторожно говорит "Что-то типо мид-левел кодописателя" - в целом топовые LLM уже на данном уровне находятся, даже не нужно ничего изобретать (хотя наверное он конкретно про свою LLM говорит, а не про топовые)
Это правда, изолированные куски кода отлично генерируются и уже довольно давно. Но есть очень много задач помимо указанной, которые делает программист (особенно если он отвечает не только за код)
Как показывает практика - решение небольшого набора псевдо-олимпиадных задачек в тепличных условиях не слишком много общего имеет с работой программиста (не кодера). Только недавно Девина разоблачали и вот опять.
Желаю им удачи
А она была? Я думал она исчезла в тот момент, когда телегу сначала блокировали в РФ, а потом резко перестали, и всякие гос чиновники резко вернулись в нее обратно.
Я уверен, что "домашний реактор" всегда будет проигрывать по стоимости энергии нормальным стационарным решениям, об этом я и написал в посте выше. Поэтому никаких предпосылок для адаптации "бытовых реакторов" не видно - дешевле просто покупать энергию у сетей, которые построят "большой" и выбросят в электросеть.
Ну, конечно, кроме случаев, когда экономически выгоднее свой личный источник (удаленная география), но тут уж я даже не знаю, дешевле наверное будет газовый баллон возить или камаз дров, чем ядерную батарейку
Что это вообще значит? Можете привести какие-то примеры?
Тенденции к деглобализации я вижу, но они никаким боком не относятся к "ядерному реактору в каждый дом".
Наоборот, есть вполне четкие соотношения между свойствами устройств генерации. Эффективность, компактность, безопасность, долговечность, и т.д. - нельзя сделать все сразу, что-то будет страдать. Если получится сделать 10-летнюю безопасную ядерную батарейку, значит сздоровый стационарный реактор за городом будет в 100 раз мощнее и энергия с него будет в 10 раз дешевле.
Ее и производят в том числе и атомными реакторами, только для этого не нужно тащить "реактор в каждый дом". Есть много проблем, которые можно и нужно решать, но "компактные бытовые ядерные батарейки для массвого использования" - не одна из них.
Очень сомневаюсь что это будет в таком виде. Раздавать радиоактивные элементы направо и налево - самый быстрый шаг к катастрофе. Какой-нибудь дурак кинет по приколу подобную штуку в костер посреди города, и что дальше будет?
Прогресс идет в направлении электроэнергии, как основного и единственноого топлива. И этому есть хорошая причина - это прекрасно ложится на существущую инфраструктуру, позволяя при этом обеспесчивать контроль и безопасность