Здравствуйте, Alekzander, Вы писали:

A>Так ведь, "невозможно восстановить исходное значение из нуля". А тут какая-то подозрительная двойка. Надо посоветоваться с ЧатГПТ.

Речь не про исходное значение — а про сам алгоритм, его реализацию в коде — возможность понимать почему программа отработала именно так а не иначе, найти точку ошибки в программе и исправить ее.

В эпоху до-магическую — это могло быть сложным — поиск бага мог занимать несколько часов а то и дней. Но баг всегда можно было найти.

В эпоху магии мы просто имеем модель и нет способа понять откуда в ней взялась та или иная связь или коэффециент. Более того — даже создатели библиотек, таких как PyTorch или ATen — не могут сказать на что способна модель а на что не способна, какие задачи она решать сможет а какие не сможет никогда.

Здравствуйте, bnk, Вы писали:

bnk>Наше "понимание" это просто понимание работы до какого-то уровня вложенности этой системы.
bnk>Но даже сейчас при желании можно спуститься до квантовой физики например, где обычная логика вообще работает довольно слабо.

Не согласен.

Понимать нужно до того уровня, на который ты можешь влиять.

На транзисторы я влиять не могу. Поэтому интересоваться, как работает процессор на уровне транзисторов — ну разве что ради общего развития. Ниже — тем более. Пока я не работаю проектировщиком процессоров, конечно. Но я не работаю.

А вот всё, что касается машинного кода — на это я уже влиять могу. Я могу запускать на своём процессоре любой код. Поэтому и понимание нужно вплоть до последнего байта, выполняющегося на этом процессоре. Ну в идеале.

M>>Функция необратимая, выполнимая операция зависит от данных.
M>>Это уже магия или еще нет?

S>Вы можете взять входящие данные и пошагово пройтись именно с этими же данными в дебагере — и понять почему код отработал именно таким образом. Если что-то не так как вы хотели — найдете точку где именно эта проблема возникает.

Погоди, так магия это «невозможность дебага» чтоли?
И чем так не понравился термин «невозможность дебага», что решил его заменить на новый?

S>С LLM так нельзя в принципе — здесь уже нет контроля — чистая магия.

Почему там нельзя также подебажить?

Здравствуйте, Pzz, Вы писали:

S>>А вот для IT — магия была не нормой, ее не было. Она отрицалась, ее запрещали, отрицали. Магия была порицаема в IT. Все было доступно для понимания и отладки, для коррекции.

Pzz>Скажи это программистам, использующим хитрый Win32 API.

Любой хитрый API можно было дизассемблировать и посмотреть, что он делает, вплоть до ядра. И/или дизассемблировать код, использующие этот API. Для хорошего реверсера читать ассемблер не намного сложней, чем читать C. Поэтому с магией я бы это не сравнивал. Тут всегда можно разобраться.

Здравствуйте, Pzz, Вы писали:

Pzz>Если я не ошибаюсь, именно Эдсгер Дейкстра ввел в обиход организацию ввода-вывода вокруг системы прерываний, вместе с чем ушла детерминированность. Раньше этого избегали. И это, на минуточку, середина 60-х.

Тем не менее никто не пишет программы с прерываниями в юзерспейсе. Любая программа с вводом-выводом взаимодействует в чётких точках вызова API. Кстати задумался даже — почему так. Вроде бы логично было бы дать операционной системе указатели на функции и чтобы она вызывала эти функции при вводе/выводе, аналогично тому, как это происходит с сигналами... Ну не суть, по факту так не делают. Поэтому таки детерминированность не ушла для 99% программистов, её аккуратно вернули на место.

Здравствуйте, vsb, Вы писали:

vsb>А вот всё, что касается машинного кода — на это я уже влиять могу. Я могу запускать на своём процессоре любой код. Поэтому и понимание нужно вплоть до последнего байта, выполняющегося на этом процессоре. Ну в идеале.

Нейронне сети — на уровне софта. Но точно влиять не можете по ряду причин.

Здравствуйте, Muxa, Вы писали:

M>Погоди, так магия это «невозможность дебага» чтоли?
M>И чем так не понравился термин «невозможность дебага», что решил его заменить на новый?

Не только дебага — принцип другой. Нельзя отследить пошагово и установить почему модель решила повести себя именно так — какие именно данные на это повлияли.

S>>С LLM так нельзя в принципе — здесь уже нет контроля — чистая магия.
M>Почему там нельзя также подебажить?

Потому что изменился принцип — вместо последовательности команд имеет нейроны и связи между ними, вес связей. Если вы задаете вопрос (входящие данные) — то все нейроны всех слоев (или большая часть нейронов) — вносят свой небольшой вклад в ответ. Откуда взялись те или иные значения — отследить не возможно, т.к. обучение сети применяет необратимые алгоритмы.

Здравствуйте, vsb, Вы писали:

Pzz>>Скажи это программистам, использующим хитрый Win32 API.

