Data Science: Алгоритмы и Структуры данных

Как мы ускоряли диффузионный декодер TTS

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

Внутри TTS работает каскад из трёх компонентов: языковая модель предсказывает аудиотокены по тексту, диффузионный декодер восстанавливает мел-спектрограмму из латентов, а вокодер превращает её в звуковую волну. Долгое время самой тяжёлой была языковая модель, но после её оптимизации на первый план вышел декодер латентов — его forward pass запускается на каждом шаге семплинга диффузии, а шагов — десятки. Именно его мы и взялись ускорять.

Меня зовут Цырен-Доржо Цыбиков, я ML-инженер команды TTS в Яндексе и ментор проекта Даниила Маслова, студента бакалавриата кафедры АД ФПМИ МФТИ и ШАД. В рамках проектного курса мы запустили отдельную исследовательскую ветку по оптимизации диффузионного декодера латентов в TTS-пайплайне перевода видео.

https://habr.com/ru/companies/yandex/articles/1051334/

Алгоритмы и Структуры данных

Мы не выравниваем железо — мы выравниваем реальность: как превратить любой лазерный гравер в прецизионный фотоплоттер

Если вы хоть раз пытались сделать печатную плату сложнее «мигалки на светодиоде», вы знаете цену «геометрического ада».
ЛУТ (лазерно-утюжная технология) — это лотерея. Классический фотометод требует идеального шаблона, а профессиональный фотоплоттер стоит как подержанный автомобиль. Казалось бы, решение на поверхности: взять доступный китайский лазерный гравер за $100 и вперёд. Но тут начинается новый «ад»: оси изначально кривые, реальный шаг моторов живёт своей жизнью, а заготовка почти всегда лежит на столе с перекосом в пару градусов. Малейшее отклонение — и прецизионный Gerber превращается в бесполезный кусок текстолита.
Я решил эту проблему иначе. Зачем часами юстировать механику, если можно переложить всё на математику и нейросети?
Представляю LPP-Laser — флагманское направление открытой модульной платформы LPP (Linear Path Platform). Система не требует от станка совершенства. Она просто «натягивает» ваш проект на реальность.

https://habr.com/ru/articles/1051624/

Алгоритмы и Структуры данных

HyperLogLog: как найти уникальные значения в терабайте данных, не храня их

Представим задачу: хайлоад-сервис гонит поток данных — логи, IP-адреса, ID пользователей, миллиарды записей в сутки. Ваша задача — посчитать количество уникальных посетителей за неделю.

Первым решением может показаться завести HashSet и кидать туда ключи, а в конце посмотреть размер. Решение неплохое, но когда речь заходит о миллиардах записей — память будет слабым местом. Один IP-адрес (4 байта) как ключ в HashSet потянет за собой накладные расходы на ноды, указатели и хеши. На практике один элемент сжирает не меньше 50–100 байт. Поток в миллиард уникальных записей потребует под сотню гигабайт оперативной памяти. Это дорого, а если инстансов десять — то просто нереально.

Но существует алгоритм, который способен решить эту задачу примерно в 1.5 килобайта памяти с погрешностью около 2%? Без хранения самих данных и гигантских кластеров. Достаточно одного прохода по потоку и пары битовых трюков — именно так и работает HyperLogLog, алгоритм родом из математической статистики, который перевернул подход к подсчёту уникальности в Big Data.

https://habr.com/ru/companies/timeweb/articles/1046345/

Алгоритмы и Структуры данных

Ненормальное марковское программирование: бег по правилам

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

https://habr.com/ru/articles/1049258/

Алгоритмы и Структуры данных

Конволюция и деконволюция — работаем с сигналами под нефтяным соусом

Свёртка и восстановление сигнала (далее — конволюция и деконволюция) в инженерии вещи известные и давно не новые. Здесь, на Хабре, есть замечательные статьи, которые отлично объясняют, что это и как используется, на примере компьютерных технологий. Например, всеми любимые свёрточные нейронные сети (CNN) используют как раз конволюцию как механизм в своей основе (Сверточная нейронная сеть, часть 1: структура, топология, функции активации и обучающее множество). Или в другой работе используют деконволюцию для восстановления изображения (Восстановление расфокусированных и смазанных изображений) .
Тема этой статьи та же — работа с сигналами, но здесь я хочу разобрать применение данного подхода в контексте конкретной инженерии: нефтегазового дела, а точнее — работы с гидродинамикой нефтяного пласта. Казалось бы, широкому читателю это вещь бесполезная, и тем не менее мне кажется, что такой материал может быть полезен по нескольким причинам:

https://habr.com/ru/articles/1049244/

