Дайджест за 13 октября 2026

EmbeddingGemma 2: компактная мультимодальная модель эмбеддингов от Google

ИИ и агенты · Habr · 9/10

Google DeepMind выпустила EmbeddingGemma 2 — открытую модель эмбеддингов, которая преобразует текст, изображения, видео и аудио в единое 768-мерное векторное пространство, позволяя сравнивать разные модальности и запускаться прямо на устройстве (191 МБ для текста, 567 МБ полной версии на Pixel 11 Pro). Модель построена на архитектуре Gemma 4 с 740M параметров, разделёнными модульно: 270M для текста, 170M для зрения, 300M для аудио, что позволяет загружать только нужные части. Ключевые особенности: локальное и глобальное внимание (5 слоёв видят окно в 1024 токена, каждый 6-й видит всю последовательность), огромный словарь из 262K токенов, поддержка интерлива (смешивание разных модальностей в один вектор) и Matryoshka-векторы для гибкого сжатия (до 128 измерений с небольшой потерей качества). На многоязычном тексте модель почти не продвинулась против первой версии (61.36 vs 61.15 по MTEB), зато улучшилась на коде на 10 пунктов и появилась мультимодальность. Важные грабли: float16 ломает модель, нужна нормализация при обрезке вектора, разные размерности у запросов и документов несравнимы, забывчивость про префиксы снижает точность, качество варьируется между языками, нет встроенных защитных механизмов.

Выводы автора:

• EmbeddingGemma 2 решает проблему мультимодальности, помещая текст, код, изображения, видео и аудио в единое векторное пространство, при этом оставаясь достаточно компактной для запуска на мобильных устройствах.
• Модульная архитектура позволяет загружать только нужные модальности (текст за 270M параметров, добавить зрение за +170M, аудио за +300M), экономя память и время загрузки.
• Метод Matryoshka Representation Learning даёт гибкость в масштабировании: 768-мерный вектор можно обрезать до 512, 256 или 128 измерений с минимальной потерей качества на текстовых задачах, экономя до 6 раз на объёме хранения.

Это инженерный компромисс, и очень удачный: одно общее пространство для пяти видов данных, модульная загрузка, гибкая обрезка векторов и аппетиты, которые позволяют держать модель прямо в кармане.

Оригиналы:Как Google научил крошечную модель понимать текст, картинки, видео и звук: разбираем EmbeddingGemma 2

Как Meta разработала Muse: ИИ-агент, с которым люди хотят общаться

ИИ и агенты · Lenny's Newsletter · 9/10

Алекс Корнелл, дизайн-директор Meta, рассказывает о принципах проектирования ИИ-агента Muse, который спроектирован как беседа с человеком, а не взаимодействие с софтом. Ключевой принцип — прогрессивное раскрытие информации: одна и та же деятельность представлена на трёх уровнях (эмодзи для casual-пользователей, список задач для тех, кто хочет детали, логи для инженеров), позволяя каждому получить нужную прозрачность. Видимая цепочка рассуждений часто — это костыль для скрытия медленности модели; Muse достаточно быстра, чтобы работать молча. Generative UI работает лучше, когда структура фиксирована, а содержимое меняется: аватар и карточки идей остаются, но статус агента и рекомендации персонализированы. Корнелл переделал годы сохранённых постов из Instagram в каталог покупок через Muse, анализирует игры в гольф и шахматы, превращает двадцатилетний блог в ежедневный подкаст. Дизайн non-deterministic систем требует судить результаты по полезности, а не визуальной точности. Muse использует одно постоянное окно чата как основную беседу с агентом, сохраняя контекст иначе, чем традиционные потоки.

Выводы автора:

• ИИ-агенты должны проектироваться как разговоры с людьми, а не взаимодействие с программным интерфейсом.
• Прогрессивное раскрытие информации — один из самых полезных принципов дизайна ИИ-продуктов: одна активность на трёх уровнях детализации для разных типов пользователей.
• Видимая цепочка рассуждений часто служит скрытию медленности, а не ценной особенностью — быстрые модели могут работать незаметно.

Как бы это выглядело, если бы вы разговаривали с другим человеком? Этот вопрос сформировал всё — от убрания традиционных пузырьков сообщений до размещения агента в верхней части экрана.

