Week_11_Lecture_1

1.

WEEK 11 · LECTURE 1
System Design Patterns for AI
Паттерны системного дизайна для AI-систем
Модель — только один сервис внутри большой backend-системы из многих компонентов.
Пользователь
Сервер API
Маршрутизатор
Кэш
Vector DB / Model
Пост-обработка
Logs / Metrics
Ответ
• Модель — лишь один компонент production-системы, а не вся система.
• Запрос проходит через сервер API, маршрутизацию, кэш, retrieval, сервер модели и мониторинг.
• Надёжность не появляется сама: нужны таймаут, повтор, fallback и наблюдаемость (observability).
• Хороший AI-инженер проектирует не только happy path, но и сценарии отказа (failure modes).
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
01 / 40

2.

ПЛАН ЛЕКЦИИ
Что будем проходить
• почему «я обучил модель» — недостаточно;
• как устроена типовая AI-архитектура;
• зачем разделять сервер API, сервер модели, векторную базу и
мониторинг;
• как работает маршрутизация запросов (request routing);
• что и как кэшировать;
• как обрабатывать ошибки: таймаут, повтор, размыкатель,
деградация;
Маршрут лекции
Архитектура
Микросервисы
Request flow
Маршрутизация
Кэш
Надёжность
ADR
• зачем нужны записи архитектурных решений (ADR).
Мини-глоссарий
• сервис — отдельный компонент системы;
• маршрутизация — выбор пути обработки запроса;
• кэш — сохранение повторно используемого результата;
• наблюдаемость — журналы (logs) + метрики (metrics) + трассировка
(traces).
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
02 / 40

3.

ЦЕЛИ ОБУЧЕНИЯ
Что студент должен понять
После лекции студент должен уметь:
• нарисовать архитектуру AI-системы;
• разделить систему на сервисы;
Архитектура
• объяснить роль сервера API, сервера модели, векторной базы, кэша и
мониторинга;
• найти 3 наиболее вероятные точки отказа (failure points);
Компоненты
• предложить защиты (mitigations) для каждой ошибки;
• записать архитектурное решение в ADR.
Точки отказа
Защиты
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
03 / 40

4.

КОНТЕКСТ КУРСА
Что мы уже умеем к Week 11
• Python, тесты и отладка (debugging);
• NumPy, Pandas и разведочный анализ (EDA);
Теперь задача: собрать компоненты в надёжную систему.
• supervised ML и метрики качества;
• конвейеры (pipelines) и MLflow;
• Docker и FastAPI;
Лестница навыков
Production AI System
• embeddings, векторный поиск и RAG;
• основы мониторинга.
RAG
Docker / API
Pipelines
ML
Python
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
04 / 40

5.

ПОСТАНОВКА ПРОБЛЕМЫ
Почему «я обучил модель» — недостаточно
Модель может быть хорошей, а система — плохой, если вокруг неё нет инженерии.
• сервер API принимает невалидные запросы;
Хорошая модель в плохой системе
• сервер модели отвечает слишком долго;
• retrieval возвращает неправильные документы;
slow API
bad retrieval
• нет кэша — растут задержка и стоимость;
• нет журналов — невозможно понять ошибку;
Good model
• нет fallback, когда модель недоступна.
accuracy ↑
no cache
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
no logs
no fallback
05 / 40

6.

КАРТА СИСТЕМЫ
Модель — маленькая коробка внутри большой системы
• frontend или клиент;
• сервер API;
• предобработка (preprocessing);
• retrieval;
Client
API
Preprocessing
Retrieval
Model
Post-proc
Response
• инференс модели (model inference);
• пост-обработка (post-processing);
← модель здесь
• мониторинг;
• обратная связь (feedback loop).
Logs / Metrics / Feedback
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
06 / 40

7.

ТИПОВАЯ АРХИТЕКТУРА
Типовая архитектура AI-приложения
• пользователь отправляет запрос;
User → Frontend
• сервер API валидирует вход;
• маршрутизатор выбирает путь обработки;
• кэш проверяет готовые результаты;
Сервер API
• векторная база ищет релевантный контекст;
• сервер модели генерирует ответ;
Маршрутизатор
• мониторинг записывает метрики.
Кэш
Векторная база
Сервер модели
Мониторинг → Ответ
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
07 / 40

8.

