Алгоритмы *

Как одна продуктовая фича может превратить обычный GPS-трекер в главную спортивную зависимость десятилетия? Разбираем феномен «KOM-хантеров» в Strava с точки зрения поведенческой психологии и системного анализа. Внутри: механика дофаминовой петли, технические уязвимости алгоритмов расчета сегментов при частоте опроса GPS в 1 Гц, программное читерство через API и то, как комьюнити устраивает самосуд над нарушителями виртуальных границ.

На волне того бардака, что творится в найме, я как-то сидел и скролил вакансии go-разработчика на одной из площадок. И тут я подумал: “Я же всегда хотел в геймдев! Интересно, в геймдеве нужны гоферы?”. Я настроил фильтр и начал скролить по новой. Пока скролил, меня посетила отрезвляющая мысль: “Да не хотел я никогда в настоящий геймдев. Я хотел в тот геймдев, который я себе сам придумал”. Но не успел я эту мысль додумать, как наткнулся на вакансию гофера, как раз в геймдев. Пробежавшись взглядом по вакансии, я наткнулся на ключевой требуемый навык: необходим опыт в игровом матчмейкинге.

Что я знаю о матчмейкинге? Его Арпад Эло придумал, вроде?

Мы не собирались писать эту статью. Мы всего лишь хотели воспроизвести результаты открытого бенчмарка ICASSP-2024 по низкодозовой компьютерной томографии, сравнить их с алгоритмами Smart Tomo Engine и понять свое место относительно опубликованных baseline и SOTA-решений.

Сначала всё шло по плану. Потом более быстрый алгоритм неожиданно оказался точнее более медленного. Затем на картах ошибок начали повторяться странные структуры. А спустя несколько дней выяснилось, что часть измеряемого качества может определяться не реконструкцией томографических данных, а особенностями самого бенчмарка.

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

Когда я впервые заинтересовался шифрованием, я знал о шифрах только то, что в них время от времени находят уязвимости. Чтобы хоть как-то разобраться в этой теме без наставника, специальной литературы и (поначалу) без доступа к интернету, я решил проводить опыты над самодельным шифром. Одни идеи сменялись другими, а новые знания из разных источников заставляли многое пересматривать снова и снова. Шифр многократно менялся, пока не приобрёл более-менее стабильные черты. Целью же данной статьи является описание истории создания этого шифра и реализованных в нём принципов, а также выставить на суд читателю полученный результат.

Я проверил маленький нейросетевой слой в арифметике GF(137): не через квантизацию готовой float32-модели, а сразу в байтовом конечнополевом представлении. В лучшем замере получилось около 4x по памяти и до 4.86x по времени относительно моей NumPy float32-реализации. Внутри — код нативного ядра, ARM NEON, таблица запусков и честный разбор, где результат не сработал.

За attention-механизм с 2017 года брались сотни раз: sparse attention, linear attention, MoE, MLA, скользящие окна, что только не. А вот residual connection, остаточная связь, та самая x + F(x) из ResNet 2016 года, простояла почти десять лет нетронутой. Её просто унаследовали из résnet'ов, воткнули в трансформер и забыли.

31 декабря 2025-го DeepSeek выложил на arXiv препринт, где взялся именно за этот кирпич. И что показательно, загрузил его на arXiv лично основатель компании Liang Wenfeng, он же в соавторах. Когда основатель сам публикует статью, это обычно значит, что она ляжет в следующую флагманскую модель. Так и вышло: mHC поехал в DeepSeek V4, который выкатили 24 апреля 2026-го.

Разберём, что они сделали, почему это работает и при чём тут матрица из шестидесятых.

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

Я решил написать морской бой на sed — потоковом текстовом редакторе из набора стандартных юниксовых утилит. Обычно его применяют для того, чтобы заменить в потоке или файле одну регулярку на другую. Но дополнительные директивы, которые есть в sed, формируют Тьюринг-полный язык, на котором теоретически можно написать что угодно.

Так, энтузиасты писали на sed мастермайнд (на наши деньги — «Быки и коровы»), сокобан, сапер и даже шахматы. Я упоролся несколько сильнее и написал игру с неполной информацией, псевдослучайной генерацией расстановок и ходов и достаточно сильным противником. Причем реализованный алгоритм позволяет усилить его еще больше, изменив буквально пару строк. Насколько я могу видеть по гитхабу, у меня получился один из самых масштабных на сегодняшний день проектов (если не самый масштабный) среди всей этой адской эзотерики.

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

Сперва я просто хотел показать, какие клевые вещи можно реализовать самыми минимальными средствами, но в итоге получился большой пошаговый гайд. Для тех, кому результат интереснее процесса, в конце статьи есть ссылка на гитхаб, чтобы сразу посмотреть, что получилось. Остальные — наливайте чайку и добро пожаловать под кат!

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

