Инженерный дайджест — 2026-10-08

Risk Management

BIS Financial Stability Institute

Chasing El Dorado: gold under shifting geopolitical and financial conditions

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

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

1. Золото как «безопасный актив» растёт в цене при росте геополитических рисков, особенно при слабых финансовых условиях.
2. Основной механизм — это риск кредитов и ликвидности: при слабых условиях инвесторы могут легко перейти на золото, если у них есть возможность перебалансировать портфель.
3. Эффект ослабевает при жёстких финансовых условиях, когда инвесторы не могут легко переключаться на золото.
4. В периоды совпадения мягких финансовых условий и геополитической напряжённости (2024–2026) эффект на золото достигает максимума.
5. Разделение геополитических шоков (угроз и реальных событий) позволяет лучше понять, как именно риски влияют на рынок золота.

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

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

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

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

Bank of England Prudential Regulation

CP13/26 – The Prudential Regulation Authority’s automatic thresholds indexation framework

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

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

1. Пороги будут автоматически обновляться каждые пять лет на основе номинального роста ВВП Великобритании, начиная с 1 июля 2031 года.
2. Механизм обеспечивает системность и предсказуемость, что упрощает планирование бизнеса и снижает необходимость в частых отдельных регуляторных обновлениях.
3. Пороги, связанные с размерами, активами или рисками, могут быть пересмотрены, чтобы избежать «скальп-эффектов» и неравномерного увеличения нагрузки на растущие компании.
4. Несмотря на то, что PRA оставляет право на периодические проверки, автоматическая индексация не заменяет оценку рисков и не устраняет необходимость в ручных проверках.
5. Учет не всех порогов в рамках механизма подразумевает, что некоторые из них могут быть исключены, что требует анализа по конкретным сценариям.

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

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

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

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

arXiv Quantitative Finance - Risk Management

Recursive Copula Aggregation for Market and Credit Portfolios

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

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

• Иерархическая структура копул позволяет моделировать сложные взаимосвязи между рисками на разных уровнях агрегации.
• Рекурсивное перестановка рангов обеспечивает прозрачное и вычислительно эффективное распространение зависимости.
• Калибровка с использованием Kendalls tau даёт устойчивую и интерпретируемую оценку зависимости на основе реальных данных.
• Учёт хвостовой зависимости (tail dependence) критичен для корректной оценки рисков в условиях стресса.

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

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

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

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

Agentic AI Systems and Financial Stability, From Model Risk to Systemic Risk

Открыть оригинал ↗ Перевод заголовка: Агентные ИИ-системы и финансовая стабильность: от риска моделей до системного риска

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

1. Риск агентных ИИ-систем не может быть диверсифицирован — даже при росте числа пользователей, общая уязвимость сохраняется из-за общей базовой модели.
2. Существует порог перекрытия (percolation threshold), при превышении которого ошибка в одной системе может вызвать каскадные сбои в других.
3. Детекция и контроль ошибок в реальном времени невозможны при наличии необратимых действий, что делает раннюю диагностику и реакцию нарушаемыми.
4. Системный риск растёт пропорционально "достижимости" системы (systemic reach), что означает, что чем больше институтов зависит от ИИ, тем выше угроза.
5. Только проактивные структурные меры (например, ограничения на доступ к ИИ-моделям) могут предотвратить рост системного риска — реактивные подходы неэффективны.

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

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

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

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

Explicit Finite-Sum Tail Risk Measures for Hierarchical Market--Credit Copula Aggregation

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

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

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

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

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

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

Optimal Transport for Actuarial Science

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

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

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

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

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

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

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

Approximate Design-Based Intervals for Downsampled Cross-Sectional Market Aggregates: A Randomized Design for Bandwidth-Constrained Financial Data Pipelines

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

Финансовые институты часто сокращают объём панелей опционов для снижения пропускной способности и затрат. Традиционный подход — выбор топ-$k$ по объёму открытых интересов — не даёт оценки ошибки агрегации, что делает рисковые метрики непроверяемыми. Авторы показывают, что для детерминированных правил, не зависящих от результата, целевая статистика не идентифицируется без дополнительных ограничений, и предлагают использовать случайный выбор с вероятностями пропорциональными объёму открытого интереса, в сочетании с оценщиком Хейкса и линеаризованным оценщиком дисперсии, чтобы получить приближённые интервалы вокруг каждого агрегата. Эксперименты на 80 сессиях торгов в США и 83 в Гонконге показывают, что метод снижает среднюю абсолютную ошибку на 35%, а интервалы при случайном выборе значительно узче, чем у топ-$k$, особенно при наличии оценок границ.

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

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

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

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

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

Equivalent Behavioural Martingale Measure

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

Статья предлагает формализацию поведенческой теории ценообразования в рамках непрерывного времени, где мера, основанная на предпочтениях и межвременной устойчивости, становится эквивалентной мартингальной мерой только после компенсации дрейфа, вызванного риск-аверсией и осторожностью. Авторы показывают, что поведенческая плотность вероятности генерируется через броуновский ядро $-A_t\sigma_t$, где $A_t$ — коэффициент Арроя-Прайта, а $\sigma_t$ — волатильность состояния, и что для получения истинного мартингала необходимо исключить конечнозначный компонент дрейфа. В рамках этой структуры сохраняется равенство опционов (put-call parity), а также появляется идентичность рискового премиума, связывающая премии опционов и базового актива через волатильность. Эмпирически модель показывает лучшую производительность по критерию ошибки при арбитраже по сравнению с SVI, но результаты на уровне срезов остаются неоднозначными.

• Поведенческая плотность становится мартингалом только после компенсации дрейфа, связанного с риск-аверсией и пруденцией.
• Мера генерируется через броуновское ядро $-A_t\sigma_t$, что позволяет связать предпочтения инвесторов с динамикой цен.
• Модель сохраняет put-call parity и даёт явную связь между премиями опционов и волатильностью через Cox–Ross-идентичность.
• Эмпирические результаты показывают, что EBMM превосходит SVI по общей ошибке, но не устойчива на уровне срезов.
• EBMM лучше рассматривается как тест адмиссивности плотности, а не как замена оценки волатильности.

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

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

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

