Выбор API модели ИИ — это не поиск по каталогу. Модель может хорошо выглядеть в демонстрации и всё же не подходить для продукта, который вам нужно создать. Когда рабочий процесс становится доступен реальным пользователям, важны также её элементы управления, формат вывода, время выполнения и поведение при ошибках.
Начните с нужного вам результата. Определите доступные входные данные, ожидаемый пользователем результат, требуемый уровень качества и неприемлемые сценарии сбоев. Это даст команде тест, который другой человек сможет запустить и проверить.
Начните с текущего каталога
Используйте OdiRouter model catalog, чтобы увидеть доступные сейчас модели и модальности. В нём есть категории для работы с изображениями, видео и аудио, поэтому он служит более надёжным источником актуальных вариантов, чем статическая статья или старое объявление о запуске.
Первое сравнение следует сузить. Для коротких роликов о продукте сравните рабочие процессы с видео. Для визуальных материалов сравните рабочие процессы обработки изображений. Для озвучивания или звука сравните рабочие процессы с аудио. Один-единственный тест, сочетающий в себе все методы исследования, обычно затрудняет принятие необходимого решения.
Создайте небольшой набор тестов
Приведите примеры, которые напоминают ту работу, которую вам предстоит выполнять. Включите обычный входной запрос, сложный входной запрос и случай, выявляющий важное ограничение. Например, видеотест может включать обычный промпт, промпт с обязательным объектом и промпт, в котором явно задано требование к таймингу.
Для каждого теста сохраняйте входные данные, запрошенные параметры, полученный результат и итог. Одного лучшего результата недостаточно. Фиксируйте, что происходит, когда входные данные неполны, задаче требуется опрос статуса или запрос нужно повторить.
Сравните поведение в эксплуатации
Применяйте одинаковые критерии к каждому кандидату. Проверьте, соответствует ли результат запросу, достаточно ли элементов управления для задачи, как поступает результат и как ведёт себя рабочий процесс, если запрос не завершается ожидаемым образом. Для получения информации, которая может измениться, обратитесь к странице текущей модели и странице с ценами.
Не называйте это сравнение эталонным, если у вас нет определенного метода тестирования и данных для публикации. Обычно протокол принятия решений оказывается более полезным. В нём указаны задача, кандидаты, набор входных данных, критерии, выявленные компромиссы и причина окончательного выбора.
Перейдите от тестирования к интеграции
После выбора рабочего процесса используйте OdiRouter getting-started documentation для получения API-ключей, сведений об авторизации, идентификаторов моделей, примеров первого запроса и рекомендаций по настройке. Для асинхронных задач обработки медиа начните с multimodal setup documentation.
По возможности отделяйте выбор модели от логики приложения. Тогда вы сможете повторно запускать тот же набор тестов при изменении доступности каталога или требований к продукту, а ваша команда сможет проверить решение до его выхода в продакшен.
Практический следующий шаг
Откройте OdiRouter model catalog, выберите модальность, соответствующую задаче вашего продукта, и запустите минимальный набор тестов, способный выявить значимое различие. Когда у вас появится кандидат, используйте документацию, чтобы реализовать жизненный цикл запроса, необходимый вашему приложению.