AI

Habr AI

Лимиты ChatGPT и локальные LLM: мой эксперимент с Hermes Agent

Открыть оригинал ↗ Перевод заголовка: Лимиты ChatGPT и локальные LLM: мой эксперимент с Hermes Agent

Автор провел эксперимент по использованию локальных моделей (LLM) вместо облачных, чтобы снизить зависимость от лимитов ChatGPT. Он проверил Qwen и GLM на своём ПК, включил их в агент Hermes, и оценил качество ответов, память и стабильность работы. Основной вывод — локальные модели не решают проблем с архитектурными ошибками и не обеспечивают надёжности, особенно при отсутствии явных допущений в задачах. При этом они позволяют выполнять задачи без прерывания и сохраняют данные локально, что полезно в аварийных ситуациях.

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

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

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

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

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

Сколько живёт ссылка в ответе нейросети: сравнил три замера по 20 вопросам

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

Автор провёл анализ устойчивости ссылок в ответах нейросетей Алисы AI и Perplexity, проверив 20 вопросов по одной тематике через 5 и 45 дней. В ходе эксперимента выяснилось, что доля прежних ссылок в ответах резко падает к 45-му дню — от 27,5% до 35,5%, при этом большая часть ссылок меняется даже в течение часа. Устойчивость ссылок зависит от частоты повторов: те, что присутствовали во всех трёх повторах в течение часа, доживают до 45 дней в 42–47% случаев, в то время как мелькнувшие в одном повторе — почти не выдерживают.

  1. Ссылки, присутствующие во всех трёх повторах в течение часа, значительно чаще сохраняются до 45 дней, чем мелькнувшие в одном из них.
  2. Через 5 дней устойчивость ссылок уже заметна: у Алисы AI — 55,2%, у Perplexity — 59,7%, но к 45-му дню остаётся от 27,5% до 35,5%.
  3. Большинство ссылок в поздних ответах — новые, что означает, что место в ответе может быть занято не только потерянным, но и вновь добавленным контентом.
  4. Прогноз устойчивости ссылок по повторам работает у Алисы AI, но только на короткий срок — у Perplexity эффективность прогноза теряется к 45-му дню.
  5. Для достоверного мониторинга необходимо проводить три повтора в один час и проверять ответы через 5 и 45 дней, чтобы избежать ошибок, вызванных временным разбросом.

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

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

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

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

Хватит жечь гигабайты на антидетекты: как RFC 9421 и открытый протокол wbauth ускоряют AI-агентов в 5,5 раза

Открыть оригинал ↗ Перевод заголовка: Хватит жечь гигабайты на антидетекты: как RFC 9421 и открытый протокол wbauth ускоряют AI-агентов в 5,5 раза

Традиционные методы маскировки агентов — от фингерпринтов до имитации поведения человека — оказались неэффективными и ресурсоёмкими. Вместо этого вводится криптографическая идентификация через стандарт RFC 9421 и открытый протокол wbauth, который позволяет агентам подтверждать свою подлинность без подделки поведения. Это приводит к резкому снижению времени запуска (с 1744 мс до 5 мс), времени выполнения запроса (с 86,8 мс до 15,8 мс), и потребления памяти (с 500 МБ до 0,76 МБ), при этом устраняется необходимость в прокси и ручных настройках.

  • Вместо имитации человеческого поведения агенты теперь подписывают запросы асимметричным ключом Ed25519 по стандарту RFC 9421, что обеспечивает надёжную и проверяемую идентичность.
  • Протокол wbauth реализован как открытое решение с поддержкой Node.js, Python и Cloudflare Workers, позволяя интегрировать его в существующие системы без переписывания.
  • Проверка на WAF происходит за несколько миллисекунд: заголовок Signature-Agent используется для получения публичного ключа, затем выполняется подпись и проверка временных меток, что делает процесс прозрачным и быстрым.
  • Система не зависит от инфраструктуры: при смене облака или IP-адреса репутация не теряется, так как идентичность основана на криптографии, а не на физических характеристиках.
  • В отличие от традиционных решений, wbauth не требует запуска сложных рантайм-модулей или воровства фингерпринтов, что делает его стабильным и масштабируемым.

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

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

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

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

InfoQ Architecture

Presentation: Exploding GPUs

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

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

  1. GPU-ресурсы стали ценностями, которые могут быть проданы на тёмных рынках — их доступ позволяет запускать тысячи агентов для атак на веб-приложения и бизнес-почту.
  2. Модели могут "обмануть" ограничения и сгенерировать опасные или неподходящие ответы, даже если в них встроены "ограничители", что делает их нестабильными и непредсказуемыми.
  3. Атаки через промпты (например, с помощью нулевого ширины или скрытых символов) могут внедрять вредоносный код в систему, особенно если ввод происходит через GitHub-запросы или публичные каналы.
  4. Безопасность в Kubernetes остаётся критически важной — даже небольшие уязвимости в политике доступа или контейнерных настройках могут быть использованы агентами для проникновения в систему.
  5. Для защиты требуется внедрение "предельных проверок" (bounds checking) и "ограничений по диапазону" в ответах моделей, а не только на уровне промптов — это требует реальных тестов и инструментов, которые проверяют логику ответа.

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

Материал особенно полезен для команд, работающих с AI-моделями в production, где есть доступ к GPU-инфраструктуре и где ввод данных происходит через пользовательские интерфейсы или внешние системы (например, GitHub, Slack).

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

  1. В каких условиях использование "временного" или "временного" времени выполнения (time slicing) на GPU может быть допустимо, несмотря на риски проникновения и утечки данных?
  2. Какой минимальный уровень проверки ответов модели (например, через range checking) может быть реализован в реальных условиях без значительного увеличения задержки или затрат на инфраструктуру?
  3. При каких условиях агенты, работающие в Kubernetes, могут быть безопасно "встроены" в систему без риска превращения в неуправляемые, нестабильные угрозы?

Java / Spring

InfoQ Java

Helidon 27 Introduces Restructured Programming Models and New Messaging and Data Modules

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

Helidon 27 — первый релиз, внедривший модель разработки Oracle Tip & Tail: версия Tip (27) использует последнюю версию Java (JDK 27) и включает современные функции, в то время как версия Tail (4.5.5) остаётся стабильной на JDK 21 и поддерживается дольше для production-использования. В новом выпуске представлены два новых модуля — Helidon Messaging и Helidon Data JDBC — а также перестроены модели программирования: введён Helidon Core с моделями Imperative и Declarative, где первая поддерживает "простой Java", а вторая — инъекцию зависимостей и аннотации с предварительным сбором кода. Также отдельно размещены проекты Helidon MP и Helidon Extensions, что упрощает управление и поддержку.

  1. В Helidon 27 модель Imperative позволяет писать приложения на "простом Java" без зависимостей и аннотаций, что снижает сложность для новичков, но может уменьшать гибкость при масштабировании.
  2. Модель Declarative использует инъекцию зависимостей и аннотации для генерации кода на этапе сборки, что повышает читаемость и поддержку, но требует более глубокого понимания конфигурации и сборки.
  3. Helidon Messaging предлагает блокирующие, не-реактивные API для работы с Kafka, JMS и Pulsar, обеспечивая простую интеграцию без необходимости освоения реактивных фреймворков.
  4. Helidon Data JDBC даёт унифицированный API для запросов к базам данных, с предварительным преобразованием интерфейсов в реализации на этапе компиляции, что улучшает производительность и совместимость с Hibernate и EclipseLink.

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

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

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

  1. В каких сценариях будет предпочтительнее использовать Imperative модель, а в каких — Declarative, с учётом производительности и сложности поддержки?
  2. Какова оценка производительности и масштабируемости Helidon Messaging при работе с Kafka и Pulsar в условиях высокой нагрузки и задержек?
  3. В каких условиях Helidon Data JDBC может привести к увеличению времени компиляции, и как это влияет на CI/CD-процессы в production-среде?

System Design

DEV System Design

Understanding AI System Design: Beyond a Simple LLM API Call

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

Простой вызов API LLM не приводит к созданию надёжной и масштабируемой системы. В производственной среде необходимо решать сложные инженерные задачи — от аутентификации и управления доступом до контроля затрат, обработки ошибок и мониторинга. Ключевые компоненты включают безопасный доступ к данным, эффективную ретриев-систему, управление очередями и кэшированием, а также строгую валидацию ответов. РАГ (Retrieval-Augmented Generation) позволяет встраивать контекст из документов в запрос к LLM, но не гарантирует точность — ошибки могут возникать из-за плохой ретриев-точности, устаревших данных или неточного контекста. В реальных условиях приоритеты — скорость, стоимость и безопасность — конкурируют, и их баланс зависит от бизнес-целей и масштаба системы.

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

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

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

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

Design GitHub Actions in 45 Minutes: Job Queue, Runners, Live Logs and the Cache

Открыть оригинал ↗ Перевод заголовка: Проектирование GitHub Actions за 45 минут: очередь задач, бегуны, живые логи и кэш

Для проектирования CI-сервиса на основе принципов работы GitHub Actions рассматриваются ключевые компоненты: очередь задач с механизмом аренды, живые логи через Server-Sent Events, кэш зависимостей и масштабирование. Основные ограничения — быстрое запуск задач (в секунды), непрерывность работы и отсутствие потери задач, а также несмещённость нагрузки между клиентами. Важные технические решения включают использование Postgres как очереди с операцией SKIP LOCKED, механизм аренды (lease) с истечением срока, idempotent шаги, разделение по меткам для масштабирования, кэширование по входным данным (OS, архитектура, хэш lockfile), двухуровневое хранение (манифест + блоки), и защиту от кэш-атак и перегрузок.

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

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

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

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

