В прошлых статьях я рассказывал, как устроен мой тренажёр инцидентов, и разбирал кейс с 502 Bad Gateway. Сегодня утром я релизнул два новых режима: «дежурство недели» и публичный профиль игрока. Покажу, как они устроены: там нет ни крона, ни новых таблиц, и всё равно есть пара мест, где легко ошибиться.

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

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

На примере этой системы разберём семь паттернов микросервисной архитектуры, их ограничения и короткие примеры на Python.

В этой статье слова “сервис” и “микросервис” используются взаимозаменяемо.

Всем привет! Меня зовут Александр, я руковожу направлением аналитики страховой вертикали в Банки.ру. Наша вертикаль живёт в отчётах и данных: продажи ОСАГО и КАСКО, ипотечное страхование, кроссы, пролонгация, воронки, кэшбэк и сверки с партнёрами.

И каждый день в рабочем мессенджере на меня прилетает поток одного и того же жанра: «где посмотреть КВ по ОСАГО за сентябрь?», «почему упало одобрение у страховой?», «сделай выгрузку по регионам», «это у нас баг или так и задумано?». КВ здесь комиссионное вознаграждение.

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

В статье рассказал, как бот устроен, какие правила не дают ему врать и как он им учится.

Я изучаю посттренировочное квантование семейства RWKV-7 (от 0.1B до 13.3B параметров) двумя пресетами: REDUCTION (сжатие около 2.1x, почти без потерь) и COMPRESSION (около 3.1x, 4 бита на проекции). Исходный вопрос работы: почему 4-битный пресет на модели 2.9B деградирует сильнее, чем на 1.5B (+4.04% против +2.85% по перплексии), хотя ожидается обратное.

Оказалось, что до 86% вклада всей группы o_proj на 2.9B приходится на одну матрицу: выходную проекцию нулевого блока. Её вход несёт «массивный канал» (98% энергии входа в восьми каналах из 2560). Хранение этой одной матрицы в bf16 (0.5% файла) снижает KL к эталону на 39% и возвращает 2.9B в монотонную линейку; перевод эмбеддинга с 5 на 6 бит добавляет ещё −22% KL за 1.1% файла. Три естественные локальные метрики ошибки не предсказывают вред от квантования матрицы; предсказывает ошибка, внесённая в остаточный поток и умноженная на усиление ниже по глубине. На этом основании я строю автоподбор битности по правилу «снятый вред на байт» (−16…−39% KL при приросте файла не более 0.5%) и переношу GPTQ на ту же сетку (−29…−43% KL при тех же байтах).

Вместе методы дают потерю по перплексии от +2.76% (0.1B) до +0.70% (13.3B) на файле размером 31.6–35.2% от bf16, монотонно убывающую с размером модели. Пресет REDUCTION с GPTQ даёт +0.46…+0.07% при 46–50% от bf16. При равном размере файла KL моего 6-битного файла с GPTQ в 2.0–3.3 раза ниже, чем у GGUF Q6_K с imatrix, и в 3.5–7.4 раза ниже, чем у MLX int6; 4-битный файл в 2.1 раза точнее Q4_K_M на 1.5B, а Q4_K_M на 2.9B ломается. Отдельно описываю утечку калибровочного корпуса в мой первый оценочный набор и измеренный масштаб её влияния, а также разброс GPTQ между численно эквивалентными реализациями (около ±1.5% KL).

Стив Франсиа, автор Hugo и Cobra, после эмулятора NES запустил на конференц-бейдже GitHub Universe с RP2350 эмулятор Game Boy Color — на MicroPython с генератором кода Viper. Процессор SM83 с его восемью регистрами и 512 опкодами не влез в четыре быстрые локальные переменные Viper, и декодер пришлось строить на восьмеричной раскладке опкода. Ветвления по адресу заменила таблица из 16 страниц по 4 КБ, двухмегабайтные картриджи подгружаются по банку при первом обращении, а разгон до 300 МГц вешал общую шину QSPI. Плюс три бага из реальных игр: окно диалога в Oracle of Ages, «вывернутый» Линк в режиме двойной скорости и указатель стека, который Pokémon Crystal направляет прямо в ROM.

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

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

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

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

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

Мы переделали менеджера в агента: модель сама выбирает инструменты и порядок. И сразу же его ограничили: 8 шагов и 150 секунд на ход, узкие инструменты, запись в кабинет — только после «да» владельца. Рассказываем, как это устроено, с кодом, и что дали агенту вместо сценариев.

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