Привет, Хабр. Хочу рассказать про «Конкурса красоты кода», который мы снова запускаем. Год назад мы его придумали, и идея народу зашла — больше 1000 человек прислали свои работы. Идея была в том, что есть несколько задач на выбор, и их надо решить в коде. Условий три: код должен работать, быть лаконичным и удобочитаемым.

Год пролетел, и мы решили повторить. Опять зовём всех поучаствовать — напиши такой код, которым будешь потом гордиться. Даже если ты не программист, победа может быть отличным стартом для карьеры (но, конечно, без гарантий).

Консоль Dendy в первую очередь ассоциируется с относительно простыми играми (Super Mario Bros, Duck Hunt, Battle City и т. д.), которые обычно не требуют сложных расчётов и обходятся целочисленной математикой. Но как только нужно сделать трёхмерную графику или сложную физику, сразу появляется потребность в точных вычислениях и дробных числах.

Самым простым и быстрым способом программного представления дробей являются числа с фиксированной запятой (Fixed‑point числа). О реализации такой арифметики для NES/Dendy мы и поговорим.

Анализ данных на уровне муниципалитетов осложняется преобразованиями структуры территориальных единиц: меняются не только границы, но и типы муниципалитетов, названия, код ОКТМО. Это нужно учитывать в ходе исследований и при использовании информации, например, при работе с Базой данных показателей муниципальных образований Росстата. Открытых машиночитаемых данных о таких преобразованиях нет.

Меня зовут Артём Кушлевич, я геоаналитик из команды СберИндекса. В этой статье расскажу, о каких нюансах муниципальных данных нужно знать аналитикам, как мы сделали пространственный слой муниципалитетов с историей версий и разработали справочник преобразований, который можно использовать для построения непрерывных временных рядов. Эта информация может помочь:

— геоаналитикам, заинтересованным в данных о границах муниципальных образований;

— исследователям, которые работают с муниципальными данными (в первую очередь с Базой данных показателей муниципальных образований Росстата (БДПМО));

— при проектировании БДПМО 2.0.

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

Video Understanding — направление на стыке компьютерного зрения (CV) и обработки естественного языка (NLP), включающее в себя множество разнообразных задач на восприятие и интерпретацию видео. От базового распознавания предметов и объектов в видеоряде, локализации объектов в пространстве или во времени, подсчета предметов и людей, до генерации кратких или развернутых описаний видео и задач на рассуждения о причинах происходящего на видео, требующих глубокого понимания мира — от человеческой психологии до физических свойств объектов. 

Привет, Хабр! Меня зовут Артем Безруков, я DevOps‑инженер в команде интеграционных сервисов Platform V Synapse в СберТехе.

Наша команда работает над продуктом из линейки Platform V Synapse — Platform V Synapse Messaging. Это брокер сообщений, в основе которого лежит Apache ActiveMQ Artemis. Мы делаем из него более безопасное и функционально обогащённое решение, разрабатывая дополнительные плагины, и заботимся о том, чтобы его можно было просто и быстро развернуть с помощью наших скриптов автоматизации.

В последние годы набирает обороты тренд на использование облачных технологий, технологий контейнеризации и микросервисной архитектуры, и наша команда решила расширить возможности продукта. И если изначально стенды ограничивались только виртуальными машинами (ВМ), то с недавнего времени мы начали выводить Platform V Synapse Messaging в среды оркестрации контейнеров — Kubernetes (K8s/облако).

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

Поехали!

Добрый день, уважаемые читатели Хабра. В связи с бурным развитием генеративных моделей и реализованных на них чат‑ботов (ChatGPT, Gemini, Bard, Notion AI, Compose AI, Poe, Phind) у пользователя появляется ложное чувство, что модели стали умнее, защищённее и, в целом, ближе к совершенству, сравнимы с человеческим интеллектом. Отсюда мы получаем целый пласт заблуждений. Например, что модели нас «чувствуют», «понимают», ведь мы выкладываем для них столько информации о себе, начиная от стилистики нашего письма, что уже является неким цифровым отпечатком нашей личности, и заканчивая оценкой их собственной работы. На самом деле это миф. И трендом 2023–2024 годов стало обширное внимание публики к XAI:

• как они (генеративные модели) устроены и как они принимают решения;

• как проводятся атаки уклонения (склонение моделей к неверной выдаче);

