Алгоритмы *

Аннотация. В статье рассматривается физическая основа измерений Ekahau Sidekick и механизм применяемого RSSI‑offset с позиций теории антенн, теории шума радиоприёмных устройств, статистической теории сигналов и стандартов IEEE 802.11. Показано, что scalar RSSI‑offset является линейным сдвигом уровня и не моделирует ни реальный SNR клиентского устройства, ни структуру QAM‑созвездия, ни алгоритм rate adaptation, ни роуминговое поведение. Помимо пяти независимых физических и системных причин неточности, рассматриваются системные упрощения Ekahau, касающиеся MIMO‑усиления, многолучёвости, оценки airtime и визуализации SNR. Приведены верифицированные численные оценки погрешности для конкретных сценариев и практические рекомендации.

Привет Хабр. Надеюсь читатели поймут моё желание закрепить результат по алгоритмизации. Просто перед утренней поездкой на работу, в машине задал вопрос ассистенту - стоит ли выкатывать академическую публикацию с сравнением с каноническими алгоритмами моего. И "Алиса" сказал что да. Далее мне пришлось просто уничтожить поток хвалебных од от Gemini в адрес моего алгоритма, взяв от него самое точное и ценное зерно различий (быть точнее - я навязал ему его, он его даже не упоминал, впрочем как и алгоритмы сами) - остальные что мне он представлял мне представлялись генеративной ересью: часть из проблем испытываемых кодом канонической школы, в принципе, криво - но была решаема, и поэтому я остерёгся публиковать всё им предлагаемое- уж чересчур он мне льстил и ругал каноны. Здесь нет схем, но я беру вектор текста не на соцсети и веб, а на соцсети и веб с ИИ (на своих алгоритмах), каждое из этих трёх, само по себе, в наше время - ни о чём. Формат текстовый: 1) сравнение с бинарным деревом Дональда Кнута (каноны алгоритмизации), 2) переход к LLM, 3) эпилог - закрытие алгоритмизацией небольшого социального вопроса, заданного приверженцами старых канонов. Да - это всё написано с использованием текста сгенерированного ИИ, но если бы читатель читал всё что он генерировал - он бы просто подумал, что ИИ бесполезен и опасен.

При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение.

После серии экспериментов и улучшений пришло понимание, что промышленный ИИ-агент — это не столько про LLM, сколько про качество извлечения информации и гибкую оркестрацию компонентов ИИ-агента. Что в итоге полностью поменяло архитектуру моей системы.

В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.

Привет, Хабр! Меня зовут Алексей Васильев, я тимлид команды «Рекомендательные системы и персонализация» Sber AI Lab — Центра практического искусственного интеллекта Сбера. В нашей команде мы занимаемся исследованиями в области рекомендаций на последовательностях (sequential recommendations). Например, прослушивания музыки или просмотры карточек товаров можно представить как последовательность взаимодействий пользователя. А для моделирования последовательностей, как мы знаем, отлично подходят трансформеры: популярные варианты в рекомендациях — SASRec и BERT4Rec. Эти модели прекрасно справляются с задачей рекомендаций на основе взаимодействий, но они ничего не знают о самих товарах.

Допустим, пользователь покупает безлактозный йогурт и растительный сыр. У нас сразу появляется гипотеза: возможно, пользователь не переносит лактозу. Однако для sequential‑модели это не очевидный факт, а статистический паттерн, который нужно выучить из взаимодействий. Если данных мало, товары редкие или связи между ними плохо представлены в истории, то такой смысл легко потерять.

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

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

Если совсем коротко напомнить, где мы остановились во второй части, то картинка такая. Гибридная архитектура из трёх слоёв: ECS-миры снизу как операционный движок для большого количества однотипных сущностей, акторы-менеджеры посередине как тактический уровень, и более тяжёлые акторы или сервисы наверху как стратегический мозг. Сбоку реактивная среда, которая подбрасывает события. Под всем этим слой данных на DuckDB. Технологически: Bevy ECS на Rust для движка, лёгкая акторная абстракция поверх, egui для дев-интерфейса, WASM для демонстраций в браузере, Godot 4 опционально как 3D-витрина. Этот расклад мне показался самым интересным, и в этой части я попытаюсь показать, к чему он прикладывается на практике.

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

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

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

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

Здравствуй, Хабр! Разработка ингибиторов мутантного онкобелка KRAS ( особенно формы G12D)- одна из главных задач современной онкофармакологии. Используя наш проприетарный матаппарат мы рассчитали несколько секвенсов под целевой карман мишени. Мы оперировали секвенсами от 7 до 21 остатка на мишенях длиной от 102 до 188 остатков, полученные при докинге результаты ipTM в AlfaFold Server варьировались от 0.58 до 0.92.

