Risk Management

arXiv Quantitative Finance - Pricing

Market Efficiency in a Changing Asset Population: Mobility, Entry, and Survival over Cryptocurrency's Full History

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

Статья исследует, насколько криптовалютный рынок соответствует гипотезе слабой эффективности, анализируя движение активов по распределению капитализации с 2013 по 2026 год. Авторы используют полную историю 8970 активов с еженедельными сечениями, где отслеживается не только движение, но и фактические входы, выходы и выживание активов. Результаты показывают, что симметрия в переходах между активами отклоняется во всех периодах, однако степень асимметрии снижается на 70%, что указывает на доминирование входного составного потока (вход новых активов) вместо влияния на оценку самих криптовалют. Особенно важно, что нижний десяток активов обеспечивает высокую доходность в теории (27,5% в неделю), но при этом не приносит прибыли на практике, когда речь идёт о торговых активов с объёмом до $293 000 — компенсация за игнорирование наблюдается именно там, где торговля отсутствует.

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

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

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

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

Inverse Learning of Latent Risk-Neutral Densities from Irregular Option Quotes

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

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

  • Двухкомпонентный логнормальный смешанный распределение показывает наименьшие ошибки по ценам, $L^1$, Вассерштейну и в хвостах на синтетических данных.
  • DeepONet улучшает ошибки в 1%-ном квантиле и варииации относительно смешанного распределения на 39% и 34% соответственно.
  • Трансформер снижает $L^1$-ошибку на 16,4% при структурно неправильной модели Мертона.
  • После наложения ограничений по массе и фронтальной консистентности 95 из 126 направлений цен становятся численно нулевыми, что объясняет нечувствительность моделей к некоторым ценам.
  • На реальных данных (524 NIFTY-опциона) адаптация на этапе валидации сокращает RMSE DeepONet на 28,3%, но смешанные распределения и SVI остаются более точными в долгосрочной перспективе.

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

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

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

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

arXiv Quantitative Finance - Risk Management

Agentic AI in Automated Markets

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

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

  1. Ретейл-следователи вызывают частые, но кратковременные эпизоды стресса, что указывает на уязвимость к массовому поведению.
  2. Манипуляторы создают редкие, но длительные периоды стресса, что демонстрирует потенциал для системных рисков.
  3. Рациональные агенты обеспечивают стабильные показатели Шарпа, несмотря на высокую волатильность доходов, что свидетельствует о их устойчивости к рыночным шокам.
  4. SHAP-анализ показывает, что волатильность и сигналы межактивных рынков напрямую связаны с поведением агентов.
  5. Рекомендуется внедрение поведенческих норм, а не универсальных лимитов, для более точного управления рисками.

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

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

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

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

AI

Habr AI

Ouroboros, очередной инструмент для вашего harness

Открыть оригинал ↗ Перевод заголовка: Ouroboros, очередной инструмент для вашего harness

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

  1. Основная цель — заменить написание тестов агентом на отладку кода через логирование, что снижает барьер для входа в разработку.
  2. Инструмент встраивается в код как обёртка вокруг функций, генерируя структурированные логи с именем функции, аргументами и результатами.
  3. Показатели производительности демонстрируют незначительный рост времени выполнения (до 50 мкс), что делает его применимым в разработке.
  4. Повышается точность ответов агентов (на 20–35 процентных пунктов), особенно при работе с большими базами кода.
  5. Поддерживается как через бинарные, так и через интеграцию с агентами, с документацией на русском и датасетами для обучения.

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

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

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

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

Синтетическая эмпатия: как RAG, системные промпты и TTS инженерят привязанность к LLM-агентам

Открыть оригинал ↗ Перевод заголовка: Синтетическая эмпатия: как RAG, системные промпты и TTS инженерят привязанность к LLM-агентам

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

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

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

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

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

Интерпретируемость LLM доказана?

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

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

  1. Слабые активации не являются второстепенными — они критичны для распознавания границ между близкими классами, особенно на пограничных примерах.
  2. Метод абляции 75% хвоста может создавать иллюзию стабильности сети, так как он не учитывает важность границ классов в реальных задачах.
  3. Эксперименты на простых моделях (MLP-512) показывают, что удаление хвоста активаций приводит к значительному падению точности на критических примерах, что противоречит утверждению о их второстепенности.
  4. Интерпретируемость LLM не доказана — проверка через абляцию хвоста не охватывает ключевые кейсы, где модель использует тонкие различия.

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

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

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

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

