Kurgan-Telecom Ru | Информационные технологии

Допустим, вы пишете программу для обработки изображений. Программа получает изображение, преобразует его в значения с плавающей запятой, выполняет обработку и сохраняет изменённые пиксели на диск в виде 8-битных цветов. Сегодня я хочу рассмотреть вопрос преобразования целых значений в значения с плавающей запятой. Существует два решения, которые на Python и NumPy выглядят так:

Стандартное деление на 255

pixels = img / 255.0
result = process(pixels)
output = np.trunc(result * 255 + 0.5)

Альтернативное деление на 256

pixels = (img + 0.5) / 256.0
result = process(pixels)
output = np.trunc(result * 256)

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

# Ограничение и преобразование в 8 бит
output_8bit = output.clip(0, 255).astype(np.uint8)

В стандартном случае целочисленный 0 соответствует 0.0, а 255 соответствует 1.0. Это работает абсолютно нормально и именно так всё реализовано в GPU. В альтернативном случае прибавляется смещение на 0,5 и деление происходит на 256, поэтому целочисленный 0 соответствует 0.5/256=0.001953125. Это неудобно, потому что код обработки изображений, например, без знания константы не сможет обнаруживать чёрные пиксели. Из‑за этого мы привязываем логику к 8-битным значениям, даже если вычисления выполняются с плавающей запятой. В стандартном решении всегда можно предполагать, что чёрный соответствует 0.0.

Однако некоторых программистов всё равно притягивает альтернативное решение. В чём дело? Чем оно им так нравится?

Известно, что чем больше продается мороженого, тем больше регистрируется несчастных случаев с утонувшими. Корреляция есть - значит, мороженое опасно?

Эта статья — о том, почему знание правила «correlation ≠ causation» еще не гарантирует, что вы сами на нем не попадетесь

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

Привет! Я Никита, разработчик системного ПО в Selectel. В этой статье рассмотрим эволюцию трех наиболее известных планировщиков Linux: O(1), CFS (Completely Fair Scheduler) и EEVDF (Earliest Eligible Virtual Deadline First).

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

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

Если вы пишете SQL-запросы, то наверняка сталкивались с ситуацией, когда данные исчезают, отчеты не сходятся, а бизнес теряет деньги. И виновник этого — маленькое, но очень коварное слово NULL. В 1974 году Эдгар Кодд, создатель реляционной модели данных, ввел это понятие, чтобы обозначить отсутствие информации. Он хотел, как лучше, но спустя пятьдесят лет NULL продолжает «терроризировать» разработчиков по всему миру. Важно усвоить раз и навсегда: NULL — это не значение. Это состояние неизвестности.

Поэтому:

·       NULL ≠ 0 (ноль - это число);

·       NULL ≠ '' (пустая строка - это строка);

·       NULL ≠ ' ' (пробел - это символ).

Но всегда есть нюансы и исключения. Например, в Oracle INSERT INTO table (col) VALUES ('') запишет NULL. Это поведение отличается от других СУБД и часто становится сюрпризом при миграции.

Команда VK Cloud подготовила перевод обзора релиз-команды Kubernetes (Arsh Sharma, Christopher Tineo, Kirti Goyal, Sophia Ugochukwu, Swathi Rao, Troy Connor) из блога kubernetes.io. О том, что устареет, сломается и перейдёт в GA в Kubernetes v1.37, релиз которого запланирован на 26 августа 2026 года. Будет полезен тем, кто эксплуатирует кластеры Kubernetes в проде: DevOps- и SRE-инженерам, платформенным командам, которые планируют обновление.

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

Вчера получила пуш от Я.Навигатора о “новой” фиче “по шагам”. 

Привет! Меня зовут Маша, я Senior Product Manager и я разбираю только те продукты, которыми сама пользуюсь, люблю и вижу, где есть потенциал роста. Мне драйвово искать для них решения, которые выводят продукт на новый уровень не только по деньгам, но и по UX и любви пользователей

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

В марте Nvidia показала DLSS 5 и получила такую волну критики, какой у зеленых не было довольно давно. Сейчас, спустя несколько месяцев, компания дала повод снова о ней поговорить. Она просто вышла и показала то, что стоило показывать сразу. Это касается в первую очередь инструментов, которые развязывают руки разработчикам и позволяют лучше управлять нейросетями в своих играх. Звучит пространно и непонятно, но сейчас разберем, в чем именно преимущество новой функции.

А помните, был такой Vine? В конце 2010-х это приложение для коротких видео, казалось, вот-вот станет тем, во что в итоге превратился TikTok. Вместо этого его купил Twitter и быстро закрыл.