1. Какова граница применимости EBMM при наличии сильных асимметрий в предпочтениях инвесторов, не описываемых через Arrow–Pratt?
2. В каких условиях компенсатор $-A_t\sigma_t$ может привести к неустойчивости модели при высокой волатильности или нелинейных динамиках?
3. Какой альтернативный подход к оценке волатильности может быть интегрирован с EBMM для улучшения стабильности и масштабируемости?

Two-Regime Risk Measures under Convex Loss

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

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

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

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

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

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

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

Conditional value-at-risk under reward-penalty mechanism with applications to robust portfolio management

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

В статье предлагается новый подход к оптимизации портфелей, включающий механизм вознаграждения и штрафа для управления рисками. Авторы разрабатывают модели, которые минимизируют усреднённый худший сценарий потерь (CVaR) при неопределённой совместной распределённости рисков активов, что делает подход устойчивым к неопределённости. Важно, что полученная формула для усреднённого худшего CVaR имеет явное аналитическое выражение и обобщает ранее известные результаты в теории рисков. Модели применяются как к классическим, так и к обобщённым множествам распределений, включая те, что описаны в работе Kang et al. (2019). Эмпирические эксперименты с реальными данными показывают, что портфели по предложенной модели могут превосходить существующие, при этом подчёркивается компромисс между ожидаемым доходом и контролем худшего сценария потерь.

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

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

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

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

AI

Cloudflare Blog

Building an evidence-grounded agentic security operations harness on Cloudflare

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

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

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

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

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

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

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

Habr AI

От промпта до продакшена: бесплатные уроки октября про LLM, агентов и MLOps

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

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

1. Уроки по LLM помогают разобраться в проектировании устойчивых промптов, работе с моделями и трендами генеративного ИИ.
2. Темы по ИИ-агентам фокусируются на интеграции агентов в рабочие процессы, Tool Calling, мониторинге и автоматизации тестирования.
3. Модули по MLOps и AgentOps охватывают вопросы качества данных, drift, безопасности, наблюдаемости и автоматизации экспериментов.
4. В разделе о внедрении ИИ представлены метрики для оценки ценности и ROI, что важно для бизнес-аналитиков и руководителей.
5. Все вебинары доступны онлайн без регистрации и ориентированы на специалистов с базовым уровнем знаний в ИИ и разработке.

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

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

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

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

Страдают ли LLM от боли. Разбор нашумевшего препринта

Открыть оригинал ↗ Перевод заголовка: Страдают ли LLM от боли. Разбор нашумевшего препринта

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

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

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

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

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

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

Как сделать GeoAI-агента, который ищет пожары и отправляет к этим местам пожарные расчеты и дроны

Открыть оригинал ↗ Перевод заголовка: Как сделать GeoAI-агента, который ищет пожары и отправляет к этим местам пожарные расчеты и дроны

Проект Fire Monitor — это GeoAI-агент, который на основе спутниковых данных автоматически обнаруживает пожары, анализирует их масштаб и генерирует готовые инструкции для пожарных и дронов. Агент работает через естественный чат с пользователем, понимает его намерения и выполняет сложные геоинформационные задачи без необходимости в специализированном обучении. В основе лежит цикл ReAct (рассуждение + действие), где модель Qwen3.7-Plus выбирает из 9 доступных инструментов — от поиска пожаров до построения маршрутов и полетных заданий.

1. Агент использует сжатые текстовые сводки вместо полных GeoJSON-данных, чтобы избежать переполнения контекста и сократить токены — геометрия передаётся параллельно на фронтенд для отрисовки.
2. Внедрена система кеширования с TTL 5 минут, которая позволяет агенту сохранять промежуточные результаты и не терять контекст при многократных запросах.
3. Реализованы три практические сценария: фильтрация ложных пожаров с помощью промышленных зон, планирование полетов дронов и картирование гарей по методике USGS.
4. Добавлен инструмент execute_python, позволяющий агенту генерировать и выполнять Python-код для ГИС-анализа, защищённый четырьмя уровнями безопасности: Docker-изоляция, AST-фильтрация, блокировка магических методов и системные лимиты.
5. Архитектура основана на Django REST + PostgreSQL/PostGIS для хранения данных и React + MapLibre GL JS для визуализации, с поддержкой внешних инструментов через Model Context Protocol (MCP).

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

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

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

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

Luna Decisions в n8n для парсинга объявлений недвижимости: схема интеграции, ограничения и вопросы к сообществу

Открыть оригинал ↗ Перевод заголовка: Luna Decisions в n8n для парсинга объявлений недвижимости: схема интеграции, ограничения и вопросы к сообществу

Статья рассматривает возможность внедрения API Luna Decisions в n8n для анализа изменений цен на недвижимость, фокусируясь не на автоматизации сбора данных, а на границе между парсингом и принятием решений. Автор предлагает структурированный подход, где код отвечает за числовые проверки и валидацию, а модель — за оценку необходимости ручной проверки, не выдавая инвестиционных рекомендаций. Вместо прямого внедрения Decisions API предлагаются эксперименты с фильтрацией по критериям (например, снижение цены на 1500 у.е. или 3%), с последующим анализом ответов модели на основе заданных критериев.

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

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

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

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

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

Hugging Face Blog

One Model Family, Two Gold-Level Results: Fine-Tuning Nemotron for IOI and IMO

Открыть оригинал ↗ Перевод заголовка: Один семейство моделей, два результата на уровне золота: настройка Nemotron для IOI и IMO

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

1. Адаптация Nemotron к IOI достигается через SFT и RL, где для более слабых моделей (Nano) RL даёт дополнительный вклад, а для мощных (Ultra-CC) один эпох SFT уже превосходит базовую модель.
2. В IMO модель учится не только генерировать доказательства, но и проверять их, реагировать на критику и оценивать полноту — это достигается за счёт структурированных данных, охватывающих весь цикл доказательства.
3. Ключевым элементом является не просто настройка модели, а интеграция с циклом генерации → проверки → улучшения (generate-verify-refine), который работает в естественном языке без внешних инструментов.
4. Успешные результаты достигаются не за счёт чистого настройки или массового генерирования, а за счёт синергии между специализированной моделью и инференс-циклом, что делает подход масштабируемым.
5. Результаты подтверждают, что даже открытые модели могут достигать уровня человеческих экспертов при правильной настройке и инференс-архитектуре.

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

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

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

