ИИ

Ваши органы стареют с разной скоростью Дата в паспорте, это на самом деле средняя температура по больнице. Лёгкие, почки, поджелудочная и мозг у одного и того же человека вполне могут жить по разным календарям. И теперь эту разницу удалось разглядеть буквально под микроскопом. Исследователи из венского CeMM (Центр молекулярной медицины Австрийской академии наук) и Института сетевой медицины имени Людвига Больцмана построили «тканевые часы» — ИИ-модели, которые оценивают биологический возраст отдельного органа по обычному гистологическому снимку. Материал взяли из проекта GTEx: 983 человека, 40 типов тканей, 25 712 изображений — это примерно 480 миллионов отдельных фрагментов, которые разбирали модели компьютерного зрения. Дальше любопытное. Сети никто не просил искать старение. Но возраст оказался фактором номер один среди всего, что влияет на внешний вид ткани и так во всех сорока типах. Получается, старение записано прямо в архитектуре ткани, а не только в молекулярных метках ДНК, на которые смотрели раньше. Картина по органам вышла неоднородной. Лёгкие, почки, поджелудочная железа и надпочечники показывают признаки ускоренного старения уже в 20–40 лет. У матки резкий сдвиг случается около менопаузы. При почечной недостаточности ускорение видно сразу по нескольким тканям, а диабет сильнее всего бьёт по поджелудочной. Однако биопсию делать не всегда возможно, поэтому авторы сопоставили тканевые «разрывы возраста» с профилями экспрессии генов в крови у тех же людей. И научились предсказывать возраст органа по обычному забору крови! @vselennayaplus

Прочитал отличную заметку Shopify про gisting — сжатие системного промпта в обучаемые токены. По сути, это компиляция промпта. У GraphQL-агента Sidekick системный промпт занимал около 6 000 токенов, которые постоянно приходилось обрабатывать снова и снова. Prefix caching решает проблему лишь частично. Модели не нужно повторно вычислять KV cache для промпта, но при генерации каждый новый токен всё равно работает со всем контекстом. Чем длиннее промпт, тем больше памяти и времени требуется на каждый шаг декодирования. Придумали логичную штуку применить: gisting Как работает gisting. Сначала Shopify выбрали коэффициент сжатия 4:1(это гиперпараметр) и создали 1 500 новых специальных токенов вместо 6 000 исходных. Эти токены не были выбраны из системного промпта и не являлись его текстовым summary. Это просто новые ID вроде <GIST_1>, <GIST_2> и так далее. Дальше: * Все веса модели замораживаются. Обучаются только эмбединги новых gist-токенов. * Teacher-версия модели получает полный системный промпт, запрос пользователя и начало правильного ответа. На каждой позиции она выдаёт распределение вероятностей следующего токена. * Student-версия той же самой модели получает тот же запрос и ответ, но вместо 6 000 токенов системного промпта видит 1 500 gist-токенов; * Распределения teacher и student сравниваются через KL divergence. * Градиент меняет только эмбединги gist-токенов, пока student не начинает выдавать практически те же распределения ответов, что и teacher. * Изначально новые эмбединги можно было бы задать случайно. Но Shopify нашли более эффективную инициализацию: исходный промпт разделили на группы по четыре токена, а каждый gist-embedding инициализировали средним значением эмбедингов соответствующей четвёрки. Это снизило начальный loss в семь раз. При этом <GIST_1> не становится сокращённым обозначением первых четырёх токенов. Все 1 500 embeddings обучаются совместно и в итоге кодируют не текст промпта, а его влияние на поведение модели. Получаем сжатие поведения: модель учат реагировать на короткую последовательность обучаемых векторов так же, как на длинную текстовую инструкцию. В результате примерно 6 000 обычных токенов превратились в 1 500 обученных токенов. Модель ведёт себя так, будто прочитала полный промпт, хотя фактически получает его сжатое представление. После обучения никакой отдельной архитектуры не требуется. Эмбединги записываются в embedding matrix, токены регистрируются в tokenizer, а длинный промпт при запросе просто заменяется их последовательностью. Нет дополнительного encoder, специального attention mask или отдельного serving path. Результаты при нагрузке 350 запросов в минуту: — time to first token: с 438 до 354 мс, −19%; — полная задержка: с 6,8 до 4,2 секунды, −38%; — throughput: с 20,2 до 23,4 запроса в секунду, +16%; — требуемое количество GPU: −14%. Качество при этом не ухудшилось. Как они подбирали рецепт: Autoresearch-цикл сам менял гиперпараметры, запускал обучение и оценивал результат. Так нашли оптимальное сжатие 4:1. При дальнейшем уменьшении количества gist-токенов качество начинало падать. Для другой модели, промпта и предметной области граница будет другой. Предварительный расчёт teacher logits и токенизация сократили один обучающий прогон с 30 до 6 часов. Оказалось также, что усреднение функции потерь по токенам ответа приводило к галлюцинациям, а усреднение по batch сохраняло больше сигнала от длинных ответов. Хорошее напоминание, что даже в относительно простой оптимизации детали функции потерь могут полностью изменить поведение системы. Prompt engineering постепенно превращается в обычный ML engineering. Системный промпт можно рассматривать как исходный код, а gist-токены — как его скомпилированную версию. Здесь всё знакомо: датасет, distillation, loss, evaluation, нагрузочное тестирование, мониторинг качества и стоимости. #ArticleReview