Алгоритмы и Структуры данных

Как я нашел новую панграмму (разнобуквицу)

Ну само собой получилось, что мне захотелось составить что‑то из всех букв. Оказалось, что классика вроде «Съешь ещё этих мягких французских булок» не подходит — в моём наборе каждая буква была только один раз. А те панграммы, где буквы не повторяются (можно найти, например, у Лебедева в «Ководстве») — «Эй, жлоб! Где туз? Прячь юных съёмщиц в шкаф.» или «— Любя, съешь щипцы, — вздохнёт мэр, — кайф жгуч» — они, скажем так, на любителя. Слишком много восклицаний, междометий и прямой речи. Хотелось чего-то более пристойное и связное.
И я тут вспомнил видео Мэтта Паркера про оптимизацию его кода. Действительно, можно попробовать найти панграмму с помощью bitwise логики — тогда перебор комбинаций будет быстрым. Допустим, у нас есть слово «кайф». Буква «к» — это 11-й бит, «а» — 0-й, «й» — 10-й, «ф» — 21-й. В числе биты этих разрядов будут выставлены в единицу. Слово «жгуч» — своё число, и так для каждого слова из словаря. При этом анаграммы будут друг другу соответствовать: «адрес» и «среда» будут с одним числом, что приемлемо, для поставленной цели эти слова взаимозаменяемы.

https://habr.com/ru/articles/1049056/

Алгоритмы и Структуры данных

Сказ о том, как нейросеть занялась reward hacking прямо у меня на кухне

Я хотел просто пожарить кесадилью. В холодильнике лежали зеленые оливки (солено-кислые), сулугуни и фарш, а на полке — консервированная кукуруза. И вот стою я над сковородкой и думаю: а оливки с кукурузой вообще сочетаются? А сулугуни не пересолит блюдо вместе с оливками? Сколько чего вообще класть?
В любой другой ситуации я бы загуглил рецепт. Но не тут-то было, я же великий комбинатор оптимизатор, и у меня в голове сразу всплыло: «это же задача оптимизации». Тем же вечером у меня был ноутбук с обученной нейросетью вместо ужина. Рассказываю, как дошел до жизни такой, и как из этого внезапно получился реально вкусный рецепт.

https://habr.com/ru/companies/selectel/articles/1048264/

Алгоритмы и Структуры данных

Почему мы до сих пор неправильно пишем физические движки и 3D-графику

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.
Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.
И самое интересное заключается в том, что так было не обязательно.

https://habr.com/ru/companies/timeweb/articles/1036176/

Алгоритмы и Структуры данных

Сказ о том, как нейросеть занялась reward hacking прямо у меня на кухне

Я хотел просто пожарить кесадилью. В холодильнике лежали зеленые оливки (солено-кислые), сулугуни и фарш, а на полке — консервированная кукуруза. И вот стою я над сковородкой и думаю: а оливки с кукурузой вообще сочетаются? А сулугуни не пересолит блюдо вместе с оливками? Сколько чего вообще класть?
В любой другой ситуации я бы загуглил рецепт. Но не тут-то было, я же великий комбинатор оптимизатор, и у меня в голове сразу всплыло: «это же задача оптимизации». Тем же вечером у меня был ноутбук с обученной нейросетью вместо ужина. Рассказываю, как дошел до жизни такой, и как из этого внезапно получился реально вкусный рецепт.

https://habr.com/ru/companies/selectel/articles/1048264/

Алгоритмы и Структуры данных

Почему мы до сих пор неправильно пишем физические движки и 3D-графику

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

https://habr.com/ru/companies/timeweb/articles/1036176/

Алгоритмы и Структуры данных

📣Стол компьютерный с подъемным механизмом

Цена: ~15000₽
Рейтинг: 4.8😀
Отзывов: 1.431 💬

🖱 Заказать

Компьютерный стол с электрической регулировкой высоты позволит работать сидя или стоя одним нажатием кнопки. Просторная столешница 150×78 см легко вместит несколько мониторов, ноутбук и всю периферию. Отличный выбор для программистов и удаленщиков, которые проводят за компьютером весь день и хотят сделать рабочее место более комфортным и эргономичным.

#стол #регулировка

Находки Программиста

🔥 Нашли сервис, который позволяет за пару минут собрать под себя полноценный курс по любой теме — Gurufy.

🔅 Это не просто чат как ChatGPT, а целая экосистема, которая позволяет разобраться в вопросах чуть сложнее, чем «какая сегодня погода».

🔅 По запросу создаётся план курса, а в каждой статье — иллюстрации, интерактивные виджеты, отдельный ИИ-ассистент и задания для закрепления материала.

