Старая байка начала 70х, когда в автопроме пытались заменить людей на сборочных роботов. На демонстрации директор завода (Chrysler?), кивая на роботов, говорит с подначкой профсоюзному боссу: "Попробуй уговорить их выйти на забастовку", на что тот отвечает "Попробуй продать им автомобиль".
Заменили людей только на сборке двигателей - она практически полностью автоматизирована уже больше 40 лет без использования ИИ.
Хороший график. При Ковиде сделали кредит бесплатным и компании бросились нанимать. Как только ключевая ставка начала расти - начали увольнять. В случае инженерных и околоинженерных специальностей - в 2020 начала действовать поправка к налоговому кодексу США - списать зарплаты инженеров на R&D сразу нельзя - только амортизировать пять или десять лет. И R&D начали резать. Так что нет каких-то таинственных причин (AI) падения спроса на программистов. Денег стало меньше.
Об этом сказал глава NVidia в своем последнем выступлении, отвечая на вопрос о возможном падении спроса на GPU: Не будет никакого падения - чем больше использование AI, тем больше нужно GPU (и электричества).
Так что эффект нулевых доп затрат (zero marginal cost), за счет которого было возможно практически неограниченное увеличение продаж при почти нулевых дополнительных затратах, с AI не работает. За пользование надо платить не разово (купили лицензию) и не ежегодно (контракт на поддержку), а за каждый факт его использования (за запрос - точнее за токены) и ценник за использование будет только расти. Это возврат к экономической модели промышленности - чтобы больше выпустить продукции, надо купить больше материалов или нанять больше работников, а это радикально новая концепция для софтверной индустрии.
Нет и market lock/network effect in за счет установления стандартов - тоже традиционная power play в индустрии ПО, когда тебе приходится покупать условный Excel потому что все пользуются Excel.
Все подписки на инструменты AI сейчас финансируются венчурным капиталом и кредитами (на ~$1 дохода ~$12-$15 долларов затрат).
И тут вопрос: что же такого должен делать этот софт чтобы оправдать затраты? Готовы платить пользователи, так уверенно заявляющие о замене людей на AI, не $20 а $250 в месяц? Кто-то наверняка готов, но их точно немного.
В той памятной статье было мелким шрифтом напечатано, что она написана под галоперидолом является художественным вымыслом, но внимания на это никто не обратил.
Вот про паровую машину - хорошая тема. Давно думал: можно ли дать ИИ задание на проектирование какой-нибудь простенькой детальки, и попросить сделать КД и техкарты - что он сделает? Как-то все больше про ИИ в медицине, программировании и покорении мира. А конструкторам, технологам, архитекторам, проектировщикам, электрикам и прочим технарям, на которых современная цивилизация и держится, уже можно надеяться (или бояться) или пока рано? Может ИИ помочь проектировщику систем газоснабжения например?
Во Франции запретили алкоголь в школах около 1954 по инициативе министра здравоохранения. До этого бутылка вина была вполне обычным элементом в домашнем обеде старшеклассников (в школьных буфетах все-таки не наливали).
"Вместо этого он сосредоточился на технологии" - это ключевая проблема. Пусть попытается зарегистрировать технологию как разрешенную к применению для оказания медицинских услуг (обязательное условие в большинстве стран для оплаты услуг страховыми компаниями) и он быстро убедится в том, что технология в медицине не значит ровным счетом ничего, пока она не подтверждена клиническими испытаниями. А вот на проведение этих самых clinical trials ни времени ни денег у них не хватит точно.
Можно конечно пойти путем "просто сервис" - вроде как просто сканируем, а уж если найдем что-то подозрительное то направим к врачам. И тут ему предстоит убедиться в том что 1. врачи этих направлений видеть не хотят (и их можно понять) 2. что технология легко воспроизводится - т.е. конкурентов будет полно. 3. не много найдется желающих делать такие манипуляции за свои деньги - это не подписка на Spotify.
И, да, если он попытается хотя бы заикнуться в рекламе (а она нужна) о том, что "спасает жизни", ее тут же запретят (должно быть обоснование - см. пункт "клинические исследования")
«На сегодняшний день нет документальных доказательств того, что скрининг всего тела экономически выгоден или эффективен для продления жизни» - это они не просто так сказали. Когда появилось высокоточное сканирование КТ многие "энтузиасты" сканировали все и бежали к врачам, которые конечно же ничего не находили в подавляющем большинстве случаев (то самое большое количество ложноположительных результатов).
Нашли диабет! Конечно, взяв тест на гликированный гемоглобин (HbA1c) можно выявить пациентов с диабетом, но при чем тут стартап?
Из существующих превентивных технологий ничего лучше регулярного профосмотра, учитывающего медицинскую историю пациента, и, конечно же, грамотного врача пока не придумали.
do
$$
declare
rec record;
l_seq bigint;
l_tab_max bigint;
begin
for rec in (select format('%s.%s', table_schema, table_name) as seq, data_type from information_schema.columns
where column_name = 'id' and data_type in ('integer', 'bigint') order by 1)
loop
begin
SELECT nextval(pg_get_serial_sequence(rec.seq, 'id')) into l_seq;
execute 'select coalesce(max(id), 0) from ' || rec.seq::varchar into l_tab_max;
if l_tab_max > 0 and l_seq < l_tab_max then
execute format('alter sequence %s restart with %s', pg_get_serial_sequence(rec.seq, 'id'), l_tab_max);
raise notice 'corrected table % seq % tabmax %', rec.seq, l_seq, l_tab_max;
end if;
exception
when others then
null;
end;
end loop;
end;
$$
Вот таким скриптом пользуюсь при миграции или после version upgrade. Все identity columns называются id.
Да, инсулин - один из препаратов, для которого применяется sliding scale dosing (особенно в стационаре), и тут я бы больше доверял автоматике, чем медсестре.
Насчет регистрации программ как медицинского оборудования - сейчас это применимо если они идут в составе медоборудования (та же инсулиновая помпа). Я имел в виду немного другое: цифровизация ИМП. Было бы здорово если вместе с бумажкой держатель РУ регистрировал программный компонент который содержит математическую модель применения ЛС. Еще лучше если к этой модели держатель РУ прикладывает набор тестовых данных (подаем на вход набор исходных данных, смотрим ответы на выходе). Тогда вопрос регистрации программы как оборудования сводится к тому проходит она тесты от владельца РУ или нет.
Когда-нибудь регуляторы к этому придут, а пока это слишком радикальная, хотя и реализуемая, идея.
Очень познавательно. Конечно хотел бы. Есть вопрос: Допустим, для каждого препарата разрабатывается математическая модель, которая валидируется в ходе клинических исследований. Насколько применима такая модель в клинической практике? Сейчас, как я понимаю, разработанная модель трансформируется в бумажную инструкцию по применению. А ведь можно было бы (надеюсь) завернуть ее в какой-то компонент, который стандартным образом подключить к информационной системе, опять же стандартным образом "впрыснуть" в него данные о пациенте и получить оптимальные дозировку и режим. Реализуемо ли это?
Элизе (или Элайзе?) Дулитл perfect English помог попасть в high society (а профессору Хиггинсу - выиграть пари). Кроме этого, "правильное" произношение ни для чего не нужно. Поможет ли "правильное" произношение специфических терминов попасть в IT high society expert community? Да как бы не так: классовая структура этого прекрасного общества основана совсем на других принципах; не по произношению мы коллег оцениваем. Мы даже, наверное, гордимся тем, что нам не нужны подобные условности. А говорить надо так, чтобы тебя поняли коллеги - и вот это будет правильно и, главное, рационально.
Была когда-то (больше 50 лет назад) идея "правильного календаря" - объявить первый день нового года нулевым (условно "День нового года"), а начинать отсчет со второго. Тогда календари не нужны: 364/7 = 0 поэтому 1 января ВСЕГДА будет понедельником. 29 февраля будет "Днём високосного года"). Удобно, но так и не реализовано. Imperial system, используемая в США лет всего лишь лет 200, - настоящий ад для инженерных расчетов. Но на метрическую они не переходят.
Про curl cтрого наоборот - использование curl как раз самый, что ни на есть энтерпрайз. У меня сейчас проект, где есть пара сотен вызовов API внешних систем, в результаты которых время от времени надо "тыкать носом" разработчиков некоторых организаций и их начальство.
Вызовы API отрабатываются, заворачиваются в скрипты с генерированием набора тестовых данных (очень важно), журналированием и прочими прелестями. Иногда приходится повозиться с заковыристым запросом (google/ChatGPT здесь в помощь), но в итоге у нас есть скрипт или набор скриптов для тестирования с документированием, который можно запускать одним вызовом или даже встраивать в test/deploy pipeline - не уверен что так можно сделать с postman.
Плюсы: a) читаемый текст б) нормальный кирпичик/модуль, который хочешь в pipeline встраивай, хочешь в git положи в) все документировано! - что и когда вызывали и с какими параметрами, что при этом сломалось и на каких данных г) нужен всего лишь минималистичный текстовый редактор, bash и curl (+ git для отслеживания версий).
Проблема визуальной читаемости решается правильным стандартизированным форматированием скриптов: и, в отличие от postman, все видно на одной-двух страничках. Поэтому с автором полностью согласен (может быть субъективно): намного проще разобраться, намного легче поддерживать, намного более функционально получается.
Старая байка начала 70х, когда в автопроме пытались заменить людей на сборочных роботов. На демонстрации директор завода (Chrysler?), кивая на роботов, говорит с подначкой профсоюзному боссу: "Попробуй уговорить их выйти на забастовку", на что тот отвечает "Попробуй продать им автомобиль".
Заменили людей только на сборке двигателей - она практически полностью автоматизирована уже больше 40 лет без использования ИИ.
Хороший график. При Ковиде сделали кредит бесплатным и компании бросились нанимать. Как только ключевая ставка начала расти - начали увольнять. В случае инженерных и околоинженерных специальностей - в 2020 начала действовать поправка к налоговому кодексу США - списать зарплаты инженеров на R&D сразу нельзя - только амортизировать пять или десять лет. И R&D начали резать.
Так что нет каких-то таинственных причин (AI) падения спроса на программистов. Денег стало меньше.
Об этом сказал глава NVidia в своем последнем выступлении, отвечая на вопрос о возможном падении спроса на GPU: Не будет никакого падения - чем больше использование AI, тем больше нужно GPU (и электричества).
Так что эффект нулевых доп затрат (zero marginal cost), за счет которого было возможно практически неограниченное увеличение продаж при почти нулевых дополнительных затратах, с AI не работает. За пользование надо платить не разово (купили лицензию) и не ежегодно (контракт на поддержку), а за каждый факт его использования (за запрос - точнее за токены) и ценник за использование будет только расти. Это возврат к экономической модели промышленности - чтобы больше выпустить продукции, надо купить больше материалов или нанять больше работников, а это радикально новая концепция для софтверной индустрии.
Нет и market lock/network effect in за счет установления стандартов - тоже традиционная power play в индустрии ПО, когда тебе приходится покупать условный Excel потому что все пользуются Excel.
Все подписки на инструменты AI сейчас финансируются венчурным капиталом и кредитами (на ~$1 дохода ~$12-$15 долларов затрат).
И тут вопрос: что же такого должен делать этот софт чтобы оправдать затраты? Готовы платить пользователи, так уверенно заявляющие о замене людей на AI, не $20 а $250 в месяц? Кто-то наверняка готов, но их точно немного.
В той памятной статье было мелким шрифтом напечатано, что она
написана под галоперидоломявляется художественным вымыслом, но внимания на это никто не обратил.Главный акушер. См значение слова delivery
Все верно. Именно проблемы с многопоточностью в Java подвигли Рича Хики на создание Clojure. Туда же вскоре двинулся и Роберт Мартин.
Вот про паровую машину - хорошая тема. Давно думал: можно ли дать ИИ задание на проектирование какой-нибудь простенькой детальки, и попросить сделать КД и техкарты - что он сделает?
Как-то все больше про ИИ в медицине, программировании и покорении мира. А конструкторам, технологам, архитекторам, проектировщикам, электрикам и прочим технарям, на которых современная цивилизация и держится, уже можно надеяться (или бояться) или пока рано? Может ИИ помочь проектировщику систем газоснабжения например?
Во Франции запретили алкоголь в школах около 1954 по инициативе министра здравоохранения. До этого бутылка вина была вполне обычным элементом в домашнем обеде старшеклассников (в школьных буфетах все-таки не наливали).
Еще один энтузиаст.
"Вместо этого он сосредоточился на технологии" - это ключевая проблема. Пусть попытается зарегистрировать технологию как разрешенную к применению для оказания медицинских услуг (обязательное условие в большинстве стран для оплаты услуг страховыми компаниями) и он быстро убедится в том, что технология в медицине не значит ровным счетом ничего, пока она не подтверждена клиническими испытаниями. А вот на проведение этих самых clinical trials ни времени ни денег у них не хватит точно.
Можно конечно пойти путем "просто сервис" - вроде как просто сканируем, а уж если найдем что-то подозрительное то направим к врачам. И тут ему предстоит убедиться в том что 1. врачи этих направлений видеть не хотят (и их можно понять) 2. что технология легко воспроизводится - т.е. конкурентов будет полно. 3. не много найдется желающих делать такие манипуляции за свои деньги - это не подписка на Spotify.
И, да, если он попытается хотя бы заикнуться в рекламе (а она нужна) о том, что "спасает жизни", ее тут же запретят (должно быть обоснование - см. пункт "клинические исследования")
«На сегодняшний день нет документальных доказательств того, что скрининг всего тела экономически выгоден или эффективен для продления жизни» - это они не просто так сказали. Когда появилось высокоточное сканирование КТ многие "энтузиасты" сканировали все и бежали к врачам, которые конечно же ничего не находили в подавляющем большинстве случаев (то самое большое количество ложноположительных результатов).
Нашли диабет! Конечно, взяв тест на гликированный гемоглобин (HbA1c) можно выявить пациентов с диабетом, но при чем тут стартап?
Из существующих превентивных технологий ничего лучше регулярного профосмотра, учитывающего медицинскую историю пациента, и, конечно же, грамотного врача пока не придумали.
Удивляюсь, что нашлись инвесторы в эту пустышку.
Тема полностью провальная
1. Очень жесткое регулирование (в каждой стране - свое).
2. Чем
Вот таким скриптом пользуюсь при миграции или после version upgrade. Все identity columns называются id.
<зануда мод
не из той оперы. Здесь это значит "тупить" ( be unable to think of something )
нет у Pink Floyd такого альбома
зануда мод/>
Можете привести пример файла модели или ссылку(и) на требования FDA/EMA ?
Да, инсулин - один из препаратов, для которого применяется sliding scale dosing (особенно в стационаре), и тут я бы больше доверял автоматике, чем медсестре.
Насчет регистрации программ как медицинского оборудования - сейчас это применимо если они идут в составе медоборудования (та же инсулиновая помпа).
Я имел в виду немного другое: цифровизация ИМП. Было бы здорово если вместе с бумажкой держатель РУ регистрировал программный компонент который содержит математическую модель применения ЛС. Еще лучше если к этой модели держатель РУ прикладывает набор тестовых данных (подаем на вход набор исходных данных, смотрим ответы на выходе). Тогда вопрос регистрации программы как оборудования сводится к тому проходит она тесты от владельца РУ или нет.
Когда-нибудь регуляторы к этому придут, а пока это слишком радикальная, хотя и реализуемая, идея.
Очень познавательно. Конечно хотел бы. Есть вопрос: Допустим, для каждого препарата разрабатывается математическая модель, которая валидируется в ходе клинических исследований. Насколько применима такая модель в клинической практике? Сейчас, как я понимаю, разработанная модель трансформируется в бумажную инструкцию по применению. А ведь можно было бы (надеюсь) завернуть ее в какой-то компонент, который стандартным образом подключить к информационной системе, опять же стандартным образом "впрыснуть" в него данные о пациенте и получить оптимальные дозировку и режим. Реализуемо ли это?
Элизе (или Элайзе?) Дулитл perfect English помог попасть в high society (а профессору Хиггинсу - выиграть пари). Кроме этого, "правильное" произношение ни для чего не нужно. Поможет ли "правильное" произношение специфических терминов попасть в IT
high societyexpert community? Да как бы не так: классовая структура этого прекрасного общества основана совсем на других принципах; не по произношению мы коллег оцениваем. Мы даже, наверное, гордимся тем, что нам не нужны подобные условности. А говорить надо так, чтобы тебя поняли коллеги - и вот это будет правильно и, главное, рационально.По-русски будет "должность: родственник"
Была когда-то (больше 50 лет назад) идея "правильного календаря" - объявить первый день нового года нулевым (условно "День нового года"), а начинать отсчет со второго. Тогда календари не нужны: 364/7 = 0 поэтому 1 января ВСЕГДА будет понедельником. 29 февраля будет "Днём високосного года"). Удобно, но так и не реализовано.
Imperial system, используемая в США лет всего лишь лет 200, - настоящий ад для инженерных расчетов. Но на метрическую они не переходят.
Про curl cтрого наоборот - использование curl как раз самый, что ни на есть энтерпрайз. У меня сейчас проект, где есть пара сотен вызовов API внешних систем, в результаты которых время от времени надо "тыкать носом" разработчиков некоторых организаций и их начальство.
Вызовы API отрабатываются, заворачиваются в скрипты с генерированием набора тестовых данных (очень важно), журналированием и прочими прелестями. Иногда приходится повозиться с заковыристым запросом (google/ChatGPT здесь в помощь), но в итоге у нас есть скрипт или набор скриптов для тестирования с документированием, который можно запускать одним вызовом или даже встраивать в test/deploy pipeline - не уверен что так можно сделать с postman.
Плюсы: a) читаемый текст б) нормальный кирпичик/модуль, который хочешь в pipeline встраивай, хочешь в git положи в) все документировано! - что и когда вызывали и с какими параметрами, что при этом сломалось и на каких данных г) нужен всего лишь минималистичный текстовый редактор, bash и curl (+ git для отслеживания версий).
Проблема визуальной читаемости решается правильным стандартизированным форматированием скриптов: и, в отличие от postman, все видно на одной-двух страничках. Поэтому с автором полностью согласен (может быть субъективно): намного проще разобраться, намного легче поддерживать, намного более функционально получается.