vsb>Любой хитрый API можно было дизассемблировать и посмотреть, что он делает, вплоть до ядра. И/или дизассемблировать код, использующие этот API. Для хорошего реверсера читать ассемблер не намного сложней, чем читать C. Поэтому с магией я бы это не сравнивал. Тут всегда можно разобраться.

Но при этом подход у них, вендовых программеров, зачастую не научный, а мистически-магический.

M>>Почему там нельзя также подебажить?

S>Потому что изменился принцип — вместо последовательности команд имеет нейроны и связи между ними, вес связей.

Там нельзя брейкпоинт поставить и по шагам исполнять?

S>Если вы задаете вопрос (входящие данные) — то все нейроны всех слоев (или большая часть нейронов) — вносят свой небольшой вклад в ответ.

Звучит похоже на алгоритм discrete Fourier transform.
Наверное для тебя это тоже магия.

Здравствуйте, vsb, Вы писали:

vsb>Тем не менее никто не пишет программы с прерываниями в юзерспейсе. Любая программа с вводом-выводом взаимодействует в чётких точках вызова API. Кстати задумался даже — почему так. Вроде бы логично было бы дать операционной системе указатели на функции и чтобы она вызывала эти функции при вводе/выводе, аналогично тому, как это происходит с сигналами... Ну не суть, по факту так не делают. Поэтому таки детерминированность не ушла для 99% программистов, её аккуратно вернули на место.

Гы. На JS только так и пишут. С асинхронными калбеками. Которе немного облагородили, завернув в promises, чтобы совсем уж не свихнуться.

И во всякие более другие языки такой подход тащут.

S>Приходится выходить на новый уровень, вверять технике нового уровня управление теми или иными аспектами нашей жизни.
И сразу же уходить. После палестинских пейджеров — даже самые упёртые гейфонолюбы уже не могут ссылаться на паранойю. Вся эта техника "нового уровня" — кому надо ("корпорациям добра") вполне детерминированна. И те кто реально оценивает свои шансы в войне — будут возвращаться на электромеханику и "6 ножек 4 ручки", лишь бы всё было прослеживаемое от и до.
S>И основной вопрос — приняли ли вы уже это? Или же имеете внутреннюю неприязнь к ИИ и системам, построенным на его основе?
Всегда обходил смердфоны стороной, и теперь стало понятно почему.

Здравствуйте, Muxa, Вы писали:

S>>Потому что изменился принцип — вместо последовательности команд имеет нейроны и связи между ними, вес связей.
M>Там нельзя брейкпоинт поставить и по шагам исполнять?

С какой целью поставить? Что узнать?

Допустим, даете задачу и нейросеть ее решает. Вам нужно узнать на основе каких входящих данных она смогла ее решить, была ли в база такая же задача или похожая. Куда вы будете ставить брейкпоинт?

S>>Если вы задаете вопрос (входящие данные) — то все нейроны всех слоев (или большая часть нейронов) — вносят свой небольшой вклад в ответ.

M>Звучит похоже на алгоритм discrete Fourier transform.
M>Наверное для тебя это тоже магия.

А что магического? В чем вопрос, на который нет и не может быть ответа?

Здравствуйте, Pzz, Вы писали:

Pzz>Гы. На JS только так и пишут. С асинхронными калбеками. Которе немного облагородили, завернув в promises, чтобы совсем уж не свихнуться.
Pzz>И во всякие более другие языки такой подход тащут.

Да причем тут это? Код если и распараллелен — он все-равно детерминирован. Если где-то параллельный доступ к разделяемому ресурсу с непредсказуемым поведением — обязательно синхронизация.

Здравствуйте, Osaka, Вы писали:

S>>И основной вопрос — приняли ли вы уже это? Или же имеете внутреннюю неприязнь к ИИ и системам, построенным на его основе?
O>Всегда обходил смердфоны стороной, и теперь стало понятно почему.

Боюсь что так смогут лишь единицы, типа Германа Стерлигова.

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Pzz, Вы писали:

Pzz>>Если я не ошибаюсь, именно Эдсгер Дейкстра ввел в обиход организацию ввода-вывода вокруг системы прерываний, вместе с чем ушла детерминированность. Раньше этого избегали. И это, на минуточку, середина 60-х.

vsb>Тем не менее никто не пишет программы с прерываниями в юзерспейсе. Любая программа с вводом-выводом взаимодействует в чётких точках вызова API. Кстати задумался даже — почему так. Вроде бы логично было бы дать операционной системе указатели на функции и чтобы она вызывала эти функции при вводе/выводе, аналогично тому, как это происходит с сигналами... Ну не суть, по факту так не делают. Поэтому таки детерминированность не ушла для 99% программистов, её аккуратно вернули на место.

Откуда взялись 99% программистов?
Мне напротив кажется так асинхронный ввод вывод сейчас это основной, который используется в большинстве программ.
Для .NET допустим или NODE.

