Вопрос проверяет умение проектировать гибкие и расширяемые API для ML-систем.
API должно быть ориентировано на сценарии, а не на конкретные модели. Один и тот же inference может использоваться по-разному. Backend скрывает детали реализации и предоставляет стабильный контракт. Часто используются разные эндпоинты или параметры сценария. Это упрощает развитие системы.
ML-модели редко используются одинаково во всех частях системы, поэтому API должно учитывать контекст применения.
Определение:
Сценарий использования ML-модели — это конкретный бизнес-процесс, в котором применяется inference.
Основные принципы проектирования API:
Ориентация на бизнес-сценарии
/detect_objects
/analyze_frame
/evaluate_risk
API отражает смысл, а не тип модели
Абстракция моделей
Клиент не знает, какая модель используется
Возможна замена модели без изменения API
Гибкость параметров
Настройки качества
Приоритеты обработки
Асинхронные и синхронные режимы
Версионирование
Изменения без ломающих контрактов
Поддержка старых клиентов
@app.post("/analyze")
async def analyze(data: dict, scenario: str):
return {"status": "processed"}Краткий вывод:
Хорошо спроектированное API позволяет использовать ML-модели в разных сценариях без роста сложности backend-кода.
