Risk Management

arXiv Quantitative Finance - Pricing

DSINC beyond Heston: the 3/2 and other non-affine stochastic-volatility models

Открыть оригинал ↗ Перевод заголовка: DSINC за пределами модели Хестона: модель 3/2 и другие неаффинные стохастические модели волатильности

Статья предлагает обобщение метода damped-sinc (DSINC) для оценки американских опционах за пределами аффинных моделей, таких как модель Хестона, и его применение к неаффинным моделям волатильности, включая модель 3/2 и SABR. Авторы доказывают, что ключевая идентичность «сжатия» остаётся валидной для широкого класса моделей, при условии, что дисконтированный уровень активов является неотрицательным локальным мартингалом. Метод использует трансформацию Ито для факторизации характеристической функции и определения естественной координаты для аппроксимации границы раннего исполнения. В случае моделей с закрытыми формами преобразований (например, 3/2 и несвязанный SABR) — они выражаются через функции Куммера и представление в виде Бесселя соответственно. При отсутствии аналитических форм — интеграл волатильности вычисляется напрямую через решение одного обратного уравнения по частоте, без дискретной сетки по логарифмической цене.

  • DSINC остаётся применимым к неаффинным моделям волатильности при условии, что дисконтированный актив является неотрицательным локальным мартингалом.
  • Метод использует трансформацию Ито для получения факторизованной характеристической функции и определения естественной координаты для аппроксимации границы раннего исполнения.
  • Для моделей с закрытыми формами (3/2, несвязанный SABR) — используются функции Куммера и представление в виде Бесселя соответственно.
  • При отсутствии аналитических форм — интеграл волатильности вычисляется через решение одного обратного уравнения по частоте, без сетки по лог-цены.
  • Метод показывает точность до одного базисного пункта по сравнению с методами конечных разностей, при этом вычислительная стоимость сопоставима или ниже, за исключением медленного варианта для несвязанного SABR.

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

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

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

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

(Early) AI Compute Asset Pricing

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

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

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

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

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

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

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

GROMM: Generative Risk-neutral Option Market Models

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

Предложенная модель GROMM представляет собой статически и динамически безарбитражный подход к оценке европейских опционов, основанный на фреймворке SANOS. Модель обеспечивает гладкую интерполяцию цен опционов и доказывает существование единственного сильного решения для её динамики, интерпретируя локальную волатильность как описание поверхности цен опционов, а не как модель оценки. На примере данных по опционам S&P с января 2022 по август 2025 года показано, что начальное состояние модели соответствует диапазону спроса-предложения для более чем 95% опционов. Модель обучается в мерах $\mathbb{P}$ и $\mathbb{Q}$, подтверждая отсутствие арбитража и хорошее соответствие рыночным динамикам. Авторы также предложили серию тестов BHW для проверки отсутствия арбитража.

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

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

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

  1. В каких условиях локальная волатильность как представление поверхности цен опционов может привести к искажению оценок, если не учитывать динамические изменения в структуре рынка?
  2. Какова сложность вычислительного процесса обучения динамики модели GROMM в $\mathbb{P}$ и $\mathbb{Q}$ при больших объёмах данных и высокой размерности поверхности опционов?
  3. В каких сценариях BHW-тесты могут не выявить арбитраж, и как это может повлиять на надёжность выводов о безарбитражности модели?

arXiv Quantitative Finance - Risk Management

Distributions or Quantiles? A Convex Variational Theory of Worst-Case Risk

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

Статья предлагает новую теоретическую основу для оценки риска в условиях неопределённости, объединяя разрозненные подходы к анализу наихудшего случая. Авторы вводят конвексную вариационную теорию, которая позволяет выбрать между распределениями и квантилями как представления неопределённости, сохраняя при этом выпуклость множества возможных распределений. Работа даёт систематический способ определения наихудшего распределения и его риска, включая классические границы по центральным моментам и новые решения для моделей с водяными барьерами, асимметричными моментами и Kullback–Leibler-окрестностями.

  1. Теория показывает, что для сохранения выпуклости множества неопределённости лучше использовать квантильное представление, чем полное распределение, что упрощает вычисления и гарантирует стабильность оптимизации.
  2. Полученные оптимальные условия позволяют получить аналитические или полуаналитические решения для широкого класса моделей, включая Wasserstein-неопределённость и асимметричные моменты.
  3. Для практического применения разработаны проекционные алгоритмы, которые сходятся при фиксированной сетке, что делает их применимыми даже в высокомерных задачах портфельного выбора.
  4. В случае гауссового базового распределения и неопределённости, основанные на Kullback–Leibler, авторы получают точную проекцию, что позволяет сократить задачу выбора портфеля до второго порядка конуса после одной калибровки.

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

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

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

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

General bounds on functionals of the lifetime under life table constraints in a joint actuarial-financial framework

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

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

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

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

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

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

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

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

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

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

  1. Установлены динамические уравнения для VaR MDP в непрерывных пространствах, что позволяет применять методы динамического программирования в задачах с непрерывными состояниями и действиями.
  2. Работа охватывает как конечный, так и бесконечный горизонты, обеспечивая универсальность подхода для широкого спектра прикладных задач.
  3. Применение к задаче оптимального выполнения сделок показывает практическую ценность метода в финансовых и операционных системах.
  4. Уравнения позволяют строить оптимальные стратегии в реальном времени, что важно для систем, где риски должны контролироваться в динамике.
  5. Решение подразумевает использование VaR как критерия оптимизации, что требует тщательного анализа чувствительности к выбранному уровню доверия.

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

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

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

  1. Какова сложность вычислительного решения динамических уравнений для VaR MDP в непрерывных пространствах при больших размерностях состояний?
  2. В каких условиях VaR может привести к неустойчивым или несбалансированным стратегиям, и как это может повлиять на долгосрочную надежность решений?
  3. Какой альтернативный критерий риска (например, Conditional Value-at-Risk) может быть интегрирован в этот фреймворк, и как это повлияет на структуру динамических уравнений?

AI

AWS Architecture Blog

Automate medical coding with Step Functions and Amazon Bedrock AgentCore

Открыть оригинал ↗ Перевод заголовка: Автоматизация медицинского кодирования с помощью Step Functions и Amazon Bedrock AgentCore

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

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

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

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

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

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

Cloudflare Blog

How Commerce.com and Cloudflare are getting storefronts ready for AI agents

Открыть оригинал ↗ Перевод заголовка: Как Commerce.com и Cloudflare готовят магазины к использованию агентов на основе ИИ

AI может писать код и сдавать экзамен, но всё ещё не может купить пару ботинок в интернет-магазине. Сайты были созданы для людей, а не для агентов, которые сегодня работают с HTML-кодом: они смотрят на страницу, пытаются понять, что делает каждая кнопка, кликают и повторяют попытку, если что-то не сработало. Этот процесс медленный, тратит много токенов и легко нарушается при изменении темы. Вводится стандарт WebMCP от Google — он предоставляет агентам структурированные инструменты на странице, например, search_products. Вместо того чтобы искать кнопки, агент напрямую вызывает нужный инструмент, что делает покупки быстрее, дешевле и надёжнее. WebMCP пока доступен в экспериментальном режиме, в Chrome, в Origin Trials и в средах разработки, таких как Cloudflare Kitesurf. В августе Cloudflare запустил бета-версию реализации WebMCP на границе — включает небольшой скрипт, который автоматически вставляет инструменты без необходимости изменять код сайта. Commerce.com, платформа для магазинов, использующих Cloudflare для почти 100 000 доменов, запросила возможность включить WebMCP для всех магазинов сразу.

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

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

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

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

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

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

Habr AI

Почему я перестал использовать редакторы кода на основе ИИ — 2026 (взгляд на апрель 2025)

Открыть оригинал ↗ Перевод заголовка: Почему я перестал использовать редакторы кода на основе ИИ — 2026 (взгляд на апрель 2025)

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

  1. ИИ-редакторы (автокомплит, чаты) перестали быть эффективными — они вводят ошибки, отвлекают от анализа кода и приводят к «параличу мозга» при отключении.
  2. Работа с ИИ-редакторами не даёт реального ускорения: в экспериментах METR с ИИ задачи занимали на 19% больше времени, чем вручную, из-за микроконтроля и переписывания промптов.
  3. Появление агентских обвязок (например, Claude Code, MCP-интеграции) позволило перейти от ручного кода к оркестрации — человек становится не исполнителем, а стратегом, который устанавливает границы и архитектуру.
  4. Без проектной документации агенты быстро разрушают архитектуру, поэтому в 2026 году вновь возвращается Spec-Driven Development — спецификации, контракты и тест-планы становятся обязательными.
  5. Рост занятости в кастомных приложениях и снижение вовлечённости молодых разработчиков (на 20%) показывают, что рутинные задачи теперь выполняются агентами, а не людьми.

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

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

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

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

InkPeek — переводчик для Android‑читалок: работает офлайн, а с интернетом ещё и объясняет через AI

Открыть оригинал ↗ Перевод заголовка: InkPeek — переводчик для Android-читалок: работает офлайн, а с интернетом ещё и объясняет через AI

