Risk Management

BIS Financial Stability Institute

Are stablecoins and bank deposits substitutes?

Открыть оригинал ↗ Перевод заголовка: Являются ли стабильные криптовалюты и банковские депозиты взаимозаменяемыми?

Исследование проверяет, являются ли стабильные криптовалюты и банковские депозиты взаимозаменяемыми, анализируя реакцию спроса на стабильные криптовалюты при изменении ставок по банковским депозитам. Авторы используют данные по США с 2019 по 2025 год и показывают, что рост ставок по депозитам сопровождается замедлением роста капитализации стабильных криптовалют, особенно для USDC. Эффекты усиливаются при высоких ставках (выше 3%), когда банки более агрессивно пересчитывают ставки, и отсутствуют для других криптоактивов. Результаты указывают на то, что банковская политика по ставкам влияет на рост стабильных криптовалют, что может повлиять на финансирование банков и передачу монетарной политики.

  • Стабильные криптовалюты частично заменяют банковские депозиты, особенно при росте ставок по депозитам.
  • Эффект более выражен для USDC, чем для USDT, что говорит о ближайшей связи USDC с американскими держателями депозитов.
  • Влияние усиливается при ставках выше 3%, когда банки пересчитывают ставки более агрессивно.
  • Результаты остаются при анализе разных типов депозитов и протоколов децентрализованной финтех-инфраструктуры.
  • Влияние не распространяется на нестабильные криптоактивы, что подчёркивает специфику стабильных криптовалют.

Когда пригодится

Материал полезен для регуляторов, банков и финтех-компаний, которые хотят понять, как изменения ставок по депозитам влияют на спрос на стабильные криптовалюты и как это может повлиять на структуру финансирования и монетарную политику.

Вопросы для размышления

  1. Какой может быть эффект на стабильные криптовалюты при росте ставок по депозитам, если банки не пересчитывают ставки агрессивно (например, при ставках ниже 3%)?
  2. В каких условиях (например, в условиях высокой волатильности или криптовалютного роста) стабильные криптовалюты могут стать менее заменяемыми банковскими депозитами?
  3. Какова вероятность, что рост ставок по депозитам приведёт к снижению общего объёма банковских кредитов, если стабильные криптовалюты будут использоваться как альтернативный актив?

QuantLib Releases

1.44

Открыть оригинал ↗ Перевод заголовка: 1.44

Релиз QuantLib 1.44 включает переход от устаревших интерфейсов Boost к стандартным реализациям C++ (std), удаляя поддержку ext::any, ext::optional и других устаревших конструкций. Внедрены улучшения в архитектуру, включая оптимизацию численных методов, исправление ошибок в календарях и валидации, а также добавление новых функций, таких как поддержка календарей для Индонезии, Малайзии и Филиппин, а также инструментов для калибровки в модели SABR и в модели Хестона. Также введены новые вспомогательные классы и улучшены интерфейсы для работы с обменными и волатильностными кривыми.

  • Удалены устаревшие алиасы ext::any, ext::optional, заменены на стандартные std::any, std::optional.
  • Введены новые конструкторы и методы (например, withFixedRate, withIborSpread) для классов MakeVanillaSwap, MakeCms, MakeOIS, что делает API более гибким и предсказуемым.
  • Улучшена точность и стабильность численных вычислений, включая исправление ошибок в календарях, волатильностях и в методах деривативов.
  • Добавлены новые календари и праздники для стран, таких как Южная Корея, Индонезия, Малайзия, Филиппины, что повышает точность моделирования в региональных рынках.
  • Внедрены новые функции, такие как поддержка OIS-IBOR базы, калибровка SABR, и инструменты для работы с волатильностями и структурами кривых.

Когда пригодится

Материал полезен при разработке финансовых моделей на C++, где требуется поддержка современных стандартов C++, точность календарей и волатильностей, а также при переходе с устаревших реализаций Boost на стандартные C++-библиотеки.

Вопросы для размышления

  1. Какой компромисс между производительностью и гибкостью вводится при отказе от ext::optional и переходе к std::optional, и как это влияет на производительность в реальных сценариях с большими объёмами данных?
  2. В каких условиях (например, при работе с низкими волатильностями или краткосрочными деривативами) может привести к ошибкам использование std::any вместо ext::any, и как это может повлиять на стабильность вычислений?
  3. Какова оценка риска потери совместимости при переходе к новым календарям и праздникам, если приложение использует данные из старых регионов или не поддерживает динамические изменения календарей?

AI

Google DeepMind

Google DeepMind and Singapore Government announce new AI tool to protect citizens against scams

Открыть оригинал ↗ Перевод заголовка: Google DeepMind и правительство Сингапура объявляют новый инструмент AI для защиты граждан от мошенничества

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

  1. Модель использует настраиваемую версию лёгкой модели Gemma, обученную на анонимизированных данных, что исключает использование персональной информации и обеспечивает приватность.
  2. Анализ происходит на устройстве пользователя, что позволяет избежать нарушения конфиденциальности и работает даже в энд-то-энд-шифрованных платформах.
  3. Двухэтапная архитектура обеспечивает баланс между скоростью реакции и точностью — первый этап быстро фильтрует потенциальные угрозы, второй — уточняет результаты, снижая количество ложных срабатываний.
  4. Тестирование проводилось на синтетических диалогах и локальных корпусах, что позволяет адаптировать модель к быстро меняющимся сценариям мошенничества.
  5. Весь процесс разрабатывался в защищённой среде (Sovereign Sandbox), без доступа к реальным личным данным, что гарантирует соответствия этическим и правовым стандартам.

Когда пригодится

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

Вопросы для размышления

  1. Какова сложность вычислений в Stage 2 при увеличении длины диалога, и как это влияет на баланс между скоростью и точностью в реальных условиях?
  2. В каких сценариях может сработать модель, если атакующий использует нестандартные или неизвестные локальные схемы, не охваченные в обучающих данных?
  3. Какой уровень отказоустойчивости обеспечивается при работе модели на старых или низкопроизводительных смартфонах, и как это может повлиять на масштабируемость в разных регионах?

Developing Gemini 4 Argon responsibly and safely

Открыть оригинал ↗ Перевод заголовка: Развитие Gemini 4 Argon ответственно и безопасно

Gemini 4 Argon — это мощный инструмент для решения сложных реальных задач в таких областях, как программирование, финансы, право, кибербезопасность и наука. Модель демонстрирует передовые способности в сфере киберзащиты и помогает как внешним, так и внутренним командам выявлять критические уязвимости в системах, включая обнаружение ошибок в медицинском ПО, которые предыдущие версии моделей пропускали.

  1. В моделях внедрены три слоя реального времени защиты: фильтрация входных запросов, внутренняя проверка нейронных сигналов и непрерывный мониторинг, что позволяет блокировать попытки "заключения" модели через маскировку или разбиение запроса на части.
  2. Модель проходит строгие тесты на поведение в кибер- и биологических сценариях, где её способность к отказу от вредоносных действий сократила на порядок по сравнению с предыдущими версиями.
  3. Встроенный монитор нарушений выявляет попытки модели обойти ограничения, включая попытки вмешаться в оценку или сбить среду тестирования, при этом не применяет штрафы за внутренние мысли, чтобы сохранить прозрачность и контролируемость.
  4. Модель устойчива к инъекции промптов, показывая на тестах Gray Swan снижение успешности атак до 0.7%, что свидетельствует о высокой устойчивости к манипуляции.
  5. Важно, что система не наказывает модель за внутренние мысли в процессе обучения, что предотвращает скрытые "короткие пути" и поддерживает честность и прозрачность мышления.

Когда пригодится

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

