У вас LLM как был черным ящиком, так и остался таковым тогда как оценивать качество запросов имеет смысл только при наличии возможности их повторного воспроизведения.
Используя алгебру автоматов, можно любой одиночный автомат разложить на множество параллельных автоматов по операции умножения. Вот и все. И, кстати, это тоже будет детерминированная система - сеть автоматов. Ни какого недетерминизма нет и в помине.
Это верно только для синхронизированной работе сети автоматов, но любая асинхронная операция (например ожидание ввода пользователя) приводит общее состояние подобной сети в недетерминированое состояние.
Вы сейчас путаете прерывания и исключения, а это разные концепции. Исключение в вашем пример, это по сути дела способ глобально перейти на типизированный обработчик, по сути глобальный goto на тип данных (исключения). Но он работает в одном потоке и это обычный однопоточный код реализуемый на МТ, тогда как в контексте же МТ важны аппаратные прерывания (или вытесняющая многозадачность), на которую одна МТ не способна.
Да, умные люди доказали что в она в теории может выполнять любой алгоритм, вот только при важном допущении о наличии бесконечной памяти и неограниченном времени на работу, тогда как в реальности это невозможно.
Люди, утверждающие, что МТ не имеет ничего общего с реальностью из-за каких-то исключений - встречный вопрос: вы знаете про ЯП Go/Rust? Вместо тяжёлых виртуальных таблиц прерываний они используют лёгкие и предсказуемые ветвления, с лёгкостью реализующие аналогичное поведение (можно сколько угодно спорить на тему эффективности, но к теме статьи это не относится)
Это наверно камешек в мой адрес? :-) Да, я знаю и про Go и про Rust, и знаю, что у них, как и всех языков программирования реального мира есть возможность прерывания выполнения программы в любой момент времени. Просто некоторые языки умеют обрабатывать подобные прерывания, а другие нет, но сути это не меняет, тогда как МТ принципиально не умеет обрабатывать прерывания или переключать контекст, так как она всегда строго последовательная.
голая многопоточность -- это пот, боль и кровь. Если у вас есть возможность не использовать многопоточность, то не используйте ее.
К сожалению, это не вариант. Но и отчаиваться не нужно, так как всегда остается шанс найти более или менее нормальное решение, хотя не в рамах беседы с текущим автором :-)
Мне кажется, что ошибки как раз у вас в рассуждениях.
Проблема программных ошибок - это совсем не относится к МT. Ей-то какое дело до того, что у кого-то руки растут не из того места?
Полностью с вами согласен, что если Agile не работает, то значит его неправильно внедрили, а если в программе есть ошибки, то это точно виноват программист.
Проблема в том, что подобный аргумент в любом техническом споре, это риторический прием не имеющий ни к науке, ни к техничке никакого отношения
А про обязательность наличия прерываний и их обработки? Это-то каким местом относится к МТ?
Вот в том то и дело, что никаким местом не относится, так как у МТ нет прерываний, тогда как они нужны для работы в реальном мире и на реальном железе (а не в математической абстракции)
Я реальный программиста, а не сферический в вакууме, и понимаю различия между математической теорией и реальностью, в которой отсутствует бесконечная память и неограниченное время при работе реальных алгоритмов.
должна существовать, как и в случае последовательных алгоритмов
А с чего вы решили, что для последовательнх алгоритмов это существует? Машина Тьюрига - это чистая математическая абстракция, которой не существует в реальном мире. Или речь идет о чем-то другом?
Конечно есть. Но ведь может потребоваться отменять не весь пропт, а только какую то часть, когда рассуждения LLM "завернули не туда". И тут основная проблема не отменить изменения, а определить момент поворота рассуждений в неправильном направлении.
Искренне прошу прощения за невольную обиду, так как собеседник очень настойчив в попытке насаждения своей религии, поэтому я и предположил наличие у него нескольких аккаунтов.
Но это ни в коем случае не попытка очернить вас и мне искренне жаль за сделанную ранее формулировку.
Рефакторить может потребоваться любой код, не важно был он написан вручную или сгенерирован ИИ. Более того, абстрактный начальный промпт практичеси всегда раскрывается в список конкретных этапов. Вот его можно рассматривать как ТЗ на разработку, но никак не начальный промпт.
У вас LLM как был черным ящиком, так и остался таковым тогда как оценивать качество запросов имеет смысл только при наличии возможности их повторного воспроизведения.
Так эти изменения вводят задним число уже для тех, кто купил раньше без подобных ограничений.
Это верно только для синхронизированной работе сети автоматов, но любая асинхронная операция (например ожидание ввода пользователя) приводит общее состояние подобной сети в недетерминированое состояние.
Вы сейчас путаете прерывания и исключения, а это разные концепции. Исключение в вашем пример, это по сути дела способ глобально перейти на типизированный обработчик, по сути глобальный goto на тип данных (исключения). Но он работает в одном потоке и это обычный однопоточный код реализуемый на МТ, тогда как в контексте же МТ важны аппаратные прерывания (или вытесняющая многозадачность), на которую одна МТ не способна.
Да, умные люди доказали что в она в теории может выполнять любой алгоритм, вот только при важном допущении о наличии бесконечной памяти и неограниченном времени на работу, тогда как в реальности это невозможно.
Это наверно камешек в мой адрес? :-) Да, я знаю и про Go и про Rust, и знаю, что у них, как и всех языков программирования реального мира есть возможность прерывания выполнения программы в любой момент времени. Просто некоторые языки умеют обрабатывать подобные прерывания, а другие нет, но сути это не меняет, тогда как МТ принципиально не умеет обрабатывать прерывания или переключать контекст, так как она всегда строго последовательная.
Скину в личку статью с описанием похожей проблемы, но кардинально другим решением https://peterneufeld.wordpress.com/2025/03/04/esp32-c3-supermini-antenna-modification/
Облако и приватный LLM агент для работы с конфиденциальными данными, это какой-то оксюморон :-)
Жаль что не видел этой статьи раньше. Не пришлось бы писать свою :-)
Ну да, в том числе и это. Хотя мне бы хотелось, чтобы была хоть какая нибудь защитная семантика на уровне исходного кода, которая бы предотвращая ошибки многопоточности во время компиляции :-)
К сожалению, это не вариант. Но и отчаиваться не нужно, так как всегда остается шанс найти более или менее нормальное решение, хотя не в рамах беседы с текущим автором :-)
Мне кажется, что ошибки как раз у вас в рассуждениях.
Полностью с вами согласен, что если Agile не работает, то значит его неправильно внедрили, а если в программе есть ошибки, то это точно виноват программист.
Проблема в том, что подобный аргумент в любом техническом споре, это риторический прием не имеющий ни к науке, ни к техничке никакого отношения
Вот в том то и дело, что никаким местом не относится, так как у МТ нет прерываний, тогда как они нужны для работы в реальном мире и на реальном железе (а не в математической абстракции)
Абстракции в программировании нужны для упрощения/обощения алгоритмов. Для чего нужно реализовывать "чистую математическую абстракцию"?
Тогда у меня для вас есть альтернативный вариант ссылки :-)
Я реальный программиста, а не сферический в вакууме, и понимаю различия между математической теорией и реальностью, в которой отсутствует бесконечная память и неограниченное время при работе реальных алгоритмов.
А с чего вы решили, что для последовательнх алгоритмов это существует? Машина Тьюрига - это чистая математическая абстракция, которой не существует в реальном мире.
Или речь идет о чем-то другом?
А что, Lua тоже тащат в ядро Linux?
А зачем такое усложнение с доступом к GigaCode?
Как подключить вашу модель, например к Cline?
Не вижу ничего плохого в написанном коде. Может быть вы покажете конкретное место, где же плох код, написанный ИИ?
Конечно есть. Но ведь может потребоваться отменять не весь пропт, а только какую то часть, когда рассуждения LLM "завернули не туда". И тут основная проблема не отменить изменения, а определить момент поворота рассуждений в неправильном направлении.
Искренне прошу прощения за невольную обиду, так как собеседник очень настойчив в попытке насаждения своей религии, поэтому я и предположил наличие у него нескольких аккаунтов.
Но это ни в коем случае не попытка очернить вас и мне искренне жаль за сделанную ранее формулировку.
Рефакторить может потребоваться любой код, не важно был он написан вручную или сгенерирован ИИ. Более того, абстрактный начальный промпт практичеси всегда раскрывается в список конкретных этапов. Вот его можно рассматривать как ТЗ на разработку, но никак не начальный промпт.