https://share.google/aimode/K0sZdbJVBQ0RLMLeV https://share.google/aimode/QsJiCJ5HfUCgrEi3o динамическое сожаление (Dynamic Regret) 🏃‍♂️ Что такое Dynamic Regret и почему ИИ всегда «сожалеет» на ходу? В теории онлайн-обучения (Online Machine Learning) есть метрика, которая идеально описывает жизнь в хаосе — Dynamic Regret (Динамическое сожаление). Представьте, что вы бежите марафон, но правила игры меняются каждую минуту. Лидер гонки постоянно сворачивает в переулки, меняет темп и траекторию. Вы не знаете маршрута заранее и можете только подстраиваться. Dynamic Regret — это суммарное расстояние, на которое вы отстали от лидера за всю дистанцию из-за того, что реагировали с опозданием. В чем разница для ИИ? ❌ Static Regret (Статичное сожаление) — это если бы мы сравнивали ИИ с одной лучшей фиксированной стратегией на все времена. Например, купить акции одной компании и держать их 10 лет. Мир изменился, а мы все еще стоим на своем. ⚡️ Dynamic Regret (Динамическое сожаление) — это сравнение ИИ с идеальным выбором на каждом конкретном шаге задним числом. Это как если бы мы пытались угадать идеальный момент для покупки и продажи абсолютно разных акций каждый день. Зачем это нужно? В реальном мире (будь то алгоритмы беспилотников, финтех или динамическое ценообразование) концепт-дрифт неизбежен. Окружающая среда постоянно мутирует. Задача инженеров — спроектировать ИИ так, чтобы его динамическое «сожаление» росло как можно медленнее, а сам алгоритм успевал за постоянно меняющимся идеалом. #ИИ #MachineLearning #DataScience #Алгоритмы

Двести солдат и одни ворота: почему NPC топчутся на месте Двести солдат получают команду пройти через ворота и оказаться во дворе. A* исправно строит маршруты, персонажи отправляются к цели, но возле прохода начинается какая-то ерунда. Одни агенты дрожат в пятнадцати метрах от ворот, другие пятятся назад, третьи пытаются протиснуться между соседями. Во двор тем временем попадает от силы десяток. Открываем профайлер — A* тратит кучу времени на поиск маршрутов. Кажется, нужно оптимизировать алгоритм, подкрутить радиусы агентов или перестроить NavMesh. Только солдатики от этого вовсе не обязаны перестать тупить. Причём одинаковые с виду заторы могут возникать по совершенно разным причинам. На тестовой сцене можно менять ширину ворот и количество агентов, наблюдая, как ведёт себя толпа.

Kevin заканчивает своё эссе так:

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

В понедельник 5-го октября на архив выложили препринт «Truly Subquadratic 3SUM and Truly Subcubic APSP via Triangles in Sparse Lopsided Graphs». В нём опровергают две гипотезы о сложности алгоритмов решения двух задач. Одна из них формулируется очень просто, и вы наверняка на неё натыкались, если готовились к собеседованиям на LeetCode — 3 sum. Вам дан массив из n чисел (включая отрицательные), и нужно определить, есть ли в нём 3 таких, что их сумма равна нулю. В теоретической информатике долгое время существовало предположение, что для этой задачи невозможно найти алгоритм, который работал бы существенно быстрее квадратичного от размера массива. 3 sum — одна из центральных гипотез раздела fine-grained complexity. Многие другие задачи можно свести к 3 sum. Поэтому на предположении строилось множество других результатов: исследователи показывали, что если 3 sum невозможно существенно ускорить, то нельзя существенно ускорить и целый ряд других задач. И вот оказалось, что существует общий алгоритм, который вместо n^2 работает за n^(1.9992). Само по себе ускорение не особо интересно (в практике оно может работать даже медленнее, так как из нотации выкидывают константы) — и ключевым является именно опровержение гипотезы, которыми многими считалось «логичной» и «красивой». Один из двух авторов — Virginia Vassilevska Williams, одно из ведущих имён в области fine-grained complexity. И казалось бы можно порадоваться за прорыв, но если открыть конец статьи, то увидим: Как результат был первоначально получен и передан авторам: сотрудник Anthropic использовал внутреннюю исследовательскую модель для изучения открытых проблем в теории криптографии. <...> В сентябре 2026 года Anthropic передала алгоритм авторам на условиях соглашения о конфиденциальности, предложила вознаграждение и предоставила доступ к публичной версии Claude. <...> После того как статья была полностью написана, Anthropic использовала внутреннюю исследовательскую модель для формальной проверки основных результатов статьи с помощью Lean. <...> Авторы работали над этой публикацией в личное время, вне рамок своих служебных обязанностей в Колумбийском университете и MIT. Так что получился немного странный для науки подход «найти и проспонсировать подставное лицо, не участвовавшее в составлении доказательства, и указать его в качестве автора, и при этом указать, что работает он без своей основной аффилиации». Я против такого подхода ничего не имею, но многие в научном сообществе видят здесь несоответствие... духу? морали? науки и тому, как вещи «принято» делать.

