Вот последние абзацы интересней всего - я еще в прошлом году, как следует распробовав наконец агентскую разработку, начал прикидывать вероятность того что еще через 3-5 лет вся индустрия разработки необратимо поменяется.
Если есть, условно, 30% вероятность того что программистов на зарплате нужно будет в 2 раза меньше - это уже мощный риск который хеджировать надо прямо сейчас. И если не хочется менять сферу и участвовать в крысиных гонках на выживание тоже желания нет - действительно стоит смотреть в сторону запуска своих продуктов, благо ИИ тут как раз сильно помогает.
Прекрасно понимаю что далеко не у всех (и, вполне вероятно, у меня - тоже) есть необходимые для этого продуктово-маркетинговые скиллы, но что еще тут поделаешь?
Но кстати вопрос про тангенциальный импульс остается открытым - получается все же скорость (пере)излучающего тела действительно меняет направление полета фотона, иначе никак не получится сохранить работу световых часов на скоростях в условно 99.99C - когда метровой длины часы успеют "улететь" из под фотона за один тик.
И это вот как раз открывает интересный вопрос про скорость движения света в одну сторону.
В том же сетапе когда свет в часах летает по оси движения ракеты - для внешнего наблюдателя (которому гипотетически ничего не мешает наблюдать всю эту картину со стороны) свет по направлению движения ракеты до одного зеркала часов летит в сотню раз быстрее чем в другую сторону. При этом в перпендикулярных часах он в обе стороны летит одинаковое количество времени, в терминах внешнего наблюдателя.
То есть если мы снаружи отслеживаем каждый пинг-понг фотона в обеих часах - мы четко видим что "вдоль" часы тикают гораздо неравномерней чем часы "поперек" и можем спокойно вычислить скорость движения ракеты на основе этой неравномерности и даже отправить эту информацию обратно на ракету.
Собственно, вопрос такой - а каким вообще образом инвариантность между этими двумя часами сохранится для наблюдателя на ракете? Я подозреваю конечно что здесь должны выскочить преобразования Лоренца, но чисто физически - какие должны работать силы/законы чтобы нельзя было заметить что одни часы тикают равномерно (тик-----так-----тик), а другие - как (тик-так---------тик)?
Скорость передачи информации по разным направлениям искажается так, чтобы ты не мог заметить эту неравномерность? Но ведь внутренний наблюдатель может стоять в такой точке что информация от часов приходит к нему с одного направления...
В общем теория говорит что в таком сетапе для тебя разницы не будет стоят ли часы поперек или вдоль, но вот практически представить как это работать должно - не получается совсем.
ВАЖНО - я говорю именно про обучение модели с нуля, не про скармливание бинарных данных в обычную текстовую модель.
А так, надо понимать что текст - точно такие же бинарные данные для модели, просто набор абстрактных чисел (токенов) между которыми есть какие-то взаимосязи. И вот ллм в процессе обучения пытается найти взаимосвязи между этими числами и успешно находит, после чего может предсказывать какое число должно быть следующим.
У текста есть некоторое преимущество перед бинарными данными только в том что это неструктурированные данные и соответственно можно совершать небольшие ошибки и потом их корректировать через "ой, в смысле другое имел в виду", при этом ошибка в следующем байте компрессии может быть куда более серьезной проблемой.
Но учитывая насколько хорошо модели умеют соблюдать локальную структуру токенов (они по сути не совершают ошибок в структуре предложений/текстов, а это воообще будто бы более сложная задача чем соблюдать well defined структуру архивов) - скорее всего этому они прекрасно научились бы тоже.
Тут правда возникает вопрос - насколько этот дополнительный слой обфускации помешает моделям корректно понимать собственно смысл текста, ведь получается модели надо сначала перевести архив в текст на определенном языке, а потом текст - в его "смысл", общий между разными языками (то что все нейронки в итоге приходят к некоторому универсальному языку для внутреннего мышления - факт вроде бы даже доказанный).
Но тут как раз и получается что компрессия должна быть сразу в этот внутренний язык моделей, по факту - это будет внешняя алгоритмическая замена огромному количеству слоев модели, которые отвечают не за абстрактные операции, а конкретно за перевод текста в абстрактные понятия, которые там потом между собой как-то перемножаются и потом через кучу слоев снова превращаются в одно число на выходе.
Но если так не упарываться, то ничего не мешает модель и на выводе zlib с каким-то разумным размером блока и хорошим словарем - модели то все равно какие взаимосвязи предсказывать.
Вот кстати неиронично кажется мне что нейросетки можно обучить на выходе любого потокового архиватора с относительно небольшим окном (чтобы аттеншен сильно не страдал)
С точки зрения интеллекта худлит должен предоставлять не только сюжет, а еще и разные возможные жизненные (и не очень) ситуации, то как в них можно действовать и какие возможны последствия. Для этого конечно автор должен быть сам с жизненным опытом.
Лучше тогда на расте и писать, он в wasm замечательно компилируется и в браузере запускается. Десктопная версия с максимальной оптимизацией в таком случае прилагается в подарок.
Мне вот прям интересно как там своего воркера развернуть и можно ли кастомные модели делать... Жаль что для этого надо найти впс где можно TDX включить и в целом должна быть возможность сбора машинки с нужным процем и GPU, что сейчас не слишком просто сделать.
Как бы это глупо не звучало... Но лучше у ИИ спросить - https://share.google/aimode/UjLUzlP0jJyOYAIYQ Он за вас со всеми знающими людьми в интернете пообщается и ссылки вам предоставит, как в примере.
Так запретите ту же индексацию через клиппи, правило нужное я привел. Панику при overflow тоже можно устранить двумя способами - либо на уровне компиляции разрешить его чтобы не паниковал никогда, либо для клиппи настроить:
Надо просто через clippy запрещать indexing_slicing - в clippy.toml положить сразу. Там же можно и expect/unwrap запретить, а также разрешить это все в тестах.
strip_prefix clippy тоже умеет предлагать кажется.
Вот последние абзацы интересней всего - я еще в прошлом году, как следует распробовав наконец агентскую разработку, начал прикидывать вероятность того что еще через 3-5 лет вся индустрия разработки необратимо поменяется.
Если есть, условно, 30% вероятность того что программистов на зарплате нужно будет в 2 раза меньше - это уже мощный риск который хеджировать надо прямо сейчас. И если не хочется менять сферу и участвовать в крысиных гонках на выживание тоже желания нет - действительно стоит смотреть в сторону запуска своих продуктов, благо ИИ тут как раз сильно помогает.
Прекрасно понимаю что далеко не у всех (и, вполне вероятно, у меня - тоже) есть необходимые для этого продуктово-маркетинговые скиллы, но что еще тут поделаешь?
Но кстати вопрос про тангенциальный импульс остается открытым - получается все же скорость (пере)излучающего тела действительно меняет направление полета фотона, иначе никак не получится сохранить работу световых часов на скоростях в условно 99.99C - когда метровой длины часы успеют "улететь" из под фотона за один тик.
И это вот как раз открывает интересный вопрос про скорость движения света в одну сторону.
В том же сетапе когда свет в часах летает по оси движения ракеты - для внешнего наблюдателя (которому гипотетически ничего не мешает наблюдать всю эту картину со стороны) свет по направлению движения ракеты до одного зеркала часов летит в сотню раз быстрее чем в другую сторону. При этом в перпендикулярных часах он в обе стороны летит одинаковое количество времени, в терминах внешнего наблюдателя.
То есть если мы снаружи отслеживаем каждый пинг-понг фотона в обеих часах - мы четко видим что "вдоль" часы тикают гораздо неравномерней чем часы "поперек" и можем спокойно вычислить скорость движения ракеты на основе этой неравномерности и даже отправить эту информацию обратно на ракету.
Собственно, вопрос такой - а каким вообще образом инвариантность между этими двумя часами сохранится для наблюдателя на ракете? Я подозреваю конечно что здесь должны выскочить преобразования Лоренца, но чисто физически - какие должны работать силы/законы чтобы нельзя было заметить что одни часы тикают равномерно (тик-----так-----тик), а другие - как (тик-так---------тик)?
Скорость передачи информации по разным направлениям искажается так, чтобы ты не мог заметить эту неравномерность? Но ведь внутренний наблюдатель может стоять в такой точке что информация от часов приходит к нему с одного направления...
В общем теория говорит что в таком сетапе для тебя разницы не будет стоят ли часы поперек или вдоль, но вот практически представить как это работать должно - не получается совсем.
ВАЖНО - я говорю именно про обучение модели с нуля, не про скармливание бинарных данных в обычную текстовую модель.
А так, надо понимать что текст - точно такие же бинарные данные для модели, просто набор абстрактных чисел (токенов) между которыми есть какие-то взаимосязи. И вот ллм в процессе обучения пытается найти взаимосвязи между этими числами и успешно находит, после чего может предсказывать какое число должно быть следующим.
У текста есть некоторое преимущество перед бинарными данными только в том что это неструктурированные данные и соответственно можно совершать небольшие ошибки и потом их корректировать через "ой, в смысле другое имел в виду", при этом ошибка в следующем байте компрессии может быть куда более серьезной проблемой.
Но учитывая насколько хорошо модели умеют соблюдать локальную структуру токенов (они по сути не совершают ошибок в структуре предложений/текстов, а это воообще будто бы более сложная задача чем соблюдать well defined структуру архивов) - скорее всего этому они прекрасно научились бы тоже.
Тут правда возникает вопрос - насколько этот дополнительный слой обфускации помешает моделям корректно понимать собственно смысл текста, ведь получается модели надо сначала перевести архив в текст на определенном языке, а потом текст - в его "смысл", общий между разными языками (то что все нейронки в итоге приходят к некоторому универсальному языку для внутреннего мышления - факт вроде бы даже доказанный).
Но тут как раз и получается что компрессия должна быть сразу в этот внутренний язык моделей, по факту - это будет внешняя алгоритмическая замена огромному количеству слоев модели, которые отвечают не за абстрактные операции, а конкретно за перевод текста в абстрактные понятия, которые там потом между собой как-то перемножаются и потом через кучу слоев снова превращаются в одно число на выходе.
Но если так не упарываться, то ничего не мешает модель и на выводе zlib с каким-то разумным размером блока и хорошим словарем - модели то все равно какие взаимосвязи предсказывать.
Вот кстати неиронично кажется мне что нейросетки можно обучить на выходе любого потокового архиватора с относительно небольшим окном (чтобы аттеншен сильно не страдал)
Индустрия понемногу переизобретает компрессию данных для более дешевой их обработки...)
Glm 5.1 вышел который заявляется на уровне клода вполне.
С точки зрения интеллекта худлит должен предоставлять не только сюжет, а еще и разные возможные жизненные (и не очень) ситуации, то как в них можно действовать и какие возможны последствия. Для этого конечно автор должен быть сам с жизненным опытом.
Лучше тогда на расте и писать, он в wasm замечательно компилируется и в браузере запускается. Десктопная версия с максимальной оптимизацией в таком случае прилагается в подарок.
Silero модели не пробовали? У них и STT и TTS есть, ну и русский один из целевых языков.
Кстати, а насчет gonka.ai - их протокол в основе кокона лежит - не смотрели? Там гораздо больше карт и моделей вроде должно быть? @raiym
Мне вот прям интересно как там своего воркера развернуть и можно ли кастомные модели делать... Жаль что для этого надо найти впс где можно TDX включить и в целом должна быть возможность сбора машинки с нужным процем и GPU, что сейчас не слишком просто сделать.
Кажется вы переизобрели durable execution, в частности restate.dev
Как бы это глупо не звучало... Но лучше у ИИ спросить - https://share.google/aimode/UjLUzlP0jJyOYAIYQ
Он за вас со всеми знающими людьми в интернете пообщается и ссылки вам предоставит, как в примере.
Так запретите ту же индексацию через клиппи, правило нужное я привел. Панику при overflow тоже можно устранить двумя способами - либо на уровне компиляции разрешить его чтобы не паниковал никогда, либо для клиппи настроить:
#![warn(
clippy::cast_sign_loss,
clippy::cast_possible_truncation,
clippy::cast_possible_wrap,
clippy::cast_lossless
)]
Надо просто через clippy запрещать indexing_slicing - в clippy.toml положить сразу. Там же можно и expect/unwrap запретить, а также разрешить это все в тестах.
strip_prefix clippy тоже умеет предлагать кажется.
Посмотрите https://learn.golem.cloud/fundamentals - просто весь процесс в васме замораживают и продолжают с той же точки.
А можно хоть какие-то подробности добавить? Хотя бы ссылку на бенчмарки или еще что-то
@Boomburum жесть конечно ваши коллеги ущербно себя ведут.
Так, подождите, про письмо от ПОДДЕРЖКИ ХАБРА - это вы серьезно? ЧИВО БЛИН?!
https://share.google/aimode/H3WGmYMQ8sRJjKfq2
Считайте это вместо LMGTFY, вопрос просто действительно странный.