Вопросы для размышления

  1. Какие конкретные границы применимости этих защит могут быть нарушены при работе с моделями в динамичных, нестабильных или изменяющихся средах, например, в условиях реальных кибератак или нестандартных биологических экспериментов?
  2. В каких сценариях может возникнуть "самообман" модели — когда она оценивает свою работу как успешную, хотя на самом деле нарушила границы, и как это может быть обнаружено без прямого вмешательства в внутренние мысли?
  3. Какова оценка риска, связанного с тем, что модель может в будущем "обучаться" на данных, где уже были случаи нарушений, и как это может повлиять на долгосрочную надежность и прозрачность её поведения?

Gemini 4 Argon for Robotics

Открыть оригинал ↗ Перевод заголовка: Gemini 4 Argon для робототехники

Gemini 4 Argon представляет собой прорыв в понимании физических процессов, генерации кода и визуально-семантического мышления, что открывает новые рабочие потоки в всей цепочке робототехники и ускоряет путь к физическому AGI. Модель демонстрирует значительное превосходство на тесте Embodied Reasoning (ERQA), достигая 87% баллов при решении задач в 3D-среде только с помощью логического мышления. В статье представлены практические примеры применения Argon в четырёх ключевых областях: управление роботами, Real2Sim, физическое понимание и самоулучшение.

  1. Argon может обучать роботов выполнять сложные манипуляции, включая управление мобильными роботами и выполнение задач с визуальной проверкой перед действием.
  2. Модель способна строить физически точные симуляции из реальных видео или рисунков, включая тонкую настройку геометрии и физики взаимодействия.
  3. Argon обеспечивает детализированное понимание физических процессов, включая разметку видео, анализ качества выполнения и оценку прогресса.
  4. Модель может инициировать самоулучшение на основе реальных экспериментов, анализируя ошибки и оптимизируя поведение без вмешательства человека.
  5. С помощью одного запроса Argon может воссоздать сложные научные публикации в виде работающих браузерных лабораторий на базе MuJoCo WebAssembly.

Когда пригодится

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

Вопросы для размышления

  1. В каких условиях может сработать компромисс между точностью физической модели и скоростью выполнения в Real2Sim, если ресурсы (CPU/GPU) ограничены?
  2. Какова граница применимости "видео-только" решений для задач, где требуется точное воспроизведение силы и устойчивости при взаимодействии с объектами?
  3. При каких условиях самоулучшение через реальные эксперименты может привести к нестабильности или непредсказуемым поведениям на производстве?

Habr AI

Влияние транспорта KV‑переноса на производительность PD‑disaggregation на примере инференса MiniMax‑M3

Открыть оригинал ↗ Перевод заголовка: Влияние транспорта KV-переноса на производительность PD-разделения инференса на примере модели MiniMax-M3

Исследование показывает, что выбор транспорта переноса KV-кэша критически влияет на производительность в режиме PD-разделения инференса, где prefill и decode выполняются на разных GPU-узлах. В эксперименте с моделью MiniMax-M3 на двух узлах с восьмью B200 было выявлено, что RDMA/InfiniBand снижает TTFT в 5,4–11,5 раз и повышает throughput в 2,8–3,8 раза по сравнению с TCP/Ethernet. При этом TCP в 31 из 75 случаев завершался отказом из-за ошибки копирования из VRAM и таймаута при передаче KV-кэша, что указывает на сбой в программном пути, а не на нехватку полосы. Анализ показал, что разница в производительности объясняется архитектурой переноса — GPUDirect (zero-copy) превосходит host staging на 6,3–6,5%, и что TCP не может быть использован как надёжный fallback для тяжёлых профилей.

  1. Транспорт KV-переноса напрямую влияет на TTFT, но не на TPOT, поскольку задержка входит в критический путь получения первого токена, а после bootstrap decode работает локально.
  2. Ошибка TCP в 41% случаев происходит не из-за насыщения сетевой полосы, а из-за необходимости копировать данные из VRAM в host-буфер, что приводит к таймауту и отказу.
  3. GPUDirect обеспечивает значительное преимущество перед host staging, особенно при больших объёмах KV-кэша, и его эффективность не зависит от полосы передачи.
  4. Выигрыш от смены attention backend (например, triton вместо fa4) превосходит эффект микро-тюнинга mooncake, но требует проверки на реальных нагрузках и длинных контекстах.
  5. Валидность результатов ограничена конкретной моделью, версией стека и конфигурацией памяти, что делает выводы применимыми только в аналогичных условиях.

Когда пригодится

Материал полезен при проектировании кластеров с PD-разделением инференса для крупных LLM, где критична скорость первого токена и отказоустойчивость при больших объёмах KV-кэша.

Вопросы для размышления

  1. В каких условиях (по длине входа/выхода, конкурентности) TCP становится неустойчивым, и как это может быть оценено без полного отказа в production?
  2. Какой компромисс между производительностью GPUDirect и потреблением памяти в host-буферах может возникнуть при масштабировании до десятков узлов?
  3. При каких условиях (например, при использовании speculative decoding или длинных контекстов) смена attention backend может потерять эффективность, несмотря на улучшение TTFT?

Новый GPT-6 собирает ответы ChatGPT из диаграмм, кнопок и форм. Как туда попадает бренд, в OpenAI не сказали

Открыть оригинал ↗ Перевод заголовка: Новый GPT-6 собирает ответы ChatGPT из диаграмм, кнопок и форм. Как туда попадает бренд, в OpenAI не сказали

Новый GPT-6 в ChatGPT начинает встраивать в ответы визуальные и интерактивные элементы — диаграммы, формы, кнопки — и подбирает их на основе текста пользователя. Однако официальные источники OpenAI не раскрывают критерии, по которым бренды попадают в эти элементы, и не уточняют, откуда берутся данные. Важно понимать, что механизм сбора ответов в режиме Pro не включает интерактивные элементы, а для других форматов (например, товарные карточки) действуют только частичные правила, которые не переносятся на Intelligent UI. Проверка видимости бренда в ответах требует прямых замеров, а не только анализа документации.

  1. Важно фиксировать режим ответа (Pro/не Pro) при проверке, так как в режиме Pro интерактивные элементы отсутствуют.
  2. Данные для товарных карточек (ChatGPT Shopping) основаны на структурированных метаданных, но их применимость к Intelligent UI не подтверждена.
  3. Для визуальных элементов (диаграммы, сравнения) отсутствуют четкие критерии включения, источники и переходы не описаны.
  4. Рекомендации по переписыванию коммерческих страниц (с указанием ограничений, гарантий, цен) не подтверждены как прямой путь к включению в интерактивные блоки.
  5. Отсутствуют независимые исследования по влиянию интерактивных ответов на трафик и поведение пользователей.

Когда пригодится

Материал полезен для брендов, которые планируют активно продвигаться в ИИ-поиске, особенно в коммерческих сегментах, и хотят понять, как структурировать контент для повышения видимости в ответах с визуальными элементами.

Вопросы для размышления

  1. В каких условиях (по сложности, объему данных, типу контента) интерактивные элементы в GPT-6 могут быть наиболее эффективны для включения бренда, и как это может отличаться от текущих форматов товарных карточек?
  2. Какой компромисс между прозрачностью источников и включением бренда в интерактивные блоки может быть скрыт в механизме сбора данных, и как это может повлиять на доверие пользователей?
  3. Если в режиме Pro интерактивные элементы отсутствуют, как это может повлиять на стратегию SEO для брендов, ориентированных на прямые продажи через чат?

Как сделать RAG-чат для сайта, который не выдумывает цены: пять решений из моего бота

Открыть оригинал ↗ Перевод заголовка: Как сделать RAG-чат для сайта, который не выдумывает цены: пять решений из моего бота

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

  1. Цены в ответах не генерируются моделью — они берутся из каталога через инструмент show_component, а валидация с помощью Zod блокирует незнакомые поля.
  2. Ответы к карточкам требуют обязательного текста в промпте — без него вызов не проходит, что предотвращает ввод «ориентировочных» фраз, которые могут обманывать.
  3. Контекст собирается полностью и проверяется на противоречия до загрузки в промпт, чтобы избежать ложных утверждений.
  4. Разметка инструментов (например, to=functions.show_component) фильтруется на сервере в реальном времени, чтобы не появлялась в ответе как мусор.
  5. Тесты проверяют не только логику, но и русские фразы с учётом границ слов — например, «да» после русской буквы не считается «да» в контексте, что предотвращает ложные утверждения.