await File.WriteAllTextAsync(filePath, text);

Асинхронность обеспечивается на уровне OC. В Windows это OVERLAPPED, в Linux это libaio (io_submit)
Ну насколько я знаю конечно. Последние много лет я ничего кроме веба не видел. Я не прав? Что у WriteAllTextAsync "под капотом"?

Здравствуйте, bnk, Вы писали:

bnk>

bnk>await File.WriteAllTextAsync(filePath, text);
bnk>

bnk>Асинхронность обеспечивается на уровне OC. В Windows это OVERLAPPED, в Linux это libaio (io_submit)
bnk>Ну насколько я знаю конечно. Последние много лет я ничего кроме веба не видел. Я не прав? Что у WriteAllTextAsync "под капотом"?

И? В чем проблема это отладить по шагам? Ну пишите в лог, в логе будет последовательность всех вызовов. Если что-то нужно синхронизировать — добавьте мьютексы. Здесь магии нет — код фиксирован и написан человеком.

Здравствуйте, Shmj, Вы писали:

S>И? В чем проблема это отладить по шагам? Ну пишите в лог, в логе будет последовательность всех вызовов. Если что-то нужно синхронизировать — добавьте мьютексы. Здесь магии нет — код фиксирован и написан человеком.

Это немного оффтопик. Речь не совсем о твоем случае с нейросетями.
Речь была о том что когда в коде начинают использоваться асинхронные операции, он заметно усложняется.
Посмотри чуть выше по ветке о чем речь.

Здравствуйте, Shmj, Вы писали:

vsb>>А вот всё, что касается машинного кода — на это я уже влиять могу. Я могу запускать на своём процессоре любой код. Поэтому и понимание нужно вплоть до последнего байта, выполняющегося на этом процессоре. Ну в идеале.

S>Нейронне сети — на уровне софта. Но точно влиять не можете по ряду причин.

Я с исходным посылом, что нейросети невозможно отлаживать, почти согласен.

В плане "тупой" отладки — конечно согласен полностью. Это как отлаживать обфусцированную программу, там невозможно просто разобраться. Тем более, что все эти нейросети выполняются на видеокартах, в которых миллионы потоков работают одновременно, это просто безумие, пытаться там что-то понять.

Не согласен только в той части, что это принципиально невозможно отлаживать. Думаю, способы придумают. Вот та же модель o1. Она не выдаёт ответ просто так, она выдаёт все рассуждения, которые привели к этому ответу. Думаю, те, кто её тренирует, способны находить неправильные рассуждения и менять процесс тренировки так, чтобы убирать ошибки. Хотя если мы пользователи этого API, конечно это будет просто "вещь в себе", но это справедливо по сути для любого API.

Здравствуйте, Pzz, Вы писали:

vsb>>Тем не менее никто не пишет программы с прерываниями в юзерспейсе. Любая программа с вводом-выводом взаимодействует в чётких точках вызова API. Кстати задумался даже — почему так. Вроде бы логично было бы дать операционной системе указатели на функции и чтобы она вызывала эти функции при вводе/выводе, аналогично тому, как это происходит с сигналами... Ну не суть, по факту так не делают. Поэтому таки детерминированность не ушла для 99% программистов, её аккуратно вернули на место.

Pzz>Гы. На JS только так и пишут. С асинхронными калбеками. Которе немного облагородили, завернув в promises, чтобы совсем уж не свихнуться.

Ну вот получается такая пирамида — операционная система получает прерывание, кладёт чего-то в какой-то буфер, потом программа в цикле обработки событий тем или иным способом проверяет, что в этом буфере что-то получилось, вычитывает из него данные и вызывает коллбэк.

В принципе было бы интересно посмотреть на ОС, в которой этого промежуточного этапа нет. Пришло прерывание, тут же вызвался программный обработчик. Тут, конечно, много вопросов возникает — типа вообще нехорошо из обработчиков прерывания что-то нетривиальное делать и тд... Но может что-то придумали бы, чтобы избежать всей этой многоуровневой буферизации и перекладывания байтов из пустого в порожнее.

Здравствуйте, bnk, Вы писали:

bnk>Асинхронность обеспечивается на уровне OC. В Windows это OVERLAPPED, в Linux это libaio (io_submit)
bnk>Ну насколько я знаю конечно. Последние много лет я ничего кроме веба не видел. Я не прав? Что у WriteAllTextAsync "под капотом"?

Я не знаю, что там в винде, в юниксе простейший способ это вызов read/write. Можно делать select для обработки нескольких дескрипторов в одном потоке, это сути не меняет, весь ввод/вывод осуществляется в строго определённой последовательности и ОС буферизует необработанные данные, пока программа их не запросит. Конечно можно с каждым дескриптором связать указатель на функцию и вызывать этот указатель, но это уже вопрос внутренней организации программы, по-разному можно делать.