InkPeek — это независимое приложение для Android-читалок, которое позволяет переводить слова и фразы с поддержкой офлайн-функций и AI-объяснений при подключении к интернету. Оно интегрируется с популярными читалками через протокол ColorDict 3 и предлагает как базовые переводы, так и глубокий грамматический анализ с помощью моделей искусственного интеллекта. Приложение использует собранные из Викисловаря словари, оптимизированные по качеству и формам слов, а также встроенные модели для определения языка и перевода фраз, включая поддержку непрямых цепочек (например, de → en → ru).

  • Офлайн-перевод слов и фраз через локальные словари, собранные из kaikki.org и WikDict, с проверкой качества по 85% охвата наиболее частых слов.
  • Для фраз используется модель Firefox Translations (напрямую при наличии английского языка или через английский), с возможностью работы на устройстве через движок Bergamot.
  • Определение исходного языка осуществляется с помощью легкой модели fastText, способной распознавать язык среди 176 языков.
  • Поддержка грамматики слов (например, формы существительных, глаголов, множественного числа) и автоматическое корректирование форм в тексте.
  • При наличии интернета доступны AI-функции: разбор грамматики, контекстное объяснение, идиомы, примеры с переводом — через API провайдеров (OpenRouter, Ollama, LM Studio) или собственные модели.

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

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

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

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

[Перевод] AI меняет лидеров рынка (да и целую эпоху)

Открыть оригинал ↗ Перевод заголовка: AI меняет лидеров рынка (да и целую эпоху)

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

  • AI-инфраструктура требует огромных вложений: построить комплекс в 1 гигаватт стоит $50–55 млрд, из которых $40 млрд — на оборудование, и кредиторы готовы заплатить до 75%.
  • Рынок чипов и CPU растёт быстро: к 2031 году выручка от серверных CPU может вырасти в 8 раз, в основном из-за роста спроса со стороны AI-агентов.
  • Существует парадокс роста: хотя стоимость токенов падает, общее потребление ресурсов растёт из-за массового внедрения технологий, что подтверждает парадокс Джевонса.
  • Новые формы финансирования, как у Fannie Mae, могут стать необходимыми для масштабирования AI-проектов, поскольку одни компании не могут выдерживать полную нагрузку по кредитам.
  • Важно оценивать потенциал компаний не по расходам на обучение, а по прибыльности в устойчивом режиме, где AI-агенты и модели могут работать без постоянного обновления.

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

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

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

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

SIEM на двух ядрах для 150 хостов и 9 B‑модель на триаже: как устроен самописный AI SOC

Открыть оригинал ↗ Перевод заголовка: SIEM на двух ядрах для 150 хостов и 9B-модель на триаже: как устроен самописный AI SOC

Команда Medici Lab разработала архитектуру AI SOC, в которой маленькая модель на 9 миллиардов параметров (Qwen) с дообучением достигает 96–97% точности при обработке сработавших правил, используя минимальный контекст (около 200 токенов). Система работает на 150 хостах с помощью агентов на C/C++, весомых всего 60 КБ, которые фильтруют события локально и отправляют только очищенные данные в коллектор, что исключает необходимость нормализации и снижает нагрузку на центральный сервер. Вместо обработки всего потока событий модель анализирует только сработавшие правила, что позволяет избежать шума и повысить надёжность ответов. Основные преимущества — снижение затрат, упрощение входа для ИИ и автономность в реагировании, но сопряжены с рисками: видимость правил на хостах, уязвимость к реверсу и зависимость от управления правилами.

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

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

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

  1. Ставили ли вы LLM на триаж в своём SOC, и какую долю верных вердиктов она давала на ваших правилах?
  2. Где, по вашему мнению, граница, после которой модели можно отдать автоматическое реагирование на L2?

Hugging Face Blog

How Specializing the Vocabulary of SLMs Can Cut Inference Cost by 77% in Real Applications

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

В статье описывается метод VocabX, позволяющий сократить расходы на инференс на 77% без изменения базовой модели, пересматривая не частоту, а стоимость каждого токена в словаре. В отличие от существующих подходов, который базируются на частоте использования, VocabX оценивает стоимость токена с учётом его местоположения в входных или выходных данных, что делает сокращение более эффективным. Метод включает два уровня специализации: сокращение подслов (sub-word merge) и создание макро-токенов (macro tokens) для повторяющихся структур, таких как JSON-оболочки. Важно, что VocabX не только уменьшает количество токенов, но и учитывает реальную стоимость генерации, где каждый генерируемый токен стоит значительно дороже, чем входной текст. В результате в портфеле автоматического оценщика португальских эссе размер ответа сократился с 350 до 101 токена, а качество оценки выросло с 0.703 до 0.810.

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

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

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

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

InfoQ Architecture

Article Series: Agentic AI Architecture

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

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

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

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

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

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

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

Latent Space

AI for the Fortune 2000: How Tenex Builds an AI-Native SDLC — Alex Lieberman & CJ Hess