Хотел поручить AI целый проект. Уперся в изоляцию, память и восстановление после сбоев

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

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

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

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

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

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

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

Замена Lens, которую целиком написала модель: что получилось и где мы проигрываем

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

Проект Sextant — десктопный Kubernetes-клиент на Rust и Tauri — полностью сгенерирован ИИ (Claude Code), не содержит коммерческих элементов и работает без аккаунтов, телеметрии или подписок. Он решает три ключевые боли Lens: коммерциализацию, нестабильность и ограниченное развитие, предлагая бесплатный, быстрый и безопасный инструмент с полным контролем над памятью и доступом к кластерам. Важные достижения включают управление потоками в терминале, отказ от утечек памяти, живые таблицы ресурсов, GitOps-интеграцию и безопасный доступ для AI-агентов через MCP-сервер с проверкой прав и журналом действий.

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

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

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

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

InfoQ Architecture

AWS Introduces Preview of Well-Architected Agent

Открыть оригинал ↗ Перевод заголовка: AWS представляет предварительную версию агента Well-Architected

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

  1. Рекомендации генерируются на основе бизнес-целей, которые должны быть заранее определены пользователем, что поднимает вопрос о реальности и доступности этих целей в большинстве организаций.
  2. Агент может проверять инфраструктурный код (Terraform, CloudFormation) перед деплоем и предлагать исправления через CLI или IaC, но переход от рекомендаций к автоматизированным действиям требует осторожности из-за возможных противоречий между пилларами.
  3. Рекомендации могут содержать ошибки или быть неполными, и их необходимо оценивать в контексте конкретной среды с вовлечением экспертов.
  4. Доступ ограничен тремя регионами США и только для клиентов с планом Business Support+ или выше, что ограничивает масштабируемость и доступность.
  5. Возможность интеграции через API и AWS MCP Server позволяет встраивать рекомендации в CI/CD, но требует проверки надёжности и согласованности рекомендаций в production-средах.

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

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

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

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

Java / Spring

Alexander Obregon

Weekly Recap – October 18th, 2026

Открыть оригинал ↗ Перевод заголовка: Еженедельный обзор – 18 октября 2026 года

В прошлой неделе автор опубликовал две статьи: одну о работе с загрузкой файлов в Spring Boot, где рассматриваются мультиплетные запросы, валидация файлов и их хранение, и другую — о применении оператора PIVOT в SQL Server для преобразования строк в столбцы. Эти темы стали наиболее популярными у читателей, что подтолкнуло автора к размышлению о запуске новой серии статей, в которой он может углубиться в уже изученный язык или перейти к чему-то новому. В перспективе он стремится к регулярному публикованию — три статьи в неделю — и уже планирует ввести третий серийный формат.

  1. В Spring Boot важно правильно обрабатывать мультиплетные запросы, чтобы избежать ошибок при загрузке больших файлов или валидации формата.
  2. Оператор PIVOT в SQL Server позволяет трансформировать данные из таблицы с разными значениями в столбцы, но требует тщательного планирования структуры запроса и выбора условий агрегации.
  3. Автор оценивает баланс между углублением в уже знакомые технологии и экспериментами с новыми языками — это влияет на стратегию контента.

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

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

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

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

Engineering With Java

Engineering With Java: Digest #108

Открыть оригинал ↗ Перевод заголовка: Инженерия на Java: Дигест №108