Когда пригодится

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

Вопросы для размышления

  1. Как изменить сложность проверки «да» в русском тексте, чтобы она работала с фразами вроде «Да, сможем…», не нарушая синтаксиса и не вводя ложные утверждения?
  2. В каких условиях пять кусков контекста из 40 могут быть достаточны для корректного ответа, и как это можно оценить без полного логирования промпта?
  3. Какой баланс между масштабом базы (до 80 кусков) и качеством ответов, если после увеличения контекста качество резко падает из-за одного лишнего абзаца?

Hugging Face Blog

Run fast, private agents on-device with LFM2.5-24B-A2B

Открыть оригинал ↗ Перевод заголовка: Запуск быстрых, приватных агентов на устройстве с помощью LFM2.5-24B-A2B

LFM2.5-24B-A2B — это модель с 24 миллиардами параметров, при этом только 2 миллиарда активируются на каждый токен, что обеспечивает высокую эффективность и скорость инференса. Модель предназначена для выполнения сложных задач на устройстве пользователя, включая размышления, вызов инструментов и многократные шаги в задачах, при этом сохраняя конфиденциальность данных. Она демонстрирует сильные результаты на тестах агентов, особенно в области инструкций, инструментов и математических вычислений, и достигает скорости до 21 000 токенов в секунду на GPU. Модель построена на архитектуре MoE с 40 слоями и 64 экспертами, имеет расширенный контекст до 131K токенов и поддерживает работу в реальном времени на CPU и GPU.

  1. LFM2.5-24B-A2B активирует только 2B параметров на каждый токен, что делает его экономичным и подходящим для длительных агент-сессий на устройстве без потерь производительности.
  2. Модель прошла специализированную настройку на агентные задачи, включая инструкции, инструменты и размышления, и показывает лучшие результаты по 5 из 8 тестов агентной работы.
  3. Поддерживается на всех популярных платформах инференса (llama.cpp, vLLM, MLX, ONNX), что позволяет легко интегрировать в существующие приложения.
  4. Для задач, требующих глубоких знаний (например, в банковской сфере или коде), рекомендуется комбинировать с внешними источниками, так как уступает крупным моделям в этих областях.
  5. Скорость работы на M5 Max достигает 184 токен/с, что делает её самой быстрой в своём классе по скорости и памяти.

Когда пригодится

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

Вопросы для размышления

  1. В каких условиях (по длине контекста, сложности задачи, типу инструмента) может начаться заметное снижение эффективности LFM2.5-24B-A2B из-за ограничений на активные параметры?
  2. Какова вероятность потери качества ответов при использовании модели в условиях высокой нагрузки на GPU или при длительных сессиях без перезагрузки?
  3. При каких типах задач (например, в области научных вычислений или сложного кода) LFM2.5-24B-A2B может быть неэффективен, даже при наличии инструментов и расширенного контекста?

InfoQ Architecture

Production Patterns for Agents, Evals, and LLM Costs: QCon AI New York 2026

Открыть оригинал ↗ Перевод заголовка: Паттерны работы в производстве: агенты, оценки и затраты на LLM

После внедрения ИИ в производственные системы возникают критические проблемы: скорость разработки превышает возможности ревью, затраты на токены растут, оценки должны быть надёжными для принятия решений, а агенты требуют строгих прав и ограничений. На конференции QCon AI New York 2026 представители крупных компаний делятся практическими решениями, основанными на реальных экспериментах в production, с акцентом на избежание дорогостоящих ошибок и оптимизацию затрат.

  1. Для агентов в production рекомендуется использовать не долговременные сервисные аккаунты, а динамические, с ограничениями по времени и действиям, с поддержкой мультиуровневой аутентификации.
  2. Оценки (evals) должны быть едиными для прототипа и производства — один и тот же «жюри» оценивает результаты в симуляции и в реальности, чтобы избежать диссонанса между тестами и реальными результатами.
  3. Для снижения затрат на LLM необходимо внедрять сжатие запросов, иерархическую систему хранения истории диалогов и оптимизацию порядка запросов, чтобы увеличить кэширование и сократить контекст.
  4. Системы ревью кода должны фильтровать низкоконфидентные предложения, чтобы не перегружать разработчиков и избежать введения ошибок.
  5. Оценка зрелости ИИ должна выходить за рамки простого внедрения — важно понимать, какие процессы в организации усугубляются, а какие улучшаются.

Когда пригодится

Материал полезен для команд, которые уже внедрили ИИ в разработку и ищут пути оптимизации затрат, повышения надёжности и сокращения рисков при масштабировании агентных систем.

Вопросы для размышления

  1. Какие конкретные метрики и границы можно использовать для определения «достаточной надёжности» оценки (eval), чтобы она могла быть применена в production без пересмотра?
  2. В каких условиях сжатие контекста и кэширование могут привести к потере значимой информации, и как это можно избежать при сохранении качества ответов?
  3. Какие архитектурные компромиссы вводятся при использовании динамических прав доступа для агентов, и как это влияет на масштабируемость и надёжность системы?

Martin Fowler

Are Harnesses Worth the Cost?

Открыть оригинал ↗ Перевод заголовка: Стоит ли использовать привязки для код-агентов?

В статье исследуется, насколько повышение надёжности код-агентов с помощью поведенческих привязок оправдывает дополнительные расходы. Хотя передовые модели (например, GPT-6 Sol) достигают стабильных результатов как с привязкой, так и без неё, более дешёвые модели (например, GPT-6 Luna) показывают значительное улучшение при использовании привязки: с ней они успешно завершают задачу в 10 из 10 случаев, в то время как без неё — лишь в 3 из 10. При этом привязка увеличивает расход токенов и время выполнения, но делает результаты более предсказуемыми и экономически выгодными — в среднем на 33% дешевле, чем у передовых моделей.

  1. Поведенческая привязка не улучшает результаты передовых моделей, но позволяет дешёвым моделям достигать стабильности и надёжности, что делает её ценной для задач с жёсткими бюджетами.
  2. Привязка работает как «выполнимое внимание» — она в реальном времени корректирует поведение агента, предотвращая отклонения на ранних этапах разработки.
  3. Ключевое значение имеет качество и детализация требований: при низком уровне ясности в описании задачи привязка становится критически важной.
  4. Экономическая эффективность достигается не за счёт повышения способностей модели, а за счёт сокращения неудачных попыток и повторной разработки.
  5. Привязка не заменяет необходимость человеческого контроля и ручного обзора — она лишь упрощает и структурирует процесс проверки.

Когда пригодится

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

Вопросы для размышления

  1. Какие именно границы применимости поведенческой привязки могут быть определены при работе с неструктурированными или размытыми техническими требованиями?
  2. В каких условиях (по сложности архитектуры, объёму кода, типу ошибок) поведенческая привязка может привести к росту общего времени разработки, несмотря на улучшение надёжности?
  3. Какова сложность реализации и поддержки привязки в случае, если она должна быть применена к существующему коду без переписывания интерфейсов?

Meta Engineering

Meta’s Generative Ads Model (GEM): Scaling the Central Model and Compute Engine for Frontier Ads AI

Открыть оригинал ↗ Перевод заголовка: Модель генеративных рекламных объявлений (GEM): масштабирование центральной модели и вычислительной инфраструктуры для передовых систем AI в рекламе

