Обновить
0

Пользователь

Отправить сообщение

Тут мне кажется, что надо иметь две вещи в голове:

1. Иногда человек ничего не спрашивает, потому что ему так нужна работа, что он готов на любые ваши условия. Как скажете, так и будет делать. Зарплата есть? Этого достаточно.

2. Иногда вакансии такие туманные и расплывчатые, что конкретный вопрос задать сложно. Спросишь: "а вообще чем вы занимаетесь и что делать надо будет?". А тебя пометят, как незаинтересованного - не удосужился про компанию почитать в интернете.

Спрашивать про корпоративную культуру странно, вот про премии, механизмы повышения и пересмотра - это полезные вопросы.
Культуру лучше всего показывать на примере - пригласите сотрудника во все чаты или проведите по кабинетам, познакомьте со всеми. А дальше человек посмотрит на других и начнет таким же образом взаимодействовать.

Просто вы все в кучу смешали: резюме, безработных и прочее. И выводы делаете, основываясь на образности вместо фактов.

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

Учитывая, что хх.ру - центральная платформа по найму в стране с высоким уровнем цифровизации услуг, не вижу причин, почему там не может быть 8 млн резюме.

Непонятно, как аналогия с миллионниками доказывает вашу правоту. Да, резюме много, но и сокращений много.

А можете в статье добавить примеры контуринга, который генерирует модель? Вы описали случаи: с пуговицами, с перилами, можете их показать?

А как без кода узнать, что используется ваша модель, а не обычная YOLO?

А где метрики по классификации? Она в статье упоминается, а метрик нет.

На рисунке 3, где в каждом подзапросе одинаковые условия where, не проще перенести их в часть from? Тогда они будут обрабатываться один раз

Чтобы вместо from orders был подзапрос

From

(Select * from orders

where id = 123

And date between x and y) as orders-filtered?

Но ИИ до сих пор не может заменить базовое написание sql-запросов

LLM'ки отлично пишут sql-запросы. Даже допотопные вроде gpt 3.5. А уж с базовыми запросами вообще проблем нет.

Студент получил 7 собесов и несколько офферов на 50 откликов?

А говорят, что в отечественном IT кризис, а говорят, что джуны не нужны.

Что-то не сходится.

OpenWorm сделали, а в марте запустили цифровой мозг мухи в "матрицу".

Гуглите Eon Systems.

Вот про сам эксперимент от авторов:

https://theinnermostloop.substack.com/p/the-first-multi-behavior-brain-upload

Eon Systems в прошлом месяце как раз провели такой эксперимент - загрузили оцифрованный мозг дрозофилы в симуляцию. И, вроде как, она полетела без какого-либо либо обучения/настройки извне.

Подробнее от основателя компании:

https://theinnermostloop.substack.com/p/the-first-multi-behavior-brain-upload

🔗 Sequential (конвейер): Агенты работают по очереди. Каждый видит, что конкретно сделали предыдущие, и сам решает — кем быть и стоит ли вообще участвовать.

Из статьи непонятно - зачем тогда нужна команда агентов. Если все агенты работают последовательно, т.е. только один агент активен в один момент времени, разве не должно хватать ровно одного агента? А роль он будет менять себе на лету.

И в продолжение мысли - разве ваша статья не доказывает, что агентская разработка, когда несколько агентов совместно разрабатывают ПО, проигрывает инкрементальному подходу, когда один агент последовательно пишет всё ПО? Что, в принципе, ставит под сомнение эффективность в использовании группы агентов.

Кстати, в статье опущен важный элемент - скорости разработки. Sequental может быть эффективнее других, но гораздо медленнее. Проводилась ли оценка по критерию: при каком из подходов будет быстрее достигнуто решение с уровнем качества 0.6, например? Потому что sequental, может быть, и даёт результат качественнее, но ждать его надо, допустим, в 10 раз дольше. Возможно, что самоотвод будет давать дополнительную прибавку к скорости - при одном подходе агенты решат, что "и так уже хорошо", а при другом будут "биться об стену в тщетных попытка".

Платформа CodeSpeak меняет этот парадокс, фиксируя диалог с ИИ в виде статических файлов спецификаций. Спецификация становится главным артефактом, подлежащим контролю версий и код-ревью. Команда обсуждает и утверждает смысловую часть алгоритма, оставляя валидацию синтаксиса на откуп автоматизированным тестам.

А чем это отличается от обычной спецификаций в .md для языковых моделей?

Главная ценность такого подхода заключается в жесткой изоляции. Так как спецификация предельно четкая и имеет строгие контракты ввода-вывода, ИИ-агенту не нужно выдумывать, что именно реализовать, или галлюцинировать дополнительный функционал. Нейросеть ограничена рамками Markdown-файла. Если спустя время разработчику понадобится добавить извлечение даты получения письма, он просто допишет одну строку в раздел «Output Structure» в .cs.md файле. После команды сборки CodeSpeak обновит исключительно eml_converter.py и его тесты, совершенно не затрагивая остальную кодовую базу проекта.

Так и как это реализовано? За счёт чего удается избежать галлюцинаций (тем более, что исследователи OpenAI уже доказали, что это невозможно) и написания лишнего функционала?

Я, кстати, тоже не понял, почему 70B лучше запускать на потребительских картах, если они не умещаются в память. Наоборот, Spark нужен как раз для работы с большими моделями.

Он перед уходом от Цукерберга начал претворять концепции "понимания мира" в жизнь - разработал класс новых моделей jepa. Так что он точно не просто болтает.

Reasoning должен быть проверяемым. В математике в качестве проверки используются правила. Поэтому модель может навыдумывать кучу задач, а затем проверять, чтобы она соответствовала правилам математики.

С изображениями сложнее - в качестве проверки выступают правила реального мира, и их сложно формализовать.

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

Нужно разбираться с DataParallel, Distributed DataParallel и прочими шутками. Впрочем, это тема для отдельного разговора.

Без этого непонятно зачем вообще столько мороки.

Можно почитать про архитектуру JEPA от Яна Лекуна, с помощью которой он хочет приблизить модели к человеческому мышление.

Если вкратце, то животные, и человек в том числе, рождаются с "предобученной моделью", с базовыми знаниями о законах мира, которая "быстро дообучается".

Тут скорее про то, что не существовало объемных датасетов, размеченных под такую задачу. Авторы в статье описывают, как они создали такой датасет.

Если почитать оригинальную статью, то там не совсем про форму. Просто раньше не было датасетов, которые бы могли научить модели отличать "живое" от "неживого", растения от животных, сухопутное от морского и т.д. А за счет нового датасета модели могут это понять, что делает их восприятие близким к человеческому.

1

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность