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

Risk Management

BIS Financial Stability Institute

Central banks and macro financial stability in a fragmented global economy

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

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

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

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

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

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

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

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

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

ISDA

US FX Derivatives Review: Non-deliverable Forwards Take the Lead

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

Анализ торговой активности американских валютных деривативов, представленный на платформе SwapsInfo, показывает рост общей величины сделок на 27,1% — до 19,4 трлн долларов квартала 2026 года. Основной вклад в этот рост внесли несделимые фьючерсы (NDFs), чей общий несделимый объем вырос на 37,1% и достиг 10,2 трлн долларов, что сделало их долю в общей структуре валютных деривативов 52,7% — выше, чем в предыдущем периоде. Исследование охватывает не только объемы сделок, но и структуру продуктов, размеры сделок, пары валют и площадки исполнения.

Несделимые фьючерсы (NDFs) стали доминирующим продуктом в американском рынке валютных деривативов, превысив долю в 52,7% квартала 2026 года.
Рост несделимых фьючерсов (NDFs) на 37,1% превзошёл рост общего объема валютных деривативов, что указывает на устойчивый спрос на инструменты для управления валютными рисками.
Платформа SwapsInfo расширила охват до валютных деривативов, что позволяет более полно отслеживать динамику OTC-рынков.
Анализ включает детализацию по валютным парам и площадкам исполнения, что важно для оценки локальных рыночных тенденций.
Рост NDF-объемов может быть связан с ростом активности в условиях нестабильности в международных финансовых рынках.

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

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

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

В каких сценариях рост NDF-объемов может быть не связан с увеличением валютных рисков, а с другими рыночными или структурными факторами?

Какие ограничения или недостатки в данных SwapsInfo могут повлиять на достоверность оценки доли NDF в общей структуре валютных деривативов?

При каких условиях несделимые фьючерсы (NDFs) могут стать менее эффективными инструментами по сравнению с другими валютными деривативами, например, с фьючерсами на доставку?

arXiv Quantitative Finance - Pricing

SHADE: Shrinkage via Halted Alpha-stable Denoising for Heavy-Tailed Probabilistic Time Series Forecasting

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

ШADE — это новый подход к прогнозированию временных рядов с тяжёлыми хвостами, основанный на альфа-стабильных диффузиях. Вместо полного возврата к нулевому уровню шума, модель останавливается на ненулевом уровне, что позволяет ввести сжатие распределений на уровне всей вероятности, уменьшая избыточную уверенность в прогнозах. Метод разделяет риск остановки на смещение при гладкой оценке и ошибку оценки, позволяя автоматически оптимизировать уровень сжатия без прямых меток шума. На данных с тяжёлыми хвостами (α ≤ 1.3) модель значительно улучшает калибровку хвостов и снижает CRPS на 21.7%, при этом на данных с низкой тяжестью хвостов или высоким отношением сигнал/шум модель переходит к стандартным гауссовым диффузиям.

SHADE использует альфа-стабильные диффузии, останавливаясь на ненулевом уровне, чтобы ввести сжатие распределений, что снижает избыточную уверенность в прогнозах.
Внедрён механизм калибровки уровня остановки (τ*), который оптимизируется по критерию погрешности, и контекст-амортизированный подход, не требующий прямых меток шума.
Модель демонстрирует значительное улучшение калибровки хвостов на синтетических и реальных данных (криптовалюты, валюты), особенно при α ≤ 1.3.
На данных с низкой тяжестью хвостов или высоким SNR модель ведёт себя как стандартная гауссовая диффузия, что обеспечивает стабильность и универсальность.
SHADE сохраняет общую точность прогнозов на уровне сильных базовых моделей, но обеспечивает более реалистичную оценку рисков в хвостах распределений.

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

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

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

Какой компромисс между сжатием распределений и потерей детализации в хвостах может возникнуть при использовании SHADE на данных с α близким к 1.0, и как это влияет на оценку рисков в реальных сценариях?

В каких условиях (по динамике шума, длине временного ряда или структуре данных) может привести к сбоям контекст-амортизированный механизм остановки, и как это может повлиять на надёжность прогнозов?

Какова сложность вычислений при оптимизации τ* в реальном времени, и как это влияет на масштабируемость модели при работе с большими объемами данных?

arXiv Quantitative Finance - Risk Management

The Control Layer Behind Rule-Following Agents Trading Across Market Conditions

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

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

Соблюдение правил (rule adherence) у всех агентов, включая неудачный, остаётся высоким, что подчёркивает надёжность внутреннего контроля.
Потери не выходят за пределы заявленных стоп-уровней (97,5% грубых потерь), и в большинстве случаев закрываются на уровне, объявленном в начале.
Риск-контроль остаётся стабильным как в спокойные, так и в волатильные периоды, даже при 29% рыночной падении и восстановлении.
Ограничение на количество открытых позиций (5) соблюдается в 23 из 24 случаев, что указывает на устойчивость к перегрузке.
Результаты зависят от стратегии, что означает необходимость тщательного выбора и тестирования подхода на реальных данных.

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

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

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

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

В каких условиях (по волатильности, объёму, типу активов) вероятность нарушения правил может вырасти, и как это может быть учтено в архитектуре контроля?

Какова сложность проверки дисциплины в реальном времени при наличии нестабильных рыночных режимов и неопределённых входных данных?

Teacher Supervision, Fixed Representations and Calibration: Exact Risk Calculations for Candidate-Scoring Decision Models

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

