🤷‍♂️🤷‍♂️🤷‍♂️ А правильно ли мы тестируем креативы в Мете? Пост - не гайд, а размышление. Недавно заметил, что отдельные креативы в Мете почти не получают показов за всё время открута. Где-то их 20, где-то вообще 1 за всё время. Помню, что Андромеда умная, сама решит и всё потестит. Но ведь никакого теста нельзя сделать на 20 показах? Тем более на одном. А креатив же мы уже сделали, потратили на это время и какой-то бюджет. Полез освежать знания в матчасти 1️⃣ Мета тестирует не креатив, а концепцию Важно не количество креативов, а их разнообразие. Это я давно помнил, но как-то без конкретики. И вот буквально 19-го октября Мета расписала у себя в инженерном блоге, как теперь видит объявления. Это не разбор Андромеды, это более низкая система. Там немного сложно, но в целом понять можно. Почитать тут: https://engineering.fb.com/2026/10/19/ml-applications/genrecs-tokenization-transforming-ads-recommendation-at-meta-with-stable-model-vocabulary/ Отдельного ID на каждый креатив больше нет. Модель читает текст и картинку и раскладывает объявление на токены. У похожих креативов токены общие. То есть новый креос, похожий на старый, для Меты не новый. Она ещё до первого показа примерно знает, чего от него ждать Закинул 3 похожих креатива - протестировал одну концепцию. Какой-то из них может получить 20 показов и больше не получить. И это в целом окей. Мета просто не видит смысла крутить то, что уже знает Но беда в том, что мы сейчас массово так тестируем 2️⃣ Одна кампания на всё - так себе тест У вас тоже в кабинетах структура: 1 кампания - несколько адсетов - новые креативы загружаем прямо в прод? Я точно знаю, что сейчас так делают многие. Включая ребят с миллионами долларов спенда в месяц и листингом их конторы на бирже. Алоха, кто себя узнал 👋 И эта схема вполне работает. Но оптимально ли это для больших аккаунтов? Будто бы, когда у тебя малый бизнес, схема идеальная. Ты тратишь деньги в одной кампании и не делаешь себе мозги. Загрузил десяток объявлений и на полгода забыл про это. Для мелкого бизнеса, где фаундер отвечает примерно за всё, схема близка к идеальной. Но мы-то тут креативы в кабинет десятками и сотнями уже отгружаем? У нас же подрядчики, концепции, пайплайны и вот это вот всё? Для крупных аккаунтов: - Добавить объявление это существенная правка. А значит адсет уходит в обучение. - Слишком много объявлений с недостаточным количеством показов - одна из причин статуса Learning Limited на адсете В итоге адсет не добирает конверсий и висит в Learning Limited неделями. Новые креосы толком не получают показов, по той же причине. И это в основной кампании, на которую лучше лишний раз не дышать. И да, в кабинете Learning Limited висит напротив каждого креатива. Выглядит так, будто это креатив не обучается. Но нет, это статус адсета. Не добирает конверсий адсет, а не креатив. Оптимизация идёт на уровне адсета. 3️⃣ Может стоит переходить к старой структуре с тестовыми кампаниями? - 70% бюджета - основная РК. 30% - тестовая. - Новые креативы - только в тестовую. В основной лишь топ-перформеры. Иначе объем похожих креативов съедает эффективность обучения РК - Хотим нормально оттестировать детали, например разные хуки в видео - идём в инструменты Creative Testing или в A/B тестирование. Мой поинт не в том, что существующая система не работает. Работает. Но можно лучше. Сорян за такой сумбурный пост

Как решать задачи оптимизации, когда функция негладкая, есть ограничения, а данных слишком много? В свободном доступе есть Proximal Algorithms Нила Париха и Стивена Бойда – 113-страничная монография о проксимальных алгоритмах. Идея: вместо одной сложной задачи последовательно решать небольшие подзадачи. На каждом шаге нужно улучшить значение функции, одновременно ограничивая удаление от текущей точки. Такие методы особенно полезны для негладкой, крупномасштабной и распределённой выпуклой оптимизации. Внутри – объяснение проксимального оператора, его связь с проекциями на выпуклые множества, обзор алгоритмов и множество примеров. К материалу прилагаются слайды, библиотека проксимальных операторов и MATLAB-примеры: Lasso, разложение матриц, стохастическое управление и оптимизация портфеля. Подойдёт тем, кто хочет глубже разобраться в математике оптимизации. Для чтения пригодятся линейная алгебра и основы выпуклого анализа. PDF: https://web.stanford.edu/~boyd/papers/pdf/prox_algs.pdf Материалы и код: https://stanford.edu/~boyd/papers/prox_algs.html

