Я использовал разные и ChatGPT и Gemini, Opus и Sonnet и deepSeek. Так как делать миграцию ручками не очень. И с переносом простых вещей модели справляются хорошо, если делают маленькими патчами за раз (то есть переносят 10 таблиц только, но если все сразу то контекст растет и они начинают терять детали обязательно где то будет не так перенесен тип или поле название измениться или что то еще).
Конечно всегда уточнялось в начале про PG. Но на сложных SQL хранимых процедурах это не очень помогает. Так как PG начинает терять влияние и дальше уже сильнее влияют другие токены. Кроме того, часто было так, что он упорно в самом начале пытался использовать конструкцию из Oracle, а в другом не мог правильно реализовать логику и зацикливался и ходил по кругу (там была конструкция где в PG, ее можно было применять только к одному параметру, а он пытался применять сразу ко всем). Хуже всего, когда код проходит валидацию и выполняется, но в отчетах генерирует мусор.
Поэтому я бы хотел, чтобы модель специализировалась на одной предметной области, а не разбавляла бы свою статистику вероятностей кулинарной книгой, когда мне нужно от нее только написание кода на конкретном языке разработки.
На самом деле тренд на специализированные модели уже есть. Все эти Opus и Sonnet это уже первые специализированные модели под языки программирования, где при обучении упор делается на программирование. Теперь осталось специализировать модели под разные языки программирования и уровни постановки задач.
Это не работает так всегда. Если вы делали миграцию с MS SQL или Oracle на pgSql, то видели бы как это плывет на сложных хранимых процедурах. Ни какой "pgSql" не помогает тут, начинают вставлять конструкции из других диалектах, так как влияние pgSql теряется при росте контекста.
У меня с SQL языковые модели плывут сильно и часто путаются с PG и MS SQL/Oracle, когда делал миграцию БД. Проблема возникла с хранимыми процедурами, которые генерировали отчеты. Постоянно путала и вставляла конструкции от Oracle и MS SQL в конструкции PG, потом извинялась и снова.. допускала ошибки. И помогает только руками писать, так как итоговый результат пишется что выдает мусор. И подобный подход работает хорошо, только на очень простом. И дикий ужас возникает в динамических запросах, где запрос формируется в процессе и сразу не проверишь.
Тут очень не хватает специализированных моделей, заточенных под своих языки.
Смотрит, но вы слишком оптимистично считаете что это правило работает жестко. Контекст это иерархия контекстов. На одном это будут слоги. на другом соседние слова, на третьем конструкция. И результат это общее усиление. И если на одних уровнях модель не уверена и вклад не велик, а на другом уровне иерархии уверена сильнее, то именно он сыграет главную роль. То есть если модель решит что после SELECT должно идти FROM и эта связь будет сильнее чем связь данной конструкции c верхней абстракцией pgSql или ms sql, то именно она сыграет ключевую роль в выборе токена.
Влияние контекста так не работает. Он может не сработать в том ключе, как изначально предполагалось, так как контекст это не влияние одного слова или конструкции, а учет всей иерархии.
Речь идет про разные языки программирования, тот же Java и JS и TS, или же C/C++ и Rust. Нет смысла затачивать под один фреймворк.
Все знания важны, слишком абстрактно. В рамках одной предметной области другие значения начинают мешать. Когда чинишь коллайдер, то знания с форума мамочки ру о том, как что-то там.. будут только размазывать ваши общие знания.
Кол-во специализированных датасетов остается тем же, мы убираем мусор (в плане данной предметной области). Это похоже на то, что вы изучаете Python, и при этом еще учите рецепты от проф повара. Информация смешивается, когда вы начинаете учиться готовить питона по вьетнамски.
Вот что происходит со статистикой, когда мы собираем ее по разным цепям Маркова. Есть отдельные уникальные группы, частотность которых уникальная. А есть вырожденные группы, у которых частотность появления одинаковая. Проблема одинаковой частотности - одинаковая вероятность.
Если мы берем одну предметную область например Java, то размеры групп с одинаковой частотой будут меньше. Это меньше неопределенности. Но если мы добавим сюда JavaScript, то кол-во элементов в группах с одинаковой частотой будет расти, потому что наложиться и в JavaScript и в Java некоторая динамика переходов (цепи Маркова) встречается одинаковое кол-во раз (как не парадоксально).
В современных LLM это решается через Dropout, когда мы вносим случайный шум и смещает это распределение. Теперь значения могут немного отличаться и модель знает какое выбирать.
Это приводит к другой проблеме. Теперь у нас есть две траектории построения цепи Маркова с близкими вероятностями разделенные на небольшую случайную величину. В итоге на выходе в logits у нас может оказаться два или более схожих по вероятности значения, например 0.1 и 0.104 и 0.99997 от разных языков Java и JavaScript, потому что мы сдвинули их dropout. Но мы используем top-p или top-k, и это значит что все эти значения попадают у нас в выбор случайного следующего токена.
Если мы убираем из датасета мусор (по мусором я имею ввиду, то что не относится к предметной области модели) и при этом уменьшаем размер модели, то ни какой потери информации нет. Наоборот, модель теперь лучше улавливает связи. Потому что у нее теперь на выходе не будет logits 0.1 и 0.104 и 0.99997 от разных языков программирования схожих по синтаксису. У модели останется только те токены, которые она видела в рамках одного языка.
Да, если мы попробуем обучить огромную LLM только на Python, то вероятно данных не хватит для огромных моделей и она будет недоучена и часто генерировать галлюцинации. Но проблемы с данными при обучении языкам программирования сейчас как раз нет, так как процесс расширения данных сводится к тому, что при RL обучении, сам компилятор является учителем и выдает, что не правильно и мы обучаем только тогда все хорошо (генерируются множество вариантов и выбирается лучший).
Спасибо почитал, да вижу что в ViT это убрало проблему больших значений в классическом Attention при большом кол-ве блоков.
Но это компромисс, так как теряется информация о норме вектора. И как замечают на разных площадках, такой поход снижает "остроту" внимания, модель хуже работает на инференсе. И из того, что я вижу в других работах, там как раз пытаются решить эту проблему нормализации, через добавление обучаемой температуры:
Swin Transformer V2: Softmax(τ*cos(Q,K)+B)V , τ - температура
Теперь вижу, что в крупных ViT решали таким образом взрыв значения, теряя информацию о длине вектора как компромисс. Но это так же приводит к различным проблемам, которые сейчас пытаются решить за счет обучаемой температуры.
Не готов объяснять разницу, если вы не попытались понять что вам дали.
Если вы говорите, что описанный вами подход рабочий и есть исследования на эту тему и показания эффективности, то это следовало привести в статье. Сейчас это выглядит как гипотеза, которую вы описали, но не обучили модель чтобы показать разницу и не привели исследования других, где показана разница.
Буду рад ошибаться, и с полостью почитаю эти исследования.
Я показал там сравнение, где обучил такую же llm того же размера на тех же данных. Там это есть и результат виден. Там дело не только в связях, там другой токенизатор, который не BPE или другой частотный я там токенизатор построен на цепях Маркова. Что касается связей, то я провел вам исследования. Я пока не понимаю, что делает вас слой, чему модель не может обучиться через уже имеющиеся слои.
Вам следует в пользу своих аргументов приводит обучение. Показать, вот я обучил llm с этим слоем и без него. Данные одинаковые, вот кривая обучения я вот результат. Я буду рад, если вы сделаете такое обучение покажите разницу.
Речь не о том что смогут на нашем языке. Вы пробовали использовать большие языковые модели для сложных SQL запросов? Они постоянно там ошибаются.
Потому что когда у вас система обобщила, что в конце select идёт одна конструкция и другая для разных диалектов, то их вероятности становяться очень близкими. Прибавляем к этому top-p/top-k на выходе при выборе случайного токена, и вот уже система легко выбрала другой диалект и пытается править его в случае ошибки.
В случае специализированной модели она не может перепутать там, потому что в выборе следующего случайного токена не будет два схожих по вероятности из разных диалектов языка. То же самое касается многих языков фреймворков.
Причина в softmax. У вас например после одинакового текста java и JavaScript модель выбирает следующий токен. И в вероятности попали две реализации в рамках одного и другого языка, потому что предыдущий текст усилил их вероятности у обоих (обобщил). И вы пишите код на Java, а в выборке top-p продолжение для JavaScript. И вот ещё она легко ошиблась.
Но хуже всего с хвостом, где встречаются более редкие токены. И там шум очень сильно влияет. При обобщении, они могут выпасть из выборки, потому что может при обучении встречала чаще из других языков. А это какой то фреймворк. И вот уже модель его не использует.
Речь не про язык (человеческий), а про язык программирования. Если модель много обобщала, то она напишет кучу всего и не словесном языке. Да вероятно даже может решить задачу, а может и нет, так как длинный текст создал кучу шума и привел к потере деталей.
Не совсем так. Если мы посмотрим не на название MoE, а на ее реализацию, то разница есть.
Что делает MoE? Она разбивает выходной сигнал после голов на K участков. Если сильнее участок 1, то используется FFN1, если сильнее участок 2, то используется FFN2.
Что это значит? Возьмём SQL. В нем активизируется участок 1 для SQL при чем и для ms sql и для oracle sql. Система не вызовет эксперта 2. Они оба будут сидеть на участке 1.
В реальности MoE это не совсем про экспертов, это решение проблемы одного большого FFN, когда мы делим его на участки и таким образом повышаем точность (могли бы взять огромный FFN, но памяти не хватит).
То есть если мы обучаем Java и JavaScript, то это не значит что будут задействованы 2 разных участка (эксперта). Наоборот, с высокой долей вероятности, что грамматический синтаксис этих языков приведет их к одному и тому участку (эксперту) на выходе.
Поэтому отчасти MoE можно считать экспертной системой, где сильно разные области будут разнесены. А могут быть и не разнесены, если их головы вернут сильный сигнал для одинакового эксперта. А так как языки программирования чаще всего сильно пересекаются по структуре, то более вероятно что все они будут работать в рамках одного двух экспертов.
Подобное решается только через специализированные модели. Где и токенизатор заточен под язык, и головы находят соответствующие разные связи и эксперты работают в рамках одного языка, улучшая точность прогноза.
Да, если мы говорим например о языках программирования и термоядерной физике, то с большой долей вероятности головы дадут разное распределение с максимумами в сильно разных участках dim. Но когда речь идёт об одной области, то MoE тут не сильно поможет.
Выскажу свое мнение. На мой взгляд следующим шагом будут не большие языковые модели, а множество мелких специализированных языковых моделей, написанных под каждый язык программирования и свою область.
Это должно увеличить качество. Дело в том, что чем больше мы скармливаеи данных, тем сильнее модель их обобщает. Это приводит к тому, что некоторые связи становяться почти равновероятны и и могу пересекаться из разных языков. Когда накопление ошибки может привести к тому, что модель пойдет по одному маршруту.
Приведу пример, в одном языке есть фреймворк с какими-то параметрами и в другом с таким же названием. И при сильном обобщении softmax становится более плоским. Небольшая ошибка в точности (у моделей часто делают катетеризацию и уменьшают точность ради скорости и памяти), приводит к тому, что маленькое отклонение EPS приводит к смещению вероятности. Или хуже того, случайный выбор согласно температуре захватывает их.
В итоге, модель пишет вызов функция, который она например видела на sql oracle и сейчас пытается применить к sql ms sql. Такое встречается часто уже сейчас.
Более маленькие специализированные языковые модели, заточены под свою область. Они более "уверенно" и точно выдают результат, так как у них нет такой модели. В их датасете не было других языков разработки, поэтому их вероятности в softmax будут более ярко выражены.
В этом случае обучение более качественное, а loss остаётся стабильным. Так как в этом случае каждый блок вносит свой вклад во все последующие и модели не нужно пытаться одновременно обеспечить этот проброс на уровне одного FFN и одновременно делать обобщение данных.
Как уже сказал выше, сейчас такие же результаты получили другие исследователи.
"Простыня" была специально адаптирована, чтобы ее могла понимать LLM (и другим было проще скармливать). Я дал вам ссылку, потому что ваши ответы выше написаны нейронкоц, поэтому предложил скормить ей материал.
Что касается loss, то прежде чем делать выводы, надо было увидеть что это обучения длилось 1 день. Где целью являлось подтвердить математическую модель.
Я предлагаю подтвердить на обучении модели свои утверждения. Я провел вам не только мат модель, но и ее реализацию и показатели обучения.
В коде нет QV и прочего, вы посмотрели на развитие архитектуры, когда постепенно она приближалась к правильной.
Я же говорю, про последнюю реализацию HierarchicalMHA_20, которая есть в обоих ссылках. В ней нет классического attention и голов.
Повторюсь, целью было показать, что совершенно другая форма реализации, совсем не похожая на attention работает согласно математической модели. Как уже сказал, обучение было 1 день и модель уже строит слова, ставит скобки, пытается делать связи.
В вашем случаев, вам просто следует показать:
Математически, что ваши предположения на чем то основаны
Обучить небольшую модель, хотя бы сутки или несколько дней с вашим решением и без него и показать, что результат формирования связей (не loss) действительно отличается.
Тогда вопросы отпадут сами собой. А то сейчас вы отвечаете с помощью сетки, не привели примеры что это работает. Если говорить корректно, вы выдвинули гипотезу, которую надо либо подтвердить или опровергнуть.
Вы пытаетесь отвечать через LLM. Я предлагаю вам сделать иначе, чтобы лучше понять что такое Attention, скормить это вашей LLM (вопрос-ответ можно не скармливать, это уточнения которые были у людей по коду, я вынес как отдельные пояснения):
Я привел вам ссылки и на код, и на текст и визуально показал.
Предлагаю скормить их вашей модели в том порядке как это указано (это специально было адаптировано для LLM). И после этого, предложить ей дать оценку, вашему предположению (не пытаясь ее переубедить).
Без этого контекста, рассуждения мало эффективны. Так как выше математически доказанная модель, которая так же была проверена на примере архитектурного кода.
Что касается регулирования температуры, то как раз я имел ввиду, что вам нужно регулировать температуру внутри Attention, как это показано на рисунке выше. Тогда модель сама решает, когда ей нужно увеличить ее, а когда понизить внутри Atention.
Нет, "важность" это частотность, она же вероятность. Ломая эту информацию, мы ломаем распределение и создаем неопределенность, это означает что некоторые вещи становятся равно вероятными, хотя это не так. не должна буква "ы" быть чаще буквы "а", так и эти вектора. Это "энергия" в информационном плане (абстрактном), информация о том, сколько система тратить на переход от токена А к токену В, то есть ее затраты. И задача модели научиться найти баланс между затратами и сложностью многообразием. Вы убивая "затраты", оставляете только сложность многообразие и тем самым увеличиваете энтропию системы, а это всегда не определенность. Это ближе к тому, что мы сделаем температуру высокой, и часть вероятностей будут одинаковой важности.
Q*K это фактически I(P1, P2) взаимная информация между случайными величинами, которую можно представить как две компоненты PMMI матрицу (связи, о которых вы говорите) и "энергия" (затраты на переход между связями). Когда вы нормализуете их, то теряете информацию об этих переходах. Это как если бы для вас не было разницы, произносить А или О, потому что вы приравняли их "энергетические" затраты на открывание рта.
Информация о частотности при сравнении связей, не менее важна чем и сами связи, потому что стоимость этих переходов меньше и они чаще.
Поэтому описанная проблема это не QK, можете увеличить кол-во других данных. Или изменить архитектуру, чтобы температура была динамической, тогда в одних случаях модель будет искать баланс между затратами системы (частотность) и ее многообразием (энтропией). Вы сейчас наоборот пытаетесь жестко сделать второй вариант, а задача как раз баланс, дать системе самой определять на сколько важны связи эмбеддингов и на сколько важна частотность эмбеддингов.
Добавив нормализацию в QK, вы таким образом поломали эмбеддинги и их смысл. Они содержат информацию не только о сходстве, но и частотности. Когда вы нормализовали их перед QV, то фактически лишили информации о важности информации (какая встречается чаще, а какая реже).
Сам эмбеддинг это не только сходство между токена. Норма эмбеддингов содержит информацию о частоте, но когда вы делаете нормализацию конкретного сигнала, то теряет большую часть информации. Было например |-15.45| как частота слова "кот", которая встречалась 1000 раз и |4.3| как частота слова "собака" которая встречалась 100 раз. Вы в данном случае полностью ломаете логику, так как после нормализации Q и K они могут совпасть по норме, станут например оба 0.7 и модель уже больше не может понять, какое из них важнее.
Я выкладывал обучаемую архитектуру на которой эту логику можно проследить более отчетливо в коде.
Она ближе к EMB (Energy-Based Models, или Энергетические модели). Там как раз мы извлекает из эмбеддингов разные составляющие. Мы даже можем разделить эмбеддинги на составляющие, которые будут храниться и обучаться отдельно (вместо векторов).
От МТС как то ждешь больше профессионализма в статьях. которые пишут. Я бы сказал, что материал описанный в статье сильно устарел. Это было актуально в 2021-2022 году, когда были разработаны Flamingo (DeepMind) и Perceiver IO (DeepMind). Сейчас более продвинутыми все таки является V-Jepa, и более свежая этого года Le-Jepa.
То что описано в статье не стоит использовать, это крайне неэффективные и устаревшие решения. Тем более в контексте "Будущее роботизированных манипуляций". У вас отставание лет на 4-5. Приделать агентов к старым неэффективным подходам не решает проблем.
В качестве истории развития, я бы рекомендовал вот это видео (от прошлого века, до сегодняшнего времени). И не забивать себе голову мусором про VLM в рамках данной статьи. Это только пойдет во вред.
Я пока в течении недели разбирался с теоремами и архитектурой и кодом, частично через сетки, частично в фотошопе сделал данные изображения, можете если нужно что-то вырезать из них. Это облегчит задачу, так как сетки плохо генерируют такие картинки (пробовал в разных, даже с учетом подробного описания, выходило в большей части мусор), поэтому пришлось делать сначала крупные картинки (по частям генерировать фрагменты) и собирать их в фотошопе (хотел сначала в комментарии приложит именно их), но потом решил что это будет не очень понятно.
Поэтому замечательно если их переработать и написать наглядно не доказательную часть, а визуально объясняющую. Я их делал исходя из того, как их понял архитектуру с кодом и теоремы.
И чтобы добавить веса, стоит все таки провести аналогию с OpenMythos, чтобы было проще понять общую идею.
А предложенное архитектурное решение и доказательства теорем - интересные.
Я использовал разные и ChatGPT и Gemini, Opus и Sonnet и deepSeek. Так как делать миграцию ручками не очень. И с переносом простых вещей модели справляются хорошо, если делают маленькими патчами за раз (то есть переносят 10 таблиц только, но если все сразу то контекст растет и они начинают терять детали обязательно где то будет не так перенесен тип или поле название измениться или что то еще).
Конечно всегда уточнялось в начале про PG. Но на сложных SQL хранимых процедурах это не очень помогает. Так как PG начинает терять влияние и дальше уже сильнее влияют другие токены. Кроме того, часто было так, что он упорно в самом начале пытался использовать конструкцию из Oracle, а в другом не мог правильно реализовать логику и зацикливался и ходил по кругу (там была конструкция где в PG, ее можно было применять только к одному параметру, а он пытался применять сразу ко всем). Хуже всего, когда код проходит валидацию и выполняется, но в отчетах генерирует мусор.
Поэтому я бы хотел, чтобы модель специализировалась на одной предметной области, а не разбавляла бы свою статистику вероятностей кулинарной книгой, когда мне нужно от нее только написание кода на конкретном языке разработки.
На самом деле тренд на специализированные модели уже есть. Все эти Opus и Sonnet это уже первые специализированные модели под языки программирования, где при обучении упор делается на программирование. Теперь осталось специализировать модели под разные языки программирования и уровни постановки задач.
Это не работает так всегда. Если вы делали миграцию с MS SQL или Oracle на pgSql, то видели бы как это плывет на сложных хранимых процедурах. Ни какой "pgSql" не помогает тут, начинают вставлять конструкции из других диалектах, так как влияние pgSql теряется при росте контекста.
У меня с SQL языковые модели плывут сильно и часто путаются с PG и MS SQL/Oracle, когда делал миграцию БД. Проблема возникла с хранимыми процедурами, которые генерировали отчеты. Постоянно путала и вставляла конструкции от Oracle и MS SQL в конструкции PG, потом извинялась и снова.. допускала ошибки. И помогает только руками писать, так как итоговый результат пишется что выдает мусор. И подобный подход работает хорошо, только на очень простом. И дикий ужас возникает в динамических запросах, где запрос формируется в процессе и сразу не проверишь.
Тут очень не хватает специализированных моделей, заточенных под своих языки.
Смотрит, но вы слишком оптимистично считаете что это правило работает жестко. Контекст это иерархия контекстов. На одном это будут слоги. на другом соседние слова, на третьем конструкция. И результат это общее усиление. И если на одних уровнях модель не уверена и вклад не велик, а на другом уровне иерархии уверена сильнее, то именно он сыграет главную роль. То есть если модель решит что после SELECT должно идти FROM и эта связь будет сильнее чем связь данной конструкции c верхней абстракцией pgSql или ms sql, то именно она сыграет ключевую роль в выборе токена.
Влияние контекста так не работает. Он может не сработать в том ключе, как изначально предполагалось, так как контекст это не влияние одного слова или конструкции, а учет всей иерархии.
Речь идет про разные языки программирования, тот же Java и JS и TS, или же C/C++ и Rust. Нет смысла затачивать под один фреймворк.
Все знания важны, слишком абстрактно. В рамках одной предметной области другие значения начинают мешать. Когда чинишь коллайдер, то знания с форума мамочки ру о том, как что-то там.. будут только размазывать ваши общие знания.
Кол-во специализированных датасетов остается тем же, мы убираем мусор (в плане данной предметной области). Это похоже на то, что вы изучаете Python, и при этом еще учите рецепты от проф повара. Информация смешивается, когда вы начинаете учиться готовить питона по вьетнамски.
Вот что происходит со статистикой, когда мы собираем ее по разным цепям Маркова. Есть отдельные уникальные группы, частотность которых уникальная. А есть вырожденные группы, у которых частотность появления одинаковая. Проблема одинаковой частотности - одинаковая вероятность.
Если мы берем одну предметную область например Java, то размеры групп с одинаковой частотой будут меньше. Это меньше неопределенности. Но если мы добавим сюда JavaScript, то кол-во элементов в группах с одинаковой частотой будет расти, потому что наложиться и в JavaScript и в Java некоторая динамика переходов (цепи Маркова) встречается одинаковое кол-во раз (как не парадоксально).
В современных LLM это решается через Dropout, когда мы вносим случайный шум и смещает это распределение. Теперь значения могут немного отличаться и модель знает какое выбирать.
Это приводит к другой проблеме. Теперь у нас есть две траектории построения цепи Маркова с близкими вероятностями разделенные на небольшую случайную величину. В итоге на выходе в logits у нас может оказаться два или более схожих по вероятности значения, например 0.1 и 0.104 и 0.99997 от разных языков Java и JavaScript, потому что мы сдвинули их dropout. Но мы используем top-p или top-k, и это значит что все эти значения попадают у нас в выбор случайного следующего токена.
Если мы убираем из датасета мусор (по мусором я имею ввиду, то что не относится к предметной области модели) и при этом уменьшаем размер модели, то ни какой потери информации нет. Наоборот, модель теперь лучше улавливает связи. Потому что у нее теперь на выходе не будет logits 0.1 и 0.104 и 0.99997 от разных языков программирования схожих по синтаксису. У модели останется только те токены, которые она видела в рамках одного языка.
Да, если мы попробуем обучить огромную LLM только на Python, то вероятно данных не хватит для огромных моделей и она будет недоучена и часто генерировать галлюцинации. Но проблемы с данными при обучении языкам программирования сейчас как раз нет, так как процесс расширения данных сводится к тому, что при RL обучении, сам компилятор является учителем и выдает, что не правильно и мы обучаем только тогда все хорошо (генерируются множество вариантов и выбирается лучший).
Спасибо почитал, да вижу что в ViT это убрало проблему больших значений в классическом Attention при большом кол-ве блоков.
Но это компромисс, так как теряется информация о норме вектора. И как замечают на разных площадках, такой поход снижает "остроту" внимания, модель хуже работает на инференсе. И из того, что я вижу в других работах, там как раз пытаются решить эту проблему нормализации, через добавление обучаемой температуры:
Swin Transformer V2: Softmax(τ*cos(Q,K)+B)V , τ - температура
CosScale / Scaled Cosine Attention: β(i,j) = Exp(α*cos(θ(i, j))) / Sum(Exp(α*cos(θ(i, l)))) , α температура
Теперь вижу, что в крупных ViT решали таким образом взрыв значения, теряя информацию о длине вектора как компромисс. Но это так же приводит к различным проблемам, которые сейчас пытаются решить за счет обучаемой температуры.
Можете объяснить свой ответ? Как RL решает данную проблему? Если речь про файтюнинг, то это и есть специализированные модели.
Я привел аргумент, почему MoE не даёт такую специализацию, а softmax может привести к ошибкам на близко вероятных токнах.
Но я могу ошибаться, поэтому будет интересно узнать, почему этого не возникает и как RL решает данную проблему.
Не готов объяснять разницу, если вы не попытались понять что вам дали.
Если вы говорите, что описанный вами подход рабочий и есть исследования на эту тему и показания эффективности, то это следовало привести в статье. Сейчас это выглядит как гипотеза, которую вы описали, но не обучили модель чтобы показать разницу и не привели исследования других, где показана разница.
Буду рад ошибаться, и с полостью почитаю эти исследования.
Я показал там сравнение, где обучил такую же llm того же размера на тех же данных. Там это есть и результат виден. Там дело не только в связях, там другой токенизатор, который не BPE или другой частотный я там токенизатор построен на цепях Маркова. Что касается связей, то я провел вам исследования. Я пока не понимаю, что делает вас слой, чему модель не может обучиться через уже имеющиеся слои.
Вам следует в пользу своих аргументов приводит обучение. Показать, вот я обучил llm с этим слоем и без него. Данные одинаковые, вот кривая обучения я вот результат. Я буду рад, если вы сделаете такое обучение покажите разницу.
Речь не о том что смогут на нашем языке. Вы пробовали использовать большие языковые модели для сложных SQL запросов? Они постоянно там ошибаются.
Потому что когда у вас система обобщила, что в конце select идёт одна конструкция и другая для разных диалектов, то их вероятности становяться очень близкими. Прибавляем к этому top-p/top-k на выходе при выборе случайного токена, и вот уже система легко выбрала другой диалект и пытается править его в случае ошибки.
В случае специализированной модели она не может перепутать там, потому что в выборе следующего случайного токена не будет два схожих по вероятности из разных диалектов языка. То же самое касается многих языков фреймворков.
Причина в softmax. У вас например после одинакового текста java и JavaScript модель выбирает следующий токен. И в вероятности попали две реализации в рамках одного и другого языка, потому что предыдущий текст усилил их вероятности у обоих (обобщил). И вы пишите код на Java, а в выборке top-p продолжение для JavaScript. И вот ещё она легко ошиблась.
Но хуже всего с хвостом, где встречаются более редкие токены. И там шум очень сильно влияет. При обобщении, они могут выпасть из выборки, потому что может при обучении встречала чаще из других языков. А это какой то фреймворк. И вот уже модель его не использует.
Речь не про язык (человеческий), а про язык программирования. Если модель много обобщала, то она напишет кучу всего и не словесном языке. Да вероятно даже может решить задачу, а может и нет, так как длинный текст создал кучу шума и привел к потере деталей.
Не совсем так. Если мы посмотрим не на название MoE, а на ее реализацию, то разница есть.
Что делает MoE? Она разбивает выходной сигнал после голов на K участков. Если сильнее участок 1, то используется FFN1, если сильнее участок 2, то используется FFN2.
Что это значит? Возьмём SQL. В нем активизируется участок 1 для SQL при чем и для ms sql и для oracle sql. Система не вызовет эксперта 2. Они оба будут сидеть на участке 1.
В реальности MoE это не совсем про экспертов, это решение проблемы одного большого FFN, когда мы делим его на участки и таким образом повышаем точность (могли бы взять огромный FFN, но памяти не хватит).
То есть если мы обучаем Java и JavaScript, то это не значит что будут задействованы 2 разных участка (эксперта). Наоборот, с высокой долей вероятности, что грамматический синтаксис этих языков приведет их к одному и тому участку (эксперту) на выходе.
Поэтому отчасти MoE можно считать экспертной системой, где сильно разные области будут разнесены. А могут быть и не разнесены, если их головы вернут сильный сигнал для одинакового эксперта. А так как языки программирования чаще всего сильно пересекаются по структуре, то более вероятно что все они будут работать в рамках одного двух экспертов.
Подобное решается только через специализированные модели. Где и токенизатор заточен под язык, и головы находят соответствующие разные связи и эксперты работают в рамках одного языка, улучшая точность прогноза.
Да, если мы говорим например о языках программирования и термоядерной физике, то с большой долей вероятности головы дадут разное распределение с максимумами в сильно разных участках dim. Но когда речь идёт об одной области, то MoE тут не сильно поможет.
Выскажу свое мнение. На мой взгляд следующим шагом будут не большие языковые модели, а множество мелких специализированных языковых моделей, написанных под каждый язык программирования и свою область.
Это должно увеличить качество. Дело в том, что чем больше мы скармливаеи данных, тем сильнее модель их обобщает. Это приводит к тому, что некоторые связи становяться почти равновероятны и и могу пересекаться из разных языков. Когда накопление ошибки может привести к тому, что модель пойдет по одному маршруту.
Приведу пример, в одном языке есть фреймворк с какими-то параметрами и в другом с таким же названием. И при сильном обобщении softmax становится более плоским. Небольшая ошибка в точности (у моделей часто делают катетеризацию и уменьшают точность ради скорости и памяти), приводит к тому, что маленькое отклонение EPS приводит к смещению вероятности. Или хуже того, случайный выбор согласно температуре захватывает их.
В итоге, модель пишет вызов функция, который она например видела на sql oracle и сейчас пытается применить к sql ms sql. Такое встречается часто уже сейчас.
Более маленькие специализированные языковые модели, заточены под свою область. Они более "уверенно" и точно выдают результат, так как у них нет такой модели. В их датасете не было других языков разработки, поэтому их вероятности в softmax будут более ярко выражены.
Описанная вами проблема решается с помощью множества residual связей. В последних исследованиях, как раз пришли к этому решению.
https://t.me/greenruff/2497
В этом случае обучение более качественное, а loss остаётся стабильным. Так как в этом случае каждый блок вносит свой вклад во все последующие и модели не нужно пытаться одновременно обеспечить этот проброс на уровне одного FFN и одновременно делать обобщение данных.
Как уже сказал выше, сейчас такие же результаты получили другие исследователи.
"Простыня" была специально адаптирована, чтобы ее могла понимать LLM (и другим было проще скармливать). Я дал вам ссылку, потому что ваши ответы выше написаны нейронкоц, поэтому предложил скормить ей материал.
Что касается loss, то прежде чем делать выводы, надо было увидеть что это обучения длилось 1 день. Где целью являлось подтвердить математическую модель.
Я предлагаю подтвердить на обучении модели свои утверждения. Я провел вам не только мат модель, но и ее реализацию и показатели обучения.
В коде нет QV и прочего, вы посмотрели на развитие архитектуры, когда постепенно она приближалась к правильной.
Я же говорю, про последнюю реализацию HierarchicalMHA_20, которая есть в обоих ссылках. В ней нет классического attention и голов.
Повторюсь, целью было показать, что совершенно другая форма реализации, совсем не похожая на attention работает согласно математической модели. Как уже сказал, обучение было 1 день и модель уже строит слова, ставит скобки, пытается делать связи.
В вашем случаев, вам просто следует показать:
Математически, что ваши предположения на чем то основаны
Обучить небольшую модель, хотя бы сутки или несколько дней с вашим решением и без него и показать, что результат формирования связей (не loss) действительно отличается.
Тогда вопросы отпадут сами собой. А то сейчас вы отвечаете с помощью сетки, не привели примеры что это работает. Если говорить корректно, вы выдвинули гипотезу, которую надо либо подтвердить или опровергнуть.
Вы пытаетесь отвечать через LLM. Я предлагаю вам сделать иначе, чтобы лучше понять что такое Attention, скормить это вашей LLM (вопрос-ответ можно не скармливать, это уточнения которые были у людей по коду, я вынес как отдельные пояснения):
https://disk.yandex.ru/d/UNyaCbYUm-jpWw
Я привел вам ссылки и на код, и на текст и визуально показал.
Предлагаю скормить их вашей модели в том порядке как это указано (это специально было адаптировано для LLM). И после этого, предложить ей дать оценку, вашему предположению (не пытаясь ее переубедить).
Для большей строгости можно даже скормить ей код архитектуры, так как в ней Attention реализован как я описал выше (модель отлично обучается):
https://disk.yandex.ru/d/eJg7Nc__qIeQ9A
Без этого контекста, рассуждения мало эффективны. Так как выше математически доказанная модель, которая так же была проверена на примере архитектурного кода.
Что касается регулирования температуры, то как раз я имел ввиду, что вам нужно регулировать температуру внутри Attention, как это показано на рисунке выше. Тогда модель сама решает, когда ей нужно увеличить ее, а когда понизить внутри Atention.
Нет, "важность" это частотность, она же вероятность. Ломая эту информацию, мы ломаем распределение и создаем неопределенность, это означает что некоторые вещи становятся равно вероятными, хотя это не так. не должна буква "ы" быть чаще буквы "а", так и эти вектора. Это "энергия" в информационном плане (абстрактном), информация о том, сколько система тратить на переход от токена А к токену В, то есть ее затраты. И задача модели научиться найти баланс между затратами и сложностью многообразием. Вы убивая "затраты", оставляете только сложность многообразие и тем самым увеличиваете энтропию системы, а это всегда не определенность. Это ближе к тому, что мы сделаем температуру высокой, и часть вероятностей будут одинаковой важности.
Q*K это фактически I(P1, P2) взаимная информация между случайными величинами, которую можно представить как две компоненты PMMI матрицу (связи, о которых вы говорите) и "энергия" (затраты на переход между связями). Когда вы нормализуете их, то теряете информацию об этих переходах. Это как если бы для вас не было разницы, произносить А или О, потому что вы приравняли их "энергетические" затраты на открывание рта.
Информация о частотности при сравнении связей, не менее важна чем и сами связи, потому что стоимость этих переходов меньше и они чаще.
Поэтому описанная проблема это не QK, можете увеличить кол-во других данных. Или изменить архитектуру, чтобы температура была динамической, тогда в одних случаях модель будет искать баланс между затратами системы (частотность) и ее многообразием (энтропией). Вы сейчас наоборот пытаетесь жестко сделать второй вариант, а задача как раз баланс, дать системе самой определять на сколько важны связи эмбеддингов и на сколько важна частотность эмбеддингов.
Добавив нормализацию в QK, вы таким образом поломали эмбеддинги и их смысл. Они содержат информацию не только о сходстве, но и частотности. Когда вы нормализовали их перед QV, то фактически лишили информации о важности информации (какая встречается чаще, а какая реже).
Сам эмбеддинг это не только сходство между токена. Норма эмбеддингов содержит информацию о частоте, но когда вы делаете нормализацию конкретного сигнала, то теряет большую часть информации. Было например |-15.45| как частота слова "кот", которая встречалась 1000 раз и |4.3| как частота слова "собака" которая встречалась 100 раз. Вы в данном случае полностью ломаете логику, так как после нормализации Q и K они могут совпасть по норме, станут например оба 0.7 и модель уже больше не может понять, какое из них важнее.
Я выкладывал обучаемую архитектуру на которой эту логику можно проследить более отчетливо в коде.
https://t.me/greenruff/2596
Она ближе к EMB (Energy-Based Models, или Энергетические модели). Там как раз мы извлекает из эмбеддингов разные составляющие. Мы даже можем разделить эмбеддинги на составляющие, которые будут храниться и обучаться отдельно (вместо векторов).
От МТС как то ждешь больше профессионализма в статьях. которые пишут. Я бы сказал, что материал описанный в статье сильно устарел. Это было актуально в 2021-2022 году, когда были разработаны Flamingo (DeepMind) и Perceiver IO (DeepMind). Сейчас более продвинутыми все таки является V-Jepa, и более свежая этого года Le-Jepa.
То что описано в статье не стоит использовать, это крайне неэффективные и устаревшие решения. Тем более в контексте "Будущее роботизированных манипуляций". У вас отставание лет на 4-5. Приделать агентов к старым неэффективным подходам не решает проблем.
В качестве истории развития, я бы рекомендовал вот это видео (от прошлого века, до сегодняшнего времени). И не забивать себе голову мусором про VLM в рамках данной статьи. Это только пойдет во вред.
Если будет нужно использовать в других статьях исходники выше, то выложил тут:
https://disk.yandex.ru/d/J1bS853ToIpgSg
Я пока в течении недели разбирался с теоремами и архитектурой и кодом, частично через сетки, частично в фотошопе сделал данные изображения, можете если нужно что-то вырезать из них. Это облегчит задачу, так как сетки плохо генерируют такие картинки (пробовал в разных, даже с учетом подробного описания, выходило в большей части мусор), поэтому пришлось делать сначала крупные картинки (по частям генерировать фрагменты) и собирать их в фотошопе (хотел сначала в комментарии приложит именно их), но потом решил что это будет не очень понятно.
Поэтому замечательно если их переработать и написать наглядно не доказательную часть, а визуально объясняющую. Я их делал исходя из того, как их понял архитектуру с кодом и теоремы.
И чтобы добавить веса, стоит все таки провести аналогию с OpenMythos, чтобы было проще понять общую идею.
А предложенное архитектурное решение и доказательства теорем - интересные.