AI

Habr AI

Нейросеть по рецепту: вычисляем веса вместо хранения матриц

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

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

  • Вместо хранения полных матриц весов модели сохраняются небольшие генераторы (например, нейросети или функции), позволяющие динамически вычислять веса во время работы.
  • Методы, такие как гиперсети или координатные модели, сокращают размер модели на диске в десятки или сотни раз, но требуют вычислительных затрат при каждом проходе.
  • Практическая реализация показывает, что даже при сжатии на диске до 130 МБ для GPT-2, память и время выполнения остаются высокими, а качество предсказаний может ухудшаться без дополнительного дообучения.
  • Подходы работают лучше на небольших моделях и простых задачах, но не позволяют запускать крупные LLM на слабых устройствах без значительных потерь в производительности и точности.
  • Критически важный компромисс: сжатие на диске не означает сокращение потребления памяти или времени — восстановление весов в реальном времени остаётся основным барьером.

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

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

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

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

Детектор ИИ-текста своими руками: какие признаки нейрослопа ловит код и какие остаются живому редактору

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

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

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

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

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

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

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

Latent Space

Building AI for Reliable Execution: Lessons From Industrial Robotics

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

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

  1. Использование целенаправленных данных и в-ситу коррекций позволяет эффективно решать конкретные задачи, даже при отсутствии больших объёмов данных — это критически важно для промышленных сценариев с высокими требованиями к надёжности.
  2. Локальный инференс на роботах, с использованием edge GPU и внутреннего Ethernet, обеспечивает стабильность и безопасность, особенно в условиях отсутствия стабильного интернета.
  3. Модели не являются полностью независимыми от аппаратуры — Standard Bots интегрирует AI и контрольные алгоритмы на уровне аппаратного обеспечения, что позволяет оптимизировать работу на всех уровнях.
  4. Ошибки в производственных задачах фиксируются и используются для обучения, особенно в не-вакуумных средах, где данные возвращаются в систему.
  5. Платформа StandardOS предоставляет API и SDK, позволяя внешним разработчикам интегрировать модели и создавать приложения, включая возможность использования собственных моделей.

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

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

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

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

Java / Spring

Foojay

Media Partner for OCX27 and jChampions Conference 2027

Открыть оригинал ↗ Перевод заголовка: Медиа-партнёр по OCX27 и конференции jChampions 2027

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

  1. Для OCX 2027 (13–15 апреля 2027 г.) открыта подача заявок на доклады — участники могут представить свои работы в рамках международного формата, включая технические и социальные аспекты открытых сообществ.
  2. jChampions 2027 (21–22 и 25–26 января 2027 г.) — полностью онлайн-событие с 7 сессиями в день, ведётся на StreamYard и транслируется на YouTube, с возможностью подачи докладов на любой язык (но ревью — на английском).
  3. Участники jChampions должны быть Java Champion, но могут присоединяться к докладу с коллегой без этого статуса; доклады длительностью один час с вопросами от аудитории.

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

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

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

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

Habr Spring

У нас есть MCP дома

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

Автор рассказывает о создании собственного MCP-сервера для интеграции с Jira, Confluence и GitLab в корпоративной среде. Вместо использования готовых открытых решений, команда выбрала реализовать свой сервер из-за серьёзных недостатков в существующих проектах: отсутствие авторизации, плохая расширяемость, непроверенный код и риски промпт-инъекций. Сервер построен на Java 25, Spring Boot 4.1 и Spring AI 2.0, с поддержкой двух транспортных протоколов (streamable-http и stdio), шифрованием секретов в Vault и интеграцией с Keycloak для авторизации через корпоративный AD.

  1. Реализован гранулярный доступ: каждый пользователь видит только свои токены, а администратор не видит данных других пользователей.
  2. Весь процесс авторизации и обработки токенов происходит в изолированной среде — токены расшифровываются только в рамках вызова и не хранятся в открытом виде.
  3. Интеграции генерируются автоматически из OpenAPI-спецификаций, что обеспечивает единообразие и упрощает добавление новых сервисов.
  4. Для поддержки клиентов, не умеющих работать с HTTP-заголовками, реализован stdio-прокси, который динамически подключается к инструментам через MCP Java SDK.
  5. Проверка инструментов на работоспособность проводится через реальные вызовы на проде, а не только через юнит-тесты, что позволяет выявлять критические ошибки, такие как null-поля и отсутствие валидных полей в API-спеках.

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

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

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

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

