Обновить
Сначала показывать
Порог рейтинга
Уровень сложности

Single Task Algorithmic Reasoning Models: как с помощью маленькой модели обойти большую LLM?

Уровень сложностиСредний
Время на прочтение12 мин
Охват и читатели11K

Привет, Хабр! Результаты коллег по цеху и наши исследования позволяют сделать однозначный вывод: в 2026-м для рецепта отличной reasoning-модели уже недостаточно лишь текстовых рассуждений. Для качественных ответов на большинство вопросов пользователей нужна работа с инструментами, мультимодальные режимы рассуждений, и нередко даже такая экзотика, как рассуждения в латентных представлениях сети.

Мы рады поделиться с сообществом фреймворком для обучения рекурсивных reasoning-моделей STARM, существенно опережающих по качеству предыдущие open source-аналоги.

Читать далее

Новости

Мы научили ИИ решать реальные бизнес-задачи клиентов через MCP-сервер Сбера: пример Ouroboros

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели6.7K

Всем привет! Меня зовут Оля, я руководитель направления в канале Sber API. Сейчас расскажу, как мы сделали инновационный для российского рынка MCP, и как это решение может упростить вам работу.

ИИ быстро развивается и получает новые функции. Есть LLM-решения для генерирования текста и изображений, для автоматизации персональных задач, для нефинансового сектора и заказа еды, и многие другие. Однако их всё ещё тяжело применять в реальных бизнес-задачах.

Я расскажу, как мы с командой попробовали внедрить в ИИ функцию работы с финансовыми сервисами банка для корпоративных клиентов. 

Читать далее

Монолит больше не приговор: строим быстрые и гибкие микрофронтенды на ES-модулях

Уровень сложностиСредний
Время на прочтение11 мин
Охват и читатели9.2K

Меня зовут Иван Соснович, я сеньор фронтенд-разработчик в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. По итогам прошлой статьи мнения читателей разделились.

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

Сразу скажу, что код проекта будет писать ИИ через GigaCode CLI, навыки останутся в репозитории.

Читать далее

Как мы сделали веб-аналог Jaspersoft Studio (и зачем вообще это понадобилось)

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели5.6K

Представьте сотни уникальных шаблонов строгой отчётности — от актов выполненных работ до счетов-фактур, — которые являются неотъемлемой частью работы одного из крупнейших банков страны. Каждый шаблон — JRXML-файл, каждый файл — чья-то зона ответственности. В нашей команде инструмент для создания этих шаблонов был Jaspersoft Studio — но и он нередко становился источником системных проблем.

Расскажем, как и почему мы написали собственный браузерный редактор печатных форм, и как он помог разработчикам и аналитикам быстро и самостоятельно создавать сложные отчёты.

Читать далее

Обновления GigaIDE за июль 2026

Время на прочтение4 мин
Охват и читатели6.5K

Всем добрый день. Как и в предыдущие месяцы, по итогам июля мы решили рассказать про то, как изменилась GigaIDE за прошедший месяц. Ниже — краткий обзор обновлений Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе.

Читать далее

Kandinsky WM 1.0: генеративные модели для Physical AI

Уровень сложностиСредний
Время на прочтение17 мин
Охват и читатели10K

В конце прошлого года мы представили семейство моделей генерации изображений и видео Kandinsky 5.0. Флагманская модель Kandinsky 5.0 Video Pro заняла и долгое время удерживала первое место среди open-source-моделей в категории text-to-video на arena.ai. Сегодня мы выкладываем в открытый доступ Kandinsky WM 1.0, набор из трех специализированных моделей генерации видео для доменов Physical AI: автомобильные сценарии, робототехника и сцены со сложной физикой.

Читать далее

Как LLM могут помочь определить Data Lineage

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели7.7K

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

Приходится постоянно полагаться на традиционную документацию, спецификации по загрузке данных или Source-to-Target mapping-файлы. Эти артефакты, как правило, быстро устаревают, не отражая актуальной логики преобразований, зашитой в ETL-процессах и SQL-коде. В результате необходимо вручную поддерживать актуальность такой документации, или, что ещё ресурсозатратнее, проведить реверс-инжиниринг тысяч строк SQL-кода хранилища данных для понимания реальных зависимостей. 

Эти проблемы обостряются в контексте постоянных изменений ИТ-ландшафта, например, миграции в облако, замены устаревших систем-источников (legacy systems) или интеграции новых платформ. И если нет понимания «жизненного цикла» данных, то это превращается в прямую угрозу для бизнес-непрерывности. Критичной задачей становится безопасное и контролируемое переключение существующих решений — витрин, дашбордов и отчётов — на новые источники данных при строгом условии минимизации или полного исключения влияния на конечных потребителей.

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