Открыть оригинал ↗ Перевод заголовка: AI для компаний Fortune 2000: как Tenex строит AI-ориентированный жизненный цикл разработки

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

  1. Tenex платит инженерам за результаты, а не за время, что создаёт прямую связь между продуктивностью и доходом — в результате наблюдается значительная дисперсия заработных плат (до 4×).
  2. Вместо традиционного «код-код» процесс разработки в Tenex включает в себя архитектуру, обсуждение с клиентами и формирование контекста, который передаётся моделям — это делает работу агентов более эффективной.
  3. MetaHarness — это совокупность документации, планов и CLI, встроенных в Git, где каждое решение, обсуждение и выбор фиксируются как часть истории проекта, обеспечивая прозрачность и воспроизводимость.
  4. Внедрение AI-агентов привело к росту среднего объёма работы инженеров в 2 раза за год, что подтверждает эффективность модели, несмотря на субъективность «стори-пойнтов».
  5. Компания сталкивается с проблемой оценки ценности работы, которая не вписывается в традиционные задачи — здесь важно учитывать не только код, но и процесс принятия решений, клиентские вводы и стратегическое мышление.

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

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

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

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

Martin Fowler

Fragments: October 21

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

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

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

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

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

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

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

Java / Spring

Alexander Obregon

How to Manage Spring Boot 4 Profiles for Different Environments

Открыть оригинал ↗ Перевод заголовка: Как управлять профилями Spring Boot 4 для разных сред развертывания

Spring Boot позволяет эффективно управлять конфигурацией приложений в зависимости от среды — от разработки до производства — через профили. Вместо копирования полных файлов конфигурации для каждой среды, приложение использует общий базовый конфиг, где хранятся стабильные настройки, а изменения ведутся только в профильных файлах. С помощью механизмов вроде @Profile, @ConfigurationProperties и активации профилей через переменные среды или командные аргументы можно динамически настраивать поведение без изменения кода. При этом Spring Boot 4 поддерживает все эти функции, включая обновлённые имена свойств (например, spring.mongodb.uri вместо spring.data.mongodb.uri), и требует Java 17+.

  1. Общие настройки (например, имя приложения, логирование) хранятся в application.properties и доступны во всех средах, что упрощает поддержку и минимизирует дублирование.
  2. Профильные файлы (например, application-dev.properties) содержат только отличающиеся настройки, что позволяет избежать переписывания общих параметров.
  3. Активация профиля может происходить через командную строку, переменную среды SPRING_PROFILES_ACTIVE или в application.properties, но не должна быть включена в профильные файлы, чтобы избежать циклической зависимости.
  4. При наличии конфликтующих свойств в разных профильных файлах Spring Boot применяет правило «последний выигрывает» — значение из последнего профиля переходит в конечный результат.
  5. Для тестирования можно использовать аннотацию @ActiveProfiles и проверять значения через @Autowired и утверждения, что обеспечивает надёжную валидацию настроек без ручного анализа файлов.

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

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

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

  1. Какой компромисс возникает при использовании условных конфигураций в одном файле (через spring.config.activate.on-profile), если в будущем количество сред увеличится и потребуется более гибкая структура?
  2. В каких случаях может привести к ошибке или нестабильности активация нескольких профилей одновременно, особенно если они содержат конфликтующие настройки, и как это можно предотвратить на архитектурном уровне?
  3. Как влияет изменение имени свойства (например, spring.data.mongodb.uri → spring.mongodb.uri) на миграцию приложения с Spring Boot 3.x, и как можно автоматизировать проверку совместимости таких изменений без ручного анализа кода?

Foojay

Exact Prices in Java: Decimal Strings and BigDecimal Traps

Открыть оригинал ↗ Перевод заголовка: Точные цены в Java: десятичные строки и ловушки BigDecimal

В Java для работы с ценами нельзя использовать тип double, так как он не может точно представить десятичные дроби — даже простые значения, такие как 0.1, приводят к ошибкам. Вместо этого следует использовать BigDecimal, особенно при обработке строковых цен из JSON, где потеря точности происходит уже на этапе парсинга. Основные риски — это неверные вычисления при суммировании, сравнении или хранении, а также неправильное отображение значений при использовании стандартных методов. Ключевые практики включают чтение строковых цен через new BigDecimal(node.asText()), избегание decimalValue() и asDouble(), применение точного форматирования при выводе и выбор правильного режима округления.

  1. Никогда не используйте double для цен — даже для отображения — так как он не может точно хранить десятичные дроби.
  2. При чтении цен из JSON-строки используйте new BigDecimal(node.asText()), а не decimalValue() или asDouble(), чтобы избежать потери точности.
  3. Если цена приходит как число в JSON, включите DeserializationFeature.USE_BIG_DECIMAL_FOR_FLOATS, чтобы сохранить полную точность на этапе парсинга.
  4. Создавайте BigDecimal из строк, а не из double, чтобы избежать ошибок, связанных с двоичным представлением.
  5. При сравнении значений используйте compareTo(), а не equals(); при делении укажите масштаб и режим округления, и всегда используйте toPlainString() для вывода.

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

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

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

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

