Спасибо за разьяснение, теперь понятно. Был не прав. С учетом описанного, согласен, что они все являются Quasi-LPV. Ранее не встречал "On the State-Space Realization of LPV Input-Output Models: Practical Approaches", хотя судя по всему работа старая.
Recurrent Transformers гораздо ближе к RNN, чем к Quasi-LPV. Они являются прямыми архитектурными наследниками рекуррентных нейросетей. Основная идея Recurrent Transformers (например RMT), это разбиение длинной последовательности на сегменты и передача информации от одного сегмента к другому через фиксированное скрытое состояние.
В классических RNN это состояние называется h(t) и обновляется через полносвязный слой. В Recurrent Transformers роль h(t) играют специальные токены памяти (memory tokens), которые обновляются с помощью механизма Self-Attention. Математический граф вычислений здесь абсолютно такой же, как у RNN: последовательный, итеративный и использующий скрытый вектор для сжатия предыстории.
Если попытаться найти хоть какое-то сходство, то механизм Attention в Recurrent Transformers можно натянуть на структуру Quasi-LPV лишь концептуально: матрицы внимания (Attention weights) вычисляются динамически на основе текущих входных данных (токенов). В ТАУ это отдаленно напоминает изменение параметров системы в зависимости от её состояния. Однако это лишь аналогия.
Про обучение и остальное согласен. К Quasi-LPV скорее относятся Mamba (SSM), но Recurrent Transformers нет, он построен на RNN, а RNN напрямую к Quasi-LPV не относится, есть только сходство/аналогия.
В рамках рекуррентных сетей, лучше рассматривать подробнее не ParaRNN и старые RNN. Сейчас в 20026 году тенденция сместилась на рекуррентные трансформеры: Recurrent Transformer, Latent Recurrent Transformer, Test-Time Memory и другие. Они сочетают RNN и старый трансформер. Именно благодаря им достигается длинна контекста в 1 млн. токенов и более. Стоит рассмотреть их в статьях.
В чистом виде от RNN мало толку, даже с учетом распараллеливания ParaRNN. Подобное решается в SSM (State Space Models) методом "сканирования". Если перенесете подобное в архитектуры выше и покажете, что это работает, то будет очень интересно.
Пока у архитектуры не будет динамической реализации predict coding, ни о каком полноценном "не знаю" не может идти речи.
Механизм predict coding, позволяет усилить альтернативные маршруты. То есть, если модель изначально ошибалась и оказалось что альтернативный маршрут "я не знаю" даёт больше вероятность чем текущий, то она переключится на него, потому что ошибка усилит его вероятности. И тогда переход "я не знаю", на множестве данных датасета (а не конкретных) будет иметь высокую вероятность.
Сейчас же, если обучать модель на конкретных данных отвечать "я не знаю", то это ничем не отличается от любого другого обучения другим ответам на конкретных данных. С таким же успехом, можно обучить отвечать "я не знаю" на текст "Маша пошла в лес".
"Я не знаю" должен быть результатом обобщения динамики ошибок при использовании predict coding.
Именно по этой же причине, модель не можем сама полноценно сама переключиться на альтернативный вариант продолжения текста. Случайный выбор токена, который может являться устойчивым альтернативным маршрутом тут не в счёт, так как это рулетка.
LLM на самом деле предсказывает множество альтернативных маршрутов. Но именно ошибка, должна усиливать наиболее сильные альтернативы.
В мозге за это отвечает слой 6. А в более глубоком погружении зона ACC. Которые выделяют ошибку, и добавляют ее на вход (если упрощённо). Это похоже на то, как Mythos сделали с добавлением выходного сигнала, подмешивая его во входной, чтобы увидеть контекст. Это делают слои 5 неокортекса и MPFC. А вот сигнал ошибки не делают. В упрощённой схеме, ACC смешивает сигнал ошибки и входной сигнал, чтобы усилить альтернативы. А MPFC смешивает выходной сигнал и вход, чтобы сохранить контекст. И уже в зависимости, что сильнее окажется влияние контекст или ошибка, то и будет наиболее вероятным продолжением.
Проблема в том, как встроить такую динамику в трансформеры и обучать с ней. Чтобы "я не знаю", "с другой стороны.." и так далее, стали результатом обобщения ошибки на множестве обучающих данных, а не конкретного ответа.
То что вы описали в статье не утверждается сегодня. Уже давно это понятие расширенно. Во второй лекции Сапольского (которая вышла лет 10 назад), тогда уже говорилось об этом. Стратегии сильно зависят от правил и среды. Более того, возникает круговорот оптимальных стратегий, и описанный в статье вариант это лишь оптимальная стратегия в конкретных условиях.
Дилемма заключённого в чистом виде уже давно не используется и не интерпретируется биологами.
Порой лучше один раз посмотреть лекции, чем сотни раз читать такое.
Эта фраза "Традиционная дилемма предполагает, что игроки действуют вслепую. " в корне не верна на сегодня. Так как рассматриваются разные стратегии, разные состояния среды. И когда игроки действуют в слепую и когда нет, и когда знают когда стратегия закончится, и когда не знают и так далее.
Недавно попадался пример "удачного" внедрения во время церемонии вручения дипломов в этом году в колледже Глендейл в Аризоне. Cистема распознавания имен (подозреваю на основе агентов) галлюцинировала. Пропустила десятки студентов, неправильно произнесла имена и делала длинные паузы, что разозлило толпу. В итоге церемония была приостановлена на несколько часов, и администрация извинялась со словами " Мы используем новую систему искусственного интеллекта в качестве считывателя текста. Так что это для нас урок ", чем сильнее разозлила всех. В итоге пригласили живого ведущего, чтобы правильно объявить имена оставшихся выпускников.
Для примера Cortical Labs и систему DishBrain, эксперимент, где культура живых нейронов училась играть в Pong.
Для многих новостей это выглядело как: нейроны играют в Pong. Но для самих авторов центральной была проверка идей Free Energy Principle и active inference.
Идея была примерно такой. Есть культура нейронов, сенсорный вход, обратная связь, возможность действия на среду.
Если системе давать предсказуемую сенсорику при правильных действиях и хаотическую/непредсказуемую при “неправильных”, то нейронная система начинает самоорганизовываться так, чтобы минимизировать непредсказуемость входов и стабилизировать сенсорный поток. Это очень близко к active inference framing.
Ключевой момент, что нейроны не знали Pong.Никто не объяснял правила, не обучал через labels, не делал supervised learning, не делал RLHF.
Нейроны вообще не знали, что такое мяч, не знали, что такое игра, не знали, что такое выигрыш. Но система адаптировала динамику, уменьшала неожиданные сенсорные состояния.
Это и было интерпретировано как минимизация surprise / variational free energy.
Это НЕ означает, что FEP доказан окончательно. И не означает, что FEP единственная теория. Но это сильный аргумент, что FEP не является бессмысленной философией и active inference имеет экспериментальную ценность.
И это уже уровень не философской работы, а повторяемых экспериментов.
Free Energy Principle построена на теории вероятности и Марковской цепи, при этом вы оперируете к Марковскому одеяло и одновременно игнорируете марковскую цепь связанную с ним (когда пишите Марковская память — это архитектурная ложь). Сюрпраз о котором вы пишите - это как раз -ln(P) где P это вероятность.
Вы получили аналог Reservoir Computing моделей (точнее семейства Attention-Enhanced RC и Liquid State Machine (LSM) и Physical Reservoir Computing и Echo State Network (ESN) ). Это, то о чем пишет в статье ниже
Фактически вы получил тоже самое (только через веса attention). У этих моделей интересный подход, но свои ограничения.
Что конкретно? Это фиксированная нелинейная динамическая система, где обучается только outputs. В ней есть некоторый фиксированный резервуар, который инициализирован случайным способом. Обучается только выход (линейный слой или MLP).
Есть разновидности с Attention. Система после обучения выдает осмысленный текст.
Проблема этих систем в не оптимальности, что-то вроде "мы хотим обучаемую динамику, но не хотим её обучать". Они плохо прогнозируют при наличии шума, разной температуре, плохая стабильность, и так далее.
Сейчас таких моделей нет, но речь о том, что они должны появиться, как часть процесса оптимизации. Так как размер таких моделей может быть меньше, так как они заточены под конкретную область.
Они явно будут работать быстрее - так как это будет означать, что токенизатор будет собран на статистике узкой специализации. То есть конструкции for if и прочие уже как токены, и вероятно редкие токены как функции частых фреймворков. Это ускоряет генерацию и уменьшает кол-во токенов. Модель уже не допустит ошибку при написании синтаксиса, так как он ее часть.
Поэтому я уверен, что такие модели будут появляться в будущем (сейчас у всех идет упор на оптимизацию), так как именно это решает бизнес задачи и приносит платежеспособных клиентов. А подобный подход существенно удешевляет развертывание таких моделей.
Их гораздо проще обучать, так как обучение Codex (GPT-5.3-Codex и Codex-5.4, и Codex-ChatGPT 5.5) и Opus прежде всего строиться на специальном подходе обучения, отличном от обучения простым текстам (дообучали). Например для программирования сетка генерирует множество разного кода, этот код запускается через компилятор, выбирается лучший на основе ошибок запуска и с ним модель обучается. Это синтетические данные. Именно поэтому сейчас некоторые делают уклон отдельных моделей под IT разработку, так как проще собрать данные для некоторых областей через корректную синтетику.
Но сейчас, небольшие модели под языки разработки пока ни кто не обучал.
Хотя квантование имеет проблемы, есть подходы к уменьшению значений до (-1, 0, 1) в Bonsai языковой модели, которая обучается с нуля. Но сейчас пока не ясно, насколько хорошо они масштабируются. Если окажется, что хорошо, то это сильно сместит акцент в языковых моделях. Насколько я знаю, исследования пока ведутся, у той же Microsoft как раз BitNet (тоже присутствует в видео).
Да про гроккинг помню статью. Я не говорю что MoE бесполезное решение, но у него есть границы и оно не всегда работает эффективно или имеет преимущество перед другими решениями.
Так же, я не утверждаю, что нам нужна куча моделей взамен больших языковых. Все зависит от оптимальности, а это много вводных: размер модели, скорость работы, точность и так далее. Безусловно для всех областей это не нужно.
Но приведу два аргумента за:
1) сегодня только попалось исследование, где обучили на множестве заболеваний (от Альцгеймера до рака) и лекарств (при чем молекулярных связях по моему - точно не помню) и модель показала результаты гораздо лучше других, так как была заточена под одну область, не было мусора, не было противоречий и лишних обобщений. В этой области такая специализированная модель оправдана, так как шум с сайта мамочки.ком не будет мешать.
2) Если токенизатор заточен под конкретную область, то модель более качественно будет строить прогноз в этой области и быстрее (токенов на прогноз уйдет меньше). Если в нем встречаются все конструкции ЯП вроде for, if и даже каких то методов, потому что они очень часто встречались (мы существенно уменьшили долю общих данных). в этом случае инференс быстрее, модель точнее (она не разделит слово "for " на "fo中" - а иногда подобное встречается в текстах). Но конечно при условии, что в токенизатор действительно попадает это все. Но такая специализация токенизатора - теоретически оправдана. Так ли это будет на практике - я не знаю.
Опять же, я не утверждаю, что все станет специализированными моделями. Речь о том, что специализация позволяет оптимизировать и вероятно часть задач будут решаться в рамках таких моделей.
Все верно, так и есть. Людей 7 млрд. и среди них даже попадаются очень редкие виды, которые изучают палеоантропологию Австралии в период за 100 тыс до 1 млн лет до нашей эры. И таких может быть всего 5 человек на 7 млрд.
Эволюция к этому не просто так пришла. То что модели сейчас ресурсоемко обучать - это другая проблема текущих архитектур и мат. теории (не в том плане что она плохая, а в том что еще не достаточно развилась в этой области).
С ростом модели и данных, возникает проблема обобщения. В реальности данные не всегда уникальны (речь про вероятность их появления) и многие пересекаются и отличаются очень слабо или лежат в небольшом диапазоне. Чем больше данных вы обобщаете, тем сильнее размываете асимметрию между ними и в какой-то момент малейший шум в данных меняет направление предсказание на другое (опечатка, длинный текст, ошибки округления и так далее).
Когда у вас цена ошибки высокая, то вам выгоднее использовать специализированные модели. Например, как муравьи - каждый выполняет свою роль, или как в ИТ где разные разработчики по своим стекам, а есть проджект и архитектор и другие. Если спросить разработчика, который узкий спец по Rust, как реализовать что-то, то он тут же скажет ответ, так как его модель обучена и предсказывает это. Но спроси человека, который обобщил множество знаний и он начнет сомневаться, как лучше сделать (продумывать общее решение). И когда дело дойдет до кода, он может сделать хуже (хотя архитектурно продумал глубже), так как редкие детали языка уже не помнит. Вот с LLM так же, при обобщении детали обобщаются и теряются. Был у вас X1=5 и X2=100, обобщили получили (X1+X2)/2 = 52.5 и если у вас разброс значений при обобщении веса был большой, то вы стираете детали. Все сложнее, но пример просто условный.
Когда же обучение происходит только в одной области данных, то у вас не будет возникать ситуаций, которые так сильно размазываются вероятности. Потому что четко: после конструкции А идет В и ни когда не встречается C (из другой области где после А могла идти С). Модель более уверенно и точно делает предсказание.
Например, вы обучили модель на романе Мастер и Маргарита. Она более точно продолжит нам моменты данного романа, чем крупная модель.
Поэтому все равно уходят и будут уходить к специализированным моделям. И это происходит уже сейчас. Вопрос только на сколько детализировано они будут разбиты.
Например, только сегодня смотрел исследование, где обучали модель на множестве заболеваний, чтобы она лучше специализировалась. И как я понимаю это значительно улучшило качество при разработке лекарств. Будут ли в ИТ разбиения на языки или на бэк/фронт/архитектура или разработка/управление разработкой/проектирование или что-то еще нельзя сказать. Все будет зависеть от стоимости затрат на обучение и поддержку.
Если окажется, то небольшие локальные модели на 24-32B при специализированном обучении только Python дают качество лучше или сопоставимое с крупными в области Python, то разработчику Python нет смысла от крупной при написании своего кода. Он просто будет локально использовать ее или арендовать недорогой доступ к ней.
Да, вы правы тут "с точностью до наоборот" /s, поэтому вы под разные специализации задач, советуете человеку разные модели. Хотя на сегодня все модели обучались на одних и тех же данных, разница какие чаще повторяли и на что делали упор при обучении.
Не понимаю, как вы утверждаете обратное, и тут же в другом месте пишете об этом же, но в другой формулировке.
Я использовал разные и 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 обучении, сам компилятор является учителем и выдает, что не правильно и мы обучаем только тогда все хорошо (генерируются множество вариантов и выбирается лучший).
Спасибо за разьяснение, теперь понятно. Был не прав. С учетом описанного, согласен, что они все являются Quasi-LPV. Ранее не встречал "On the State-Space Realization of LPV Input-Output Models: Practical Approaches", хотя судя по всему работа старая.
Recurrent Transformers гораздо ближе к RNN, чем к Quasi-LPV. Они являются прямыми архитектурными наследниками рекуррентных нейросетей.
Основная идея Recurrent Transformers (например RMT), это разбиение длинной последовательности на сегменты и передача информации от одного сегмента к другому через фиксированное скрытое состояние.
В классических RNN это состояние называется h(t) и обновляется через полносвязный слой. В Recurrent Transformers роль h(t) играют специальные токены памяти (memory tokens), которые обновляются с помощью механизма Self-Attention. Математический граф вычислений здесь абсолютно такой же, как у RNN: последовательный, итеративный и использующий скрытый вектор для сжатия предыстории.
Если попытаться найти хоть какое-то сходство, то механизм Attention в Recurrent Transformers можно натянуть на структуру Quasi-LPV лишь концептуально: матрицы внимания (Attention weights) вычисляются динамически на основе текущих входных данных (токенов). В ТАУ это отдаленно напоминает изменение параметров системы в зависимости от её состояния. Однако это лишь аналогия.
Про обучение и остальное согласен. К Quasi-LPV скорее относятся Mamba (SSM), но Recurrent Transformers нет, он построен на RNN, а RNN напрямую к Quasi-LPV не относится, есть только сходство/аналогия.
В рамках рекуррентных сетей, лучше рассматривать подробнее не ParaRNN и старые RNN. Сейчас в 20026 году тенденция сместилась на рекуррентные трансформеры: Recurrent Transformer, Latent Recurrent Transformer, Test-Time Memory и другие. Они сочетают RNN и старый трансформер. Именно благодаря им достигается длинна контекста в 1 млн. токенов и более. Стоит рассмотреть их в статьях.
Recurrent Transformer: https://arxiv.org/pdf/2604.21215
Latent Recurrent Transformer (LRT): https://www.researchgate.net/publication/405317536_Latent_Recurrent_Transformer_Architecture_Exploration_Training_Strategies_and_Scaling_Behavior
Fast Byte Latent Transformer (Fast BLT): https://arxiv.org/pdf/2605.08044
Test-Time Memory архитектуры (Test-Time Training): https://arxiv.org/pdf/2604.06169
Так же понравилась представленная на Хабре работа Sessa (Selective State Space Attention): https://habr.com/ru/articles/990704/
В чистом виде от RNN мало толку, даже с учетом распараллеливания ParaRNN. Подобное решается в SSM (State Space Models) методом "сканирования". Если перенесете подобное в архитектуры выше и покажете, что это работает, то будет очень интересно.
Пока у архитектуры не будет динамической реализации predict coding, ни о каком полноценном "не знаю" не может идти речи.
Механизм predict coding, позволяет усилить альтернативные маршруты. То есть, если модель изначально ошибалась и оказалось что альтернативный маршрут "я не знаю" даёт больше вероятность чем текущий, то она переключится на него, потому что ошибка усилит его вероятности. И тогда переход "я не знаю", на множестве данных датасета (а не конкретных) будет иметь высокую вероятность.
Сейчас же, если обучать модель на конкретных данных отвечать "я не знаю", то это ничем не отличается от любого другого обучения другим ответам на конкретных данных. С таким же успехом, можно обучить отвечать "я не знаю" на текст "Маша пошла в лес".
"Я не знаю" должен быть результатом обобщения динамики ошибок при использовании predict coding.
Именно по этой же причине, модель не можем сама полноценно сама переключиться на альтернативный вариант продолжения текста. Случайный выбор токена, который может являться устойчивым альтернативным маршрутом тут не в счёт, так как это рулетка.
https://telegra.ph/Simmetriya-v-rangovoj-teorii-chast-2-12-21
LLM на самом деле предсказывает множество альтернативных маршрутов. Но именно ошибка, должна усиливать наиболее сильные альтернативы.
В мозге за это отвечает слой 6. А в более глубоком погружении зона ACC. Которые выделяют ошибку, и добавляют ее на вход (если упрощённо). Это похоже на то, как Mythos сделали с добавлением выходного сигнала, подмешивая его во входной, чтобы увидеть контекст. Это делают слои 5 неокортекса и MPFC. А вот сигнал ошибки не делают. В упрощённой схеме, ACC смешивает сигнал ошибки и входной сигнал, чтобы усилить альтернативы. А MPFC смешивает выходной сигнал и вход, чтобы сохранить контекст. И уже в зависимости, что сильнее окажется влияние контекст или ошибка, то и будет наиболее вероятным продолжением.
Проблема в том, как встроить такую динамику в трансформеры и обучать с ней. Чтобы "я не знаю", "с другой стороны.." и так далее, стали результатом обобщения ошибки на множестве обучающих данных, а не конкретного ответа.
То что вы описали в статье не утверждается сегодня. Уже давно это понятие расширенно. Во второй лекции Сапольского (которая вышла лет 10 назад), тогда уже говорилось об этом. Стратегии сильно зависят от правил и среды. Более того, возникает круговорот оптимальных стратегий, и описанный в статье вариант это лишь оптимальная стратегия в конкретных условиях.
Дилемма заключённого в чистом виде уже давно не используется и не интерпретируется биологами.
Порой лучше один раз посмотреть лекции, чем сотни раз читать такое.
Эта фраза "Традиционная дилемма предполагает, что игроки действуют вслепую. " в корне не верна на сегодня. Так как рассматриваются разные стратегии, разные состояния среды. И когда игроки действуют в слепую и когда нет, и когда знают когда стратегия закончится, и когда не знают и так далее.
Недавно попадался пример "удачного" внедрения во время церемонии вручения дипломов в этом году в колледже Глендейл в Аризоне. Cистема распознавания имен (подозреваю на основе агентов) галлюцинировала. Пропустила десятки студентов, неправильно произнесла имена и делала длинные паузы, что разозлило толпу. В итоге церемония была приостановлена на несколько часов, и администрация извинялась со словами " Мы используем новую систему искусственного интеллекта в качестве считывателя текста. Так что это для нас урок ", чем сильнее разозлила всех. В итоге пригласили живого ведущего, чтобы правильно объявить имена оставшихся выпускников.
https://www.businessinsider.com/graduation-ceremony-ai-misses-names-boos-glendale-community-college-2026-5
Недовольны в итоге были все. В комментариях на разных ресурсах было как всегда - "да
гранатыпромпт/агенты у него не той системы" и т.д.Простой пример, как пытаются запихать нейронки ради нейронок.
Для примера Cortical Labs и систему DishBrain, эксперимент, где культура живых нейронов училась играть в Pong.
Для многих новостей это выглядело как: нейроны играют в Pong. Но для самих авторов центральной была проверка идей Free Energy Principle и active inference.
Идея была примерно такой. Есть культура нейронов, сенсорный вход, обратная связь, возможность действия на среду.
Если системе давать предсказуемую сенсорику при правильных действиях и хаотическую/непредсказуемую при “неправильных”, то нейронная система начинает самоорганизовываться так, чтобы минимизировать непредсказуемость входов и стабилизировать сенсорный поток. Это очень близко к active inference framing.
Ключевой момент, что нейроны не знали Pong.Никто не объяснял правила, не обучал через labels, не делал supervised learning, не делал RLHF.
Нейроны вообще не знали, что такое мяч, не знали, что такое игра, не знали, что такое выигрыш. Но система адаптировала динамику, уменьшала неожиданные сенсорные состояния.
Это и было интерпретировано как минимизация surprise / variational free energy.
Это НЕ означает, что FEP доказан окончательно. И не означает, что FEP единственная теория. Но это сильный аргумент, что FEP не является бессмысленной философией и active inference имеет экспериментальную ценность.
И это уже уровень не философской работы, а повторяемых экспериментов.
Free Energy Principle построена на теории вероятности и Марковской цепи, при этом вы оперируете к Марковскому одеяло и одновременно игнорируете марковскую цепь связанную с ним (когда пишите Марковская память — это архитектурная ложь). Сюрпраз о котором вы пишите - это как раз -ln(P) где P это вероятность.
Вы получили аналог Reservoir Computing моделей (точнее семейства Attention-Enhanced RC и Liquid State Machine (LSM) и Physical Reservoir Computing и Echo State Network (ESN) ). Это, то о чем пишет в статье ниже
https://habr.com/ru/articles/1028548/
Фактически вы получил тоже самое (только через веса attention). У этих моделей интересный подход, но свои ограничения.
Что конкретно? Это фиксированная нелинейная динамическая система, где обучается только outputs. В ней есть некоторый фиксированный резервуар, который инициализирован случайным способом. Обучается только выход (линейный слой или MLP).
Есть разновидности с Attention. Система после обучения выдает осмысленный текст.
Проблема этих систем в не оптимальности, что-то вроде "мы хотим обучаемую динамику, но не хотим её обучать". Они плохо прогнозируют при наличии шума, разной температуре, плохая стабильность, и так далее.
Сейчас таких моделей нет, но речь о том, что они должны появиться, как часть процесса оптимизации. Так как размер таких моделей может быть меньше, так как они заточены под конкретную область.
Они явно будут работать быстрее - так как это будет означать, что токенизатор будет собран на статистике узкой специализации. То есть конструкции for if и прочие уже как токены, и вероятно редкие токены как функции частых фреймворков. Это ускоряет генерацию и уменьшает кол-во токенов. Модель уже не допустит ошибку при написании синтаксиса, так как он ее часть.
Поэтому я уверен, что такие модели будут появляться в будущем (сейчас у всех идет упор на оптимизацию), так как именно это решает бизнес задачи и приносит платежеспособных клиентов. А подобный подход существенно удешевляет развертывание таких моделей.
Их гораздо проще обучать, так как обучение Codex (GPT-5.3-Codex и Codex-5.4, и Codex-ChatGPT 5.5) и Opus прежде всего строиться на специальном подходе обучения, отличном от обучения простым текстам (дообучали). Например для программирования сетка генерирует множество разного кода, этот код запускается через компилятор, выбирается лучший на основе ошибок запуска и с ним модель обучается. Это синтетические данные. Именно поэтому сейчас некоторые делают уклон отдельных моделей под IT разработку, так как проще собрать данные для некоторых областей через корректную синтетику.
Но сейчас, небольшие модели под языки разработки пока ни кто не обучал.
Хотя квантование имеет проблемы, есть подходы к уменьшению значений до (-1, 0, 1) в Bonsai языковой модели, которая обучается с нуля. Но сейчас пока не ясно, насколько хорошо они масштабируются. Если окажется, что хорошо, то это сильно сместит акцент в языковых моделях. Насколько я знаю, исследования пока ведутся, у той же Microsoft как раз BitNet (тоже присутствует в видео).
Да про гроккинг помню статью. Я не говорю что MoE бесполезное решение, но у него есть границы и оно не всегда работает эффективно или имеет преимущество перед другими решениями.
Так же, я не утверждаю, что нам нужна куча моделей взамен больших языковых. Все зависит от оптимальности, а это много вводных: размер модели, скорость работы, точность и так далее. Безусловно для всех областей это не нужно.
Но приведу два аргумента за:
1) сегодня только попалось исследование, где обучили на множестве заболеваний (от Альцгеймера до рака) и лекарств (при чем молекулярных связях по моему - точно не помню) и модель показала результаты гораздо лучше других, так как была заточена под одну область, не было мусора, не было противоречий и лишних обобщений. В этой области такая специализированная модель оправдана, так как шум с сайта мамочки.ком не будет мешать.
2) Если токенизатор заточен под конкретную область, то модель более качественно будет строить прогноз в этой области и быстрее (токенов на прогноз уйдет меньше). Если в нем встречаются все конструкции ЯП вроде for, if и даже каких то методов, потому что они очень часто встречались (мы существенно уменьшили долю общих данных). в этом случае инференс быстрее, модель точнее (она не разделит слово "for " на "fo中" - а иногда подобное встречается в текстах). Но конечно при условии, что в токенизатор действительно попадает это все. Но такая специализация токенизатора - теоретически оправдана. Так ли это будет на практике - я не знаю.
Опять же, я не утверждаю, что все станет специализированными моделями. Речь о том, что специализация позволяет оптимизировать и вероятно часть задач будут решаться в рамках таких моделей.
Все верно, так и есть. Людей 7 млрд. и среди них даже попадаются очень редкие виды, которые изучают палеоантропологию Австралии в период за 100 тыс до 1 млн лет до нашей эры. И таких может быть всего 5 человек на 7 млрд.
Эволюция к этому не просто так пришла. То что модели сейчас ресурсоемко обучать - это другая проблема текущих архитектур и мат. теории (не в том плане что она плохая, а в том что еще не достаточно развилась в этой области).
С ростом модели и данных, возникает проблема обобщения. В реальности данные не всегда уникальны (речь про вероятность их появления) и многие пересекаются и отличаются очень слабо или лежат в небольшом диапазоне. Чем больше данных вы обобщаете, тем сильнее размываете асимметрию между ними и в какой-то момент малейший шум в данных меняет направление предсказание на другое (опечатка, длинный текст, ошибки округления и так далее).
Когда у вас цена ошибки высокая, то вам выгоднее использовать специализированные модели. Например, как муравьи - каждый выполняет свою роль, или как в ИТ где разные разработчики по своим стекам, а есть проджект и архитектор и другие. Если спросить разработчика, который узкий спец по Rust, как реализовать что-то, то он тут же скажет ответ, так как его модель обучена и предсказывает это. Но спроси человека, который обобщил множество знаний и он начнет сомневаться, как лучше сделать (продумывать общее решение). И когда дело дойдет до кода, он может сделать хуже (хотя архитектурно продумал глубже), так как редкие детали языка уже не помнит. Вот с LLM так же, при обобщении детали обобщаются и теряются. Был у вас X1=5 и X2=100, обобщили получили (X1+X2)/2 = 52.5 и если у вас разброс значений при обобщении веса был большой, то вы стираете детали. Все сложнее, но пример просто условный.
Когда же обучение происходит только в одной области данных, то у вас не будет возникать ситуаций, которые так сильно размазываются вероятности. Потому что четко: после конструкции А идет В и ни когда не встречается C (из другой области где после А могла идти С). Модель более уверенно и точно делает предсказание.
Например, вы обучили модель на романе Мастер и Маргарита. Она более точно продолжит нам моменты данного романа, чем крупная модель.
Поэтому все равно уходят и будут уходить к специализированным моделям. И это происходит уже сейчас. Вопрос только на сколько детализировано они будут разбиты.
Например, только сегодня смотрел исследование, где обучали модель на множестве заболеваний, чтобы она лучше специализировалась. И как я понимаю это значительно улучшило качество при разработке лекарств. Будут ли в ИТ разбиения на языки или на бэк/фронт/архитектура или разработка/управление разработкой/проектирование или что-то еще нельзя сказать. Все будет зависеть от стоимости затрат на обучение и поддержку.
Если окажется, то небольшие локальные модели на 24-32B при специализированном обучении только Python дают качество лучше или сопоставимое с крупными в области Python, то разработчику Python нет смысла от крупной при написании своего кода. Он просто будет локально использовать ее или арендовать недорогой доступ к ней.
Да, вы правы тут "с точностью до наоборот" /s, поэтому вы под разные специализации задач, советуете человеку разные модели. Хотя на сегодня все модели обучались на одних и тех же данных, разница какие чаще повторяли и на что делали упор при обучении.
Не понимаю, как вы утверждаете обратное, и тут же в другом месте пишете об этом же, но в другой формулировке.
Я использовал разные и 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 обучении, сам компилятор является учителем и выдает, что не правильно и мы обучаем только тогда все хорошо (генерируются множество вариантов и выбирается лучший).