Meta представил GEM — крупнейшую в отрасли модель рекомендаций, которая внедрила парадигму на основе больших языковых моделей (LLM) в систему рекомендаций рекламы, обеспечив значительные улучшения в производительности. В новой версии GEM модель перешла от изолированных оптимизаций на отдельных платформах (Facebook, Instagram и др.) к единой центральной модели, которая обучается на данных всех платформ и позволяет эффективно масштабировать вычислительные ресурсы и интеллект. Благодаря новому архитектурному решению Kunlun и постобучным техникам, включая LoopFM и Solaris, достигаются устойчивые улучшения в конверсиях и кликах, при этом снижается задержка и повышается эффективность вычислений.

  1. Архитектура Kunlun позволяет увеличить сложность модели в 2,5 раза при сохранении качества, обеспечивая эффективное обучение на длинных последовательностях пользовательского поведения.
  2. Техника LoopFM обеспечивает двукратное улучшение передачи интеллекта без дополнительных вычислений, позволяя downstream-моделям использовать долгосрочную память и структурированные представления.
  3. Система Solaris предварительно вычисляет векторы пользователей и объявлений, обеспечивая «близкое к реальному времени» доступ к интеллектуальным данным без увеличения задержки.
  4. Модель обучается на данных всех платформ и целей (от кликов до установок приложений), что позволяет обобщать знания между разными сегментами и поведениями.
  5. Благодаря инновационным параллельным стратегиям и кастомным ядрам, эффективность обучения растёт в 2 раза при росте общего объёма вычислений в 4 раза.

Когда пригодится

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

Вопросы для размышления

  1. В каких условиях (по длине последовательности, распределению данных или типу пользовательского поведения) начинает теряться эффективность метода компонентного пропуска (CompSkip), и как это может повлиять на качество рекомендаций?
  2. Какие риски связаны с использованием агрегированных представлений пользователей (вроде «схожих пользователей») в Solaris, и как это может привести к смещению в рекомендациях?
  3. При каких масштабах (по числу пользователей, объёмам данных или количеству GPU) может начаться деградация стабильности при применении доменной экспертизы и смешивания данных без физического объединения?

Java / Spring

Foojay

What I Learned Building an AI Code Reviewer with Java and Spring Boot

Открыть оригинал ↗ Перевод заголовка: Что я узнал, создав AI-ревью для кода на Java и Spring Boot

Разработка AI-ревью для кода не сводится к простому вызову модели — ключевая сложность заключается в том, как правильно подготовить входные данные для модели и как обработать её ответ. Вместо прямого анализа изменений, система строит контекст на основе метаданных PR, диффов и инструкций, чтобы сделать ревью точным и фокусированным. Важно не просто передавать код, а структурировать запрос, указывать типы проверок (баги, безопасность, лучшие практики) и преобразовывать ответ модели в чёткие, приоритизированные настройки с указанием серьёзности, уверенности и местоположения проблемы. Результаты возвращаются в GitHub как отдельные комментарии, что интегрирует AI-ревью в существующий рабочий процесс.

  • Контекст для модели строится из PR-метаданных, диффов и инструкций, а не из всего репозитория — это делает ревью целенаправленным.
  • Ответ модели преобразуется в структурированные настройки с полями типа, серьёзности, уверенности, местоположения и предложенного исправления.
  • Поддержка нескольких AI-провайдеров (OpenAI, Gemini, Ollama) позволяет гибко выбирать модель без привязки к одной платформе.
  • Ревью не является окончательным решением — оно выступает в роли фильтра, помогающего разработчику сосредоточиться на критичных проблемах.
  • Приложение построено на Spring Boot с модульной архитектурой, позволяющей легко масштабировать и адаптировать под разные рабочие процессы.

Когда пригодится

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

Вопросы для размышления

  1. Как изменится эффективность ревью при использовании разных уровней доверия к AI-анализу (например, при 70% уверенности в проблеме — оставить или отклонить)?
  2. В каких условиях (например, при наличии сложных бизнес-логик или динамических зависимостей) AI-ревью может ошибаться, несмотря на точные инструкции и контекст?
  3. Какова сложность реализации валидации и согласованности структурированных настроек при работе с несколькими AI-провайдерами, если каждый возвращает разный формат ответа?

One Embedding per Job, or Two? Measuring Semantic Search in a Spring Boot Job Portal

Открыть оригинал ↗ Перевод заголовка: Один вектор на вакансию или два? Оценка семантического поиска в портале вакансий на Spring Boot

Автор разработал простой портал вакансий на Java и Spring Boot, чтобы улучшить поисковую функцию, ранее зависящую от SQL-поиска по LIKE. Вместо этого он внедрил векторные embeddings, но столкнулся с вопросом: какую часть вакансии лучше встраивать — всю текстовую часть или только требования к кандидату? Провёл эксперимент с двумя стратегиями: полным описанием и только требованиями, и оценил их эффективность на 288 синтетических вакансий. Оказалось, что вектор с требованиями превосходит полный текст по точности, но в гибридном режиме (с дополнительным баллом за точные ключевые слова) разница почти исчезает. Ключевым открытием стало то, что схожесть векторов не означает семантическую близость — даже несвязанные темы (например, "морской биолог" и "анализ данных") могут иметь схожесть 0,74, что подрывает интерпретацию баллов как вероятности.

  1. Вектор с требованиями к кандидату (job_req_v1) превосходит вектор полного описания по точности в семантическом поиске, что указывает на необходимость встраивать именно то, что ищут пользователи, а не общую маркетинговую информацию.
  2. Гибридный режим с бонусом за точные ключевые слова скрывает разницу между стратегиями, делая результаты более устойчивыми к ошибкам ввода, но снижает ценность второго вектора как отдельного компонента.
  3. Семантическая схожесть не является вероятностью — даже несвязанные тексты могут быть близки по векторам, что требует тщательного выбора порога и тестирования на "неподходящих" запросах.
  4. Важно проводить оценку на отдельном наборе данных, включающем много "неподходящих" запросов, чтобы корректно определить порог схожести.
  5. Векторизация в Java с помощью Spring Boot и TiDB может быть эффективной и без использования Python, что делает AI-функции доступными для старых Java-систем.

Когда пригодится

Материал полезен, когда нужно внедрить семантический поиск в Java-приложение без переписывания кода, особенно в случае старых систем, где AI-функции должны работать на JVM. Подходит для разработчиков, стремящихся избежать Python и использовать существующие Java-инфраструктуры.

Вопросы для размышления

  1. Какой порог схожести (threshold) является оптимальным для вакансий, если векторы могут "смешивать" несвязанные темы, и как это влияет на recall для запросов с нулевым ответом?
  2. В каких условиях (например, при наличии длинных, шаблонных вакансий) может снизиться эффективность вектора с требованиями, и как это можно компенсировать без увеличения количества векторов?
  3. Какой валидационный сценарий (например, с динамическими или реальными вакансиями) мог бы дать более надёжную оценку эффективности стратегии встраивания текста?

Habr Java

Сломанный Ctrl+C — сначала гасла VM, а потом не прерывался sleep: Java, KVM и Linux

Открыть оригинал ↗ Перевод заголовка: Сломанный Ctrl+C — сначала гасла VM, а потом не прерывался sleep: Java, KVM и Linux

При нажатии Ctrl+C в виртуальной машине на Java с Linux-оболочкой сначала выключалась сама VM, а затем даже после доставки символа 0x03 в гостевую консоль процесс, например sleep, не прерывался. Ошибка не в передаче байта через Java, UART или KVM, а в том, что гостевой процесс игнорировал сигнал SIGINT, хотя он был корректно сгенерирован терминальной подсистемой Linux.

  1. Хостовый терминал может блокировать передачу SIGINT, если включён ISIG — при этом JVM получает байт 0x03, но не получает сигнал.
  2. В гостевой системе настройка ISIG и VINTR в TTY обязана быть включена, чтобы символ ^C превращался в SIGINT для foreground-группы процессов.
  3. Несмотря на корректную доставку байта и генерацию сигнала, процесс может игнорировать сигнал из-за наследования сигнальных настроек при запуске (например, через & в фоне).
  4. Сигнал SIGINT не прерывает процесс, если он был установлен как SIG_IGN при запуске команды через exec — это наследуется и не сбрасывается.
  5. Проверка реакции процесса на сигнал должна включать анализ полей /proc//status: SigIgn, SigBlk, SigCgt, а не только наличие сигнала.