🔥 Попробовать можно бесплатно.

Ссылка на сервис → https://gurufy.ru

Как мы считаем недельное меню в Pikni Food: пачки, остатки и solver вместо списка рецептов

Когда мы только начали собирать Pikni Food, идея выглядела довольно простой: пользователь отвечает на несколько вопросов, мы подбираем блюда, считаем калории и показываем список покупок.

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

Например, меню требует 620 г гречки, а в магазине она продаётся пачкой 900 г. Рецепту нужно 180 г творога, а упаковка может быть 400 г. Огурец в салате можно посчитать как 70 г, но купить его всё равно придётся штукой или лотком. Если считать только съеденные граммы, неделя выглядит аккуратно и недорого, ну а если считать чек, то… получается совсем другая история.

Так мы пришли к выводу, что мы делаем не просто «генератор рецептов», а планировщик продуктовой корзины. А в нём важно не только КБЖУ, но и многое другое, например: упаковки, остатки, сроки годности, цены магазинов, техника на кухне, время готовки и тд.

Ниже расскажу как это всё устроено, какие алгоритмы пробовали, с какими проблемами столкнулись и как мы их решали.

https://habr.com/ru/articles/1048656/

Алгоритмы и Структуры данных

МТС приглашает на четвертый сезон True Tech Champ 2026 — всероссийского чемпионата по программированию с призовым фондом 10 250 000 рублей

Соревнование проходит в двух треках.

Трек 1. Алгоритмический [призовой фонд 2 750 000 ₽]
Проверь, насколько быстро и точно ты решаешь классические и нестандартные алгоритмические задачи.

Трек 2. Программирование роботов [призовой фонд 7 500 000 ₽]
Собери команду и запрограммируй робособаку и робота-манипулятора для доставки груза через полосу препятствий.

Зарегистрируйся на алгоритмический трек до 13 сентября и на программирование роботов до 27 сентября и включайся в гонку за финал True Tech Champ 2026.

Бритва Оккама против сложности: когда машинное обучение побеждает, а где сбоит в инвестициях

Принцип «бритвы Оккама» — краеугольный камень социальных наук. Для экономистов-финансистов он почти аксиома. Принцип назван в честь Уильяма Оккама, монаха XIV века. Согласно ему, самое простое объяснение любого явления — лучшее.

Как пишет The Economist, в настоящее время финансовые аналитики боятся «переобучения» — создания модели, которая благодаря своей сложности хорошо соответствует существующим данным, но плохо предсказывает будущее. Однако тут проявляется принцип Оккама. По новым данным, когда дело касается больших моделей машинного обучения, экономия переоценивается, а сложность может стать определяющим фактором. Если это так, методы современного инвестирования значительно изменятся.

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

https://habr.com/ru/companies/finam_broker/articles/1046475/

Алгоритмы и Структуры данных

Ненормальное марковское программирование: КТ-строки и синглетоны

(Сокращения: НАМ - нормальные алгорифмы Маркова, КТ - компайл-тайм, РТ - рантайм)
Продолжение. Первая часть - программирование на НАМ. Вторая - обзор неприятностей, концепты.

https://habr.com/ru/articles/1048176/

Алгоритмы и Структуры данных

MCP vs CLI + Skill: что выгоднее для ИИ‑агента при работе с внутренними API

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

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

https://habr.com/ru/companies/yandex/articles/1046191/

Алгоритмы и Структуры данных

Ненормальное марковское программирование: неприятности

(Продолжение. См. первую часть, где мы научились кодить на марковских алгорифмах "на бумажке").
Сокращения:
НАМ - нормальные алгорифмы Маркова
КТ - компайл-тайм
РТ - рантайм

https://habr.com/ru/articles/1047886/

Алгоритмы и Структуры данных

OSDEV: vsnprintf полная реализация без поддержки чисел с плавающей точкой

Думаю о разработке своей vsnprintf функции думал каждый кто увлекается osdev и есть много кода написанного на эту тему. Так же есть масса гайдов и туториалов, но не один из известных мне не заканчивается vsnprintf функцией проходящей тесты от gcc. Перед вами первый из них!
В первую очередь нужно сказать что ориентироваться будем на этот документ, но реализации расширений gnu в духе $, m$ не будет за исключением всего двух: вывод строки (null) вместо nullptr для спецификатора %s и строки (nil) вместо nullptr для спецификатора %p. Я уже не помню в какой версии glibc я видел (Nil) но мне это очень понравилось. Так же форматирование %p будет реализовано как в glibc.

https://habr.com/ru/articles/1046445/

Алгоритмы и Структуры данных