Расскажите немного о себе.

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

Работал на проекте связанном с системами автоматизированного проектирования (САПР). Занимаясь алгоритмизацией прикладных задач, быстро убедился, что алгоритмы и блок-схемы, если они относятся к предметным областям, требующим специального образования, понимают только те, кто эти алгоритмы и блок-схемы создавал.

Занялся программированием, чтобы вместо алгоритмов и блок-схем писать прототипы прикладных программ.

В то время (как время быстро летит). В то время повсеместное внедрение САПР было основной темой, подобно ИИ сейчас. Естественным продолжением карьеры стал переход из учебного заведения в отдел САПР крупного конструкторского бюро.

Отдел, в котором я работал, плодотворно сотрудничал с учебными и отраслевыми институтами и располагал весьма современной (по тем временам) вычислительной базой. Всё шло своим чередом на уровне мировых тенденций. Что потом случилось всем известно…

Когда моделируешь помехоустойчивые коды, декодер обычно остаётся чёрным ящиком: пишешь ldpcDecode(llr, cfg, 30), comm.TurboDecoder или dvbs2ldpc(1/2) — и получаешь красивый «водопад» BER, не заглядывая внутрь. А самое интересное в современных кодах именно там: не в том, как закодировать, а в том, как декодер из зашумлённого сигнала достаёт правильные биты.

Первая часть заканчивалась предложением: «если интересно разобрать итеративное декодирование LDPC/турбо в деталях или полярные коды с последовательным отменением — пишите в комментариях». Написали — так что эта статья и есть ответ на запрос из комментариев. Читать первую часть необязательно: там мы прошли эволюцию кодов в сотовой связи от GSM до 5G по BER‑кривым в MATLAB, а всё нужное я напомню по ходу. Здесь — вскрываем сами декодеры.

Эта часть открывает ящик. Разберём три декодера, на которых держится всё современное кодирование:

— belief propagation — итеративный обмен сообщениями по графу, ядро LDPC и всего 5G eMBB;

— BCJR + итеративный обмен мнениями — то, что сделало турбо‑коды возможными;

— successive cancellation — последовательное отменение в полярных кодах.

Чтобы видеть каждую строчку, MATLAB‑тулбокс не годится — он прячет алгоритм. Поэтому весь разбор идёт по коду небольшой библиотеки, которую я написал специально для этого — fec‑cpp: header‑only C++17, без единой внешней зависимости, только STL. Её можно прочитать целиком за вечер, и каждый декодер в ней — полсотни строк, которые делают ровно то, что написано в учебнике. Рядом с каждым разбором будет и MATLAB‑эквивалент — чтобы видеть контраст: одна строка тулбокса против явного алгоритма. А в конце — большое сравнение: прогоним обе реализации по одинаковым кодам и наложим их BER‑кривые на одни графики.

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

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

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

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

Есть такое устойчивое интеллектуальное заблуждение: если модель больше — значит, она лучше. Больше параметров, больше обучающих данных, больше денег в предобучении — и вот вам SOTA. Гонка за размером казалась единственной игрой в городе. Но в 2025–2026 годах что‑то сломалось в этой логике. И сломалось публично, с цифрами и бенчмарками.

Я хочу рассказать три истории, которые произошли практически одновременно и складываются в одну картину. Первая — про то, как Microsoft заткнула за пояс «самую опасную» языковую модель Anthropic с помощью ста специализированных агентов. Вторая — про MIT‑трюк, позволяющий маленькой GPT-5-mini обогнать полноразмерный GPT-5 вдвое на сложных задачах. Третья — про китайскую модель Qwen, которую сделала небольшая команда с ограниченными ресурсами, и которая сейчас работает в 200 000 продуктах по всему миру. В каждой истории маленький (или менее очевидный) игрок побеждает «большого». И каждый раз причина примерно одна и та же.

Вокруг квантовых вычислений много маркетингового шума. Если вы попытаетесь смоделировать честное 48-кубитное квантовое состояние в комплексном базисе complex128, то неизбежно упретесь в «стену памяти» в 4.5 Петабайта. Если же вы решите применить блочную декомпозицию пространства состояний для ее поочередного обсчета, то упретесь в «стену времени» длиною в несколько лет непрерывных вычислений на GPU.

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

Давайте сразу снимем маски: физически данный симулятор не удерживает 48 кубитов в единой суперпозиции. Между старшей и младшей половиной регистра полностью отсутствует квантовая запутанность (entanglement).

Вместо этого применена жесткая, но эффективная классическая блочная декомпозиция (принцип Space-Time Trade-off, то есть размен памяти на время):