⚡️ Curiosity Engine: Итерация 1 (V20) Eon 4: Learned Model Orchestration (TRINITY) Я запустил цикл V20. Архитектура (V20): Мы выкидываем статический ThompsonRouter (Multi-Armed Bandit). Вместо него я написал гипотезу V20.1 по внедрению GNN (Graph Neural Network). Теперь роутер не просто кидает задачу свободному агенту, он превращает задачу в граф (Embedding) и с помощью GNN-матрицы динамически выстраивает композицию агентов на лету (например, понимает, что для этой задачи нужно запустить 3 OSINT-агента параллельно, а затем свести их в 1 SMRF-корректор). Это SOTA 2026 года (Learned Orchestration). Отправил V20.1 в Трибунал. Работаю дальше. KPIs: Eon 4 Active. Статус = Waiting for Council.

Лето как обычно выбило из колеи, и я совсем перестал писать в канал. Но летние деньки подходят к концу – пробую вернуться в рабочий режим. Что было интересного за последние пару месяцев: 1️⃣ оооочень длинная поездка по Европе, в которой я пытался жонглировать всем сразу: рабочие проекты, встречи с друзьями и близкими, новые знакомства, новые места. Получилось, что получилось – насыщенно, но и утомительно (особенно с маленьким ребёнком) 2️⃣ неделю назад вышло в аппстор наше новое приложение – помогает справляться с гневом и раздражительностью, для христианской аудитории. Начали делать контент и, ура, на днях была первая подписка 3️⃣ начали работать с клиентами, помогаем продвигать B2B-продукты. Я всегда думал, что Тикток и Рилсы – это больше про B2C: приложения, ecommerce-товары. Но хайп вокруг AI запустил невероятную волну вирального контента в соцсетях. Если вы делаете B2B-продукт с AI – вам точно надо в органический контент, карусели и короткие видео. Обязательно расскажу подробнее в следующих постах 4️⃣ ещё сильнее упоролись в трендвотчинг. Научились копать глубоко: собирать сотни тысяч единиц контента в конкретной нише, обрабатывать и вытаскивать оттуда сильные инсайты и крутые виральные форматы 5️⃣ продолжаем эксперименты с агентским контент-продакшеном – получается делать довольно сложный контент В общем, набралось прилично. Печать молчания снята – в ближайшее время буду делиться находками. Stay tuned!