А давайте немного поговорим про карты. Вот пара кейсов из жизни разработчиков карт. Пишет Kanat Zhussipov (Senior Software Engineer, Python):

🛰 Почему ваш навигатор не тормозит? Разбираем Contraction Hierarchies (CH) Представьте: вы строите маршрут из Нью-Йорка в Бостон. Между ними ~350 километров дорог, тысячи развязок, заправок и десятки тысяч жилых тупиков в штате Коннектикут. Если искать путь обычным алгоритмом Дейкстры, он будет «заглядывать» в каждый двор по пути, проверяя: «А вдруг через эту парковку в Стэмфорде доехать до Бостона быстрее?». Это занимает секунды. Google Maps или OSM выдают результат за миллисекунды. Секрет — в Contraction Hierarchies (CH). 🏙 Пример: NY ➔ Boston Вместо того чтобы работать с «плоской» картой, CH превращает её в строгую иерархию, где каждому перекрестку присвоен ранг важности. 1. Выезд из Нью-Йорка (Climbing the Ladder) Вы стартуете из Таймс-сквер. Алгоритм запускает поиск, но с железным правилом: идти только к узлам с более высоким рангом. С узкого переулка он сразу перескакивает на авеню, оттуда — на шоссе I-95. Как только вы оказались на I-95, алгоритм «забывает» про существование съездов в маленькие городки. Для него их ранг ниже, а значит, они «невидимы». 2. Магия Shortcuts (Прыжки через штаты) На этапе подготовки (Preprocessing) алгоритм уже «схлопнул» скучные участки дорог. Вместо сотен мелких узлов на трассе между городами, у нас есть один Shortcut (ярлык) с весом, равным общему времени в пути. Поиск из Нью-Йорка просто «летит» по этим ярлыкам, не тратя ресурсы на обсчет каждого километра. 3. Встреча в Бостоне (The V-Shape Search) Одновременно запускается поиск из Бостона навстречу. Он тоже идет только «вверх» по иерархии: От вашего отеля в Бэк-Бэй ➔ на городскую магистраль ➔ на то же шоссе I-95. Два поиска встречаются в «самой высокой» точке (на главной магистрали). Область поиска выглядит не как огромный круг, а как два узких луча, направленных друг на друга. 🚀 Почему это System Design Masterpiece? Скорость: Поиск сокращается с миллионов операций до нескольких сотен. Точность: В отличие от эвристик (типа A*), CH гарантирует математически кратчайший путь. Space-Time Tradeoff: Мы тратим немного памяти на хранение ярлыков (Shortcuts), чтобы получить колоссальный выигрыш в скорости ответа (Latency). Итог: Когда вы едете в Бостон, алгоритм видит мир как сеть скоростных хайвеев. А когда вы ищете дорогу в соседний двор — он работает на «нижних этажах» той же самой иерархии.

А вот еще был случай. Пишет Ivan Petrakov (Senior Staff Software Engineer, Ruby on Rails): Н