1. В чём заключается компромисс между масштабом модели (например, Ultra-CC) и эффективностью RL-обучения, если увеличение размера модели не приводит к линейному росту производительности?
2. Какова граница применимости "generate-verify-refine" для задач, где доказательства или решения не могут быть структурированы в естественном языке?
3. При каких условиях SFT может быть более эффективным, чем RL, и как это влияет на выбор архитектуры инференс-цикла для задач с высокой вариативностью решений?

Multimodal open d1 decision models for the edge

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

Новинки из семейства моделей d1 — d1-3B и экспериментальный d1-omni-600M — предлагают быстрые, структурированные решения на основе текста, изображений и аудио. d1-3B демонстрирует лучшую производительность среди моделей до 10 миллиардов параметров, достигая 48.57 баллов на Decision Index, и работает на устройствах с краевыми процессорами за 16–50 мс. Модель d1-omni-600M поддерживает три модальности (текст, изображения, аудио), но находится на стадии раннего тестирования.

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

• d1-3B — оптимальный выбор для задач, где требуется высокая точность и скорость на устройствах с ограниченными ресурсами.
• d1-omni-600M — подходит для сценариев, где важна минимальная вычислительная нагрузка, но требует осторожного подхода из-за стадии разработки.
• Обе модели работают в режиме «один проход», не генерируя токены, что обеспечивает низкую задержку и высокую стабильность.
• Поддержка изображений и аудио в d1-omni-600M расширяет возможности для мультимодальных задач, но без публичных тестов на визуальные и аудио-задачи.
• Важно использовать модели с trust_remote_code=True и корректно форматировать входные данные, включая структурированные вопросы и изображения.

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

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

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

1. В каких сценариях d1-omni-600M может быть предпочтительнее d1-3B, несмотря на его экспериментальный статус и отсутствие публичных валидаций на аудио-задачах?
2. Какие риски связаны с использованием d1-3B на устройствах с ограниченной памятью, если вводится много изображений или длинные состояния?
3. При каких условиях (по сложности, размеру входа, типу задачи) может превзойти d1-3B модель с меньшим количеством параметров, например, Decider 2B, и как это влияет на выбор архитектуры для краевого применения?

InfoQ Architecture

Cloudflare Uses an AI Harness to Probe and Harden Its WAF

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

Cloudflare внедрил в свою систему защиты веб-приложений (WAF) AI-модели, которые анализируют уже заблокированные атаки, генерируя и оптимизируя новые варианты атаки. В ходе эксперимента с 45 сценариями было сгенерировано 1 107 попыток, из которых 49 были признаны значимыми и внесены в правила WAF. Модели не имели доступа к внутренним правилам или коду системы, что делало тестирование «чёрным ящиком». Система использовала Python-харнесс для управления запросами, контроля состояния и сбора ответов, позволяя моделям генерировать вариации без прямого управления выполнением запросов. В одном из тестов на SSRF модель изменила формат адреса, получив в ответ перенаправление вместо блокировки, что показало важность дифференцированного подхода к интерпретации результатов. В итоге были внесены три изменения в правила WAF: два новых детектора и улучшение существующего правила по SSRF.

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

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

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

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

Presentation: The Reinvention of the Dev Team

Открыть оригинал ↗ Перевод заголовка: Перевод команды разработчиков: агенты и новая эра разработки

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

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

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

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

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

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

Latent Space

Can a Cloud-Native Harness Make Agents Reliable Beyond the Desktop?

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

Кодирующие агенты, основанные на LLM, работают по схеме циклического вызова инструментов с сохранением контекста, что вначале реализуется локально. Однако в условиях масштабных предприятий такие решения сталкиваются с проблемами управления, безопасности и масштабируемости, если они остаются на локальном ПК. Stacklok, созданный разработчиками Kubernetes, предлагает Mecatl — облачный харнесс, который разделяет агент-цикл от его выполнения и хранения состояния, позволяя вести централизованное управление как в рамках одной организации, так и между несколькими кластерами.

1. Механизм разделения агент-цикла от инструментов и выполнения позволяет избежать проблем с жизненным циклом агента и безопасностью, особенно при паузе или ожидании ввода пользователя.
2. Харнесс Mecatl не хранит сессии в виде JSONL-файлов на диске, а интегрирует их в управляемые системы, что повышает надёжность и масштабируемость.
3. Stacklok предлагает «enterprise spine» — централизованную платформу для управления политиками, аутентификацией и аудитом, что решает задачи масштабирования и регулирования в корпоративной среде.
4. В отличие от решений, выбирающих модель на основе задачи, AI Gateway фокусируется на контроле доступа, бюджетах и маршрутизации, что более безопасно и подходит для регулируемых отраслей.
5. Архитектура Mecatl и ToolHive ориентирована на инфраструктуру, а не на локальные индивидуальные решения, что делает их применимыми для крупных команд и распределённых команд.

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

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

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

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

Java / Spring

Foojay

Introducing Jenesis: You Already Wrote the Build Script

Открыть оригинал ↗ Перевод заголовка: Введение в Jenesis: Вы уже написали скрипт сборки

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

1. Jenesis использует модульный файл module-info.java как основной источник сборки, избегая отдельных конфигурационных файлов, таких как pom.xml или build.gradle.
2. Сборка происходит в рамках обычного Java-проекта: всего 2,3 МБ исходного кода запускается через JDK, без необходимости скачивать или устанавливать дополнительные инструменты.
3. Сборка автоматически определяет версии зависимостей и проверяет их целостность с помощью SHA-256-хэшей и OpenPGP-подписей, без вмешательства плагинов.
4. Все шаги сборки кэшируются по хэшу входных данных, что позволяет быстро пересобирать проект и делает результаты сборки совместимыми между машинами.
5. Каждый запуск выполняется в изолированном контейнере, не имеющем доступа к домашнему каталогу или переменным среды — обеспечивая безопасность при работе с неизвестными проектами.

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