• как эти атаки (уклонения) связаны с другими атаками на LLM и какие они могут быть для эскалации деструктивного поведения системы;

• с какой позиции верно интерпретировать выход генеративной модели;

• разработка системы эшелонированной защиты моделей;

• разработка системы внутреннего критика для модели.

Для начала начнём с существующих атак и их анализа. Заинтересованных приглашаем под кат.

Технология «deepfake» несёт в себе глубокие этические последствия, усиливая опасения по поводу дезинформации и манипуляций. Плавно смешивая сфабрикованный контент с реальностью, дипфейки подрывают доверие к СМИ и общественному дискурсу. А так как образы людей эксплуатируются без их согласия, это ставит под угрозу и личную безопасность. 

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

Предыдущая лекция.

Рандомизированные контролируемые испытания (РКИ) представляют собой наиболее объективную, прозрачную и эффективную методологию для проведения экспериментов. Они пользуются огромной популярностью и применяются в самых разных сферах, включая науку, медицину, маркетинг и технологии. С их помощью учёные и специалисты могут проверять эффективность новых методов лечения, лекарственных препаратов, продуктов или услуг, сравнивая результаты между двумя или более группами. РКИ встречаются гораздо чаще, чем может показаться на первый взгляд. Это невероятно популярный метод исследования причинно‑следственных связей. Хотя они довольно просты в реализации, их точность значительно превосходит все другие методы аппроксимации .

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

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

Однако со временем стало ясно, что для полного понимания данных необходимо научиться объединять эти два подхода. Здесь на сцену выходит причинно‑следственный вывод (Causal Inference). Эта область Data Science помогает раскрыть причины явлений, объединяя преимущества как машинного обучения, так и эконометрики. Judea Pearl в своей статье 2021 года подчеркивает важность причинно‑следственного вывода как «ключевого элемента для достижения баланса между радикальным эмпиризмом ML и интерпретационным подходом эконометрики».

Таким образом, Causal Inference — это область статистики и научных исследований, направленная на выявление и измерение причинно‑следственных связей между переменными. Она помогает определить, какое воздействие оказывает изменение одной переменной на другую, отличая это воздействие от простых корреляций.

Привет, Хабр! Меня зовут Дмитрий Королёв, я инженер по нагрузочному тестированию Platform V Pangolin — целевой СУБД в Сбере и не только. Эту статью я написал вместе с моим коллегой Алексеем Хорохориным @AlexeyHorohorin. Наш продукт — специальная сборка PostgreSQL с доработками (крупных больше 30, а всего уже больше 70) в области безопасности, производительности, отказоустойчивости.

Условия для нас таковы: мы тестируем продукт целиком, в разных версиях, на разных ядрах. У нас работает три версии в параллель для восьми разных ОС, и тестировать нам нужно при использовании и неиспользовании разных фич. А теперь представьте, сколько тут интеграций…

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

Всем привет! Если в компании растёт количество продуктов, а для их развёртывания используются виртуальные машины, то рано или поздно возникает задача оптимизации ресурсов. Скажем, вы используете для оркестрации Jenkins. Количество агентов на ВМ при этом статично, а количество развёртываний в разное время разное. В этом случае при массовых установках агенты периодически упираются в установленный лимит исполнителей (executor), а в свободные часы ВМ простаивают, занимая ресурсы.

Мы, команда Run4Change в СберТехе, сопровождаем тестовые среды. В наши задачи входит в том числе развёртывание продуктов облачной платформы Platform V на стендах для последующего тестирования. Расскажем, как мы решили проблему использования системных ресурсов и отказались от виртуальных машин в пользу cloud‑native‑решения. Статья может быть полезна тем, кто планирует начать использование динамических агентов Jenkins, и может использоваться как первоначальное руководство.

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

Привет, Хабр! Меня зовут Станислав Епишин, я DBA в дивизионе поддержки решений в тестовых средах в СберТехе. Эту статью я написал вместе с Дмитрием Корневым, тимлидом и DBA. У Сбера есть целевая СУБД, которую разработали в СберТехе на основе open source версии PostgreSQL, — Platform V Pangolin. Наша команда перешла на Pangolin в числе первых, когда у продукта еще не было инструментов для мониторинга БД. Забегая вперед, позже появились такие решения — графическая консоль Platform V Kintsugi, расширение для сбора статистики — Performance Insights и система мониторинга IT‑инфраструктуры Platform V Monitor. А поначалу мы решили мониторить базы данных связкой Grafana, Prometheus и postgres_exporter. Но, во‑первых, столкнулись, с тем, что нам не хватает гибкости в использовании queries.yaml в postgres exporter. А, во‑вторых, так мы не могли регистрировать события с таймаутом меньше 15 секунд. Поэтому мы тогда сделали свой инструмент для мониторинга — pangolin_exporter.