аш поиск по карте занимал 3 секунды на запрос. Пользователи зумили и двигали карту. Каждое движение запускало новый запрос к базе. 3 секунды каждый раз. Карта казалась сломанной. Мы снизили до 300мс. Улучшение на 900%. Вот как. Старый подход: мы хранили широту и долготу в двух отдельных колонках. Каждый поиск использовал ST_DWithin или bounding box запрос с PostGIS. Работало нормально на маленьких данных. С 2 миллионами точек стало слишком медленно. Решение: quadkeys. Quadkey - это одна строка, которая кодирует местоположение на сетке тайлов карты. Думайте о нем как о почтовом индексе, но для тайлов карты. Чем длиннее строка, тем точнее локация. Зум уровень 1: мир - это 4 тайла (quadkeys: 0, 1, 2, 3) Зум уровень 15: каждый тайл - примерно квартал Вот что мы изменили: 1. Добавили колонку quadkey к каждой геолоцированной записи. Мы предрассчитали quadkeys для каждого поддерживаемого зум-уровня (с 10 по 18). 2. Заменили PostGIS bounding box запросы на простой поиск по префиксу строки. Вместо: WHERE ST_DWithin(point, user_location, radius) Теперь: WHERE quadkey LIKE '0213012%' Поиск по префиксу строки на индексированной колонке работает очень быстро. 3. Добавили составные индексы: (zoom_level, quadkey). 4. Предагрегировали количество точек на quadkey для кластерных представлений. При отдалении показываем кластеры с количеством. Не нужно загружать отдельные точки. Результат: 3 секунды стали 300мс. Карта работает мгновенно. Пользователи могут зумить и двигать карту без ожидания.

Вчера общался со старшим директором по Data Science в одной компании в Штатах. Оказалось, что именно она была автором той самой модели в Target, которая в своё время отправила купоны со скидками на детские товары в семью, где отец ещё не знал, что его дочь беременна. Той самой, после которой он в ярости прибежал в ближайший магазин Target разбираться: С какого перепуга вы присылаете моей дочери такое (My daughter got this in the mail!” he said.“She’s still in high school, and you’re sending her coupons for baby clothes and cribs? Are you trying to encourage her to get pregnant?)? А спустя некоторое время вернулся и сказал: Да, она беременна. У меня к ней был один главный вопрос. В сообществе ведь ходили две версии этой байки. По одной, девушка сама ещё не знала о беременности, а модель уже всё поняла. По другой — девушка знала и уже покупала какие-то товары, по которым модель определила беременность и начала предлагать скидки на соответствующие покупки. Не знал только отец. Ну и тайна раскрылась: по её словам, сама девушка уже знала, что беременна. Конечно, забавно в какой-то момент карьеры встречать людей, о которых ты никогда не слышал, но прекрасно знаешь о том, что они создали. А еще она пишет детские книжки

🖥 Задачка дня: «Я встану — вы ляжете» Дима решил складывать бесконечный ряд чисел до тех пор, пока не устанет. На вход программе подаются целые значения. Концом ввода служит слово Wasted — это значит, что Дима устал. Гарантируется, что кроме чисел и финального слова Wasted, никаких других слов во вводе не будет. Нужно обработать все числа до слова Wasted. Присылайте свои решения в комментарии — позже опубликуем разбор 👀 В прошлый раз мы решали задачу «Пары», предлагаем прочитать её разбор: Идея решения простая: сумма двух чисел нечётна только тогда, когда одно число чётное, а второе нечётное. Значит, весь набор можно разбить на такие пары только в одном случае: если количество чётных и нечётных чисел совпадает.

#include <bits/stdc++.h>

using namespace std;

int main() {
  int n;
  cin >> n;

  int even = 0, odd = 0;

  for (int i = 0; i < 2 * n; ++i) {
    int x;
    cin >> x;

    odd += x % 2;
    even += (x + 1) % 2;
  }

  if (even == odd) {
    cout << "Yes\n";
  } else {
    cout << "No\n";
  }
}

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

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

Воронка 1 — ваш отклик. Вы откликнулись → алгоритм ранжирует вас среди всех откликнувшихся → рекрутер видит сначала лучших. Воронка 2 — поиск по базе. Рекрутер сам вбивает запрос → вы либо попадаете в выдачу, либо нет.В обеих рулит один ML-алгоритм hh — он оценивает 700+ параметров резюме. Сначала вас режут жёсткие фильтры, потом ранжируют. Разбираем оба этапа.

Этап 1. Кто отсеивается до рекрутера