- Какие витрины и отчёты зависят от этого источника? 

- Какие преобразования данных необходимо проверить или перенастроить?

- Откуда в новой системе взять актуальные и корректные данные?

Мы рассмотрим, как с помощью применения больших языковых моделей (LLM) для автоматического анализа SQL-кода и ETL-логики извлечь точный Data Lineage.

Читать далее

RUMBA: русскоязычный бенчмарк для оценки долгосрочной памяти

Уровень сложностиПростой
Время на прочтение13 мин
Охват и читатели7.9K

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

При этом такая память о пользователе обычно не является встроенным свойством самой языковой модели. В прикладных продуктах её чаще добавляют как отдельный слой вокруг LLM: например, через RAG с долговременным хранилищем фактов (векторные или графовые базы памяти, профили пользователя, журналы событий) или агентные схемы — например, локальную файловую систему в духе Obsidian в сочетании с вызовом инструментов.

Из-за этого качество памяти становится не столько вопросом того, насколько хороша модель, сколько вопросом всей архитектуры: как система извлекает факты, что именно сохраняет, как разрешает противоречия, удаляет ли данные по запросу пользователя и как использует временной контекст.

Для русского языка до сих пор не хватало бенчмарка, который проверяет именно такие аспекты долгосрочной памяти в многосессионных диалогах. Поэтому мы сделали RUMBA — Russian User Memory Benchmark: русскоязычный бенчмарк для анализа способности диалоговых систем работать с долгосрочной памятью пользователя в реалистичных разговорных сценариях.

Читать далее

Apple Intelligence в Python для агента Hermes

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели9.2K

Apple выпустила Foundation Models SDK for Python ещё в феврале 2026. Эта Python-библиотека предоставляет прямой доступ к локальной модели Apple Intelligence: модель грузится в процесс, KV-кеш лежит в памяти, инференс идёт на Apple Silicon. Библиотека получила 1,2 тыс. звёзд на GitHub, последнюю версию 0.2.0 с поддержкой изображений представили на WWDC26.

Есть несколько обёрток для Foundation Models с поддержкой интерфейса OpenAI, но нет нативного провайдера для агентов, написанных на Python, таких как Hermes, в котором локальная модель работала бы как основной инференс агента со всеми его особенностями: рейтлимитером, откатом к другим моделям и аудитом. Также известно прямое использование Foundation Models в агенте iClaw на Swift, но эти возможности пока недоступны более универсальным агентам на Python.

Почему бы не попробовать добавить к Hermes адаптер на Foundation Models SDK for Python и получить среднее время реакции на короткие запросы 2,8 секунды, а на бенчмарке из 50 вопросов из MMLU, BoolQ, GSM8K, BIG-Bench и HellaSwag выбить 46 правильных ответов?

Под катом — архитектура, код и бенчмарки нативного провайдера для автономного агента Hermes.

Читать далее

Ошибки операторов Kubernetes: как мы их исправляли и чему научились

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели8K

Ошибки в разработке неизбежны, но они помогают расти. Я Стас Иванкевич, техлид в команде разработки управляющего слоя Platform V DropApp в СберТехе. Наша команда придерживается простого принципа: не наступать на одни грабли дважды. Из каждой ошибки стараемся извлечь урок и больше её не повторять, а ещё лучше — учиться на ошибках других. Поэтому мы развиваем культуру открытого обсуждения ошибок и не закрываем глаза на возникающие сложности.

На первый взгляд, написание Kubernetes-операторов — технически сложная, но вполне понятная работа. Определил CRD, написал контроллер, настроил реконсиляцию — и вуаля, автоматизация работает. Но на практике ошибки могут быть не в коде, а в архитектуре, подходах и принятых допущениях — даже если основная логика реализована правильно.

Я уже рассказывал о подводных камнях и лучших практиках при разработке операторов Kubernetes: материал в трёх частях можно почитать тут, тут и тут. А в этой статье я собрал ошибки, которые часто встречались мне в реальных проектах при работе с Kubernetes-операторами. Расскажу, как мы их исправляли, какие выводы сделали и что теперь делаем иначе. Надеемся, наш опыт будет полезным для вас и поможет их не повторить.

Читать далее

Giga4DQM: мультиагентный подход к расследованию качества данных на базе GigaChat

Уровень сложностиСредний
Время на прочтение16 мин
Охват и читатели11K