В этом выпуске рассматриваются ускорение старта Java-сервера, безопасные механизмы обмена токенами в Spring Security 7, лёгкая мониторинговая система для Spring Boot без Prometheus и Grafana, а также перспективы Java 28 и роль искусственного интеллекта в разработке. Особое внимание уделено практическим аспектам: снижению затрат на токены в AI-разработке, защите от атак SSRF в Spring Boot 4.1 и эффективному управлению файловыми загрузками.

  1. Использование ZGC в JDK 28 (JEP 545) позволяет сократить время запуска и прогрева приложения, что особенно важно для сервисов с высокой нагрузкой на старт.
  2. Spring Security 7 внедряет DPoP и механизм обмена токенами для безопасного взаимодействия сервисов, обеспечивая минимальные привилегии и защиту от перехвата токенов.
  3. StatLite — простой мониторинг Spring Boot на базе Actuator и Micrometer, который заменяет сложные стеки Prometheus и Grafana для небольших сервисов.
  4. Встроенный механизм SSRF-защиты в Spring Boot 4.1 через InetAddressFilter делает безопасность HTTP-запросов единым компонентом, а не разрозненными решениями.
  5. Появление легковесного JSON-API в Java 28 (JEP 540) упрощает работу с JSON без сторонних библиотек, делая его доступным для базовых задач.

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

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

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

  1. В каких сценариях JEP 545 по ускорению запуска Java может привести к неожиданному поведению при использовании ZGC, и как это может повлиять на производительность при резких пиковых нагрузках?
  2. Какова граница применимости DPoP в Spring Security 7 для сервисов, где требуется поддержка устаревших протоколов или нестандартных аутентификационных методов?
  3. При каких условиях StatLite может быть менее эффективен, чем полноценная интеграция с Prometheus и Grafana, и как это влияет на надёжность мониторинга в критически важных системах?

HowToDoInJava

Spring Boot and Vaadin CRUD Example

Открыть оригинал ↗ Перевод заголовка: Пример CRUD с Spring Boot и Vaadin

В этом руководстве создаётся веб-приложение на Java 21 с использованием Spring Boot 4 и Vaadin 25, где Vaadin отвечает за отображение интерфейса (таблицы и формы), а Spring Boot с JPA управляет взаимодействием с базой данных. Пример реализует полноценную систему CRUD на одной странице без использования HTML или JavaScript. Важно, что в Vaadin 25 отсутствует автоматическая загрузка темы, поэтому требуется явно указать стиль (Lumo), иначе интерфейс будет выглядеть неудобно. Ключевым моментом является использование BeanValidationBinder, который обеспечивает корректную передачу валидационных правил из сущности в форму, в отличие от простого Binder, который игнорирует аннотации @NotBlank. Также важно понимать, что при работе с большими объёмами данных (тысячи строк) необходимо использовать пагинацию в Grid, иначе будет происходить перегрузка памяти.

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

Материал полезен при разработке быстрых MVP-приложений с минимальным количеством кода, где требуется визуальный интерфейс и работа с базой данных без вмешательства в HTML или JavaScript. Особенно подходит для образовательных целей, демонстрации архитектуры Spring Boot + Vaadin и для быстрых прототипов, где важна скорость развертывания и понятность кода.

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

  1. Как изменить поведение валидации при вводе в форме, если пользователь вводит текст, но не соответствует правилу @NotBlank — будет ли ошибка отображаться в интерфейсе, если валидация провалена на уровне JPA, а не в форме?
  2. В каких условиях использование BeanValidationBinder может привести к нежелательным эффектам, например, при работе с валидацией в расширенных сценариях (например, с валидацией по регулярному выражению или с поддержкой нескольких языков)?
  3. Какова оценка производительности при использовании Grid с пагинацией на больших объёмах данных (например, 10 000 строк), и как это влияет на выбор между setItems(list) и пагинационным подходом в setItems()?

Prompt Injection in LLM Apps: Risks and Defenses

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

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

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

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

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

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

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

Fine Tuning vs RAG vs Prompt Engineering for LLM Apps

Открыть оригинал ↗ Перевод заголовка: Файн-тюнинг, RAG и промптовая инженерия для приложений на основе ЛЛМ

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

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

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

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

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

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

Run LLMs Locally: Ollama, LM Studio & Docker Model Runner

Открыть оригинал ↗ Перевод заголовка: Запуск больших языковых моделей локально: Ollama, LM Studio и Docker Model Runner

