Числа -- это не сущности отдельного мира, а абстракции, продукт вполне материального мозга, так что пообождём с отменой математики. То же самое касается философии: она полезна для мотивационной составляющей, может предложить полезные модели, типа "бритвы Оккама". Но не более того.
Сознание -- это процесс, производимый организованной материей.
Пространство, время, движение, информация и законы природы -- это не самостоятельные субстанции, лишь свойства материи и её взаимодействий.
Нет никаких частиц сознания. Есть элементарные частицы и поля, которые в своей динамике дают весь наблюдаемый мир. Сознание -- это функция мозга, время, форма существования материи, законы -- абстракции, выведенные человеком для описания повторяющихся свойств той же самой материи.
Мир один, материальный, и он не нуждается в надстройке идеальных сущностей.
Нет, конечно. Я не говорю об "истинном" устройстве мира, я же не балабол. Пардон, не философ. Всё, что я могу сказать, это то, что материальный мир я могу непосредственно воспринять, поэтому для меня есть только первый мир, материальный, без дуальности. Он же последний.
Исследователи взяли "нормальные" ответы и ответы, в которых ИИ проявлял одну из перечисленных выше особенностей, а затем вычли активации нейронов, получив так называемый persona vector. Чем сильнее активации "смотрят" в направлении вектора — тем больше проявляется черта, с которой он связан.
abliterated-модели сделаны ровно по тому же принципу: ищем разницу между нежелательными вариантами ответов и вычитаем полученные вектора (упрощённо). Или control vectors из llama.cpp , который даже в примере делает ровно то же: заставляет модель вести себя более "радостно"/"грустно".
Такое "исследование" и я проводил. Самое полезное, что из этого можно вынести: действительно наблюдать, что активируется в разных ситуациях. Но предварительно нужно отчистить активации от постоянно горящих элементов, либо наблюдать только за относительными значениями. Например, я нашёл несколько цепей гиперактивированных нейронов, вся цель существования которых -- прокачка максимально возможного значения дальше вглубь сети (условный источник единиц для модели).
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Это у Вас Nested Routes не было. Не всегда проект настолько мал, что он хранится в одном репозитории, не всегда настолько статичен, что все роуты можно прописать в одном файле. Более того, разными модулями занимаются разные люди.
Профит только в том, что эти кубики заменяемы по усмотрению, т.е. гибче. Но это же и недостаток: сторонние либы регулярно устаревают: либо всё через адаптеры, либо регулярно будешь бегать и чинить несовместимости. Особенно весело, когда какой-нибудь react-router в очередной раз решает поменять форму записи своих роутов, и ты как дурак носишься по всей иерархии маршрутов и переписываешь, потому что чувство прекрасного у автора либы взыграло, и он решил всё переназвать.
Исторически это немножко не бьётся, они появились примерно в одно время, но Vue тогда был сильно другим фреймворком по стилю. Vue 3, да, был рефлексией в т.ч. на сложности с React. После React я воспринимаю Vue как такой неплохой набор best practices в одном месте: как вы правильно отметили, можно сразу садиться и писать.
В React же я вынужден использовать собственный конструктор из пакетов и конфигов, который я наработал за годы. Но я его уже наработал, так что особых трудностей у меня это не вызывает. Сейчас поглядываю на какой-нибудь SolidJS: синтаксис реакт-подобный, много всего встроено, весьма быстрый. В теории выглядит хорошо, но ничего большого я на нём пока не писал, да и слишком молодой он, чтобы полагаться на него в больших проектах.
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
Я надеялся, что там патчинг wasm worker твича, думал почитать интересный код. А по факту всего лишь прокси. Так-то, думаю, будет достаточно расширить массив qualities (именно его передаёт воркер в UI на рендеринг реакту), но делать это надо на стороне воркера, потому что запросы на смену quality уходят в него. Ну, либо можно попробовать просто патчить url-ы к index-dvr.m3u8 , там прямо в GET-запросе передаётся, что нужно ограничивать. Но этот вариант хуже тем, что тоже потребовал бы прокси.
Моды в игре должны быть разные. Если уж говорить об идеальном мире, должна быть система привилегий: "этот мод может записывать файлы в такую-то папку", "этот мод может иметь доступ в интернет", как это работает с мобильными приложениями, которые тоже пишутся множеством независимых авторов.
Мне недавно пришлось инжектить DLL и хукать одну из игр, чтобы интегрировать необходимую функциональность, потому что авторы сделали непробиваемый sandbox, который никак не может обмениваться данными с внешним миром.
Никаких там принципиальных проблем нет, такой триггер-бот не писал только ленивый. Даже я ради интереса писал, правда, не для Валоранта и сугубо из любопытства, а не чтоб нагибать. Даже вторая мышка не нужна, достаточно цепануться к кликеру основной (можно какой-нибудь esp32 воткнуть прямо в корпус мыши и запитать от неё же). И камера никакая не нужна, достаточно обычной карты видеозахвата, которая стоит у массы стримеров, т.е. не палится античитом по определению. И нейронка не нужна, достаточно motion vectors, а при наличии цветового кодирования в игре -- ещё проще. Т.е. весь бюджет такого чита -- карта захвата, микроконтроллер, ноут рядом, и немного мозгов.
Вы говорите об аимботе, это совсем другая программа.
Дообучать я тоже пробовал, но, к сожалению, если учить на коротком окне, то и консистентно оно получается только на коротком окне, затем всякие чудеса вылезают. Так что применимость такого результата сильно хуже, чем предобученные софтверными гигантами модели. А на длинном окне обучать локально мне дороговато. Но да, забавно, когда учишь на собственном коде, и оно перенимает стиль кода и комментариев.
У меня даже есть специально дообученная LLM, которая умеет более компактно представлять логику и интерфейсы внутри файлов, чтобы побольше нашего кода запихнуть в локальную модель с ограниченной длиной контекста :D
С объяснением ошибок тоже ограниченно применимо: иногда она сразу может сказать, где что пошло не так, особенно полезно при работе в незнакомом стэке. Но в случае, если мы применяем LLM для "вайб-кодинга", где ошибку выдаёт код, полученный от LLM, обилие ошибок означает плохо составленное ТЗ. Хорошее ТЗ, говорящее LLM, какие использовать алгоритмы и модули, как управлять сложностью, к каким парадигмам и шаблонам проектирования обращаться, приводят к малому количеству глупых ошибок.
Можно считать, что я использую LLM просто для того, чтобы меньше набивать пальчиками, чтобы руки не болели после работы. Либо чтобы она что-то долго и муторно искала. У меня нет задачи, чтобы она много думала и принимала важные архитектурные решения.
Я максимум кормил 200 кб доков + 100 кб модулей приложухи с запросом типа "проанализируй документацию, найди неправильно используемые / deprecated поля и методы в коде, составь список TOP 10, начиная с наиболее критичных проблем". На большее лично у меня RAM/VRAM не хватает. Ну, и у меня код предобрабатывается питоновским скриптом перед загрузкой в LLM: проставляются номера строк, немного изменяется форматирование, чтобы снизить количество токенов.
Чего им "оперировать"? Просто поглядывай на графики Needle In a Haystack для используемой тобой модели и соизмеряй риски потери контекста в соответствии с ними.
Окей, я допускаю, что различия наших позиций могут быть более семантическими, нежели сущностными.
Числа -- это не сущности отдельного мира, а абстракции, продукт вполне материального мозга, так что пообождём с отменой математики. То же самое касается философии: она полезна для мотивационной составляющей, может предложить полезные модели, типа "бритвы Оккама". Но не более того.
Всё материально. Увы и ах.
Намешали всё в кучу.
Сознание -- это процесс, производимый организованной материей.
Пространство, время, движение, информация и законы природы -- это не самостоятельные субстанции, лишь свойства материи и её взаимодействий.
Нет никаких частиц сознания. Есть элементарные частицы и поля, которые в своей динамике дают весь наблюдаемый мир. Сознание -- это функция мозга, время, форма существования материи, законы -- абстракции, выведенные человеком для описания повторяющихся свойств той же самой материи.
Мир один, материальный, и он не нуждается в надстройке идеальных сущностей.
Нет, конечно. Я не говорю об "истинном" устройстве мира, я же не балабол. Пардон, не философ. Всё, что я могу сказать, это то, что материальный мир я могу непосредственно воспринять, поэтому для меня есть только первый мир, материальный, без дуальности. Он же последний.
У вас ложная предпосылка о дуальности мира. Всё остальное, вытекающее из неё, можно выбросить в мусорную корзину сразу.
abliterated-модели сделаны ровно по тому же принципу: ищем разницу между нежелательными вариантами ответов и вычитаем полученные вектора (упрощённо). Или control vectors из llama.cpp , который даже в примере делает ровно то же: заставляет модель вести себя более "радостно"/"грустно".
Такое "исследование" и я проводил. Самое полезное, что из этого можно вынести: действительно наблюдать, что активируется в разных ситуациях. Но предварительно нужно отчистить активации от постоянно горящих элементов, либо наблюдать только за относительными значениями. Например, я нашёл несколько цепей гиперактивированных нейронов, вся цель существования которых -- прокачка максимально возможного значения дальше вглубь сети (условный источник единиц для модели).
На бэке просто уже есть наработанный набор инструментов, в т.ч. БД, которые уже отлично решают задачу хранения больших массивов данных. Теоретически, на фронт тоже можно затащить чисто клиентскую БД вместо ручной обработки и фильтрации данных, и завязать реактивность на неё, и даже можно бинарные блобы выгружать куда-нибудь в localStorage, но всё это настолько редкие и нишевые решения, что ими можно пренебречь. Да и задачи разные, не будут те же инструменты так удобны на фронте. Собственно, все стейт-менеджеры, в какой-то мере и являются простым аналогом базы данных для хранения данных и обновления UI.
Особенно весело, что из дисциплинированности бэка вытекает, что я, нажав Alt+Tab, становлюсь мгновенно более дисциплинированным, и наоборот.
Не знаю, в одном из моих проектов это не так. Я такой же программист, а не их начальник, организовывать их -- не моя работа :)
Это у Вас Nested Routes не было. Не всегда проект настолько мал, что он хранится в одном репозитории, не всегда настолько статичен, что все роуты можно прописать в одном файле. Более того, разными модулями занимаются разные люди.
Гуд, спасибо за опыт.
Профит только в том, что эти кубики заменяемы по усмотрению, т.е. гибче. Но это же и недостаток: сторонние либы регулярно устаревают: либо всё через адаптеры, либо регулярно будешь бегать и чинить несовместимости. Особенно весело, когда какой-нибудь react-router в очередной раз решает поменять форму записи своих роутов, и ты как дурак носишься по всей иерархии маршрутов и переписываешь, потому что чувство прекрасного у автора либы взыграло, и он решил всё переназвать.
Исторически это немножко не бьётся, они появились примерно в одно время, но Vue тогда был сильно другим фреймворком по стилю. Vue 3, да, был рефлексией в т.ч. на сложности с React. После React я воспринимаю Vue как такой неплохой набор best practices в одном месте: как вы правильно отметили, можно сразу садиться и писать.
В React же я вынужден использовать собственный конструктор из пакетов и конфигов, который я наработал за годы. Но я его уже наработал, так что особых трудностей у меня это не вызывает. Сейчас поглядываю на какой-нибудь SolidJS: синтаксис реакт-подобный, много всего встроено, весьма быстрый. В теории выглядит хорошо, но ничего большого я на нём пока не писал, да и слишком молодой он, чтобы полагаться на него в больших проектах.
Нет, производительностью самой системы классов на данном этапе для большинства нормально написанных проектов можно пренебречь. Я думаю, что основной причиной послужило желание избавиться от наследования и иерархии классов, которые в ООП создают самый большой объём сложности. За это мы заплатили отсутствием встроенного стейта и необходимостью использовать хуки, соблюдать правила хуков, иметь ту самую неочевидную последовательность исполнения.
Лично я не знаю одного идеального способа разработки, я писал свои проекты очень по-разному, и везде есть плюсы и минусы. Большинство программ стремится либо к "морю акторов" (много мелких блоков/функций/компонентов, взаимосвязи которых сложно проследить), либо в "монолит" (одно большое неделимое ядро со сложным, почти неопределённым состоянием и его обвязка). Всегда выбор сводится к тому, предпочитаем мы терпеть объёмную или концептуальную сложность кода. Всегда приходится прикладывать чудовищные усилия, чтобы проект представлял собой прозрачные взаимодействия фиксированного количества акторов, и в процессе роста он всё равно будет стремиться в одно из вышеописанных состояний, какой бы парадигма ни была.
Я надеялся, что там патчинг wasm worker твича, думал почитать интересный код. А по факту всего лишь прокси. Так-то, думаю, будет достаточно расширить массив qualities (именно его передаёт воркер в UI на рендеринг реакту), но делать это надо на стороне воркера, потому что запросы на смену quality уходят в него. Ну, либо можно попробовать просто патчить url-ы к index-dvr.m3u8 , там прямо в GET-запросе передаётся, что нужно ограничивать. Но этот вариант хуже тем, что тоже потребовал бы прокси.
Моды в игре должны быть разные. Если уж говорить об идеальном мире, должна быть система привилегий: "этот мод может записывать файлы в такую-то папку", "этот мод может иметь доступ в интернет", как это работает с мобильными приложениями, которые тоже пишутся множеством независимых авторов.
Мне недавно пришлось инжектить DLL и хукать одну из игр, чтобы интегрировать необходимую функциональность, потому что авторы сделали непробиваемый sandbox, который никак не может обмениваться данными с внешним миром.
Никаких там принципиальных проблем нет, такой триггер-бот не писал только ленивый. Даже я ради интереса писал, правда, не для Валоранта и сугубо из любопытства, а не чтоб нагибать. Даже вторая мышка не нужна, достаточно цепануться к кликеру основной (можно какой-нибудь esp32 воткнуть прямо в корпус мыши и запитать от неё же). И камера никакая не нужна, достаточно обычной карты видеозахвата, которая стоит у массы стримеров, т.е. не палится античитом по определению. И нейронка не нужна, достаточно motion vectors, а при наличии цветового кодирования в игре -- ещё проще. Т.е. весь бюджет такого чита -- карта захвата, микроконтроллер, ноут рядом, и немного мозгов.
Вы говорите об аимботе, это совсем другая программа.
Молодец! Возьми с полки пирожок.
Дообучать я тоже пробовал, но, к сожалению, если учить на коротком окне, то и консистентно оно получается только на коротком окне, затем всякие чудеса вылезают. Так что применимость такого результата сильно хуже, чем предобученные софтверными гигантами модели. А на длинном окне обучать локально мне дороговато. Но да, забавно, когда учишь на собственном коде, и оно перенимает стиль кода и комментариев.
У меня даже есть специально дообученная LLM, которая умеет более компактно представлять логику и интерфейсы внутри файлов, чтобы побольше нашего кода запихнуть в локальную модель с ограниченной длиной контекста :D
С объяснением ошибок тоже ограниченно применимо: иногда она сразу может сказать, где что пошло не так, особенно полезно при работе в незнакомом стэке. Но в случае, если мы применяем LLM для "вайб-кодинга", где ошибку выдаёт код, полученный от LLM, обилие ошибок означает плохо составленное ТЗ. Хорошее ТЗ, говорящее LLM, какие использовать алгоритмы и модули, как управлять сложностью, к каким парадигмам и шаблонам проектирования обращаться, приводят к малому количеству глупых ошибок.
Можно считать, что я использую LLM просто для того, чтобы меньше набивать пальчиками, чтобы руки не болели после работы. Либо чтобы она что-то долго и муторно искала. У меня нет задачи, чтобы она много думала и принимала важные архитектурные решения.
Я максимум кормил 200 кб доков + 100 кб модулей приложухи с запросом типа "проанализируй документацию, найди неправильно используемые / deprecated поля и методы в коде, составь список TOP 10, начиная с наиболее критичных проблем". На большее лично у меня RAM/VRAM не хватает. Ну, и у меня код предобрабатывается питоновским скриптом перед загрузкой в LLM: проставляются номера строк, немного изменяется форматирование, чтобы снизить количество токенов.
Чего им "оперировать"? Просто поглядывай на графики Needle In a Haystack для используемой тобой модели и соизмеряй риски потери контекста в соответствии с ними.