Статья исследует, как три ключевых компонента моделей оценки кандидатов — обучение на "мягких" целевых значениях больших моделей (teacher targets), использование фиксированного предобученного слоя (frozen backbone) и калибровка через температуру — влияют на точность и риски принятия решений. Авторы показывают, что даже при наличии большого объёма данных и калибровке, модель может наследовать смещение учителя, и это смещение не устраняется ни дополнительными данными, ни согласованностью с учителем. Важно, что калибровка через температуру эффективна только при правильном направлении коэффициента учителя, и в противном случае оставляет невидимый остаточный риск. Также доказано, что для согласованности оценок по кандидатам требуется использование функции log-sum-exp, а не других агрегаций. На реальных данных (231 521 жалобы) модель, обученная на вероятностях логистического учителя, достигает его уровня риска, в то время как модель, обученная на исходных результатах, уступает на 8%, а модель размером 30B даже после калибровки остаётся хуже и отклоняется от условия согласованности на 17,5 дБ.

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

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

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

В каких условиях фиксированное представление в backbone может привести к значительному снижению риска, и какова минимальная выборка, при которой это снижение становится эффективным?

Если учителем является модель с неправильным направлением коэффициента, как можно обнаружить остаточный риск, который не выявляется стандартными диаграммами калибровки?

В каких сценариях использование log-sum-exp как агрегатора оценок может быть заменено на альтернативную функцию без потери согласованности, и как это повлияет на стабильность модели в production?

Dynamic Programming for Value-at-risk Markov Decision Processes in Continuous Spaces

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

Данная работа решает ключевую проблему в теории управления рисками — интеграцию меры риска Value-at-Risk (VaR) в марковские процессы принятия решений (MDPs) в непрерывных пространствах состояний и действий. Авторы доказывают валидность динамических уравнений динамического программирования для VaR MDPs в обоих случаях — конечного и бесконечного горизонта, что ранее не было доказано для непрерывных пространств. Применение предложенного подхода к задаче оптимального выполнения сделок с VaR-ограничением позволяет получить явное описание оптимальных динамических стратегий, тем самым разрешая открытую проблему в области финансовой динамики.

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

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

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

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

Какие допущения о структуре переходной функции в непрерывном пространстве могут привести к сбоям в аппроксимации динамического уравнения, и как это влияет на стабильность стратегии?

В каких условиях (по сложности, масштабу или типу динамики) динамическое программирование по VaR может потерять эффективность по сравнению с альтернативными подходами, такими как моделирование на основе симуляций?

Какова оценка чувствительности оптимальной стратегии к небольшим изменениям в параметрах VaR (например, сдвигу квантиля), и как это может повлиять на надежность решения в production-среде?

Coherent risk from finite models

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

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

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

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

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

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

Какой именно компромисс между точностью оценки и стабильностью при дублировании сценариев в дихотомических моделях может привести к потере когерентности?

В каких условиях (по структуре распределения или размеру выборки) интегральный порог на хвостах становится неизбежным, а не просто предложенным?

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

AI

Cloudflare Blog

Cutting our inference bill by 68% by being obsessive about optimization

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

Когда в апреле Cloudflare опубликовал пост о своём AI-рецензенте, средняя стоимость ревью составляла $1,19. К августу цена выросла до $2,46 — несмотря на отсутствие изменений в архитектуре и системе распределения нагрузки. В середине сентября команда начала систематически анализировать, где уходят токены, и внедряла меры по их сокращению. В результате средняя стоимость ревью снизилась до $0,77 — на 68% меньше, чем в самые дорогие периоды. Основная часть сбережений (около 40%) связана с оптимизацией кода рецензента, а остальная — с выбором моделей и уровня усилий. Ключевые изменения включают использование кэширования, снижение количества вызовов LLM, перераспределение первых запросов и переход на более эффективные модели.

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

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

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

Какие риски связаны с отказом от кэширования первых запросов в пользу более строгого контроля за структурой системного промпта, если это приведёт к потере гибкости при работе с разными репозиториями?

В каких условиях (по масштабу, типу изменений, уровню сложности) переход на более дешёвые модели может привести к потере реальных проблем, а не просто к сокращению шума?

Какова сложность и надёжность реализации синхронного запуска трёх ревьюеров с общей кэш-предпосылкой, если между ними есть разные временные лимиты и потенциальные сбои в потоке ответов?

Introducing Clairic, a new System One class of extraction models

Открыть оригинал ↗ Перевод заголовка: Введение Clairic — нового класса моделей System One для извлечения данных

Clairic — первый в своём классе экстракционный модель System One, разработанный Cloudflare, предназначен для быстрого и точного извлечения, вычисления и прогнозирования значений из неструктурированных входных данных. В отличие от традиционных LLM, Clairic не генерирует текст, а возвращает типизированные значения с метаданными: позиции в тексте, уверенность и вероятность отсутствия ответа (p_null), что делает выводы более надёжными и проверяемыми. Модель работает в одном проходе, не используя токены вывода, что обеспечивает высокую скорость, низкую стоимость и стабильность ответов.

Clairic извлекает значения напрямую из текста или изображений, возвращает их с позициями в исходном тексте и уверенностью, что позволяет точно отслеживать источники данных.
Модель может вычислять числовые значения (с учётом форматов, например, два десятичных знака) и строить распределения (оценки), основываясь на имеющихся данных, без необходимости предварительной очистки.
Для прогнозов Clairic возвращает интервалы (80%) с медианой, что даёт оценку уверенности, но не заменяет специализированные модели временных рядов.
Важно использовать метрики уверенности (confidence, p_null) для принятия решений: если значение имеет низкую уверенность, его следует проверять вручную.
Модель не решает сложные арифметические задачи с несколькими шагами и не работает с длинными цепочками вычислений — для таких случаев лучше использовать код или специализированные модели.

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

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

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