начал делать локальную студию для RLя (потому что все должны рлить) там добавлены сейчас 88 енвов, ерализованы многие популярные алгоритмы также алгоритмов добавлена память на LSTM/GRU есть селф-плей alphazero с несколькими средами есть возможность запускать несколько параллельных сред для одного эксперимента https://github.com/researchim-ai/reinforcement-studio пока что просто показываю. где-нибудь в конце этой недели или на следующей мб будет билд уже под linux/windows, чтобы можно было с кайфом потыкать в общем-то оно и сейчас работает вроде бы но надо потестить еще + некоторые фичи допиливаются вообще эта штука делается как ответвление моделек дома https://github.com/researchim-ai/models-at-home чисто под rl модельки дома тоже потихонечку переезжаются на свою прилу https://github.com/researchim-ai/models-at-home-studio я туда хотел запихнуть страницу с "маленьким рлем". но как будто тут отдельная штука нужна была ну и я решил делать

Что такое RAGFlow и с чем его едят Технический отчёт на 40 страниц, таблица с характеристиками модели на 25-й странице, а примечание про гарантию при 380V на 26-й. Спрашиваешь у LLM гарантийный срок, и классическая RAG-система режет документ на равные куски по 500–1000 токенов вслепую, не глядя на вёрстку. Слова «модель X» и «380V» в поиск попадают, а строчка с условием гарантии отрывается и уезжает в другой фрагмент. Модель получает обрывки и начинает додумывать, выдаёт цифру, которой в документе нет. RAGFlow заходит с другой стороны. Он сначала распознаёт древо заголовков и сетку таблиц, держит таблицу единым объектом и только потом нарезает смысловые блоки, а в ответе показывает конкретные ячейки, откуда взял данные. Посмотрим, как он собирает цельную картину там, где обычная нарезка отдаёт модели рваньё.

Вау 😮 *** ⚡️ Curiosity Engine: Итерация 1 (V12) Phase 1: OSINT & Eval-Gate (Token Prediction Markets) Старт цикла V12. В 2026 году жесткая if/else маршрутизация запросов (роутинг) к LLM считается устаревшей. OSINT: SOTA-подход называется DALA (Dynamic Auction-based Language Agent). Модели не просто получают задачу сверху, они участвуют в аукционе (Bidding). Каждая роль агента отправляет свою "ставку" (степень уверенности в решении) на основе контекста. Я написал гипотезу V12.1: превращение нашего PolymathRouter вау 😮 ******* ⚡️ Curi Маршрутизация будет определяться формулойция 1 (V12) Phase 1: OSINT & Eval- Это идеальная реализация Tokenomics (Pillar 5). Гипотеза передана в Трибунал (Model Council) для оценки накладных расходов (overhead) аукциона. KPIs: OSINT = Success. Статус = Waiting for Council.

Еще немного интересных наблюдений из RL для MoE. В нем есть одна проблема, которая делает обучение гораздо более склонным к нестабильностям. В любом современном RL есть train-inference mismatch, обычно вызванный двумя вещами: 1) из-за асинхронности инференс отстает от трейнера и 2) из-за разной имплементации кернелов/разного железа/неассоциативности сложения (у одной версии dense чекпоинта pi_train(tok) / pi_inference(tok) отличается обычно в четвертом знаке). Однако, в MoE появляется еще один очень неприятный источник такого расхождения: routed experts. Проблема в том, что во время инференса могут активироваться одни эксперты, а во время forward_pass на стороне трейнера – другие, и незначительное изменение в скорах роутера (но достаточное для того, чтобы topK изменился) могут значительно изменить итоговый результат. Основные решения такие: - Просто фризим роутер и уменьшаем асинк ⇒ роутер реже пересекает границу, при которой меняется topK - R2/R3, они же Routing Replays: сохраняем экспертов, активируемых версией модели для инференса и форсируем forward pass через них в трейнере. В статье https://arxiv.org/abs/2512.01374 можно почитать про разницу R2 vs R3 и всякие доп детали. Но проблема в том, что экспертов-то мы форсируем, но скоры роутера меняются, и это может быть проблемой (можно порассуждать на тему, что будет, если инференс версия дала i-ому эксперту высокий скор, а трейнер – низкий) И на самом деле у всех результаты смешанные: у кого-то работает одно, у других – другое. Вчера прочитал https://kiddyboots216.github.io/mismatch/#conclusion-router-replay и увидел еще один способ: Total Router Recall – сохраняем не только экспертов, но и их скоры, а в трейнере фризим роутер. Интересно, что можно предложить способ, при котором мы будем роутер учить, используя скоры и экспертов с инференса, правда работать это будет плохо. В общем, для всех интересующихся RL-ем рекомендую полистать блогпост, там много чего интересно помимо реплеев