Giga4DQM — открытый проект, реализующий концепцию ИИ-агентов для автоматизированного расследования инцидентов с данными и построения целостной картины зависимостей в существующей БД. Система понимает вопросы на естественном языке, самостоятельно анализирует структуру базы, строит граф зависимостей и формирует диагностические запросы. Архитектура не привязана к одной СУБД: в качестве примера взята PostgreSQL, но подход может быть адаптирован к любой системе с развитым каталогом метаданных. В основе — мультиагентная архитектура на основе GigaChat и LangGraph. Код открыт, доступен для тестирования и внедрения.

Читать далее

Как мы делаем разграничение доступа в одной платформе Сбера

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели8.6K

Наша команда создаёт сервис управления доступом (коротко - СУД) в одной из самых больших в Сбере платформ - Платформе Кибербезопасности, или просто ПКБ. На ней обрабатываются все данные Банка, связанные с кибербезопасностью, а также работает множество продуктов и сервисов, предназначенных для противодействия внутреннему и внешнему мошенничеству, защиты инфраструктуры, а также для мониторинга и анализа различных угроз. Подробнее о том, что собой представляет ПКБ, можно посмотреть в Кибрарии Сбера в статье Аналитическая платформа кибербезопасности. Опыт Сбера. Там же можно узнать, как наш сервис вписан в платформу.

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

Наш сервис используется в большой гетерогенной среде, которая содержит не только разрабатываемое в банке программное обеспечение, но и opensource-продукты, предоставляющие различную функциональность (Apache Flink и MLFlow), а также управляющие данными (Apache Hadoop, Ozone и Clickhouse).

Читать далее

Обновления GigaIDE за июнь 2026

Уровень сложностиПростой
Время на прочтение3 мин
Охват и читатели8.2K

Всем добрый день. В этой статье мы расскажем вам об июньских изменениях в Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе. Соответствующий обзор за май доступен по этой ссылке.

Читать далее

Ближайшие события

GigaChat 3.5 — меньше, быстрее, сильнее

Уровень сложностиСложный
Время на прочтение18 мин
Охват и читатели38K

Салют, Хабр!

Сегодня мы выкладываем в open source GigaChat 3.5 Ultra — нашу новую 432B-модель. В этом релизе мы впервые для нашей линейки масштабировали собственную гибридную архитектуру на сотни миллиардов параметров, ускорили инференс и усилили модель в коде, агентных сценариях и сложных областях.

GigaChat 3.5 Ultra компактнее прошлого флагмана: 432 млрд параметров вместо 700 млрд у GigaChat 3.1 Ultra. Но это не компромисс «меньше, зато дешевле»: за счёт новых данных, обновлённого рецепта обучения и архитектурных изменений модель стала сильнее, а также эффективнее по памяти и скорости генерации.

Интересно? Добро пожаловать под кат.

Читать далее

GFusion: как мы обучали диффузионную LLM в GigaChat

Уровень сложностиСложный
Время на прочтение10 мин
Охват и читатели15K

Салют, Хабр!

Хочу поделиться проектом, которым я занимался во время стажировки в команде GigaChat Pretrain. В течение нескольких месяцев мы исследовали диффузионные языковые модели (dLLM) — относительно новое направление в LLM, в котором многие идеи только начинают проверяться на практике.

Главной целью было не тратить огромное количество ресурсов на обучение с нуля, а взять базовую авторегрессионную модель GigaChat3-10B-A1.8B-base и перевести её в диффузионный режим. Так появились наши экспериментальные GFusion-10B-A1.8B-base и GFusion-10B-A1.8B!

Читать далее

Применение методов детектирования объектов в задаче долгосрочного прогнозирования событий

Уровень сложностиСложный
Время на прочтение19 мин
Охват и читатели8K

Привет, Хабр. Мы — Савченко Андрей — директор по науке, и Иван Карпухин — senior researcher в в Sber AI Lab — Центре практического искусственного интеллекта Сбера, расскажем о нашем исследовании, представленном на конференции AAAI 2026.

В сфере искусственного интеллекта за последние десять лет многие самые успешные идеи родились не в какой-то одной предметной области, а на стыке нескольких направлений. Так произошло с трансформерами, которые сначала появились в обработке естественного языка, затем практически полностью изменили компьютерное зрение, а сегодня их используют почти во всех задачах машинного обучения. Похожая ситуация и с долгосрочным прогнозированием последовательностей событий. Неожиданно оказалось, что многие идеи, давно ставшие стандартом в задачах детектирования объектов на изображениях, позволяют принципиально иначе взглянуть на прогнозирование будущих событий.

