Согласен, смотрел его работы, но кроме PR не видел ничего за что так пиарят. Что-то на уровне блогеров, которые делают примеры на Youtube, только с большим пиаром.
Если уже выше хотят пиарить, то лучше бы писали, что сказал к примеру Yann Lecun, который является одним из пионеров Jepa (в частности VL-Jepa). После того как ушел из Meta, чтобы развивать архитектуру и не зацикливаться на классических LLM. А ведь именно эта архитектура (пусть не в таком виде как сейчас) претендует на замену современным мультимодальным моделям. И полезно услышать аргументы тех, кто развивает архитектуры и ищет альтернативы, а не тот кто смог сделать красивый учебный пример (так как подобного и без него много).
Скепсис к статье оправдан. Когда читаешь такие статьи, то не можешь понять, кто преувеличил: журналисты или авторы работы.
Во первых импульсные сети как пока работали плохо, так и работают не особо. Там архитектурные проблемы, я бы даже сказал скорее не работают чем работают. Так как решают только очень простые задачи вроде фильтров и ни о какой иерархии данных там вообще нет речи. Это относится и к NeuroFEM. Собственно тут можно глянуть что это
Из описания NeuroFEM следует, что алгоритм переводит метод конечных элементов (FEM)
в форму, исполнимую на спайковой нейронной сети (SNN) и запускается на Loihi 2.
То есть речь не о том, что Loihi решает PDE, а о том, что классическая задача FEM (Ax = b) переписана в виде динамической нейронной системы, которая сходится к решению. Это известный подход и многие PDE после дискретизации дают линейную систему Ax=b. Её можно решать как градиентный спуск, релаксационную динамику, дифференциальную систему.
Самая сомнительная часть, что мозг решает PDE на экзафлопсах. Здесь сильное преувеличение, которое дурно пахнет. Про связь с моделью моторной коры 12-летней давности звучит как, была биологическая модель динамики и её переписали в вычислительную форму и поняли, что она реализует релаксационный решатель. Вот это вполне возможно, но явно это не равнозначно фразе "мозг как PDE-машины".
Ну и главное, в статье нет обучения сложной модели. Это даже не обученная SNN, а запрограммированный динамический решатель. По уровню сложности это ближе к линейному фильтру/релаксации, чем к элементарному распознаванию образов. Сеть почти наверняка не обучали.
В задачах типа NeuroFEM происходит следующее, берётся PDE и делается дискретизация методом конечных элементов. Получается линейная система Ax=b. Эта система переписывается как динамика x`=−Ax+b. Эта динамика реализуется через спайковые нейроны. Но это не обучение. Это жёстко заданная архитектура, соответствующая матрице A. Каждый нейрон соответствует узлу сетки. Связи соответствуют коэффициентам FEM. То есть сеть кодирует матрицу, а не обучается её аппроксимировать.
Например, FEM может решать уравнение Пуассона, теплопроводность, простые стационарные PDE и другие мат задачи. Похоже, что они сконфигурировали веса, задали матрицу и запустили динамику.
Это больше похоже на аппаратную реализацию метода Якоби или Гаусса-Зейделя, чем на обучение нейросети.
Какая проблема ввода? Вы понимаете что есть общая задач убрать выбросы из данных. Данные много много тысяч элементов. Данных множество. Мы можем визуализировать или все или участки приблизив. Я привел пример приближенного и в целом одного из наборов данных.
Конечно модель видела кучу данных, и изображений кучу и приближенные и просто наборы данных.
Я не говорю что задача не решается. Я ее решил самостоятельно достаточно успешно, выбрав компромисс. Модели не смогли сами.
Вы и в работе так получаете детально расписанное ТЗ, какие отклонения у него, куда детально вставить, что надо учесть и ли ваша задача проанализировать и исходя из опыта выбрать решение? Если вы детально распишите модели все проблемы, где они могут быть, какие они, и так далее - это и есть решение задачи. Написать 20-100 строк код не проблема вообще, проблема самостоятельно найти решение. Не подогнать решение, а найти решение. Это совершенно разный класс задач.
Если вы дадите задачу решить проблему модели через агентов или не понимая, что она делаете и какой результат будет. Когда это применимо и когда нет. То в итоге вы либо не решите проблему или потратите на нее кучу времени. Но еще хуже то, что вы возможно даже не будете знать о ней, так как "вроде работает" и вы не лезли и не разбирались в коде или не понимаете его. И вам в отчете совсем другие показали, рекомендации в поисковой системе выдают мусор и так далее.
Я уже написал, что в итоге сел и быстро решил эту задачу. Модель самостоятельно не может с ней справиться. Если бы она собирала реальный проект на реальных задах, то просто все запорола бы. Я не говорю про простые проекты, а про серьезные банковские проекты или в аналитические или любой инженерный софт и так далее.
Я не говорю, что LLM бесполезна. Удобная штука для поиска, быстрого wizard кода, когда быстрее описать чем сделать или набросать шаблон и затем его довести до ума. Но ни как самостоятельная система, которая способна написать правильный и серьезный код.
Речь о том, что глядя на глобальные рисунки (а модели их видели), они видят, анализируют их. Но все равно нужно огромное время и детальное описание, куча данных. Как вы себе это представляете, вручную искать все фрагменты и отдавать? Когда человек смотрит, быстро оценивает, продумает и решает. tukey тоже не будет работать нормально по ряду причин. В этом и заключается зада программиста, не написание строчек кода, а решение и код тут вторичен. В реальности решение в том, что надо реализовывать методы правильного подбора параметров для мат методов и модель сама до такого ни у меня, ни у вас сама не додумалась и человеку с опытом это очевидно и еще ряд вещей которые стоит учитывать при реализации. Это к тому что не агентские системы, ни просто LLM не могут решать задачи самостоятельно. Они ближе к Wizard или словесному коду, где ты все детально расписал и дал и она сделала и это допустимо в определенных случаях. То что вы показываете код, вопросы и решения - это на уровне Джуна, который не подумав быстро написал код который "вроде решает", и так и бегает по кругу дорабатывает под каждый чих.
Можно ли подобрать значения? коэф и прочие вещи под эти данные? ну в теории можно. Будет ли это работать на всей траектории? с агентами и просто ллм нет, потому что сам подход хитрее, чтобы работало корректнее. И LLM сама до него не догадывается, а просто пытается применить применить известные методы и меня их настройки. Ну и зачем такое решение, которое умеет считать только 2+2 и не умеет считать 50+22.
Вот пример полной траектории. Это сплайн траектории по сути (визуально). Зачем мне скармливать по каждой точке на куче данных? Зачем мне тогда вообще LMM? Я понимаю как решить задачу, так как в голове у меня есть опыт и я сразу представляю как решать. Но если я подробно опишу это все модели во всех деталях. то это уже будет больше чем самого кода. Смысл сетки, чтобы имея данные суметь решить задачу, а не узкий ее фрагмент. Естественно я пробовал всю задачу решать через сетку. Просто выше приводил ее фрагмент для наглядной визуализации. Какой пример данных скормить? Тысячи. и десятки тысяч данных? Да они в этом случае начинают ломаться, когда их просишь на большом массиве данных расставить их в таблицу, чтобы визуализировать внутри модели. И они легко терять их. Эту задачу можно самостоятельно решить гораздо быстрее.
Речь о том, что вы в проекте не знаете, где именно это произойдет. У вас будет например работа со счетами и аккредитивами, или электронными сообщения, Swift где нужно правильно убирать все. Гонять миллион данных в сетке для теста, чтобы они подобрала? Это так не работает.
И ваш вариант ломается. Дело не в сложности точек. Они все одинаковые. движение про траектории с некоторыми отклонениями, которые надо выбросить, так как они не подходят. Точки могут двигаться с ускорением, поэтому мы не можем выкинуть просто по дистанции, по касательной тоже не вес так просто смотреть так как в расчет может попасть точка выброса и так далее. Там нюансов множество. Модель поберет вам решение под конкретный набор, и хорошо если это будет не какой то x1 < x2 или y1-y2 > 3
и он уже перестает работать. В итоге модель перебрав кучу вариантов решила этот набор данных. Как? если x[i] < x[i-1]... Вы реально хотите, чтобы такой код по-тихому попал в прод?
Попробуйте. RANSAC он мне конечно генерировал. Сейчас сам в принципе сделал.
Мне он на RANSAC генерируем код для этих данных, который делает вот такое. Почему он решил что прямая, почему такие пороги и прочие параметры, не ясно. Поэтому проще писать самому. Так ка потратил много времени, и давал изображения и чаты с нуля и даже сейчас сделал проект с нуля де просто чистые данные массива на вход. Результат один, ерунда. И разбираться с его логикой больше, чем самой в итоге написать. Так как подход должен быть универсальным, а не сломаться на других данных, так как он может просто подобрать параметры под текущие.
Хотя выше, он в итоге подобрал параметры. Но как уже сказал, работать в слепую такое не будет. Ни какие юнит тесты такое не покроют. Тут надо точно понимать что делаешь. И пока не включишь свои мозги, толку от такого подхода. Когда я ему буквально описываю, как решить, что не так.. то это уже тоже самое, что я написал код.
И да, я вспомнил почему этот вариант не работал. Он работал только на этом наборе точек, а меня огромное кол-во данных и он выкидывал важные на других. На 30 точках, когда их скормить то он в итоге решает. В этом и отличие разработки самому и сеткой. которая наделает...
В итоге он мне подобрал параметры. Но это когда ты ему добиваешь, кроме того. когда точно знаешь где проблемы, и надо быть уверенным что это не затыкание дыры. А что будет если он просто генерирует код.
Вам не надоело писать одни и те же статьи. Вот прям буквально простой пример.
Исходная траектория.
Есть траектория движения. Массив точек, надо отсеять выбросы шума.
Я перебрал сейчас все сетки. Все они с умным видом после анализа предложили множество методов, реализовали в итоге каждый их них. Все методы запускаются, ошибок нет. При этом они проанализировали картинку. С умным видом написали.
Вот примерно что они выдают. Какие-то еще сильнее хуже. Но точки не убраны. Выкинула вообще первые точки.
Результат - не один из них не смог удалить точки. Они предложили сделали:
Сглаживание с последующим анализом остатков (Savitzky-Golay Filter + Residual Analysis), Фильтр Хампеля (Hampel Filter), Анализ производных (First/Second Derivative Analysis), RANSAC для робастного подбора модели, Локальная интерполяция с порогом ошибки и еще множество других. Пробовал и Claude, ChatGpt, Qwen, DeepSeek. Ни один не дал нужный результат после выполнения кода. Только извиняются и предлагают дальше. А теперь представьте, вы пишите банковский софт, где логика связанная с аккредитивами, разные счета, разная логика, разные условия и подходы. Или генерация отчетов, которая имеет своеобразную логику. Или анализ данных если это ML. Я не говорю про элементарные задачи, а про те задачи, которые реально встречаются на практике. Что вам на выходе сгенерирует модель?
Запускающийся код? Да. Рабочий код? Нет.
На реальных проектах, это не работает. Вот сижу сейчас и сам правильно делаю расчеты и пишу код для этого. Попытка, чтобы за меня сделал модель, полностью провалилась. Я потратил дофига времени, подумав, что ну с этим сетки должны же справиться. Задача вроде бы простая. Убито на кодо-генерацию полдня. Теперь я знаю, что с этим сетки справиться не могут. И что банковский софт я бы им и близко не доверял бы или генерацию отчетов, если они сложнее уровня Wizard как солянка простых запросов.
1) когда я пишу код, то делаю это на автомате и не задумываюсь. Это как ходить. Я включаю мозг, только в узких местах, где есть сомнения или надо продумать в целом
2) когда я использую нейронки, то приходиться тщательно проверять код. То есть включать мозг на полную, чтобы понять что они делает и правильно или нет.
То есть в случае нейронки я трачу много сил.
Где таких проблем нет? При генерации шаблонного кода, или черновика, базовой структуры. То что многие IDE пытались оптимизировать через wizard формы или графический интерфейс. Сейчас эту роль взяли нейронки.
Например, написать код скачивания датасета и подготовка его в конкретный формат. При том что я знаю что такой датасет есть и какие поля в нем с какими данными. Но если я этого не знаю, сетка может сделать полный бред, который возможно даже заработает, но например данных будет мало, или не так объединит или вообще решит привести их в правильный вид по своему усмотрению (бывает такое).
Поэтому тут неоднозначно. В одних случаях, где много шаблонных простых кирпичиков при создании проекта, агенты/LLM могут ускорить и упростить. А в других, наоборот потратишь гораздо больше времени и сил при их использовании, так как надо будет каждый раз анализировать их код, править или указывать модели что не так, где он снова может сломать изменить.. и через пару часов голова уже не пашет от проверки кода за ней, а на выходе получен монстр калека, который так и не делает задуманного.
Так они не описывают полностью архитектуру реализации. Может там баг, а может они обобщали диалоги с пользователем как память и отправляли в RAG, куда потом лезли при ответа другим. Но если это реально было как описано и стиль для всех (что сомнительно), то больше похоже на баг. Когда запомнили диалог или обобщили его, чтобы потом использовать как RAG.
Вариант, что они обучали потом модель на своих диалогах из поддержки (взяв для дообучения те, где указано "положительно решенные"), и это отразилось на стиле. Или изначально дообучали модель на диалогах с ЖКХ с форума или из реальной поддержки.
Либо в статье написана неправда. Так что тут не понятно, либо статья врет или разработчики допустили баг или накосячили при предобучении.
Но что то мне подсказывает, что это было не у всех пользователей, а у многих, которые ругались матом сразу при обращении или в процессе диалога. Не удивительно, что при обращении в ЖКХ таких диалогов могло быть много. Отсюда и решили, что для "всех".
Вариант, что они это сделали специально - выглядит странно. И за такое могут уволить. Что угодно могло быть - включая вайкодинг, который смешал все диалоги.
Или наоборот объясняет, так как кетский язык "вымер", и вполне вероятно что это одна из причин вымирания. Конечно не единственная, но если брать во внимание, что другие языки при этом еще как-то держаться.
Что касается атабаскских языков, то там упрощенная тональность "высокий/низкий тон".
Это ни сколько не оправдывает, что они плохо вписываются в описание выше. Но, как уже было сказано, это один из важных факторов. Это не означает, что он единственный. Это как вредная мутация, которая может сохраняться, даже при условии, что он вредная, так как позволяет сохранить какие-то полезные свойства. В данном случае, возможность социальных связей для атабаскских языков вполне могут преобладать над негативным влиянием тонального языка в северных широтах.
Как уже было сказано, клики это звуки на вдох приводят к охлаждению гортани и легко заболеть. Тоже касается тонального языка, который требует более длительного контакта с холодным воздухом. Кроме того, было исследование, что в холоде были изменения языка (по-моему в канаде где то) в сторону звонких звуков (не вспомню по памяти точно), так как на холоде отдельные частоты лучше переносились по воздуху и были лучше слышны. Это просто как пример того, что среда меняет звучание языка из за температуры. а когда она сильно влияет на подверженность простуде бронхов, то те кто будут использовать такой подход просто вымрут постепенно в холодном климате.
Тут все проще, модель скопировала стиль пользователя и продолжила отвечать в этом стиле. Чем дальше диалог, тем меньше влияет системный промпт. Это обходиться, но в большинстве компаний с которыми я общался, ни кто всерьез эту проблему не решает. Частично она может снизиться если агент будет предварительно обобщать вопрос или разбивать его на части. Так что, если долго вести диалог с агентскими чатами, они рано или поздно начнут копировать стиль пользователя. Просто в ЖКХ этот стиль явно сильно отличается от нейтрального.
Старые спайковые SNN должны умереть. Они не выстрелят, так как имеют слабое отношение к спайковым и поэтому почти не обучаются (если это можно вообще назвать обучение). В случае случае SNN реализуют фильтры, а не спайковые сети, там где их и применяют как детекторы.
А так да, при правильной реализации спайковая сеть, я ее пример обучения показал выше, отлично обучается на GPU. Даже может выигрывать у классических по ресурсоемкости, так как работает только с сигналами, которые образовали спайки. Это приводит к тому, что кол-во арифметических операций уменьшается.
Вот пример обучения при правильной реализации спайковой сети и сравнение с SNN.
Сейчас готовлю статью об этом, если кратко то часть динамики это цепь Маркова, разрыв цепи по порогу (https://t.me/greenruff/2462) описываемому размерностью пространства состояний - спайк. В остальном нейрон представляет собой Марковское одеяло, что накладывает требования на вход и выход. Ну а сама динамика нейрона происходит в лог пространстве, поэтому цепь Маркова представляет собой сложение, а не произведение. Это если совсем грубо и кратко. Так что ответ - да, на GPU это работает при правильной реализации.
Так проблема мультимодальных модулей в том, что в них каждая модальность по большому счету живёт своей жизнью.
В той же jepa, которую сейчас на западе рассматривают как следующий шаг, работает с мультимодальностью в специальном латентном пространстве. Которое уже и выдает данные через декодер. А текущие мультимодальные модели используют латентное пространство только как дополнение (и то не все), а прогноз в итоге делает отдельно текстовая или графическая модель. В случае jepa, в латентном "абстрактном" пространстве мы находим устойчивые связи. Там не анализируются пиксели для распознавания или общие детали. Там модель находить абстрактные связи, образно говоря модель видит что "скелет" соответствует животному, пейзаж "Африке" как сущности, морда ещё кому-то и так далее. И уже на выходе скажет, что это собака (через декодер в текст), а может ничего не сказать или что не знает. То есть это как если бы мы распознавали не по пикселям, а по общей "логике" абстрактной в целом. Для нас отдельные пиксели и детали в этом случае просто шум.
Согласен, смотрел его работы, но кроме PR не видел ничего за что так пиарят. Что-то на уровне блогеров, которые делают примеры на Youtube, только с большим пиаром.
Если уже выше хотят пиарить, то лучше бы писали, что сказал к примеру Yann Lecun, который является одним из пионеров Jepa (в частности VL-Jepa). После того как ушел из Meta, чтобы развивать архитектуру и не зацикливаться на классических LLM. А ведь именно эта архитектура (пусть не в таком виде как сейчас) претендует на замену современным мультимодальным моделям. И полезно услышать аргументы тех, кто развивает архитектуры и ищет альтернативы, а не тот кто смог сделать красивый учебный пример (так как подобного и без него много).
Скепсис к статье оправдан. Когда читаешь такие статьи, то не можешь понять, кто преувеличил: журналисты или авторы работы.
Во первых импульсные сети как пока работали плохо, так и работают не особо. Там архитектурные проблемы, я бы даже сказал скорее не работают чем работают. Так как решают только очень простые задачи вроде фильтров и ни о какой иерархии данных там вообще нет речи. Это относится и к NeuroFEM. Собственно тут можно глянуть что это
https://github.com/sandialabs/NeuroFEM/blob/main/NeuroFEM.ipynb
Из описания NeuroFEM следует, что алгоритм переводит метод конечных элементов (FEM)
в форму, исполнимую на спайковой нейронной сети (SNN) и запускается на Loihi 2.
То есть речь не о том, что Loihi решает PDE, а о том, что классическая задача FEM (Ax = b) переписана в виде динамической нейронной системы, которая сходится к решению. Это известный подход и многие PDE после дискретизации дают линейную систему Ax=b. Её можно решать как градиентный спуск, релаксационную динамику, дифференциальную систему.
Самая сомнительная часть, что мозг решает PDE на экзафлопсах. Здесь сильное преувеличение, которое дурно пахнет. Про связь с моделью моторной коры 12-летней давности звучит как, была биологическая модель динамики и её переписали в вычислительную форму и поняли, что она реализует релаксационный решатель. Вот это вполне возможно, но явно это не равнозначно фразе "мозг как PDE-машины".
Ну и главное, в статье нет обучения сложной модели. Это даже не обученная SNN, а запрограммированный динамический решатель. По уровню сложности это ближе к линейному фильтру/релаксации, чем к элементарному распознаванию образов. Сеть почти наверняка не обучали.
В задачах типа NeuroFEM происходит следующее, берётся PDE и делается дискретизация методом конечных элементов. Получается линейная система Ax=b. Эта система переписывается как динамика x`=−Ax+b. Эта динамика реализуется через спайковые нейроны. Но это не обучение. Это жёстко заданная архитектура, соответствующая матрице A. Каждый нейрон соответствует узлу сетки. Связи соответствуют коэффициентам FEM. То есть сеть кодирует матрицу, а не обучается её аппроксимировать.
Например, FEM может решать уравнение Пуассона, теплопроводность, простые стационарные PDE и другие мат задачи. Похоже, что они сконфигурировали веса, задали матрицу и запустили динамику.
Это больше похоже на аппаратную реализацию метода Якоби или Гаусса-Зейделя, чем на обучение нейросети.
Какая проблема ввода? Вы понимаете что есть общая задач убрать выбросы из данных. Данные много много тысяч элементов. Данных множество. Мы можем визуализировать или все или участки приблизив. Я привел пример приближенного и в целом одного из наборов данных.
Конечно модель видела кучу данных, и изображений кучу и приближенные и просто наборы данных.
Я не говорю что задача не решается. Я ее решил самостоятельно достаточно успешно, выбрав компромисс. Модели не смогли сами.
Вы и в работе так получаете детально расписанное ТЗ, какие отклонения у него, куда детально вставить, что надо учесть и ли ваша задача проанализировать и исходя из опыта выбрать решение? Если вы детально распишите модели все проблемы, где они могут быть, какие они, и так далее - это и есть решение задачи. Написать 20-100 строк код не проблема вообще, проблема самостоятельно найти решение. Не подогнать решение, а найти решение. Это совершенно разный класс задач.
Если вы дадите задачу решить проблему модели через агентов или не понимая, что она делаете и какой результат будет. Когда это применимо и когда нет. То в итоге вы либо не решите проблему или потратите на нее кучу времени. Но еще хуже то, что вы возможно даже не будете знать о ней, так как "вроде работает" и вы не лезли и не разбирались в коде или не понимаете его. И вам в отчете совсем другие показали, рекомендации в поисковой системе выдают мусор и так далее.
Я уже написал, что в итоге сел и быстро решил эту задачу. Модель самостоятельно не может с ней справиться. Если бы она собирала реальный проект на реальных задах, то просто все запорола бы. Я не говорю про простые проекты, а про серьезные банковские проекты или в аналитические или любой инженерный софт и так далее.
Я не говорю, что LLM бесполезна. Удобная штука для поиска, быстрого wizard кода, когда быстрее описать чем сделать или набросать шаблон и затем его довести до ума. Но ни как самостоятельная система, которая способна написать правильный и серьезный код.
Речь о том, что глядя на глобальные рисунки (а модели их видели), они видят, анализируют их. Но все равно нужно огромное время и детальное описание, куча данных. Как вы себе это представляете, вручную искать все фрагменты и отдавать? Когда человек смотрит, быстро оценивает, продумает и решает.
tukeyтоже не будет работать нормально по ряду причин. В этом и заключается зада программиста, не написание строчек кода, а решение и код тут вторичен. В реальности решение в том, что надо реализовывать методы правильного подбора параметров для мат методов и модель сама до такого ни у меня, ни у вас сама не додумалась и человеку с опытом это очевидно и еще ряд вещей которые стоит учитывать при реализации. Это к тому что не агентские системы, ни просто LLM не могут решать задачи самостоятельно. Они ближе к Wizard или словесному коду, где ты все детально расписал и дал и она сделала и это допустимо в определенных случаях. То что вы показываете код, вопросы и решения - это на уровне Джуна, который не подумав быстро написал код который "вроде решает", и так и бегает по кругу дорабатывает под каждый чих.Он ломается на других данных. Но да, я его использую, но только более хитро. Хотя сейчас переписываю на другой подход, так как он тоже не выдерживает.
То есть проблема не подобрать под конкретный интервал значений. Проблема в том, что это будет ломаться на других, когда они сломают нормальные данные.
Скрытый текст
[[-0.06696627 0.06516338]
[-0.03489703 -0.26608484]
[ 0.04749564 -0.39843422]
[ 0.10074646 -0.12782019]
[ 0.10338986 0.38532736]
[ 0.05373366 0.88471337]
[ 0.00474008 1.1177341 ]
[-0.01937724 1.12247418]
[-0.06348366 1.02324915]
[-0.09659275 0.68680767]
[-0.11325134 0.19304749]
[-0.11294483 -0.37577133]
[-0.09286917 -0.93361529]
[-0.05158771 -1.38051125]
[-0.01070006 -1.61036378]
[ 0.01432249 -1.62106384]
[ 0.06191423 -1.54072795]
[ 0.09954657 -1.20981633]
[ 0.11936263 -0.69943307]
[ 0.12048324 -0.09911078]
[ 0.09953754 0.49634622]
[ 0.04564962 0.97534513]
[ 0.01758727 1.1956814 ]
[-0.00218539 1.23085593]
[-0.06018518 1.20630136]
[-0.11794497 0.87041962]
[-0.13422892 0.2662691 ]
[-0.10773771 -0.39832407]
[-0.0365943 -0.90806878]
[ 0.00379152 -1.05444599]]
Скрытый текст
[[ 0.11547587 -3.51388294]
[ 0.12941082 -2.9291204 ]
[ 0.14057426 -2.27606886]
[ 0.1489268 -1.56858588]
[ 0.15303102 -0.82106067]
[ 0.15148317 -0.05583759]
[ 0.14547436 0.69907023]
[ 0.13623506 1.42230187]
[ 0.12379899 2.09773865]
[ 0.10816615 2.7093967 ]
[ 0.08945534 3.24129216]
[ 0.0692831 3.67856503]
[ 0.04938572 4.01490526]
[ 0.03033934 4.25218257]
[ 0.01214696 4.39465499]
[-0.00518489 4.44659248]
[-0.02161408 4.41231612]
[-0.03712702 4.29635149]
[-0.05153704 4.10330442]
[-0.06426933 3.83891352]
[-0.07375026 3.51226877]
[-0.07951361 3.14007816]
[-0.08155718 2.74092961]
[-0.06014731 2.33344058]
[-0.05727865 2.01423642]
[-0.06996945 1.71134728]
[-0.0609416 1.36571018]
[-0.04988847 1.06622498]
[-0.03681007 0.82301804]
[-0.014328 0.64621575]]
Скрытый текст
[[-7.27760962e-02 -6.86302929e+00]
[-7.07112410e-02 -7.22588903e+00]
[-6.85684812e-02 -7.57838554e+00]
[-6.63478168e-02 -7.92012930e+00]
[-6.40492480e-02 -8.25073078e+00]
[-6.16727746e-02 -8.56980047e+00]
[-5.92183966e-02 -8.87694884e+00]
[-5.66861141e-02 -9.17178637e+00]
[-5.40759271e-02 -9.45392353e+00]
[-5.13878355e-02 -9.72297080e+00]
[-4.86218393e-02 -9.97853867e+00]
[-4.57779387e-02 -1.02202376e+01]
[-4.28561335e-02 -1.04476781e+01]
[-3.98564237e-02 -1.06604706e+01]
[-3.67853531e-02 -1.08582256e+01]
[-3.36850466e-02 -1.10406047e+01]
[-3.05681826e-02 -1.12074740e+01]
[-2.74347611e-02 -1.13587506e+01]
[-2.42847820e-02 -1.14943519e+01]
[-2.11182455e-02 -1.16141951e+01]
[-1.79351515e-02 -1.17181972e+01]
[-1.47354999e-02 -1.18062756e+01]
[-8.88138750e-03 -1.18783475e+01]
[-6.94371445e-03 -1.19244247e+01]
[-6.33891670e-03 -1.19601623e+01]
[-3.07965812e-03 -1.19902297e+01]
[-4.60660988e-04 -1.20039926e+01]
[ 8.52988672e-04 -1.20049139e+01]
[ 3.49000658e-03 -1.20013679e+01]
[ 5.09914958e-03 -1.19822634e+01]]
Можно ли подобрать значения? коэф и прочие вещи под эти данные? ну в теории можно. Будет ли это работать на всей траектории? с агентами и просто ллм нет, потому что сам подход хитрее, чтобы работало корректнее. И LLM сама до него не догадывается, а просто пытается применить применить известные методы и меня их настройки. Ну и зачем такое решение, которое умеет считать только 2+2 и не умеет считать 50+22.
Вот пример полной траектории. Это сплайн траектории по сути (визуально). Зачем мне скармливать по каждой точке на куче данных? Зачем мне тогда вообще LMM? Я понимаю как решить задачу, так как в голове у меня есть опыт и я сразу представляю как решать. Но если я подробно опишу это все модели во всех деталях. то это уже будет больше чем самого кода. Смысл сетки, чтобы имея данные суметь решить задачу, а не узкий ее фрагмент. Естественно я пробовал всю задачу решать через сетку. Просто выше приводил ее фрагмент для наглядной визуализации. Какой пример данных скормить? Тысячи. и десятки тысяч данных? Да они в этом случае начинают ломаться, когда их просишь на большом массиве данных расставить их в таблицу, чтобы визуализировать внутри модели. И они легко терять их. Эту задачу можно самостоятельно решить гораздо быстрее.
Речь о том, что вы в проекте не знаете, где именно это произойдет. У вас будет например работа со счетами и аккредитивами, или электронными сообщения, Swift где нужно правильно убирать все. Гонять миллион данных в сетке для теста, чтобы они подобрала? Это так не работает.
Теперь проверьте его на другом наборе точек. Ведь он может быть разным.
Скрытый текст
points = np.array([ [-1.56019764e-03, -3.40385927e-01], [-1.44440314e-03, -3.48129496e-01], [-1.32541753e-03, -3.55292498e-01], [-1.20324081e-03, -3.61858976e-01], [-1.07787299e-03, -3.67812975e-01], [-9.49314052e-04, -3.73138539e-01], [-8.17564010e-04, -3.77819713e-01], [-6.82622859e-04, -3.81840541e-01], [-5.44490600e-04, -3.85185068e-01], [-4.03167233e-04, -3.87837338e-01], [-2.58652757e-04, -3.89781395e-01], [-1.10947458e-04, -3.91001285e-01], [-5.75605629e-06, -3.91481060e-01], [ 5.51054351e-05, -3.91486816e-01], [ 1.93754893e-04, -3.91205130e-01], [ 3.50639316e-04, -3.90158367e-01], [ 5.10543332e-04, -3.88325671e-01], [ 6.73466940e-04, -3.85691945e-01], [ 8.39410140e-04, -3.82242092e-01], [ 1.00837293e-03, -3.77961013e-01], [ 1.18035532e-03, -3.72833610e-01], [ 1.35535730e-03, -3.66844785e-01], [ 1.53337887e-03, -3.59979441e-01], [ 1.27210860e-03, -3.52222479e-01], [ 1.38218270e-03, -3.45364799e-01], [ 2.01036664e-03, -3.37919091e-01], [ 2.19925875e-03, -3.27773264e-01], [ 2.39116458e-03, -3.16681468e-01], [ 2.58462674e-03, -3.04628790e-01], [ 1.99626036e-03, -2.91609613e-01]])
И ваш вариант ломается. Дело не в сложности точек. Они все одинаковые. движение про траектории с некоторыми отклонениями, которые надо выбросить, так как они не подходят. Точки могут двигаться с ускорением, поэтому мы не можем выкинуть просто по дистанции, по касательной тоже не вес так просто смотреть так как в расчет может попасть точка выброса и так далее. Там нюансов множество. Модель поберет вам решение под конкретный набор, и хорошо если это будет не какой то x1 < x2 или y1-y2 > 3
И да, теперь прогоните ваш метод через эти точки:
Скрытый текст
points = np.array([ [-1.56019764e-03, -3.40385927e-01], [-1.44440314e-03, -3.48129496e-01], [-1.32541753e-03, -3.55292498e-01], [-1.20324081e-03, -3.61858976e-01], [-1.07787299e-03, -3.67812975e-01], [-9.49314052e-04, -3.73138539e-01], [-8.17564010e-04, -3.77819713e-01], [-6.82622859e-04, -3.81840541e-01], [-5.44490600e-04, -3.85185068e-01], [-4.03167233e-04, -3.87837338e-01], [-2.58652757e-04, -3.89781395e-01], [-1.10947458e-04, -3.91001285e-01], [-5.75605629e-06, -3.91481060e-01], [ 5.51054351e-05, -3.91486816e-01], [ 1.93754893e-04, -3.91205130e-01], [ 3.50639316e-04, -3.90158367e-01], [ 5.10543332e-04, -3.88325671e-01], [ 6.73466940e-04, -3.85691945e-01], [ 8.39410140e-04, -3.82242092e-01], [ 1.00837293e-03, -3.77961013e-01], [ 1.18035532e-03, -3.72833610e-01], [ 1.35535730e-03, -3.66844785e-01], [ 1.53337887e-03, -3.59979441e-01], [ 1.27210860e-03, -3.52222479e-01], [ 1.38218270e-03, -3.45364799e-01], [ 2.01036664e-03, -3.37919091e-01], [ 2.19925875e-03, -3.27773264e-01], [ 2.39116458e-03, -3.16681468e-01], [ 2.58462674e-03, -3.04628790e-01], [ 1.99626036e-03, -2.91609613e-01]])
и он уже перестает работать. В итоге модель перебрав кучу вариантов решила этот набор данных. Как? если x[i] < x[i-1]... Вы реально хотите, чтобы такой код по-тихому попал в прод?
Буквально на других данных RANSAC уже работать не будет. Задача де не выбросить конкретно точки из данной кривой, а из любой.
Выше скинул пример последних 30 точек. Продублирую.
Скрытый текст
[[ 2.35145966e-04 8.87099491e+01]
[ 5.31358478e-05 8.87110337e+01]
[-1.28013995e-04 8.87112086e+01]
[-3.08303561e-04 8.87104783e+01]
[-4.87732851e-04 8.87088469e+01]
[-6.66301866e-04 8.87063189e+01]
[-8.44010604e-04 8.87028984e+01]
[-1.02085907e-03 8.86985898e+01]
[-1.19684725e-03 8.86933973e+01]
[-1.37197516e-03 8.86873254e+01]
[-1.54624280e-03 8.86803783e+01]
[-1.71965016e-03 8.86725602e+01]
[-1.89219695e-03 8.86638756e+01]
[-2.06382459e-03 8.86543286e+01]
[-2.23442815e-03 8.86439240e+01]
[-2.40399991e-03 8.86326670e+01]
[-2.57253989e-03 8.86205625e+01]
[-2.74004807e-03 8.86076159e+01]
[-2.90652446e-03 8.85938323e+01]
[-3.07196906e-03 8.85792168e+01]
[-3.23638187e-03 8.85637746e+01]
[-3.39976289e-03 8.85475108e+01]
[-3.56211211e-03 8.85304307e+01]
[-2.78051720e-03 8.85125393e+01]
[-2.87681240e-03 8.84976456e+01]
[-3.97939130e-03 8.84822386e+01]
[-4.13802608e-03 8.84622622e+01]
[-4.29562906e-03 8.84414931e+01]
[-4.45220024e-03 8.84199365e+01]
[-3.30230097e-03 8.83975976e+01]]
Попробуйте. RANSAC он мне конечно генерировал. Сейчас сам в принципе сделал.
Мне он на RANSAC генерируем код для этих данных, который делает вот такое. Почему он решил что прямая, почему такие пороги и прочие параметры, не ясно. Поэтому проще писать самому. Так ка потратил много времени, и давал изображения и чаты с нуля и даже сейчас сделал проект с нуля де просто чистые данные массива на вход. Результат один, ерунда. И разбираться с его логикой больше, чем самой в итоге написать. Так как подход должен быть универсальным, а не сломаться на других данных, так как он может просто подобрать параметры под текущие.
Хотя выше, он в итоге подобрал параметры. Но как уже сказал, работать в слепую такое не будет. Ни какие юнит тесты такое не покроют. Тут надо точно понимать что делаешь. И пока не включишь свои мозги, толку от такого подхода. Когда я ему буквально описываю, как решить, что не так.. то это уже тоже самое, что я написал код.
И да, я вспомнил почему этот вариант не работал. Он работал только на этом наборе точек, а меня огромное кол-во данных и он выкидывал важные на других. На 30 точках, когда их скормить то он в итоге решает. В этом и отличие разработки самому и сеткой. которая наделает...
Пробовал разные версии. Вот пример 30 точек. Порядок важен.
Скрытый текст
[[ 2.35145966e-04 8.87099491e+01]
[ 5.31358478e-05 8.87110337e+01]
[-1.28013995e-04 8.87112086e+01]
[-3.08303561e-04 8.87104783e+01]
[-4.87732851e-04 8.87088469e+01]
[-6.66301866e-04 8.87063189e+01]
[-8.44010604e-04 8.87028984e+01]
[-1.02085907e-03 8.86985898e+01]
[-1.19684725e-03 8.86933973e+01]
[-1.37197516e-03 8.86873254e+01]
[-1.54624280e-03 8.86803783e+01]
[-1.71965016e-03 8.86725602e+01]
[-1.89219695e-03 8.86638756e+01]
[-2.06382459e-03 8.86543286e+01]
[-2.23442815e-03 8.86439240e+01]
[-2.40399991e-03 8.86326670e+01]
[-2.57253989e-03 8.86205625e+01]
[-2.74004807e-03 8.86076159e+01]
[-2.90652446e-03 8.85938323e+01]
[-3.07196906e-03 8.85792168e+01]
[-3.23638187e-03 8.85637746e+01]
[-3.39976289e-03 8.85475108e+01]
[-3.56211211e-03 8.85304307e+01]
[-2.78051720e-03 8.85125393e+01]
[-2.87681240e-03 8.84976456e+01]
[-3.97939130e-03 8.84822386e+01]
[-4.13802608e-03 8.84622622e+01]
[-4.29562906e-03 8.84414931e+01]
[-4.45220024e-03 8.84199365e+01]
[-3.30230097e-03 8.83975976e+01]]
В итоге он мне подобрал параметры. Но это когда ты ему добиваешь, кроме того. когда точно знаешь где проблемы, и надо быть уверенным что это не затыкание дыры. А что будет если он просто генерирует код.
Вам не надоело писать одни и те же статьи. Вот прям буквально простой пример.
Есть траектория движения. Массив точек, надо отсеять выбросы шума.
Я перебрал сейчас все сетки. Все они с умным видом после анализа предложили множество методов, реализовали в итоге каждый их них. Все методы запускаются, ошибок нет. При этом они проанализировали картинку. С умным видом написали.
Результат - не один из них не смог удалить точки. Они предложили сделали:
Сглаживание с последующим анализом остатков (Savitzky-Golay Filter + Residual Analysis), Фильтр Хампеля (Hampel Filter), Анализ производных (First/Second Derivative Analysis), RANSAC для робастного подбора модели, Локальная интерполяция с порогом ошибки и еще множество других. Пробовал и Claude, ChatGpt, Qwen, DeepSeek.
Ни один не дал нужный результат после выполнения кода. Только извиняются и предлагают дальше.
А теперь представьте, вы пишите банковский софт, где логика связанная с аккредитивами, разные счета, разная логика, разные условия и подходы. Или генерация отчетов, которая имеет своеобразную логику. Или анализ данных если это ML. Я не говорю про элементарные задачи, а про те задачи, которые реально встречаются на практике. Что вам на выходе сгенерирует модель?
Запускающийся код? Да.
Рабочий код? Нет.
На реальных проектах, это не работает. Вот сижу сейчас и сам правильно делаю расчеты и пишу код для этого. Попытка, чтобы за меня сделал модель, полностью провалилась. Я потратил дофига времени, подумав, что ну с этим сетки должны же справиться. Задача вроде бы простая. Убито на кодо-генерацию полдня. Теперь я знаю, что с этим сетки справиться не могут. И что банковский софт я бы им и близко не доверял бы или генерацию отчетов, если они сложнее уровня Wizard как солянка простых запросов.
Все авторы упускают следующее. На своем примере:
1) когда я пишу код, то делаю это на автомате и не задумываюсь. Это как ходить. Я включаю мозг, только в узких местах, где есть сомнения или надо продумать в целом
2) когда я использую нейронки, то приходиться тщательно проверять код. То есть включать мозг на полную, чтобы понять что они делает и правильно или нет.
То есть в случае нейронки я трачу много сил.
Где таких проблем нет? При генерации шаблонного кода, или черновика, базовой структуры. То что многие IDE пытались оптимизировать через wizard формы или графический интерфейс. Сейчас эту роль взяли нейронки.
Например, написать код скачивания датасета и подготовка его в конкретный формат. При том что я знаю что такой датасет есть и какие поля в нем с какими данными. Но если я этого не знаю, сетка может сделать полный бред, который возможно даже заработает, но например данных будет мало, или не так объединит или вообще решит привести их в правильный вид по своему усмотрению (бывает такое).
Поэтому тут неоднозначно. В одних случаях, где много шаблонных простых кирпичиков при создании проекта, агенты/LLM могут ускорить и упростить. А в других, наоборот потратишь гораздо больше времени и сил при их использовании, так как надо будет каждый раз анализировать их код, править или указывать модели что не так, где он снова может сломать изменить.. и через пару часов голова уже не пашет от проверки кода за ней, а на выходе получен монстр калека, который так и не делает задуманного.
Так они не описывают полностью архитектуру реализации. Может там баг, а может они обобщали диалоги с пользователем как память и отправляли в RAG, куда потом лезли при ответа другим. Но если это реально было как описано и стиль для всех (что сомнительно), то больше похоже на баг. Когда запомнили диалог или обобщили его, чтобы потом использовать как RAG.
Вариант, что они обучали потом модель на своих диалогах из поддержки (взяв для дообучения те, где указано "положительно решенные"), и это отразилось на стиле. Или изначально дообучали модель на диалогах с ЖКХ с форума или из реальной поддержки.
Либо в статье написана неправда. Так что тут не понятно, либо статья врет или разработчики допустили баг или накосячили при предобучении.
Но что то мне подсказывает, что это было не у всех пользователей, а у многих, которые ругались матом сразу при обращении или в процессе диалога. Не удивительно, что при обращении в ЖКХ таких диалогов могло быть много. Отсюда и решили, что для "всех".
Вариант, что они это сделали специально - выглядит странно. И за такое могут уволить. Что угодно могло быть - включая вайкодинг, который смешал все диалоги.
Или наоборот объясняет, так как кетский язык "вымер", и вполне вероятно что это одна из причин вымирания. Конечно не единственная, но если брать во внимание, что другие языки при этом еще как-то держаться.
Что касается атабаскских языков, то там упрощенная тональность "высокий/низкий тон".
Это ни сколько не оправдывает, что они плохо вписываются в описание выше. Но, как уже было сказано, это один из важных факторов. Это не означает, что он единственный. Это как вредная мутация, которая может сохраняться, даже при условии, что он вредная, так как позволяет сохранить какие-то полезные свойства. В данном случае, возможность социальных связей для атабаскских языков вполне могут преобладать над негативным влиянием тонального языка в северных широтах.
Как уже было сказано, клики это звуки на вдох приводят к охлаждению гортани и легко заболеть. Тоже касается тонального языка, который требует более длительного контакта с холодным воздухом. Кроме того, было исследование, что в холоде были изменения языка (по-моему в канаде где то) в сторону звонких звуков (не вспомню по памяти точно), так как на холоде отдельные частоты лучше переносились по воздуху и были лучше слышны. Это просто как пример того, что среда меняет звучание языка из за температуры. а когда она сильно влияет на подверженность простуде бронхов, то те кто будут использовать такой подход просто вымрут постепенно в холодном климате.
Тут все проще, модель скопировала стиль пользователя и продолжила отвечать в этом стиле. Чем дальше диалог, тем меньше влияет системный промпт. Это обходиться, но в большинстве компаний с которыми я общался, ни кто всерьез эту проблему не решает. Частично она может снизиться если агент будет предварительно обобщать вопрос или разбивать его на части. Так что, если долго вести диалог с агентскими чатами, они рано или поздно начнут копировать стиль пользователя. Просто в ЖКХ этот стиль явно сильно отличается от нейтрального.
Обучение этой спайковой сети было на GPU и работают они на GPU. Но это не SNN архитектура.
Старые спайковые SNN должны умереть. Они не выстрелят, так как имеют слабое отношение к спайковым и поэтому почти не обучаются (если это можно вообще назвать обучение). В случае случае SNN реализуют фильтры, а не спайковые сети, там где их и применяют как детекторы.
А так да, при правильной реализации спайковая сеть, я ее пример обучения показал выше, отлично обучается на GPU. Даже может выигрывать у классических по ресурсоемкости, так как работает только с сигналами, которые образовали спайки. Это приводит к тому, что кол-во арифметических операций уменьшается.
Вот пример обучения при правильной реализации спайковой сети и сравнение с SNN.
https://t.me/greenruff/2564
Сейчас готовлю статью об этом, если кратко то часть динамики это цепь Маркова, разрыв цепи по порогу (https://t.me/greenruff/2462) описываемому размерностью пространства состояний - спайк. В остальном нейрон представляет собой Марковское одеяло, что накладывает требования на вход и выход. Ну а сама динамика нейрона происходит в лог пространстве, поэтому цепь Маркова представляет собой сложение, а не произведение. Это если совсем грубо и кратко. Так что ответ - да, на GPU это работает при правильной реализации.
Так проблема мультимодальных модулей в том, что в них каждая модальность по большому счету живёт своей жизнью.
В той же jepa, которую сейчас на западе рассматривают как следующий шаг, работает с мультимодальностью в специальном латентном пространстве. Которое уже и выдает данные через декодер. А текущие мультимодальные модели используют латентное пространство только как дополнение (и то не все), а прогноз в итоге делает отдельно текстовая или графическая модель. В случае jepa, в латентном "абстрактном" пространстве мы находим устойчивые связи. Там не анализируются пиксели для распознавания или общие детали. Там модель находить абстрактные связи, образно говоря модель видит что "скелет" соответствует животному, пейзаж "Африке" как сущности, морда ещё кому-то и так далее. И уже на выходе скажет, что это собака (через декодер в текст), а может ничего не сказать или что не знает. То есть это как если бы мы распознавали не по пикселям, а по общей "логике" абстрактной в целом. Для нас отдельные пиксели и детали в этом случае просто шум.
Так что, тут разный подход на уровне архитектуры.
А дальше мы перейдем к спайковым сеткам или jepa. И история с обещанием AGI повторится по новой))
Если их правильно реализовать, то они уделывают классические SOTA реализации и по стабильности и по качеству.
А так , классическим мульимодальным моделям на замену так же идёт новая архитектура jepa (условно новая). Где совсем другой подход.
Так что история про убытки это ещё на долго с нами.