КОМПОНЕНТЫ
Основные компоненты AI-системы
Хороший system design начинается с разделения ответственности.
Сервер API (API server)
Кэш (Cache)
вход, валидация, формирование ответа
быстрый повторный доступ
Маршрутизатор (Router)
Очередь (Queue)
выбор пути обработки запроса
долгие фоновые задачи
Сервер модели (Model server)
Мониторинг (Monitoring)
инференс (inference)
метрики, журналы, алерты
Векторная база (Vector DB)
семантический поиск (semantic search)
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
08 / 40

9.

МИКРОСЕРВИСЫ
Зачем разделять сервисы
Плюсы разделения
Цена разделения
• независимое масштабирование;
• больше сетевых вызовов;
• изоляция ошибок (один сбой не валит всё);
• сложнее DevOps и оркестрация;
• разные ресурсы для CPU- и GPU-задач;
• обязательна наблюдаемость;
• независимый деплой;
• сложнее локальная разработка;
• понятные границы ответственности;
• нужны контракты между сервисами;
• проще мониторить и отлаживать.
• выше начальная сложность системы.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
09 / 40

10.

АРХИТЕКТУРНЫЙ ВЫБОР
Монолит vs микросервисы для AI
Монолит подходит, если
Микросервисы подходят, если
• маленький demo или прототип;
• несколько команд;
• один разработчик;
• GPU-инференс вынесен отдельно;
• низкая нагрузка;
• RAG и индексация отдельно;
• простая модель;
• нужна масштабируемость;
• нужен быстрый старт.
• надёжность важнее простоты.
Простота
Масштабирование
Быстрый старт
Изоляция ошибок
Меньше DevOps
Больше контроля
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
10 / 40

11.

ГЛАВНЫЙ ПРИМЕР
Пример: Capstone AI Assistant
Учебная production-like AI-система — сквозной пример всей лекции.
• принимает вопросы по документам курса;
• ищет релевантные источники в векторной базе;
• выбирает модель по сложности запроса;
Основной пользовательский запрос
«Объясни правило поздней сдачи, найди источник в документах
курса и посчитай, какая будет оценка, если было 100 баллов.»
• кэширует embeddings, retrieval и частые ответы;
• возвращает ответ с источниками (sources);
• пишет журналы, метрики и трассировку.
Вопрос пользователя
Assistant API → Retrieval
Сервер модели
Ответ + Sources + Trace
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
11 / 40

12.

КОМПОНЕНТ · СЕРВЕР API
Сервер API (API server)
Входная дверь системы и точка, где начинается управляемость.
• приём HTTP-запроса;
Пример endpoint
• проверка входных данных (валидация);
• создание request_id;
POST /api/v1/ask
• вызов нужных внутренних сервисов;
• сбор финального ответа;
• возврат response клиенту.
Client
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Сервер API
Внутренние сервисы
12 / 40

13.

КОМПОНЕНТ · СЕРВЕР МОДЕЛИ
Сервер модели (Model server)
Отдельный сервис, отвечающий только за инференс.
• загружает модель в память;
Примеры backend
• принимает запросы на генерацию;
vLLM
• управляет батч-обработкой (batch);
Ollama
• использует GPU;
LM Studio
• возвращает результат модели;
внешний LLM API
• может быть локальным или внешним.
внутренний corporate endpoint
Сервер API
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Сервер модели
GPU / LLM
13 / 40

14.

КОМПОНЕНТ · ВЕКТОРНАЯ БАЗА
Векторная база данных (Vector DB)
Хранилище и поиск контекста для модели — основа RAG.
• хранит embeddings документов;
• ищет похожие фрагменты (chunks);
Примеры
FAISS
ChromaDB
Weaviate
pgvector
Qdrant
• поддерживает top-k retrieval;
• фильтрует по metadata;
• возвращает контекст для модели.
Chunks
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Embeddings
Vector DB
Top-k
14 / 40

15.

КОМПОНЕНТ · КЭШ
Сервис кэширования (Cache service)
Кэш снижает задержку и стоимость, но требует дисциплины.
Кэш снижает
• задержку (latency);
Запрос
• стоимость LLM-запросов;
• нагрузку на сервер модели;
• нагрузку на векторную базу;
• повторное вычисление embeddings.
Cache HIT
Cache MISS
Быстрый ответ
Полный pipeline
Что можно кэшировать
• embeddings;
• результаты retrieval;
• частые запросы (frequent queries);
• финальные ответы.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
15 / 40

16.