Материал особенно полезен при разработке в среде AI-агентов или CI/CD, где требуется быстрая, безопасная и воспроизводимая сборка без дополнительных зависимостей и настройки.

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

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

Habr Java

Java Digest 40: что изменилось в Java 27 и почему Spring ускоряет релизы

Открыть оригинал ↗ Перевод заголовка: Java Digest 40: что изменилось в Java 27 и почему Spring ускоряет релизы

В выпуске описывается релиз Java 27 с ключевыми изменениями: включены по умолчанию компактные заголовки объектов и G1 как стандартный сборщик мусора, что снижает потребление памяти и улучшает производительность. Также представлены новые фичи, включая постквантовые криптографические механизмы и улучшения в структурированной конкуренции. Сбер запустил SberJDK — отечественную альтернативу OpenJDK с оптимизациями, включёнными на основе ИИ, обеспечивающими производительность на 20% выше. Spring перешёл к более быстрым релизам из-за роста AI-обнаруженных уязвимостей, что привело к сокращению цикла релизов с двух недель до одного дня. В статье подробно разбираются вопросы проектирования данных в Spring Data JDBC, а также механизмы управления конфигурацией через EnvironmentPostProcessor и внутренние процессы Kafka.

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

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

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

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

HowToDoInJava

AssertJ Tutorial: Fluent Assertions Cheat Sheet for JUnit 6

Открыть оригинал ↗ Перевод заголовка: Учебник по AssertJ: краткая таблица флюентных утверждений для JUnit 6

AssertJ — это библиотека для тестов, которая позволяет писать утверждения в виде естественного языка, начиная с вызова assertThat(actual) и последовательного добавления проверок, таких как hasSize(3) или containsExactly("apple", "banana"). При неудаче теста AssertJ показывает не только реальное значение, но и точное место отклонения, что значительно упрощает диагностику ошибок без использования отладчика. Вместо стандартных методов JUnit, таких как assertEquals() или assertTrue(), AssertJ рекомендуется использовать для проверки строк, списков, опциональных значений и исключений, и он совместим с JUnit 4, 5, 6 и TestNG.

• Вместо прямых сравнений в JUnit, AssertJ предоставляет методы, которые визуально идентифицируют позиции разницы в коллекциях (например, индексы, где элементы не совпадают).
• Для строк AssertJ предлагает проверки с игнорированием регистра, пробелов и паттернов, что делает тесты более гибкими и читаемыми.
• Для чисел с плавающей точкой используется isCloseTo() вместо isEqualTo(), чтобы избежать ошибок округления.
• В проверках коллекций важно выбирать строгость: containsExactly() требует точного порядка, containsExactlyInAnyOrder() — любое расположение, а containsOnly() игнорирует дубликаты.
• Для исключений AssertJ позволяет в одной цепочке проверить тип и сообщение, что упрощает тестирование ошибок без необходимости отдельного блока try-catch.

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

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

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

1. В каких случаях использование containsExactlyInAnyOrder() может привести к ложному прохождению теста, если исходные данные из базы не сортируются, и как это влияет на надёжность теста при изменении порядка элементов?
2. Какой компромисс между читаемостью и точностью в сообщении об ошибке возникает при использовании isCloseTo() для сравнения дробных чисел, и как это может повлиять на восприятие качества теста разработчиком?
3. При каких условиях softAssertions могут привести к упущению ошибок в production-среде, и как это может быть обнаружено при масштабировании тестов?

Spring Cloud Gateway Tutorial with Spring Boot 4 Examples

Открыть оригинал ↗ Перевод заголовка: Учебник по Spring Cloud Gateway с примерами на Spring Boot 4