Hands-on System Design with Java Spring Boot

Phase 1: The Connection

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

Статья о построении веб-гейтве на Java 21 с использованием нативных NIO-контроллеров, способного удерживать 10 000 активных соединений, обнаруживать "мертвые" соединения и восстанавливать их без потери сообщений. В системе реализованы Discord-подобный протокол с опциями (HELLO, IDENTIFY, READY, HEARTBEAT, RESUME и др.), а также механизмы для управления состоянием соединений и сессий, включая хранение истории событий в кольцевом буфере для восстановления после сбоев. Ключевые инженерные решения — использование эполя (epoll), хеш-часов для быстрого обнаружения мёртвых соединений, разделение жизненного цикла соединения и сессии, а также оптимизация производительности за счёт виртуальных потоков и эффективного управления памятью.

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

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

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

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

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

System Design

DEV System Design

I built a free tool that shows where your system design breaks — with maths, not servers

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

System Canvas — это бесплатный, веб-инструмент, который позволяет визуально моделировать архитектуру системы и симулировать прохождение трафика через неё без реальных запросов. Вместо запуска на реальных серверах инструмент использует математические модели, основанные на теории очередей (например, Закон Литтла) и правилах поведения компонентов, чтобы оценить нагрузку, задержки и точки перегрузки. Результаты отображают п50, п95, п99 задержек, пропускную способность, ошибки и уровень использования каждого компонента, а также показывают, где возникает бутылочное горло и как сбои распространяются.

  1. Математическая модель оценивает нагрузку на компоненты, основываясь на теории очередей, и показывает, как задержки растут при приближении к 100% загрузке.
  2. Каждый компонент (например, Redis, серверы, CDN) имеет настраиваемые параметры (например, коэффициент попадания в кэш, лимит соединений), влияющие на результат.
  3. Инструмент поддерживает как простые схемы (один сервис), так и сложные микросервисные архитектуры, где сервисы моделируются отдельно и соединяются на уровне системы.
  4. Результаты — это оценки, а не реальные метрики: важно понимать, где архитектура "перегревается", а не доверять им как точным измерениям.
  5. Возможность сравнения вариантов (например, с Redis и без) в рамках короткой итерации позволяет быстро находить оптимальные решения.

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

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

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

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

Understanding Load Balancing Through a Cafe Example

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

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

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

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

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

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

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

Your Database Is an Architectural Decision. Not Just Storage.

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

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

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

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

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

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

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

The bug is in the handshake

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

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

  1. Всегда определяйте, кто несёт ответственность за повторные попытки (retry) — в очереди, в сервисе или в рабочем процессе — и в каких условиях.
  2. Уточните, кто владеет временными метками (clock): кто определяет таймаут, и как он передаётся между компонентами.
  3. Запишите явно, что каждый элемент предполагает от другого, например, что данные уже записаны или что работа будет передана.
  4. Не добавляйте "робастность" через повторные попытки в отдельных модулях — это приводит к перегрузке и несогласованности, а не к надёжности.
  5. Перед написанием кода создавайте список "связей" (handshakes), где каждый элемент описывает взаимодействие и ответственность.

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

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

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

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

Melampaui Hype: Membangun Sistem AI yang Bisa Diandalkan di Tahun 2026

Открыть оригинал ↗ Перевод заголовка: Превзойдя ожидания: создание надёжной системы ИИ в 2026 году

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

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

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

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

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

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

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

Revocation Under Partial Failure: Killing Financial Authority in a Distributed System

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

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