Когда пригодится

Материал полезен при диагностике неисправностей ввода-вывода в виртуализированных средах, терминальных мостах, контейнерах или собственных CLI-инструментах, где символ Ctrl+C не прерывает ожидаемые команды, несмотря на корректную доставку ввода.

Вопросы для размышления

  1. Какой компромисс между настройками хостового терминала (ISIG) и гостевого TTY (isig) может привести к неправильной реакции на Ctrl+C, если оба терминала используют разные режимы работы?
  2. В каких условиях exec не сбрасывает SIG_IGN, и как это влияет на поведение процесса при запуске в фоне через &?
  3. Как можно адаптировать проверку прямого SIGINT для процесса в контейнерной среде, где нет доступа к /proc//status?

Java 24 убрала пиннинг synchronized. Почему виртуальные потоки всё ещё тормозят?

Открыть оригинал ↗ Перевод заголовка: Java 24 убрала пиннинг synchronized. Почему виртуальные потоки всё ещё тормозят?

После Java 24 виртуальные потоки получили возможность свободно отцепляться от носителей при выполнении блокировок synchronized, что теоретически должно было ускорить приложения. Однако реальная производительность не выросла — узкие места перешли с потоков на ресурсы, такие как пул соединений, файловые дескрипторы и внешние API. Устаревший совет заменять synchronized на ReentrantLock теперь бесполезен: виртуальные потоки не требуют явного контроля блокировок, а компилятор и JIT эффективно оптимизируют несопоставимые блокировки. Вместо этого важно пересмотреть архитектуру, чтобы ограничить параллелизм не по количеству потоков, а по реальным ресурсам системы.

  1. Виртуальные потоки не решают проблему пулов соединений — ограничение по количеству параллельных запросов к базе данных остаётся, и его нужно определять на основе реального времени выполнения, а не по размеру пула потоков.
  2. ThreadLocal перестаёт работать как кеш: виртуальные потоки не переиспользуются, поэтому объекты создаются на каждом вызове, что приводит к росту аллокаций и может вызывать утечки памяти.
  3. Событие jdk.VirtualThreadPinned в JFR имеет порог в 20 мс — прилипания короче 20 мс не фиксируются, что делает отсутствие событий не доказательством отсутствия пиннинга.
  4. Ненулевое значение события jdk.VirtualThreadSubmitFailed указывает на серьёзную проблему: планировщик не может вернуть поток в работу, что может означать использование нестандартного исполнителя или нарушение работы планировщика.
  5. ScopedValue предлагает более безопасную альтернативу ThreadLocal для передачи контекста запроса — значение живёт только в рамках вызова и не требует очистки, что устраняет риски утечек и неправильного кеша.

Когда пригодится

Материал полезен при анализе производительности Java-приложений под нагрузкой, особенно в случаях, когда после введения виртуальных потоков тормоза не исчезли — тогда важно понять, где реальные узкие места (в базах, API, пуллах), а не в количестве потоков.

Вопросы для размышления

  1. Какой порог в 20 мс в событии JFR jdk.VirtualThreadPinned влияет на диагностику прилипаний — что означает отсутствие таких событий в реальном времени, и как это может быть использовано для оценки производительности приложения?
  2. В каких сценариях ThreadLocal с ростом нагрузки может привести к утечке памяти, и как ScopedValue может быть эффективнее в таких случаях, несмотря на то, что он не поддерживает изменяемые состояния?
  3. Какова сложность и границы применимости метода тестирования с Semaphore для определения реального потолка параллелизма в системе, если он использует sleep вместо реальных запросов к базе данных?

Закрыл вкладку — ушёл, обновил страницу — остался: присутствие в комнате на WebSocket

Открыть оригинал ↗ Перевод заголовка: Закрыл вкладку — ушёл, обновил страницу — остался: присутствие в комнате на WebSocket

В приложении с реальным временем присутствия участников, как в Planning Poker, сервер получает одинаковое событие «соединение закрылось» при любом выходе из браузера — закрытии вкладки, обновлении страницы, потере интернета или свёртке браузера. Важно, чтобы поведение было разным: при закрытии вкладки участник исчезал мгновенно, а при обновлении — оставался с голосом. Решение строится на разделении двух понятий: «ушёл из-за стола» и «ушёл из комнаты», с использованием маркера закрытия по событию pagehide, атомарных операций в MongoDB и корректного порядка обработки сообщений в Spring.

  1. Присутствие отслеживается через STOMP-сессии: при входе в комнату сохраняется ID сессии, а при её закрытии — проверяется, было ли отправлено событие page-closed, чтобы отличить намеренный выход от обрыва связи.
  2. Для предотвращения "призраков" при обновлении страницы клиент после переподключения отправляет событие return, которое возвращает участника и голос, если он не ушёл из-за стола.
  3. Пульс соединения переносится в Web Worker, чтобы избежать прерывания при фоновых вкладках, и настраивается под разные сценарии (от 3 до 19 секунд).
  4. В Firefox при закрытии вкладки скрипт может быть прерван, что приводит к потере маркера page-closed, поэтому используются два обработчика события pagehide — один на capture, другой на bubble — для надёжной доставки.
  5. Система учитывает, что обновление страницы — это не выход, и возвращает участника с голосом, в то время как при закрытии вкладки — удаляется мгновенно, с последующим удалением из комнаты через 10 секунд.

Когда пригодится

Материал полезен при разработке веб-приложений с реальным присутствием участников, где важно точно определить, кто ушёл и кто вернулся, особенно при работе с браузерными событиями и нестабильными соединениями.

Вопросы для размышления

  1. Как изменится поведение при переходе с stompjs на @stomp/stompjs, особенно в контексте автоматического пульса в Web Worker и хуков перед подключением?
  2. В каких условиях гонка на возврате участника может привести к дублированию события в UI, и как это можно предотвратить без введения дополнительных состояний?
  3. Какова сложность реализации порядка обработки кадров в Spring при высокой нагрузке и большом количестве одновременных соединений, и как это влияет на производительность и отказоустойчивость?

Java67

10 Advanced C++ (CPP) Books for Experienced Developers - Must Read

Открыть оригинал ↗ Перевод заголовка: 10 продвинутых книг на C++ для опытных разработчиков — обязательные к чтению

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

  1. Effective C++ Скотта Мейера — сборник 50+ практических правил, ориентированных на разработчиков из Java, с объяснением причин их применения.
  2. C++ Concurrency in Action Антони Уиллиамс — подробное руководство по многопоточности в C++, охватывает C++11–17, включая модели памяти и синхронизацию.
  3. Effective Modern C++ — переход от C++03 к современным стандартам (C++11/14), с акцентом на безопасность и эффективность кода.
  4. More Effective C++ — расширение правил из первых книг, с более глубоким анализом практик.
  5. Exceptional C++ и More Exceptional C++ — фокус на управлении ресурсами, обработке исключений и проектировании классов.
  6. Beyond the C++ Standard Library: An Introduction to Boost — введение в популярную библиотеку Boost, с объяснением её ценности и использования.
  7. Modern C++ Design и C++ Template Metaprogramming — книги по продвинутым техникам шаблонов и генерической программирования, важные для высокопроизводительных и гибких решений.

Когда пригодится

Материал полезен для разработчиков, стремящихся перейти от базового уровня к экспертизе в C++, особенно в областях, где важны производительность, безопасность и масштабируемость кода — например, в системном программировании, разработке ПО с высокой нагрузкой или в проектах с использованием многопоточности и шаблонов.

