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

Да, есть определенная хронология у развития нейросетей. Знаковые, скажем так, места. Стэнфорд, Торонто, DeepMind. Хинтон, ЛеКун, Бенжио. И много еще дат с разнообразными событиями. А вот в Красноярске в 1996-м вышла книга "Нейронные сети на персональном компьютере". Её автора звали Александр Горбань.

Привет, дорогой Хабр. Давайте сегодня все вместе вспомним этого выдающегося человека.

Синхронный WAL очень частое явление в базах данных, делая их durability максимальной. При таком исходе каждый батч записи это вызов fsync, и это дало мне 956k opr/s на 16кб значениях , звучит хорошо, но на самом деле: скорость записи упала в 5 раз.

В этой статье я расскажу:

Что такое групповой коммит на пальцах

Почему групповой коммит не для финтеха

Как это реализовано у меня

Как изменились цифры до и после внедрения

Во сколько раз ScoriaDB с group commit быстрее BadgerDB и Pebble.

Если вы пишете хранилище, логгер, кэш или просто любите копаться в LSM‑движках — добро пожаловать на борт, нас ждет короткое путешествие

Всем привет. Я сделал бесплатную обучающую платформу shlyk.tech с упором на визуализацию идей и структур. Графы, системы счисления, логику, комбинаторику, индукцию здесь можно потрогать, покрутить, прошагать и понять, почему оно так работает.

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

В прошлой статье про Гамма-флип я вскользь касался механики работы с отклонениями, но не раскрыл тему до конца.

В этой статье мы углубимся в стохастический анализ и рассмотрим методы определения стационарности временных рядов в реальном времени. Разберем математический аппарат расширенного теста Дики-Фуллера (ADF), причины его интеграции в ядро нашей торговой системы и особенности реализации на Python при работе с большими массивами данных.

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

Недавно я собирал ровно такой движок и наткнулся на библиотеку, которая делает эту работу заметно аккуратнее. Называется pydantic-graph. Про неё почти не пишут, хотя на ней стоит весь pydantic-ai, агентский фреймворк от авторов Pydantic. Дальше я расскажу про неё на конкретном примере, харнессе надёжности для слабых языковых моделей.

Сразу оговорюсь про термин, потому что он сейчас на слуху. Харнесс это не только MCP, скиллы и память. Это ещё и робастность, в том числе у совсем небольших моделей. Вот эту вторую часть я и беру за пример. Но статья не столько про модели, сколько про сам подход. Основная мысль простая: это удобный способ собрать движок для чего угодно, где есть состояния и переходы, и при этом не утонуть в собственном цикле.

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

Теперь попробую разложить архитектуру UI по нескольким осям, именно осям, потому что один и тот же UI может быть diegetic по расположению, immediate mode по хранению, reactive по потоку данных, flexbox по лейауту и векторным по рендеру одновременно, а проблемы начинается там, где люди пытаются совместить несовместимое.

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

В статье разберём, как Pipeline в sklearn помогает собрать обработку данных и модель в единый воспроизводимый конвейер, снизить риск data leakage и упростить работу со сложными ML‑сценариями.

Много лет назад моя рутинная работа заключалась в поддержке большой базы кода на C++. Этот проект был настоящим кормильцем всей компании, и в нём предоставлялся публичный HTTP API, через который принимались онлайн-платежи. Речь шла об обработке платежей в размере миллиардов евро ежегодно.

Тогда меня ещё было не назвать опытным C++-разработчиком. Разумеется, я знал о неопределённом поведении, но как о чём-то абстрактном, о беде, которая приключается только с новичками. Как же я был неправ!  

В этой статье везде, где написано «структура», я имею в виду «структура или класс».

Полгода назад я написал статью про FlakyDetector — инструмент, который ищет нестабильные тесты по одному лишь исходному коду, Потом была статья FlakyDetector 2.0 . AST + CatBoost, 37 признаков, вроде бы всё круто.

Но один комментарий меня добил.

Пользователь Ariless рассказал реальный кейс: в их проекте тест падал с SLOT_OVERLAP — не потому, что в коде теста было что-то плохое, а потому что фикстура была общая на несколько тестов (shared scope). Предыдущий тест не успел почистить слот — следующий упал.

В предыдущей статье я разобрал что умеет REDB на практике: code-first схемы, LoadAsync без Include, LINQ с оконными функциями, деревья, redb.Route и redb.Tsak. Если не читали — начните с неё, она даёт общую картину.

Теперь начинаю цикл «REDB изнутри» — серия статей про устройство хранилища: как хранятся объекты и свойства, как работают схемы и кэш структур, как LINQ превращается в SQL, как устроены деревья, права, оконные функции. Всё с реальным SQL под капотом.