В каких условиях экстракционная модель может дать неверный результат, несмотря на высокую уверенность в ответе, и как это может повлиять на автоматизированные процессы?

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

Какова граница применимости модели при вычислении сложных арифметических операций (например, с несколькими шагами), и как это влияет на архитектуру цепочки обработки данных?

Habr AI

Что пишут в CLAUDE.md и AGENTS.md: разбор 3 126 популярных репозиториев GitHub

Открыть оригинал ↗ Перевод заголовка: Что пишут в CLAUDE.md и AGENTS.md: разбор 3 126 популярных репозиториев GitHub

Анализ 3 126 популярных репозиториев GitHub показал, что файлы правил для агентов (CLAUDE.md и AGENTS.md) в основном содержат справочные инструкции, а не жёсткие запреты. AGENTS.md встречается у 18% проектов, CLAUDE.md — у 12%, причём почти половина CLAUDE.md — это ссылка на AGENTS.md. Медианный файл содержит около 6 000 символов (90–120 строк), с минимальным количеством жёстких правил (в 40% случаев отсутствуют заглавные метки типа IMPORTANT/NEVER/MUST). В новых проектах (менее 6 месяцев) наблюдается снижение требований к инженерной дисциплине (например, линтер — с 76% до 55%), но растёт внимание к поведению агента (например, проверка результата — с 21% до 28%).

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

Начинайте с справки (команд, проверок, архитектуры), а не с запретов — это то, что агент чаще всего угадывает без явного указания.
Используйте единственный источник правил: AGENTS.md для общих процессов, CLAUDE.md только для настроек и инструментов (например, skills, субагенты, MCP), с явным импортом через @AGENTS.md.
Разделяйте конфликтующие правила (например, «прогоняй все проверки» и «запускай точечно»), чтобы агент не сталкивался с противоречиями.
Указывайте цену и необратимость команд (платные проверки, запуск в main без разрешения) — это критически важно для безопасности, но часто упускается.
Не перегружайте файлы: медиана — 100 строк, при превышении — выносите в вложенные файлы по каталогам, как в крупных проектах.

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

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

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

Какой компромисс между масштабом правил (всё в одном файле) и их поддерживаемостью (в вложенных файлах) лучше подходит для проектов с 10–100 разработчиками, и как это влияет на согласованность поведения агента?

В каких условиях (по масштабу, возрасту, количеству коммитов) правил о необратимых действиях (force-push, reset) перестают быть критичными, и как это может быть оценено без ручной разметки?

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

10 API-роутеров с долгосрочным бесплатным или сверхдешёвым доступом к DeepSeek, GLM, GPT и другим моделям

Открыть оригинал ↗ Перевод заголовка: 10 API-роутеров с долгосрочным бесплатным или сверхдешёвым доступом к DeepSeek, GLM, GPT и другим моделям

В статье анализируются 10 сервисов, позволяющих получить доступ к языковым моделям (DeepSeek, GLM, GPT и др.) по API без прямого подключения к поставщикам. Основное внимание уделено бесплатным или почти бесплатным квотам, ограничениям частоты запросов, наличию русского интерфейса и поддержке оплаты в рублях. В подборку включены OrcaRouter, TeamoRouter, Srazu, RockAPI, OpenRouter, llmgw, VseGPT, Token Harbor, NaraRouter и FreeRouter — каждый из которых предлагает уникальный набор условий доступа.

Практические тезисы:
— TeamoRouter и Srazu обеспечивают доступ к моделям с очень низкой стоимостью вызова (до 0,1% от обычной цены), причём Srazu даёт до 5 бесплатных запросов в день.
— OpenRouter предлагает 15 бесплатных моделей, но только 7 из них доступны в тесте из-за ограничений провайдеров или условий доступа.
— Token Harbor и OrcaRouter предоставляют долгосрочные бесплатные квоты (семидневные или ежедневные), но с ограничениями по частоте запросов.
— llmgw и VseGPT дают небольшие начальные бонусы (0,10 ₽ и 5 credits), но они истекают через короткий срок.
— FreeRouter временно недоступен, что делает его неприменимым на текущий момент.

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

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

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

В чём заключается компромисс между длительностью бесплатной квоты (например, 7 дней у Token Harbor) и гибкостью использования API — как это влияет на непрерывную работу при росте нагрузки?

Почему у OpenRouter часть моделей недоступна из-за условий провайдеров, а не из-за отсутствия квоты — как это может указывать на внутреннюю архитектуру доступа к моделям?

Какова вероятность, что ограничения частоты запросов (например, 15 в минуту у NaraRouter) будут ослаблены при увеличении объёма использования или при пополнении баланса?

ЭПОХА НООЦЕНА

Открыть оригинал ↗ Перевод заголовка: ЭПОХА НООЦЕНА

Автор статьи анализирует трансформацию философии в контексте развития искусственного интеллекта, подчеркивая, что в эпоху роста ИИ философия перестаёт быть академической дисциплиной и становится практической, интегрирующейся в разработку ИИ-моделей. В центре внимания — концепция «нооцен» как новой геологической эпохи, начавшейся 30 ноября 2022 года — даты запуска ChatGPT, и перехода к синтеллекту — совместному разуму человека и машины. В статье рассматриваются три основных подхода к этике ИИ: деонтология (Anthropic), консеквенциализм (OpenAI, Google) и гибкая настройка под корпоративную философию (IBM). Автор отмечает, что философия переходит от аналитического направления к «технософии» — философии, интегрированной в технологии, и предлагает понятие «онтотехники» как практики создания новых миров на основе философских основ.

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

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

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

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