Для запуска больших языковых моделей (LLM) локально используется локальный запускатель, который загружает открытую модель и запускает её на собственном компьютере, обеспечивая, что запросы остаются на устройстве и не требуют оплаты. В статье сравниваются три популярных решения — Ollama, Docker Model Runner и LM Studio — и демонстрируется один универсальный класс на Java 17, использующий встроенный в JDK HttpClient без дополнительных фреймворков. Каждый из запускаторов предоставляет OpenAI-совместимый API, что позволяет использовать один и тот же код для взаимодействия с ними, меняя лишь базовый URL и имя модели. Класс отправляет запрос в формате OpenAI, включая системное сообщение и пользовательский вопрос, и извлекает ответ из поля choices[0].message.content.

  • Все три решения поддерживают OpenAI-совместимый API, что позволяет использовать один и тот же клиентский код для всех из них.
  • Оллама — простой инструмент для пользователей без Docker, с удобной командной строкой и встроенной GUI.
  • Docker Model Runner идеально подходит для пользователей, уже работающих в Docker Desktop, с минимальными настройками и встроенной интеграцией.
  • LM Studio предлагает полноценную GUI для просмотра и тестирования моделей, что полезно при выборе и оценке моделей.
  • Для работы с моделями требуется точное совпадение имени модели (с тегом, например, qwen2.5:0.5b), и настройка TCP-доступа в Docker Desktop обязательна для подключения к порту 12434.

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

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

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

  1. Какой из трёх запускаторов наиболее эффективен при работе с моделями на 3–7 миллиардов параметров на компьютере с 16 ГБ ОЗУ и без GPU, и почему?
  2. В каких сценариях может привести к нестабильности использование Docker Model Runner без включённого host-side TCP, и как это влияет на производительность при запуске в production?
  3. Какой из запускаторов наиболее подходит для интеграции в CI/CD-процесс, где требуется минимальное количество зависимостей и стабильность настройки?

RAG Explained: Retrieval Augmented Generation for Java

Открыть оригинал ↗ Перевод заголовка: RAG объяснён: ретриев-усиленное генерирование для Java

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

  1. Важно понимать, что LLM не знает содержимое собственных документов — они не участвовали в обучении модели.
  2. RAG работает в трёх фазах: индексация (разбиение документов на куски, векторизация и хранение), поиск (поиск похожих кусков на основе вопроса) и генерация (сборка промпта с найденными кусками и отправка к LLM).
  3. Ключевые компоненты: кусок документа (небольшой смысловой фрагмент), векторизация (преобразование текста в числовое представление), вектор-хранилище (список кусков с векторами), схожесть по косинусу (оценка близости текстов), параметр top-k (количество возвращаемых кусков).
  4. В примере используется встроенный в JVM-модель embedding (all-MiniLM-L6-v2), Ollama для запуска LLM, и простой Java-список как хранилище — всё работает без интернета и API-ключей.
  5. Критически важно, чтобы каждый кусок имел смысл в отдельности и содержал идентификатор документа (например, заголовок), иначе поиск может ошибочно выбирать неподходящий фрагмент.

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

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

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

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

Kafka MockConsumer and MockProducer Example (JUnit 6)

Открыть оригинал ↗ Перевод заголовка: Пример использования MockConsumer и MockProducer (JUnit 6)

В этой статье демонстрируется, как проводить единичные тесты кода, работающего с Kafka, без запуска брокера. Для этого используются встроенные в библиотеку kafka-clients тестовые компоненты MockProducer и MockConsumer, которые позволяют проверять, как код отправляет и читает сообщения, без подключения к реальному брокеру. В примере реализован сервис заказов книг, где публикатор отправляет события в топик, а агрегатор собирает статистику по количеству заказов на каждый ISBN. Ключевым моментом является то, что оба компонента принимают в конструкторе не реализованный KafkaProducer или KafkaConsumer, а интерфейсы, что делает их легко заменяемыми на моки в тестах.

  1. Классы должны принимать Kafka-клиенты в конструкторе, а не создавать их самостоятельно — это делает код поддающимся тестированию без брокера.
  2. MockProducer сохраняет историю отправленных сообщений через метод history() и может имитировать сбои при отправке с помощью errorNext().
  3. MockConsumer возвращает сообщения, добавленные через addRecord(), и может вызывать ошибку при poll() с помощью setPollException().
  4. Для корректной работы MockConsumer необходимо сначала вызвать assign() и updateBeginningOffsets(), иначе возникает исключение при добавлении записей.
  5. В Kafka 4.x требуется четырёхаргументный конструктор MockProducer — устаревший трёхаргументный не компилируется.

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

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

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

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