Оригиналы:How I AI: Как Meta разработала Muse с Алексом Корнеллом · YouTube · Spotify

Почему большие языковые модели не решают судоку, и как работают модели рассуждений

ИИ и агенты · ByteByteGo · 9/10

Статья разбирает фундаментальное ограничение больших языковых моделей (LLM) на примере судоку: фронтальные LLM вроде GPT-5.2, Claude Opus и Gemini 3 Pro решили только 2% головоломок за $11 тыс., а модель Kona на энергетических моделях решила 96.2% за $4. Проблема LLM кроется в двух архитектурных особенностях: генерация слева направо (токен за токеном) не позволяет вернуться к ошибкам на ранних шагах без переген­ерации всей последовательности; дискретный выход (цифры 1–9) исключает плавное приближение к правильному ответу.

Это не просто о судоку — проблема актуальна для любых задач с множественными ограничениями: шахматы, го, дизайн микросхем, оптимизация энергосетей, торговля. Яннн ЛеКун и основатель Logical Intelligence Ив Бодния показывают, что язык — это интерфейс разума, а не сама разумность. Альтернатива — энергетические модели рассуждений (EBRM), которые работают с латентными переменными вместо дискретных токенов. Модель обучается функции E(x,y), где x — задача, y — кандидат ответа; низкая энергия означает согласованность с правилами. Во время инференса модель начинает со случайного шума и спускается по градиенту энергии к правильному ответу — плавно и непрерывно. Обучение использует контрастную функцию потерь, сравнивая правильные и неправильные ответы на одну задачу.

Выводы автора:

• LLM не эффективны для задач с множественными ограничениями из-за архитектурных限制: левосторонней генерации токенов и дискретного выхода
• Энергетические модели рассуждений (EBRM) лучше подходят для constraint-satisfaction проблем благодаря работе в непрерывном латентном пространстве с плавным спуском по градиенту энергии
• Язык — интерфейс к разуму, а не сам разум; для полноценного ИИ нужны архитектуры, которые не полагаются только на языковые токены

Язык — действительно мощный инструмент развития знания. Но язык сам по себе не является разумностью и не даёт все ответы.

Оригиналы:How to Build Models Without Language, with Logical Intelligence

Контекст в ИИ: 10 значений и как их различать

ИИ и агенты · Modern Data 101 · 9/10

Материал разбирает семь различных значений термина «контекст» в ИИ-разработке и объясняет, как они соотносятся между собой. Слово «контекст» до недавнего времени означало просто текст, который видит модель, но к 2026 году охватило множество концепций: окно контекста модели, контекст-инженерия (выбор информации для каждого запроса), протокол MCP для подключения инструментов, инструкции и процедуры, семантический контекст (определения метрик и объектов), память агента и другое.

Автор Animesh Kumar разделяет эти значения по двум осям: когда строится контекст (для одного запроса, из использования или заранее) и для кого (один запрос, одна команда или вся компания). Ключевая идея: контекст-инженерия — это не продукт, а инженерная работа по выбору и упорядочиванию информации для окна модели. Model Context Protocol (MCP) — это просто труба доставки данных, не решение проблемы качества этих данных. Исследования показывают, что модели работают хуже с информацией в середине длинного входа (эффект «потеряны в середине»).

Процедурный контекст (инструкции, как работает процесс) часто недооценивается, хотя агенты часто ошибаются именно в том, как что-то делать, а не в фактах. Материал также выделяет проблему: многие продукты, называющие себя «слоем контекста», на самом деле комбинируют несколько концепций и часто бывают сильны только в одной-двух из них.

Выводы автора:

• Слово «контекст» в ИИ теперь имеет минимум десять разных значений на разных уровнях абстракции, от окна модели до памяти агента и корпоративных определений.
• Контекст-инженерия и Model Context Protocol — это две разные вещи: первая делается для каждого запроса вручную инженерами, вторая просто доставляет данные, не гарантируя их качество.
• Больших результатов дает не увеличение окна контекста, а правильная организация источников данных: моделям нужны чёткие определения, процедуры и семантический контекст, иначе они уверенно выдают неправильные ответы.

Контекст-инженерия — это выбор того, что попадёт в окно для каждого шага задачи: это не создание определений или памяти, а трата ограниченного внимания модели на подходящую информацию.