Какие риски связаны с внедрением деонтологических или прагматических этических моделей в ИИ, если они не учитывают культурные и исторические контексты пользователей?

В каких масштабах и на каких этапах разработки ИИ может быть реализована «онтотехника» без угрозы потери автономности или приватности?

Поиск узких мест в Oracle с помощью ASH/AWR и LLM

Открыть оригинал ↗ Перевод заголовка: Поиск узких мест в Oracle с помощью ASH/AWR и LLM

Статья описывает инструмент Optimus Oracle, который автоматизирует поиск и оптимизацию медленных SQL-запросов в базе данных Oracle с использованием данных из ASH и AWR и логических моделей (LLM). Программа собирает метаданные о запросах, планах выполнения и структуре таблиц, затем передаёт их LLM для генерации рекомендаций по индексам, переписыванию запросов или изменению хранения данных. Работа основана на анализе планов выполнения, где выявляются узкие места — полные сканирования таблиц, отсутствие индексов на критические фильтры и сложные CASE-выражения, мешающие оптимизации.

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

Программа использует ASH/AWR для извлечения топ-запросов и их планов выполнения, не требуя ручного логирования.
На основе метаданных и планов LLM предлагает конкретные рекомендации — создание индексов, переписывание запросов, оптимизацию соединений.
Для сложных запросов с LOB-данными и множественными соединениями LLM рекомендует разбиение на логические ветви через UNION ALL, что снижает нагрузку и улучшает производительность.
Важно понимать, что рекомендации LLM — это черновик, а не готовое решение: требуется проверка на корректность и соответствие реальной структуре данных.
Для чувствительных данных предпочтительнее использовать локальные LLM (например, Ollama), чтобы избежать передачи метаданных в облако.

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

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

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

В каких условиях локальные LLM (например, Ollama) могут быть надежнее, чем облачные модели, при анализе сложных SQL-запросов в Oracle, и как это влияет на качество рекомендаций?

Какие границы применимости LLM-рекомендаций в Oracle можно определить на основе их галлюцинаций — например, предложения индексов на несуществующие таблицы или использование несуществующих колонок?

Какова оценка рисков утечки метаданных при использовании Optimus Oracle с облачными LLM, и как можно минимизировать эти риски без полной отказа от ИИ?

Оценка агентных систем

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

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

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

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

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

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

В каких условиях калибровка LLM-судьи может привести к систематической ошибке, и как это можно обнаружить без вмешательства в процесс разметки?

Какова сложность (в терминах времени и ресурсов) реализации пайплайна с параллельным сравнением baseline и кандидата в CI, если учесть динамичность внешних API и версий моделей?

ORCESTRA: как мы создали универсальный интуитивный интерфейс для обучения роботов

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

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

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

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

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

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

Какова сложность валидации траектории для роботов с разной кинематикой (например, манипуляторы с 6 степенями свободы и мобильные платформы с дифференциальным приводом), и как это влияет на производительность системы в реальных условиях?

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

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

Джун закрывает задачи с агентом, но спотыкается на разборе инцидента

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

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

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

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

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

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

Как изменить баланс между использованием агента и самостоятельной отладкой, чтобы джун развивал навык формулирования гипотез, а не просто копировал исправления?

В каких условиях (по сложности системы, сроку проекта, опыту джуна) можно сократить этап исследования системы до нескольких дней без потери качества обучения?

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

Java / Spring

Foojay

Upgrading from Java 21 to 25: What Actually Breaks

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

При обновлении с Java 21 на Java 25 часть устаревших функций и настроек перестаёт функционировать — не всегда с ошибками, а часто без предупреждений. Некоторые изменения приводят к сбою при запуске, другие проявляются позже, после запуска приложения. Важные примеры включают отключение аннотационных процессоров, удаление Security Manager, исчезновение методов Thread, игнорирование флага COMPAT и строгие изменения в работе с локальными и TLS-настройками.

Аннотационные процессоры больше не запускаются по умолчанию — требуется явно указывать их через параметры компиляции.
Security Manager полностью убран: попытка включить его приводит к ошибке, а вызов методов вроде Subject.getSubject() теперь вызывает UnsupportedOperationException.
Методы Thread.suspend(), Thread.stop() и др. полностью удалены — в JDK 25 они не существуют, и попытка их вызвать приводит к NoSuchMethodError.
Флаг java.locale.providers=COMPAT больше не работает — в JDK 25 он игнорируется, и при парсинге строк с датами может возникнуть ошибка DateTimeParseException.
В новых версиях появляются предупреждения о вызове sun.misc.Unsafe и JNI, которые в будущем приведут к ошибкам — требуется включать --enable-native-access и проверять зависимости.

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

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

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

Какой компромисс между совместимостью и безопасностью включает отключение Security Manager и sun.misc.Unsafe, и как это влияет на системы, зависящие от привилегированных операций?

В каких условиях Thread.suspend() может быть безопасно заменён на альтернативу без потери производительности, и как оценить риски при замене в старых библиотеках?

Какие риски связаны с использованием DateTimeFormatter с COMPAT в системах, где даты вводятся пользователями, и как можно избежать ошибок при парсинге без изменения логики?

Habr Java

[Перевод] Как Netflix повысила эффективность ИИ‑агентов для программирования с помощью JetBrains IDE

Открыть оригинал ↗ Перевод заголовка: Как Netflix повысила эффективность ИИ-агентов для программирования с помощью JetBrains IDE

