📰Сегодня немного про "БАЗУ"

Выбор модели и метрики — это не вопрос ML, а бизнес-вопрос

Типичный разговор:
🗣 Какую модель возьмём?
🗣 Градиентный бустинг, лучший ROC-AUC.
🗣 Отлично!

Проблема: забываем главный вопрос — зачем бизнесу нужна эта модель?

Высокая метрика не гарантирует:
- Влияние на ключевые KPI
- Правильный баланс ошибок
- Пользу в реальных решениях

Сначала спрашиваем:
- Какое бизнес-решение улучшаем?
- Какие ошибки дороже?
-Как модель будет использоваться?

Только потом обсуждаем метрики, сложность, интерпретируемость.
- Модель — это не цель.
- Бизнесу нужен результат, а не алгоритм.

Лучшее решение — то, что:
- Даёт ясный эффект,
- Легко внедряется,
- Вызывает доверие стейкхолдеров.

🗞Главный вывод:
Перед выбором модели спросите: какой бизнес-результат мы оптимизируем?
Это меняет разговор с абстрактного ML на реальные решения.

👀 Недавно прочитал статью Валерия Бабушкина (https://www.linkedin.com/in/venheads/), про неоднозначность precision в продакшн‑сценариях вроде фрода или спама. Метрика выглядит хорошо на бумаге, но при изменении доли позитивного класса может сильно упасть, хотя TPR/FPR остаются стабильными.

💻 У меня был кейс с внедрением NLP-модели для проверки заявок в кредитном скоринге: на тесте precision была почти 0.9, но при росте объёма заявок и изменении их качества фактический «хороший» результат по бизнес-KPI упал в два раза. Переключились на фиксированную специфичность и максимизацию recall, и модель стала стабильно полезной в продакшне.

🚩Вывод: для систем с редкими событиями лучше смотреть на TPR/FPR или recall при фиксированной специфичности, а не на precision как на главный ориентир.

Статья: https://www.linkedin.com/pulse/why-precision-dangerous-metric-valerii-babushkin/?trackingId=4ANfb3R7Tc8nEiTB2rHz5A%3D%3D

💻 На ML собесах часто выделяют этап System Design не для того, чтобы проверить, умеешь ли ты писать код, а чтобы понять, как ты строишь систему вокруг модели. Тут важно показать, что ты думаешь не только о метриках и моделях, но и о пайплайнах данных, мониторинге, масштабируемости, latency, надежности и бизнес-цели.

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

📱 Отличная серия собеседований для подготовки к System Design Interview от karpov.courses (https://www.youtube.com/@karpovcourses/featured).
1 часть - https://www.youtube.com/watch?v=VPg2Uu1MYgI&t=1894s
2 часть - https://www.youtube.com/watch?v=WKYPQtqE-m0&t=518s
3 часть - https://www.youtube.com/watch?v=3X-TAuWdIAc

LoRA — адаптер для больших моделей

💻 Недавно наткнулся на статью про LoRA (habr.com/ru/articles/747534) и чет задумался: как круто эта штука упрощает жизнь при работе с большими моделями вроде LLM и diffusion.

Суть в том, что вместо того, чтобы дообучать всю огромную сеть (миллионы и миллиарды параметров), мы учим маленькие матрицы поправок. Это значит: меньше GPU, меньше памяти, меньше времени и данных для fine-tuning — а качество почти не страдает.

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

Думаю, это реально меняет подход к продакшену: раньше нужно было думать, как заставить всю модель работать, теперь — как грамотно встроить адаптер и оптимизировать нагрузку. Для инженера, который строит системы вокруг LLM/генеративок, это прям must-know.

💡Итог: LoRA — не просто фишка для исследований, а реально рабочий инструмент для ускорения, экономии ресурсов и масштабируемости в продакшене.

Зачем смотреть IT‑контент и как это делать эффективно

1️⃣Учёба через контекст. Видео и подкасты помогают лучше усваивать новые технологии и строить нейронные связи.
2️⃣Сленг и формулировка вопросов. Понимание терминов помогает точнее задавать вопросы и быстрее расти.
3️⃣Расширение кругозора. Слыша новые технологии, идёшь гуглить и узнаёшь, что развивается сейчас.
4️⃣Следим за трендами. Контент показывает, что движется быстрее всего и куда стоит обратить внимание.

💡Как встроить контент в день:
- Слушайте видео на 2х скоростях.
- Слушайте со смартфона во время прогулок, домашних дел, бега.
- Отбирайте качественный контент, чтобы не тратить время впустую.

🎧 Что смотреть/слушать:
- Подкасты и видео по языку/технологии (Python: Moscow Python Podcast, Real Python, Диджатилизируй; JS: Frontend Weekend).
- Конференции: HighLoad, TeamLead Conf, Agile Days.
- YouTube-каналы: Лёша Корепанов, АйТиБорода, Over Engineer, IT-KAMASUTRA, Миша Ларченко.
- Лидеры мнений: Кира Кузьменко, Кирилл Мокевнин (Hexlet), Григорий Бакунов, Антоха Гладков, Андрей Анищенко.

🔈Подкасты:
- Podlodka
- Мы Обречены
- Radio-T.

📎 Итог: регулярное потребление качественного контента ускоряет обучение, помогает быть в теме и развивает системное мышление

🌐 - https://goo.su/L9Sz1

Claude Opus 4.6 за час решил задачу, над которой Дональд Кнут бился неделями

🤖Очередное доказательство тому, что AI ничего сам по себе не заменяет. Он усиливает.

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

Но если убрать людей и оставить только модель — она не «станет гением». Она станет статистической машиной, которая блестяще компилирует известное.

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

💡Поэтому вопрос не в том, «заменит ли ИИ». Вопрос в том, кто научится использовать его как инструмент и встроит в свою работу так, чтобы получить реальное преимущество.

😳Фатальная ошибка при проектировании ML-систем, которую делают почти все

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

Я недавно написал об этом в LinkedIn, с примером из книги ML System Design Валерия Бабушкина и Арсения Кравченко.

Читать полный пост и разбор: https://goo.su/Mgmb9T