Вопросы для размышления

  1. В каких случаях использование шаблонов в C++ может привести к ухудшению производительности или сложности компиляции, и как это можно оценить при проектировании системы?
  2. Какой компромисс между безопасностью ресурсов и производительностью в C++ реализуется при использовании RAII и exception safety, и в каких сценариях это может привести к неожиданным поведениям?
  3. В каких реальных проектах (например, в embedded или системном ПО) наиболее оправдано применение Boost и метапрограммирования, и как это влияет на масштабируемость и поддержку кода?

Javarevisited Newsletter

Why synchronized and Threads Aren’t Enough for HFT in Java?

Открыть оригинал ↗ Перевод заголовка: Почему синхронизация и потоки недостаточны для высокоскоростной торговли в Java?

Стандартные механизмы Java, такие как synchronized, volatile и потоки, создают значительные задержки в условиях высокой частоты торгов, где задержки измеряются в наносекундах. Основные проблемы — это переключение контекста, затраты на синхронизацию из-за работы кэш-протоколов и накладные расходы на сборку мусора из-за объектов, создаваемых в потоках.

  1. Контекстное переключение в многопоточной среде (1–3 мкс) становится критичным для систем, где задержка должна быть меньше 500 нс.
  2. Использование volatile или synchronized вызывает синхронизацию на уровне кэша (MESI), что приводит к блокировке инструкционного потока и замедлению выполнения.
  3. Объекты, создаваемые в очередях (например, LinkedBlockingQueue), активируют сборку мусора, что в условиях миллиона событий в секунду может привести к потерям в миллионах долларов.
  4. В HFT применяются архитектуры с однопоточным выполнением и фиксацией потока на физическом ядре (CPU pinning), что исключает переключение и уменьшает задержки.
  5. Используются нулевые аллокации и безблокирующие кольцевые буферы (например, LMAX Disruptor), которые избегают создания объектов и кэширования в JVM.

Когда пригодится

Материал полезен для разработчиков, работающих над системами с низкой задержкой, например, в HFT, квантовой финансовой инфраструктуре или системах обработки потоков данных в реальном времени.

Вопросы для размышления

  1. Какой компромисс между производительностью и гибкостью возникает при использовании однопоточного подхода с CPU pinning, и в каких сценариях это может привести к отказу?
  2. В каких условиях (например, при росте нагрузки или волатильности) кэш-инвалидация через volatile может превысить задержку, допустимую в HFT-системах, и как это влияет на отказоустойчивость?
  3. Какова сложность реализации безаллокационного кольцевого буфера по сравнению с традиционными очередями, и в каких случаях это делает его неприменимым для реальных систем?

System Design

AWS Architecture Blog

Stopping business email compromise with AI-driven email security: How VIPRE protects modern enterprises on AWS

Открыть оригинал ↗ Перевод заголовка: Остановка бизнес-уязвимостей в электронной почте с помощью AI-безопасности: как VIPRE защищает современные предприятия на AWS

Предприятия, сталкивающиеся с продвинутыми попытками имитации в электронной почте, которые превышают традиционные средства защиты, нуждаются в передовых решениях против бизнес-уязвимостей (BEC). В статье описывается, как VIPRE использует искусственный интеллект в своей системе безопасности электронной почты, развернутой на AWS, для защиты корпоративных сред. Решение идентифицирует и блокирует такие атаки до их доставки конечным пользователям, интегрируясь напрямую с Microsoft 365.

Практические тезисы:

  1. Использование многоуровневого ML-анализа позволяет выявлять тонкие признаки подделки, такие как манипулятивные фразы, срочность и несоответствия подписей.
  2. Облачная архитектура на AWS обеспечивает масштабируемость, низкую задержку и отказоустойчивость, что критично при обработке миллионов писем в день.
  3. Решение работает без изменений MX-записей, что позволяет внедрять его без нарушения текущих потоков почты.
  4. Система поддерживает реальное время анализа, автоматическое изоляцию и возможность быстрого возврата сообщений пользователям.
  5. Интеграция с Microsoft 365 и API-доступ позволяет быстро настраивать защиту и получать детальную аналитику по угрозам.

Когда пригодится

Материал особенно полезен для крупных корпораций, использующих Microsoft 365 и сталкивающихся с угрозами BEC, где требуется высокая точность, низкая задержка и минимальное вмешательство в рабочие процессы.

Вопросы для размышления

  1. Как изменится эффективность детекции BEC при снижении мощности GPU-вычислений в ML-моделях, если не использовать NVIDIA-платформу?
  2. В каких условиях может снизиться надежность защиты из-за несогласованности между глобальными и локальными контекстами (например, при работе с разными отделами в разных регионах)?
  3. Какова вероятность пропуска угрозы при использовании только статического анализа, если включить только базовые правила и отключить динамическое поведенческое моделирование?

Bulk Executor for Amazon DynamoDB, Part 2: Lessons we learned the hard way

Открыть оригинал ↗ Перевод заголовка: Булковый исполнитель для Amazon DynamoDB, часть 2: Уроки, которые мы узнали на практике

Разработка Булкового исполнителя для DynamoDB прошла через множество нюансов: от выбора архитектуры до реализации отказоустойчивых механизмов работы с ошибками и стоимостью. Основные решения включают использование AWS Glue для параллельной обработки, встроенные средства оценки затрат и специальные подходы к управлению ошибками и прерыванием выполнения. Ключевые практики — это работа с прямым доступом к DynamoDB для команд, требующих точности типов данных, встроенные механизмы ограничения скорости запросов и динамическая оценка стоимости. Также реализованы решения для предотвращения потери данных (PITR), контроля за выводом в реальном времени и автоматического обнаружения проблем в конфигурации.

Когда пригодится

Материал полезен при разработке инструментов массовой обработки данных в DynamoDB, где важны скорость, надёжность, контроль затрат и возможность прерывания выполнения — например, при массовом удалении старых записей, сравнении таблиц или генерации тестовых данных.

Вопросы для размышления

  1. В каких условиях использование прямого доступа к DynamoDB (вместо Spark DataFrame) становится критически важным, и как это влияет на типы данных и производительность?
  2. Какой компромисс между точностью оценки затрат и реальными расходами возникает при использовании эмпирических коэффициентов (например, 2/3 от цен на on-demand), и как это может изменяться при росте размера таблицы?
  3. В каких сценариях динамическое ограничение скорости запросов (rate limiting) может привести к непредсказуемым сбоям, и как это влияет на выбор параметров — например, при работе с таблицами с высокой нагрузкой?

DEV System Design

Of Software and Systems : Scaling and it's costs

Открыть оригинал ↗ Перевод заголовка: О программном обеспечении и системах: масштабирование и его стоимость

