Что входило в запрос к API модели?

Что проверяют

Действительно ли вы интегрировали модель в сервис или видели её только в ноутбуке. Вопрос уточняющий, он идёт следом за рассказом о проекте, и интервьюер смотрит, помните ли вы состав полезной нагрузки и всё, что вокруг неё: аутентификацию, таймауты, версии, логирование.

Как отвечать

Разложить свой реальный запрос по слоям, коротко и конкретно:

• транспорт: метод POST на эндпоинт инференса, формат тела, ключ или токен в заголовке;
• полезная нагрузка: объекты для предсказания и набор признаков у каждого, ровно в том виде и порядке, в каком их видела модель при обучении;
• служебные поля: версия или имя модели, идентификатор запроса для сквозной трассировки, режим одиночного вызова или батча;
• откуда брались признаки: считались на лету в вызывающем сервисе, приходили из хранилища признаков или из кэша;
• параметры постобработки: порог отсечения, число возвращаемых кандидатов.

Если речь про языковую модель, состав другой: системная инструкция, пользовательский текст, описание инструментов, ограничение на длину ответа, параметры выбора токенов.

Дальше стоит самому добавить про надёжность: таймаут и повторы, ограничение размера батча, что происходит при недоступности модели, и что именно писалось в логи для последующего разбора и контроля дрейфа. Отдельный плюс, если скажете, что персональные данные в запрос не клали.

Где спотыкаются

Отвечают одной фразой про то, что отправляли объект с признаками. Это не ответ: интервьюер ждёт деталей, по которым видно личное участие.

Второе: приводят красивые цифры вроде ускорения на треть или точности до сотых, которых не считали. Один уточняющий вопрос про методику замера, и вся история рассыпается. Честнее назвать порядок величины и оговорить, что точно не помните.

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