Модель адаптивной сложности выглядела безупречно: формулы верны, тесты зелёные. Симуляция показала, что новички получают 58% верных ответов вместо 82%. Рассказываю, как устроена модель и где был провал.
Как часто вы слышали: «Не доверяй компилятору, пиши вручную»? Похоже, эту идеологию пора сдавать в архив.
Автор специально собрал примеры, в которых «умный» код современного C++ либо проигрывает наивному, либо не даёт выигрыша, но при этом ухудшает читаемость и мешает оптимизатору. Тут и легендарный Q_rsqrt, и бит-хаки для подсчёта единичек, и вездесущие const&, и даже опасные фокусы с фильтрацией диапазонов. Всё с воспроизводимыми бенчмарками на Clang 21 и Ryzen 9. Если вы готовы пересмотреть багаж старых привычек – просим под кат.
Нейросети обсуждают так много, что за громкими обещаниями легко потерять главное: где заканчивается эффектная демонстрация и начинается рабочий инструмент.
Я, Александр, автор телеграм‑канала «Shulepov Code», поговорил с Василием Рязановым — кандидатом физико‑математических наук, руководителем команды Data Science и автором блога об искусственном интеллекте на YouTube. В этом выпуске мы разбираем, почему нейросетям уже около 80 лет, как устроены языковые модели, какие задачи ИИ решает в бизнесе и почему «заработать миллион одним промптом» всё ещё нельзя. Василий делится практическим опытом работы с нейросетями и объясняет, где заканчивается хайп и начинается реальная польза.
Мы создаем крошечную языковую модель с нуля на чистом Node.js без использования TensorFlow или PyTorch, реализуя нейроны, автоград, эмбеддинги, механизм самовнимания (self-attention), полносвязную сеть (FFN), обратное распространение ошибки и SFT, одновременно наблюдая за тем, как отдельные веса и целые матрицы изменяются в процессе обучения
Перед вами четвёртый материал (вот первый, второй и третий) из серии статей, посвящённых информационным технологиям в авиаперевозках. Наша сегодняшняя тема — DCS (Departure Control System, система контроля отправки пассажиров).
Что произошло в 05:30, когда я вошёл в аэропорт Нагпура и GDS выбыла из игры?
Написать эту статью меня сподвиг странный случай. Я опубликовал на Хабре свою статью «Асимптотика на практике: Сравнение алгоритма сортировки вставками и выбором» и через некоторое время обнаружил ее в черновиках с пометкой «Сгенерировано». Это меня, конечно, сильно удивило, я написал в поддержку, сообщив о ложном срабатывании. Там мне ответили, что им в принципе неизвестны случаи ложного срабатывания.
Вот их позиция по поводу ложных срабатываний детектора (цитата из переписки):
Сколько глаз у человека? Два.
А в сфере машинного обучения модели умеют видеть любую сразу тысячей или миллионами глаз. Мы живем в 3-х мерном пространстве(3D), и видим 2-х мерную картину мира. Модель, в свою очередь, обитает в цифровом пространстве. Она может видеть ваши 2D фото, 3D модель в Blender сразу со всех сторон и спокойно построить параллелепипед в 15D.
Мы отлично ориентируемся в двух измерениях, немного хуже в трех, а дальше - ВСЁ.
То, что вышло за пределы привычного куба, перестает быть геометрией в нашем земном понимании.
Тем не менее нам приходится анализировать результаты работы моделей, для принятия соответствующих решений. Как это делать? Для этого многомерное пространство приходится каким-то образом «свернуть» в обычную плоскость, сохранив как можно больше информации о взаимном расположении точек.
Для этой задачи разработаны специальные алгоритмы. Самыми известными из них сегодня стали PCA, t-SNE и UMAP. Несмотря на схожий результат в виде разноцветной двумерной карты, внутри они основаны на разных математических идеях. И сегодня мы узнаем на каких
В моей практике пришлось разрабатывать программную часть измерительных приборов, источников тока, испытательных установок, автономных, не связанных с компьютером. Меню как помощник и путеводитель пользователя было необходимо. Хочу поделиться опытом разработки своей библиотеки
Представьте, что любой человек, выйдя на улицу или посмотрев в окно, может стать частью распределенной системы раннего обнаружения воздушных угроз. Не как оператор или специалист, а как источник дополнительного сенсорного наблюдения.
Современный смартфон представляет собой доступную COTS‑платформу с набором встроенных датчиков: камерой, GNSS‑приемником, 6-DoF IMU, барометром и микрофонами. По отдельности эти сенсоры ограничены, однако их совместное использование в распределенной сети потенциально позволяет создавать новые подходы к обнаружению низколетящих БПЛА.
Это не задача создания «смартфонного радара», а инженерная задача на стыке краудсорсинга, Edge Computing, машинного обучения и обработки сигналов.
Как превратить множество пользовательских устройств в единую распределенную апертуру? Попробуем рассмотреть возможную архитектуру такой системы.
Описанный в предыдущих частях калькулятор уже работал. Реализация 2021 года запускалась на реальном оборудовании, обрабатывала нажатия клавиш, вычисляла результаты и отображала их. Арифметика была корректной в том смысле, что большинство результатов было точным до 12 значимых разрядов, а это больше, чем требуется обычному пользователю.
Но «большинство» это не «все», а «примерно 12» — это не 15-16 разрядов, которые может и должна обеспечивать 16-разрядная BCD-машина. Существовали пограничные случаи, в которых результаты оказывались совершенно неверными. Имелись итеративные алгоритмы с точностью приемлемой, но не такой, какой она могла быть. Кроме того, в процессе тестирования я обнаружил ошибки, при отладке которых обнаружились фундаментальные баги в коде прототипа на C++. Это привело меня в смятение, ведь для их устранения мне бы пришлось переделать заново код прототипа. В конечном итоге, так я и поступил. Старый код я оставил в репозитории (Pathfinding/Methods) и с нуля разработал совершенно новую версию (Pathfinding/Proof). Я пообещал себе, что занимаюсь этим последний раз в жизни, поэтому стремился делать всё идеально.
В итоге, версия 2025 года устранила найденные мной проблемы. Это был не патч, а почти полное переписывание арифметического движка, расширение набора команд CPU и существенное увеличение библиотеки функций. В этом посте я расскажу об изменениях и их причинах.
Каждый айтишник, который хоть раз стоял «на красном» на пустом перекрестке в три часа ночи, думал одно и то же: «Да я бы это за выходные пофиксил».
Я тоже так ненароком подумал. Потом начал разбираться, как устроено управление светофорами и выяснил кое-что интересное. Оказывается сама постановка задачи «как оптимизировать светофоры» при ближайшем рассмотрении рассыпается на глазах. Неочевидно, но это не задача оптимизации в том смысле, в котором мы привыкли. И самое обидное, что компьютер тут не главное бутылочное горлышко.
Давайте по порядку, потому что путь от «я исправлю это за выходные» до «а, вот почему до сих пор не пофиксили» это, честно, лучшая экскурсия по тому, чем реальная инженерия отличается от академической.
Чтобы дать команду умной колонке, не обязательно говорить активационное слово «Алиса»: есть быстрые команды — короткие фразы, с помощью которых можно управлять музыкой, громкостью или умным домом. Например, чтобы переключить трек, достаточно просто сказать «дальше», а чтобы убавить звук — «тише». Весь список команд можно посмотреть в настройках вашего аккаунта в приложении «Дом с Алисой».
Быстрые команды удобнее не только пользователям, но и системе: запросы через слово «Алиса» требуют обращения к модели распознавания речи ASR, которой из‑за её размеров необходимы серверные вычислительные ресурсы, а модель быстрых команд устроена гораздо компактнее. Она работает прямо на устройстве, а значит, ограничена вычислительными ресурсами самой колонки — её CPU и оперативной памятью. Из‑за этого модель нельзя сильно увеличить: ей приходится оставаться компактной, зато запрос обрабатывается быстрее.
За распознавание быстрых команд отвечает нейросеть. Её архитектура почти полностью совпадает с решением для наушников Яндекс Дропс, которое подробно описал в своей статье Григорий Афанасенко. Разница в основном в масштабе: наша модель весит всего от 0,5 до 1,5 МБ в зависимости от железа конкретного устройства.
Со временем перед нами встала задача добавить к базовым командам «лайк» и «дизлайк» для управления треками, а также команды «включи блютус» и «выключи блютус». Особенно это актуально для Станции Стрит, которую часто берут с собой на природу, где нет интернета. Но главным было гарантировать абсолютное отсутствие ухудшения на уже запущенных командах и не слишком сильно увеличивать потребление ресурсов на устройстве.
Зашёл тут на карту и вижу странную картину. На Чистых прудах висят три пина ровно друг на друге. Тыкаю, а там один и тот же «Вишнёвый сад» в Ленкоме. Совпадает всё, вплоть до времени и зала. Просто данные прилетели из трёх разных мест. Где-то площадка записана просто как Ленком, где-то полностью с именем Марка Захарова, а в третьем случае вообще пусто. Для пользователя это три разных события на карте, хотя спектакль на самом деле один.
У меня сейчас Окрест тянет афиши по шестнадцати городам из Яндекс Афиши, Afisha.ru, Timepad, KudaGo и телеграм-каналов самих площадок. Сейчас в базе 23 097 активных событий, и пересечений между источниками много. 8260 событий приходят из двух источников, 533 из трёх, десять встречаются сразу в четырёх. На карте всё это должно превращаться в одну точку, а не в гирлянду пинов.
Месяц назад закончилась тренировка DATA DOJO от Яндекса. Здесь я бы хотел рассказать про ключевые аспекты соревнования, моё решение на топ-6%, авторские идеи и, конечно, про реальный путь к победе.
Магнус Карлсен сыграл партию с точностью 88.7% на Chess.com и 71% на Lichess. Кто прав? Спойлер: единственно правильного ответа здесь, скорее всего, нет. Разбираю по шагам, как Lichess считает точность партии, от сантипешек и логистической функции до гармонического среднего и контекстно-взвешенной агрегации. В конце - Python-скрипт для воспроизведения результата.
Проблема, которую не решает обычная оптимизация
Классические методы оптимизации — градиентный спуск, генетические алгоритмы с элитизмом, CMA‑ES — заточены под одну вещь: найти один глобальный максимум функции приспособленности. Всё остальное население на пути к этому максимуму считается расходным материалом и отбрасывается.
Но во многих задачах нас интересует не единственное решение, а набор разнообразных хороших решений:
Эволюционная робототехника. Нужно не одно «оптимальное» положение ног шагающего робота, а целая библиотека походок под разные повреждения — если у робота откажет один сустав, он должен уметь быстро подобрать альтернативную походку вместо повторной оптимизации с нуля.
Процедурная генерация контента в играх. Нужны не «лучшие» уровни, а уровни, покрывающие весь спектр: лёгкие/сложные, линейные/разветвлённые.
Дизайн и инженерия. Инженеру интересно увидеть весь фронт компромиссов (вес vs прочность vs стоимость), а не одну точку.
Открытые (так называемый open‑ended) эволюционные системы, где само понятие «лучшего» плохо определено, а интересна широта поведенческого репертуара.
Это направление получило название Quality‑Diversity (QD) оптимизации: цель — не максимизировать один скаляр, а заполнить пространство возможных поведений решениями, каждое из которых максимально хорошо в своей поведенческой нише.
MAP‑Elites — один из первых и самый концептуально простой алгоритм этого семейства.
Идея алгоритма
MAP‑Elites (Multi‑dimensional Archive of Phenotypic Elites) был предложен в 2015 году.
Думаю, один из самых завораживающих и интересных феноменов, о котором я узнал именно с Хабра — это клеточные автоматы. О Джоне Конвее и его игре «Жизнь» я впервые прочитал в переводной статье уважаемого @SLY_G «Джон Хортон Конвей: Жизнь, как игра», а среди авторских материалов мне запомнились «Наша Вселенная — симуляция на основе большого клеточного автомата?», которую мне довелось прочитать, будучи в жюри конкурса «Технотекст», «Простейшие клеточные автоматы и их практическое применение» уважаемого @oshibka404 и, наконец, блестяще иллюстрированная алгоритмическая работа «Эволюционирующие клеточные автоматы» уважаемого @xcont. Эти статьи натолкнули меня на размышления о том, почему биологическая (дарвиновская) эволюция не слишком популярна в качестве источника сюжетов для компьютерных игр. Если как следует поискать, такие игры всё-таки существуют (пусть многие из них и напоминают образовательные пет-проекты), но мейнстримом они определённо не стали. Под катом попробую рассмотреть, так ли интересно играть в эволюцию и не слишком ли фаталистична и сложна эта тема в качестве развлекательной.
Каждый C#‑разработчик писал numbers.Where(x => x > 10).Select(x => x * 2) — и удивлялся, узнав, что эта строчка ничего не вычисляет. Цепочка спит, пока мы не начнём перебирать результат.
За этим стоит конкретный механизм — отложенные вычисления, а в его основе лежит обычная фича языка: yield. Разбираем, как устроены ленивые методы LINQ изнутри — от ручной реализации Where без yield до того, во что этот yield разворачивается компилятором.
А вы точно знаете, что происходит под капотом каждый раз, когда пишете .Where(...).Select(...)?
К статье приложен репозиторий с полной реализацией.
Представьте: вы пишете парсер, который обходит сотни миллионов URL. Каждую новую ссылку нужно проверить — посещали ли мы её раньше? Заводить гигабайтный хеш-набор для хранения всех адресов — расточительно и медленно.
Но существует вероятностная структура данных, которая способна ответить на вопрос «видели ли мы этот URL?», занимая при этом в десятки раз меньше памяти, чем полное множество строк. Плата за такое — мизерная возможность ложноположительного срабатывания, где алгоритм заявит что URL есть, хотя на самом деле он новый. Зато на вопрос «не видели?» она не ошибётся никогда.
Это и есть Фильтр Блума, созданный Бёртоном Блумом аж в 1970 году. Более полсотни лет этому алгоритму! В принципе, никогда не помешает освежить знания и вспомнить, как писать реально оптимизированное ПО.
Привет, Хабр! На днях мы выкатили третье поколение языковых моделей Cotype — флагманскую Cotype Pro 3 и ее облегченную версию Cotype Light 3 (к слову, лайт мы выкатили чутка раньше, но это не имеет значения). Почитать о характеристиках моделей можно вот в этом посте. Тут же мы расскажем вам о нюансах обучения — точнее о том, как мы учим наши модели выполнять многошаговые сценарии без запинок, что совершенно необходимо, так как они выступают ключевым компонентом наших корпоративных ИИ-агентов и мультиагентных систем.