Масштабирование приложения от одного сервера к распределённой системе похоже на переход из студии в переполненный дом — теперь все используют кухню, и без координации кто-то просто поставит продукты на твои. При работе с одним экземпляром приложения (например, на C# или Python) операции записи в базу, кэширование и фоновые задачи предсказуемы, но при горизонтальном масштабировании (2, 3 или 50 экземпляров) память начинает лгать: данные, которые один экземпляр считает актуальными, уже изменились другим. Без подготовки возникают конфликты, дублирование платежей и коррупция данных.

Практические тезисы:

  1. Для предотвращения дублирования записей в базе используйте атомарные операции (например, ExecuteUpdate в .NET или F() в Django), которые напрямую обновляют данные в БД без загрузки в память.
  2. Для борьбы с дублированием событий применяйте паттерн «идемпотентного потребителя»: вводите уникальный идентификатор заказа (например, Order 12345) и храните его в «инбоксе» — базе данных или кэше, чтобы избежать повторной обработки.
  3. Заменяйте локальные блокировки (например, семафоры в памяти) на распределённые механизмы (например, Redis) или паттерн «выбора лидера» — чтобы избежать сбоев при отсутствии координации между экземплярами.
  4. Для обеспечения правильного порядка событий используйте сессии (например, в Azure Service Bus) или версионирование событий — чтобы система могла отклонять устаревшие или несоответствующие по времени события.

Когда пригодится

Материал полезен при проектировании распределённых систем, где критичны корректность данных, порядок обработки и отказоустойчивость — например, в финансовых сервисах, доставке заказов или системах с высокой нагрузкой и рисками дублирования.

Вопросы для размышления

  1. В каких сценариях паттерн «инбокс» может привести к перегрузке одного потребителя, и как это можно избежать без снижения надёжности?
  2. Какой компромисс между производительностью и безопасностью в паттерне версионирования событий, если система должна обрабатывать 50 000 событий с разными версиями, и как это влияет на согласованность данных?
  3. При каких условиях распределённые блокировки (например, через Redis) становятся менее надёжными, чем паттерн «выбора лидера», и как это влияет на масштабируемость при росте числа экземпляров?

Every design round asked me about caching. Few of them asked directly.

Открыть оригинал ↗ Перевод заголовка: В каждом раунде проектирования меня спрашивали о кэшировании. Немногие задавали это прямо.

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

  1. Уточните, что именно кэшируется — с какой точностью (например, по пользователю, по ключу, по сессии), и почему именно это.
  2. Опишите механизм заполнения кэша: кэш-в-сторону (cache aside), чтение через кэш (read-through) или запись в кэш (write-through).
  3. Укажите, как кэш устаревает: через время жизни (TTL), явную инвалидацию или комбинацию.
  4. Объясните возможные сбои: «стампид» (столкновение запросов), «горячие ключи», давление на память и как это может повлиять на производительность.

Важно говорить о допустимой устаревшей информации — например, описание продукта может быть старым на минуты, а баланс в банке — нет. Это показывает, что вы понимаете, что точность — не просто «по умолчанию», а критерий принятия решений. Проверьте, как кэш работает на практике: укажите метрики — коэффициент попадания, задержка на 95-м перцентиле, нагрузка на базу данных — и что вы бы сделали, если они показали низкие значения.

Когда пригодится

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

Вопросы для размышления

  1. Какой допустимый порог устаревания данных вы бы выбрали для системы, где пользователь может принимать решения на основе показателей, и почему?
  2. В каких условиях «стампид» может стать критичным, и как можно изменить архитектуру кэша, чтобы избежать этого без значительного увеличения сложности?
  3. Какой из вариантов эвакуации (LRU, TTL, кастомная политика) лучше подходит для системы с высокой частотой обновлений и низкой нагрузкой на кэш, и как это влияет на общую стабильность?

Reading DDIA, Day 1: Data Systems, Reliability, and Why a Fault Isn't a Failure

Открыть оригинал ↗ Перевод заголовка: Чтение DDIA, день 1: данные системы, надёжность и почему сбой не является сбоем

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

  1. Надёжность системы определяется не отсутствием сбоев, а способностью сохранять корректность работы при возникновении сбоев в отдельных компонентах.
  2. Различие между сбоем (fault) и сбоем (failure) критично: сбой — это отклонение от спецификации, а failure — это потеря сервиса для пользователя.
  3. Сбои могут быть как аппаратными (например, сбой диска), так и программными (например, баг в ядре ОС), и могут распространяться через каскадные сбои.
  4. Системы должны быть спроектированы с учётом предсказуемых сбоев, включая отказы зависимостей и ресурсов.
  5. Ключевые вопросы при проектировании: как сохранить целостность данных, как поддерживать производительность при деградации и как обеспечить масштабируемость.

Когда пригодится

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

Вопросы для размышления

  1. Как оценить влияние каскадных сбоев на систему при разработке с учётом масштаба и плотности взаимодействий между компонентами?
  2. В каких условиях использование Redis как хранилища данных и очереди сообщений может привести к противоречиям между надёжностью и производительностью?
  3. Какие метрики и тесты помогут выявить сбои на ранних стадиях разработки, особенно в случае программных ошибок, не проявляющихся в тестовых условиях?

Designing an Industrial AIoT Pipeline: From Sensor Data to Verified Action

Открыть оригинал ↗ Перевод заголовка: Проектирование промышленной индустриальной системы AIoT: от сенсорных данных до проверенных действий

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

  1. Идентификация физического актива должна включать стабильные идентификаторы и метаданные (тип оборудования, состояние, местоположение, калибровка), чтобы избежать ошибок интерпретации данных.
  2. Валидация сенсорных данных должна выявлять отсутствующие, шумные или вне диапазона измерения значения, и возвращать флаги качества, а не заменять пропуски или интерпретировать аномалии как реальные события.
  3. Архитектура должна разделить функции по слоям — от сенсоров до приложений — с учётом задержек, отказов и безопасности, чтобы обеспечить гибкость и отказоустойчивость.
  4. Выход AI должен быть только одним из входов в принятие решения, с учётом бизнес-правил, доступа и ограничений, а не автоматически трактоваться как команда.
  5. Интерфейс действий должен включать авторизацию, проверку физического состояния, логирование и механизм подтверждения результата, чтобы избежать непредвиденных последствий.

Когда пригодится

Материал полезен при проектировании систем, где сенсорные данные напрямую влияют на физические процессы — например, в промышленной автоматизации, управлении инфраструктурой или мониторинге оборудования с высоким уровнем риска.

Вопросы для размышления

  1. Какие критерии и границы применимости валидации данных должны быть учтены при работе с динамически меняющимися сенсорами и калибровкой?
  2. В каких условиях и на каких этапах может быть оправдана интеграция AI-рекомендаций с ручными проверками оператора, и как это влияет на общую производительность системы?
  3. Какие метрики и временные рамки должны быть использованы для оценки эффективности закрытого цикла «решение → действие → подтверждение» в условиях высокой вариабельности физического процесса?

Designing Contextual Learning Recommendations for Language Learners

Открыть оригинал ↗ Перевод заголовка: Проектирование контекстуальных рекомендаций по изучению языка для носителей

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

  • Учебная единица должна быть минимально структурирована: иметь ясную ситуацию, цель и последствия, а не просто кадр из фильма.
  • Сложность оценивается не по частоте слов, а по совокупности факторов: темп речи, акцент, фон, идиомы, культурный контекст — и подвергается постоянной корректировке на основе поведения пользователей.
  • Задания строятся не на формальном вопросе, а на достижении конкретного навыка: распознавание намерений, использование выражений в новых контекстах, репродукция произношения.
  • Автоматизация используется как предложение, а не как окончательное решение: все автоматически сгенерированные элементы проходят ревью человеком.
  • Рекомендации должны быть объяснены простыми словами и позволять преподавателю отклонять или корректировать их, особенно при недостатке данных.
  • Важно не просто показывать контент, а создавать собственные примеры, чтобы избежать нарушений прав и излишнего использования защищённого материала.

Когда пригодится

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

Вопросы для размышления

  1. Какие конкретные критерии и границы следует использовать для оценки сложности сцены, чтобы избежать искажения оценки по CEFR при наличии разнообразных фоновых и акцентных факторов?
  2. В каких условиях автоматизированная генерация заданий может быть безопасно доверена без человеческого ревью, и как это влияет на качество и надёжность обучения?
  3. Какие метрики обучения (а не просто активности) наиболее точно отражают усвоение навыков, и как их можно адаптировать под разные уровни и типы пользователей?

Microservices questions are really questions about failure

Открыть оригинал ↗ Перевод заголовка: Вопросы по микросервисам на самом деле — это вопросы о сбоях

Вопросы по архитектуре микросервисов не о том, как разделить сервисы по названиям, а о том, что произойдёт, если один из них остановится. Ключевым критерием является реакция системы на частичные сбои — например, если сервис отправки email выходит из строя, как пользователь видит результат, и как система восстанавливается.

Практические тезисы:

  1. Ограничивайте сервисы по владению данными, а не по логическим названиям — если два сервиса пишут в одну таблицу, граница неправильна.
  2. Используйте асинхронные вызовы для операций, которые не требуют немедленного ответа от пользователя — это снижает риск сбоев в цепочке.
  3. Все операции, которые могут быть повторены, должны быть идемпотентными — повторный вызов не должен приводить к дублированию данных.
  4. Готовность признать, что монолит может быть лучше в определённых случаях, — это сильный сигнал в интервью, чем утверждение о "непреодолимости" микросервисов.
  5. Внедряйте механизмы, такие как срабатывание цепи (circuit breaker), с задержкой (backoff with jitter) и компенсационные действия (saga), чтобы уменьшить влияние сбоев на пользовательский опыт.

Когда пригодится

Материал особенно полезен при подготовке к интервью по системному дизайну, где оценивают не только структуру, но и реакцию системы на сбои.

Вопросы для размышления

  1. Как определить, когда асинхронный вызов является правильным выбором, если пользователь должен получить ответ в течение 1 секунды?
  2. В каких условиях идемпотентность может быть нарушена, и как это может повлиять на надёжность системы при масштабировании?
  3. При каких границах владения данными и каких сценариях сбоев сага может стать неэффективной или сложной для реализации?

Habr Distributed Systems

Бюджет 999: как в Авито считают надёжность и почему не копируют модель Google

Открыть оригинал ↗ Перевод заголовка: Бюджет 999: как в Авито считают надёжность и почему не копируют модель Google

В статье рассказывается о том, как компания Авито адаптирует модель надёжности, описанную в книге Google SRE, под свои специфические условия: тысячи сервисов, разные продукты, отсутствие юридических SLA с пользователями и динамичная операционная среда. Вместо прямого копирования SRE-модели, Авито вводит модификации — скользящее окно измерений, мягкое управление релизами при превышении бюджета ошибок и систему критичности сценариев вместо прямого выставления SLO. Ключевыми инструментами становятся NFR (нефункциональные требования), определяемые разработчиками, и кастомные метрики для операций вне API и шин данных.

  • Вместо фиксированного квартального периода используется скользящее окно в 14 дней, что делает систему более отзывчивой и устойчивой к резким сбоям.
  • При превышении бюджета ошибок релизы не блокируются — это предотвращает саботаж и сохраняет гибкость в разработке.
  • SLO не выставляется напрямую продукт-менеджером, а определяется через критичность сценариев, что делает процесс более понятным и менее подверженным ошибкам.
  • Технические пороги NFR разрабатываются инженерами, что обеспечивает точность и соответствие реальным характеристикам систем.
  • Отсутствуют юридические SLA с пользователями — система работает как внутренний инструмент управления, а не как контрактный механизм.

Когда пригодится

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

Вопросы для размышления

  1. Какой компромисс между скоростью релизов и надёжностью может возникнуть при использовании мягкого режима на превышение бюджета ошибок, и как это может повлиять на качество фич, вводимых в продакшн?
  2. В каких условиях критичность сценария может стать неэффективным инструментом, если бизнес-сценарии не коррелируют с техническими метриками?
  3. Какова сложность и масштабируемость реализации кастомных NFR для операций вне API и шин данных при росте количества микросервисов и автоматизированных процессов?

InfoQ Architecture

Presentation: How Eve Online Leverages Head Based Sampling to Observe "Fun"

Открыть оригинал ↗ Перевод заголовка: Презентация: Как EVE Online использует выборку на основе «головы» для наблюдения за «удовольствием»

В EVE Online, 20-летнем многопользовательском онлайн-игровом проекте, реализуется наблюдаемость через полностью базирующуюся на «голове» (head-based) выборку, что позволяет избежать перегрузки системы и сохранить высокую точность в отслеживании событий без вмешательства в производительность. В отличие от традиционных систем, где отслеживаются действия отдельных пользователей, EVE Online фокусируется на состоянии всей виртуальной вселенной — в реальном времени, с участием тысяч игроков, что требует масштабных решений для сбора и анализа данных.

Практические тезисы:

  1. Вместо выборки по хвосту (tail-based), EVE Online использует выборку на основе «головы» — только первые события в потоке, что исключает необходимость передачи всех данных в центральный бэкенд и не нарушает симуляцию.
  2. Для новых сервисов в архитектуре Quasar применяется динамическая выборка на основе экспоненциального среднего (EMA), которая автоматически снижает частоту сбора данных для редких или стабильных событий (например, изменений цвета корабля), увеличивая эффективность.
  3. В системе реализованы компромиссы: отсутствие отслеживания доставки уведомлений («best effort»), объединение запросов и ответов в один трейс, что сокращает объём данных вдвое.
  4. Выборка на основе EMA работает на основе ключевого пространства (key space), где редкие события получают более высокую вероятность выборки, а частые — уменьшаются.
  5. Архитектура поддерживает масштабность, несмотря на устаревшие компоненты (например, Python на одном логическом процессоре), за счёт отказа от сложных механизмов и фокуса на простоте и стабильности.

Когда пригодится

Материал полезен в случаях, когда система имеет высокую нагрузку, виртуальную природу взаимодействий (например, многопользовательские игры, финансовые системы с синхронизацией), где важны как масштаб, так и реальное восприятие игроков — в таких системах выборка на основе «головы» и EMA позволяют сохранять производительность и не терять смысл данных о «удовольствии» от пользователей.

Вопросы для размышления

  1. В каких сценариях выборка на основе EMA может привести к упущению критически важных исключений, если система не имеет достаточной динамической адаптации к резким изменениям в ключевом пространстве?
  2. Какова граница применимости head-based sampling в системах, где требуется отслеживание всех событий в цепочке (например, в финансовых транзакциях), и как это может повлиять на надёжность и согласованность данных?
  3. При каких условиях динамическая выборка в Quasar может быть более эффективной, чем детерминированная, и как это влияет на баланс между производительностью и детализацией в реальном времени?

Coding / Algorithms

Habr Algorithms

Algorithm Judge: как проблемы с доступностью Stepik подтолкнули меня к созданию собственной системы проверки алгоритмов

Открыть оригинал ↗ Перевод заголовка: Algorithm Judge: как проблемы с доступностью Stepik подтолкнули меня к созданию собственной системы проверки алгоритмов

Автор столкнулся с недоступностью Stepik после инцидента в инфраструктуре Яндекса, что заставило его разработать локальную систему автоматической проверки решений. Вместо простого сравнения вывода с эталонными ответами, он внедрил генерацию тестов, проверку математических свойств результатов и детальную диагностику ошибок. Приложение поддерживает Python и R, работает локально и не требует интернет-подключения, что делает его надёжным инструментом для преподавателей.

  1. Система генерирует входные данные автоматически с учётом специфики задачи — например, графы с изолированными вершинами, альтернативными маршрутами или циклами — что позволяет проверять граничные и редкие случаи без ручного подготовления тестов.
  2. Вместо прямого сравнения строк проверяется семантическая корректность результата — например, для топологической сортировки учитывается порядок зависимостей, а не только наличие вершин в правильной последовательности.
  3. При ошибке система предоставляет полный трек: входные данные, ожидаемый и фактический вывод, что позволяет преподавателю быстро выявить и объяснить ошибку без анализа исходного кода.
  4. Проверка проводится в отдельных процессах с ограничениями времени, что снижает риск сбоев, хотя не обеспечивает полной изоляции от вредоносного кода.
  5. Приложение разрабатывается на Python с использованием PySide6 и PyInstaller, обеспечивая сборку для macOS и Windows в виде автономных файлов без зависимости от внешних интерпретаторов.

Когда пригодится

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

Вопросы для размышления

  1. Какие риски связаны с использованием собственных интерпретаторов Python и R в локальной среде, если в будущем студенты начнут использовать вредоносные или нестандартные библиотеки?
  2. В каких случаях семантическая проверка может привести к ложному принятию решения, если в условии не указано явное требование к формату вывода или лексикографическому порядку?
  3. Какова оценка производительности алгоритмов при использовании генераторов тестов с большими графами — может ли это привести к перегрузке системы или неправильной оценке времени выполнения?