Netflix и JetBrains разработали решение, позволяющее ИИ-агентам эффективно понимать структуру кода на Java и Kotlin без запуска графического интерфейса IntelliJ IDEA. Вместо этого они интегрировали движок интеллектуального анализа кода JetBrains, работающий в режиме без GUI, что позволяет агентам быстро и точно ориентироваться в проектах, включая JAR-библиотеки, избегая ручного распаковывания и декомпиляции.

Использование движка анализа кода JetBrains IDE (без GUI) позволяет ИИ-агентам получать детерминированный индекс проекта, включая все библиотеки, что значительно улучшает понимание структуры кода.
Для избежания "холодного старта" LSP-сервера, Netflix внедрила фоновый daemon-сервис и CLI, работающие на Java с GraalVM, что сокращает время запуска и повышает производительность.
Бенчмарки показали, что эффективность агентов растёт на 20–65% (в зависимости от модели и задачи), особенно при высоком уровне вычислительных усилий, с сохранением корректности результатов.
В задачах полного цикла агенты используют меньше вызовов инструментов, что приводит к экономии токенов и времени, без потери точности.
Решение не применимо к языкам с другими механизмами зависимостей, но его архитектура может быть адаптирована под Python, TypeScript и Go.

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

Материал полезен в средах, где ИИ-агенты работают автономно без GUI (например, в CI/CD, рефакторинге, автоматизированных тестах), и где требуется точное понимание структуры кода, особенно в проектах на JVM с JAR-библиотеками.

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

Какой компромисс между точностью анализа и масштабируемостью может возникнуть при внедрении фонового daemon-сервиса в средах с частыми перезапусками проектов?

В каких сценариях использование LSP-сервера может быть менее эффективным, чем интеграция движка анализа кода, и почему?

Как изменится оценка эффективности при переходе от "пакетных" к "многоэтапным" запросам в задачах полного цикла, если агенты начинают использовать виртуальные курсоры вместо структурных связей?

Сколько символов в нике «Аня»? Шесть языков, три ответа, и ни одного правильного

Открыть оригинал ↗ Перевод заголовка: Сколько символов в ника «Аня»? Шесть языков, три ответа, и ни одного правильного

Вопрос о количестве символов в нике «Аня👩‍👩‍👧🇷🇺» выглядит простым, но на деле он раскрывает глубокое разночтение между техническими единицами измерения строк: байтами, кодовыми точками, UTF-16-единицами и графемами. Разные языки и системы (Java, JavaScript, Go, Python, PostgreSQL и т.д.) интерпретируют длину строки по разным правилам, что приводит к разным ответам — от 5 графем до 32 байт. При этом пользователь видит на экране 5 знаков, а система может обрезать флаг или искажать эмодзи, не давая никакого предупреждения.

Длина строки в Java и JavaScript считается по единицам UTF-16, что делает их несовместимыми с графемами и эмодзи.
Go и Rust измеряют длину в байтах UTF-8, что приводит к значительным отклонениям от визуальной длины.
Python и PostgreSQL используют кодовые точки, что соответствует визуальному восприятию пользователя, но не всегда совпадает с байтовой длиной.
Обрезка строки по индексу ведёт к искажению графем (например, семья эмодзи разрезается на две женщины), что делает результат невалидным.
Проверка длины должна проводиться в единице, соответствующей пользовательскому восприятию (графемам), а не в единицах хранения или кодировки.

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

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

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

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

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

Какова сложность реализации унифицированной функции длины строки, которая работает с графемами и при этом поддерживает совместимость с существующими бэкендами на Java, Go и Python?

InfoQ Java

Java News Roundup: JEPs for JDK 28, Azul Payara, Gatherers4j, Google ADK, Yupiik, Apache Camel CVEs

Открыть оригинал ↗ Перевод заголовка: Java News Roundup: JEPs for JDK 28, Azul Payara, Gatherers4j, Google ADK, Yupiik, Apache Camel CVEs

В этом обзоре представлены ключевые разработки в экосистеме Java: три JEP (Java Enhancement Proposals) для JDK 28, обновления Azul Payara, патч-релизы Gatherers4j, Yupiik и Google ADK, а также устранение 38 уязвимостей в Apache Camel. Особое внимание уделено улучшениям в ZGC (адаптивный размер стека, быстрый запуск и структурированная конкуренция), новым функциям в платформах и безопасности.

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

JEP 546 и 545 улучшают производительность и старт приложения за счёт адаптивного управления памятью и быстрого выделения ресурсов в ZGC.
Структурированная конкуренция (JEP 543) упрощает управление ошибками и отменой задач в многопоточных приложениях, что повышает надёжность и отслеживаемость.
Azul Payara 7.5.0 устраняет критические уязвимости RCE в административной консоли и шаблонном рендеринге, что критично для безопасности в production.
Gatherers4j 0.15.0 вводит новые статистические агрегаторы (moving/running statistics), позволяя более точно отслеживать динамические метрики в реальном времени.
Google ADK для Java и Kotlin добавляет новые типы графов и DSL, упрощающие создание рабочих потоков в агентных приложениях.
Apache Camel устраняет 38 уязвимостей, включая 13 HIGH-уровневых, и рекомендуется обновление до версий 4.23.0, 4.22.1 и 4.18.5.

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

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

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

Какой компромисс между производительностью и стабильностью может возникнуть при использовании адаптивного размера стека ZGC в высоконагруженных средах?

В каких сценариях структурированная конкуренция может привести к непредсказуемому поведению при отмене задач, если не заданы корректные границы для групп задач?

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

JEP 543 Finalizes Structured Concurrency in JDK 28, Ending Seven Preview Rounds

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

