Здравствуйте, mrTwister, Вы писали:
T>При условии, что LLM "знает", как преобразовывать инструкции из статьи в код. Твой пример скорее идентичен преобразованию программы с одного языка программирования в другой, то что на входе псевдокод с текстовым описанием сути не меняет. Это LLM конечно умеют. А вот такую статью с новым алгоритмом она уже придумать не сможет (но сможет скомпоновать несколько существующих алгоритмов).
Сейчас идут опыты с тем, чтобы LLM смогли решать ранее нерешенные задачи. Успехи есть, хотя пока и не впечатляющие.
T>AlfaGo не имеет ничего общего с современными LLM. После обучения для LLM делают скорее файн-тюнинг, в результате которого новые знания и умения не появляются. Знания и умения берутся только из обучающего датасета.
Я знаю, что архитектурно LLM и AlfaGo имеют мало общего (но кстати что-то имеют), я про сам подход, в том числе опять же есть опыты с агентским самообучением моделей. То есть, когда LLM действует во внешней среде (от роботов до просто запуска компилятора) и происходит RL (Reinforcement Learning, самообучение с подкреплением). Пока тут нащупывают оптимальные архитектуры (и кстати трансформеры на которых llm далеки от идеала), но работы идут.
В конце-концов, вспомни совсем недавнее прошлое. Еще совсем недавно (лет 5 назад) люди тащились от того, что LLM могла вообще генерировать связный текст и даже немного в тему промпта. Сильно галлюцинируя при этом. Ни о каком поиске алгоритмов, реализации их по описаниям и тп. речи даже не было. Сейчас уже всерьез обсуждаем пределы возможностей в этом.
Здравствуйте, hi_octane, Вы писали:
_>Современные общедоступные LLM ближе к AlphaGo — они обучаются на человечьих датасетах. И они пытаются шаг за шагом превратиться в AlphaZero. В тех утечках, которые обсуждаются сейчас, и которые выкатят в 2026-м, после начального обучения на датасете, идёт состязательное обучение. Нейросеть-решала читает задачу и пишет решение, а нейросеть-критик решение оценивает (в том числе пишет тесты, которые решение ломают). И обе сети обучаются и растут параллельно. Оно уже создаёт куски кода (пока небольшие), лучшие чем всё человеческое. И, что для контор с гигантскими датацентрами важнее всего, у такого процесса пока не нашли точки выхода на плато.
Имхо, это только очень узкий класс задач, типа литкод задач по программированию, которые хорошо формализуются и по которым можно снять метрики качества решения. Именно поэтому LLMки в олимпиадных задачах по программированию сейчас делают колоссальные успехи, при этом часто лажая в значительно более простых будничных програмистских задачах. Сеть-критик не может оценить качество решения несформулированной задачи.
Здравствуйте, Michael7, Вы писали:
M>Сейчас идут опыты с тем, чтобы LLM смогли решать ранее нерешенные задачи. Успехи есть, хотя пока и не впечатляющие.
Я думал сейчас все ограничивается циклическим подходом условно "составь план, выполни первый пункт плана, оцени выполнение, скорректируй план и т.д."? Это все хорошо и позволяет решать многие задачи, но у этого подхода есть граница применимости, которую пока мне не понятно, как преодолеют.
M>В конце-концов, вспомни совсем недавнее прошлое. Еще совсем недавно (лет 5 назад) люди тащились от того, что LLM могла вообще генерировать связный текст и даже немного в тему промпта. Сильно галлюцинируя при этом. Ни о каком поиске алгоритмов, реализации их по описаниям и тп. речи даже не было. Сейчас уже всерьез обсуждаем пределы возможностей в этом.
Ну вот у меня ощущение, что вышли на плато с которого без нового прорыва не вырваться
T>Имхо, это только очень узкий класс задач, типа литкод задач по программированию, которые хорошо формализуются и по которым можно снять метрики качества решения. Именно поэтому LLMки в олимпиадных задачах по программированию сейчас делают колоссальные успехи, при этом часто лажая в значительно более простых будничных програмистских задачах. Сеть-критик не может оценить качество решения несформулированной задачи.
Ну в этом случае обе сети и решала и критик должны обнаружить неопределённости и задать уточняющие вопросы. И в этом направлении нейросети тоже обучают, и модели потихоньку учатся и этому. Топовые платные и бесплатные точно задают уточняющие вопросы, я сам видел.
Здравствуйте, Miroff, Вы писали:
SD>>А вы пробовали внедрять все эти инструменты от Rational? Я вот пробовал. И Rose, и даже (свят-свят) ClearCase. Как вспомню, так вздрогну. И ведь не то чтоб идеи плохие были, или продукты. M>Я тоже пробовал. Если применять как задумано, когда архитектор с аналитиком совместно рисуют диаграммы, а потом из этих диаграмм генерируются стабы и отдаются на имплементацию кодеру, то получается довольно эффективно.
Вопрос не "как задумано", а "кем задумано". И какую именно проблему эти "продукты" решали? Что тупой кодер не мог написать стаб класса?
M>Проблемы в внедрением случаются когда кодер считает себя умным и вместо того чтобы кодировать что сказано лезет в архитектуру.
Когда "кодер" видит, что пока вы там мышевозюкаете, он все это ручками может не просто "описать", а реализовать в коде, покрыть тестами и даже погонять на железе, то проблемы вовсе не в бобине.
M>В результате диаграммы быстро перестают отражать реальность. Но я как-то работал в команде, где было физически запрещено менять архитектуру в коде, только через диаграммы и кодогенерацию. И, в общем, это даже работало не смотря на то, что к моему приходу эту технологию уже лет 10 забили развивать и от нее остались ER диаграммы.
Я тоже работал в команде, где использовался ClearCase. И вроде бы даже "успешно" работали. Ну да, бывают такие люди — садомазохисты.
SD>>Просто решали они совсем не ту задачу, которую нужно было. M>А какую проблему, на твой взгляд, нужно было решать?
Какую-нибудь другую, не высосанную из пальца.
M>Программисты в массе даже сейчас не умеют в архитектуру,
Настало время офигительных историй (с).
M>а тогда и подавно не умели.
Зато архитекторы вот прямо так сразу умели, что могли архитектуру такую нарисовать, что хоть сразу в продакшен!
P.S. Единственное, для чего эти, с позволения сказать, "продукты", были изначально предназначены — это откаты и распилы.
Здравствуйте, TG, Вы писали:
TG>Что это за троллинг такой, когда доцент говорит явные глупости?
К доценту, специализирющемся на AI, пришел вот такой вот журналист.
Пишу про Петербург и петербуржцев, отвечаю в «Фонтанке» за школы города и историю. Окончил бакалавриат и магистратуру истфака СПбГУ, бросил аспирантуру и стал профессиональным журналистом. Сейчас вернулся к диссертации.
Ну как его не протроллить сказами про зажравшихся программистов, которых вот-вот на место поставит великий АЙ. Вон, смотри, он даже похудеть помогает!
Есть, конечно, вариант, что доцент это на чистом глазу говорит. Но это значит, что ИТМО — RIP.
M>Я тоже пробовал. Если применять как задумано, когда архитектор с аналитиком совместно рисуют диаграммы, а потом из этих диаграмм генерируются стабы и отдаются на имплементацию кодеру, то получается довольно эффективно.
Это называется "friction by design", и совершенно неважно, каким именно образом создается оный friction.
M>А какую проблему, на твой взгляд, нужно было решать? Программисты в массе даже сейчас не умеют в архитектуру, а тогда и подавно не умели.
Какую проблему — зависело от конкретной конторы. Во времена rational rose (для меня это был примерно 2003-2005) в большинстве контор не умели даже банальный source control, не говоря уже про tests и прочие CI. Внедрение этих "прорывных технологий" и нужно было решать. А не писать код диаграммами.
N> Вообще, будет ли так, что программа — это промт + граничные условия, а тело программы на выбранном ЯП нейроннка каждый раз переписывает заново.
"Граничные условия" называются "тесты". А так-то процесс примерно такой и есть — в развитых больших системах тестами и failsafe'ами обложено по возможности все. В этом как раз и идея, чтобы можно было нанимать дешевых работников, которые методом написания "Войны и мир" обезьянами будут решать определенные задачи. Замена этих дешевых работников на нейросети уже происходит.
T>Я думал сейчас все ограничивается циклическим подходом условно "составь план, выполни первый пункт плана, оцени выполнение, скорректируй план и т.д."? Это все хорошо и позволяет решать многие задачи, но у этого подхода есть граница применимости, которую пока мне не понятно, как преодолеют.
Нет, все несколько иначе.
Я бы скорее привел в качестве аналогии property-based testing (упрощенная вариация которого называется fuzzying). Нейросеть генерирует некоторое рандомное (*) изменение (примерно как "мутация" в наших генах генерируется ионизирующим излучением), а другая нейросеть (или просто набор тестов) проверяют полученный вариант на то, лучше ли он предыдущего, или хуже.
(*) на самом деле, не совсем рандомное, но это уже детали
Здравствуйте, SkyDance, Вы писали:
SD>...в развитых больших системах тестами и failsafe'ами обложено по возможности все. В этом как раз и идея, чтобы можно было нанимать дешевых работников, которые методом написания "Войны и мир" обезьянами будут решать определенные задачи.
Идея там совсем не в этом. Основная идея тестов в том, что ты всегда можешь быть уверен, что всё работает так, как задумано, что ты, выполнив свою задачу, не разломал 10 других, и что ты не сломал один из необходимых инвариантов. И это ппц как выручает иногда!
Без тестов бывает так, что ошибку внесли полгода назад и до определённого момента её никто не замечал, а потом она вылазит при релизе совершенно иной фичи — искать суть проблемы ты потом будешь до посинениня.
Тесты помогают разобраться в существующем коде: они шаг за шагом описывают ньюнасы поведения системы, без необходимости погружения в детали реализации.
Наличие и качество тестов — это показатель профессионализма, а не наоборот.
Всё сказанное выше — личное мнение, если не указано обратное.
SD>>...в развитых больших системах тестами и failsafe'ами обложено по возможности все. В этом как раз и идея, чтобы можно было нанимать дешевых работников, которые методом написания "Войны и мир" обезьянами будут решать определенные задачи.
Ф>Идея там совсем не в этом. <...> Ф>Наличие и качество тестов — это показатель профессионализма, а не наоборот.
Может, это я написал непонятно, а может, кто-то меня неправильно понял. Но я именно про это и писал: устойчивая ("показатель профессионализма") система обложена тестами по самое не могу, поэтому можно загнать на работу над этой системой довольно-таки малоопытных людей. И они ничего не сломают.
Теперь этих малоопытных людей можно заменять на нейросети.
Здравствуйте, SkyDance, Вы писали:
SD>Может, это я написал непонятно, а может, кто-то меня неправильно понял. Но я именно про это и писал: устойчивая ("показатель профессионализма") система обложена тестами по самое не могу, поэтому можно загнать на работу над этой системой довольно-таки малоопытных людей. И они ничего не сломают.
Да, не сломают. Просто отключат тесты, которые "сами поломались"
Здравствуйте, SkyDance, Вы писали:
SD>Это называется "friction by design", и совершенно неважно, каким именно образом создается оный friction.
В первую очередь это называется проектированием сверху вниз. И это до сих пор единственный рабочий способ построить сложную систему не закопавшись в внутренних противоречиях. Да, при этом создаются некоторые тормоза, но эти тормоза плата за концептуальную целостность.
Здравствуйте, landerhigh, Вы писали:
L>Вопрос не "как задумано", а "кем задумано". И какую именно проблему эти "продукты" решали? Что тупой кодер не мог написать стаб класса?
Задумано разработчиком инструмента, очевидно. Задумано для того чтобы упросить проектирование очень сложных систем. В том проекте, где я работал, одних экранных форм было 1.5 тысячи, а классов порядка 10 тысяч и все это обеспечивала команда всего человек в 15 не считая контракторов. Современный проект с аджайлом аналогичного объема будет занимать порядка 100 микросервисов и требовать команды в полтысчи человек. Естественно, кодер может написать и стаб класса и сам класс и даже тесты на класс. А вот чего он не может это увязать свой класс с остальной системой ничего не поломав. В результате сейчас приходится со всех сторон обкладываться интеграционными тестами, потому что высокоуровневыми инструментами индустрия пользоваться совершенно разучилась.
Здравствуйте, mgu, Вы писали:
mgu>Пока во всей этой вакханалии я не понимаю, на какие шиши безработные "кожаные мешки" будут покупать произведённую роботами продукцию.
Нинакакие и не будут. Более того большая часть этой продукции будет отправляться прямиком на переработку лома и на свалки.
Здравствуйте, Pzz, Вы писали:
Pzz>P.S. Вообще, если посмотреть на "программирование на промптах" как на программирование на очень высокоуровневом языке, при использовании которого человек, фактически, описывает архитектуру, а машина "додумывает" детали — может в эту сторону и стоит развиваться?
Машине не хватает контекста. У человека контекст формируется всю его жизнь.
Здравствуйте, landerhigh, Вы писали:
L>То, что он являлся неправильным решением несуществующей проблемы.
Основа пути от Rational Rose мне очень нравилась. Они сломались о дураков, которые, когда молятся, лоб расшибают.