На первый взгляд эти две области никак не связаны между собой. В одном случае модель ищет автомобили, людей и дорожные знаки на фотографии, а в другом — пытается предсказать будущие покупки клиента банка, последовательность медицинских процедур или активность пользователя в социальной сети. Но если отбросить подробности реализации и посмотреть на задачу более абстрактно, то мы обнаружим сходство. В компьютерном зрении необходимо ответить всего на два вопроса: что находится на изображении и где именно расположен объект. В прогнозировании событий задача выглядит почти так же: какое событие произойдёт и когда именно это случится. Двумерное пространство изображения превращают в одномерную временную ось. Эта аналогия впоследствии позволила перенести целый класс методов из object detection в моделирование последовательностей событий.

Читать далее

Как мы строили безопасную микросервисную архитектуру с Service Mesh: интеграция с базами данных и масштабированиe

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели11K

Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.

В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.

Читать далее

Как оценивать LLM на практике, если времени на «идеальный бенчмарк» нет

Уровень сложностиСредний
Время на прочтение18 мин
Охват и читатели7.9K

Меня зовут Алёна, и я более пяти лет занимаюсь оценкой языковых моделей: участвовала в создании таких русскоязычных бенчмарков как Russian SuperGLUE, ruMTEB, куратор проекта Альянса в сфере искусственного интеллекта «MERA» (бенчмарка для оценки русскоязычных LLM), и создатель множества других проектов в области тестирования генеративных моделей. На конференциях, встречах с командами и обсуждениях LLM-продуктов я часто слышу один и тот же вопрос: «А как вообще правильно оценивать LLM на практике?», и почти всегда за этим вопросом стоит один и тот же разрыв.

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

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

На этом месте и возникает типовая развилка. Часть команд не оценивает почти ничего: несколько ручных примеров перед демо, быстрый просмотр ответов глазами — и решение «вроде, работает». Другая часть пытается сделать «минимально нормальную» оценку: 10–20 запросов, LLM-судья, средний балл, табличка для отчёта. Проблема в том, что второй вариант часто выглядит как контроль качества, но им не является. Более того, он может быть опасен, потому что создаёт уверенность там, где на самом деле есть только очень слабый сигнал. При этом я хорошо понимаю, почему так происходит. Дело не в том, что команды ленятся или не понимают важности оценки. Скорее, наоборот: они работают в темпе, для которого классический академический подход часто является слишком тяжеловесным.

Читать далее

Аудио-токенизатор KVAE-Audio от Сбера

Уровень сложностиСредний
Время на прочтение8 мин
Охват и читатели13K

Привет, Хабр. Мы уже показывали токенизаторы для изображений и видео, рассказывали про обновление видеомоделей KVAE-2.0, а теперь закрываем третью модальность — публикуем KVAE-Audio, непрерывный полнодиапазонный (48 кГц) токенизатор для звука. По результатам тестов наш VAE (вариационный автоэнкодер, Variational Autoencoder) показывает лучшее качество генераций в задаче text-to-audio (генерирование звука по текстовому описанию) в общем домене, при этом не отставая в качестве реконструкций от моделей конкурентов, и имея заметно меньше параметров и каналов в латентном представлении. Код, инференс — в открытом доступе под лицензией MIT, веса на HF.

Читать далее

История искусства информационной безопасности и её верных слуг

Уровень сложностиПростой
Время на прочтение16 мин
Охват и читатели7.2K

Привет, Хабр! На связи Сергей Кубан, руководитель направления защиты инфраструктуры производства ПО в СберТехе. Наша команда отвечает за то, чтобы поставляемое клиентам ПО и сервисы соответствовали требованиям кибербезопасности.

В военных вузах есть предмет «История военного искусства». Он исследует формы и способы вооружённой борьбы, стратегию и тактику, обобщает опыт прошлых войн. На мой взгляд, в вузах для кибербезопасников тоже целесообразно включать в программу историю ИБ и противоборства в киберпространстве.

В своих выступлениях на конференциях я часто провожу аналогии между ИБ, военным и художественным искусством. В этой статье также позволю себе подобные аналогии. По своему опыту опишу этапы развития ИБ: популярные технологии, средства защиты информации (СЗИ), законы, ассоциации с искусством. И отмечу евангелистов ИБ, которые активно участвовали в формировании отрасли, организации и работе профессиональных сообществ и конференций, бескорыстно делились знаниями, вели блоги, учили школьников и студентов.

Читать далее
1
23 ...