Когда вы загружаете фотографии на Яндекс Диск, они не просто лежат в облаке: ML‑модели анализируют снимки, группируют их в альбомы и выбирают хайлайты для фотоленты в Яндекс Диске. Но чтобы улучшать такую систему, нужно уметь измерять качество её работы. И здесь начинается проблема: модель выбирает «красивые» и «удачные» кадры, а эстетика — вещь субъективная. Одному важны насыщенные цвета, другому — композиция, третьему — эмоции и лица в кадре. Если попросить асессоров ставить оценки от 1 до 10, мы быстро получим не объективную шкалу, а смесь личных вкусов, разной строгости и шума.

Поэтому мы подошли к задаче не как к обычной разметке, а как к исследованию. Вместо абсолютных оценок использовали шахматный подход. Каждая фотография стала «игроком», который соревнуется с другими по 16 признакам эстетики — цветам, фокусу, геометрии, эмоциональности и другим параметрам. Это позволило получить не просто рейтинг кадров, а инструмент для анализа того, какие визуальные признаки учитывают ML‑модели Диска.

Всем привет! Я Всеволод Мещеряков из службы разметки Yandex Crowd Solutions. Мы собираем и размечаем фото, видео, тексты — в общем, готовим данные, на которых учатся ML‑модели. В этой статье расскажу, как подход из мира шахмат помог нам связать субъективное восприятие фотографий с математическими оценками и сделать фотоленту Яндекс Диска ещё красивее.

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

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

Цена ошибки — повреждённый груз, развёрнутая на КПП машина, простой ворот и сорванный график отгрузки. Для исключения таких ошибок, было принято решение об инспекции фуры человеком: кто-то заглядывает в кузов и по визуальному осмотру решает, грузить фуру или разворачивать. Это медленно, субъективно и не масштабируется — а отказы по геометрии кузова составляют заметную долю разворотов.

Задача, которая стояла перед командой: автоматизировать этот осмотр. Убрать человека из точки принятия решения и выдавать вердикт «грузить / не грузить» по объективным числам, а не по взгляду грузчика.

Требования заказчика сразу задали высокую планку. Нужно мерить три габарита: ширину свободного прохода, высоту от пола до горизонтальной балки, длину — и находить посторонние предметы внутри кузова. Пороги жёсткие: ширина меньше 2,43 м — отказ, высота меньше 2,60 м — отказ, длина меньше 8 м — отказ. Зазор между «входит» и «не входит» — 2 см: паллета шириной 2,40 м идёт впритык, и выступающий на стойке крючок, съедающий эти 2 см, делает кузов непригодным. То есть мерить надо с точностью лучше сантиметра — и не у ворот, а на всей глубине кузова, до 15 м от точки установки.

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

А думал ли ты, кем станешь ты и такие как ты через 10 лет?

Может, всё-таки «Идиократия» ближе, чем кажется? Давайте погадаем немного на лавандовом рафе и прикинем, что же всё-таки произойдёт уже в ближайшем будущем.

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

Меня зовут Александра Атаман, я QA‑инженер в команде веба Яндекс Такси. В этой статье я расскажу, как мы оптимизировали процесс формирования регрессионного тестирования для ручного прогона, внедрив систему весов для тест‑кейсов. Этот подход помогает прицельно отбирать наиболее «опасные» сценарии: самые старые, забагованные или потенциально проблемные.

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

Представьте себе задачу, условия которой можно объяснить восьмилетнему ребенку ровно за тридцать секунд. А теперь представьте, что эта же самая задача десятилетиями заставляет сдаваться величайших математиков современности. Гипотеза Коллатца (или проблема «3x+1») доказывает поразительную вещь: за самыми элементарными арифметическими правилами может скрываться абсолютно непредсказуемый хаос и бесконечная сложность. Разбираемся, в чем подвох этой задачи, почему Пауль Эрдёш предлагал за её решение деньги из своего кармана и как с ней справляются современные суперкомпьютеры.

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

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

Люди тоже их создают. Для меня один из самых удивительных паттернов, которые мы придумали — это дороги.

Иногда я представляю инопланетян из далёких галактик, которые откроют Землю уже спустя много времени после нашего ухода. Леса, снова занятые природой, города, превратившиеся в развалины; однако между ними всё равно заметен слабый паттерн — сеть дорог. Мне нравится думать, что они будут чувствовать то же самое, что и я, когда смотрю на природные паттерны: «Ого, кто-то действительно это продумал».

Градостроительные симуляторы и их дороги

Должен сказать, что дороги восхищали меня с детства.

До сих пор помню, как в возрасте шести-семи лет впервые играл в SimCity 2000. Я понял не особо многое и не знал, что такое зонирование, налоги и спрос. Но дороги сразу меня восхитили.

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

Развязки. Перекрёстки с круговым движением. Эстакады. Сужения полос. Замечал каждую мелочь.

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