На этом, по идее, история должна был и закончиться, но на самом деле у нее было совершенно дикое продолжение, и нет, речь не о Логане Поле, перебравшемся из Vine в YouTube.

Речь про HQ Trivia.

Я много лет занимался инфраструктурой. Потом перестал и ушёл в продукт — но привычка заглядывать: «А как у вас тут всё устроено?» осталась. И вот теперь я хожу к клиентам по совсем другим вопросам, а глаза всё равно выпадают.

Когда кожа начинает шелушиться или стягиваться после умывания — это значит, что есть пробитие в верхнем слое. Он устроен как кирпичная кладка — кератиноциты окружены межклеточным жировым матриксом. На 40–50% он состоит из церамидов. Это молекулы, которые держат кожный барьер герметичным. Они не дают влаге бесконтрольно испаряться и не пускают внутрь бактерии и аллергены. Если умываться мылом до скрипа, постоянно жить в сухом воздухе или просто стареть — церамидов становится меньше. Барьер теряет плотность, и кожа начинает реагировать на всё подряд.

Казалось бы, логичное решение — намазать чем-нибудь жирным. Вазелином, например. Он, правда, снижает испарение воды, но работает как временная заглушка. То же самое с маслами. Чтобы восстановить барьер, нужны родные запчасти. У человека как минимум девять видов церамидов, и повторить их архитектуру в лаборатории долго не получалось — мешала сложная геометрия молекул.

Решение внезапно нашли в рисе.

Привет! Меня зовут Кристина, я MLOps-инженер в Туту. Занимаюсь тем, что помогаю рекомендательным системам добраться до прода со всеми компромиссами, горящими дедлайнами и новыми идеями. 

Эта статья — про один из таких запусков.

В идеальном ML-мире запуск рекомендаций выглядит примерно так: полгода проектируют хранилище признаков (Feature Store), настраивают, откуда и как берутся данные, гоняют тяжёлые расчёты фичей и моделей, а отдельная команда следит, не деградирует ли модель из‑за изменений в данных. 

В реальном бизнесе у тебя есть 5 недель до старта высокого сезона, два инженера, DS и задача: сделать так, чтобы пользователь, который купил билет, сразу увидел релевантный отель. Рассказываем, как мы собрали работающую RecSys v1 на привычном стеке: Kafka, MongoDB, ClickHouse. При этом мы сознательно отказались от перфекционизма ради скорости.

Инженерный вызов здесь не в масштабе и не в алгоритмах, а в контексте. Cross-sell в travel — это не «похожие товары». 

Пример

Пользователь купил билет Москва → Сочи на 10–17 июля: значит, нужно показать отели именно в Сочи, именно на эти даты. 

Коллаборативная фильтрация без контекста поездки — «похожие пользователи → похожие отели» — не знает ни город, ни даты, ни то, что заказ только что оплачен и его ещё нет в DWH. 

Нужен подход, где контекст конкретной поездки — куда, когда, с кем — задаётся явно до ранжирования.

«Правильный» путь —  Feature Store и полноценная ML-платформа, занял бы 4–6 месяцев. Бизнесу нужно было проверить гипотезу на живом трафике. Мы собрали v1 на том, что уже работало в проде, с некоторыми компромиссами и без иллюзий насчёт идеальной архитектуры. 

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

На связи Юлия Шеянова, менеджер проектов в здравоохранении, Центр технологий для общества Yandex Cloud. В этой статье расскажу, как мы в Yandex Cloud вместе с Ассоциацией детских ревматологов (ASPiRRe) и студентом ИТМО сделали ИИ-агента для системы дистанционного мониторинга. 

Ниже — как он устроен и почему мы доверили модели только две узкие задачи, а все решения о рисках вынесли в детерминированные правила.

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

На связи Юлия Шеянова, менеджер проектов в здравоохранении, Центр технологий для общества Yandex Cloud. В этой статье расскажу, как мы в Yandex Cloud вместе с Ассоциацией детских ревматологов (ASPiRRe) и студентом ИТМО сделали ИИ-агента для системы дистанционного мониторинга. 

Ниже — как он устроен и почему мы доверили модели только две узкие задачи, а все решения о рисках вынесли в детерминированные правила.

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

Между этими двумя мирами находится большой цифровой тракт. Данные проходят через протокольную обработку, канальное кодирование, модуляцию, размещение в частотно-временной ресурсной сетке, OFDM-преобразования, IQ-представление, цифровую фильтрацию, ЦАП/АЦП, квадратурное преобразование частоты, усилители. И все это должно работать в жестких временных рамках, синхронно с другими базовыми станциями, с контролем мощности, спектральной маски, задержек, помех и других требований стандарта.