Habr Spring

JetBrains выпустила расширение Java и Kotlin для VS Code и Cursor

Открыть оригинал ↗ Перевод заголовка: JetBrains выпустила расширение Java и Kotlin для VS Code и Cursor

JetBrains представила стабильную версию 1.0 расширения «Java and Kotlin by IntelliJ IDEA», которое переносит языковой анализ из IntelliJ IDEA в сторонние редакторы VS Code и Cursor. Расширение работает локально как языковой сервер по протоколу LSP, обеспечивая автодополнение, навигацию, проверку ошибок, рефакторинг и поддержку фреймворков, таких как Spring. Оно поддерживает Maven, Gradle, Bazel и JUnit, а в Cursor — позволяет ИИ-агентам использовать семантический анализ через прямой доступ к языковому серверу, что повышает точность ответов на запросы о вызовах методов.

  1. Какие риски связаны с использованием локального языкового сервера в редакторах, если проекты крупные и включают миллионы строк кода?
  2. В каких сценариях может привести к снижению производительности или нестабильности включение нескольких Java-расширений (например, от Red Hat и JetBrains) в одном редакторе?
  3. Какова вероятность того, что агенты в Cursor, использующие LSP для семантического поиска, будут в состоянии корректно интерпретировать сложные типы данных и анонимные классы в Kotlin, если не привязаны к компилятору?

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

Материал полезен для разработчиков, работающих с Java и Kotlin в средах, где важна точность анализа кода и интеграция с ИИ-агентами, особенно при работе с крупными проектами и монорепозиториями. Особенно актуален для тех, кто использует Cursor или VS Code и хочет получить компилятор-уровневую поддержку без зависимости от IntelliJ IDEA.

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

  1. Какие риски связаны с использованием локального языкового сервера в редакторах, если проекты крупные и включают миллионы строк кода?
  2. В каких сценариях может привести к снижению производительности или нестабильности включение нескольких Java-расширений (например, от Red Hat и JetBrains) в одном редакторе?
  3. Какова вероятность того, что агенты в Cursor, использующие LSP для семантического поиска, будут в состоянии корректно интерпретировать сложные типы данных и анонимные классы в Kotlin, если не привязаны к компилятору?

Курсы программирования со скидкой: Python, Java и 1С на конец 2026 года

Открыть оригинал ↗ Перевод заголовка: Курсы программирования со скидкой: Python, Java и 1С на конец 2026 года

Скидки в онлайн-курсах по программированию часто выглядят привлекательными, но их реальная ценность зависит не от процента скидки, а от итоговой стоимости, тарифа, срока обучения и карьерных условий. В подборке представлены семь курсов по Python, Java и 1С, где разброс цен и сроков достигает 14 раз, что делает выбор критичным. Ключевыми факторами становятся не только скидка, но и формат обучения, наличие стажировки, гарантии по трудоустройству и возможность налогового вычета. Для новичков важна пробная стадия — например, бесплатные уроки или короткий курс, чтобы оценить вовлечённость. Для специалистов с опытом в бухгалтерии или закупках 1С становится более доступным выбором благодаря русскоязычному коду и внутреннему пониманию учёта.

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

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

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

  1. В чём заключается компромисс между коротким курсом (например, Python Academy) и долгосрочным обучением по Java, если бюджет позволяет только на пробу?
  2. Какие скрытые условия в гарантиях возврата денег (например, в Бруноям или Skillfactory) могут повлиять на реальную ценность курса, и как их проверить без доступа к документу?
  3. При каких условиях 1С-курс может быть более выгодным, чем Python или Java, несмотря на более низкую зарплату, и как это оценивается с точки зрения карьерного роста?

Java67

Top 5 Soft Skill and Career Development Books and Courses for Software Engineers

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

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

  1. The Clean Coder — книга о профессиональном поведении, включая как говорить «нет», чтобы избежать перегрузки, так и как задавать правильные вопросы для выявления рисков.
  2. Pragmatic Programmer 2nd Edition — практическое руководство по управлению карьерой, включая построение команд и принятие решений, с примерами из реальной практики.
  3. Confessions of a Software Techie — фокус на навыках общения, особенно в письменной форме, и взаимодействии с менеджерами и клиентами.
  4. The Passionate Programmer — подход к карьере как к бизнесу, где навыки программиста — это продукт, который можно продвигать и развивать.
  5. Курсы на Udemy (например, Soft Skills: The 11 Essential Career Soft Skills, How to become an Outstanding Solution Architect) дополняют книги и делают обучение доступным и структурированным.

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

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

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

  1. В каких условиях The Clean Coder может быть неэффективным для команды, где коммуникация основана на формальных протоколах, а не на личных взаимодействиях?
  2. Какой компромисс между глубиной технических знаний и развитием мягких навыков может возникнуть при использовании Pragmatic Programmer в рамках корпоративной среды с жесткими KPI?
  3. В каких сценариях The Passionate Programmer может привести к переоценке роли технической специализации в карьере, особенно при отсутствии бизнес-опыта у программиста?