Ключевые тезисы:

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

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

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

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

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

Coding / Algorithms

DEV Data Structures

Python Data Structures

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

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

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

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

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

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

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

The Sliding Window Chronicles: A Journey Through the Matrix

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

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

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

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

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

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

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

Part 4: Double Hashing Bloom Filters

Открыть оригинал ↗ Перевод заголовка: Часть 4: Двойное хеширование в фильтрах Блум

В предыдущей статье была реализована структура фильтров Блум, а здесь представлен более эффективный вариант — фильтр Блум с двойным хешированием (DHBF). В классической реализации для вычисления индексов использовалась повторная хеширование значения с изменением семени, что требует многочисленных вызовов дорогостоящего криптографического хеш-функции SHA-256. Вместо этого DHBF использует только два хеш-вычисления и формулу двойного хеширования: индекс_i = (h1 + i * h2) mod m, что позволяет получить все необходимые позиции без повторного хеширования. Для предотвращения циклов в вычислении индексов важно, чтобы h2 и размер таблицы не имели общих делителей, поэтому рекомендуется использовать простое число в качестве размера таблицы. При добавлении значения в фильтр и поиске по нему используется та же логика, что и в обычном фильтре Блум, но с гарантированными уникальными индексами, что снижает количество ложных отрицаний.

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

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

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

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

The Matrix of Tree Traversals: Recursive vs Iterative

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

Разговор о рекурсивных обходах деревьев начинается с боли — когда на собеседовании вдруг всплывает ошибка переполнения стека при работе с сильно наклонным деревом. Классическая рекурсивная реализация inorder кажется красивой и логичной, но на больших данных она падает из-за ограничения глубины рекурсии. Ключевое понимание — что рекурсия фактически использует стек для хранения "незавершённых" шагов: сначала обход левого поддерева, затем обработка узла, затем правого. Итеративный подход копирует этот процесс, используя явный стек, чтобы избежать ограничений языка. Это позволяет обрабатывать деревья любой высоты, сохраняя время O(n) и пространство O(h), где h — высота дерева. Практически это означает, что можно безопасно работать с миллионами узлов, а не зависеть от внутренних ограничений языка.

  • Рекурсия работает как стек: каждый вызов сохраняет состояние (узел и следующий шаг), и при возврате — выполняется следующий шаг.
  • Итеративный обход имитирует рекурсию, используя явный стек для хранения узлов, которые ещё не обработаны.
  • Важно не пропускать узлы: перед движением влево нужно добавить текущий узел в стек.
  • Проверка порядка обхода (например, валидация BST) может быть сделана на лету, используя стек и предыдущее значение.
  • Паттерн легко адаптируется к другим типам обходов (предпорядок, постпорядок) и может быть расширен до Morris-обхода с O(1) дополнительным пространством.

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

Материал полезен при работе с большими деревьями (например, 10⁶ узлов), где рекурсия несёт риск переполнения стека, и когда требуется контроль за процессом обхода — например, для валидации BST или динамического изменения порядка обхода.

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

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

LeetCode.ca Solutions

4034 - Minimum Bishop Moves to Reach Target

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

Ладья движется только по диагоналям, и каждый её ход сохраняет инвариант — сумма координат (r + c) по модулю 2. Если начальная и целевая позиции имеют разные значения этого инварианта, ладья никогда не достигнет цели. Если позиции лежат на одной диагонали, то ходов потребуется ровно один. В противном случае, при одинаковой цветности клеток, ходов всегда достаточно двух — через промежуточную позицию. Решение работает за константное время и не требует поиска или симуляции движений.

  • Если (sr + sc) и (tr + tc) имеют разные остатки при делении на 2 — возвращаем -1 (неприменимо).
  • Если |sr - tr| == |sc - tc| — возвращаем 1 (непосредственный ход по диагонали).
  • В остальных случаях (одинаковый цвет, не на одной диагонали) — возвращаем 2 (через промежуточную точку).

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

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

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

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