Первая статья цикла — про саму базу данных. Без понимания схемы таблиц всё остальное будет висеть в воздухе.

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

Тема экономии токенов сейчас дико популярна, и мы с ребятами в Гильдии AI-инженеров знатно её пообсуждали. Напомню краткую суть: там связка Serena (LSP) + Semble (векторные эмбеддинги) + Ripgrep (поиск координат) показала себя абсолютным топом для точечной навигации.

Но в комментариях и личке мне тут же начали советовать: «Нахлобучь сверху еще rtk для сжатия вывода терминала и context-mode для полнотекстового индекса репозитория! Тема прокси-экономии сейчас на пике хайпа, сэкономишь еще больше!». Я подумал за**ись.

И решил провести душный чек. Взял популярный open-source проект supermemory (~180 файлов, JS/TS) и замерил: действительно ли добавление rtk + context-mode дает реальный профит поверх моего текущего сетапа, или это просто карго-культ и оверхед, который утянет бюджет в минус?

Привет, Хабр!

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

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

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

Если коротко — хочу сделать не «революционный AGI», а понятный конструктор, на основе которого любой разработчик сможет собрать своего личного ассистента.

Иногда одна строка датасета соответствует не одному объекту, а целому набору связанных объектов: новостям, комментариям, изображениям или событиям. Каждый из них можно превратить в эмбеддинг, но модель обычно ждет фиксированный набор признаков. В статье разбираю, как с этим работать на практике: от простых агрегатов и pooling до MIL, LLM‑разметки и гибридных подходов.

Спойлер: я не выпускник МФТИ, не олимпиадник и ненавидел программирование. У меня было 45 баллов ЕГЭ по математике, диплом инженера ПГУПС и стойкое ощущение, что в IT мне не светит ничего. Сейчас я Senior Data Scientist в крупном банке, а в 26/27 буду преподавать в ИТМО. В этой статье - как именно так получилось, и что нужно понять, чтобы не сидеть годами на одной работе за 100к, когда соседняя сфера платит втрое больше.

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

Вышла недавно статья на Хабре, которая осталась незамеченной.

Девушка, которая не шарит в программировании, навайбкодила телеграм-бота для практики английского. Бот буквально является оберткой над ChatGPT.

Что не так с этой историей...

В феврале 2026 года эксперты F6 Threat Intelligence обнаружили файл, исследование которого привело к раскрытию инфраструктуры ранее неизвестной группировки. Специалисты F6 назвали её SiribClone – по метаданным одного из атакующих и используемому инструменту rclone (утилита командной строки с открытым исходным кодом для работы с облачными хранилищами). Несмотря на небольшое количество обнаруженных публичных сэмплов, мы установили, что атакующие активно тестировали свои разработки с декабря 2025 года, а самые ранние следы фишинговой активности злоумышленников датируются летом 2025 года.

В начале XIX века английские ткачи ломали станки — не потому что не понимали технологию, а потому что понимали слишком хорошо. Два века спустя эта тревога возвращается.

Перевод статьи Why the Biggest Threat to Robotics Isn't Technical (Six Degrees of Robotics, Аарон Прейтер, май 2026) о том, почему главная угроза робототехнике сегодня — не техническая, с моими пояснениями для тех, кто следит за темой снаружи индустрии.

Remote Photoplethysmography (rPPG) — это технология бесконтактного измерения физиологических сигналов человека по видеозаписи. Изначально метод создавался для оценки пульса через обычную камеру, но позже стал одним из важных инструментов обнаружения дипфейков.

Основная идея очень проста:

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

Для настоящего человека физиологический сигнал присутствует всегда, однако его качество извлечения зависит от условий съемки. В синтетических видео rPPG-сигнал часто отсутствует, искажается или демонстрирует физиологически неправдоподобные характеристики.

Почему дипфейки плохо проходят rPPG

Большинство генеративных моделей обучаются воспроизводить -

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

Признак 1. Отсутствие пульсового сигнала

В некоторых дипфейках спектр выглядит как шум:

Настоящее лицо:

пик на 75 bpm

Дипфейк:

хаотический спектр

без выраженного пика

Признак 2. Несогласованность областей лица

У живого человека:

лоб,

правая щека,

левая щека

показывают одинаковый пульс.

Например:

Лоб: 72 bpm

Правая щека: 73 bpm

Левая щека: 71 bpm

У дипфейка:

Лоб: 62 bpm

Правая щека: 91 bpm

Левая щека: 47 bpm

что физиологически маловероятно.