JEP 543 официально внедрил в JDK 28 API структурированной конкуренции, сохранив исходную архитектуру, не внося изменений по сравнению с предыдущей предварительной версией в JDK 27. В отличие от традиционных паттернов с ExecutorService и Future, где ошибка в подзадаче может оставаться незамеченной до вызова get(), структурированная конкуренция обеспечивает автоматическое отмену всех подзадач при первой ошибке и ожидание завершения всех ветвей в рамках одного контекста. Основной элемент — интерфейс StructuredTaskScope, работающий через статические фабричные методы, где метод open() создаёт область, в которой join() ожидает успешного завершения всех подзадач, отменяет неудачные и выбрасывает исключение ExecutionException при первом сбое. Важно, что в JDK 28 устранён механизм отмены по таймауту через отдельное исключение, вместо этого используется CancelledByTimeoutException как причина, а также добавлены гибкие политики завершения через Joiner, позволяющие настраивать поведение при неудаче, включая возврат первого успешного результата или ожидание выполнения условия. Для пользователей, переносящих с JDK 26, требуется изменение кода в сигнатурах joiner, где вводится тип исключения R_X, и исчезает поддержка метода awaitAll.

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

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

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

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

В каких сценариях использование Joiner.allSuccessfulOrThrow() может привести к утечке ресурсов или неверному поведению, если не учитывать структуру выполнения и порядок завершения подзадач?

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

Javarevisited Newsletter

Java on AWS Serverless: A Practical Migration Guide

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

Миграция существующих Java-приложений на AWS Lambda требует не просто переноса методов, а выбора подхода в зависимости от архитектуры и нагрузки. В статье рассматриваются несколько ключевых паттернов: миграция монолитных приложений с сохранением существующей модели, использование Spring Cloud Function для функциональных приложений, оптимизация производительности через настройку памяти и CPU, применение Provisioned Concurrency для стабильных и латентно-чувствительных API, а также использование Lambda Durable Functions для сложных рабочих процессов. Особое внимание уделено компромиссам между затратами, латентностью и масштабируемостью.

Для монолитных приложений лучше использовать Serverless Java Container, чтобы сохранить существующую структуру Spring Boot и контроллеры, не переписывая всё в отдельные функции.
При построении новых событийных сервисов рекомендуется использовать Spring Cloud Function, так как он лучше соответствует принципам функционального программирования и позволяет избежать сложных маршрутов.
Оптимизация памяти в Lambda не должна основываться на интуиции — нужно использовать Lambda Power Tuning для анализа зависимости между памятью, временем выполнения и стоимостью.
Для снижения холодного старта в Java следует применять SnapStart, а для строгих требований к задержке — Provisioned Concurrency, при этом важно понимать, что оба решения решают разные проблемы.
Lambda Managed Instances позволяют обрабатывать несколько запросов одновременно, но требуют полной thread-safe реализации кода и тщательных нагрузочных тестов перед внедрением.

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

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

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

В каких случаях миграция через Serverless Java Container может привести к ухудшению производительности из-за длительной инициализации, несмотря на использование SnapStart?

Какой из компромиссов между стоимостью и задержкой будет предпочтительным для Java-функции, обрабатывающей 1000 запросов в день с низкой задержкой, если память увеличена с 512 до 1024 МБ?

При каких условиях Lambda Managed Instances могут привести к нестабильности, даже если приложение уже проходит нагрузочные тесты на одиночные запросы?

Microsoft for Java Developers

Plan Your Java Upgrade Ahead of Microsoft’s 2027 Support Milestones

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

Microsoft запустил серию поддерживаемых версий OpenJDK (Java 11, 17, 21 и 25), и с 2027 года начнутся окончания поддержки: Java 11 и 17 — с сентября 2027 года, Java 21 — с сентября 2028, Java 25 — с сентября 2030. Эти даты касаются всех сред, где используется Microsoft Build of OpenJDK — в виртуальных машинах, контейнерах, Kubernetes или на платформе Azure. Важно понимать, что поддержка в Azure-сервисах (App Service, Functions) также завершится 1 сентября 2027 года, и после этого версии не будут получать обновления безопасности или поддержку.

Практические тезисы:
— Используйте Modernize CLI для оценки кода и планирования перехода на Java 21 или 25, чтобы избежать рисков при обновлении.
— План модернизации должен включать конкретные изменения (например, обновление Spring Boot), сохранение стабильности API и включать тесты и проверки в стадии развертывания.
— Необходимо синхронизировать настройки сборки (Maven, JDK), CI-процессы и конфигурацию в Azure, чтобы избежать разрыва между локальными и рабочими средами.
— Проверяйте политику поддержки в зависимости от среды (управляемые сервисы vs. пользовательские контейнеры), так как сроки могут отличаться.
— Внедрение должно быть поэтапным с возможностью отката, особенно при переходе на новые версии Java с изменёнными API (например, миграция Spring Boot 2 → 3).

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

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

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

Какие компромиссы возникают при переходе с Java 17 на Java 21, если в приложении используются устаревшие библиотеки, несовместимые с новыми версиями JDK?

В каких условиях (по сложности, масштабу, типу нагрузки) можно безопасно внедрить виртуальные потоки в Java 21 без изменения основной логики приложения?

Какова вероятность сбоя при отсутствии проверки совместимости в CI-процессе, если сборка проходит на Java 17, но приложение запускается на Java 21?

System Design

Cloudflare Blog

Beyond the patch: Protecting your NetScaler gateway against future vulnerabilities

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