Spring Cloud Gateway — это гибридный API-гейтвей, который направляет входящие HTTP-запросы на соответствующие микросервисы и выполняет фильтры для модификации запросов и ответов. Он особенно полезен, когда клиенты должны обращаться к одному адресу вместо множества сервисов, и когда задачи, такие как переписывание путей, ограничение скорости, повторные попытки и CORS, должны быть централизованы. В примере конфигурации в application.yml запросы к /api/recipes/** перенаправляются на сервис на порту 8081, при этом путь переписывается и добавляется заголовок метаданных, что позволяет скрывать внутренние пути и не изменять клиентские вызовы при переносе или разделении сервисов.

• Гейтвей использует маршруты с предикатами (например, по пути или методу) и фильтрами (например, переписывание пути или добавление заголовков), чтобы обрабатывать запросы и ответы.
• Реализация в YAML проста для быстрой настройки, в то время как Java-конфигурация позволяет добавлять сложные логики, такие как повторные попытки или срабатывание кирпича (circuit breaker).
• Встроенные фильтры, такие как Redis-лимитер, повторные попытки и кирпич, обеспечивают отказоустойчивость и безопасность без необходимости вносить изменения в каждый сервис.
• Гейтвей поддерживает два режима: WebFlux (реактивный, высокая производительность) и Web MVC (совместим с Servlet-контейнерами), что даёт выбор в зависимости от экосистемы.
• Важно понимать, что в версии 5.0+ старые ключи конфигурации устарели, и требуется проверка актуальности путей через /actuator/gateway/routes.

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

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

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

1. В каких сценариях использование WebFlux вместо Web MVC может привести к ухудшению производительности или увеличению сложности развертывания, даже при наличии виртуальных потоков?
2. Какой компромисс между безопасностью и гибкостью возникает при использовании заголовков, таких как X-User, для определения лимитера, если клиент может вводить произвольные значения?
3. При каких условиях повторные попытки (retry) могут привести к созданию дублирующих данных, и как это можно предотвратить без изменения логики сервисов?

Embabel Tutorial: Agents With Spring Boot and Ollama

Открыть оригинал ↗ Перевод заголовка: Учебник по Embabel: агенты с Spring Boot и Ollama

Embabel — это открытый фреймворк для JVM, созданный Роджером Джонсоном и построенный на Spring AI. В нём агент реализуется как Java-класс с методами, помечёнными аннотацией @Action, а планировщик на основе алгоритма GOAP автоматически определяет порядок шагов для достижения цели. Каждый шаг принимает типизированные объекты в качестве параметров и возвращает новый объект, что позволяет Embabel точно понимать, что каждый шаг требует и создаёт. Фреймворк особенно полезен, когда одна вызов LLM недостаточна, и приложение должно объединять LLM-вызовы с собственными сервисами, например, в системах сортировки поддержки или планирования поездок.

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

• Планировщик Embabel использует типы и условия для автоматического построения последовательности действий, не требуя ручного управления порядком шагов.
• Доменные объекты (Java-рекорды) определяют структуру данных, передаваемых между шагами, и генерируют JSON-схемы для LLM-вызовов.
• Агенты могут включать как LLM-вызовы (через @LlmTool), так и обычные Java-методы (например, запросы к базе данных), что обеспечивает гибкость и производительность.
• Проверка логики планирования и ветвлений возможна с помощью FakeOperationContext и EmbabelMockitoIntegrationTest, позволяя тестировать без реальных API-ключей.
• Для работы с локальными моделями (например, Ollama) достаточно запустить Docker-контейнер и настроить параметры времени ожидания, особенно при использовании моделей без GPU.

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

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

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

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

ArchUnit Tutorial: Test Java Architecture with JUnit 6

Открыть оригинал ↗ Перевод заголовка: Учебник по ArchUnit: проверка архитектуры Java с JUnit 6

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

1. Архитектурные правила проверяются на уровне зависимостей: запрет на прямой доступ контроллеров к репозиториям, ограничение на использование пакетов, запрет на инъекцию полей и нарушение слоев.
2. ArchUnit использует флюентный API, где каждое правило строится как цепочка: выбор классов → условие → причина, что делает код понятным и близким к документации команды.
3. Для проверки сложных структур (слоев, «овала») применяются специальные методы: layeredArchitecture() для горизонтальных слоёв, onionArchitecture() для архитектуры с центральной доменной частью.
4. Пакетные циклы обнаруживаются с помощью slices(), что позволяет выявлять взаимозависимости между подпакетами.
5. Для старых кодбаз используется FreezingArchRule, который фиксирует текущие нарушения и отслеживает только новые, что позволяет постепенно улучшать архитектуру без полного сбоя при запуске.

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

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

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

1. Какой компромисс между чувствительностью к нарушениям и масштабируемостью ведёт к тому, что ArchUnit может не обнаруживать циклы в глубоких вложенных пакетах, даже если они нарушают архитектуру?
2. При каких условиях использование FreezingArchRule может привести к ложному ощущению стабильности, если в проекте происходят частые изменения структуры пакетов без реальной переработки логики?
3. Какова сложность (по времени и памяти) выполнения правила layeredArchitecture() в проекте с тысячами пакетов и тысячами классов, и как это влияет на производительность CI-пайплайна?

Case-Insensitive Map in Java (TreeMap, Commons, Spring)

Открыть оригинал ↗ Перевод заголовка: Кейс-инсессивный словарь в Java (TreeMap, Apache Commons, Spring)

В Java нет встроенной структуры данных с кейс-инсессивными ключами, поэтому для реализации такого поведения используют TreeMap с компаратором String.CASE_INSENSITIVE_ORDER, либо библиотеки, такие как CaseInsensitiveMap от Apache Commons или LinkedCaseInsensitiveMap от Spring. Такие словари необходимы при работе с данными, где ключи могут быть в разных регистрах — например, в HTTP-заголовках или CSV-файлах. Каждый подход по-своему обрабатывает сохранение спеллинга ключей, порядок инициализации, поддержку null и производительность.

• TreeMap с CASE_INSENSITIVE_ORDER обеспечивает сортировку по алфавиту и игнорирует регистр, но не поддерживает null-ключи и имеет логарифмическую сложность операций.
• CaseInsensitiveMap от Apache Commons хранит ключи в нижнем регистре, поддерживает null-ключи и работает за O(1), но при выводе ключей показывает их в нижнем регистре, что может нарушать ожидания пользователей.
• LinkedCaseInsensitiveMap от Spring сохраняет исходный спеллинг и порядок вставки, но не поддерживает null-ключи и может иметь проблемы при работе с локальными настройками (например, с турецким языком).
• Ручная нормализация ключей в HashMap через toLowerCase(Locale.ROOT) сохраняет скорость поиска, но требует надёжной реализации и ведёт к риску ошибок при пропуске конверсии.

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

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

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

1. В каких сценариях использование LinkedCaseInsensitiveMap может привести к ошибке при работе с локальными настройками, например, при обработке ключей "TITLE" в турецком языке?
2. Какой из подходов наиболее безопасен при работе с большими объемами данных, где важна производительность и стабильность при наличии множества кейс-различных ключей?
3. При каких условиях нормализация ключей вручную через toLowerCase(Locale.ROOT) может быть предпочтительнее, чем использование готовых библиотек?

Gson JsonParser: Parse JSON to JsonObject and Read Values

Открыть оригинал ↗ Перевод заголовка: Gson JsonParser: Парсинг JSON в JsonObject и чтение значений

Gson JsonParser преобразует JSON-строку в дерево объектов JsonElement, где корневой элемент — JsonObject, и значения извлекаются по ключу с помощью метода get(). Для парсинга используется статический метод parseString() для строки и parseReader() для файлов или потоков. Этот инструмент подходит, когда нужно извлечь несколько полей из JSON без создания Java-класса, например, статус API-ответа или настройки из конфига. В процессе работы с JSON-данными важно проверять типы элементов, обрабатывать отсутствующие ключи и ошибки в структуре, так как прямое обращение к несуществующему ключу приводит к NullPointerException, а значение null в JSON возвращает JsonNull.

1. Используйте JsonParser.parseString() для строк и JsonParser.parseReader() для файлов или потоков — они возвращают JsonElement, который можно преобразовать в JsonObject или JsonArray.
2. Для безопасного доступа к значениям проверяйте наличие ключа с помощью has() и тип элемента с помощью isJsonNull() или isJsonPrimitive().
3. При работе с несуществующими или пустыми полями используйте вспомогательный метод с Optional, чтобы избежать исключений.
4. Валидацию JSON-строки следует проводить с помощью try-catch для JsonSyntaxException и проверки типа корневого элемента.
5. При работе с большими файлами или в условиях, где важна надежность, лучше использовать JsonReader с strictness, чтобы избежать парсинга некорректных данных.

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

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

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

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

Java UnsupportedOperationException: Causes and Fixes

Открыть оригинал ↗ Перевод заголовка: Java UnsupportedOperationException: Причины и решения

В Java исключение UnsupportedOperationException возникает, когда на объекте вызывается метод, который не поддерживается — например, добавление элемента в неизменяемый список. Оно чаще всего встречается при работе с списками, возвращаемыми методами Arrays.asList() или List.of(), поскольку такие списки неизменяемы и не позволяют вносить изменения. Основное решение — создать копию списка в модифицируемом формате, например, ArrayList, чтобы внести изменения без нарушения исходного объекта.

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

• Для списков, созданных через Arrays.asList(), можно создать копию в ArrayList, чтобы добавлять или удалять элементы.
• Списки, возвращаемые List.of(), Stream.toList() или Collections.unmodifiableList(), не поддаются изменениям — на них вызов add() или set() приведёт к исключению.
• Вместо прямого изменения неизменяемого списка, следует использовать collect с Collectors.toCollection(ArrayList::new) для получения модифицируемого результата.
• Методы, такие как Collections.sort(), могут вызывать исключение при работе с неизменяемыми списками, даже если они уже отсортированы.
• При передаче списка извне методу, важно делать копию перед изменением, чтобы не повлиять на исходный объект.

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

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

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

1. В чём разница между поведением метода add() в списке из Arrays.asList() и в списке из List.of(), и как это может привести к упущению ошибки в тестах?
2. Какой из вариантов — копирование в ArrayList или использование List.copyOf() — лучше подходит для обеспечения надёжности и предсказуемости в производственной среде, если список передаётся из внешнего модуля?
3. При каких условиях использование Collections.sort() на неизменяемом списке может быть допустимым, и как это может быть обойдено без создания копии?

Java 8 date/time type not supported by default: Jackson Fix

Открыть оригинал ↗ Перевод заголовка: Java 8 date/time type not supported by default: Jackson Fix

Ошибка «Java 8 date/time type not supported by default» в Jackson возникает, когда маппер не имеет сериализаторов для классов java.time (например, LocalDate, LocalDateTime), и это происходит при использовании стандартного конструктора ObjectMapper без дополнительных модулей. В Jackson 2.12 и новее такой сценарий приводит к исключению InvalidDefinitionException, даже если объект содержит поля типа java.time. Решение — добавить модуль jackson-datatype-jsr310 и зарегистрировать JavaTimeModule в мапперах, либо обновиться до Jackson 3, где поддержка java.time встроена.

1. Добавить зависимость jackson-datatype-jsr310 с версией, совпадающей с jackson-databind.
2. Регистрировать модуль JavaTimeModule при создании каждого ObjectMapper или JsonMapper.
3. Отключить флаг WRITE_DATES_AS_TIMESTAMPS для получения форматов в виде ISO-8601 (например, "1989-05-17").
4. В приложениях на Spring Boot и с Hibernate JSON столкновения могут возникать из-за использования отдельных мапперов, не наследующих модуль — требуется либо кастомный FormatMapper, либо корректная настройка.
5. В Jackson 3 поддержка java.time встроена, и по умолчанию даты сериализуются как текст в формате ISO, что упрощает интеграцию.

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

Материал полезен при работе с Java 8 date/time типами в приложениях на Java, использующих Jackson для сериализации/десериализации, особенно в контекстах Spring Boot, Hibernate JSON-колонок, Redis-сервера или тестов, где маппер создаётся вручную.

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

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

System Design

DEV System Design

The System Design Interview Roadmap

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

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

1. Основы системного дизайна — от протоколов до CAP-теоремы.
2. Масштабируемость — выбор между вертикальным и горизонтальным расширением, балансировкой нагрузки и шардингом баз данных.
3. Производительность — кэширование, индексация, асинхронная обработка и оптимизация запросов.
4. Надёжность — отказоустойчивость, высокая доступность, репликация данных и восстановление после сбоев.
5. Хранение данных — сравнение SQL и NoSQL, объектное хранилище, файловые системы и хранилища данных.
6. Микросервисы — понимание архитектуры, API-гейтвей, открытие сервисов и паттернов (CQRS, Saga).
7. Безопасность — аутентификация, авторизация, шифрование и работа HTTPS.
8. Мониторинг — логирование, метрики, трассировка запросов и проверки здоровья.
9. Облачные сервисы — понимание IaaS/PaaS/SaaS, контейнеризации и Kubernetes.
10. Паттерны системного дизайна — Pub/Sub, Circuit Breaker, Bulkhead и другие.

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

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

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

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

Building an Ultra-Low Latency Telemetry Pipeline for AIoT Tracking

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

Для работы с телеметрией в промышленных условиях, где каждая задержка в обработке координат может привести к потере событий (например, пропуск операций сбора), требуется архитектура, способная обрабатывать десятки тысяч точек данных в секунду с задержкой менее 100 мс. В статье представлено решение, позволяющее интегрировать данные с разных типов датчиков — UWB, BLE и RFID — на уровне края, фильтровать шум и передавать структурированные события в системы управления производством.

1. На уровне гейтвейсов используется стандартный Protobuf-схема для унификации данных от разных производителей (Decawave, Zebra и др.), что позволяет инференс-сервису работать с единым форматом, независимо от источника.
2. На краю применяется простой скользящий окно для сглаживания координат, что уменьшает влияние шума от отражений в металлических конструкциях и предотвращает ложные срабатывания геозон.
3. После сглаживания система проверяет вход/выход объекта в заданные геозоны и генерирует события, которые напрямую используются для прогнозирования потока материалов и автоматического запуска пополнения.
4. Критерии производительности включают пропускную способность не менее 10 000 пакетов в секунду, задержку обработки не более 15 мс и сокращение размера пакета на 65% за счёт Protobuf.
5. Рекомендованы технологии: EMQX или Mosquitto для брокеров, Rust/Go для микросервисов на краю, NATS JetStream или Kafka для передачи в корпоративные системы.

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

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

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

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

The industry is swinging back from default to microservices to most microservices are just distributed monoliths

Открыть оригинал ↗ Перевод заголовка: Промышленность возвращается от микросервисов к монолитам, но большинство «микросервисов» — это просто распределённые монолиты

Индустрия перестала верить в микросервисы как идеальный путь развития. Большинство систем, которые называли «микросервисами», на самом деле были распределёнными монолитами: сервисы делили одну базу данных, использовали общие библиотеки и зависели друг от друга на уровне развертывания. Архитектура отражала структуру команд, а не бизнес-границы, что приводило к нечётким границам сервисов и сложным зависимостям. Правильный путь — не в выборе между монолитом и микросервисами, а в построении модульных монолитов с жёсткими границами модулей и чёткой собственностью на код. Реальный микросервис должен иметь конкретную причину: независимую масштабируемость, разные циклы развертывания или разные SLA. Без такой причины граница — это просто организационная граница, маскирующаяся под вызов сервиса.

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

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

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

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

Kafka Interview Prep (Part 2) — When Things Break in Production

Открыть оригинал ↗ Перевод заголовка: Kafka Interview Prep (Part 2) — Когда в производстве что-то ломается

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

1. При сбое потребителя после обработки сообщения, но до подтверждения смещения, возникают дублированные обработки — это норма в режиме "at-least-once", и решением является сделать обработку идемпотентной (например, через проверку по идентификатору сообщения).
2. Рост задержки потребителя не означает необходимость добавления новых экземпляров — нужно сначала профилировать время обработки, проверить баланс нагрузки по партициям и выявить истинный бутылочный горлышко (например, медленный запрос к БД).
3. Смешивание разных типов событий (например, создание, отмена, обновление заказа) в одной теме — не рекомендуется без явного обоснования, так как нарушает порядок и масштабируемость; лучше использовать типизированные оболочки и отдельные темы для разных событий.

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

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

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

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

How RFID Hotel Lock Systems Differ From Traditional Mechanical Locks

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

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

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

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

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

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

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

Building a Real-Time Notification System at Scale: The Gandalf Approach

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

История начала начинается с того, что наша система уведомлений начала вести себя как дракон, хранящий золото. При попытке обеспечить мгновенные реакции на события (лайки, комментарии и т.п.) мы начали писать в базу PostgreSQL для каждого события, но это быстро привело к перегрузке — задержки достигали 12 секунд, а система начала выдавать ошибки. Нам нужно было сгладить всплески нагрузки без потери ощущения реального времени. Решение заключалось в создании системы, которая бы поглощала всплески, защищала бэкенд и обеспечивала быстрое доставление уведомлений. В основе лежит подход, похожий на то, как Гандальф управляет водой: вместо блокировки потока, система позволяет проходить определённое количество событий, хранит остаток и постепенно выдаёт его при уменьшении нагрузки. В реализации используется двухуровневый токен-бакет: локальный бакет в памяти для быстрых реакций на всплески, и Redis для глобального контроля скорости. Локальный бакет поглощает мелкие всплески без обращения к Redis, а при сбое Redis система продолжает работать на короткое время, предотвращая полный сбой.

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

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

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

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

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

Introduction to a General IoT Platform Architecture

Открыть оригинал ↗ Перевод заголовка: Введение в общую архитектуру платформы IoT

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

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

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

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

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

Design a rate limiter, from fixed window to token bucket

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

Стандартный лимитер на основе фиксированного окна (по минутам) позволяет превысить лимит в момент смены границы — например, 200 запросов за 2 секунды вместо 100 в минуту. Это происходит из-за того, что старые данные удаляются при переходе к новому периоду, и запросы, поступающие в моменты перед и после смены, "пропускаются" как часть одного интервала. Для точного контроля вводится "сдвигаяй лог" — история всех временных меток запросов, который фильтрует по последним 60 секундам, но требует значительного объема памяти. Альтернативой становится оценка по двум бакетам (предыдущий и текущий), где по времени распределяется предыдущий поток — это дает приближённую, но не точную оценку. Самый гибкий подход — бакет токенов: клиент получает бакет с фиксированным объёмом, где токены поступают постепенно, и запросы разрешаются только при наличии токена. Это позволяет разрешать короткие всплески (burst), не нарушая среднего роста. При распределении нагрузки между серверами лимитер должен храниться в общем хранилище (например, Redis), и для предотвращения конкуренции между операциями используется атомарное выполнение (например, Lua-скрипт). В ответе на блокировку используется статус 429 с возможностью включения заголовка Retry-After и дополнительных меток, таких как x-ratelimit-remaining.

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

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

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

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

InfoQ Architecture

Grab Redesigns Counter Service Storage for 50% Lower P99 Latency

Открыть оригинал ↗ Перевод заголовка: Grab перестроил хранилище сервиса счётчиков для снижения P99 задержки на 50%

Grab переработал архитектуру сервиса счётчиков, заменив хранилище на Aerospike и пересмотрев модель данных, что позволило сократить задержку P99 на 50%, снизить объём данных на диске с 3 ТБ до 1 ТБ и сократить стоимость на узле на 45–50%. Вместо хранения отдельных строк по временным интервалам (15 минут, час, день) сервис теперь хранит все временные метки в одном записи в виде отсортированного карта, что сокращает количество записей более чем в десять раз. Вместо серверного фильтрации по временным диапазонам, сначала данные возвращаются клиентом, а запросы группируются в батч-запросы, что уменьшает количество сетевых вызовов. Миграция прошла без перерывов и ошибок данных, благодаря использованию абстракции слоя хранения, постепенного переключения трафика и проверки паритета через шадовую ветку.

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

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

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

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

Microservices.io

Architecting for uncertainty - part 3: GenAI as an amplifier

Открыть оригинал ↗ Перевод заголовка: Архитектура для неопределённости — часть 3: Генеративная ИИ как усилитель

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

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

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

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

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

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

Coding / Algorithms

DEV Data Structures

Heap and Priority Queue Invariants: Implementing Min-Heap from Scratch and Top-K Elements

Открыть оригинал ↗ Перевод заголовка: Мин-куча и инварианты приоритетной очереди: реализация мин-кучи с нуля и задача «Топ-K» элементов

Статья объясняет, как построить мин-кучу с нуля на основе массива, используя математические формулы для взаимодействия между родителями и дочерними узлами. Основные операции — sift_up и sift_down — обеспечивают поддержку инварианта кучи, при котором каждый узел меньше или равен своим потомкам. В статье показано, как эффективно построить кучу за линейное время с помощью алгоритма heapify, и как применить её для решения задачи поиска K наибольших элементов в потоке данных, сохраняя память на уровне K.

1. Мин-куча может быть реализована в массиве без указателей, используя простые формулы индексов: левый дочерний узел — 2i+1, правый — 2i+2, родитель — (i-1)//2.
2. Операции sift_up и sift_down позволяют поддерживать инвариант кучи при вставке и извлечении элементов, с логарифмической сложностью каждой операции.
3. Алгоритм heapify строит кучу за линейное время O(N), так как большинство узлов — листья, и их проверка требует минимального количества шагов.
4. Для обработки потока данных с неизвестной длиной используется ограниченная мин-куча размера K, что обеспечивает O(N log K) время и O(K) память.
5. При обработке потока элементов куча динамически поддерживает только K наибольших значений, что делает решение масштабируемым и память-эффективным.

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

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

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

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

Heap & Priority Queue: The Sorting Hat's Secret Weapon

Открыть оригинал ↗ Перевод заголовка: Куча и приоритетная очередь: секретное оружие Шляпы-сортировщика

При работе с массивом, чтобы найти k-й по величине элемент, традиционный подход — сортировка всего массива — требует O(n log n) времени и неэффективен при больших данных. Вместо этого можно использовать мин-кучу размером k, чтобы в один проход отслеживать только наибольшие элементы, что даёт сложность O(n log k) и потребление памяти O(k). Алгоритм работает за счёт сохранения в куче ровно k наибольших значений: если новый элемент больше текущего минимального в куче, он заменяет его и восстанавливает структуру кучи. Это позволяет избежать полной сортировки и эффективно обрабатывать большие массивы при малом k.

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

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

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

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

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

How Autocomplete Search Engines Work

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

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

1. Trie хранит слова в виде дерева, где каждый узел соответствует одной букве, и позволяет искать подстроки за O(L) времени, где L — длина слова.
2. Для автозаполнения используется обход дерева в глубину (DFS), который собирает все возможные слова, начиная с заданного префикса, с ограничением по количеству результатов.
3. Добавление популярности слов в узлах (TopSuggestions) позволяет возвращать результаты по частоте, не сортируя их на каждом запросе — это ускоряет ответ.
4. Radix-дерево (сжатый Trie) объединяет последовательные узлы в один с многосимвольным ребром, что сокращает объём памяти на 70% и улучшает эффективность хранения.
5. Для поддержки высокой пропускной способности в многопоточной среде используется ReaderWriterLockSlim, позволяя одновременным чтениям и защищённым записям.

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

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

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

1. Какой компромисс между скоростью поиска и затратами памяти возникает при использовании предварительно кэшированных топ-рекомендаций, и как это влияет на частоту обновления данных?
2. В каких сценариях сжатый Trie (Radix Tree) может быть неэффективен, и как это влияет на точность поиска при наличии редких или разреженных слов?
3. При каких условиях сложность вставки в Trie может превысить O(L), и как это может повлиять на производительность при обновлении базы в реальном времени?

Java67

Review — Is Coding Interview Patterns: Nail Your Next Coding Interview by Alex Xu & Shaun Gunawardane Good for Tech Interviews?

Открыть оригинал ↗ Перевод заголовка: Оценка книги «Coding Interview Patterns: Nail Your Next Coding Interview» Алекса Ху и Шуана Гунавардэна — полезна ли она для технических интервью?

Книга «Coding Interview Patterns» является эффективным ресурсом для подготовки к техническим интервью, особенно в части алгоритмов и структур данных. Она фокусируется на ключевых паттернах, таких как два указателя, скользящее окно, хэш-таблицы и DFS/BFS, и предлагает понятные объяснения, визуализации и разнообразные задачи, что помогает избежать механического решения задач. Авторы — Алекс Ху и Шуан Гунавардан, оба с опытом в FAANG и киберпрограммировании — обеспечивают глубину и практическую применимость.

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

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

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

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

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

LeetCode.ca Solutions

4031 - Find All Numbers Disappeared in an Array II

Открыть оригинал ↗ Перевод заголовка: 4031 - Найти все отсутствующие числа в массиве II

Дан массив целых чисел и диапазон [lower, upper]. Нужно найти все целые числа в этом диапазоне, которые отсутствуют в массиве, и вернуть их как последовательности отрезков в порядке возрастания. Каждый отрезок представляет собой группу последовательных отсутствующих чисел, объединённых в минимальное количество интервалов. Алгоритм использует сортировку и уникальные значения, чтобы проходить по массиву и выявлять пропуски между соседними числами в диапазоне. При этом отслеживается предыдущее число, и если разрыв между ним и текущим превышает 1, формируется интервал. После обхода массива добавляется завершающий интервал, если последнее число ещё не достигло upper.

1. Сортируем массив и удаляем дубликаты, чтобы работать только с уникальными значениями в диапазоне.
2. Используем переменную prev для отслеживания предыдущего числа в диапазоне; при обнаружении разрыва (разность > 1) формируется интервал от prev + 1 до x - 1.
3. После завершения итерации проверяется, не остался ли отрезок после последнего найденного числа — если prev < upper, добавляется интервал от prev + 1 до upper.
4. Алгоритм работает за O(n log n) из-за сортировки, и потребляет O(log n) памяти из-за хранения отсортированного множества.
5. Подходит для больших массивов, но требует, чтобы все числа в диапазоне были в пределах [lower, upper].

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

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

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

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