Реально интересная история. Многого не знал. Хотя в своё время перестроечную литературу по этой теме читал.
Но, похоже, более-менее понятно, почему так получилось с Вавиловым: его открытия, конечно, великие, и имя своё он в историю вписал.
Но: реальной отдачи от них в пределах десятилетий - не было и быть не могло.
Ну не было у СССР в тот момент возможности заниматься фундаментальной наукой без очевидной привязки к прикладному применению.
А Лысенко напирал именно на прикладное применение. И - правдиво или нет - какие-то результаты демонстрировал.
С Королёвым, кстати, та же самая штука случилась: потратил деньги на проект, который изначально (на том уровне развития техники) был невозможен. Но ему повезло больше, и он дожил до момента, когда его идеи осуществились.
------------------------
Кстати, насчёт Вавилова-шпиона. Есть теория, что он действительно был шпионом - в смысле, что его путешествия по всяческим ебеням использовались спецслужбами СССР для маскировки своей разведдеятельности. Всё-таки его выпускали за границу, и снабжали валютой - не верится, что "под чистую науку".
Ой блин, а нельзя было наклеить плитки на стену и подогреть выхлопом из того же реактивного двигателя?
А то, что "металлические плитки окисляются при высокой температуре" - блин, да за то, что у них нет в команде химика и материаловеда - или они их тупо не слушают - надо руководство ставить к стенке.
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
Но в статье я поднимаю немного другую тему: как сделать так, чтобы даже ошибки возникли система продолжала работать насколько это возможно, а пользователь не сталкивался с крашем, потерей данных или “горящим” интерфейсом и надеждой, что его починят как можно скорее. Идеального кода не бывает, а отказоустойчивость — это как раз про то, что делать, когда идеал дал трещину.
Вот именно! Практически в 100% случаев, попытка "продолжить работу после ошибки" - приводит к тому, что система становится не просто бесполезной, но - активно вредной.
Вот у вас нет памяти. Вы начинаете "обходить" ошибки выделения памяти, в результате - теряете данные, пользователь об этом не знает - и получает потерю или искажение пользовательских данных.
Например, разработчик текстового редактора (уровня OpenOffice/MS Word), если попробует "обходить" и "восстанавливаться" после проблем нехватки памяти - запросто может потерять часть документа. Или, например, вставленные рисунки. После чего пользователь этот документ сохраняет - и привет.
Практически единственный пример, когда "обход" ошибок выделения памяти оправдан - это если вы непосредственно по команде пользователя пытаетесь сделать что-то, требующее выделения большого-большого блока памяти, начинаете операцию с выделения памяти - и вот тут реально можно проверить, что память не выделена и операцию выполнить не удастся. И об этом удастся сообщить пользователю, т.к. свободная память ещё есть.
А вот если вы начали большую операцию, выделяете память мелкими кусочками по-объектно, и вот где-то в середине у вас обломалось выделение очередного мелкого объекта - вам кирдык.
Вы не сможете ни сообщить об этом пользователю, ни откатить операцию - так как памяти у вас вообще нет. А на сообщения и откат - сюрприз - нужна память.
Я такое проходил. Допустил утечку памяти, причём, малыми кусочками. За месяц непрерывной работы, память тупо кончилась вся. И дальше, так как программа именно была ориентирована на "продолжение работы" - начала терять функции интерфейса. Пункты из меню. Элементы интерфейса.
Что выглядело совершенным безумием для пользователя. Причём если бы она просто грохнулась - пользователь просто запустил бы её заново.
А, вот откуда появлется куча "программистов", постоянно использующих паттерн:
let data;
try
{
data = this.getSomeData();
} catch(error)
{ data = this.getErrorData();
console.error(error); }
this.doSomething(data);
А ещё паттерн:
bool someFunc(Param * param)
{
if (nullptr == param) return false;
....
}
И ещё хорошо, если ошибку залогируют.
Возможно, если хорошо прищуриться, это может в каких-то редких случаях иметь смысл при разработке фронтенда на JS.
Но! Вот такой подход категорически, абсолютно недопустим при разработке абсолютно любых реально используемых для чего-то разумного продуктов.
Самый разумный подход: это при обнаружении ошибки, которую вы не знаете как можно обработать - немедленно паниковать с сохранением достаточной информации (где и почему) запаниковало.
Попытки продложить работу, если вы обнаружили не предусмотренную вашим алгоритмом ошибку - их необходимо категорически исключить. Продолжая работу при ошибке - вы а) сделаете хуже б) затрудните обнаружение и исправление ошибки.
Включите в ваш набор инструментов аналог макроса assert (я предпочитаю комбинацию verify()/halt())который никогда не отключается, в том числе в релизной сборке.
Активно применяйте его для проверки входных данных, выходных данных, возвращаемых значений и промежуточных условий/утверждений.
Подход "оборонительного программирования" - не означает, что вы должны паниковать и завершать работу, если пользователь указал для сохранения данных файл, не доступный на запись, или если сетевое соединение разорвалось.
Вы можете корректно и разумно обработать эти события? Обрабатывайте. Не можете или вам лень вот прямо сейчас писать код обработки? Ставьте verify().
Но вот если вам в функцию передали nullptr, и в спецификации функции не указано, что "вот этот параметр можно поставить null и поведение будет следующим ..." - паникуйте. Никогда, ни при каких условиях не надо пытаться "маскировать" ошибку.
Читать почту и отвечать на почту. А для того, чтобы ответить на почту - надо знать, что отвечать.
И да, есть такой небольшой нюанс: у нейросети нет отдельного входа для "данных снаружи" и "данных изнутри".
Их можно маркировать "данные присланные снаружи" и "внутренние данные" - но нейросеть технически никак не ограничена в том, чтобы эти данные не могла попутать.
Точно так же, как человек может забыться и в ответ на электронной письмо с незнакомого адреса ответить какой-нибудь конфеденциальной информацией. Типа: "ой, не подумал".
---------------
Теоретически, если у нейросети просто нет доступа к "закрытой" информации - а только к открытой - она не сможет её разгласить. Но тогда особого смысла в этой нейросети и нет.
То есть я правильно понимаю - вместо литературных текстов, системе глубокого обучения дали на вход 22 миллиона спецификаций ферментов и описания их свойств, а далее - для спецификации фермента предложили описать его свойства?
Охренительно. То есть модель никакого физического представляения о самом ферменте (и том, как он работает в огранизме) не имеет, но выдаёт "похожие на настоящие" описания?
Реально интересная история. Многого не знал. Хотя в своё время перестроечную литературу по этой теме читал.
Но, похоже, более-менее понятно, почему так получилось с Вавиловым: его открытия, конечно, великие, и имя своё он в историю вписал.
Но: реальной отдачи от них в пределах десятилетий - не было и быть не могло.
Ну не было у СССР в тот момент возможности заниматься фундаментальной наукой без очевидной привязки к прикладному применению.
А Лысенко напирал именно на прикладное применение. И - правдиво или нет - какие-то результаты демонстрировал.
С Королёвым, кстати, та же самая штука случилась: потратил деньги на проект, который изначально (на том уровне развития техники) был невозможен. Но ему повезло больше, и он дожил до момента, когда его идеи осуществились.
------------------------
Кстати, насчёт Вавилова-шпиона. Есть теория, что он действительно был шпионом - в смысле, что его путешествия по всяческим ебеням использовались спецслужбами СССР для маскировки своей разведдеятельности. Всё-таки его выпускали за границу, и снабжали валютой - не верится, что "под чистую науку".
К сожалению, кодируют. И Ё, и Й кодируют. Я сам нарывался - при копировани из MS Excel названия документа - скопировалость именно таким образом.
Не представляете, как потом бесило то, что файл не мог быть найден в файловой системе - хотя вот он, блин, лежит.
Но это не проблема UTF-8 - это Unicode в целом.
Ой блин, а нельзя было наклеить плитки на стену и подогреть выхлопом из того же реактивного двигателя?
А то, что "металлические плитки окисляются при высокой температуре" - блин, да за то, что у них нет в команде химика и материаловеда - или они их тупо не слушают - надо руководство ставить к стенке.
Извините за вопрос - а ЗАЧЕМ нужен абсолютный детерменизм в машинном обучении?
Возможно, имеет некоторый смысл при тонкой оптимизации/отладки собственно алгоритмов разработчиками библиотек МЛ - но для обычных целей - зачем?
Механизм обнаружения утечек памяти в долговременно запущенном ПО - да, обязательно должен быть. Проекты, с которыми сталкивался я - имеют прогнозируемый uptime, измеряемый в годах. Т.е. перезапуск - при штатном сервисном обслуживании. Раз в год, а то и реже.
Может быть очень медленная утечка памяти, когда проблемы начнут проявляться не через сутки и даже не через неделю.
Более того, лично я сталкивался с ситуацией, когда утечка памяти начинала проявляться не как "нет памяти/падают процессы" - а замедлением работы системы, т.к. тот же аналог кэша разрастался настолько, что поиск в нём стал занимать существенное время.
Поэтому - все наши разработки включают механизм, который отслеживает потребление памяти. Чтобы не мучиться с настройкой для каждого процесса - через сутки после запуска берём текущее потребление, удваиваем, добавляем константу - и считаем это жёстким лимитом сверху.
Нет. Основное отличие современного "вайб-кодинга" от всех прежних попыток - недетерминированность.
Ассемблер, С, языки высокого уровня, да даже графический интерфейс "мышкой натягал блоков" - всё это детерменировано. Ты формулируешь приказы на чётко определённом, однозначном языке - и получаешь результат.
Когда ты пишешь код с помощью генеративного ИИ - результат не детерминирован.
Не очень понятно вообще, как можно сделать корпус батискафа из углеволокна. Углеволокно отлично работает на растяжение/разрыв, но плохо - на сжатие. Существенно проще преодолеть предел упругости на сжатие, чем на растяжение.
То есть я могу себе представить сосуд из углеволокна, у которого бешеное давление внутри сосуда, такой сосуд будет легче и надёжнее, чем сосуд из металла - но батискаф-то работает наоборот.
Как они вообще сумели 13 раз успешно спустится, не пойму.
80 часов в неделю? Ну да, ну да - как в анекдоте: "Печатаю 3000 знаков в минуту. Правда, такая фигня получается...".
Невозможно заниматься творческой работой 80 часов в неделю больше 1-2 недель подряд. Да и по факту какой-то выигрыш будет первые несколько дней.
Такая потогонка означает, что они или хотят нафиг выкинуть всех оставшихся из купленной компании - или демонстрируют, "какие они крутые" для инвесторов.
Классический пример, когда систему управления задачами/дефектами внедряли не для того, чтобы людям было легче - а для того, "чтобы начальство видело".
И самая первая ошибка - безумная схема переходов между статусами с 15 отдельными статусами.
Статусов должно быть 4-5 максимум (считая "новая" и "закрыто"), и переходы между ними - произвольные или почти произвольные. Потому что в реальности очень мало задач решается "по схеме".
Дальше - людей надо:
а) научить работать в системе - и лучше, чтобы система была действительно простая.
б) категорически все задачи ставить только через систему. Лично, самому.
в) проверять результаты - тоже только через систему.
Ну выбирай, будешь крепостным или колхозником?
Собеседование - только очное. Телефон - сдаётся и кладётся в сейф.
Тестовое задание кандидат пишет на бумаге.
Задание не сложное, и не требующее знания конкретного API. В своё время мне такое задание давали на 2 курсе, на практикуме по С/С++.
Для решения необходим только язык, знание его базовых конструкций и базовые операции.
Час времени.
И да, мы не требуем, чтобы результат компилировался - но кандидат должен объяснить, что делает его алгоритм, как делает - и как доработать алгоритм так, чтобы исправить ошибку, которую кандидат наверняка допустил (задания простые, но требуют продумать задачу до конца).
Можно потом поспрашивать по типовым вопросам, но задание - важнее.
Халява! Оплачивается госдепом США. Всё ради процветания и демократии в Иране!
А потом (и чем больше обучающих данных и объем нейросети) начинается то, что в вычислительной математике называется "неустойчивое решение" - т.е. фактически результаты на выходе - произвольные, зависящие от ошибок округления.
Это и называется галлюцинацией нейросети.
Если заказчик не написал ТЗ - пишите его сами. И требуйте согласовать.
Нет, есть конечно вариант, когда заказчик "согласует" не глядя ваше ТЗ, а потому выяснится, что "он не то имел в виду" - обычно это случается во внутренних проектах внутри организации.
Но даже в этом случае, имея на руках документ - проще доказать необходимость дополнительных часов/людей на выполнение новых "хотелок".
-------------------------------
На самом деле есть команды, которые очень любят отсутствие ТЗ. Это команды, ориентированные на процесс, а не результат. Обычно такая команда берётся за мегапроект с хорошим финансирование, месяцы-годы над проектом работает - а потом сливается в полном составе, например, "все уволились по причине того, что нас тут не ценят".
Далее ищется другой проект ... а по поводу прежнего в резюме перечисляется миллион суперкрутых техник/фреймворков/языков (у нас всё на микросервисах, работаем с бигдатой с помощью ИИ, почти закончили суперсистему для торговли индивидуально сгенерированными ИИ и распечатанными на 3д-принтере чесалками для жопы, но тут заказчик закрыл проект из-за финансовых проблем. А, да, всё это написано на Go, а что не на Go - то на Rust).
А критиковать Троцкий начал именно тогда, когда проиграл во внутрипартийной борьбе. А проиграл, потому что не смог предложить ничего разумного.
Замечаетельно! Описания коммитов, сгенерированные нейросетью - читать будет только другая нейросеть.
Вот именно! Практически в 100% случаев, попытка "продолжить работу после ошибки" - приводит к тому, что система становится не просто бесполезной, но - активно вредной.
Вот у вас нет памяти. Вы начинаете "обходить" ошибки выделения памяти, в результате - теряете данные, пользователь об этом не знает - и получает потерю или искажение пользовательских данных.
Например, разработчик текстового редактора (уровня OpenOffice/MS Word), если попробует "обходить" и "восстанавливаться" после проблем нехватки памяти - запросто может потерять часть документа. Или, например, вставленные рисунки. После чего пользователь этот документ сохраняет - и привет.
Практически единственный пример, когда "обход" ошибок выделения памяти оправдан - это если вы непосредственно по команде пользователя пытаетесь сделать что-то, требующее выделения большого-большого блока памяти, начинаете операцию с выделения памяти - и вот тут реально можно проверить, что память не выделена и операцию выполнить не удастся. И об этом удастся сообщить пользователю, т.к. свободная память ещё есть.
А вот если вы начали большую операцию, выделяете память мелкими кусочками по-объектно, и вот где-то в середине у вас обломалось выделение очередного мелкого объекта - вам кирдык.
Вы не сможете ни сообщить об этом пользователю, ни откатить операцию - так как памяти у вас вообще нет. А на сообщения и откат - сюрприз - нужна память.
Я такое проходил. Допустил утечку памяти, причём, малыми кусочками. За месяц непрерывной работы, память тупо кончилась вся. И дальше, так как программа именно была ориентирована на "продолжение работы" - начала терять функции интерфейса. Пункты из меню. Элементы интерфейса.
Что выглядело совершенным безумием для пользователя. Причём если бы она просто грохнулась - пользователь просто запустил бы её заново.
А, вот откуда появлется куча "программистов", постоянно использующих паттерн:
let data; try{data = this.getSomeData(); } catch(error){ data = this.getErrorData();console.error(error); }this.doSomething(data);А ещё паттерн:
bool someFunc(Param * param)
{
if (nullptr == param) return false;
....
}
И ещё хорошо, если ошибку залогируют.Возможно, если хорошо прищуриться, это может в каких-то редких случаях иметь смысл при разработке фронтенда на JS.Но! Вот такой подход категорически, абсолютно недопустим при разработке абсолютно любых реально используемых для чего-то разумного продуктов.Самый разумный подход: это при обнаружении ошибки, которую вы не знаете как можно обработать - немедленно паниковать с сохранением достаточной информации (где и почему) запаниковало.Попытки продложить работу, если вы обнаружили не предусмотренную вашим алгоритмом ошибку - их необходимо категорически исключить. Продолжая работу при ошибке - вы а) сделаете хуже б) затрудните обнаружение и исправление ошибки.Включите в ваш набор инструментов аналог макроса assert (я предпочитаю комбинацию verify()/halt())который никогда не отключается,в том числе в релизной сборке.Активно применяйте его для проверки входных данных, выходных данных, возвращаемых значений и промежуточных условий/утверждений.
Подход "оборонительного программирования" - не означает, что вы должны паниковать и завершать работу, если пользователь указал для сохранения данных файл, не доступный на запись, или если сетевое соединение разорвалось.
Вы можете корректно и разумно обработать эти события? Обрабатывайте. Не можете или вам лень вот прямо сейчас писать код обработки? Ставьте verify().
Но вот если вам в функцию передали nullptr, и в спецификации функции не указано, что "вот этот параметр можно поставить null и поведение будет следующим ..." - паникуйте. Никогда, ни при каких условиях не надо пытаться "маскировать" ошибку.
Читать почту и отвечать на почту. А для того, чтобы ответить на почту - надо знать, что отвечать.
И да, есть такой небольшой нюанс: у нейросети нет отдельного входа для "данных снаружи" и "данных изнутри".
Их можно маркировать "данные присланные снаружи" и "внутренние данные" - но нейросеть технически никак не ограничена в том, чтобы эти данные не могла попутать.
Точно так же, как человек может забыться и в ответ на электронной письмо с незнакомого адреса ответить какой-нибудь конфеденциальной информацией. Типа: "ой, не подумал".
---------------
Теоретически, если у нейросети просто нет доступа к "закрытой" информации - а только к открытой - она не сможет её разгласить. Но тогда особого смысла в этой нейросети и нет.
То есть я правильно понимаю - вместо литературных текстов, системе глубокого обучения дали на вход 22 миллиона спецификаций ферментов и описания их свойств, а далее - для спецификации фермента предложили описать его свойства?
Охренительно. То есть модель никакого физического представляения о самом ферменте (и том, как он работает в огранизме) не имеет, но выдаёт "похожие на настоящие" описания?
Хайпожоры, что тут сказать.