Недавняя уязвимость в Citrix NetScaler выявила системный риск: входная страница может быть использована для проникновения в сервер приложения. Уязвимость позволяла атакующим выполнять команды без аутентификации, что делает патч критически важным, но одновременно вызывает конфликт между безопасностью и доступностью пользователей. После патча важно внедрять дополнительные защитные меры, чтобы избежать повторных кризисов. Ключевые подходы включают применение политик Zero Trust, валидацию запросов на уровне WAF и ограничение доступа к серверам через туннели или сетевые фильтры.

Переместите аутентификацию в систему Zero Trust (например, через Cloudflare Access), чтобы принять решение о доступе до того, как запрос достигает сервера.
Используйте WAF с машинным обучением (Attack Score) для обнаружения неизвестных атак, даже если они не соответствуют известным CVE.
Ограничьте доступ к приложениям через DNS-записи и туннели (например, Cloudflare Tunnel), чтобы исключить прямой доступ к серверу.
Добавьте проверку токенов (JWT) на стороне источника для подтверждения, что запрос прошёл через Cloudflare Access.
Проверяйте конфигурацию в тестовой среде: без подтверждения на уровне логов и сетевых политик защита может быть обойдена.

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

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

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

Какой компромисс между доступностью и безопасностью может возникнуть при внедрении Cloudflare Access, если пользователи уже привыкли к прямому доступу к приложениям через публичный URL?

В каких условиях WAF-атака с использованием Attack Score может привести к ложным срабатываниям, особенно при работе с корпоративными приложениями, где запросы могут быть валидными и законными?

Какие риски связаны с тем, что туннель Cloudflare Tunnel не поддерживает прямой доступ к внутренним сервисам, и как это может повлиять на отказоустойчивость при сбое в сети?

DEV System Design

Building Scalable Placement Database Systems for Higher Education ERP

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

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

Использование реляционной модели (например, PostgreSQL) с четко определёнными таблицами и ключами позволяет структурировать данные о студентах, вакансиях, заявках и отборах, обеспечивая ссылки между записями.
Внедрение уникальных ограничений (например, на комбинацию student_id и drive_id) предотвращает дублирование заявок и поддерживает целостность данных.
Безопасность достигается за счёт валидации ввода, параметризованных запросов и контроля доступа по ролям, что особенно важно при работе с персональными данными.
Для масштабируемости необходимо использовать индексы для часто используемых запросов, пагинацию для работы с большими объёмами данных и, при необходимости, кэширование или репликацию.
Система должна быть протестирована на реальных рабочих процессах и нагрузках перед внедрением в production.

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

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

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

Как изменится архитектура при наличии большого количества вакансий в разных дисциплинах, и как это повлияет на производительность запросов по критериям "доступность по специальности"?

В каких условиях и при каких нагрузках оправданы введение реплик и кэширования, и как это может повлиять на согласованность данных между репликами?

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

Saga Pattern

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

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

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

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

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

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

В каких условиях компенсирующие действия могут стать неэффективными или привести к несогласованности, даже если они идемпотентны?

Какова сложность реализации саги при увеличении количества сервисов и ветвлениях в бизнес-логике?

DDIA is a great book. It is a bad lab.

Открыть оригинал ↗ Перевод заголовка: DDIA — отличная книга, но плохой лабораторный материал.

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

Упражнения не сводятся к пересказу — они требуют прохождения сценариев отказа (например, сбой координатора в 2PC) и анализа, почему простое переподключение не работает.
Каждая схема в лаборатории — это не просто иллюстрация, а активное упражнение: нужно отслеживать переходы, находить точки, где система не может действовать, и понимать, почему "перезапуск" не решает проблему.
Структура упражнений разбита по уровням (новичок, старший, руководитель) и помечена по приоритету, что позволяет систематически развивать навыки от базовых до сложных решений.
Лаборатория не заменяет книгу — она дополняет её, предоставляя практику, которая отсутствует в оригинальном материале.
Весь контент включает оба языка (английский и персидский), что делает её полезной для тех, кто изучает английский технический язык.

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

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

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

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

В каких условиях (по сложности, времени, типу сценария) 2PC-модель может стать неэффективной, и как это может быть выявлено в лаборатории?

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

72% of Anthropic's design questions are AI or ML. 62% of OpenAI's are classic.

Открыть оригинал ↗ Перевод заголовка: 72% вопросов по проектированию у Anthropic касаются ИИ или машинного обучения, у OpenAI — 38%.

У Anthropic в 29 вопросов по проектированию 21 касается ИИ-систем или машинного обучения, в то время как у OpenAI из 50 — только 19. Большинство вопросов у Anthropic связаны с инфраструктурой ИИ: работа с GPU, инференсом моделей, загрузкой моделей. Вопросы о классических системах составляют лишь 8 из 29, но один из них — «один на один чат с очередью и присутствием» — является универсальным и часто встречается. Вопросы о критике существующих проектирований также входят в состав, что требует навыков анализа и выявления слабых мест.

При подготовке к собеседованию в Anthropic нужно фокусироваться на 3 ключевых вопросах по ИИ-инфраструктуре: batched LLM inference API over GPUs, AI prompt playground и distributed AI model downloader.
Важно тренироваться писать проектирование в текстовом формате (например, Google Doc) в течение 55 минут без использования ИИ, чтобы соответствовать реальным условиям.
Нужно подготовиться к критике существующих проектирований — вы должны уметь выявлять первые сбои, оценивать стоимость и задавать автору уточняющие вопросы.
Если вы проходите оба интервью (Anthropic и OpenAI), начните с 7 общих вопросов, затем перейдите к классическим вопросам OpenAI.
Вопросы о классических системах, хотя и редки, всё же важны — особенно «один на один чат с очередью», который может быть использован как базовый пример.

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

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

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