Спортивные интеграции. Промежуточные итоги. Несколько раз уже писал про варианты интеграции AI-агентов и спортивных приложений. По итогу пришёл к стабильному сетапу, который ежедневно анализирует мои данные, создаёт тренировки и настойчиво пытается не пустить меня на улицу. Сейчас в качестве основного AI-ассистента я использую Hermes. И интеграции категории "спорт и здоровье" я также подключил через него. Вы можете использовать тот харнесс, который больше нравится. Первым делом я подключил Strava. И нет это не официальный MCP-сервер, про который я рассказывал тут. Потому что он до сих пор в статусе "частично доступен" (2,5 месяца!). Хорошо, что у Strava можно в два клика создать своё приложение и получить API-key. Я натравил своего Гермеса на API-документацию и он сделал собственный локальный MCP-сервер (очевидно, что Гермес не читал пост Коли). Он выгрузил весь архив тренировок и забирает новые, когда те появляются. С Garmin всё не так просто. У них до сих пор путь к официальному API лежит через подачу заявления в качестве компании-разработчика. Не тот вариант, что нужен для домашнего использования. Поэтому – MCP-сервер для неофициального API. Я взял готовый отсюда. Если есть желание, можно на базе данной библиотеки собрать собственное решение. Подключаем два коннектора к AI-агенту, даём ему долговременную память (llm-wiki подойдёт) – и готово. Инструментарий для анализа состояния здоровья (на базе Garmin), тренировок (Garmin + Strava) и планирования следующих готов. Чтобы максимально упростить установку, подготовил для вас репозиторий. Натравите на него своего AI-агента – он сам всё настроит.