Надеюсь, что эта статья будет полезна тем, кто мониторит инфраструктуру с помощью postgres_exporter и хочет кастомизировать все под свои нужды. Покажу детали и код решения.

Здравствуйте, уважаемые читатели Хабра. Чем больше я погружаюсь в LLM, тем больше укрепляюсь во мнении, что сейчас они (LLM) заняли если не самое важное, то уж точно одно из очень значимых мест во всём пантеоне моделей машинного обучения. При этом всё чаще встаёт вопрос шифрования моделей в самом широком смысле. Речь не столько о механизмах, алгоритмах, подходах и методиках шифрования того, что запрашивает пользователь, сколько о работе с данными в целом, в том числе и для обучения моделей. То есть о шифровании как на входе, так и на выходе — данных от пользователя, от модели и обучающих данных.

Мы поговорим о безопасном обращении с коммерческим контентом, шифровании данных, моделях и подходах к безопасному обращению и встраиванию коммерческих данных в модель. Будет интересно ;)

Почему это важно? Сегодня работает четвёртое поколение GPT‑систем, ждём пятое. Есть много аналогов «четвёрки» (Megatron‑LLM, LLaMA, Claude, PaLM, Mistral, BLOOM, Grok, Megatron‑Turing NLG, Chinchilla, OPT, GODEL, Jurrassic-2), которые по ряду параметров намного превосходят GPT-4. Однако для качественной «эволюции» систем необходимо «скармливать» им «правильный» эксплуатационный код, апробированный и полностью покрытый тестами, который создаётся крупными корпорациями, средним и малым бизнесом. Но есть нюанс: такой код просто так никто не отдаст. Более того, он защищён авторскими правами и имеет ряд наложенных юридических условий использования.

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

На нашей недавней конференции GigaConf мы много​​ рефлексировали о том, как будет развиваться направление DevOps. Оно немыслимо без инструментов. Поэтому я расскажу о том, как мы внедряем в Сбере практики GitAIOps, какие совершили ошибки и извлекли уроки, какие сделали выводы по поводу внедрения ИИ. Сегодня на всех углах рассказывают, как ИИ поможет разработчикам, но мало кто говорит о его помощи DevOps-инженерам. Надо это исправить.

Меня зовут Юрий Спорынин, в ИТ я более 20 лет. Начинал с разработки, своими руками создавал процессинговую систему для интернет-эквайринга. В 2016 году я перешёл в Сбер, где мы в 2018 году внедрили платформу в «Сбербанк Онлайн». Сейчас среди моих задач — кластер DevOps-инструментов, о которых мы отчасти сегодня поговорим. 

Привет, я Дмитрий Коляндра, разработчик в подразделении SberWorks, занимающемся автоматизацией и сопровождением инструментов производственного процесса. Эта история о том, что происходит в крупных компаниях, где развёрнуто много десятков экземпляров Jenkins.

Всем привет! Не так давно мы с GitVerse, платформой для работы с исходным кодом от СберТеха, проводили опрос, чтобы выяснить, как сегодня выглядит типичный программист. Не в смысле внешности, а в плане своих личных и профессиональных качеств. Опрос прошли почти 2,5 тысячи человек. Мы очень рады, что наша затея оказалась такой популярной. Теперь настало время поделиться результатами. Кто он такой — Типичный Программист-2024? Заходите под кат, чтобы узнать о нём всё.

Всем привет! Не так давно Хабр и GitVerse, платформа для работы с исходным кодом от СберТеха, проводили опрос, чтобы выяснить, как сегодня выглядит типичный программист. Не в смысле внешности, а в плане своих личных и профессиональных качеств. Опрос прошли почти 2,5 тысячи человек. Мы очень рады, что наша затея оказалась такой популярной. Теперь настало время поделиться результатами. Кто он такой — типичный программист 2024 года? Заходите под кат, чтобы узнать о нём всё.

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