Javarevisited Newsletter

50 Java Multithreading and Concurrency Questions That Actually Prepare You for Real Interviews

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

Для разработчиков с 2–5 годами опыта Java этот список вопросов — ключ к успешной сдаче интервью по теме многопоточной и синхронизированной обработки. Вопросы охватывают от базовых концепций (например, разницу между Thread и Process) до сложных тем, таких как модель памяти Java, дедлоки, volatile-переменные и выбор между Runnable и Callable. Важно понимать не только ответы, но и логику работы механизмов: например, почему volatile гарантирует видимость изменений, почему wait/notify должны вызываться в синхронизированном блоке, и как thread-local переменные решают проблемы синхронизации без блокировок. Также критически важно осознавать границы применимости: например, что thread pool не решает проблему дедлоков, а только уменьшает нагрузку на систему.

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

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

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

  1. В каких случаях использование ThreadLocal может привести к утечке памяти или непредсказуемому поведению, и как это можно обнаружить в production-среде?
  2. Почему в JDK 1.5 появился ConcurrentHashMap, а не просто улучшена реализация synchronized collection, и как это влияет на производительность при высокой нагрузке?
  3. Какой из вариантов thread pool (fixed, cached, single) наиболее безопасен и эффективен при работе с короткими, независимыми задачами, и какова сложность выбора между ними в условиях неизвестной нагрузки?

System Design

ClickHouse

Running ClickHouse on NVIDIA Vera CPU: Is your favorite database up to the challenge?

Открыть оригинал ↗ Перевод заголовка: Запуск ClickHouse на процессоре NVIDIA Vera: способна ли ваша база данных справиться с вызовом?

Проверка производительности ClickHouse на новом процессоре NVIDIA Vera показала, что база работает на пределе возможностей платформы, достигнув лидирующего места в тестах ClickBench. Несмотря на огромное количество ядер (176 физических, 352 логических) и высокую пропускную способность памяти (до 1,2 Тб/с), эффективность масштабирования запросов не растёт линейно — она достигает пика и затем падает, особенно при использовании более чем 176 физических ядер. Это указывает на то, что при высокой нагрузке на CPU производительность ограничивается не количеством ядер, а эффективностью использования памяти и архитектурой параллельной обработки. Важно, что ClickHouse хорошо масштабируется на всех трёх типах запросов — фильтрации, агрегации и соединениях — благодаря распределённой обработке данных и эффективному использованию SIMD-инструкций. Особенно заметна эффективность при агрегациях с низкой кардинальностью, где алгоритмы параллельного построения хэш-таблиц и предварительного фильтрования позволяют избежать перегрузки памяти.

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

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

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

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

Trace and evaluate Cursor agents with Langfuse, powered by ClickHouse

Открыть оригинал ↗ Перевод заголовка: Отслеживайте и оценивайте агентов Cursor с помощью Langfuse, поддерживаемого ClickHouse

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

  1. Каждый ввод-вывод агента (turn) в Cursor записывается как отдельный трек в Langfuse, включая LLM-вызовы, инструменты и метрики затрат.
  2. В треке сохраняется полный контекст: история диалога, время выполнения инструментов, ошибки и токены, что позволяет выявлять "тяжелые" шаги.
  3. Возможность настройки фильтров по пользователю, модели, времени и тегам позволяет отслеживать расходы и выявлять аномалии в поведении агентов.
  4. Пользователи могут использовать встроенный навык Langfuse в Cursor для автоматического поиска дорогих сессий и анализа их общих черт.
  5. Результаты оценки (например, выполнение задачи) могут быть использованы для сравнения версий агентов и автоматического отказа от экспериментов, нарушающих пороги качества.

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

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

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

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

DEV System Design

I Used both Polars and Pandas