nipafx

Modern Java - Past | Present | Future

Открыть оригинал ↗ Перевод заголовка: Современный Java — прошлое, настоящее и будущее

Статья описывает эволюцию языка Java от ранних версий до современных возможностей и прогнозирует дальнейшее развитие. Автор подчёркивает, что Java уже проделал значительный путь — от введённых в 2020 году паттернов распознавания (pattern matching) до внедрения виртуальных потоков и улучшений при запуске приложения. В будущем ожидается расширение языка за счёт ввода ценовых типов (value types), структурированной конкуренции и улучшения типовой системы, а также появление интегрированных возможностей для работы с данными и нативного AI.

  1. Введение value types (типов значений) позволит упростить управление объектами и снизить затраты на копирование, особенно в задачах, связанных с данными.
  2. Структурированная конкуренция (structured concurrency) улучшит управление потоками выполнения в многопоточных приложениях, обеспечивая более чёткую и надёжную структуру контроля.
  3. Улучшения в типовой системе и runtime могут привести к более точной и эффективной типизации, что снизит количество ошибок и ускорит компиляцию.
  4. Развитие данных-центрированного программирования означает, что Java будет лучше интегрировать работу с данными, включая автоматизацию и анализ.
  5. Нативные возможности AI могут позволить Java выполнять задачи машинного обучения и обработки данных прямо в JVM без внешних библиотек.

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

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

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

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

System Design

DEV System Design

Stop Rambling in System Design Interviews — 3 Frameworks That Fix It

Открыть оригинал ↗ Перевод заголовка: Остановите рамbling в интервью по системному дизайну — 3 структуры, которые это исправляют

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

  1. RADIO-фреймворк обеспечивает последовательность ответа: от определения требований до оптимизаций, каждый шаг — это логичный шаг в развитии идеи.
  2. Многоуровневый чек-лист дополняет RADIO, давая конкретные элементы для развертывания архитектуры (например, разделение контрольной и данных плоскостей, асинхронность, наблюдаемость).
  3. Метод скоуп-первым помогает в первые 15 минут интервью — через точные оценки масштаба (пользователи, QPS, объём данных) и определение критических требований, устанавливает фокус и обосновывает последующие решения.

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

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

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

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

Case Study: Eliminating a Single Point of Failure

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

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

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

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

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

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

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

Designing a Distributed Cache Inspired by The Lord of the Rings: One Insight to Rule Them All

Открыть оригинал ↗ Перевод заголовка: Проектирование распределённого кэша, вдохновлённого «Властелином Колец»: одна идея, которая управляет всеми

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

  1. Вместо прямого присвоения ключа физическому узлу используется хеширование на кольце с виртуальными узлами (токенами), что позволяет равномерно распределять нагрузку и избегать «горячих точек».
  2. При добавлении или удалении узла перераспределяются лишь ключи, относящиеся к токенам этого узла — доля перераспределённых ключей составляет около 1 / (количество узлов × количество виртуальных токенов), что значительно меньше, чем при модульной схеме.
  3. Реализация основана на сортированном списке хеш-значений, что позволяет выполнять поиск по ключу за O(log N) времени с низкой константой.
  4. При удалении узла необходимо удалить его токены из кольца, иначе запросы будут направляться на несуществующий узел.
  5. Важно выбирать несмещённую хеш-функцию (например, FNV или MurmurHash), чтобы избежать дрейфа кольца между разными средами выполнения.

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

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

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

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

Building a Job Portal Backend: From Database Design to Deployment

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

Проект представляет собой многокомпанийский портал вакансий, построенный на Node.js, TypeScript, PostgreSQL, Redis, BullMQ и Docker. Система обеспечивает строгий контроль доступа по ролям (админ, рекрутер, кандидат) и полную изоляцию данных между компаниями, охватывая весь жизненный цикл: настройку компании, публикацию вакансий, обработку заявок, планирование собеседований и обратную связь, модерацию, асинхронную обработку писем и резюме, ограничение скорости запросов, структурированное логирование и плавное завершение работы.