По умолчанию идея рекомендательных алгоритмов не вызывает у меня никакого энтузиазма — в соцсетях я всегда переключаюсь с алгоритимического фида на хронологический (зря я что ли на всех, кого фолловлю, подписывался?), в киносервисах меня не интересует теле-кино-слоп под вывеской «вам может понравиться» (может понравиться, а может и не понравиться — как с вероятностью встретить динозавра на улице). С музыкой, однако, ситуация иная: с тех пор, когда я впервые прочитал в 2018 году про статистику, что люди, в среднем, после 33 лет перестают слушать новую музыку — мысль об этом прочно засела в моей голове (мне было как раз 30). Почему-то идея окостенения моих музыкальных вкусов мне совершенно не понравилась. И, если я пришёл в Яндекс Музыку в 2022 из-за санкций, то остался — из-за рекомендаций: если про своё избранное в Youtube Music я могу практически про каждый трек сказать, когда и как я его услышал и добавил (в чём, конечно, тоже есть свой кайф), то в Яндекс Музыке за 4 года соотношение в избранном треков, которые я услышал где-то и добавил сам, и треков, услышанных и сохранённых из рекомендаций Яндекс Музыки сейчас практически сравнялось. Т.е. половина моего избранного в Яндекс Музыке — это заслуга «старой» Моей волны, у которой в 2026 появился новый, более мощный рекомендательный алгоритм.

Срочно переписывайте свои устаревшие bloom фильтры на мой богоподобный lz77-фильтр. Совершенно бесплатно! Спасибо великому нанабанана за обложку!

Как я улучшил универсальный код Элиаса 1975 года, заменив длину на popcount — и получил 36% экономии на метаданных. С бенчмарками! Картинка на обложке кринжовая, но тут вроде так принято? 😅

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

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

Мы в команде ML Research в Городских сервисах Яндекса давно поняли, что руками такие системы не масштабируются. Нужна автоматика, которая сама фиксирует нормальное поведение метрики и засекает отклонения. Звучит как задача для тяжёлого ML, однако на бенчмарках мы доказали, что простая авторегрессия обгоняет сложные модели.

Давайте вместе пройдём путь от «Почему пороги не работают?» до рабочей системы детекции аномалий в общеяндексовой системе Monium и наблюдения за 800+ городами в Яндекс Такси с бенчмарками и конкретными цифрами.

Самодельный генератор псевдослучайных чисел (ГПСЧ) стал побочным продуктом работы над любительским шифром, а шифры для меня всего лишь хобби и поле для творчества и экспериментов. Поскольку в своём шифре я делал упор на заранее непредсказуемые динамические связи, которые зависят от промежуточных состояний шифра, сама собой напросилась идея о применении этой непредсказуемости для генерации псевдослучайных чисел. Нужно было лишь оценить степень случайности полученного генератора. Как выполнялась оценка, что показали тесты NIST и сравнение с известными «эталонами» — далее в статье.

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

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

P. S. Среди прошедших тест алгоритм выберет получателей призов.

10 апреля 2019 года человечеству показали оранжевый бублик. Журналисты назвали его «первой фотографией черной дыры». Через час картинка была у всех — мемы про глаз Саурона, шутки про пончик, антропоморфизация,  заголовки «ученые сфотографировали невидимое».

Проблема в том, что это не совсем фотография.Точнее сказать, это очень странная фотография: если бы вы использовали телескоп горизонта событий (англ. EHT — далее по тексту) «как камеру» и нажали кнопку, вы бы получили черный квадрат и никакого бублика. Потому что он делает измерения, из которых алгоритм уже собирает изображение…  которого нет.

Вот про этот алгоритм и про то, как 3,5 петабайта данных летели в Бостон самолетом, и пойдет речь.

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

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

Вот, например, Milvius(DiskANN) рассчитан на вектора размерности до 32 768, но это приближенный поиск. Но как насчёт поиска точного?

В данной статье рассматривается работоспособность 1024 мерного индекса, хранилищем которого служит обычное B‑дерево (насколько вообще может быть обычным такое дерево). Используемый диск — вполне себе «железный» старый добрый WD Purple, оперативная память сознательно ограничена 8 Гб. Можно ли что‑то из этого выжать на рядовом десктопе за приемлемое время?

Друзья, знаю, что интернет переполнен воспеванием AI, что вызывает у многих людей (особенно специалистов) фрустрацию, особенно когда речь заходит о написании кода на C/C++. Я не AI-проповедник – просто активный и ответственный программист, который пользуется AI-инструментами. Недавно я предложил AI (если быть точнее, opencode + GLM-5.1) придумать алгоритм для одной из задач, над которой я работаю, и он справился очень хорошо. Это не прорывной алгоритм, на котором я разбогатею, но он интересный: составленный из известных компонентов, но всё же новый. В статье расскажу:

Как решать задачу “дана битовая строка, нужно найти все позиции в ней, что количество единиц минус количество нулей до этой позиции равно заданному числу”

Что мне придумал AI для этой задачи

Что я использую для того, чтобы AI писал что-то адекватное на C++

Если вам интересны алгоритмы и структуры данных, то описанная задача используется в контексте RMQ/LCA.

Продолжение истории. Во второй части речь пойдет про поиск пути к своему симулятору: затронем мультиагентные системы "прошлого" (MAS), акторную модель (actor model), современную игровую архитектуру ECS и Data-Oriented Design. Что взлетело, что не взлетело, и почему гибридная архитектура показалась подходящей для трёхуровневой модели управления из первой части. Все это с историческими отсылками к Хьюитту, Армстронгу и Эктону.