Всем добрый день. В этой статье мы расскажем вам об июньских изменениях в Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе. Соответствующий обзор за май доступен по этой ссылке.
Салют, Хабр!
Сегодня мы выкладываем в open source GigaChat 3.5 Ultra — нашу новую 432B-модель. В этом релизе мы впервые для нашей линейки масштабировали собственную гибридную архитектуру на сотни миллиардов параметров, ускорили инференс и усилили модель в коде, агентных сценариях и сложных областях.
GigaChat 3.5 Ultra компактнее прошлого флагмана: 432 млрд параметров вместо 700 млрд у GigaChat 3.1 Ultra. Но это не компромисс «меньше, зато дешевле»: за счёт новых данных, обновлённого рецепта обучения и архитектурных изменений модель стала сильнее, а также эффективнее по памяти и скорости генерации.
Интересно? Добро пожаловать под кат.
Салют, Хабр!
Хочу поделиться проектом, которым я занимался во время стажировки в команде GigaChat Pretrain. В течение нескольких месяцев мы исследовали диффузионные языковые модели (dLLM) — относительно новое направление в LLM, в котором многие идеи только начинают проверяться на практике.
Главной целью было не тратить огромное количество ресурсов на обучение с нуля, а взять базовую авторегрессионную модель GigaChat3-10B-A1.8B-base и перевести её в диффузионный режим. Так появились наши экспериментальные GFusion-10B-A1.8B-base и GFusion-10B-A1.8B!
Привет, Хабр. Мы — Савченко Андрей — директор по науке, и Иван Карпухин — senior researcher в в Sber AI Lab — Центре практического искусственного интеллекта Сбера, расскажем о нашем исследовании, представленном на конференции AAAI 2026.
В сфере искусственного интеллекта за последние десять лет многие самые успешные идеи родились не в какой-то одной предметной области, а на стыке нескольких направлений. Так произошло с трансформерами, которые сначала появились в обработке естественного языка, затем практически полностью изменили компьютерное зрение, а сегодня их используют почти во всех задачах машинного обучения. Похожая ситуация и с долгосрочным прогнозированием последовательностей событий. Неожиданно оказалось, что многие идеи, давно ставшие стандартом в задачах детектирования объектов на изображениях, позволяют принципиально иначе взглянуть на прогнозирование будущих событий.
На первый взгляд эти две области никак не связаны между собой. В одном случае модель ищет автомобили, людей и дорожные знаки на фотографии, а в другом — пытается предсказать будущие покупки клиента банка, последовательность медицинских процедур или активность пользователя в социальной сети. Но если отбросить подробности реализации и посмотреть на задачу более абстрактно, то мы обнаружим сходство. В компьютерном зрении необходимо ответить всего на два вопроса: что находится на изображении и где именно расположен объект. В прогнозировании событий задача выглядит почти так же: какое событие произойдёт и когда именно это случится. Двумерное пространство изображения превращают в одномерную временную ось. Эта аналогия впоследствии позволила перенести целый класс методов из object detection в моделирование последовательностей событий.
Привет, Habr! Меня зовут Валентин, я DevOps-инженер команды Platform V Kintsugi. Мы занимаемся развитием облачного сервиса и на практике регулярно сталкиваемся как с архитектурными задачами построения распределённых систем, так и с вопросами обеспечения их безопасности.
В предыдущей части мы подробно разобрали механизм делегирования TLS-соединения на уровень Service Mesh и показали, как Egress Gateway может выступать полноценным участником PostgreSQL handshake. Однако этот сценарий рассматривался в упрощённой конфигурации — один сервис, один сертификат, одно подключение.
Меня зовут Алёна, и я более пяти лет занимаюсь оценкой языковых моделей: участвовала в создании таких русскоязычных бенчмарков как Russian SuperGLUE, ruMTEB, куратор проекта Альянса в сфере искусственного интеллекта «MERA» (бенчмарка для оценки русскоязычных LLM), и создатель множества других проектов в области тестирования генеративных моделей. На конференциях, встречах с командами и обсуждениях LLM-продуктов я часто слышу один и тот же вопрос: «А как вообще правильно оценивать LLM на практике?», и почти всегда за этим вопросом стоит один и тот же разрыв.
С одной стороны, есть академический мир. В нём бенчмарк — это методология, датасеты, метрики, контроль качества, проверка утечек, воспроизводимость, анализ ошибок и месяцы работы. Хороший академический тест должен быть достаточно строгим, чтобы его результатам можно было доверять.
С другой стороны, есть индустриальная практика. Команде нужно выбрать модель, проверить новую версию промпта, сравнить два пайплайна, выкатить RAG-систему, оценить агентную систему или понять, не стало ли хуже после очередного изменения. И всё это не через полгода, а, желательно, к следующему релизу.
На этом месте и возникает типовая развилка. Часть команд не оценивает почти ничего: несколько ручных примеров перед демо, быстрый просмотр ответов глазами — и решение «вроде, работает». Другая часть пытается сделать «минимально нормальную» оценку: 10–20 запросов, LLM-судья, средний балл, табличка для отчёта. Проблема в том, что второй вариант часто выглядит как контроль качества, но им не является. Более того, он может быть опасен, потому что создаёт уверенность там, где на самом деле есть только очень слабый сигнал. При этом я хорошо понимаю, почему так происходит. Дело не в том, что команды ленятся или не понимают важности оценки. Скорее, наоборот: они работают в темпе, для которого классический академический подход часто является слишком тяжеловесным.
Привет, Хабр. Мы уже показывали токенизаторы для изображений и видео, рассказывали про обновление видеомоделей KVAE-2.0, а теперь закрываем третью модальность — публикуем KVAE-Audio, непрерывный полнодиапазонный (48 кГц) токенизатор для звука. По результатам тестов наш VAE (вариационный автоэнкодер, Variational Autoencoder) показывает лучшее качество генераций в задаче text-to-audio (генерирование звука по текстовому описанию) в общем домене, при этом не отставая в качестве реконструкций от моделей конкурентов, и имея заметно меньше параметров и каналов в латентном представлении. Код, инференс — в открытом доступе под лицензией MIT, веса на HF.
Привет, Хабр! На связи Сергей Кубан, руководитель направления защиты инфраструктуры производства ПО в СберТехе. Наша команда отвечает за то, чтобы поставляемое клиентам ПО и сервисы соответствовали требованиям кибербезопасности.
В военных вузах есть предмет «История военного искусства». Он исследует формы и способы вооружённой борьбы, стратегию и тактику, обобщает опыт прошлых войн. На мой взгляд, в вузах для кибербезопасников тоже целесообразно включать в программу историю ИБ и противоборства в киберпространстве.
В своих выступлениях на конференциях я часто провожу аналогии между ИБ, военным и художественным искусством. В этой статье также позволю себе подобные аналогии. По своему опыту опишу этапы развития ИБ: популярные технологии, средства защиты информации (СЗИ), законы, ассоциации с искусством. И отмечу евангелистов ИБ, которые активно участвовали в формировании отрасли, организации и работе профессиональных сообществ и конференций, бескорыстно делились знаниями, вели блоги, учили школьников и студентов.
Я Игорь Юрченко, backend-разработчик Сбера, в этой статье расскажу о нашем опыте автоматизации деплоя потоков Apache NiFi.
Apache NiFi — инструмент для управления потоками данных между автоматизированными системами (реализует подход ETL — extract, transform, load). Документация: https://nifi.apache.org/documentation/v1 (на момент написания статьи актуальна версия 2.x, но тут речь про 1.x). Физически это Java-приложение с графическим web-интерфейсом, в котором настраивается поток — в общем случае набор процессоров, которые получают на вход какие-то данные от предыдущего процессора или из внешней системы, обрабатывают их определённым образом и передают следующему процессору или во внешнюю систему. Процессор — готовый модуль с параметрами интеграции и/или обработки данных (например, строка подключения к БД, или схема трансформации данных). То есть ETL настраивается графически, без написания кода. NiFi обладает возможностями горизонтального масштабирования (ноды кластера имеют одинаковую копию настроек потока, обрабатывают данные параллельно), и расширения (пользователь может писать custom процессоры и использовать их в потоках наравне со штатными). Из коробки поддерживается множество внешних систем и протоколов передачи данных.
Apache NiFi Registry — инструмент версионирования потоков, Java-приложение с web-интерфейсом, интегрировано с NiFi. Что-то вроде системы контроля версий исходного кода, но проще. Пользователь может сохранять в Registry, просматривать и восстанавливать старые версии потока. Документация: https://nifi.apache.org/docs/nifi-registry-docs.
Многие из нас делают что-то интересное: создают агентов, RAG-системы, делают крутые решения на основе LLM или в области генерирования изображений и видео, собирают датасеты, придумывают бенчмарки — этот список можно продолжать и продолжать. Создав что-то замечательное, напишут статью на Хабре, и на этом всё. Хотя ту же самую работу вполне можно отправить на ведущие мировые конференции по Data Science и ИИ, таких как NeurIPS, ICLR или ACL. Разница не всегда в качестве исследования, просто мало кто знает, как правильно обернуть свои ИИ-решения и разработки в научные статьи, которые пройдут на топовые конференции.
Я Мария Тихонова, исследователь из Sber AI. Занимаюсь бенчмарками и генеративными моделями, развиваю исследовательское направление внутри наших команд. Расскажу о том, как превратить крутые результаты, которые у вас есть, в научную статью высшего ранга (A/A*).
Представьте парк из более чем 700 экземпляров СУБД. Классический сценарий: приходит оповещение о высокой нагрузке, администратор начинает вручную собирать метрики с десятков дашбордов в Prometheus/Grafana, анализировать журналы, ища ошибки и медленные запросы, пытаться сложить разрозненные данные в единую картину, сформулировать проблему и создать задачу на исправление.
На это уходит много ресурсов, а ценное время на реакцию уходит.
Наша команда решила автоматизировать этот цикл, создав систему, которая не просто собирает данные, но и анализирует их, генерирует контекст и сама запускает процессы по созданию заявки.
С вами Станислав Епишин и Константин Резник из команды «R4C.Support.Всадники апокалипсиса» в СберТехе. В этой статье покажем, как мы соединили Prometheus, Pipeliner (CI/CD-оркестратор, разработан в СберТехе, аналог Jenkins), TaskTracker (система управления задачами, разработана в СберТехе, аналог Jira) и GigaChat (продукт Сбера) через AI Hub API (анализ) в единый механизм.
Финансовые данные в компании обычно уже есть: в 1С, в хранилище, витринах, аналитических кубах. Но в конце отчётного периода аналитики всё равно часто делают одно и то же: выгружают числа в Excel, собирают сводные таблицы, вручную считают отклонения и готовят презентации для руководства. В этой статье покажем, как перевести такой процесс в промышленный контур: создать OLAP-модель, вынести бизнес-логику в семантический слой и получать живые отчёты в Web, Excel и LibreOffice без ручного копипаста. Выгружать данные будем из 1С, но в виду большого количества способов это сделать мы коснёмся этой темы в следующей статье, а здесь сосредоточимся я на возможностях анализа данных.
Статья будет особенно полезна:
- BI-разработчикам;
- архитекторам данных;
- бизнес-аналитикам;
- финансистам;
- руководителям, которым важно быстро получать корректную управленческую отчётность.
Допустимо ли пожертвовать одним человеком, чтобы спасти нескольких? Стоит ли вмешиваться, если любой выбор приведёт к ущербу? У таких задач нет ответа в формате «правильно или неправильно». Есть личная позиция — результат ценностей, культурных норм и прошлого опыта. Эта позиция может меняться, когда рядом появляется тот, кто говорит уверенно, последовательно и убедительно. Раньше в этой роли выступал другой человек, сегодня всё чаще — языковая модель.
Мы в Лаборатории нейронаук и поведения человека Сбера проверили, способен ли ИИ влиять на моральные решения людей. Препринт исследования опубликован на arXiv.org.
Чат как интерфейс упирается в потолок. Текст хорош, когда ответ это объяснение или код. Но на запрос «покажи продажи за квартал и сравни с прошлым годом» модель отвечает стеной чисел, в которой ничего не покрутить. Хочется другого: интерактивный дашборд прямо в чате, который при следующей реплике не пересобирается с нуля, а аккуратно обновляется. Очевидное решение — попросить модель сгенерировать React-компонент — оказывается тупиком. Вывод нестабилен: один и тот же промпт сегодня даёт useState, завтра — Zustand. Сгенерированный JSX это исполняемый код, то есть открытая дверь для инъекций: в мае 2025 Invariant Labs показали на официальной GitHub MCP-интеграции, как вредоносный issue провоцирует агент на утечку данных из приватных репозиториев. И главное, что нет инкрементальности: на запрос «добавь фильтр» модель регенерирует весь компонент, состояние теряется, ввод сбрасывается.
Вывод: код это плохой интерфейс между LLM и приложением. Нужен промежуточный слой. Эта статья про два таких слоя: json-render отвечает за то, что и как рендерить из декларативной спецификации, MCP Apps — за то, где и как доставить этот интерфейс в ассистент. По официальному анонсу MCP Apps поддерживаются в Claude, Goose, VS Code Insiders и ChatGPT; json-render заявляет MCP-интеграцию для Claude, ChatGPT, Cursor и VS Code. Через всю статью я протащу один пример: дашборд продаж, который пользователь докручивает репликами «добавь разбивку по регионам», «сравни с прошлым годом», «убери блок». Сразу обозначу жанр: это мой первый пилотный заход в тему, поэтому текст ближе к обзору с пробами, чем к боевому отчёту из эксплуатации.
Привет, Хабр! Меня зовут Александр Чесноков, я разработчик команды Platform V DataGrid в СберТехе. Наш продукт – форк Apache Ignite с нашими доработками, и мы активно поддерживаем open-source версию: контрибьютим в основной репозиторий, исправляем баги, развиваем новые фичи, а также поддерживаем инфраструктуру для тестирования.
В этой статье расскажу, как в Ignite мы столкнулись с orphan JVM на тестовых стендах, как они поломали нам процесс тестирования и как мы решили эту проблему, научив дочерние JVM отслеживать завершение родителя через pipe, используя System.in. В конце будет разбор конкретной реализации решения.
Статья будет полезна тем, кто работает с CI, интеграционными тестами или запускает дочерние процессы в своих приложениях.
Меня зовут Дмитрий Валов, я тимлид команды «Инструменты для банка (агенты)» в Sber AI Lab — Центре практического искусственного интеллекта Сбера.
Большие языковые модели (LLM) научились отвечать на вопросы, писать код и анализировать документы. Логично спросить: «А может ли одна универсальная модель заменить зоопарк специализированных систем, которыми банк описывает своих клиентов?» Сегодня под каждую задачу — отток, кредитный риск, NBA — заводится отдельный пайплайн: свой набор фичей поверх истории транзакций, своё обучение, свои перетренировки при каждом изменении. Данные об одном и том же клиенте растаскиваются по разным системам и плохо переиспользуются. Сложнее всего — сопровождение и актуализация: стоит появиться новому источнику или фиче, как модель приходится переобучать, иначе она просто не умеет ими пользоваться.
LLM выглядит идеальным кандидатом на роль единого интерфейса к этим данным: данные переводятся в текст, и новый источник достаточно дописать в промпт на инференсе, без переобучения. Но есть проблема: если просто скормить модели историю транзакций, она справляется заметно хуже специализированных моделей. В нашей работе FinTRACE мы разобрались, почему так происходит, и предложили способ это починить — не дообучая модель на огромных размеченных датасетах, а перестраивая то, что именно мы ей показываем.
Статья принята на SIGIR 2026.
Вначале, наверное, каждый попадал в эту ловушку на собеседовании: кандидат открывает экран, уверенно запускает draw.io и бодро начинает рисовать. Бац — микросервисы! Бац — брокеры сообщений между ними! Redis-кеш сверху, базы данных снизу. Даже стрелки вызовов нарисованы в правильном стиле. Интервьюер кивает, видя техническую беглость. Кандидат чувствует уверенность, ждёт похвалы.
— Отлично, — говорит интервьюер, — а откуда берутся данные для этого отчёта?
Кандидат на секунду замешкается. «Откуда?.. Ах да, из базы данных, наверное... или из очереди?..» Он смотрит на схему, где слева — пустое место перед микросервисами.
— И кто потребитель этого события? — продолжает интервьюер. — Кто его забирает и что делает с результатом?
Кандидат начинает водить курсором по доске draw.io, но схема рассыпается. Сквозного потока данных нет, потому что контекст не был зафиксирован с самого начала. Это не техническая ошибка, а фундаментальный пробел в системном мышлении.
Проблема не в отсутствии знаний, а в отсутствии целостной картины.
Большинство кандидатов (и не только на собеседованиях) сразу ныряет в глубину технологий, не очертив границы системы. Они рисуют внутреннюю механику бэкенда, не уточнив, откуда приходят входные данные и куда уходит результат. Это как строить фундамент, не зная размеров участка. Или как инженер, который начинает проектировать двигатель, не узнав, что это за транспорт и что он должен делать.
На собеседовании такая ошибка критична. Интервьюер видит технический кругозор, но не видит системного мышления. А ведь это именно то, что отличает senior-архитектора от middle, который умеет только пилить отдельные сервисы.
Deep Research часто описывают как «LLM с интернет-поиском». Однако если система просто делает несколько поисковых запросов, читает часть выдачи и пишет ответ, то она упускает несколько важных аспектов, без которых невозможно полноценное исследование.
В настоящем глубоком исследовании, помимо доступа к актуальным источникам, важен и сам исследовательский процесс: понять исходный вопрос, не потерять ограничения, разложить задачу на проверяемые части, собрать доказательную базу, отличить найденные факты от выводов модели, зафиксировать пробелы и собрать итоговый отчёт.
В этой статье мы расскажем о том, как решили задачу построения системы B2C Deep Research на основе Instruct-модели (GigaChat Ultra 3.1), в которой модель выполняет специфицированные задачи, а логика исследования реализована с помощью конвейера из набора ролей, условий завершения, циклов поиска и постепенного накопления контекста, подкреплённого цитатами. Так Deep Research становится не просто набором промптов с доступом к источникам в интернете, а управляемым исследовательским контуром.
В крупных компаниях зоопарк фреймворков автоматизации убивает эффективность. Мы создали централизованное решение на базе Perfeccionista‑framework, подключили к нему RAG и MCP‑сервер для работы с LLM, и теперь языковые модели понимают контекст наших тестов. Главный вывод: будущий QA‑инженер — это промпт‑инженер с глубокими предметными знаниями
На первый взгляд кажется, что автоматизировать тестирование в крупной компании просто: выбрал фреймворк, заставил всех писать на нём — и порядок. Однако на практике команды размножают десятки похожих инструментов, изобретают велосипеды и тонут в костылях, а попытка подключить ИИ к этому хаосу превращается в ловушку.
Меня зовут Владимир Михаленков, основной стрим моей деятельности — разработка и тиражирование централизованного фреймворка автоматизированного тестирования в Сбере. В этой статье расскажу, как мы обуздали технологический зоопарк и научили языковые модели понимать, чего от них хотят QA‑инженеры.
Всем привет! Мы создаём GraphRAG-систему и нам постоянно приходится тестировать новые гипотезы: менять подходы к поиску по графу, обработку контекста, внешние интеграции и вспомогательные компоненты. Почти каждая такая гипотеза требует правок в коде или конфигурирования агента, а значит, быстро возникает несколько параллельных вариантов реализации, которые хочется сравнивать между собой.
При этом тестирование одной версии не должно блокировать тестирование другой. Разработчики должны иметь возможность одновременно прогонять бенчмарки для разных веток, реализаций и конфигураций, а затем выбирать наиболее удачные изменения и интегрировать их в основную версию агента, которая уже проходит путь до эксплуатации.
Другая проблема: агент — это не просто промпт к LLM, а комплексная кодовая база со своим окружением, множеством зависимостей и точек отказа. Тестирование его встраиванием в ноутбуки и кастомные скрипты может аукнуться неприятными побочными эффектами и необходимостью постоянно их дорабатывать под изменения в агенте или добавление новых агентов.
В результате задача «оценить качество агента» превращается не только в задачу про метрики, но и в задачу про инженерную надёжность: как воспроизводимо запускать агент, как не зависеть от конкретного агента или его версии, как не терять промежуточные результаты прогонов, как хранить артефакты и сравнивать результаты между версиями.