MAS vs SAS: границы применимости (1/4) Мультиагентные системы в целом и для разработки в частности - штука, с которой сообщество агентной инженерии давно экспериментирует, и уже даже вендоры добавляют всякие Agent Teams и Swarms в свои продукты. Однако повсеместным стандартом они до сих пор не стали. Почему? В этой серии постов будем разбираться: 1. Границы применимости - когда хватает одного агента или параллельных агентов, а когда нужна команда 2. Как именно команды ломаются - потеря контекста, одинаковость, хрупкое доверие и конфликты 3. Почему это закономерность, а не невезение - теория информации и законы человеческих организаций 4. Что со всем этим делать сейчас и чего ждать от следующих поколений моделей Копаться в этом стоит отнюдь не только из академического интереса: всё идёт к тому, что мультиагентность станет нормой - включая гибридные коллективы из людей и агентов. И часть сегодняшних проблем, судя по всему, никуда не денется в ближайших поколениях моделей, так что лучше бы о них знать. На эту тему за последние полгода вышло два примечательных исследования: Google измерил, когда команда агентов выигрывает у одиночки (и наоборот), а Anthropic разобрала, почему агенты пока так себе по части кооперации. Сначала о понятиях Просто количество агентов нам говорит примерно ничего. Архитектуру задаёт топология: кто с кем связан, кто чем владеет и как организованы потоки информации (контекста). Для этой серии будем различать три режима: ● одиночный агент (SAS) решает задачу целиком ● независимые агенты (independent MAS) работают параллельно, не общаются, а их ответы в конце просто собираются вместе ● координирующаяся команда (coordinated MAS) обменивается промежуточными результатами напрямую или через оркестратора Главное различие между двумя последними: независимые агенты не меняют работу друг друга, а внутри команды сообщение может изменить чужой план, границы работы или общее состояние. Исследование Google Мотивация апрельской работы Google Towards a Science of Scaling Agent Systems - проверить на прочность популярную эвристику "чем больше агентов, тем лучше" (потому что в литературе есть буквально More Agents Is All You Need). Цель - посчитать и понять, когда добавление агентов помогает, когда вредит и можно ли предсказать это заранее по свойствам задачи. Дизайн экспериментов Пять канонических архитектур: одиночный агент, независимые параллельные, централизованная (оркестратор и воркеры), децентрализованная (peer-to-peer с раундами дебатов) и гибридная. Гоняли это всё на нескольких агентных бенчмарках и семействах моделей от разных вендоров. Результаты 🟢 Настоящий параллелизм окупается На хорошо декомпозируемом финансовом анализе команда с оркестратором дала +80,8% точности в сравнении с одиночным агентом. 🔴 Последовательные задачи штрафуют команду К примеру, на PlanCraft, где нужно последовательно выполнять зависящие друг от друга действия, все командные архитектуры выполняли успешно на 39-70% меньше задач, чем одиночный агент. 🟡 Сильному одиночке команда уже мешает Когда одиночный агент может решить больше ~45% задач, дополнительная координация чаще даёт убывающую отдачу. Это, к слову, самый статистически устойчивый вывод работы. 🟡 Оркестратор тут - пример полезного руководителя Независимые агенты усиливали ошибки до x17.2, а в схеме с оркестратором - до x4.4: он работает фильтром/валидатором и гасит распространение ошибок, которые неизбежно накапливаются в мультиагентных средах. 🟡 Архитектуру можно выбирать заранее (ну почти) По свойствам задачи и метрикам координации авторы предсказывают, какая архитектура окажется лучшей, - внутри изученных доменов модель угадывает в 87% случаев. До универсального калькулятора "сколько агентов брать" пока далеко (перенос между доменами заметно слабее), но направление интересное. А в целом - ну надо же, кто бы мог подумать: вдумчивая работа одного бывает полезнее, чем собрать митинг на десятерых и хорошенько поговорить. Никогда такого не было, и вот опять! Где проходит граница Как можно видеть из экспериментов, дело не в количестве агентов, а в графе зависимостей задач. Если работу можно разнести по независимым веткам - исследование вширь, отдельные ревью, разные модули или worktrees - команда даёт скорость и покрытие. Если всем нужен один контекст, общее состояние и постоянные синки, налог на координацию начинает съедать выигрыш. Мой опыт сводится к тому же: команда агентов работает, когда задача заранее декомпозирована, подзадачи не конфликтуют и роли чётко прописаны. А если бросить в команду задачу "как есть", самый воспроизводимый результат - спалить пятичасовой лимит Claude Max за полчаса - проверено лично, работает надёжно :) Дальше - что происходит, когда агенты всё-таки вынуждены работать вместе. #ai #agents #research #mas_sas

Я так и думал: вайбкодинг вызывает зависимость — официально. 🚬 Coddy Tech опросили 305 разработчиков и выяснили, что 80% хотя бы раз ощущали использование ИИ скорее как зависимость, чем как преимущество. А самые активные пользователи ИИ на 51% чаще сообщали о выгорании! Дело в том, что почти половина работяг продолжают кодить с ИИ после работы, даже если собирались остановиться, треть откладывает сон ради ещё одного промпта, а 39% говорят, что с ИИ им стало сложнее вообще отключаться от работы. Ведь когда агент всё делает правильно, то ты получаешь дофамин, а когда ломает — адреналин. Так все и подсаживаются на ИИ-иглу. Нужен вайбрехаб, где кодят руками 😱