По 1-ой ссылке - "Результаты Anthropic и Google подчёркивают прогресс в понимании работы ИИ, но также напоминают о сложности прямых аналогий с человеческим мышлением. В то время как Claude демонстрирует элементы планирования и абстрактных концептов, её «рассуждения» остаются продуктом многослойных математических операций, а НЕ сознательного анализа. Эти работы открывают путь к более прозрачным и контролируемым системам, но также ставят новые вопросы о природе «интеллекта» в машинном обучении".
Поэтому пока корректнее оперировать терминами "человеческий интеллект" и "машинный интеллект" и не пытаться их обобщать.
Добро, на словах ставим тчк. Проверить алгоритм формирования LLM-моделью выходного контента можно только через log-журнал внутренней трассировки его выполнения для заданного на входе запроса (промта).
То есть как начинается анализ текста запроса, как формируется план его обработки и пошаговый цикл формирования выходной информации. Чем оперирует LLM-модель? Извлекает ли смысл из текста, то есть какие понятия (объекты материального мира) в нем присутствуют, по их связям и отношениям в базе знаний строит логические заключения и по ним формирует выходной контент. Если ДА, то это интеллект. Если идёт просто механическая обработка текста как данных, поиск (подбор) в базе подходящего ответа или по обученному "за этим должно следовать это", то это настроенный автомат формирования ответа.
Понимать смысл - значит осознавать суть, содержание и назначение воспроизводимой информации, осознавать и использовать причинно-следственные связи для её формирования.
Фундаментальный вопрос: понимают ли модели LLM смысл того, что сами выдают ? Ответ - нет. Соответственно очевиден и ответ на другой вопрос: могут ли они вести осмысленные понятийные и логические рассуждения. А от этого уже потом рассматривать и все остальное.
Для 2, 4 случаев и ниже для игр ничего сказать не могу, тк этим не занимался. Для 1-ого случая при сложном алгоритме для надежности кода программной единицы (функции, модуля) желательно сразу на входе делать проверку корректности значений входных параметров для которых будет работать этот алгоритм и выдавать сообщение вызывающей единице с записью в системный errors.log. То есть "на берегу" исключать появление run-time error. Дальше все зависит от самого алгоритма и правильности его представления на ЯП. Из классики надёжного программирования рекомендуется размер процедур и функций ограничивать не более 50-100 строками ЯП. Для 3-его применения в системном программировании (при разработке компиляторов, интерпретаторов, СУБД) описанные Вами приёмы оправданы, самому приходилось складывать в байтовую память а затем извлекать из неё наборы разнотипных данных. Но, согласитесь, такие потребности возникают "не каждый день". Все задачи прикладного программирования, для обеспечения надёжности и понятности программного кода, решаются стандартными возможностями ЯП без всяких ухищрений.
Писать можно статью, комментарий, письмо другу и проч. Программный код разрабатывается и это инженерных труд требующих знаний и практики, как и весь процесс разработки сложного ПО, который 1в1 повторяет проектирование и разработку технического изделия. Ваши рассуждения на счёт "писания программного кода" типичны для обычного кодера, а не квалифицированного разработчика ПО.
Воспринять и разобраться в чужом программном коде (от 100 строк ЯП), неважно кем он создан (автогенератором или человеком), намного сложнее чем разработать его самому и не каждый программист сделает эту работу квалифицированно. Тут требуется прежде всего большой практический опыт программирования. Логику сырого кода для поддержки нужно документировать, дорабатывать на уровне программных единиц (процедур, функций), например, вставлять проверку на корректность вх.параметров, делать в разных местах обработку исключений во избежании run-time ошибок и записи их системный error.log и др, чего никакой самый умный автогенераторов за вас НЕ сделает. Так что если подсчитать по времени, то процесс разработки короче уж точно не будет чем тот, который уже проверен временем и своей практикой. Для справочной информации используйте свои наработанные практикой знания или учитесь, например, открывайте книги Кнута и др. гуру программирования. Главная проблема при постоянном использовании готовых "ИИ рецептов" это постепенное снижение способности самостоятельно мыслить и принимать решения.
Точнее до настроят. При обучении, если корректно применять этот термин, обучаемый логически рассуждает и понимает смысл того чему обучается. У модели LLM при "обучении" понятийные рассуждения отсутствуют (другая алгоритмика) и, следовательно, смысла из обучаемого материала она не извлекает. А раз не понимает смысла, то сама и не знает как сделать лучше. Надо снова до настраивать и так далее без конца.
Вся изложенная автором технология (и ей подобные) рассчитана исключительно на нежелающих и неумеющих думать, так и на думающих, с целью постепенного атрофирования у них способности самостоятельного мышления и принятия решений.
Вообще-то для профессионала (не путать с кодером! ) НЕТ такого понятия как "писать код". Есть понятие "разрабатывать программный код". Писать можно письмо, статью, комментарий или даже ниписать книгу. Давно (полвека уж точно) у профессионалов сложилась аналогия 1в1 проектирования и разработки ПО как сложного технического изделия. Все стадии разработки и жизненные циклы повторяются 1в1. Разработка кода программой единицы (процедуры, функции) соотносится с изготовлением рабочим конкретной детали по разработанному технологом технологическому процессу. Автогенератор выдаёт программный код. Он может быть верным, а может и содержать ошибки. Это может определить только его тщательное тестирование и время эксплуатации. Есть один нюанс, который отличает программный код от детали. Даже если он прошёл успешное тестирование, все равно требуется его верификация и документирование алгоритма его работы для будущей возможной модификации или нахождения вдруг возникшей ошибки. Разобраться в чужом программном коде из более чем 100 строк ЯП далеко не тривильная задача, тут прежде всего требуется большой практический опыт программирования и не КАЖДЫЙ эту работу сможет выполнить профессионально. А главное тоже требуется время. Если вы используете автогенераторы для своих личных целей никто вас не отговаривает делать это. Как говорится, бог в помощь. Если же разрабатывается серьёзное ПО с десятками и сотнями тысяч строк на ЯП, то тут "на арапа" с автогенератором проскочить будет не так просто. Допустим, что он вам все "сгенерит" в несколько раз быстрее, чем бы разрабатывалось вручную. Собрали, прогнали, вроде все работает, Ок. Через некоторое время (скажем через полгода) выплывают ошибки (без них не бывает даже у автогенераторов), как их будете искать и устранять если у вас на руках от вайб-кодера на память остались лишь задания-промпты для автогенератора? Это конечно при условии, что верификации и документировании не было. Найти ошибку в недокументированном программном коде и/или его модифицировать будет не так просто. Повторяю, что эту работу НЕ каждый сможет выполнить качественно. Без верификации и без доработки под свои стандарты ни одна ответственная ИТ компания сгенерированный программный код использовать не будет. Поэтому довод в пользу резкого сокращения общего времени разработки ПО при "написания кода" автогенератором сомнителен. Да, "сгенерится" все быстро, но сколько времени и какой квалификации потребуется чтобы во всем этом разобраться и довести до ума.
Вообще-то в статье и в комментах речь идёт об вайб-кодинге и автоматизации генерации программного кода с помощью современных ИИ-технологий. А на счёт того что "юристы, бухгалтерия, аналитики, инженеры.. и т.д." скоро "на выход", так эти фантазии лучше оставьте при себе.
Сегодня нахваливают Python, а завтра с уже удвоенной энергией Alligator.
Как это нет ? То есть вы не понимаете как сами строите свои рассуждения, даёте обьяснения и делаете выводы ? Вот это интересная новость !
А LLM, правильно говорите, генерирует свои "размышления", только НЕ так, как это делает человек.
Так как не сойдёмся, то на этом можно поставить в нашей дискуссии точку.
По 1-ой ссылке - "Результаты Anthropic и Google подчёркивают прогресс в понимании работы ИИ, но также напоминают о сложности прямых аналогий с человеческим мышлением. В то время как Claude демонстрирует элементы планирования и абстрактных концептов, её «рассуждения» остаются продуктом многослойных математических операций, а НЕ сознательного анализа. Эти работы открывают путь к более прозрачным и контролируемым системам, но также ставят новые вопросы о природе «интеллекта» в машинном обучении".
Поэтому пока корректнее оперировать терминами "человеческий интеллект" и "машинный интеллект" и не пытаться их обобщать.
Короче, нужна внутренняя трассировка обработки конкретного запроса, а потом и поговорим.Лучше такого, ответ на который (как вы говорите) нет в базе.
Добро, на словах ставим тчк. Проверить алгоритм формирования LLM-моделью выходного контента можно только через log-журнал внутренней трассировки его выполнения для заданного на входе запроса (промта).
То есть как начинается анализ текста запроса, как формируется план его обработки и пошаговый цикл формирования выходной информации. Чем оперирует LLM-модель? Извлекает ли смысл из текста, то есть какие понятия (объекты материального мира) в нем присутствуют, по их связям и отношениям в базе знаний строит логические заключения и по ним формирует выходной контент. Если ДА, то это интеллект. Если идёт просто механическая обработка текста как данных, поиск (подбор) в базе подходящего ответа или по обученному "за этим должно следовать это", то это настроенный автомат формирования ответа.
Забалтывание. Смотри толковый словарь русского языка.
Понимать смысл - значит осознавать суть, содержание и назначение воспроизводимой информации, осознавать и использовать причинно-следственные связи для её формирования.
Большая. Если не понимают, то нет и интеллекта, а только настроенный на предсказания автомат. Гадалок тоже многие любят слушать.
Они НЕ понимают смысл того что выдают, а от этого надо смотреть и на все остальное.
Фундаментальный вопрос: понимают ли модели LLM смысл того, что сами выдают ? Ответ - нет. Соответственно очевиден и ответ на другой вопрос: могут ли они вести осмысленные понятийные и логические рассуждения. А от этого уже потом рассматривать и все остальное.
"Чем проще тем надёжнее. " - Н. Вирт.
Для 2, 4 случаев и ниже для игр ничего сказать не могу, тк этим не занимался. Для 1-ого случая при сложном алгоритме для надежности кода программной единицы (функции, модуля) желательно сразу на входе делать проверку корректности значений входных параметров для которых будет работать этот алгоритм и выдавать сообщение вызывающей единице с записью в системный errors.log. То есть "на берегу" исключать появление run-time error. Дальше все зависит от самого алгоритма и правильности его представления на ЯП. Из классики надёжного программирования рекомендуется размер процедур и функций ограничивать не более 50-100 строками ЯП. Для 3-его применения в системном программировании (при разработке компиляторов, интерпретаторов, СУБД) описанные Вами приёмы оправданы, самому приходилось складывать в байтовую память а затем извлекать из неё наборы разнотипных данных. Но, согласитесь, такие потребности возникают "не каждый день". Все задачи прикладного программирования, для обеспечения надёжности и понятности программного кода, решаются стандартными возможностями ЯП без всяких ухищрений.
Интересно узнать, для решения каких предметных задач строится такой сложный "огород" ?
Писать можно статью, комментарий, письмо другу и проч. Программный код разрабатывается и это инженерных труд требующих знаний и практики, как и весь процесс разработки сложного ПО, который 1в1 повторяет проектирование и разработку технического изделия. Ваши рассуждения на счёт "писания программного кода" типичны для обычного кодера, а не квалифицированного разработчика ПО.
Воспринять и разобраться в чужом программном коде (от 100 строк ЯП), неважно кем он создан (автогенератором или человеком), намного сложнее чем разработать его самому и не каждый программист сделает эту работу квалифицированно. Тут требуется прежде всего большой практический опыт программирования. Логику сырого кода для поддержки нужно документировать, дорабатывать на уровне программных единиц (процедур, функций), например, вставлять проверку на корректность вх.параметров, делать в разных местах обработку исключений во избежании run-time ошибок и записи их системный error.log и др, чего никакой самый умный автогенераторов за вас НЕ сделает. Так что если подсчитать по времени, то процесс разработки короче уж точно не будет чем тот, который уже проверен временем и своей практикой. Для справочной информации используйте свои наработанные практикой знания или учитесь, например, открывайте книги Кнута и др. гуру программирования. Главная проблема при постоянном использовании готовых "ИИ рецептов" это постепенное снижение способности самостоятельно мыслить и принимать решения.
Точнее до настроят. При обучении, если корректно применять этот термин, обучаемый логически рассуждает и понимает смысл того чему обучается. У модели LLM при "обучении" понятийные рассуждения отсутствуют (другая алгоритмика) и, следовательно, смысла из обучаемого материала она не извлекает. А раз не понимает смысла, то сама и не знает как сделать лучше. Надо снова до настраивать и так далее без конца.
Если понимают их смысл.
Вся изложенная автором технология (и ей подобные) рассчитана исключительно на нежелающих и неумеющих думать, так и на думающих, с целью постепенного атрофирования у них способности самостоятельного мышления и принятия решений.
Вообще-то для профессионала (не путать с кодером! ) НЕТ такого понятия как "писать код". Есть понятие "разрабатывать программный код". Писать можно письмо, статью, комментарий или даже ниписать книгу. Давно (полвека уж точно) у профессионалов сложилась аналогия 1в1 проектирования и разработки ПО как сложного технического изделия. Все стадии разработки и жизненные циклы повторяются 1в1. Разработка кода программой единицы (процедуры, функции) соотносится с изготовлением рабочим конкретной детали по разработанному технологом технологическому процессу. Автогенератор выдаёт программный код. Он может быть верным, а может и содержать ошибки. Это может определить только его тщательное тестирование и время эксплуатации. Есть один нюанс, который отличает программный код от детали. Даже если он прошёл успешное тестирование, все равно требуется его верификация и документирование алгоритма его работы для будущей возможной модификации или нахождения вдруг возникшей ошибки. Разобраться в чужом программном коде из более чем 100 строк ЯП далеко не тривильная задача, тут прежде всего требуется большой практический опыт программирования и не КАЖДЫЙ эту работу сможет выполнить профессионально. А главное тоже требуется время. Если вы используете автогенераторы для своих личных целей никто вас не отговаривает делать это. Как говорится, бог в помощь. Если же разрабатывается серьёзное ПО с десятками и сотнями тысяч строк на ЯП, то тут "на арапа" с автогенератором проскочить будет не так просто. Допустим, что он вам все "сгенерит" в несколько раз быстрее, чем бы разрабатывалось вручную. Собрали, прогнали, вроде все работает, Ок. Через некоторое время (скажем через полгода) выплывают ошибки (без них не бывает даже у автогенераторов), как их будете искать и устранять если у вас на руках от вайб-кодера на память остались лишь задания-промпты для автогенератора? Это конечно при условии, что верификации и документировании не было. Найти ошибку в недокументированном программном коде и/или его модифицировать будет не так просто. Повторяю, что эту работу НЕ каждый сможет выполнить качественно. Без верификации и без доработки под свои стандарты ни одна ответственная ИТ компания сгенерированный программный код использовать не будет. Поэтому довод в пользу резкого сокращения общего времени разработки ПО при "написания кода" автогенератором сомнителен. Да, "сгенерится" все быстро, но сколько времени и какой квалификации потребуется чтобы во всем этом разобраться и довести до ума.
Вообще-то в статье и в комментах речь идёт об вайб-кодинге и автоматизации генерации программного кода с помощью современных ИИ-технологий. А на счёт того что "юристы, бухгалтерия, аналитики, инженеры.. и т.д." скоро "на выход", так эти фантазии лучше оставьте при себе.