Что делать с архитектурным дрифтом в эпоху ИИ?
С появлением ИИ-инструментов код в проектах начал расти быстрее. Новый сервис, багфикс или интеграцию теперь можно получить быстрее чем согласование изменений, но цена архитектурной ошибки на этом фоне только растёт.Проблема не в том, что ИИ пишет плохой код, а в том, что он ускоряет накопление расхождений между тем, какой систему задумывали изначально, и тем, во что она превращается по мере изменений. Если архитектурные ограничения не формализованы и не проверяются автоматически, команда рано или поздно начинает проигрывать собственной скорости.
Система мониторинга ML-моделей: превращаем данные в полезный инструмент
В прошлой статье мы разобрали, из каких компонентов собирается система мониторинга, и составили инструкции, чтобы указывать на действительно важные проблемы. Пришло время выстроить их в единую систему. Она должна масштабироваться и давать ясную картину происходящего, чтобы наш мониторинг не был бесполезным потребителем ресурсов.В этой статье мы сформулируем правила, которые помогут:организовать хранение данных для масштабируемости;построить понятную визуализацию на дэше;настроить осмысленные оповещения;написать документацию.
Система мониторинга ML-моделей: что важно контролировать и почему
«Обучил, запустил и забыл» — плохая стратегия работы с ML‑моделями, но она часто встречается после удачного тестирования. Качество моделей может незаметно снижаться, и если пропустить этот момент — последствия могут дорого стоить. Когда мы начали задумываться о системе мониторинга, одна из наших моделей начала выдавать предсказания, которые требовали незамедлительного вмешательства в выстроенную работу. Но разум подсказывал, что проблема не в процессе, а в модели. О том, каким трудоемким оказалось наше расследование, и как мы восстанавливали и изучали каждую составляющую процесса почти вслепую, читайте по
