И ваш вариант ломается. Дело не в сложности точек. Они все одинаковые. движение про траектории с некоторыми отклонениями, которые надо выбросить, так как они не подходят. Точки могут двигаться с ускорением, поэтому мы не можем выкинуть просто по дистанции, по касательной тоже не вес так просто смотреть так как в расчет может попасть точка выброса и так далее. Там нюансов множество. Модель поберет вам решение под конкретный набор, и хорошо если это будет не какой то 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, в латентном "абстрактном" пространстве мы находим устойчивые связи. Там не анализируются пиксели для распознавания или общие детали. Там модель находить абстрактные связи, образно говоря модель видит что "скелет" соответствует животному, пейзаж "Африке" как сущности, морда ещё кому-то и так далее. И уже на выходе скажет, что это собака (через декодер в текст), а может ничего не сказать или что не знает. То есть это как если бы мы распознавали не по пикселям, а по общей "логике" абстрактной в целом. Для нас отдельные пиксели и детали в этом случае просто шум.
Здесь интересный момент был в том, что переход к нетональному явно прослеживается с переходом в холодный климат. (Там и другие есть исследования других лабораторий).
В частности, клики у африканских народов исчезают, когда мы смещаемся в холодный климат. Так как клики это "речь" на вдохе. Аналогично тональный язык это грубо говоря речь "песня", а открывать часто рот в холод чревато восполнением лёгких или трахеи.
Интересно, есть ли исследования, где связь речи и заболеваний. Поговорил много в холод и организм ослаб или простыл.
А дальше уже заразил остальных: было исследование о распространении болезни на основе метода 6 рукопожатий (условно, точно не помню название). Там было, что уже заражённый быстро разносит болезнь на всю популяцию без изоляции, за 24 дня вроде (не вспомню). Его используют при прогнозировании времени роста эпидемии.
Если хотите улучшить озвучку, то рекомендую синтезировать не все сразу. В этом случае модели часто плохо справляются с этим. А разбивать текст на синтагмы. Это не панацея, но улучшает качество.э, так как делает речь более живой.
Тут с синтезом было сложнее. Так как задача была управлять эмоциями, но большую роль так играет именно синтез по частям - синтагмам. В этом случае нет длинных синтезированных фраз. При этом управляя скоростью озвучки через тон и громкость, вы меняете эмоциональный окрас.
В этом случае получаем более человеческий вариант речи. Мозг не устает тогда. По стандартных синтезах, без данного подхода, через 1-2 дня начинаешь слышать разницу.
Сейчас правда есть уже модели вроде с возможностью задать эмоции, поэтому задача упрощается. Но даже там, для улучшения качества, текст для синтез надо резать на синтагмы.
Это так, если вы решите развить качество синтеза речи.
Сам подход тот же, что и для тензорных датчиков. Только тут были специально разработанные сплавы на основе галлия, с сопротивлением близком к меди. Сама технология относительно дешёвая.
Проблема на тот момент была в том, что по сути это не особо было нужно. Рынок только только появляется.
Но идея было в том, чтобы прикрутить через нейронки "кожу".
Уже тогда во всех странах велись работы над этим. Германия, США, Китай, Япония - основные страны работающие над этим. С учётом того, как сейчас в Китае развивается робототехника, думаю там первым и выстрелит это.
Свое же оборудование, которое сделали, так и лежит в гараже. Увы..
Слабое исследование. Вместо того, чтобы использовать мат. статистику, пытаются искусственно вводить правила. Данный подход не будет учитывать динамику языка, его заимствования и прочие вещи. Правила конечно лучше чем BPE, но фактически и там и там используется просто частотный подход.
Хотите реально качественный скачек в токенизации, а не эти извращения, то надо рассматривать текст как условные вероятности, которые формируют цепи Маркова и собирать статистику по цепям Маркова, а не по частотным слияниям букв.
В данном случае, даже уже всего на 1000 примерах обучения разница будет огромная. И чем дальше обучение, тем сильнее эта разница заметнее. BPE и подход выше, так и будет оставаться в рамках частотных (случайных токенов), где модель пытается это исправить через обучение. И мы долго будем видеть шум и высокочастотные токены. В то время как при правильном подходе, даже на первых 100-400 примерах сразу будет видна разница и первые формирования устойчивых правил. Так как все эти правила и так собраны в статистику наиболее вероятных Марковских цепей.
То что вы написали, это и есть цепь Маркова. Только в статье извращенный способ попытки встроить ее к токенизатор. Не важно на одном уровне блоков или нескольких или только в начале.
Связка "Александр" + "Македонский" это и есть условная вероятность, которая присуща цепи Маркова, а три "слова" в вашем случае это цепь из трех элементов.
Какой-то извращенный способ. Все эти последовательности "внутренней дополнительной архитектуры", как цепи можно получить и так на основе сбора статистики.
Длина слова регулируется через длину цепи Маркова. Больше чувствительность больше статистика для токенизации. Описывал это тут https://t.me/greenruff/2483
Классический подход BPE и любых ngramm, построенный на частотности.
при правильной токенизации, когда вместо частотности (маргинальные вероятности) мы используем условные вероятности при построении токенов, хоть на первичном, хоть на после каждого блока дополнительно.
И тогда, если выкинуть частотный подход. который вообще чудом работает в языковым моделях из-за их пластичности, а правильно собирать статистику, то мы можем строить правильно и токенизатор и правильно вставлять его между уровнями, а не как в статье через "извращенный прием".
Вместо того, чтобы изобретать костыли как описано выше, почему ни кто не делает R&D, почему вообще так с точки зрения математики. Такая реализация вставки между слоями - просто пытается сгладить проблемы ngramm, чтобы он стал ближе к цепочке условных вероятностей. Именно их и пытаются получить в статье: Александр -> Македонский, яблоко-> красное, Древний мир -> Греция -> Аристотель и так далее.
До этой работы были выдвинуты гипотезы, как работают различные процессы на уровне нейрона. Они были описаны математически и написан симулятор на основе этих формул. Из научных исследования были взяты значения параметров (данные из сканирования мозга мыши), которые были получены при различных исследованиях. Этими данными были инициализированы значения параметров в описанных ими математических формулах. После этого симуляция была запущена для огромного числа таких инициализированных элементов. Задачей эксперимента была проверить, не "упадет" ли вообще модель, например в нейронных сетях есть взрывы градиентов. Аналогично тут, хотели проверить, не будет ли каких проблем, вдруг какие-то значения пойдут в разнос, так как упустили какие-то ограничения.
Это можно представить так. Мы делаем игру, наделяем элементы какими-то правилами. Заранее инициализируем их. Запускаем игру с миллиардом таких элементов и смотрим, как будут вести себя значения. Мы пока не делаем ни обучения, ни управления ими. Мы делаем проверку, что наша модель не упадет, если мы инициализируем ее и оставим работать на некоторое время с огромным кол-вом элементов на поле. То есть проверяем, масштабируема она или нет.
Поэтому пока говорить о связи с мозгом рано. Да, гипотеза описания формул на основе реальных нейронов. Но пока нет сравнения реального поведения нейронов с таким сигналом и тех что в модели, мы не можем говорить о том, что данная модель симулируем нейроны равносильно нейронам в мозгу.
Теперь проверьте его на другом наборе точек. Ведь он может быть разным.
Скрытый текст
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 (условно новая). Где совсем другой подход.
Так что история про убытки это ещё на долго с нами.
В свое время делал небольшое исследование тонального и нетонального языка.
https://t.me/greenruff/2034
Здесь интересный момент был в том, что переход к нетональному явно прослеживается с переходом в холодный климат. (Там и другие есть исследования других лабораторий).
В частности, клики у африканских народов исчезают, когда мы смещаемся в холодный климат. Так как клики это "речь" на вдохе. Аналогично тональный язык это грубо говоря речь "песня", а открывать часто рот в холод чревато восполнением лёгких или трахеи.
Интересно, есть ли исследования, где связь речи и заболеваний. Поговорил много в холод и организм ослаб или простыл.
А дальше уже заразил остальных: было исследование о распространении болезни на основе метода 6 рукопожатий (условно, точно не помню название). Там было, что уже заражённый быстро разносит болезнь на всю популяцию без изоляции, за 24 дня вроде (не вспомню). Его используют при прогнозировании времени роста эпидемии.
Если хотите улучшить озвучку, то рекомендую синтезировать не все сразу. В этом случае модели часто плохо справляются с этим. А разбивать текст на синтагмы. Это не панацея, но улучшает качество.э, так как делает речь более живой.
https://t.me/greenruff/1826
Тут с синтезом было сложнее. Так как задача была управлять эмоциями, но большую роль так играет именно синтез по частям - синтагмам. В этом случае нет длинных синтезированных фраз. При этом управляя скоростью озвучки через тон и громкость, вы меняете эмоциональный окрас.
В этом случае получаем более человеческий вариант речи. Мозг не устает тогда. По стандартных синтезах, без данного подхода, через 1-2 дня начинаешь слышать разницу.
Сейчас правда есть уже модели вроде с возможностью задать эмоции, поэтому задача упрощается. Но даже там, для улучшения качества, текст для синтез надо резать на синтагмы.
Это так, если вы решите развить качество синтеза речи.
Тема искусственной кожи не нова. В 2020 году получал грант бортника на создание стендового оборудования для его производства
https://vc.ru/tribuna/466947-stoit-li-sozdavat-v-rossii-novye-tehnologii-nash-opyt-razrabotki-tyanusheisya-elektroniki-gflex
Сам подход тот же, что и для тензорных датчиков. Только тут были специально разработанные сплавы на основе галлия, с сопротивлением близком к меди. Сама технология относительно дешёвая.
Проблема на тот момент была в том, что по сути это не особо было нужно. Рынок только только появляется.
Но идея было в том, чтобы прикрутить через нейронки "кожу".
Уже тогда во всех странах велись работы над этим. Германия, США, Китай, Япония - основные страны работающие над этим. С учётом того, как сейчас в Китае развивается робототехника, думаю там первым и выстрелит это.
Свое же оборудование, которое сделали, так и лежит в гараже. Увы..
Слабое исследование. Вместо того, чтобы использовать мат. статистику, пытаются искусственно вводить правила. Данный подход не будет учитывать динамику языка, его заимствования и прочие вещи. Правила конечно лучше чем BPE, но фактически и там и там используется просто частотный подход.
Хотите реально качественный скачек в токенизации, а не эти извращения, то надо рассматривать текст как условные вероятности, которые формируют цепи Маркова и собирать статистику по цепям Маркова, а не по частотным слияниям букв.
https://t.me/greenruff/2483
В данном случае, даже уже всего на 1000 примерах обучения разница будет огромная. И чем дальше обучение, тем сильнее эта разница заметнее. BPE и подход выше, так и будет оставаться в рамках частотных (случайных токенов), где модель пытается это исправить через обучение. И мы долго будем видеть шум и высокочастотные токены. В то время как при правильном подходе, даже на первых 100-400 примерах сразу будет видна разница и первые формирования устойчивых правил. Так как все эти правила и так собраны в статистику наиболее вероятных Марковских цепей.
То что вы написали, это и есть цепь Маркова. Только в статье извращенный способ попытки встроить ее к токенизатор. Не важно на одном уровне блоков или нескольких или только в начале.
Связка "Александр" + "Македонский" это и есть условная вероятность, которая присуща цепи Маркова, а три "слова" в вашем случае это цепь из трех элементов.
Какой-то извращенный способ. Все эти последовательности "внутренней дополнительной архитектуры", как цепи можно получить и так на основе сбора статистики.
Длина слова регулируется через длину цепи Маркова. Больше чувствительность больше статистика для токенизации. Описывал это тут https://t.me/greenruff/2483
И тогда, если выкинуть частотный подход. который вообще чудом работает в языковым моделях из-за их пластичности, а правильно собирать статистику, то мы можем строить правильно и токенизатор и правильно вставлять его между уровнями, а не как в статье через "извращенный прием".
Вместо того, чтобы изобретать костыли как описано выше, почему ни кто не делает R&D, почему вообще так с точки зрения математики. Такая реализация вставки между слоями - просто пытается сгладить проблемы ngramm, чтобы он стал ближе к цепочке условных вероятностей. Именно их и пытаются получить в статье: Александр -> Македонский, яблоко-> красное, Древний мир -> Греция -> Аристотель и так далее.
До этой работы были выдвинуты гипотезы, как работают различные процессы на уровне нейрона. Они были описаны математически и написан симулятор на основе этих формул. Из научных исследования были взяты значения параметров (данные из сканирования мозга мыши), которые были получены при различных исследованиях. Этими данными были инициализированы значения параметров в описанных ими математических формулах. После этого симуляция была запущена для огромного числа таких инициализированных элементов. Задачей эксперимента была проверить, не "упадет" ли вообще модель, например в нейронных сетях есть взрывы градиентов. Аналогично тут, хотели проверить, не будет ли каких проблем, вдруг какие-то значения пойдут в разнос, так как упустили какие-то ограничения.
Это можно представить так. Мы делаем игру, наделяем элементы какими-то правилами. Заранее инициализируем их. Запускаем игру с миллиардом таких элементов и смотрим, как будут вести себя значения. Мы пока не делаем ни обучения, ни управления ими. Мы делаем проверку, что наша модель не упадет, если мы инициализируем ее и оставим работать на некоторое время с огромным кол-вом элементов на поле. То есть проверяем, масштабируема она или нет.
Поэтому пока говорить о связи с мозгом рано. Да, гипотеза описания формул на основе реальных нейронов. Но пока нет сравнения реального поведения нейронов с таким сигналом и тех что в модели, мы не можем говорить о том, что данная модель симулируем нейроны равносильно нейронам в мозгу.