→ Зарплата. Указали выше вилки → вылетели на отсечке. Если рынок платит меньше ваших хотелок — либо снижайте, либо убирайте цифру вовсе. → Регион и формат. Только удалёнка/в офис не готов режет 40–50% вакансий — это правда. Ищете активно — ставьте максимально широкую готовность. → Возраст и пол. В тексте вакансии это писать запрещено законом (ст. 3 и 64 ТК РФ). Но в поиске по базе резюме такие фильтры у рекрутера есть. Повлиять вы тут не можете. Просто знайте, что это система. → Стоп-слова. Рекрутер может задать слова-исключения. Попали в ваш профиль — вы выпали. → Название резюме ≠ название вакансии. Одно из ключевых полей соответствия. Специалист и менеджер по продажам — для алгоритма два разных человека.

Этап 2. Ранжирование и что поднимает вас в топ

→ Навыки. hh показывает рекрутеру «Подходит по навыкам на X%». Зайдите в 10–15 целевых вакансий, выпишите оттуда навыки и проставьте их у себя (до 30 штук). Процент соответствия растёт, резюме чаще рекомендуется рекрутерам. → Свежесть. Резюме, обновлённое за последние 1–3 дня, идёт выше. Заходите и обновляйте каждый день — отредактировали и сохранили, дата освежилась. Бесплатно и работает лучше всего. → Полнота резюме. Цельтесь в 100%, минимум 75–80%. Базовый набор полей даёт всего ~51%. → Подтверждённые навыки. Пройдите тесты hh (английский, Excel — есть почти под любую профессию). Подтверждённый навык поднимает резюме выше. → Активность. Статус «Активно ищу работу», регулярные заходы, просмотр вакансий — всё это алгоритм учитывает.

Алгоритм под каждую вакансию (а не одно резюме на всё) 1. Делаете отдельные резюме под разные роли. 2. Название резюме = точное название целевой вакансии. 3. Ключевые слова из вакансии вставляете не только в навыки, но и в опыт и «обо мне» — показываете, как именно применяли. 4. Сопроводительное — точечное под вакансию, а не один шаблон на 100 компаний. 5. Откликаетесь прицельно. Релевантность важнее объёма, потому что алгоритм учится на реакциях рекрутеров. Поток нерелевантных откликов размывает вашу выдачу и все предыдущие усилия бессмысленными становятся. Чего точно не делать : → Не засовывать белый текст с ключевиками под цвет фона. Это работало пару лет на международном рынке, особенно на рынке США. Сейчас hh понимает синонимы и смысл, а не тупо ищет слова — приём бесполезен и палится. → Не держать одно универсальное резюме на 50% заполнения. → Не спамить откликами на всё подряд.

Вместо вывода: на hh вы фильтры не обходите — вы под них настраиваетесь. Совпадение по навыкам + свежесть + полнота + точное название = вы в топе ещё до того, как вас увидел живой человек.

Лайки и шеры — лучшая ваша благодарность за контент ❤️ #поискработы #резюме

Про кажущуюся тщетность усилий Показываю сыну: Вань, смотри, у меня в Инстаграм самый залетевший рилс - как птички бегают туда обратно от волны. Я потратила на него 5 минут. Но он за сутки собрал больше просмотров, чем за год собрали те рилсы, на которые я тратила часы. Там были супер познавательные видео про Азоры, про термы на берегу океана, про город в вулкане. Но нет. Всех победили птички, играющиеся с волнами. Ванька говорит: у меня тоже самое. Вот ролики, которые я монтировал в DaVinchi по три дня. И вот - тот, что склеил за полчаса в телефоне в электричке, пока ехал на барабаны. Он всех обошел по просмотрам и подпискам с него. Напрашивается вывод, что не надо стараться. Что достаточно ловить смешные моменты или просто что-то выкладывать регулярно и ждать, что это залетит. Многие так и делают. Многие для этого идут за помощью к ИИ, потому что самому с такой частотой генерировать контент - некогда. Но залетает же? Трудно не поддаться этому соблазну. Трудно не расстраиваться, когда ты сильно вложился и не получил отклика. Но. Если удержаться - то ты останешься тем, у кого можно найти смыслы и качество. И даже, если этими смыслами ты сможешь поделиться с десятком человек, а не с тысячами - это, кажется, ценнее, чем просмотры, собранные на нейрослоп или на то, что создано на бегу. Хотя птички бегали прикольно)) P.S. В финале ролика видно, что бегает еще и собакаПалыч, которому вчера стукнуло 7 лет. Любовь на удаленке | Оля Сохнева #дневник_наудаленке

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