Ключевые технические решения включают: выбор реляционной базы данных вместо документной из-за необходимости поддерживать целостность данных и транзакции; использование прямого SQL для избежания N+1 и оптимизации производительности; применение кривой пагинации (cursor) вместо offset для стабильности при динамическом изменении данных; отсутствие хранения файлов в базе данных в пользу S3 с пресigned URL; двойную аутентификацию (токен доступа + токен обновления) с хэшированием и ограничением срока действия; полную изоляцию между компаниями через запросы в бэкенде, а не через параметры запроса; использование внешних сервисов для асинхронной обработки и логирования.

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

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

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

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

Case Study: An MTTI-Driven Incident Reduction Program

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

Платформа, испытывающая частые повторяющиеся сбои при каждом релизе, перешла от измерения скорости восстановления (MTTR) к оценке скорости понимания сбоев (MTTI). Вместо того чтобы просто ускорять реакцию на инциденты, команда начала фокусироваться на глубоком понимании причин сбоев, что позволило выявить и устранить структурные причины.

  1. Внедрение MTTI требует не просто ускорения реакции, а создания инструментов для глубокого анализа — распределённого трейсинга, воспроизводимых сред и детальных аудитов после инцидентов.
  2. Устранение повторяющихся сбоев происходит не за счёт быстрого восстановления, а за счёт системного понимания их корней, что приводит к долгосрочному уменьшению рисков.
  3. Дашборды перестали быть хаотичными и неинформативными — они стали рабочими инструментами диагностики, что улучшает принятие решений в реальном времени.
  4. Основной компромисс — сдвиг с «быстрого восстановления» на «глубокое понимание» требует значительных ресурсов и культуры, но даёт устойчивый эффект.
  5. MTTI не заменяет MTTR, а дополняет его, делая систему более устойчивой к повторяющимся сбоям.

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

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

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

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

What Does It Take to Vibe Code a Truck?

Открыть оригинал ↗ Перевод заголовка: Что нужно, чтобы «вibe-кодировать» грузовик?

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

  1. Требуется полный системный дизайн: от сенсоров (радаров, ЛИДАРов) до вычислительных ресурсов, моделей и безопасности, с учётом условий работы (дождь, пыль, ночь).
  2. Каждый элемент зависит от других: изменение сенсора влияет на вычислительные мощности, а смена страны — на регуляторные требования.
  3. Доменные знания должны быть доступны и проверяемы — не как «взвешенные» параметры, а как контекст, который модель может интерпретировать и адаптировать.
  4. Вместо тонких настройки моделей (fine-tuning) используется механизм сжатия и расширения знаний — «сжатие» опыта в принципы, а «расширение» — в новые сценарии.
  5. Проверка качества через PADI (Physical AI Design Index) показывает, что платформа Praxis превосходит передовые ИИ-модели на новых задачах, несмотря на отсутствие предварительного обучения.

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

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

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

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

# A correction needs a provenance trail

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

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

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

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

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

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

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

Why Your Database Design Should Start with Access Patterns — Not Tables.

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

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

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

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

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

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

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

Habr Distributed Systems

SQL, NoSQL, NewSQL, Distributed SQL: как читать архитектуру СУБД

Открыть оригинал ↗ Перевод заголовка: SQL, NoSQL, NewSQL, Distributed SQL: как читать архитектуру СУБД

История развития баз данных не является линейной последовательностью SQL → NoSQL → NewSQL, как часто представляется. Распределённые реляционные СУБД существовали задолго до появления термина NewSQL, а NoSQL объединял разнородные системы с разными моделями данных и гарантиями. Термин NewSQL изначально охватывал широкий спектр высокопроизводительных SQL-систем, но со временем стал неудобным, поскольку под ним скрывались принципиально разные архитектуры — от систем с оптимизированным движком в памяти до распределённых систем с сетевой координацией транзакций. Вместо того чтобы использовать «NewSQL» как универсальный маркер, сегодня важнее анализировать конкретные архитектурные особенности: распределение данных, репликация, транзакционные гарантии и реакция на отказы.

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

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

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

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

Hands-on System Design with Java Spring Boot

Day 79: Distributed Rate Limiting II - Writing Atomic Lua Scripts for Redis