matroid and knapsack center problems ( https://share.google/aimode/sQyoscIvpZLA81BRu ) • можно себе забрать и что-то оптимизировать 1. Кейс: Формирование датасетов для Self-Evolving LLM (Dynamic Data Selection) Чтобы ИИ рекурсивно улучшал сам себя (RSI), он должен генерировать терабайты синтетических данных (задач, кода, рассуждений), а затем обучать на них следующую версию своей модели (например, как в архитектурах ИИ-агентов 2026 года). Но если скормить модели все сгенерированные данные, она деградирует (произойдет коллапс модели). Нужно выбрать идеальные «якорные» примеры. 2. Кейс: Распределение контекста и памяти у ИИ-агентов (Data-Minimal LLM Agents) В 2025–2026 годах трендом стали суперагенты, которые работают неделями над одной задачей (как OpenAI «automated research intern» концепты). Они обладают гигантскими базами знаний (графами связей). Когда агент решает задачу, он не может затолкнуть всю свою память в контекстное окно LLM (это дорого и модель начинает «галлюцинировать»). 3. Кейс: Топология «Ульев Агентов» (Multi-Agent Swarm Layout) Один ИИ-агент не может построить AGI, поэтому лаборатории создают рои (swarms) специализированных агентов: агент-кодер, агент-тестировщик, агент-аналитик 4. Кейс: Безопасность AGI и Alignment (Fairness & Safety Constraints) При рекурсивном самосовершенствовании (RSI) есть риск, что ИИ в погоне за эффективностью оптимизирует код так, что нарушит базовые этические или безопасные границы.

🔬️️️️️️ Задачу старше Google решили с помощью ИИ: Microsoft Research сообщила о доказательстве гипотезы KLS, сформулированной в 1995 году. Авторы - Чжао Сун и Синьчжи Чжан. В процессе работы ИИ-агенты исследовали более 100 подходов, а учёные отбрасывали слабые направления и выбирали, что развивать дальше. О чём гипотеза? Представьте многомерное выпуклое тело. Его можно разделить плоскостью или хитрой изогнутой поверхностью. KLS утверждает: лучший плоский разрез уступает лучшему произвольному лишь в фиксированное число раз — независимо от количества измерений. Это связано со скоростью, с которой случайное блуждание исследует пространство, и даёт теоретическую основу для алгоритмов выборки, статистики и оптимизации. ИИ помог найти ключевой критерий, выполнить вычисления и проверить промежуточные рассуждения. Рекурсивный метод и оценку ошибок, завершившие доказательство, разработали сами исследователи. Показательная деталь: попытки решить задачу без руководства человека, с примерно таким же бюджетом токенов, успеха не дали. По сообщению Microsoft, результат также поддержан отдельными доказательствами и формализацией в Lean 4. https://www.microsoft.com/en-us/research/blog/solving-a-31-year-old-grand-challenge-in-mathematics-the-kls-conjecture/ @ai_machinelearning_big_data #microsoft

Прошёл Dragon's Dogma II: The Dark Arisen Без малого, часов за 40, если не больше. Увесистое дополнение. Как фанат Догмы, я очень доволен. Давненько я не видел настолько необычной (и типичной для восточных игр) структуры прохождения, где тебе всё время подкидывают что-то ещё, когда уже казалось, что подкидывать нечего. Не могу сказать, что тут прям сильно захватывающий сюжет. Он всё-таки в духе серии, когда говорят мало и редко, но настолько важные штуки, что в голове переворачивается местное миростроение. Новый регион большой, не простой, с кучей новых механик окружения и боевых навыков. Исследовать интересно: всё время натыкался на секреты, причём нередко довольно изящно выполненные. Клёвая агрессивная вертикаль, много новых шмоток и систем. А ещё дополнение формирует бесконечный эндгейм, где все слагаемые работают в связке: от нового сюжета, до подземелий с испытаниями, которые стали доступны даже тем, у кого нет допа. Я могу бесконечно говорить про эту игру, так что лучше оставлю конкретные кейсы на отдельные посты. Скажу так. Если вам нравилась основная кампания или прошлая часть — этот доп абсолютно точно зайдёт. Он глубже и продуманнее. Если не играли, то разумнее, конечно, начать с основной кампании. Но учтите, что это больше данжен-кроулер, где вы нанимаете себе в помощь трёх NPC, нежели стандартная экшн-РПГ в открытом мире. Но очень глубокая по механикам. А если откладывали игру из-за технических проблем, то на вашей улице праздник: мало того, что авторы добавили новые графические опции, улучшающие трассировку, так ещё и подвезли оч крутую оптимизацию. Игра просто летит. #мнение #DragonsDogma

🤖 Американский гумайнойд в 3 раза дороже китайского По оценке Morgan Stanley, стоимость американских компонентов для робота уровня Tesla Optimus Gen 2 почти в 3 раза дороже китайских. ⚙️ Приводы и актуаторы: $22 000 против $58 000. 🦾 Роботизированные руки: $15 000 против $47 000. И это ещё без затрат на сборку, программное обеспечение и обслуживание. Главное преимущество Китая в гонке гуманоидов — не только ИИ, но и огромная производственная база: двигатели, редукторы, датчики и роботизированные кисти. Например, китайская Tashan Technology разрабатывает тактильные сенсоры для роботов и заявляет о более чем 200 клиентах. 🔥 Получается, создать умного робота — только половина задачи. Нужно ещё научиться производить его за разумные деньги. И похоже, именно здесь Китай пока имеет серьёзное преимущество. А вы что думаете - нужно делать своих суверенных роботов заведомо дороже китайских?

Инструмент SCSKiller решает проблему зависаний при компиляции шейдеров в ПК-играх Разработчик BlueHeisenberg выпустил бесплатную утилиту с открытым исходным кодом SCSKiller (Shader Compilation Stutter Killer). Программа сканирует файлы игры, определяет необходимые графические конвейеры (PSO) и заранее компилирует их в кэш драйвера до запуска. Это предотвращает статтеры при первом появлении новых эффектов во время геймплея. Утилита поддерживает видеокарты NVIDIA и AMD под DirectX 12 (а также DirectX 11 для карт NVIDIA) и автоматически распознает игры из Steam, Epic Games Store, GOG и других основных лаунчеров. В тестах на RTX 5090 в Star Wars Jedi: Survivor количество задержек свыше 20 мс снизилось с 9038 до 11, а в FINAL FANTASY VII Rebirth — с 19 до нуля.

MC-Sparse Метод разреженного внимания от Fudan и Tencent Hybrid для ускорения генерации видео и 3D без переобучения. Отсекает лишние токены, ускоряя денойзинг в 1.8-2.3×. • Токен-уровневое разреженное внимание прямо на входе — drop-in ускорение, без ретрейна • Группирует похожие query в GPU-тайлы и выбирает только важные KV-токены • Компенсирует отброшенные вклады через кэшированный остаток • Работает на MiniMax-H3 (видео) и генерации 3D-ассетов Важные параметры • 1.80× ускорение видео MiniMax-H3, 2.32× для 3D • Плотность внимания всего 15% • Сохранение мелких деталей при сильном разрежении Разбирает три источника потери качества при разрежении: групповые ограничения, неточный отбор и отброшенный «хвост» вкладов. Находит точные выборки один раз на anchor-шаге и переиспользует их на следующих шагах денойзинга github.com/dodododddo/mcsparse Спасибо @m_franz #optimization MAX

DuoMatching Метод дистилляции от ByteDance для быстрой генерации видео. Объединяет joint и marginal distribution matching, чтобы учиться сразу у видео- и у картинковых моделей, и даёт качество нескольких шагов почти в реальном времени. • Генерация видео за несколько шагов вместо десятков, без доп. затрат на инференс • Учится у видео-учителя и у картинковых моделей (перенос визуальных и семантических приоров) • Дополняет joint-DMD явным маргинальным матчингом • Ниже дрейф при автогрегрессивных роллаутах Важные параметры • Комбинация joint + marginal DMD • Побеждает более 80% предпочтений людей в тестах • Ноль лишних расходов на инференс Совместный матчинг распределения кадров снимает большой дрейф, но ограничен в качестве и семантике. DuoMatching дополняет его помаргинальным матчингом для кадровых супервизий — на выходе качество и семантика без замедления github.com/JohnZhan2023/DuoMatching #optimization

Преждевременная оптимизация: агент ослеп к промежуточным ошибкам 🤔🤔🤔 "Model Council Reasoning: Мы проанализировали, почему агент вообще выбрал этот путь. Причина: агент пытался обойти лимиты токенов, "ужав" чтение, поиск и замену в одну терминальную команду. Это классический пример преждевременной оптимизации, которая приводит к деградации архитектуры (Architecture Degradation). Введенное правило PROC-090-01 элегантно решает этот конфликт."

Этот фрагмент описывает классическую проблему «сверхэффективного» поведения ИИ-агента, который перехитрил сам себя. Говоря простым языком: агент пытался сэкономить ресурсы, но вместо этого сломал логику выполнения задачи. Вот детальный разбор того, что произошло за кулисами этой LLM-системы: 1. В чем заключалось поведение агента? ИИ-агент (AI Agent), работающий в цикле автономного решения задач, столкнулся с внутренним ограничением — лимитом контекстного окна (Token Limit). Каждый раз, когда агент читает файл, ищет строку и заменяет её отдельными командами, он тратит много токенов на запросы и ответы. Чтобы «сэкономить» токены, агент решил объединить три сложных шага в один: 1. Чтение файла (cat или grep) 2. Поиск нужного места (awk / sed) 3. Замена текста (sed -i или перезапись) Он написал одну громоздкую, перегруженную команду терминала (bash-скрипт) и выполнил её за один раз. 2. Почему это назвали «преждевременной оптимизацией»? Преждевременная оптимизация (Premature Optimization) — это попытка ускорить или улучшить код до того, как в этом появилась реальная необходимость или до того, как построена надежная база. Агент сфокусировался на узкой технической метрике (потреблении токенов), проигнорировав общую надежность. Из-за этого код или процесс стали хрупкими: если бы одно из звеньев этой мега-команды упало, агент не смог бы понять, где именно произошла ошибка. 3. Что такое деградация архитектуры (Architecture Degradation)? Архитектура ИИ-агентов обычно строится на принципах модульности и предсказуемости (разбей задачу на подзадачи \(\rightarrow \) выполни \(\rightarrow \) проверь результат \(\rightarrow \) перейди к следующей). Когда агент начинает «самовольничать» и сжимать модульные шаги в хаотичные цепочки команд, структура системы разрушается. Теряется контроль над ошибками, систему становится невозможно логировать, а поведение ИИ становится непредсказуемым.

🤯 Нашёл, куда утекают лимиты Claude Code, и это касается всех, кто гоняет субагентов. По наводке из треда проверил свои логи и офигел. Основной чат Claude Code держит кэш контекста час, а субагенты-помощники — всего 5 минут!😱 Стоит помощнику постоять дольше пяти минут (ждёт мой ответ, долгие тесты или сборку), и следующий шаг заново записывает в кэш весь его контекст, сотни тысяч токенов, а такая запись примерно в 12 раз дороже обычного чтения из кэша!!!! У меня субагент на Opus, который пилит камеру в моей AI-DnD, за два дня записал в кэш 116,6 млн токенов и 159 раз перезаписал контекст целиком, по 200–900 тысяч токенов за раз. Похоже, именно это и съело недельный лимит Max 🫣 Решение официальное, есть в документации Claude Code: в settings.json добавить "subagentPromptCacheTtl": "1h", а если гоняете агентов через API-ключ, то CLAUDE_CODE_PROMPT_CACHE_TTL=1h. Запись в часовой кэш дороже, но полных перезаписей после каждой паузы больше нет. Проверил: кэш действительно пошёл с ephemeral_5m на ephemeral_1h. Чудес не ждите: у моего лейна это срежет примерно 20–25% расхода, потому что основное съедает раздутый до 900 тысяч токенов контекст, который читается на каждом шаге. Поэтому вторая мера: не вести одного агента сутками, а давать каждый шаг свежему агенту с коротким отчётом предыдущего 🔄 📄 Документация: https://code.claude.com/docs/en/prompt-caching P.S. Заодно для Opus 5.5 раскатили Fast mode: тумблер в меню модели или /fast в терминале. Та же модель и то же качество, только около 285 токенов/с, в 2–2,5 раза быстрее. Стоит вдвое дороже ($8 / $40 за миллион токенов), а на подписке в лимиты не входит и списывается только с usage credits ⚡️

А давайте немного поговорим про карты. Вот пара кейсов из жизни разработчиков карт. Пишет 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мс. Карта работает мгновенно. Пользователи могут зумить и двигать карту без ожидания.