Интересно, насколько задача обучения адаптеров окажется осложнена разницей внутренних концепций, которыми оперируют разные модели. И какой процент преимущества от прямого доступа к KV-кэшу мы в результате потеряем на адаптере этого всего в новую форму.
Ещё было бы здорово, если бы адаптеры были частью архитектуры моделей, и они учились параллельно с основным обучением, т.е. разные модели сообща вырабатывали бы плотный "общий язык взаимодействия" ещё на этапе обучения, явно ощущая разницу между собственными рассуждениями и внешними групповыми.
Народ на Хабре очень разношёрстный, и не всем очевидно, зачем это нужно, вряд ли многие вычитывали и верифицировали эту работу: насколько оно работает, и работает ли эффективно. Лично я стараюсь юзать готовые движки и утилиты, чтобы не уходить в дебри векторной геометрии, кватернионов и всего прочего без необходимости. Поэтому для меня raycast -- это либо GetWorld()->LineTraceSingleByChannel , либо StartShapeTestLosProbe, за исключением случаев, когда нужно что-то совсем уж нестандартное. Из кастома в последний раз рисовал расчёт ближайшего расстояния (и точки соприкосновения) от произвольной точки до bounding box в мировых координатах, это максимум, что мне не лениво было накодить :).
Плюсанул: поддерживаю желание работать и что-то оптимизировать на низком уровне, хотя тоже внимательно не вычитывал, сорян.
Спасибо, посмотрю, хотя, честно, опасаюсь брать в свой код что-то такое большое, т.к. чем меньше стороннего, тем меньше придётся городить костыли при обновлении до новой версии UE. А т.к. в indie проекты тянутся пятилетку, это критично.
Ну, опять придётся пободаться с очередным мертворожденным скриптовым языком из-за NIH-синдрома разработчиков.
Пока заинтересовала реализация параллелизма, это может быть удобно, надо разбираться.
А, если говорить о будущем, то переходить лично мне на него, скорее всего, придётся, т.к.:
blueprints хрупкие, изолированные от C++ - составляющей, неудобные в review за счёт бинарного формата. Превращаются в спагетти на слишком простом коде.
C++ незащищённый от ошибок памяти или некорректного использования API самого UE. Т.е. вместо того, чтобы показать, какая строчка скрипта развалилась, у вас на каждый чих будет падать весь редактор. C++ требует перекомпиляции с закрытием редактора, либо "live coding", который в половине случаев не работает, а иногда ещё и портит blueprints (см. пункт выше). Его обвязка для UE создаёт массу сложностей при работе.
Я не отрицаю её полезность когда-то давно, в исторической перспективе. Наравне с религией, которая продвигала письменность и расширяла грамотность с целью распространения своих спор далее в популяции. Примерно одного поля ягоды.
Числа -- это не сущности отдельного мира, а абстракции, продукт вполне материального мозга, так что пообождём с отменой математики. То же самое касается философии: она полезна для мотивационной составляющей, может предложить полезные модели, типа "бритвы Оккама". Но не более того.
Сознание -- это процесс, производимый организованной материей.
Пространство, время, движение, информация и законы природы -- это не самостоятельные субстанции, лишь свойства материи и её взаимодействий.
Нет никаких частиц сознания. Есть элементарные частицы и поля, которые в своей динамике дают весь наблюдаемый мир. Сознание -- это функция мозга, время, форма существования материи, законы -- абстракции, выведенные человеком для описания повторяющихся свойств той же самой материи.
Мир один, материальный, и он не нуждается в надстройке идеальных сущностей.
Нет, конечно. Я не говорю об "истинном" устройстве мира, я же не балабол. Пардон, не философ. Всё, что я могу сказать, это то, что материальный мир я могу непосредственно воспринять, поэтому для меня есть только первый мир, материальный, без дуальности. Он же последний.
Исследователи взяли "нормальные" ответы и ответы, в которых ИИ проявлял одну из перечисленных выше особенностей, а затем вычли активации нейронов, получив так называемый persona vector. Чем сильнее активации "смотрят" в направлении вектора — тем больше проявляется черта, с которой он связан.
abliterated-модели сделаны ровно по тому же принципу: ищем разницу между нежелательными вариантами ответов и вычитаем полученные вектора (упрощённо). Или control vectors из llama.cpp , который даже в примере делает ровно то же: заставляет модель вести себя более "радостно"/"грустно".
Такое "исследование" и я проводил. Самое полезное, что из этого можно вынести: действительно наблюдать, что активируется в разных ситуациях. Но предварительно нужно отчистить активации от постоянно горящих элементов, либо наблюдать только за относительными значениями. Например, я нашёл несколько цепей гиперактивированных нейронов, вся цель существования которых -- прокачка максимально возможного значения дальше вглубь сети (условный источник единиц для модели).
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Это у Вас Nested Routes не было. Не всегда проект настолько мал, что он хранится в одном репозитории, не всегда настолько статичен, что все роуты можно прописать в одном файле. Более того, разными модулями занимаются разные люди.
Это уже какое-то свидетельство канарейки получится.
"Псс, челик, дай мобилу позвонить. А павербанк есть? А если найду?"
Киберпанк, который мы заслужили.
Ждём пятничной обновы Минюста?
Интересно, насколько задача обучения адаптеров окажется осложнена разницей внутренних концепций, которыми оперируют разные модели. И какой процент преимущества от прямого доступа к KV-кэшу мы в результате потеряем на адаптере этого всего в новую форму.
Ещё было бы здорово, если бы адаптеры были частью архитектуры моделей, и они учились параллельно с основным обучением, т.е. разные модели сообща вырабатывали бы плотный "общий язык взаимодействия" ещё на этапе обучения, явно ощущая разницу между собственными рассуждениями и внешними групповыми.
А ведь мог бы быть клининг-менеджером с горящими глазами и решать настоящие проблемы "на земле".
Про Zork знаю только из-за книги Ready Player One, но всё равно круто, что открыли.
Народ на Хабре очень разношёрстный, и не всем очевидно, зачем это нужно, вряд ли многие вычитывали и верифицировали эту работу: насколько оно работает, и работает ли эффективно. Лично я стараюсь юзать готовые движки и утилиты, чтобы не уходить в дебри векторной геометрии, кватернионов и всего прочего без необходимости. Поэтому для меня raycast -- это либо GetWorld()->LineTraceSingleByChannel , либо StartShapeTestLosProbe, за исключением случаев, когда нужно что-то совсем уж нестандартное. Из кастома в последний раз рисовал расчёт ближайшего расстояния (и точки соприкосновения) от произвольной точки до bounding box в мировых координатах, это максимум, что мне не лениво было накодить :).
Плюсанул: поддерживаю желание работать и что-то оптимизировать на низком уровне, хотя тоже внимательно не вычитывал, сорян.
Спасибо, посмотрю, хотя, честно, опасаюсь брать в свой код что-то такое большое, т.к. чем меньше стороннего, тем меньше придётся городить костыли при обновлении до новой версии UE. А т.к. в indie проекты тянутся пятилетку, это критично.
Ну, опять придётся пободаться с очередным мертворожденным скриптовым языком из-за NIH-синдрома разработчиков.
Пока заинтересовала реализация параллелизма, это может быть удобно, надо разбираться.
А, если говорить о будущем, то переходить лично мне на него, скорее всего, придётся, т.к.:
blueprints хрупкие, изолированные от C++ - составляющей, неудобные в review за счёт бинарного формата. Превращаются в спагетти на слишком простом коде.
C++ незащищённый от ошибок памяти или некорректного использования API самого UE. Т.е. вместо того, чтобы показать, какая строчка скрипта развалилась, у вас на каждый чих будет падать весь редактор. C++ требует перекомпиляции с закрытием редактора, либо "live coding", который в половине случаев не работает, а иногда ещё и портит blueprints (см. пункт выше). Его обвязка для UE создаёт массу сложностей при работе.
Я не отрицаю её полезность когда-то давно, в исторической перспективе. Наравне с религией, которая продвигала письменность и расширяла грамотность с целью распространения своих спор далее в популяции. Примерно одного поля ягоды.
Окей, я допускаю, что различия наших позиций могут быть более семантическими, нежели сущностными.
Числа -- это не сущности отдельного мира, а абстракции, продукт вполне материального мозга, так что пообождём с отменой математики. То же самое касается философии: она полезна для мотивационной составляющей, может предложить полезные модели, типа "бритвы Оккама". Но не более того.
Всё материально. Увы и ах.
Намешали всё в кучу.
Сознание -- это процесс, производимый организованной материей.
Пространство, время, движение, информация и законы природы -- это не самостоятельные субстанции, лишь свойства материи и её взаимодействий.
Нет никаких частиц сознания. Есть элементарные частицы и поля, которые в своей динамике дают весь наблюдаемый мир. Сознание -- это функция мозга, время, форма существования материи, законы -- абстракции, выведенные человеком для описания повторяющихся свойств той же самой материи.
Мир один, материальный, и он не нуждается в надстройке идеальных сущностей.
Нет, конечно. Я не говорю об "истинном" устройстве мира, я же не балабол. Пардон, не философ. Всё, что я могу сказать, это то, что материальный мир я могу непосредственно воспринять, поэтому для меня есть только первый мир, материальный, без дуальности. Он же последний.
У вас ложная предпосылка о дуальности мира. Всё остальное, вытекающее из неё, можно выбросить в мусорную корзину сразу.
abliterated-модели сделаны ровно по тому же принципу: ищем разницу между нежелательными вариантами ответов и вычитаем полученные вектора (упрощённо). Или control vectors из llama.cpp , который даже в примере делает ровно то же: заставляет модель вести себя более "радостно"/"грустно".
Такое "исследование" и я проводил. Самое полезное, что из этого можно вынести: действительно наблюдать, что активируется в разных ситуациях. Но предварительно нужно отчистить активации от постоянно горящих элементов, либо наблюдать только за относительными значениями. Например, я нашёл несколько цепей гиперактивированных нейронов, вся цель существования которых -- прокачка максимально возможного значения дальше вглубь сети (условный источник единиц для модели).
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Не знаю, в одном из моих проектов это не так. Я такой же программист, а не их начальник, организовывать их -- не моя работа :)
Это у Вас Nested Routes не было. Не всегда проект настолько мал, что он хранится в одном репозитории, не всегда настолько статичен, что все роуты можно прописать в одном файле. Более того, разными модулями занимаются разные люди.
Гуд, спасибо за опыт.