Caching Is Easy. Cache Invalidation Is the Hard Part.

Открыть оригинал ↗ Перевод заголовка: Кэширование — легко. Удаление кэша — сложная задача.

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

Три ключевые стратегии:

  1. TTL (время жизни) — автоматическое удаление кэша по истечении срока, но может приводить к значительной устаревшей информации.
  2. Паттерн "cache-aside" — приложение проверяет кэш, если нет — запрашивает данные из базы и сохраняет в кэш, но не решает проблему обновления после изменений.
  3. Явное удаление кэша после записи — при обновлении в базе кэш удаляется, но не гарантирует согласованность при сбоях или конкуренции запросов.

При масштабировании системы (множество серверов) кэш может быть несогласованным, и требуется внедрение механизмов, таких как события, версии ключей или TTL как фальшивая гарантия. Также важно учитывать проблему cache stampede — резкий всплеск запросов при истечении срока жизни кэша, что может перегрузить базу данных.

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

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

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

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

Website Backups: A Restore Test That Proves Your Recovery Plan Works

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

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

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

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

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

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

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

From Automation to Autonomy: Designing Coordinated AI Systems

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

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

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

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

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

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

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

Computer Networking Explained: From Real-World Analogies to Production Systems | Day 1

Открыть оригинал ↗ Перевод заголовка: Объяснение компьютерной сети: от реальных аналогий до производственных систем | День 1

Когда вы вводите в браузер адрес google.com и нажимаете Enter, ваша система автоматически находит сервер, отправляет запрос, получает ответ и отображает веб-страницу за секунды. Этот процесс — результат сложной работы компьютерной сети, где устройства взаимодействуют через связи, правила и адреса. В статье подробно раскрывается, как данные передаются от устройства до сервера, как идентифицируются цели, как избегаются ошибки и как организованы масштабные системы.

  1. Сеть — это система взаимодействующих устройств, соединённых через связи и использующих протоколы для передачи данных.
  2. Запрос проходит через несколько этапов: от идентификации сервера (DNS), до формирования пакетов, передачи через маршрутизацию и возврата ответа.
  3. Данные передаются не как единое целое, а в виде пакетов (IP), сегментов (TCP) и фреймов (Ethernet), каждый из которых работает на своём уровне.
  4. Протоколы (HTTP, HTTPS, TCP, UDP, IP, DNS) решают разные задачи: от передачи данных до безопасности и маршрутизации.
  5. IP-адреса определяют логический путь, но могут меняться (особенно в приватных сетях), а NAT позволяет нескольким устройствам делиться одним публичным адресом.

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

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

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

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

InfoQ Architecture

Mini book: Evolutionary Architecture in Practice

Открыть оригинал ↗ Перевод заголовка: Мини-книга: Эволюционная архитектура в практике

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

  1. Агентные функции фитнеса используют ИИ для автоматического мониторинга дрейфа семантики и рисков в CI/CD, обеспечивая защиту архитектуры без замедления разработки.
  2. Понимание системы рассматривается как ключевая архитектурная характеристика — без человеческого осмысления система не может эволюционировать безопасно.
  3. В реальных проектах (например, переход от B2C к B2B) функции фитнеса и границ команд помогают вести эволюцию баз данных и API без разрушения совместимости.
  4. В мультиоблачных средах платформенные барьеры обеспечивают автономию регионов при сохранении централизованных требований к безопасности и наблюдаемости.
  5. Методика эволюции прототипа с использованием AI позволяет перейти от локальных решений к распределённой архитектуре без полного переписывания кода, сохраняя долгосрочную стабильность.

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

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

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

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

Article: Cryptographic Foundation of Mobile ID Systems: An ISO/IEC 18013-5 Enterprise Architecture Blueprint

Открыть оригинал ↗ Перевод заголовка: Криптографическая основа систем мобильного идентификации: архитектурный план для предприятий по стандарту ISO/IEC 18013-5

Статья рассматривает мобильные системы идентификации как сложную архитектуру, где критически важны вопросы доверия, криптографии и управления рисками. Она подчёркивает, что интеграция через SDK не означает передачу полного контроля над безопасностью — предприятие должно понимать, где находятся доверительные границы, как происходит защита данных и как система ведёт себя при отсутствии сети. Важно разделять фазы проверки идентичности и выдачи сертификатов, поскольку они требуют разных уровней доверия и ответственности. Основные практические тезисы:
— Разделять проверку идентичности (proofing) от выдачи (provisioning) позволяет четко определить, где лежит ответственность за доверие.
— Использовать гибридное публичное шифрование (HPKE) для защиты онлайн-транзакций, обеспечивая низкую задержку и прозрачность криптографии.
— Внедрять механизм выборочного раскрытия данных, чтобы минимизировать передачу чувствительной информации.
— Оценивать поставщика не по API, а по структуре доверия, криптографическим практикам, отказоустойчивости и возможностям миграции.
— Установить прозрачные границы доверия, включая контроль за сертификатами, хранением ключей и поведением при сбоях.

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

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

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

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