Почему в Anthropic так высокая доля вопросов по ИИ-инфраструктуре, и как это влияет на оценку кандидата по навыкам системного проектирования?

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

В каких условиях (по сложности, масштабу, нагрузке) может быть неэффективным использование batched LLM inference API over GPUs как примера в проектировании?

Batch vs Stream Processing: Full Course for System Design

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

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

Какие технические ограничения (например, задержки, ресурсы, отказы) влияют на выбор между батчом и потоком в условиях низкой пропускной способности?
В каких случаях потоковая обработка может привести к неправильным результатам из-за нестабильности данных или неполной доставки событий?
Как оценить сложность и масштабируемость архитектуры, если в системе одновременно используются Kafka, Flink и Spark с разными моделями согласованности (например, exactly-once)?

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

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

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

В каких условиях потоковая обработка может привести к потере данных из-за переполнения или сбоя в системе, и как это может быть оценено без использования тестов?

Какие компромиссы между задержкой и точностью возникают при использовании Flink с watermarks в системах с высокой скоростью потока событий?

В каких сценариях батч-обработка может быть неэффективной даже при наличии больших объёмов данных, и как это влияет на выбор архитектуры?

Payment Gateway Architecture: Idempotency, Webhooks, Security, and Scaling Beyond the Happy Path

Открыть оригинал ↗ Перевод заголовка: Архитектура платежной системы: идемпотентность, вебхуки, безопасность и масштабирование за пределами «успешного пути»

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

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

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

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

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

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

В каких условиях дедупликация вебхука по идентификатору может не сработать, и как это может повлиять на состояние платежа в случае задержки событий?

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

From 100 Million Events to 1,200 Pixels: Engineering a Data-Heavy Dashboard

Открыть оригинал ↗ Перевод заголовка: От 100 миллионов событий до 1200 пикселей: инженерия дашборда с большим объёмом данных

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

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

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

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

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

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

При каких условиях физическая структура данных (например, партиции) может стать более эффективной, чем простой индекс по времени, и как это зависит от распределения нагрузки по временным диапазонам?

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

DesignGurus

Why Strong Engineers Fail System Design Interviews: 5 Traps to Avoid

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

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

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

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

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

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

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

В каких условиях (по сложности задачи, объёму данных, времени) глубокое знание распределённых систем может стать неэффективным, а не просто неудобным?

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

ScyllaDB

Feast Feature and Vector Serving at ScyllaDB Speed

Открыть оригинал ↗ Перевод заголовка: Интеграция Feast и векторного поиска в ScyllaDB на высокой скорости

Новая версия Feast (v0.65) вводит оптимизированную интеграцию с ScyllaDB, обеспечивающую быструю работу онлайн-фич-сторов, поддержку векторных эмбеддингов и улучшенную производительность. Ранее ScyllaDB использовался через неоптимизированный драйвер Cassandra, что приводило к задержкам и отсутствию поддержки векторных запросов. Новая реализация использует шард-оптимизированный драйвер Python, поддерживает как самоподготовленные, так и облачные кластеры, и реализует API векторного поиска в соответствии с стандартами Feast. Это позволяет единым хранилищем хранить как структурированные фичи, так и векторные эмбеддинги, обеспечивая низкую задержку, высокую пропускную способность и глобальную доступность.

Новая интеграция использует шард-оптимизированный драйвер ScyllaDB, что обеспечивает лучшую производительность по сравнению с драйвером Cassandra.
Поддержка векторного поиска в рамках единого API позволяет интегрировать эмбеддинги в стандартные фич-получения без дополнительных слоев.
Система обеспечивает низкие задержки (P99 < 20 мс), высокую пропускную способность (до 1 млн операций в секунду) и отказоустойчивость благодаря симметричной архитектуре.
Векторные запросы выполняются с той же скоростью, что и обычные операции, благодаря встроенному HNSW и нативной поддержке в ScyllaDB.
Упрощённая настройка через feast apply позволяет избежать отдельных миграций схемы и быстро запускать векторные запросы.

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

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

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

В каких сценариях векторный поиск в ScyllaDB может быть менее эффективен, чем в специализированных векторных базах данных, и как это влияет на выбор архитектуры?

Какова сложность и масштабируемость векторного поиска при росте количества векторов до миллиардов, и как это может повлиять на P99 задержку в реальных системах?

В каких условиях использование ScyllaDB как единого хранилища фич может привести к ухудшению производительности по сравнению с раздельными хранилищами для структурированных и векторных данных?

Coding / Algorithms

DEV Data Structures

Segment Trees: Leveling Up Like a RPG Boss

Открыть оригинал ↗ Перевод заголовка: Сегмент-деревья: рост, как у босса в RPG

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

Сегмент-дерево хранит агрегированные значения только для интервалов длины, являющейся степенью двойки, что позволяет сократить количество хранящихся данных и упростить вычисления.
Каждый запрос по диапазону разбивается на O(log n) таких интервалов, и ответ формируется путём объединения значений в соответствующих узлах дерева.
Обновление элемента требует изменения только одного листа и последующего пересчёта значений по пути к корню — всё за O(log n).
Структура поддерживает любые ассоциативные операции (сумма, минимум, максимум), что делает её универсальной для разных типов задач.
Несмотря на небольшой рост памяти (примерно 2n узлов), выигрыш в производительности делает её применимой даже при больших объёмах данных.

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

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

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

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

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

Какова граница применимости сегмент-деревьев по размеру массива и количеству операций, при котором логарифмическая сложность становится несущественной по сравнению с памятью и инициализацией?