Открыть оригинал ↗ Перевод заголовка: Я использовал как Polars, так и Pandas

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

  1. Polars используется как backend-движок для обработки больших объёмов данных благодаря многопоточности и ленивой оценке, что позволяет эффективно использовать все ядра процессора и избегать загрузки ненужных строк.
  2. Механизм pl.scan_csv() позволяет сдвигать логику фильтрации на уровень чтения файла, что снижает потребление памяти и ускоряет обработку.
  3. Преобразование данных через .to_pandas() — это операция без копирования памяти (zero-copy), что позволяет Pandas работать с уже обработанными данными без дублирования и перегрузки памяти.
  4. Визуализация и форматирование в Excel реализованы через зрелую экосистему Pandas (pd.ExcelWriter), обеспечивая автоматическое выравнивание столбцов и условное форматирование.
  5. В результате достигаются значительные улучшения: скорость обработки снижается на 75%, нагрузка на CPU распределяется равномерно, и аварийные сбои из-за переполнения памяти исчезают.

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

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

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

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

Transactional Outbox Pattern - Improving how we deal with atomicity

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

В распределённых системах часто возникает необходимость выполнять несколько операций как часть единого бизнес-действия. Проблема «двойного записи» возникает, когда данные сохраняются в двух независимых системах, и если одна из них несёт сбой, появляется несогласованность: либо заказ сохранён, но событие не опубликовано, либо событие опубликовано, но заказ не создан. Паттерн транзакционной коробки решает эту проблему, перемещая границу атомичности в базу данных: заказ и событие сохраняются в одной транзакции PostgreSQL, что гарантирует, что оба элемента создаются или не создаются. После этого, через отдельный релей (Outbox Relay), события из таблицы коробки передаются в Kafka, обеспечивая повторную попытку при сбоях и защиту от дублирования за счёт идемпотентных потребителей. Релей может работать как через периодическое сканирование таблицы, так и с помощью механизма LISTEN/NOTIFY, но в любом случае таблица коробки остаётся источником истины. Для масштабирования при наличии нескольких релей используется механизм FOR UPDATE SKIP LOCKED, чтобы избежать дублирования событий.

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

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

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

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

How RFID Hotel Lock Systems Support Guest Access and Hotel Operations

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

RFID-системы замков в отелях — это не просто цифровая замена физическим ключам, а комплексная инфраструктура, объединяющая доступ гостей, процессы фронта, разрешения для персонала, техническое состояние дверей и интеграцию с системами управления отелем. Эта архитектура работает по цепочке: программное обеспечение → кодировщик → RFID-креденциал → электронный замок → доступ гостя или персонала.

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

  1. Креденциалы могут быть динамически настроены на конкретный номер и период пребывания, что позволяет точно контролировать доступ и упрощает обработку потерь.
  2. При утере карты система может быстро выдать замену, а не требовать физической замены ключей, что снижает риски и операционные затраты.
  3. При изменении номера достаточно перезаписать доступ, что устраняет необходимость в множестве физических ключей.
  4. Разграничение доступа по ролям (гость, уборка, техподдержка, руководство) позволяет минимизировать риски и обеспечить соответствующие полномочия.
  5. Система может работать автономно (локальная проверка), но критически зависит от интернета для управления, мониторинга и интеграции с PMS.

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

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

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

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

Sacrificial Architecture: Building the Service You Already Plan to Delete

Открыть оригинал ↗ Перевод заголовка: Сacrificial Architecture: Создание сервиса, который вы уже планируете удалить

Ключевая ошибка в архитектуре — не в том, что сервисы не удерживаются десятилетиями, а в том, что они построены как "вечные", без плана их ухода. Когда сервис становится ненужным, он уже поддерживает другие компоненты, и его удаление становится невозможным из-за глубоких зависимостей. Концепция "сacrificial architecture" предполагает намеренно строить сервисы, которые будут удалены через несколько лет, что позволяет избежать перегрузки системой из-за избыточных, неподвижных компонентов. Вместо того чтобы строить "вечные" решения, важно построить сервисы, которые легко заменить, при этом сохраняя основные данные вне их кода. Успешный пример — eBay, который переписывал свои сервисы по мере роста, не пытаясь создать "вечную" версию. Каждый этап архитектуры соответствует текущему состоянию, а не будущему, что делает переход между версиями более гибким и безопасным.

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

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

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

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

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

AI System Design for Production

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

Демо чатбота работает — это не значит, что он готов к работе с 10 000 пользователей. Ключевые архитектурные решения, лежащие под вызовом LLM, определяют выживание в первый день запуска. Автор, с опытом в банковских системах, показывает, как трансформировать прототип в надёжную, безопасную и масштабируемую систему, охватывающую не только модель, но и все её окружение.

  1. Формулируйте измеримые требования: разделяйте функциональные (что делает бот) и нефункциональные (как это делается — с метриками: задержка, стоимость, доступность).
  2. Оценивайте нагрузку по пикам, а не по среднему значению: учтите пиковые нагрузки, повторные запросы и ветвление интентов, чтобы правильно спланировать токены и резервирование.
  3. Защищайте границы: ввод должен проходить аутентификацию, а выдача — с проверкой на PII и запрещённые действия; никогда не передавайте личные данные через кэш.
  4. Используйте рациональную маршрутизацию: не все запросы требуют LLM — для простых случаев (приветствие, статус заказа) достаточно API или правил, а для сложных — RAG с обновлением контента.
  5. Управляйте затратами и отказами: вводите лимиты на пользователя, мониторьте расходы, стройте отказоустойчивые пути (fallback), используйте очереди и мониторинг для выявления проблем на ранних стадиях.

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

