Алгоритмы *

На каждой второй конференции по медицинскому AI звучит один и тот же сценарий: «Дообучим мультимодальную модель, скормим ей DICOM, и она сама выдаст диагноз». На практике, когда этот скрипт пытается попасть в реальную клинику, начинаются неожиданности. OOM на GPU, врачи не понимают, где галлюцинация модели, а где финальный отчёт, двухгигабайтные NIfTI-исследования рвут таймауты балансировщика.

Я какое-то время тоже думала, что главное — это модель. А потом пересмотрела собственный код. У меня уже есть MRI Second Opinion. Но это не нейросеть. Это контур с доменной моделью, конвейером приёма данных, циклом обработки, обязательным врачебным рецензированием, финализацией и отдельным репозиторием с открытым кодом. В медицинском IT модель — не главная проблема. Главная проблема — чтобы между входом и выходом ничего не потерялось и не сломалось.

Многие наверняка сталкивались с проблемой: смотришь по ТВ спокойный фильм, который прерывается резкой и громкой рекламой; или, например, при общении по ВКС всех собеседников слышно нормально, но у кого-нибудь одного микрофон будет шуметь так, будто он в данный момент находится рядом с двигателем самолета, готовящегося взлетать. Конечно, всегда можно подрегулировать громкость динамиков, но всегда ли это удобно и возможно?

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

Привычная логика уже не такая привычная. SEO разрастается до GEO: SEO + PR + репутационный маркетинг. Сегодня: почему конкретные нейросети ChatGPT, Алиса, Gemini и другие выбирают одни источники и игнорируют другие. Поговорим о факторах присутствия в ответах конкретных ИИ-систем.

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

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

Я работал над Pizza Legacy — опенсорсным воссозданием игры 1994 года Pizza Tycoon для DOS. В игре есть вид на улицы города, при скроллинге которого игрок наблюдает постоянный поток машин. Это примерно 20-30 маленьких спрайтов, однако они едут по дорожной сети, создают очереди на перекрёстках и в целом выглядят как оживлённый город. Да, симуляция иногда глючит, машины проезжают друг через друга, но этого достаточно, чтобы придать карте ощущение жизни. И всё это на процессоре 386 с частотой 25 МГц.

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

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

Всё это время мне не давала покоя одна мысль: если оригинальная Pizza Tycoon работала на процессоре с частотой 25 МГц, то почему мои версии всегда оказывались столь сложными?

Наконец, я решил заняться ассемблерным кодом (на медленное понимание и документирование которого я уже потратил много лет), чтобы разобраться, что же происходит в оригинале; кроме того, я воспользовался помощью LLM, которые на тот момент (пару лет назад) были новой и увлекательной технологией, способной разбираться в ассемблерном коде лучше, чем я.

Ни Python, ни PyTorch, ни NumPy, … всего 260 строк кода на чистом C++ достаточно, чтобы обучить, оценить и протестировать простой двоичный классификатор, различающий рукописные цифры 0 и 1.

Это третья статья про мой "аниме завод" — систему, которая автоматически превращает длинные эпизоды в Shorts.

Если хотите полный контекст, вот предыдущие части:

Привет, Хабр! Если вам когда‑либо хотелось разобраться в том как работает линейная регрессия, или хочется освежить в памяти основные моменты без необходимости продираться через разрозненные источники, то прошу под кат. Это не статья «от начинающего для начинающих. Экстра лонгрид — писал больше года. Статья концептуальная, а концептов пять: 1) ключевой повествовательный компонент — визуализации (их около сотни), текст — вспомогательный; 2) анимации везде где только можно (их всего 34); 3) простота — достаточно знаний со школьного курса математики чтобы начать читать; 4) воспроизводимость — подавляющее большинство медиаматериалов сгенерированы при помощи Python а исходный код выложен в open‑source и, самый главный, 5) фокус на практике, — например, если упоминается векторная запись метода наименьших квадратов, значит она в нарративе решает возникшую боль читателя.»

В предыдущей статье о Vinyl я рассказывал об архитектуре LSM-движка Tarantool. Восемь лет, прошедшие с момента с написания статьи, показали, что Vinyl сразу получился идеальным и менять его не нужно :). Если серьёзно, сегодня я расскажу о тех изменениях, которые мы внесли в алгоритм в форке Tarantool от Picodata, и неизбежно коснусь более глубокой проблематики работы LSM-деревьев, а конкретнее – работы планировщика слияний (compaction scheduler).

Если вы когда-нибудь пытались натравить классическую LSTM на минутные свечи волатильных активов, вы знаете эту боль. Сначала Loss красиво падает на трейне, вы предвкушаете покупку острова, а на тесте модель превращается в тыкву. Она либо предсказывает скользящую среднюю со сдвигом на один шаг, либо упирается в «стену» Loss = 0.693 (то есть −ln(0.5)), сводя всё к подбрасыванию монетки.

Проблема не в вас. Проблема в том, что рекуррентные сети (RNN, LSTM, GRU) живут в дискретном времени. Для них шаг между 10:00 и 10:01 абсолютно идентичен шагу между пятницей и утром понедельника. Они не умеют сжимать и растягивать восприятие времени, когда волатильность взрывается.

В этой статье мы отойдем от мейнстримных архитектур и напишем с нуля Liquid Neural Network (Жидкую Нейронную Сеть). Мы заставим время течь непрерывно, используя численные методы дифференциальных уравнений прямо внутри PyTorch-графа, и посмотрим, как она вытаскивает скрытый макро-тренд из абсолютного рыночного хаоса.

Теория без воды: Что делает сеть «жидкой»?