Оригиналы:Context Decoded: 10 Meanings of Context in AI

Археологи восстановили древнеримскую игру с помощью ИИ

ИИ и агенты · Habr · 7/10

Исследователи использовали искусственный интеллект для расшифровки забытой древнеримской настольной игры, анализируя следы износа на известняковой плите из музея в Нидерландах. Учёные создали трёхмерные сканы артефакта размером 20×15 сантиметров и загрузили данные в платформу Ludii, обученную на сотне древних римских игр. ИИ смоделировал тысячи игровых сценариев и выявил девять правдоподобных наборов правил, соответствующих физическим следам истирания на доске. Реконструированная игра получила название ludus coriovalli и оказалась асимметричной стратегической игрой для двух игроков, в которой один пытается заблокировать другого в углах доски. Открытие переписывает историю развития сложных стратегических игр, которые ранее считались появившимися только в Средние века. Однако не все учёные согласны с выводами: некоторые скептики предполагают, что это может быть просто геометрическим рисунком, а не игровой доской.

Выводы автора:

• Использование ИИ позволило восстановить правила древней игры по микроскопическим следам износа, где письменные источники молчат
• Реконструированная ludus coriovalli демонстрирует, что сложные стратегические игры существовали в древнем Риме, а не только в Средневековье
• Открытие указывает на потенциал технологий для обнаружения неопознанных артефактов на римских памятниках, которые могут оказаться неизвестными игровыми досками

Эти линии указывали на маршруты, по которым фишки перемещали чаще всего

Оригиналы:Археологи расшифровали правила древнеримской настольной игры при помощи ИИ

Физика и схемотехника BLDC-моторов и драйверов

Разработка и архитектура · Habr · 8/10

Подробное объяснение устройства и принципов работы бесколлекторных трёхфазных электродвигателей (BLDC) и управляющей электроники к ним на уровне схемотехники и физики процессов. Автор разбирает три типичных применения: мотор-колесо для электросамокатов (высокий момент), FPV-моторы для коптеров (высокие обороты) и гимбалы для камер (высокая точность). Ключевая идея: момент силы пропорционален константе мотора и току (M = Kt × I), константу можно увеличить через витки, магниты, пары полюсов или радиус. Для точности и плавности решающую роль играет алгоритм коммутации фаз — FOC (Field Oriented Control) подаёт ток на все три фазы одновременно с разными значениями, позволяя добиться высокой точности позиционирования (до 0,2°). Для скоростных моторов используется более простая шестишаговая модель с контролем через противо-ЭДС. Драйверы построены на полумостовых драйверах, MOSFET-транзисторах и генерируют ШИМ-сигналы частотой 40 кГц для управления фазами. Скважность ШИМ определяет среднее напряжение и регулирует момент. В высокоточных системах используются датчики Холла, энкодеры (AS5600, AS5048A) и инерциальные модули (IMU) для обратной связи о положении.

Выводы автора:

• Момент силы BLDC-мотора определяется конструктивными параметрами (константа Kt) и величиной тока; оптимальный мотор — это компромисс между массой, потреблением и производительностью.
• FOC-алгоритм с одновременной подачей тока на все три фазы обеспечивает высокую точность позиционирования и плавность, в то время как шестишаговая модель проще и дешевле для скоростных приложений.
• В высокоточных системах (гимбалы, стабилизаторы) определяющими элементами становятся датчики положения и контроллер, а не сам мотор; система выполняет тысячи измерений и подгонок в секунду.

Хороший с инженерной точки зрения мотор — это компромисс между массой, потреблением, нагревом и итоговой производительностью.

Оригиналы:Физика и схемотехника бесколлекторных моторов и драйверов

Установка и настройка Jenkins на облачном сервере для CI/CD

Разработка и архитектура · Habr · 7/10