КОМПОНЕНТ · ОЧЕРЕДЬ
Очередь и фоновые воркеры (Queue & workers)
Долгие задачи нельзя выполнять синхронно внутри запроса.
• OCR большого PDF;
Паттерн
• батч-инференс (batch);
• переиндексация документов;
1
API принимает задачу
API
2
создаёт job_id
Queue
3
Worker выполняет задачу
4
клиент проверяет status
5
результат сохраняется
• генерация отчёта;
• обработка видео или изображений.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Worker
Storage
Status
16 / 40

17.

КОМПОНЕНТ · МОНИТОРИНГ
Сервис мониторинга (Monitoring)
Deployed model without monitoring is a liability — система без метрик непредсказуема.
• насколько система быстрая?
• сколько ошибок происходит?
Latency
Error rate
Token usage
p50 / p95
% ошибок
стоимость
Cache hit
GPU usage
Retrieval
rate %
загрузка
recall / качество
• сколько стоит один запрос?
• какая модель используется чаще?
• где узкое место (bottleneck)?
• не упало ли качество retrieval?
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
17 / 40

18.

ПОЛНАЯ СХЕМА
Полная схема микросервисной AI-системы
Не каждый запрос проходит через все компоненты — архитектура поддерживает разные пути.
User → Frontend
Сервер API
Маршрутизатор
Кэш
Embedding
Vector DB
Сервер модели
Пост-обработка →
Ответ
Сквозные сервисы (cross-cutting)
Queue / Worker
Database
Monitoring
Logs
Metrics
Trace
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
18 / 40

19.

REQUEST FLOW
Как проходит один запрос
Один запрос — это последовательность шагов. Отладка начинается с вопроса: на каком шаге сбой?
1
Пользователь отправляет вопрос
6
Сервер модели генерирует ответ
2
Сервер API валидирует запрос
7
Пост-обработка проверяет формат
3
Маршрутизатор выбирает путь
8
Мониторинг записывает метрики
4
Кэш проверяет готовый результат
9
Сервер API возвращает response
5
Retrieval ищет документы
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
19 / 40

20.

ТОЧКИ ОТКАЗА
Где может сломаться запрос
Ключевой вопрос: что здесь может сломаться, как мы это заметим и что система сделает вместо падения?
Сервер API
Маршрутизатор
Кэш
Vector DB
Сервер модели
Пост-обработка
!
!
!
!
!
!
Типичные точки отказа
• плохой или невалидный input;
• сервер модели — таймаут;
• cache miss или устаревший кэш (stale);
• LLM вернула невалидный JSON;
• векторная база недоступна;
• пост-обработка упала;
• retrieval вернул пустой результат;
• мониторинг не записал trace.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
20 / 40

21.

FLOW
Синхронный vs асинхронный flow
Синхронный flow
Асинхронный flow
• быстрый ответ;
• API возвращает job_id;
• простой UX;
• worker делает тяжёлую задачу;
• подходит для коротких запросов;
• клиент проверяет status;
• риск таймаута при долгих задачах.
• подходит для OCR, indexing, batch.
Request
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Response
Request
Job ID
Worker
Result
21 / 40

22.

НАДЁЖНОСТЬ
Проверки здоровья и готовности (health & readiness)
Health check: «процесс жив?»
Readiness check: «готов принимать трафик?»
Статус сервисов · GET /health GET /ready
Сервер API
OK
Кэш
OK
Векторная база
OK
Сервер модели
Slow
База данных
OK
Что проверять
• процесс сервера API;
• соединение с базой;
• соединение с векторной базой;
• соединение с кэшем;
• статус сервера модели;
• доступность GPU.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
22 / 40

23.

КОНТРАКТЫ
Контракты сервисов (service contracts)
Контракт — это договор между компонентами: что отправляем и что получим назад.
• формат request;
• формат response;
• обязательные поля;
Пример request
{
"request_id": "abc-123",
"query": "...",
"top_k": 5,
"route": "rag"
• возможные ошибки;
• таймаут;
• идемпотентность (idempotency);
}
• версия (version).
Request
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Schema
Validation
Response
23 / 40

24.

МАРШРУТИЗАЦИЯ
Что такое маршрутизация запросов (request routing)
Маршрутизация — выбор пути обработки. Не каждый запрос должен идти в самую дорогую модель.
• FAQ → кэш или small model;
Cache route
• вопрос по документам → RAG route;
• сложный reasoning → large model;
• длинный PDF → async worker;
RAG route
• невалидный input → отклонить сразу (reject early).
Request
Small model
Router
Large model
Async job
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
24 / 40

