Да эту статью видел, когда пытался понять, что вы сделали:
от Фодора Language of Thought идея внутренней комбинаторной системы представлений.
от Хомского идея врождённой организации и ограничений
от Ньюэлла/Саймона символьный взгляд на вычисление
от Маслэнда и других подобных, линию Hubel–Wiesel, как раннюю зрительную кору поэтому и преположил как вы вероятно реализовали.
Но с самой статьей https://habr.com/ru/articles/1061406/ не согласен. Например, что TAPe описывает Язык Мышления мозга слишком упрощённо. Так как остается практически только обобщение, я же рассматриваю это как PMAX, когда система балансирует между обобщением и сохранением разнообразия. В случае TAPe, он слишком много уделяется merge, а отбрасывает split информации. И еще ряд других моментов. Но это уже за рамками статьи.
В остальном интересно было понять, как устроен ваш подход.
quadtree + Walsh/Harmuth (не Haar) явно было бы не достаточно. Да и в патентах 2006 года у них сказано чуть больше. Они все таки пошли дальше. То есть у них буквально изображение собирается в "слова" / "фразы", если абстрагироваться.
Если я правильно понял ваш алгоритм на основе ваших патентов и прошлых публикаций (которые сумел найти с 10995 года), то в целом у вас следующий поход. В каком-то смысле это "токенизатор" (условно), так как тут главное именно упаковка входного сигнала.
У данной модели есть цензура? На днях занимался обучение классификатора и нужно было перевести английский датасет на русский с максимальной адаптацией по стилистике. Использовал при этом Yandex AI Studio, там есть все Яндекс модели и открытые китайские.
Как итог, все Яндекс модели оказались полностью не пригодными для использования, так как при любых словах religion или нецензурных и множестве других, отвечали что не могут обсуждать эту тему. При этом открытые модели китайские развернутые у Яндекс, такими проблемами не страдали.
В целом, перевод китайские открытые модели на русский язык выполнили лучше чем Alice AI и другие от яндекса, при чем китайские от самого же яндекса.
Поэтому для бизнес задач яндекс модели полностью бесполезны. Например, делаем агентскую сеть где обрабатываем сообщения пользователей. Получается что использование Яндекс модели невозможно, так как не гарантирует ответ на простых задачах из за очень глупой цензуры по словам.
Вторая большая проблема это тариф. Почему ни где не написано, что тарификация 0.5 руб за 1000 токенов (или символов не помню), это не за генерацию LLM, а сюда так же входит и отправки/получение запросов.
Для примера, перевод датасета через Яндекс китайскую модель вышел в 11 тыс руб, аналогичный перевод через развернутую модель selectel (там автоматом предлагают развернуть такие же модели) вышел ~800 руб. Если бы я развернул сам китайскую модель то вышло бы 400-600 руб. Аналогично OpenAI обошелся бы ~7$.
И это при том, что реально использовать только китайские открытые модели, развернутые Яндексом. Но сами Яндекс модели абсолютно не пригодны для бизнес задач. Вы же понимаете, что может попасться договор среди юр документов, где решат обработать RAG или как то еще через агентов и в нем будет например поставки религиозного оборудования. Или это будет Чат бот который обрабатывает сообщения клиентов. Поэтому модели от Яндекс Alice AI и Yandex GPT - бесполезны для бизнеса.
Не увидел новых направлений, которые сейчас актуальны в ML. И вероятно доберутся и до РФ.
1) Chronos от Амазон, timesFM от Гугла (вышла новая модель обученная на 1 триллиона параметров) и другие. Как альтернатива классике cstboost, prophet, arima и другим
2) RAF и другие разновидности rag для временных рядов. Когда допустим вам надо найди схожие паттерны для прогнозов. При этом некоторые разновидности, такие как SERAF позволяет отличить причины, когда ряд схожий, но причины разные: всплеск вызван распродажей на чёрную пятницу или публикацией рекламы в тик ток у блогера. И так далее.
3) причем тут ML и harness? Как они связаны друг с другом? ML про прогнозирование, harness про построение агентского pipeline. В ML подходы описываются не через агентов, а через определенные практики: работа с выбросами, подготовка данных. Тот же пример, решение задачи out of stocks, когда надо разделять причины нехватка товара из за продаж или протухшие продукты которые выкинули, тут результат совершенно противоположенный.
4) классический ML ни куда не денется. Как использовался , так и будет использоваться. И там важна как база, так и опыт или знания применения подходов, как выше привел stock outs. Более того, скажу так, что под разные задачи и используют разные подходы в связке, та же линейная регрессия+Фурье или что то другое. Все там индивидуально и выбирается и подбирается исходя из результатов. В каком нибудь высокочастотном трейдинге будут другие подходы.
Очень странный у вас roadmap. Как NLP, LLM, RAG, агенты относятся к ML? Это скорее DS или отдельно пишут NLP, подразумевая языковые модели. Чаще вижу агентские это ближе DS , ML это про прогноз временных рядов, классификации, регрессии, кластеризации и так далее.
В том видео как раз говорилось про эту проблему температур и нестабильность в первом пункте. Но там как раз речь шла про новые работы, где показали стабильно результат, а так же что необходимая среда для него была как у геотермальных источников (это отдельно подчеркивалось), которые предположительно были в то время. Я могу ошибаться, но насколько я помню там это затрагивалось, так как описывались очень свежие работы и про отрицательные температуры прошлых работ по моему упоминалось.
На эту тему недавно попалось видео Маркова, где он подробно рассказывал о трёх важных последних открытых в этой области и детально объяснял, что они значат. Если кратко, то в результате симбиоза устойчивых компонентов, в определенной среде (правдоподобной к первичным условиям) возникают новые устойчивые компоненты.
Речь про открытия важные для саморепликации, так как они запускают механизм улучшения.
1) про аминокислоты, которые помогают нуклеотидам соединяться в короткие молекулы РНК
2) открытие реалистичного способа присоединения аминокислот к РНК без помощи ферментов и рибозимов
3) что небольшая рибозимная полимераза, способная к саморепликации
Дизайн это все таки не про красивые интерфейсы. В 2000 была книга, Интерфейс. Основы проектирования взаимодействия» (в оригинале About Face: The Essentials of Interaction Design), авторами которой являются Алан Купер, Роберт Рейманн и Дэвид Кронин.
Так вот, там речь шла про простотой и интуитивно понятный интерфейс, который. Там было рассмотрен дизайн iPod, который взяли из радио устройства. Zoom интерфейс для больниц и много всего. Целью было, минимальный и интуитивно понятный.
Дизайнер, если мы говорим про профи, это тот кто может продумать такой интерфейс. В статье вы больше описали про художника и верстка, чем дизайнера. В свое время (сейчас не знаю), продавались специальные очки с камерами, которые следили за взглядом пользователя чтобы понять, якоря и проблемы. Профессиональный дизайнер выстраивает интерфейс опираясь на этот опыт. Нейронная сеть при проектировании опирается на множество готовых шаблонов, на которых обучалась. Так как у некоторых областях цена ошибки огромная. Там пригодился пример с тумблерами на критических объектах, их решении и правильных подписях.
Потому если нужно сделать лендинг, или простой сайт, то да. А если это интернет магазин, маркетплайс, мой сеть, или другой массовый продукт или массовый, то дизайн это огромная работа.
Для примера, последнее время на youtube стало много подкастов и видео про последние статьи из arxive, там сетки автомат генерируют текст и озвучивают и генерируют картинки и видео. Выглядит красочно и прикольно, но смотреть и слушать их просто нереально. Я обычно вижу в целом о чем видео, и затем лезу в статью и разбираю через сетку. И снова в статью, чтобы понять как получены результаты. Дизайн сгенерирован в таких видео, красивый, но ценность его 0.
Это напомнило мне эпоху gif, flash и java applet. Когда они появлялись, обычные сайты начали часто лепить эту красоту. Но ценность была нулевая. Некоторые порой из-за этого предпочитали отключать загрузку, чтобы просто почитать текст в целом.
Если мы говорим про посты в телеграмм или статьях, то там это ещё критичнее. Популистские картинки и схемы делает прекрасно. Хотя и за этим надо подчищать в Photoshop постоянно. Но вот серьезные схемы, там ж... полная.
Для примера, демонстрация выше. Нейрона такое не осилит. Все что сделает это красивый мусор. Но, некоторые части она генерирует неплохо, после их чистки можно вставить в итоговое.
Например, для изображения выше:
Некоторые фрагменты были нейронкой (пирамидка).
Большая часть, это рисуешь рисунок от руки и оцифровываешь сеткой и дальше Photoshop.
Другие важные элементы - чистый Photoshop.
То есть, когда одна простая идея на картинке, то сетка справиться, хотя может переусложнить и надо зачищать в Photoshop. Но если важны детали, то только сеткой не сделать.
Поэтому, если цель получить красивую картинку, то сетка ок.
Если цель получить информативную, понятную картинку, то сетка не справиться. Так косяков будет много, и править нужно дизайнеру или самому. В случае важного UX, тут должно быть понимание, как разместить правильно, а не красиво.
Ручная отрисовка схемы
Простой пример схемы, где нейросети не справляются. Красиво рисуют - да, информативно и правильно - нет.
Не понимаю, почему на Habr так зациклились на классическом RAG. Классический это просто семантический поиск по тексту. Посмотрите уже новые подходы, складывается ощущение что в России и на Хабре очень сильное отставание в этой области различных RAG подходов.
В вашем случае лучше было бы рассмотреть например Cross-RAG. Потому что вы можете учитывать историю пациента. Кроме того, у вас могут быть разносторонние данные - например вы кодирует ЭКГ в виде временных рядов и получаете их эмбеддинги и затем можете искать схожи случаи у других пациентов (просто как пример). Но главное это то, что в вашем случае важна история пациент, и тут Cross-RAG более оптимален из-за своей архитектуры.
Cross-RAG (2025) Подход к улучшению систем генерации с привлечением внешних данных (RAG), объединяющий использование кросс-энкодеров для точного ранжирования документов или узкоспециализированные фреймворки (например, для временных рядов или кросс-языковых задач).
В классическом RAG: - ищем top-k похожих элементов - добавляем их в контекст - LLM читает всё это как текст Проблема: - модель не понимает, что из retrieved важно - контекст засоряется - retrieval работает как копипаста памяти
В Cross-RAG retrieved данные не просто текст. Они являются памятью, с которой нужно взаимодействовать через attention.
Для примера: Берём запрос (или временной ряд): X Находим top-k примеров: {d1, d2, d3, ... dk} В обычном RAG было бы: [X + d1 + d2 + ...] В Cross-RAG: найденные данные остаются отдельной памятью Затем через Cross-attention модель определяет какие части этих примеров важны именно для моего случая?
Это лучше обычного RAG, так как в классическом всё retrieved просто добавлено в prompt, модель сама должна разбираться.
Cross-RAG: - retrieval становится раздельной памятью - модель сама выбирает, что использовать
Это улучшает: - автоматически фильтрует шум - Не нужно впихивать всё в prompt - в обычном RAG, retrieved превращается в текст. В Cross-RAG сохраняется структура.
Используется в: прогнозировании временных рядов (отдельный вариант Cross-RAG ) - мультимодальные retrieval модели - длинные контекстные LLM с памятью
Напишите про PixelRAG. Странно, что про PixelRAG и CrossRAG на Хабре не писали.
Суть в чем. Сейчас, например когда делают скриншотты, которые должны вывестись при запросах RAG, то используют описание. Берет скриншот, пропускают через крупную языковую модель, чтобы она сделала к нему описание и затем используют его для поиска для сходства, чтобы потом подцепить в ответе.
PixelRAG позволяет искать по изображениям. Например табличные данные на скришоте будут иметь "представление" что это заголовки таблицы, это строчки данных, а это комментарии. Или скриншот программы, система понимает что это меню, это боковая панель, это текстовое окно и учитывает это в поиске по изображениям. То есть связывает текст с изображением через специальное латентное пространство.
Суть этого нового подхода PixelRAG в том. что он позволяет не сжирать кучу ресурсов. Там хитро кодируется это все в сжатом виде и хранится.
PixelRAG это свежее решение для поиска по изображениям. Например, если это скриншоты программ для инструкции, табличные данные, из отражение товара (ищем красную футболку по картинке). Не путать с классификацией и с OCR, тут логика и принцип другой.
А так же CrossRAG это свежая работа для решения проблемы поиска по мульти модальным данных от временных рядов до разных языков (ввели на русском и нашел на английском тоже).
И последняя работа, это новое свежее решение весны 2026 года.
Правильно условные вероятности которые приводят к накоплению траектории цепи Маркова. Это как раз правильный термин. Как квантовый связан с этим?
Сейчас данный подход отлично работает. Дает сильное ускорение при обучении. Статистика собирается заранее. В отличии от классического BPE, который выдает высокочастотный шум при начале обучения, тут токены образованны не рандомно по склейке частоты, а как небольшие траектории цепей Маркова.
Формально, правила языка это как раз и есть устойчивые траектории цепей Маркова. когда мы формируем множество комбинаций таких траекторий, то статистика самых устойчивых как раз и будет совпадать с правилами правописания, так как они встречаются чаще всего (так как этого требуют правила).
Да, это не дообучала в прямом смысле. Но это именно дообучала, если смотреть на картину в целом. В LLM самое трудозатратное это обучить веса сетки. Собрать токенизатор на корпусе русского текста - это делал и Сбер, это может сделать любой, для этого не нужны GPU. Это не трудозатратно.
И тут есть три сценария:
1) взять модель и дообучать
2) взять готовую модель, заменить токенизатор и обучить сначала эмбеддинги заморозив веса, чтобы они были согласованы с моделью и затем уже дообучать модель
3) заменить токенизатор, создать модель другой размерности (хорошо если хотя бы реально другой размерности), перенести веса и обучить сначала эмбеддинги (тоже самое дообучение но веса заморожены) и затем простое дообучение.
Так как веса модели - это практически и есть LLM, то да - это дообучать, заменив некоторые детали. И не факт, что после этого она будет работать лучше (веса под изначальный токенизатор).
От того, что мы копируем веса в другую модель и называем это инициализация - не означает, что мы создали другую модель. Еще раз, замена токенизатора и обучение эмбеддингов, чтобы согласовать их со скопированными весами не делает модель другой.
Это как взять модель OpenAI, заменить токенизатор, скопировать веса и сказать - мы не брали их модель, у нас своя и это не дообучение. Это на кого вообще рассчитано?
Я бы не говорил, что это сильно разные процессы. Веса, это самое ценное в модели, а не остальное.
Они взяли веса, по сути модель и приделали свои:
обучение подходящего для русского языка токенизатора;
обучение эмбеддингов;
Pretrain на большом объёме текстовых данных;
двухэтапный Midtrain, в ходе которого модель обучается на высококачественных данных для разных срезов, а также выучивает длинный контекст;
Alignment (но об этом этапе поговорим уже в следующей главе).
То есть, чтобы модель заработала с новым токенизатором и эмбеддингами - из надо обучить и дообучать модель, чтобы она подстриглась под них.
Я надеюсь, что читающие понимают, что именно веса этот самое главное в модели. Эмббединги обучаться под новый токенизатор.
Если кратко, Яндекс собрал токенизатор под русскую речь, взял китайскую модель (скопировал веса), обучил эмбеддинги чтобы они согласовывали новый токенизатор и веса и затем дообучали модель.
Это можно назвать как угодно, но в основе китайская модель. И завуалировать это инициализацией весов, звучит как подмена понятий. Да, напрямую не используют готовую, но это все равно китайская модель с заменой токенизатора и дообучением на своих данных.
Если хочется вызовы, то есть же UTCP как MCP без обертки а сразу обращение к API, но их сложнее контролировать. Те же Skill, но они сыроваты и есть проблемы расширяемости, так как много много скиллсов просто приводят к тому, что они игнорируются.
У меня MCP одна из проблем, что забивает контекст огромными JSON-схемам и модель теряет детали. Но она уже решена (например, паттерн Code Mode от Cloudflare или Port of Context). MCP-сервер отдает модели вместо тысячи эндпоинтов, всего два метода: search() и execute(). Короче экономия порядка 99% токенов и контекст не теряется так.
Пробовали UTCP вместо MCP в данном случае (если очень хочется связать с Claude или Cursor)?
Может быть лучше внутри использовать RLM. Это аналог LangChain но умеющий работать с большим контекстом (за счет памяти), H-MEM память и так далее. Так как в вашем случае, контекст с деталями может быть важен.
Вчера только попалось видео про два свежих исследования. Это как раз касается вашей темы. В исследованиях ставился вопрос, являются ли рассуждения LLM случайными блужданиями или нет. Суть сводилась к тому, что если ли разница между генерацией правильного и неправильного рассуждения. Проверка была на медицинских данных, так как там важно чтобы разные симптомы были объединены в правильные связи и связаны с правильными лекарствами. В случае LLM реальные и вымышленные связи дают одинаковый коэффициент правдоподобия, поэтому они равнозначные - в то время как у людей он отличается. Авторы этого и другого исследования приходят к выводу, что рассуждения являются "случайными блужданиями" созданными на основе статистических данных.
Я к тому, что единственный вариант для точной проверки (к которому вы сами и пришли) - это наличие промежуточного элемента, который проверяет хотя бы валидацию кода или связей, компилируется он или нет. Собственно так обучают LLM для кодовой базы (синтетический датасет), через генерацию множества кода различных задач и затем пропускание его через компилятор. Если проходит, то можно на этом коде обучать иначе нет.
Тут вряд ли играет роль MCP или без него, так как в вашем случае проблема та же, что и со связями симптомов в исследованиях выше. MCP это просто же микросервис с оберткой понятной для LLM. Он нужен в архитектуре только там, где обычно нужен микросервис. В вашем случае, я не понял зачем изначально MCP был там.
На самом деле теорему Геделя можно понять и представить иначе.
На рисунке выше, G это какое-то скрытое пространство с наблюдаемыми состояниями размером N.
Например, если пространство G имеет 1000 состояний, то проекция двух таких пространств в третье G3 даёт нам 1000*1000 разных комбинаций состояний. А если таких проекций не 2 а больше, то все это уже очень быстро стремиться к бесконечности.
Поэтому любая система G, вынуждена обобщать наблюдения, потому что кол-во ее состояний ограничено ее размерностью. Так как G3 имеет например размерность 100 и тогда она не может описать проекцию в него всех состояний G1 и G2.
Обобщение приводит к тому, что система вынуждена обобщать устойчивые закономерности, образуя цепи Маркова.
Но цепи Маркова тоже имеют ограниченную длину, когда вероятность траектории цепи становиться ниже порога разрешения системы.
Это приводит к тому, что система G вынуждена строить иерархию цепей Маркова со скрытыми состояниями.
Как итог, пространство G3, которое наблюдает проекцию в него состояний G1 и G2, вынуждена обобщать, балансируя между устойчивыми состояниями и многообразием системы (энтропией), из вариационного принципа.
Это значит, что наши наблюдения всегда ограничены нашей разрешающей способностью и вместимостью нашей системы из которой мы наблюдаем внешнюю динамику.
Ассиметрия это наблюдаемые различие. Симметрия это когда наблюдаемые события совпадают, хотя их природа может отличаться, поэтому она равнозначные по вероятности. График на примере анализа миллиардов текстов.
Можно предположить, что если мы бесконечно будем увеличивать размерность G, то сможем описать все. Но это не так. Дело в том, что у какой то момент, при увеличении размерности N мы уже не лучшим наше понимание. Система выходит на плато. Это связано с тем, что мы не можем различить некоторые проекции.
Например, представьте себе что у вам поступает на вход текст, по которому мы собираем статистику.
Некоторые фрагменты встречаются уникальное кол-во раз, например "ова" обозначим А, но есть фрагменты которые встречаются одинаковое кол-во раз "ыро" и "пьо" у них одинаковая статистика, в текстах они встречаются только 1 раз обозначим B.
Мы наблюдаем только A->B. И по этому наблюдению мы не можем сказать это "ова"->"ыро" или это "ова"->"пьо". Для нас как наблюдателя истинная природа B скрыта, поэтому мы теряем инфорамация о том, что такое B. Мы наблюдаем только не обобщение. Если мы не можем наблюдать конечно исходные системы G.
Поэтому невозможно построить систему, которая объясняет все. Просто потому что информация может теряться при проекции.
Не важно, это текст или это звук со светом. Для нас как наблюдателя доступна только возможность, анализа динамики и ее статистика.
Каким бы не был наш язык описания системы (нашего пространства G), он всегда будет ограничен размерностью самой системой и потерей части информации при ее наблюдении, даже если мы бесконечно будем увеличивать его размерность.
Не совсем, OpenMythos и оригинальный Mythos от Anthropic хотя технически разные вещи (потому что Anthropic не раскрывает Mythos), но изначально OpenMythos являлся попыткой воссоздать архитектуру Anthropic на основе утекших данных и научных публикаций. Поэтому архитектурно, они должны быть одинаковые или схожие. Тут об этом как раз:
Тут два главных смысла, это Рекурсивная глубина (Recurrent-Depth Transformer / Looped Transformer): на чем и построен "прорыв" Mythos связанный с цикличным использованием слоев. То есть вместо сотен последовательных уникальных слоев, модель многократно (N раз) прогоняет скрытое состояние через один и тот же базовый блок с общими весами.
И рассуждение в латентном пространстве (сейчас несколько таких архитектур было особенно с начала 2026). Тут что в оригинальной идее Mythos, что в OpenMythos процесс мышления (он же reasoning) происходит скрытно и непрерывно внутри forward. Поэтому модели не генерирует промежуточный текстовый пошаговый лог (как в CoT).
Поэтому, взяли рекуррентный трансформер и скрестили его с идеей рассуждения в латетном пространстве (с подачей изначального сигнала на вход для удержания контекста). Я бы сказал так, что Anthropic взяли удачные работы по этим направлениям и использовали в своей архитектуре. Собственно поэтому OpenMythos можно считать ближайшим аналогом.
Я не верю, что Anthropic с нуля разработали что-то свое. А вот вобрать удачные решения 2025-2026 года уверен.
Смысл в том, что рассуждения работают иначе. Там есть внутренние циклы, которые прибавляются к начальному контексту, это усиливает начальный контекст и не даёт модели терять его. Но это так же увеличивает затраты на инференс, так как требуется дополнительно до 4-8 проходов на блок (если я правильно помню из разбора архитектуры OpenMythos). Поэтому в худшем сценарии модель может потреблять в 8 раз больше расчетов на инференс.
Архитектурная разница есть. В этом случае контекст более устойчивый при рассуждении и рассуждения сразу точнее. Но при этом данная модель сильно более затратная. Я не знаю сколько циклов заложено для обычно потребителя. В описании архитектуры было до 8 циклов. Но для потребителя они могли снизить их например до 2 или 4, установить более большие пороги прекращения цикла.
Так что в любом случае данная архитектура более прожорливая. И главное преимущество, это удержание контекста. Но с учётом современного подхода, когда модели постоянно переключаются - я не уверен, что это сильно эффективно.
Три модели пишут письмо дядя Фёдора.
Это как сжимать данные одним архиватором, потом в середине процесса другим архиватором и потом продолжить снова сжимать первым.
Думаю в скором времени китайцы перенесут этот подход в открытые модели.
Это большая проблема. Но хуже, когда ты пишешь продуманный код, а другой через агентов вайбкодит и полностью меняет твой код под свою задумку, и этот код не читаемый.
У меня так на днях было, сделал развертывание архитектуры в докерах. Все прозрачно, продумано, читаемо. Другой решил сделать более универсально через GitLab сборку. Скормил агентам, те переписали, работает. Но я открыл, что ему сетка сделала и у меня глаз потек. Совершенно не читаемо, вся прозрачность улетучилась, в коде появились жёсткие пути типа ../python/3.11.5/.. и прочее. И при этом человек топит за "понятный и прозрачный код" и одновременно допускает такой дикий "вайбкодинг". Разница в том, что за прозрачный код он топит там, где силен в разработке, а не читаемый вайбкодинг ему нормально в той области где он вероятно не силен.
Поэтому я подозреваю, что за полный вайбкодинг без полного код ревью топят те, кто не понимает, что им написала сетка или не планируют потом это поддерживать (я написал, а вы сами разберитесь и поддерживайте это легаси).
Да эту статью видел, когда пытался понять, что вы сделали:
от Фодора Language of Thought идея внутренней комбинаторной системы представлений.
от Хомского идея врождённой организации и ограничений
от Ньюэлла/Саймона символьный взгляд на вычисление
от Маслэнда и других подобных, линию Hubel–Wiesel, как раннюю зрительную кору поэтому и преположил как вы вероятно реализовали.
Но с самой статьей https://habr.com/ru/articles/1061406/ не согласен. Например, что TAPe описывает Язык Мышления мозга слишком упрощённо. Так как остается практически только обобщение, я же рассматриваю это как PMAX, когда система балансирует между обобщением и сохранением разнообразия. В случае TAPe, он слишком много уделяется merge, а отбрасывает split информации. И еще ряд других моментов. Но это уже за рамками статьи.
В остальном интересно было понять, как устроен ваш подход.
quadtree + Walsh/Harmuth (не Haar) явно было бы не достаточно. Да и в патентах 2006 года у них сказано чуть больше. Они все таки пошли дальше. То есть у них буквально изображение собирается в "слова" / "фразы", если абстрагироваться.
Ваш подход очень похож на то как делают реальные нейроны в зрительной коре.
Это ближе к работам описанным в книге "как мы видим" Ричарда Маслэнд.
Ниже отрывки из книги, по памяти нашел то описание.
Скрытый текст
Если я правильно понял ваш алгоритм на основе ваших патентов и прошлых публикаций (которые сумел найти с 10995 года), то в целом у вас следующий поход. В каком-то смысле это "токенизатор" (условно), так как тут главное именно упаковка входного сигнала.
У данной модели есть цензура? На днях занимался обучение классификатора и нужно было перевести английский датасет на русский с максимальной адаптацией по стилистике. Использовал при этом Yandex AI Studio, там есть все Яндекс модели и открытые китайские.
Как итог, все Яндекс модели оказались полностью не пригодными для использования, так как при любых словах religion или нецензурных и множестве других, отвечали что не могут обсуждать эту тему. При этом открытые модели китайские развернутые у Яндекс, такими проблемами не страдали.
В целом, перевод китайские открытые модели на русский язык выполнили лучше чем Alice AI и другие от яндекса, при чем китайские от самого же яндекса.
Поэтому для бизнес задач яндекс модели полностью бесполезны. Например, делаем агентскую сеть где обрабатываем сообщения пользователей. Получается что использование Яндекс модели невозможно, так как не гарантирует ответ на простых задачах из за очень глупой цензуры по словам.
Вторая большая проблема это тариф. Почему ни где не написано, что тарификация 0.5 руб за 1000 токенов (или символов не помню), это не за генерацию LLM, а сюда так же входит и отправки/получение запросов.
Для примера, перевод датасета через Яндекс китайскую модель вышел в 11 тыс руб, аналогичный перевод через развернутую модель selectel (там автоматом предлагают развернуть такие же модели) вышел ~800 руб. Если бы я развернул сам китайскую модель то вышло бы 400-600 руб. Аналогично OpenAI обошелся бы ~7$.
И это при том, что реально использовать только китайские открытые модели, развернутые Яндексом. Но сами Яндекс модели абсолютно не пригодны для бизнес задач. Вы же понимаете, что может попасться договор среди юр документов, где решат обработать RAG или как то еще через агентов и в нем будет например поставки религиозного оборудования. Или это будет Чат бот который обрабатывает сообщения клиентов. Поэтому модели от Яндекс Alice AI и Yandex GPT - бесполезны для бизнеса.
Не увидел новых направлений, которые сейчас актуальны в ML. И вероятно доберутся и до РФ.
1) Chronos от Амазон, timesFM от Гугла (вышла новая модель обученная на 1 триллиона параметров) и другие. Как альтернатива классике cstboost, prophet, arima и другим
2) RAF и другие разновидности rag для временных рядов. Когда допустим вам надо найди схожие паттерны для прогнозов. При этом некоторые разновидности, такие как SERAF позволяет отличить причины, когда ряд схожий, но причины разные: всплеск вызван распродажей на чёрную пятницу или публикацией рекламы в тик ток у блогера. И так далее.
3) причем тут ML и harness? Как они связаны друг с другом? ML про прогнозирование, harness про построение агентского pipeline. В ML подходы описываются не через агентов, а через определенные практики: работа с выбросами, подготовка данных. Тот же пример, решение задачи out of stocks, когда надо разделять причины нехватка товара из за продаж или протухшие продукты которые выкинули, тут результат совершенно противоположенный.
4) классический ML ни куда не денется. Как использовался , так и будет использоваться. И там важна как база, так и опыт или знания применения подходов, как выше привел stock outs. Более того, скажу так, что под разные задачи и используют разные подходы в связке, та же линейная регрессия+Фурье или что то другое. Все там индивидуально и выбирается и подбирается исходя из результатов. В каком нибудь высокочастотном трейдинге будут другие подходы.
Очень странный у вас roadmap. Как NLP, LLM, RAG, агенты относятся к ML? Это скорее DS или отдельно пишут NLP, подразумевая языковые модели. Чаще вижу агентские это ближе DS , ML это про прогноз временных рядов, классификации, регрессии, кластеризации и так далее.
В том видео как раз говорилось про эту проблему температур и нестабильность в первом пункте. Но там как раз речь шла про новые работы, где показали стабильно результат, а так же что необходимая среда для него была как у геотермальных источников (это отдельно подчеркивалось), которые предположительно были в то время. Я могу ошибаться, но насколько я помню там это затрагивалось, так как описывались очень свежие работы и про отрицательные температуры прошлых работ по моему упоминалось.
На эту тему недавно попалось видео Маркова, где он подробно рассказывал о трёх важных последних открытых в этой области и детально объяснял, что они значат. Если кратко, то в результате симбиоза устойчивых компонентов, в определенной среде (правдоподобной к первичным условиям) возникают новые устойчивые компоненты.
Речь про открытия важные для саморепликации, так как они запускают механизм улучшения.
1) про аминокислоты, которые помогают нуклеотидам соединяться в короткие молекулы РНК
2) открытие реалистичного способа присоединения аминокислот к РНК без помощи ферментов и рибозимов
3) что небольшая рибозимная полимераза, способная к саморепликации
Дизайн это все таки не про красивые интерфейсы. В 2000 была книга, Интерфейс. Основы проектирования взаимодействия» (в оригинале About Face: The Essentials of Interaction Design), авторами которой являются Алан Купер, Роберт Рейманн и Дэвид Кронин.
Так вот, там речь шла про простотой и интуитивно понятный интерфейс, который. Там было рассмотрен дизайн iPod, который взяли из радио устройства. Zoom интерфейс для больниц и много всего. Целью было, минимальный и интуитивно понятный.
Дизайнер, если мы говорим про профи, это тот кто может продумать такой интерфейс. В статье вы больше описали про художника и верстка, чем дизайнера. В свое время (сейчас не знаю), продавались специальные очки с камерами, которые следили за взглядом пользователя чтобы понять, якоря и проблемы. Профессиональный дизайнер выстраивает интерфейс опираясь на этот опыт. Нейронная сеть при проектировании опирается на множество готовых шаблонов, на которых обучалась. Так как у некоторых областях цена ошибки огромная. Там пригодился пример с тумблерами на критических объектах, их решении и правильных подписях.
Потому если нужно сделать лендинг, или простой сайт, то да. А если это интернет магазин, маркетплайс, мой сеть, или другой массовый продукт или массовый, то дизайн это огромная работа.
Для примера, последнее время на youtube стало много подкастов и видео про последние статьи из arxive, там сетки автомат генерируют текст и озвучивают и генерируют картинки и видео. Выглядит красочно и прикольно, но смотреть и слушать их просто нереально. Я обычно вижу в целом о чем видео, и затем лезу в статью и разбираю через сетку. И снова в статью, чтобы понять как получены результаты. Дизайн сгенерирован в таких видео, красивый, но ценность его 0.
Это напомнило мне эпоху gif, flash и java applet. Когда они появлялись, обычные сайты начали часто лепить эту красоту. Но ценность была нулевая. Некоторые порой из-за этого предпочитали отключать загрузку, чтобы просто почитать текст в целом.
Если мы говорим про посты в телеграмм или статьях, то там это ещё критичнее. Популистские картинки и схемы делает прекрасно. Хотя и за этим надо подчищать в Photoshop постоянно. Но вот серьезные схемы, там ж... полная.
Для примера, демонстрация выше. Нейрона такое не осилит. Все что сделает это красивый мусор. Но, некоторые части она генерирует неплохо, после их чистки можно вставить в итоговое.
Например, для изображения выше:
Некоторые фрагменты были нейронкой (пирамидка).
Большая часть, это рисуешь рисунок от руки и оцифровываешь сеткой и дальше Photoshop.
Другие важные элементы - чистый Photoshop.
То есть, когда одна простая идея на картинке, то сетка справиться, хотя может переусложнить и надо зачищать в Photoshop. Но если важны детали, то только сеткой не сделать.
Поэтому, если цель получить красивую картинку, то сетка ок.
Если цель получить информативную, понятную картинку, то сетка не справиться. Так косяков будет много, и править нужно дизайнеру или самому. В случае важного UX, тут должно быть понимание, как разместить правильно, а не красиво.
Простой пример схемы, где нейросети не справляются. Красиво рисуют - да, информативно и правильно - нет.
Не понимаю, почему на Habr так зациклились на классическом RAG. Классический это просто семантический поиск по тексту. Посмотрите уже новые подходы, складывается ощущение что в России и на Хабре очень сильное отставание в этой области различных RAG подходов.
В вашем случае лучше было бы рассмотреть например Cross-RAG. Потому что вы можете учитывать историю пациента. Кроме того, у вас могут быть разносторонние данные - например вы кодирует ЭКГ в виде временных рядов и получаете их эмбеддинги и затем можете искать схожи случаи у других пациентов (просто как пример). Но главное это то, что в вашем случае важна история пациент, и тут Cross-RAG более оптимален из-за своей архитектуры.
Cross-RAG (2025) Подход к улучшению систем генерации с привлечением внешних данных (RAG), объединяющий использование кросс-энкодеров для точного ранжирования документов или узкоспециализированные фреймворки (например, для временных рядов или кросс-языковых задач).
В классическом RAG:
- ищем top-k похожих элементов
- добавляем их в контекст
- LLM читает всё это как текст
Проблема:
- модель не понимает, что из retrieved важно
- контекст засоряется
- retrieval работает как копипаста памяти
В Cross-RAG retrieved данные не просто текст. Они являются памятью, с которой нужно взаимодействовать через attention.
Для примера:
Берём запрос (или временной ряд): X
Находим top-k примеров: {d1, d2, d3, ... dk}
В обычном RAG было бы: [X + d1 + d2 + ...]
В Cross-RAG: найденные данные остаются отдельной памятью
Затем через Cross-attention модель определяет какие части этих примеров важны именно для моего случая?
Это лучше обычного RAG, так как в классическом всё retrieved просто добавлено в prompt, модель сама должна разбираться.
Cross-RAG:
- retrieval становится раздельной памятью
- модель сама выбирает, что использовать
Это улучшает:
- автоматически фильтрует шум
- Не нужно впихивать всё в prompt
- в обычном RAG, retrieved превращается в текст. В Cross-RAG сохраняется структура.
Используется в:
прогнозировании временных рядов (отдельный вариант Cross-RAG )
- мультимодальные retrieval модели
- длинные контекстные LLM с памятью
https://arxiv.org/abs/2603.14709
https://github.com/seunghan96/cross-rag/
Напишите про PixelRAG. Странно, что про PixelRAG и CrossRAG на Хабре не писали.
Суть в чем. Сейчас, например когда делают скриншотты, которые должны вывестись при запросах RAG, то используют описание. Берет скриншот, пропускают через крупную языковую модель, чтобы она сделала к нему описание и затем используют его для поиска для сходства, чтобы потом подцепить в ответе.
PixelRAG позволяет искать по изображениям. Например табличные данные на скришоте будут иметь "представление" что это заголовки таблицы, это строчки данных, а это комментарии.
Или скриншот программы, система понимает что это меню, это боковая панель, это текстовое окно и учитывает это в поиске по изображениям. То есть связывает текст с изображением через специальное латентное пространство.
Суть этого нового подхода PixelRAG в том. что он позволяет не сжирать кучу ресурсов. Там хитро кодируется это все в сжатом виде и хранится.
https://www.youtube.com/watch?v=xpmxkU-0Lgc
https://youtu.be/a4AoZIZ6s7A?si=j8Oy2wrYQLNT06nq
PixelRAG это свежее решение для поиска по изображениям. Например, если это скриншоты программ для инструкции, табличные данные, из отражение товара (ищем красную футболку по картинке). Не путать с классификацией и с OCR, тут логика и принцип другой.
А так же CrossRAG это свежая работа для решения проблемы поиска по мульти модальным данных от временных рядов до разных языков (ввели на русском и нашел на английском тоже).
И последняя работа, это новое свежее решение весны 2026 года.
Правильно условные вероятности которые приводят к накоплению траектории цепи Маркова. Это как раз правильный термин. Как квантовый связан с этим?
Сейчас данный подход отлично работает. Дает сильное ускорение при обучении. Статистика собирается заранее. В отличии от классического BPE, который выдает высокочастотный шум при начале обучения, тут токены образованны не рандомно по склейке частоты, а как небольшие траектории цепей Маркова.
Формально, правила языка это как раз и есть устойчивые траектории цепей Маркова. когда мы формируем множество комбинаций таких траекторий, то статистика самых устойчивых как раз и будет совпадать с правилами правописания, так как они встречаются чаще всего (так как этого требуют правила).
Да, это не дообучала в прямом смысле. Но это именно дообучала, если смотреть на картину в целом. В LLM самое трудозатратное это обучить веса сетки. Собрать токенизатор на корпусе русского текста - это делал и Сбер, это может сделать любой, для этого не нужны GPU. Это не трудозатратно.
И тут есть три сценария:
1) взять модель и дообучать
2) взять готовую модель, заменить токенизатор и обучить сначала эмбеддинги заморозив веса, чтобы они были согласованы с моделью и затем уже дообучать модель
3) заменить токенизатор, создать модель другой размерности (хорошо если хотя бы реально другой размерности), перенести веса и обучить сначала эмбеддинги (тоже самое дообучение но веса заморожены) и затем простое дообучение.
Так как веса модели - это практически и есть LLM, то да - это дообучать, заменив некоторые детали. И не факт, что после этого она будет работать лучше (веса под изначальный токенизатор).
От того, что мы копируем веса в другую модель и называем это инициализация - не означает, что мы создали другую модель. Еще раз, замена токенизатора и обучение эмбеддингов, чтобы согласовать их со скопированными весами не делает модель другой.
Это как взять модель OpenAI, заменить токенизатор, скопировать веса и сказать - мы не брали их модель, у нас своя и это не дообучение. Это на кого вообще рассчитано?
Я бы не говорил, что это сильно разные процессы. Веса, это самое ценное в модели, а не остальное.
Они взяли веса, по сути модель и приделали свои:
обучение подходящего для русского языка токенизатора;
обучение эмбеддингов;
Pretrain на большом объёме текстовых данных;
двухэтапный Midtrain, в ходе которого модель обучается на высококачественных данных для разных срезов, а также выучивает длинный контекст;
Alignment (но об этом этапе поговорим уже в следующей главе).
То есть, чтобы модель заработала с новым токенизатором и эмбеддингами - из надо обучить и дообучать модель, чтобы она подстриглась под них.
Я надеюсь, что читающие понимают, что именно веса этот самое главное в модели. Эмббединги обучаться под новый токенизатор.
Если кратко, Яндекс собрал токенизатор под русскую речь, взял китайскую модель (скопировал веса), обучил эмбеддинги чтобы они согласовывали новый токенизатор и веса и затем дообучали модель.
Это можно назвать как угодно, но в основе китайская модель. И завуалировать это инициализацией весов, звучит как подмена понятий. Да, напрямую не используют готовую, но это все равно китайская модель с заменой токенизатора и дообучением на своих данных.
Если хочется вызовы, то есть же UTCP как MCP без обертки а сразу обращение к API, но их сложнее контролировать. Те же Skill, но они сыроваты и есть проблемы расширяемости, так как много много скиллсов просто приводят к тому, что они игнорируются.
У меня MCP одна из проблем, что забивает контекст огромными JSON-схемам и модель теряет детали. Но она уже решена (например, паттерн Code Mode от Cloudflare или Port of Context). MCP-сервер отдает модели вместо тысячи эндпоинтов, всего два метода: search() и execute(). Короче экономия порядка 99% токенов и контекст не теряется так.
Пробовали UTCP вместо MCP в данном случае (если очень хочется связать с Claude или Cursor)?
Может быть лучше внутри использовать RLM. Это аналог LangChain но умеющий работать с большим контекстом (за счет памяти), H-MEM память и так далее. Так как в вашем случае, контекст с деталями может быть важен.
Вчера только попалось видео про два свежих исследования. Это как раз касается вашей темы. В исследованиях ставился вопрос, являются ли рассуждения LLM случайными блужданиями или нет. Суть сводилась к тому, что если ли разница между генерацией правильного и неправильного рассуждения. Проверка была на медицинских данных, так как там важно чтобы разные симптомы были объединены в правильные связи и связаны с правильными лекарствами. В случае LLM реальные и вымышленные связи дают одинаковый коэффициент правдоподобия, поэтому они равнозначные - в то время как у людей он отличается. Авторы этого и другого исследования приходят к выводу, что рассуждения являются "случайными блужданиями" созданными на основе статистических данных.
Я к тому, что единственный вариант для точной проверки (к которому вы сами и пришли) - это наличие промежуточного элемента, который проверяет хотя бы валидацию кода или связей, компилируется он или нет. Собственно так обучают LLM для кодовой базы (синтетический датасет), через генерацию множества кода различных задач и затем пропускание его через компилятор. Если проходит, то можно на этом коде обучать иначе нет.
Тут вряд ли играет роль MCP или без него, так как в вашем случае проблема та же, что и со связями симптомов в исследованиях выше. MCP это просто же микросервис с оберткой понятной для LLM. Он нужен в архитектуре только там, где обычно нужен микросервис. В вашем случае, я не понял зачем изначально MCP был там.
На самом деле теорему Геделя можно понять и представить иначе.
На рисунке выше, G это какое-то скрытое пространство с наблюдаемыми состояниями размером N.
Например, если пространство G имеет 1000 состояний, то проекция двух таких пространств в третье G3 даёт нам 1000*1000 разных комбинаций состояний. А если таких проекций не 2 а больше, то все это уже очень быстро стремиться к бесконечности.
Поэтому любая система G, вынуждена обобщать наблюдения, потому что кол-во ее состояний ограничено ее размерностью. Так как G3 имеет например размерность 100 и тогда она не может описать проекцию в него всех состояний G1 и G2.
Обобщение приводит к тому, что система вынуждена обобщать устойчивые закономерности, образуя цепи Маркова.
Но цепи Маркова тоже имеют ограниченную длину, когда вероятность траектории цепи становиться ниже порога разрешения системы.
Это приводит к тому, что система G вынуждена строить иерархию цепей Маркова со скрытыми состояниями.
Как итог, пространство G3, которое наблюдает проекцию в него состояний G1 и G2, вынуждена обобщать, балансируя между устойчивыми состояниями и многообразием системы (энтропией), из вариационного принципа.
Это значит, что наши наблюдения всегда ограничены нашей разрешающей способностью и вместимостью нашей системы из которой мы наблюдаем внешнюю динамику.
Можно предположить, что если мы бесконечно будем увеличивать размерность G, то сможем описать все. Но это не так. Дело в том, что у какой то момент, при увеличении размерности N мы уже не лучшим наше понимание. Система выходит на плато. Это связано с тем, что мы не можем различить некоторые проекции.
Например, представьте себе что у вам поступает на вход текст, по которому мы собираем статистику.
Некоторые фрагменты встречаются уникальное кол-во раз, например "ова" обозначим А, но есть фрагменты которые встречаются одинаковое кол-во раз "ыро" и "пьо" у них одинаковая статистика, в текстах они встречаются только 1 раз обозначим B.
Мы наблюдаем только A->B. И по этому наблюдению мы не можем сказать это "ова"->"ыро" или это "ова"->"пьо". Для нас как наблюдателя истинная природа B скрыта, поэтому мы теряем инфорамация о том, что такое B. Мы наблюдаем только не обобщение. Если мы не можем наблюдать конечно исходные системы G.
Поэтому невозможно построить систему, которая объясняет все. Просто потому что информация может теряться при проекции.
Не важно, это текст или это звук со светом. Для нас как наблюдателя доступна только возможность, анализа динамики и ее статистика.
Каким бы не был наш язык описания системы (нашего пространства G), он всегда будет ограничен размерностью самой системой и потерей части информации при ее наблюдении, даже если мы бесконечно будем увеличивать его размерность.
Все немного сложнее, но надеюсь объяснил понятно.
Не совсем, OpenMythos и оригинальный Mythos от Anthropic хотя технически разные вещи (потому что Anthropic не раскрывает Mythos), но изначально OpenMythos являлся попыткой воссоздать архитектуру Anthropic на основе утекших данных и научных публикаций. Поэтому архитектурно, они должны быть одинаковые или схожие. Тут об этом как раз:
https://juliangoldie.com/open-mythos/
Аналогично тут:https://skillsllm.com/skill/openmythos
Тут два главных смысла, это Рекурсивная глубина (Recurrent-Depth Transformer / Looped Transformer): на чем и построен "прорыв" Mythos связанный с цикличным использованием слоев. То есть вместо сотен последовательных уникальных слоев, модель многократно (N раз) прогоняет скрытое состояние через один и тот же базовый блок с общими весами.
И рассуждение в латентном пространстве (сейчас несколько таких архитектур было особенно с начала 2026). Тут что в оригинальной идее Mythos, что в OpenMythos процесс мышления (он же reasoning) происходит скрытно и непрерывно внутри forward. Поэтому модели не генерирует промежуточный текстовый пошаговый лог (как в CoT).
Поэтому, взяли рекуррентный трансформер и скрестили его с идеей рассуждения в латетном пространстве (с подачей изначального сигнала на вход для удержания контекста). Я бы сказал так, что Anthropic взяли удачные работы по этим направлениям и использовали в своей архитектуре. Собственно поэтому OpenMythos можно считать ближайшим аналогом.
Я не верю, что Anthropic с нуля разработали что-то свое. А вот вобрать удачные решения 2025-2026 года уверен.
У Mythos есть отличие. Тут описывал:
https://habr.com/ru/companies/gazprombank/articles/1026124/comments/#comment_29866508
Смысл в том, что рассуждения работают иначе. Там есть внутренние циклы, которые прибавляются к начальному контексту, это усиливает начальный контекст и не даёт модели терять его. Но это так же увеличивает затраты на инференс, так как требуется дополнительно до 4-8 проходов на блок (если я правильно помню из разбора архитектуры OpenMythos). Поэтому в худшем сценарии модель может потреблять в 8 раз больше расчетов на инференс.
Архитектурная разница есть. В этом случае контекст более устойчивый при рассуждении и рассуждения сразу точнее. Но при этом данная модель сильно более затратная. Я не знаю сколько циклов заложено для обычно потребителя. В описании архитектуры было до 8 циклов. Но для потребителя они могли снизить их например до 2 или 4, установить более большие пороги прекращения цикла.
Так что в любом случае данная архитектура более прожорливая. И главное преимущество, это удержание контекста. Но с учётом современного подхода, когда модели постоянно переключаются - я не уверен, что это сильно эффективно.
Это как сжимать данные одним архиватором, потом в середине процесса другим архиватором и потом продолжить снова сжимать первым.
Думаю в скором времени китайцы перенесут этот подход в открытые модели.
Это большая проблема. Но хуже, когда ты пишешь продуманный код, а другой через агентов вайбкодит и полностью меняет твой код под свою задумку, и этот код не читаемый.
У меня так на днях было, сделал развертывание архитектуры в докерах. Все прозрачно, продумано, читаемо. Другой решил сделать более универсально через GitLab сборку. Скормил агентам, те переписали, работает. Но я открыл, что ему сетка сделала и у меня глаз потек. Совершенно не читаемо, вся прозрачность улетучилась, в коде появились жёсткие пути типа ../python/3.11.5/.. и прочее. И при этом человек топит за "понятный и прозрачный код" и одновременно допускает такой дикий "вайбкодинг". Разница в том, что за прозрачный код он топит там, где силен в разработке, а не читаемый вайбкодинг ему нормально в той области где он вероятно не силен.
Поэтому я подозреваю, что за полный вайбкодинг без полного код ревью топят те, кто не понимает, что им написала сетка или не планируют потом это поддерживать (я написал, а вы сами разберитесь и поддерживайте это легаси).