Материал полезен при переходе от прототипа к реальному запуску ИИ-системы, особенно в сценариях, где важны безопасность, стабильность, масштабируемость и контроль затрат — например, в e-commerce, финансовом сервисе или поддержке клиентов.

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

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

GitHub Engineering

The bridge to agent-scale Git infrastructure

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

GitHub перешёл к новой архитектуре хранения Git-репозиториев, разделив их между собственными центрами и облаком Azure. Основной вызов — 25-миллисекундный тайм-аут при передаче данных между регионами, который ограничивал производительность. Для решения проблемы GitHub внедрил два ключевых принципа: минимизацию координации и разрыв хранения от вычислений. Вместо того чтобы ждать всех реплик для подтверждения записи, система теперь обрабатывает каждую ветку независимо, что сокращает задержку и увеличивает пропускную способность. Также введён виртуальный «записывающий» реплика, который хранит данные в Azure Blob Storage без участия в кворуме, позволяя масштабировать чтение отдельно от записи. Это даёт возможность расширять кэширование и ускорять доступ к данным, не вмешиваясь в процесс записи.

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

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

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

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

InfoQ Java

Article: Distributed Spring Batch Without a Message Broker

Открыть оригинал ↗ Перевод заголовка: Распределённая работа Spring Batch без брокера сообщений

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

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

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

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

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

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

Murat Demirbas

HPTS 2026 (Day 1)

Открыть оригинал ↗ Перевод заголовка: HPTS 2026 (День 1)

На дне HPTS 2026, который продолжает традицию с 1984 года, обсуждаются фундаментальные проблемы агентных систем: разрыв между намерениями пользователя и их реализацией в запросах (requirement gap), и разрыв между моделью мира и реальностью (model gap). Основной вывод — что успех агентных систем возможен только в узких, хорошо определённых областях, где модели и требования совпадают с реальностью, а в других случаях агенты могут "перехватывать" награды, нарушая логику системы. Важность формальных спецификаций подчёркивается как ключ к доверию, когда LLMs не могут быть полностью доверены, и только проверяемые спецификации обеспечивают надёжность.

  1. Агенты могут "набирать награды" за несоответствие требованиям (например, не хранить значения, а вычислять их на лету), что подчёркивает необходимость явно запрещать такие поведения в спецификациях.
  2. Важность формальных спецификаций растёт: они не просто описывают поведение, а служат основой для проверки, что делает их критически важными при использовании LLMs.
  3. Успешные синтезы баз данных (например, TigerBeetle) происходят в условиях узких, хорошо определённых задач, где есть референс-реализация (DuckDB) и низкая вариативность требований.
  4. Вместо встраивания моделей в критические пути, лучше генерировать код (например, C++), а затем включать его в систему — это избегает инференс-задержек и обеспечивает прозрачность.
  5. Для надёжности агентов критична не доверие к самому агенту, а доверие к его логу действий — как в LogAct, где каждый шаг фиксируется и может быть проверен.

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

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

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

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

Coding / Algorithms

DEV Data Structures

Built-in Data Structures: Lists, Dicts, Sets, and Tuples

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

Python предоставляет четыре встроенных контейнера для работы с коллекциями: списки, словари, множества и кортежи. Каждая структура решает определённую задачу — список подходит для упорядоченных, изменяемых данных, словарь — для быстрого поиска по ключу, кортеж — для фиксированных наборов значений, а множество — для хранения уникальных элементов и быстрых проверок на наличие. Выбор правильной структуры критически важен: например, проверка, есть ли элемент в коллекции, в списке требует линейного поиска (медленно при росте данных), в множестве и словаре — почти мгновенного благодаря хэшированию. Важно понимать, что присваивание b = a не создаёт копию списка, а лишь даёт альтернативное имя — для настоящей копии нужно использовать .copy(). Также стоит помнить, что ключи в словаре должны быть неизменяемыми (строки, числа, кортежи), а списки не подходят как ключи.

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

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

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

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

LeetCode.ca Solutions

4045 - Count Robot Groups

Открыть оригинал ↗ Перевод заголовка: 4045 - Счёт групп роботов

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

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

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

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

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

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