По одному результату на модуль. Не «что изучим», а что будет получаться в работе.
7
Собирать AI-систему из компонентов, а не из отдельных вызовов
Вокруг агенты, векторные БД и RAG – а по каким критериям выбирать, неясно.
Разберёшь классы foundation models (LLM / LMM / SLM), векторные хранилища, оркестраторы и agent-фреймворки, inference и serving, RAG-инфраструктуру – каждое по критериям выбора, включая GPU-экономику и self-hosted против API.
8
Проектировать агентные системы – и видеть, где агент лишний
Мультиагентность выглядит модно, но непонятно, когда она оправдана.
Типы агентов и оркестрация, мультиагентные архитектуры и когда агент – overengineering, MCP, эволюция паттернов RAG, serving layer с маршрутизацией, rate limiting и graceful degradation, observability для AI-систем.
9
Работать с ИИ в петле архитектурного решения
ИИ выдаёт правдоподобный вариант – проверить его нечем.
Каталог критериев как исполняемая рубрика, red-team собственного дизайна против NFR, аудит системы: реверс C4 из репозитория, восстановление решений, ADR, карта рисков. Приёмка чужого и ИИ-сгенерированного решения. ДЗ – аудит реальной системы.
10
Держать качество недетерминированной системы в проде
Тесты зелёные, а ответы модели поплыли – и это никто не замечает.
Evals для управления качеством инференса, тестирование недетерминированного, миграции и zero-downtime, canary и откат моделей и промптов, LLM-observability, дрейф, мониторинг стоимости.
11
Закрывать безопасность архитектуры – включая ИИ-часть
Безопасность обсуждается в конце проекта, когда менять поздно.
Моделирование угроз и поверхность атаки, OAuth 2.0 / OIDC, JWT, RBAC и ABAC, секреты, шифрование и сетевая безопасность. Отдельно – безопасность ИИ-систем: prompt injection, утечка данных и PII, безопасность агентов, supply-chain моделей.