Меня зовут Дмитрий Надумин, я инженер-программист в радиочастотном центре YADRO. В статье разберем путь данных с инженерной точки зрения: как они превращаются в QAM-символы, раскладываются по OFDM-поднесущим, как IFFT формирует временные IQ-отсчеты, почему RU работает именно с IQ-представлением и как в итоге на вход антенны попадает один суммарный полосовой RF-сигнал.

Сингапурская исследовательница Шаньюань У (Shangyuan Wu) из Национального университета Сингапура опросила 14 журналистов и редакторов из печатных, телевизионных, онлайн-СМИ и информационных агентств и получила довольно тревожную картину. Чем активнее редакции внедряют ИИ, тем быстрее у части журналистов атрофируются базовые профессиональные навыки — от умения находить информацию и проверять первоисточники до способности самостоятельно мыслить и принимать решения. Тезис исследования простой — деквалификация это уже наблюдаемый процесс и остановить его может только осознанное ограничение использования ИИ плюс освоение новых скиллов, которых у журналистов раньше не было.

Привет! Сейчас покажу штуку, которую я довольно долго доводил до ума, и мне кажется, она может пригодиться не только мне.

Задача звучит скучно: нагенерировать тестовые карточки людей. Пол, имя, диагноз. Скучно ровно до того момента, пока не посмотришь, что получилось:

На YouTube очень часто мне попадаются видео, где сравнивают разные LLM для вайбкодеров: сделай 3D-аквариум с рыбками, напиши игру, слепи лендинг. Но по ним совсем непонятно, как эти модели поведут себя на существующем проекте с большой кодовой базой и можно ли их применять для ежедневных задач веб-разработчика.

Уже давно пользуюсь Claude Code, и он, в принципе, закрывает все потребности. Но при активной разработке лимиты кончаются довольно быстро... Кроме того, есть риск блокировок, поэтому я всё чаще посматривал в сторону локальных LLM. Было интересно, когда же настанет момент, что их реально можно будет использовать в повседневной разработке.

К сожалению, все модели, которые получалось запустить на своих 16 ГБ VRAM, не внушали оптимизма. Да, их можно использовать для суммаризации текста или написания короткого фрагмента кода, но до агентского кодинга им было очень далеко. И вот мне выдалась возможность поэкспериментировать с DGX Spark, который имеет 128 ГБ унифицированной памяти. Результатами этого эксперимента и хочу поделиться.

В качестве агента для локальных моделей выбрал Hermes — его имя постоянно мелькало в обсуждениях, и многие его хвалили, так что решил попробовать именно его. Модели крутились через vLLM на DGX Spark: весь процесс — чтение кода, поиск нужных мест, внесение правок, запуск тестов и статического анализа — выполнялся самим агентом, без участия человека (но иногда нужно было написать «продолжай», когда работа прерывалась по каким-то причинам).

Тестировал всё на реальных задачах из своего проекта на Symfony. Результатами первых прогонов поделился с коллегами, и им стало интересно, могут ли локальные модели конкурировать с детищем Сбера — тем более что GigaChat недавно обзавёлся агентным режимом. Так в сравнение добавился GigaCode (использовал его внутри GigaIDE) — облачный агент, который на момент написания статьи бесплатен.

От переводчика: это перевод сольного выпуска подкаста Шона Кэрролла - замечательного популяризатора науки, теоретического физика и профессора Университета Джонса Хопкинса. 

Физика переживает кризис. По крайней мере, нам так говорят. Мне доводилось слышать это в интернете, в подкастах и даже читать об этом в книгах. Мол, прямо сейчас физика находится в состоянии кризиса. И мне грустно это слышать. Я вырос с мечтой стать физиком. Теперь я физик. Помимо всего прочего, физика - это моя жизнь. Я очень ее люблю. Поэтому, когда я слышу, что моя область переживает кризис, это меня тревожит. Но что вообще значит “кризис”? Законы физики перестали работать? Физики объявили забастовку? Что именно происходит? Поэтому я решил записать сольный выпуск и рассказать вам о своем взгляде на так называемый кризис в физике. А взгляд мой заключается в том, что никакого кризиса в физике нет. Вот что я думаю. В любом случае, я объясню, почему я так считаю, а выводы вы сможете сделать сами. Но сначала хочу сказать, что мне немного грустно оттого, что приходится занимать именно эту сторону.