Uber Automates Dependency Analysis Across Its Service Mesh

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

Uber внедрил автоматизированный механизм анализа зависимостей в своей сетевой архитектуре, позволяя определять, как сбои в одном сервисе распространяются на другие. Система использует межсервисные промежуточные слои (RPC middleware) для корреляции сбоев между вызывающим и вызываемым сервисами и классифицирует зависимости как «fail-close» (сбой вызывающего сервиса приводит к сбою вызываемого), «fail-open» (сбой вызываемого не влияет на вызывающий) или «unknown». Вместо использования распределённого трейсинга с низкой частотой выборки, компания применяет метрики в RPC-миддлваре для быстрого обнаружения и анализа сбоев в реальном времени, что позволяет избежать задержек при обнаружении редких сбоев.

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

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

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

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

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

Microsoft Commits Maia to Multi-Gigawatt Inference, and Its Efficiency Metric Draws Questions

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

Майя — новая архитектура инференса от Майкрософт, которая начнёт масштабироваться до многомиллиардных ваттных установок с 2027 года и станет основной системой для инференса в продуктах компании. В отличие от общих заявлений о «токенах на ватт», архитектура Maia детально описывает движение данных, особенно в сетях и внутри узлов, где реализованы прямые соединения между акселераторами и отказоустойчивые механизмы перераспределения. Основная метрика — «токены на ватт» — вызывает критику из-за отсутствия определения, что делает её несопоставимой с реальными вычислительными нагрузками, особенно при долгих контекстах.

  1. Метрика «токены на ватт» не учитывает контекстуальную динамику и не определяет, что считается «полезным» токеном, что делает её неадекватной для оценки реальных рабочих нагрузок.
  2. Акцент на памяти (HBM, NUMA-организация) указывает, что производительность ограничена не вычислительной мощностью, а объёмом памяти, что подрывает применимость метрики на основе вычислительной эффективности.
  3. Отсутствие сравнения с конкретными GPU-системами и неясность о том, какие рабочие нагрузки использовались для теста, снижают доверие к заявленным цифрам.
  4. Доступ к Maia остаётся внутренним для Microsoft, что вызывает сомнения в экономической выгоде для клиентов и в реальном снижении стоимости инференса.
  5. Архитектура использует единую сеть («one fabric»), что позволяет эффективно передавать данные между рабочими, но требует сложного программного управления для оптимизации трафика.

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

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

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

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

Coding / Algorithms

LeetCode.ca Solutions

4040 - Minimum Operations to Form Subset Sum I

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

Для каждого элемента массива можно применять операции умножения на 2 или деления на 2, причём все умножения должны происходить до любых делений. Каждый элемент может быть преобразован в значение вида $x \times 2^i$ или $\lfloor x / 2^i \rfloor$, при этом минимальное количество операций достигается при использовании только одного направления (либо только умножение, либо только деление). Проблема сводится к 0-1 рюкзаку: для каждого элемента генерируются возможные значения и их стоимость, и ищется минимальная стоимость подмножества, суммирующегося в заданное число. Алгоритм обрабатывает значения в обратном порядке по сумме для избежания повторного использования элемента, а в случае отсутствия решения возвращается -1.

  • Каждый элемент может быть преобразован в значения $x \times 2^i$ (при умножении) или $\lfloor x / 2^i \rfloor$ (при делении), при этом стоимость равна $i$ операций.
  • Все комбинации умножений и делений эквивалентны одному направлению, так как смешанные операции увеличивают общее количество шагов.
  • Решение строится с помощью динамического программирования: для каждой суммы $w$ хранится минимальная стоимость достижения этой суммы.
  • Ограничение на сумму $S \leq 5000$ делает перебор всех возможных степеней $i$ (до $\log_2 S$) приемлемым.
  • В случае, если ни одно подмножество не достигает суммы $sum$, возвращается -1.

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

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

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

  1. Как изменится сложность алгоритма, если вместо $x \times 2^i$ и $\lfloor x / 2^i \rfloor$ разрешить смешанные операции с фиксированным порядком, но с разными стоимостями?
  2. При каких условиях может возникнуть failure mode, при котором даже при наличии теоретически достижимого значения сумма не может быть достигнута из-за ограничений на порядок операций?
  3. Как повлияет увеличение диапазона значений элементов (например, до 1000) на эффективность перебора степеней $i$ и на границы применимости решения?