Концепция Liquid Time-Constant Networks была представлена исследователями из Лаборатории искусственного интеллекта MIT (CSAIL). Их изначальная цель — управление дронами и автопилотами в непредсказуемой среде. Но финансовые рынки — это та же турбулентность, только выраженная в долларах , рублях и других валютах.

В классической RNN скрытое состояние h_t обновляется по дискретным шагам:

В Liquid Network мы отказываемся от дискретности. Состояние нейрона h(t) — это непрерывная переменная, описываемая обыкновенным дифференциальным уравнением (ОДУ):

Механизм внимания (Attention) - это метод в искусственном интеллекте, который позволяет нейросети динамически определять, какие части входных данных наиболее важны для текущей задачи. Он работает через вычисление весов важности для разных элементов входа: более важные элементы получают больший вес, а менее важные - меньший. Затем модель формирует взвешенную сумму представлений, создавая новый контекстный вектор.

Self-attention, в свою очередь, помогает модели понимать, как разные элементы входных данных связаны между собой. Например, как разные части информации взаимодействуют и влияют друг на друга в общем контексте. Этот механизм обеспечивает логическую связность и целостное понимание всей структуры данных

Баг в бинарном поиске Java прожил в стандартной библиотеке почти десять лет — и в 2006 году его разбор опубликовал сам автор кода. Казалось бы, бинарный поиск проходят на первом курсе. Но между «понял идею» и «написал без ошибок» — целая пропасть. В этой статье разберём четыре алгоритма поиска (линейный, бинарный, экспоненциальный и с использованием хеш-таблицам), покажем, когда какой выбирать, и разложим по полочкам пограничные случаи, на которых горят и на собесах, и в проде.

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

400 000 строк в файле Excel, а пропущенный день это дырка в истории и отчёты, которые тормозят даже на мощном ПК — именно с этим столкнулся алготрейдер Дмитрий Овчинников. Но он смог при помощи ИИ ассистента создать дашборд, который упрощает управлением его 100+ стратегиями в алготрейдинге. И это, по его словам, как пересесть с запорожца на вертолёт.

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

Новый пост-квантовый гибридный алгоритм шифрования для высоко-нагруженных систем с реализацией на TypeScript. Ring-LWE, работа с ключами с использованием MAC и SHAKE-256, защита от основных видов атак и другие мысли в реализации протокола QuarkDash.

512 000 строк утекшего кода. 44 feature‑флага. Система питомцев в духе тамагочи. Имена вроде «Tengu», «Fennec» и «Penguin mode». Всё это — то, о чём написали сотни новостей. Но не это главное.

Пока интернет разбирал по косточкам внутренности Claude Code, увлечённо споря, игрушка это или серьёзная архитектура, настоящая ценность утечки осталась почти незамеченной. Anthropic случайно показала миру не список фич. Она показала, как на самом деле думает её ИИ‑агент.

За милыми именами и игровыми механиками скрывается жёсткая инженерная реальность: самовосстанавливающийся цикл запросов, вычисления во сне и двухуровневая система отсечения функций. Это уже не обёртка над API. Это операционная система для ИИ. И сегодня мы разберём три паттерна, которые делают Claude Code не просто дорогим автокомплитом, а продуктом на 2,5 млрд $ в год.

В середине прошлого века люди задумались, способен ли человек передать некоторой системе (например, компьютеру) роль непосредственного создателя художественного произведения. Можно ли не просто превратить устройство в инструмент художника, а сделать его автономным генератором формы, цвета или звука? Так зародилось процедуральное (или генеративное) искусство.

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

Прочитал на Хабр статью [1], в которой автор простым языком даёт достаточно глубокое представление такого сложного и важного математического объекта как фильтр Калмана и захотел предложить читателям посмотреть на него (фильтр Калмана) несколько с другого ракурса. Сразу хочу предупредить, что перед чтением данной статьи хорошо бы прочесть статью [1], так как даже формулы были специально взяты ровно оттуда, дабы данная статья базировалась на материале упомянутой работы [1].

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

Общая идея такова: берём математическую модель двигателя и в режиме реального времени «запитываем» её показаниями датчиков напряжений фаз работающего двигателя насоса. Показания датчиков тока используем для того, чтобы в реальном времени втянуть виртуальную модель в такой режим, при котором виртуальные показания квазидатчиков тока математической модели станут равны показаниям реальных датчиков тока. То есть в этом случае мы получим виртуальную real time модель из которой можем взять любую информацию, которой она располагает, в частности частоту вращения электродвигателя.

А теперь изложенную идею попробуем воплотить в виде математических абстракций.

Мы привыкли, что повтор r в ECDSA — это случайный сбой: плохой генератор, ошибка реализации, повтор nonce. Но что, если за одним repeated-r скрывается целое семейство дефектов (defect-family), которое можно не только обнаружить, но и перенести на другие закрытые ключи?

Представляем закрытую исследовательскую систему — стратификационный анализ ECDSA-подписей на secp256k1. Вместо точечных аномалий мы смотрим на фазовые корпуса подписей, используем торическую геометрию, kNN и перестановочные тесты. Результат:

· Во внешнем корпусе из 30 адресных контекстов и 6257 подписей repeated-r найден только в 1 контексте, межадресных коллизий r — 0. · 58 из 58 контролируемых переносов defect-family с реального адреса-донора на панель реальных адресных целей прошли с полной ECDSA-валидацией реконструированных подписей. · Встроенный publication-safety audit заблокировал открытый bundle, обнаружив 498 проблем (30 критических) — от raw (r,s,z) до восстановленных синтетических k и фрагментов закрытых ключей.

В публичной версии отчёта — только математика, агрегаты и безопасные листинги. Никаких инструкций по эксплуатации. Это продолжение методологии AuditCore, но уже на уровне стратифицированного анализа.