Для меня ваша статья читается так: исследовательские данные такого качества, что легко можно подобрать данные под любой удобный вывод.
Т.е. вы осудили 100500 "плохих" статей которые доказывают "неправильный для нас" вывод. И вот есть одна хорошая статья из Китая, которая доказывает "правильный для нас" вывод. При таких вводных обычно просто вывода нет - если у вас нет компетенции утверждать, что нужная статья действительно правильная, но я, как читатель, вашу компетенцию проверить не могу.
ПС У меня плохое зрение и меня больше раздражает, что дизайнеры мобильных приложений не всегда даже берут настройки размеров шрифта из системных параметров. Это грустно.
В юристпруденции есть положение, что содержание договора должно соответствовать форме. В жизни есть ожидания, что "другая сторона не чудаки на букву "м" и в случае разночтений рулить будет здравый смысл".
Вот именно из таких предположений автор, как мне кажется, и нанялся. Т.е. он воспринял тестовое - как тестовое, а не как "фриланс-проект на месяц работы", который, кажется, невозможно выполнить за неделю. Когда выяснилось, что "тестовое" - на самом деле за рамками разумного для тестового задания он перешёл к пункту №2 - упованию на здравый смысл. Но и тут его обломали.
Задачи любого живого существа (AGI, по сути, будет иная форма жизни): получение энергии для своего существования, развития и расширение ареала обитания
Вы путаете причину со следствием. Существа с такими задачами не получаются "автоматически", просто те существа, у которых такие задачи не "записаны на подкорке" проиграли эволюционную борьбу. В итоге из всех-всех остались только те, которые расширяют свой ареал обитания.
AI же создался as-is, не проходя миллиарды лет и стотни миллионов поколений эволюционной борьбы в направлении "захапать все ресурсы". Поэтму утверждать, что он будет обладать этими признаками как минимум: преждевременно и спорно (как максимум - просто взято с потолка)
Есть ещё одна проблема с рынком джунов. Он в последнее время превратился в "наши российские институты в плохом смысле" - когда требуют очень много, в программы включают все требования, а на выходе - имитация того, что кандидат этим требованиям удовлетворяем. Поясню: - требования к вакансиям всё выше: условные SOLID + фреймворки + паттерны + ООП спрашивают у джунов, при этом прям гоняют и ожидают (а это единственно важное) что он будет всё это применять на практике в разработке проектов. - фактические знания людей претендующих на эти позиции всё ниже (курсы 6 месяцев). ПОДИТОГ: на курсах невозможно научить специалиста на тот уровень, которого ожидают собеседующие - в итоге практическую часть с программированием по best practice на курсах пропускают и дают просто "теорию best practice". ИТОГ: в проигрыше добросовестные кандидаты, что грустно.
По факту градации "джун - миддл - сеньор" в нижней части спектра явно недостаточно. Нужна ещё градация "трейни - джун - миддл - сеньор...". И те, кто не может самостоятельно писать код по тасками - не джуны, а трейни, так их и надо позиционировать.
Как итог мы из-за этого перестали даже рассматривать людей только после курсов - HR не сможет отделить тех, кто умеет в программирование от тех, кто умеет в умные слова (у них после курсов сейчас ещё и на GitHub репозиторий есть - сделанные по тому-же имитационному принципу), а тратить время инженера на просмотр 1000 вакансий джунов - нерационально.
Про то, что "сеньора не пригласили на вакансию джуна" - тут два варианта или его раскусили (мы тоже сначала бегали за теми, кто на голову выше вакансии, потом поняли что люди просто ходят потренить прохождение собеседований) либо процесс найма построен плохо.
У гугла был инцидент, когда один бит в памяти сбился (читал об этом в контексте ECC-памяти). Выглядело это как отсутствие релевантных ответов.
Они после этого они разложили конкретный снапшот поисковых данных (от сырых данных до дерева поиска и поиска по нему) - и нашли что вот тут-то у нас бит сбился при передаче (в сырых одно значение в дереве другое).
После этого дело техники - перестроили базу поехали дальше. Вот ваши движки такой уровень тулинга и зарбора инцидентов делают? Или это просто очередная студенческая-аспирантская поделка, которая на proof-of-concept тянет, а чтобы реальную систему писать - надо CS-ера увольнять и инженеров нанимать?
Почему бы тогда не прсить гпт оценивать вероятность правильности ответа?) Чтобы она прям цифры давала, там, 98% или 2%.
Я пишу как пользователь, а не разработчик. Когда в API добавят вероятности правильного ответа - буду рад.
Ну и из общих соображений - нас же интересует не "правильный следующий токен", а смысл того что написано (условно верный ли алгоритм программы или даже хорошее ли это архитектурное решение), а это впрямую вероятностью следующего токена не решается. То есть надо как-то научиться "выявлять более высокие" уровни абстракции внутри нейросеток и работать с ними.
мы с Пашей как раз на основе этого и готовим следующую большую статью про решение алайнмента и сейфети
Насколько я понимаю трэнд на падение рождаемости ниже 2.0 per woman везде кроме Африки и очень отдельных частей мира (типа в южном Казахстане рождаемость растёт).
То есть по конкретным декадам \ поколениям вы правы, по общей тенденции - можно просто написать отставание и будтет +/- верно.
Мне проблема (внедрения в повседневную деятельность) видится в том, что ChatGPT не просто ошибается, а "тихо ошибается".
Т.е. вот от человека (условно пусть условно джуна) можно получить код и он скажет, что вот тут знаю \ вот тут не уверен как писать, но сделал. А ChatGPT этого "был не уверен, вот это место перепроверить бы" не пишет. А просто выдаёт неверный ответ без уровней уверенности. В развитие этого: когда разговариваем с человеком - можно как-то косвенно получить степень его уверенности, начиная от тона и заканчивая наводящими вопросами, у ChatGPT этого пока нет.
Если как-то резюмировать (исключительно для себя) - то получается, что сейчас наиболее перспективны направления, где: - создать дорого человеку \ дёшево модели - проверить очень дёшево человеку - цена ошибки низка - приз за удачу высок Условно Midjourney - идеальный кэйс, когда нарисовать 100500 деталей сложно, а оценить одним взглядом легко.
Ну вроде ситуация, когда объект надо хранить в 2х коллекциях не супер частая, но и не очень уж редкая. Есть какое-нибудь best practics на Rust как это делать? - разумеется объект должен быть мутабельным - желательно чтобы это скэйлилось на N коллекций. (разумеется "как-то" я могу придумать, но начинают лезть не очень хорошие trade-off).
И вот такие вопросы (ну просто они регулярно всплывают "что будет если") меня останавливают от того, чтобы Rust тянуть в prod.
Как пример - хорошо. Как реальный код - плохо. Я как-то пытался лет 10 назад делать прям "автоматы-автоматы" (т.е. конечный автомат переносил в код примерно так) - через какое-то время вернулся и понял, что подход не очень.
Можно руками сделать happy path с минимумом branch (хотя во вложенном branch prediction - сужу по тестам год назад, в последние 6 лет большой прогресс, то что вызывало задержки на архитектурах 5-летней давности предсказывается на архитектурах годовой давности).
Но тут вопрос в том, что не зная прям досконально лучше не лезть.
Улучшить можно, но если не разбираешься - ухудшить можно ещё сильнее, не говоря уже о поддерживаемости кода.
Это ОЧЕНЬ сложный вопрос (если что peephole правила я руками для одного из компиляторов писал).
Если человек понимает что делает - может сделать немного или даже прилично лучше(*) если не понимет - то сильно хуже, как по уровню производительности так и по уровню поддерживаемости кода.
*) тут надо отметить, что по ощущениям вложенный branch prediction за последние лет 6, как я не в компиляторах в x86 хорошо улучшился.
Вот настоящих автотестов не пробовал. Они бы не давали перевести код между стейджами!
А чем ваши автотесты, которые вы используете (вы же их используете) не настоящие? Почему вы часто пропускаете ошибки? Покрытие? Невозможность ингетрационных? Частая выкатка новой функциональности?
Пример очень слабый если честно и похож на "синдром утёнка". Если первый пример goto был от плохого программиста, значит.... если goto => неграмотные спецы, массивы вместо типизированных данные и т.д. и т.п. А то, что первый же пример (с освобождением ресурсов) - типичный пример из Linux Kernel, где есть goto, а память шарится через union с флагом <=> тип-суммам как-то забывается.
ПС Ну и да в описанном примере вопрос к менеджменту. Если 3 месяца на разработку => 2 недели на тулчейн и стенд; 2 недели на дизайн; дальше прогать. Ну и значит через месяц менеджмент должен был спросить: - вы код писать уже начали? - MVP когда
ПС2 Ну и да в похожем примере (если верить описанию) я бы сам начал с дизайна системы, т.к. в похожих случаях (общение драйвера с железкой) реализация API железки очень часто хорошо ложится на конечный автомат с неполной схемой переходов, которую проще сначала описать, потом прогать, чем хомяк-хомяк и в продакшн.
Вы говорите о том, что IEEE 754 существует, а ваш собеседник, что его модель настолько плохая, что её и за модель-то считать не стоит.
Ну то есть IEEE 754 в случае переполнения портит вашу бизнес-логику (если нет прерываний, а их почти всегда нет) и вы можете вообще об этом не узнать и вместо ошибки получить какие-то неверные данные на выходе (а NAN вообще в промежуточной переменной с которой сравнились и забыли).
Сколько макетов надо сверстать точно в рамках тестового, чтобы вы поняли, что автор это умеет.
Считали нанимателя нормальным => считали что он разместил тестовое.
А потом внезапно выяснилось, что нанимаетль разместил не тестовое. И да это внезапно.
Для меня ваша статья читается так: исследовательские данные такого качества, что легко можно подобрать данные под любой удобный вывод.
Т.е. вы осудили 100500 "плохих" статей которые доказывают "неправильный для нас" вывод. И вот есть одна хорошая статья из Китая, которая доказывает "правильный для нас" вывод.
При таких вводных обычно просто вывода нет - если у вас нет компетенции утверждать, что нужная статья действительно правильная, но я, как читатель, вашу компетенцию проверить не могу.
ПС
У меня плохое зрение и меня больше раздражает, что дизайнеры мобильных приложений не всегда даже берут настройки размеров шрифта из системных параметров. Это грустно.
В юристпруденции есть положение, что содержание договора должно соответствовать форме.
В жизни есть ожидания, что "другая сторона не чудаки на букву "м" и в случае разночтений рулить будет здравый смысл".
Вот именно из таких предположений автор, как мне кажется, и нанялся.
Т.е. он воспринял тестовое - как тестовое, а не как "фриланс-проект на месяц работы", который, кажется, невозможно выполнить за неделю.
Когда выяснилось, что "тестовое" - на самом деле за рамками разумного для тестового задания он перешёл к пункту №2 - упованию на здравый смысл. Но и тут его обломали.
Вы путаете причину со следствием.
Существа с такими задачами не получаются "автоматически", просто те существа, у которых такие задачи не "записаны на подкорке" проиграли эволюционную борьбу.
В итоге из всех-всех остались только те, которые расширяют свой ареал обитания.
AI же создался as-is, не проходя миллиарды лет и стотни миллионов поколений эволюционной борьбы в направлении "захапать все ресурсы". Поэтму утверждать, что он будет обладать этими признаками как минимум: преждевременно и спорно (как максимум - просто взято с потолка)
Есть ещё одна проблема с рынком джунов.
Он в последнее время превратился в "наши российские институты в плохом смысле" - когда требуют очень много, в программы включают все требования, а на выходе - имитация того, что кандидат этим требованиям удовлетворяем.
Поясню:
- требования к вакансиям всё выше: условные SOLID + фреймворки + паттерны + ООП спрашивают у джунов, при этом прям гоняют и ожидают (а это единственно важное) что он будет всё это применять на практике в разработке проектов.
- фактические знания людей претендующих на эти позиции всё ниже (курсы 6 месяцев).
ПОДИТОГ: на курсах невозможно научить специалиста на тот уровень, которого ожидают собеседующие - в итоге практическую часть с программированием по best practice на курсах пропускают и дают просто "теорию best practice".
ИТОГ: в проигрыше добросовестные кандидаты, что грустно.
По факту градации "джун - миддл - сеньор" в нижней части спектра явно недостаточно. Нужна ещё градация "трейни - джун - миддл - сеньор...". И те, кто не может самостоятельно писать код по тасками - не джуны, а трейни, так их и надо позиционировать.
Как итог мы из-за этого перестали даже рассматривать людей только после курсов - HR не сможет отделить тех, кто умеет в программирование от тех, кто умеет в умные слова (у них после курсов сейчас ещё и на GitHub репозиторий есть - сделанные по тому-же имитационному принципу), а тратить время инженера на просмотр 1000 вакансий джунов - нерационально.
Про то, что "сеньора не пригласили на вакансию джуна" - тут два варианта или его раскусили (мы тоже сначала бегали за теми, кто на голову выше вакансии, потом поняли что люди просто ходят потренить прохождение собеседований) либо процесс найма построен плохо.
У гугла был инцидент, когда один бит в памяти сбился (читал об этом в контексте ECC-памяти). Выглядело это как отсутствие релевантных ответов.
Они после этого они разложили конкретный снапшот поисковых данных (от сырых данных до дерева поиска и поиска по нему) - и нашли что вот тут-то у нас бит сбился при передаче (в сырых одно значение в дереве другое).
После этого дело техники - перестроили базу поехали дальше.
Вот ваши движки такой уровень тулинга и зарбора инцидентов делают? Или это просто очередная студенческая-аспирантская поделка, которая на proof-of-concept тянет, а чтобы реальную систему писать - надо CS-ера увольнять и инженеров нанимать?
Я пишу как пользователь, а не разработчик.
Когда в API добавят вероятности правильного ответа - буду рад.
Ну и из общих соображений - нас же интересует не "правильный следующий токен", а смысл того что написано (условно верный ли алгоритм программы или даже хорошее ли это архитектурное решение), а это впрямую вероятностью следующего токена не решается.
То есть надо как-то научиться "выявлять более высокие" уровни абстракции внутри нейросеток и работать с ними.
С интересом почитаю.
Насколько я понимаю трэнд на падение рождаемости ниже 2.0 per woman везде кроме Африки и очень отдельных частей мира (типа в южном Казахстане рождаемость растёт).
То есть по конкретным декадам \ поколениям вы правы, по общей тенденции - можно просто написать отставание и будтет +/- верно.
Мне проблема (внедрения в повседневную деятельность) видится в том, что ChatGPT не просто ошибается, а "тихо ошибается".
Т.е. вот от человека (условно пусть условно джуна) можно получить код и он скажет, что вот тут знаю \ вот тут не уверен как писать, но сделал. А ChatGPT этого "был не уверен, вот это место перепроверить бы" не пишет. А просто выдаёт неверный ответ без уровней уверенности.
В развитие этого: когда разговариваем с человеком - можно как-то косвенно получить степень его уверенности, начиная от тона и заканчивая наводящими вопросами, у ChatGPT этого пока нет.
Если как-то резюмировать (исключительно для себя) - то получается, что сейчас наиболее перспективны направления, где:
- создать дорого человеку \ дёшево модели
- проверить очень дёшево человеку
- цена ошибки низка
- приз за удачу высок
Условно Midjourney - идеальный кэйс, когда нарисовать 100500 деталей сложно, а оценить одним взглядом легко.
Ну вроде ситуация, когда объект надо хранить в 2х коллекциях не супер частая, но и не очень уж редкая.
Есть какое-нибудь best practics на Rust как это делать?
- разумеется объект должен быть мутабельным
- желательно чтобы это скэйлилось на N коллекций.
(разумеется "как-то" я могу придумать, но начинают лезть не очень хорошие trade-off).
И вот такие вопросы (ну просто они регулярно всплывают "что будет если") меня останавливают от того, чтобы Rust тянуть в prod.
@slsktnkv написал "разделить" (это значит отдельно голосовать за С отдельно за С++) а не заменить.
Как пример - хорошо.
Как реальный код - плохо.
Я как-то пытался лет 10 назад делать прям "автоматы-автоматы" (т.е. конечный автомат переносил в код примерно так) - через какое-то время вернулся и понял, что подход не очень.
Можно руками сделать happy path с минимумом branch (хотя во вложенном branch prediction - сужу по тестам год назад, в последние 6 лет большой прогресс, то что вызывало задержки на архитектурах 5-летней давности предсказывается на архитектурах годовой давности).
Но тут вопрос в том, что не зная прям досконально лучше не лезть.
Улучшить можно, но если не разбираешься - ухудшить можно ещё сильнее, не говоря уже о поддерживаемости кода.
Это ОЧЕНЬ сложный вопрос (если что peephole правила я руками для одного из компиляторов писал).
Если человек понимает что делает - может сделать немного или даже прилично лучше(*) если не понимет - то сильно хуже, как по уровню производительности так и по уровню поддерживаемости кода.
*) тут надо отметить, что по ощущениям вложенный branch prediction за последние лет 6, как я не в компиляторах в x86 хорошо улучшился.
физические ядра - абстракция уровня микроархитектуры (о ней знает процессор).
виртуальные ядра - абстракция уровня архитектуры (о ней знает ваша ОС).
То есть у вас 6 физических ядер и 12 виртуальных (по 2 виртуальных ядра на каждом физическом).
А то, что у вас написано - примерно: "я купил 2 упаковки яиц и ещё 18 яиц". Мягко говоря странновато.
А чем ваши автотесты, которые вы используете (вы же их используете) не настоящие?
Почему вы часто пропускаете ошибки? Покрытие? Невозможность ингетрационных? Частая выкатка новой функциональности?
А зачем писать однопроходный компилятор (вы точно компилятор, например с парсером или ассемблером не спутали) в 2023 году?
Пример очень слабый если честно и похож на "синдром утёнка". Если первый пример goto был от плохого программиста, значит.... если goto => неграмотные спецы, массивы вместо типизированных данные и т.д. и т.п.
А то, что первый же пример (с освобождением ресурсов) - типичный пример из Linux Kernel, где есть goto, а память шарится через union с флагом <=> тип-суммам как-то забывается.
ПС
Ну и да в описанном примере вопрос к менеджменту.
Если 3 месяца на разработку => 2 недели на тулчейн и стенд; 2 недели на дизайн; дальше прогать.
Ну и значит через месяц менеджмент должен был спросить:
- вы код писать уже начали?
- MVP когда
ПС2
Ну и да в похожем примере (если верить описанию) я бы сам начал с дизайна системы, т.к. в похожих случаях (общение драйвера с железкой) реализация API железки очень часто хорошо ложится на конечный автомат с неполной схемой переходов, которую проще сначала описать, потом прогать, чем хомяк-хомяк и в продакшн.
Я думаю, что вы говорите о немного разных вещах.
Вы говорите о том, что IEEE 754 существует, а ваш собеседник, что его модель настолько плохая, что её и за модель-то считать не стоит.
Ну то есть IEEE 754 в случае переполнения портит вашу бизнес-логику (если нет прерываний, а их почти всегда нет) и вы можете вообще об этом не узнать и вместо ошибки получить какие-то неверные данные на выходе (а NAN вообще в промежуточной переменной с которой сравнились и забыли).
Ну самая большая неожиданность IQ (когда его только ввели) - оказалось что результаты тестов по разным его разделам очень неплохо скоррелированы.
Т.е. вас сценарий не исключён, но весьма маловероятен.