25.

МАРШРУТИЗАЦИЯ · СЛОЖНОСТЬ
Маршрутизация по сложности запроса
Простые запросы
• короткие FAQ;
• приветствия;
• простые определения;
Паттерн маршрутизации
simple
→ small model
complex
→ large model
document-based → RAG
• повторяющиеся вопросы.
Шкала сложности запроса
Low
Medium
High
Small model
RAG
Large model
Сложные запросы
• требуют документов или reasoning;
• несколько шагов;
• строгий формат, высокий риск ошибки.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
25 / 40

26.

МАРШРУТИЗАЦИЯ · ТИП ЗАДАЧИ
Маршрутизация по типу задачи
Маршрутизатор выбирает не только размер модели, но и весь pipeline обработки.
Тип задачи
Путь обработки
Классификация
classifier
Поиск по документам
retrieval
Генерация ответа
LLM
Суммаризация
summarizer
OCR
async worker
Tool calling
agent route
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
26 / 40

27.

МАРШРУТИЗАЦИЯ · СТОИМОСТЬ
Маршрутизация по стоимости и задержке
Архитектурное решение почти всегда — компромисс. Нельзя получить всё сразу.
• качество ответа;
Quality
• задержка (latency);
• стоимость (cost);
• надёжность;
• доступность модели.
выбери 2 из 3
• Small model: быстро, дёшево, хуже reasoning.
• Large model: лучше reasoning, дороже, медленнее.
• Cache: самый быстрый, нужен контроль актуальности.
Cost
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Latency
27 / 40

28.

НАДЁЖНОСТЬ · FALLBACK
Запасной путь (fallback strategy)
Fallback — запасной путь, если основной недоступен. Цель — не упасть полностью.
large model недоступна
векторная база недоступна
→ small model
→ ответ без источников + предупреждение
кэш недоступен
→ полный pipeline
генерация не удалась
→ шаблонный ответ
OCR не удался
→ просьба загрузить другой файл
Primary path → Error → Fallback path → ограниченный, но честный ответ
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
28 / 40

29.

МАРШРУТИЗАЦИЯ · КОД
Логика маршрутизации в псевдокоде
Маршрутизация из абстрактной идеи превращается в кодовое мышление.
if is_faq(query):
return from_cache_or_small_model(query)
if requires_documents(query):
return rag_pipeline(query)
if is_long_running(file):
return create_async_job(file)
return large_model(query)
is_faq? → cache / small
requires docs? → RAG
long running? → async
иначе → large model
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
29 / 40

30.

КЭШИРОВАНИЕ
Зачем кэш в AI-системах
Кэш нужен, чтобы
Кэш опасен, если
• ускорить повторные запросы;
• данные устарели;
• снизить стоимость LLM;
• ключ выбран неправильно;
• разгрузить сервер модели;
• ответ содержит персональные данные;
• разгрузить векторную базу;
• документы обновились.
• уменьшить задержку p95;
• повысить стабильность при пиках нагрузки.
Cache HIT → быстрый ответ
полный pipeline
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Cache MISS →
30 / 40

31.

КЭШ · EMBEDDINGS
Кэш эмбеддингов (embedding cache)
Embedding одного и того же текста не нужно вычислять повторно.
• экономит время;
• снижает нагрузку на embedding-модель;
Text → hash key
• полезен при повторной индексации;
• особенно важен для документов.
Cache HIT
→ embedding
Cache MISS
embedding-модель → сохранить
Ключ кэша
hash(text + embedding_model +
preprocessing_version)
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
31 / 40

32.

КЭШ · RETRIEVAL
Кэш результатов поиска (retrieval cache)
Сохраняет top-k результаты для частых вопросов.
Кэшировать можно
• query embedding;
• top-k document ids;
Query
• top-k chunks;
• scores и metadata.
Retrieval cache
Ключ должен учитывать
• query;
HIT → Top-k chunks
• collection_id;
• index_version;
MISS → Vector DB → save
• top_k и filters.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
32 / 40

33.