Статья представляет полный гайд по развёртыванию Jenkins на облачном сервере Selectel для автоматизации сборки, тестирования и развёртывания приложений. Jenkins — это open-source инструмент с 20-летней историей, построенный по архитектуре «контроллер + агенты», позволяющий запускать CI/CD-конвейеры независимо от платформы хостинга кода. Для лёгкой нагрузки (линтеры, unit-тесты, 10–20 коммитов в день) достаточно 2 vCPU и 2–4 ГБ RAM, для тяжёлой (компиляция больших проектов, мобильные сборки) требуется мощнее, либо добавление агентов. Статья пошагово описывает: заказ облачного сервера на Ubuntu 24.04 LTS, установку Java 21 и необходимых зависимостей (git, curl, wget, fontconfig), настройку файрвола (ufw), установку Jenkins из официального репозитория, первичную настройку через веб-интерфейс, и создание простого пайплайна на Node.js. Пайплайны описываются в файле Jenkinsfile в корне репозитория, проходят через код-ревью и хранятся вместе с проектом, что обеспечивает их версионирование и прозрачность.

Выводы автора:

• Jenkins позволяет масштабировать CI/CD через архитектуру контроллер-агентов: начать можно с одного сервера (2 vCPU, 4 ГБ), а при росте нагрузки добавить отдельные рабочие машины без изменения контроллера.
• Для лёгких нагрузок достаточна минимальная конфигурация облачного сервера; если ресурсов не хватает, можно увеличить мощность, вынести сборки на агентов или перейти на выделенный сервер.

Конвейер хранится вместе с проектом и проходит через код-ревью, как обычный код

Оригиналы:Устанавливаем Jenkins на облачный сервер для автоматизации сборки приложений

Дата-центр Яндекса во Владимире повреждён атакой БПЛА

Кибербезопасность · Habr · 8/10

11 октября центр обработки данных «Яндекса» во Владимире был атакован беспилотниками, что привело к полной остановке его работы и нестабильности десятков сервисов экосистемы компании. Повреждена критическая инфраструктура дата-центра, пострадавших нет, на месте работают профильные службы. Из строя вышли зоны доступности ru-central1-a и ru-central1-b, в результате чего облачная платформа перешла в аварийный режим. Недоступны или работают с перебоями «Яндекс Такси», «Яндекс Пэй», Поиск, Карты, Почта и более 70 других сервисов. Остальная конфигурация ресурсов признана неустойчивой, рекомендуется использовать альтернативные планы восстановления. Вечером 11 октября начался постепенный возврат сервисов к работе, при этом «Яндекс» добавил атаки БПЛА в список обстоятельств непреодолимой силы в пользовательском соглашении.

Выводы автора:

• Атака БПЛА на дата-центр привела к полной остановке его работы и нестабильности большинства сервисов Яндекса
• Облачная платформа перешла в аварийный режим с рекомендацией клиентам задействовать альтернативные планы восстановления
• Компания легализовала атаки БПЛА как обстоятельства непреодолимой силы в соглашениях, потенциально ограничив свою ответственность

Оставшуюся конфигурацию ресурсов считаем неустойчивой. Режим работы платформы является аварийным — рекомендуем задействовать любые другие альтернативные планы по аварийному восстановлению.

Оригиналы:Сервисы Яндекса работают нестабильно из-за повреждения инфраструктуры дата-центра во Владимире

Масштабный сбой инфраструктуры «Яндекса» парализовал десятки сервисов

Кибербезопасность · Habr · 7/10

11 октября 2026 года произошёл крупный сбой в инфраструктуре дата-центров «Яндекса», затронувший работу десятков российских онлайн-сервисов и маркетплейсов. Компания сообщила о повреждении сетевого оборудования, из-за чего перестали работать или работают нестабильно «Яндекс Маркет», «Яндекс Такси», «Яндекс Пэй», маркетплейсы (Lamoda, Wildberries), сети ретейла («Пятёрочка», «Лента», «Магнит»), сервисы доставки еды («Яндекс Еда», «Додо Пицца»), а также десятки других платформ (Auto.ru, Циан, Кинопоиск и др.). Пострадала также служба поддержки компании. «Яндекс Маркет» исключил заказы от 11 октября из индекса качества и отказался начислять плату за опоздания. К вечеру сервисы начали постепенно восстанавливаться, инженеры в приоритете восстанавливали наиболее используемые сервисы. Ранее компания добавила атаки БПЛА в перечень обстоятельств непреодолимой силы в пользовательских соглашениях.

Выводы автора:

• Сбой инфраструктуры «Яндекса» парализовал экосистему из десятков сервисов, включая маркетплейсы, такси, платёжные системы и доставку.
• Компания начислять штрафы не будет и гарантирует безопасность денег пользователей, при этом добавив атаки дронов в список форс-мажорных обстоятельств.

Инфраструктура наших дата-центров повреждена, поэтому в работе сервисов «Яндекса» могут быть сбои.

Оригиналы:Масштабный сбой в сервисах «Яндекса» затронул работу маркетплейсов, служб доставки и ретейлеров

Revolut против Meta Muse: чья карта победит в эпоху AI-агентов

Финтех и финансы · Linas from Linas's Newsletter · 8/10

Материал анализирует стратегию Revolut по созданию собственного AI-агента для покупок (AIR), который будет конкурировать с Meta Muse и Grok Bot. Ключевое преимущество Revolut заключается в том, что она владеет платёжной картой, процессом одобрения платежей и банковской лицензией, в то время как Meta и xAI вынуждены арендовать эти возможности у Stripe Link. Это фундаментально меняет вопрос о том, чьей учётной записью будет пользоваться AI-агент при трате денег – вопрос, который остался открытым в предыдущем анализе протокола Personal Agent Protocol (PAP). Revolut с 80+ млн клиентов нуждается в агентическом коммерсе больше, чем сами лаборатории ИИ. Тестирование в Великобритании начнётся в декабре, и ключевой деталью будет то, насколько Revolut опережает Stripe или просто его догоняет.

Выводы автора:

• Владение платёжной картой, процессом одобрения и банковской лицензией даёт Revolut конкурентное преимущество над Meta и xAI в контроле над AI-агентами для совершения покупок
• Вопрос о том, чьей учётной записью пользуется AI-агент при трате денег, станет центральным в экономике AI-агентов
• Для необанка с 80+ млн пользователей агентическая торговля имеет большее стратегическое значение, чем для компаний, разрабатывающих AI-модели

Revolut находится в центре борьбы за то, чьи учётные данные будет носить AI-агент, когда он тратит деньги

Оригиналы:Revolut строит собственного Meta Muse и Grok Bot · Почему мы недостаточно оптимистичны в отношении Revolut

Банковские продукты к 2030 году: ИИ-агенты и конец «налога на невнимательность»

Финтех и финансы · Б.О: Банки · 8/10

На юбилейном форуме Ассоциации ФинТех топ-менеджеры крупных банков и финтех-компаний обсудили, как изменятся банковские продукты к 2030 году под влиянием технологий инновационных платежей, токенизации и ИИ-агентов. Ключевой вывод: радикально продукты не изменятся (вклады, кредиты, переводы существуют 600+ лет), но изменится способ их получения и ценность для клиента. Спикеры единогласно согласились, что ИИ-агенты уничтожат классическую розничную банковскую модель, поскольку будут рационально использовать все программы лояльности, тем самым устраняя «налог на невнимательность» — скрытую маржу банков на забытых пролонгациях и непрочитанных условиях. Парадокс в том, что это вынудит банки отказаться от продуктовых команд и строить предложение под каждого клиента индивидуально. Муслим Сатыбалдиев подчеркнул критическую роль безопасности: финансовые услуги мигрируют в телеком и встроенные сервисы, поэтому нужна невидимая защита, интеграция банков с операторами и защита самих ИИ-агентов от атак. Спикеры назвали конкретные продукты 2030 года: персональный ИИ-агент-финсоветник, финансовый автопилот, токенизация реальных активов (RWA), и страховые продукты на риски ИИ-агентов.

Выводы автора:

• К 2030 году базовые банковские продукты останутся теми же, но ИИ-агенты полностью переформатируют способ их продажи и маржинальность через устранение скрытого «налога на невнимательность»
• Банки должны сосредоточиться на ценности для клиента и открыть API для ИИ-агентов вместо традиционных продуктовых команд, иначе потеряют конкурентное преимущество
• Критическим станет невидимая безопасность, интеграция операторов и банков, а также появление страховых продуктов для покрытия рисков ИИ-агентов

Часть маржи в розничном банке — это «налог на невнимательность»: забытая пролонгация или неотключенная подписка. В будущем ИИ-ассистенты полностью нивелируют этот налог, и банки лишатся маржи.

Оригиналы:Банкам больше 600 лет, а продукты — все те же