Открыть оригинал ↗ Перевод заголовка: День 79: Распределённое ограничение скорости II — написание атомических скриптов на Lua для Redis

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

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

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

  3. Какова сложность (в терминах времени и памяти) выполнения атомического Lua-скрипта по сравнению с последовательными вызовами Redis, и как это влияет на производительность при высокой нагрузке?

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

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

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

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

Coding / Algorithms

DEV Data Structures

Segment Trees and Fenwick Trees (Binary Indexed Trees): Efficient Range Queries and Point Updates

Открыть оригинал ↗ Перевод заголовка: Сегментные деревья и деревья Фенвика (бинарные индексированные деревья): эффективные запросы по диапазону и обновления по точкам

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

  1. Сегментные деревья обеспечивают гибкость при работе с произвольными операциями (сумма, минимум, максимум), но требуют значительной памяти и сложной реализации ленивой синхронизации.
  2. Дерево Фенвика (Binary Indexed Tree) более компактно и эффективно в реализации, особенно при использовании битовой операции i & (-i) для поиска минимального бита, но ограничено типами данных и операциями.
  3. При работе с обновлениями и запросами в реальном времени важно учитывать ленивую синхронизацию и возможность каскадных сбоев при необработанных граничных случаях.
  4. В производственной среде обе структуры должны быть интегрированы с механизмами отказоустойчивости, лимитированием ресурсов и наблюдаемостью.

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

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

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

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

DEV LeetCode

1569. Number of Ways to Reorder Array to Get Same BST

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

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

  1. Число способов перестановки вычисляется как биномиальный коэффициент C(n−1, |left|), учитывающий размещение элементов левого поддерева в оставшихся позициях.
  2. Для каждого поддерева рекурсивно вычисляется количество допустимых порядков, при этом внутренний порядок элементов должен сохраняться.
  3. Используется предварительное вычисление факториалов и их модульных обратных по теореме Ферма для эффективного вычисления комбинаторных коэффициентов.
  4. Окончательный ответ получается как произведение интерлейдинг-контролей и поддеревьев, минус 1 (исходный порядок).
  5. При пустом или однозначном поддереве количество способов равно 1, так как нет вариантов перестановки.

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

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

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

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

LeetCode.ca Solutions

4042 - Valid K-Unique Subarrays II

Открыть оригинал ↗ Перевод заголовка: 4042 - Валидные подмассивы с k уникальными элементами II

Задача проверяет, является ли подмассив с заданными границами валидным: он должен содержать ровно k различных чисел, и каждое из них должно встречаться чётное количество раз. В отличие от предыдущей версии, запросы генерируются динамически на основе результата предыдущего: если предыдущий подмассив был валидным, то новые границы вычисляются по формуле l_i = (l_{i-1} XOR g_{i-1}) % n и r_i = (r_{i-1} XOR g_{i-1}) % n, где g_{i-1} — сумма или разность предыдущих границ в зависимости от результата. Если валидность была нулевой, то g берётся как разность границ. После вычисления границ проверяется валидность подмассива, и процесс повторяется q раз.

  1. Для проверки валидности подмассива требуется быстро определить количество уникальных значений и их частоты — это делается с помощью префиксных структур или хэш-списков по значениям.
  2. Валидность подмассива зависит от того, что все частоты уникальных элементов чётны и их количество равно k — это требует проверки не только количества уникальных элементов, но и их распределения.
  3. Генерация новых границ зависит от предыдущего результата: при успехе — используется сумма границ, при неудаче — разность, что может привести к нестабильной динамике и выходу за пределы массива.
  4. Алгоритм требует O(1) или O(log n) времени на проверку каждого запроса, чтобы обрабатывать до 5×10⁵ запросов в реальном времени.
  5. При больших n и q важно, чтобы префиксные структуры не занимали слишком много памяти и не требовали пересчёта при каждом запросе.

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

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

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

  1. Какой компромисс между памятью и скоростью в реализации структур для подсчёта частот уникальных элементов при k до 5×10⁵, если нужно поддерживать O(1) проверку валидности для каждого запроса?
  2. При каких условиях генерация границ по XOR и разности может привести к циклическим или деградированным последовательностям запросов, и как это может повлиять на качество тестирования?
  3. Какова сложность проверки валидности подмассива при k=1, если в подмассиве есть элементы с нечётной частотой, и как это влияет на выбор структуры хранения частот?