КЭШ · RESPONSE
Кэш финальных ответов (response cache)
Самый быстрый, но самый рискованный кэш — применять осторожнее, чем embeddings.
Подходит для
• FAQ;
Не подходит для
• персональных данных;
• публичные документы;
• изменяемых данных;
• одинаковые вопросы;
• user-specific ответов;
• стабильные правила;
• юридически рискованных ответов;
• read-only сценарии.
• ответов без контроля источников.
Для персональных сценариев — добавляй user_id и access scope в cache key, либо запрещай кэширование. Кэшировать финальные
ответы нужно осторожнее, чем embeddings.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
33 / 40

34.

КЭШ · ИНВАЛИДАЦИЯ
Инвалидация кэша (cache invalidation)
Главный вопрос кэша: когда результат устарел?
Стратегии
• TTL (время жизни);
Пример ключа
• document_version;
course:v3:rag:top5:hash(query)
• index_version;
• model_version;
• ручная инвалидация;
• cache namespace per collection.
Документы обновлены
index_version меняется
старый кэш инвалидирован
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
34 / 40

35.

НАДЁЖНОСТЬ · AI-ОШИБКИ
Почему AI-системы ломаются иначе
HTTP 200 не значит, что ответ правильный — AI-система может «сломаться тихо».
Обычная ошибка (явная)
AI-ошибка (тихая)
Crash / 500 error
Уверенный, но неверный ответ
Timeout
Выдуманный источник (hallucination)
Invalid JSON
Плохой формат генерации
Database down
Retrieval нашёл не тот документ
Нужны quality signals: retrieval quality, answer validation, source coverage, user feedback.
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
35 / 40

36.

НАДЁЖНОСТЬ · TIMEOUT
Таймауты (timeouts)
Таймаут — лимит времени на внешний вызов. Защищает систему от зависания.
Где нужны таймауты
• сервер модели;
• векторная база;
• база данных;
Пример лимитов
model_timeout
vector_db_timeout
cache_timeout
= 30s
= 3s
= 500ms
• кэш;
• внешний API;
• OCR-сервис и worker очереди.
Вызов
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Таймер
OK / Timeout
36 / 40

37.

НАДЁЖНОСТЬ · RETRY
Повтор с экспоненциальной задержкой (retry with backoff)
Повтор помогает при временных сбоях, но должен быть ограниченным.
• сетевой сбой (network glitch);
• rate limit;
Ограниченный повтор: 1s → 2s → 4s, max = 3
• временная перегрузка;
• сервер модели занят;
Attempt 1
fail → wait 1s
Attempt 2
fail → wait 2s
Attempt 3
success / fallback
• медленная векторная база.
for attempt in range(3):
try:
return call_model()
except Timeout:
sleep(2 ** attempt)
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
37 / 40

38.

НАДЁЖНОСТЬ · CIRCUIT BREAKER
Автоматический размыкатель (circuit breaker)
Защищает систему от каскадного отказа: если сервис часто падает — перестать его дёргать.
• если сервис часто падает — перестать вызывать;
Состояния
много сбоев
• временно открыть circuit;
• сразу использовать fallback;
Closed
Open
норма
fallback
• периодически проверять восстановление.
успех
cooldown
Half-open
проба
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
38 / 40

39.

НАДЁЖНОСТЬ · ДЕГРАДАЦИЯ
Постепенная деградация (graceful degradation)
Система работает ограниченно, но не падает полностью.
векторная база недоступна
ответ без источников + предупреждение
large model недоступна
small model
кэш недоступен
полный pipeline
мониторинг недоступен
локальный лог
Уровни
Full
Partial
Honest
OCR не работает
просьба сменить формат файла
«Сейчас поиск по документам недоступен. Могу дать общий ответ, но без источников.»
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
39 / 40

40.

ИТОГ · OBSERVABILITY & ADR
Наблюдаемость, ADR и итог
• AI-система — это набор сервисов, а не одна модель.
• сервер API управляет request flow;
Мини-шаблон ADR
• Decision: использовать pgvector для capstone.
• маршрутизатор выбирает путь обработки;
• Context: нужен простой деплой с PostgreSQL.
• кэш снижает задержку и стоимость;
• Options: pgvector, Qdrant, ChromaDB.
• таймаут, повтор, размыкатель и fallback повышают надёжность;
• Tradeoff: проще деплой, но меньше advanced features.
• журналы, метрики и трассировка делают систему наблюдаемой;
• Result: подходит для учебной production-like системы.
• ADR объясняет, почему выбрали X вместо Y.
Architecture
System Design Patterns for AI · Паттерны системного дизайна для AI-систем
Failures
Mitigations
Observability
ADR
40 / 40