Эксперимент с использованием изображений может ответить на один из первых вопросов: выглядит ли это направление многообещающим? Следующий вопрос носит практический характер. Как этот результат впишется в продукт, процесс создания контента или внутренний инструмент? Интеграция API с использованием ИИ начинается с небольшого запроса, который команда может проверить и повторить. В первый день не обязательно автоматизировать весь процесс.
Это руководство посвящено следующему шагу. Определите нужный результат, найдите модель, которую стоит протестировать, подготовьте интеграцию и решите, что оценивать с OdiRouter.
Определите результат до выбора модели
Начните с описания успешного результата. Для процесса работы с изображениями укажите формат входных данных, нужное визуальное изменение, формат выходных данных и способ проверки результата. Сделайте первую версию достаточно узкой, чтобы человек мог проверить её без сложного процесса.
Перечислите ограничения, относящиеся к рабочему процессу. Команде контента может потребоваться единообразная подготовка материалов. Команде продукта может потребоваться этап утверждения до того, как результат попадёт к пользователям. Инженерам может понадобиться определить, где в приложении должны находиться учётные данные, идентификаторы моделей и обработка запросов. На эти вопросы легче ответить, если записать их отдельно.
Выберите модель, которую можно протестировать
Начните с задачи, а не с известного названия модели. Просмотрите позывной model catalog, чтобы найти подходящих кандидатов. OdiRouter описывает каталог. В нём перечислено более 200 AI-моделей в категориях текста, изображений, видео, аудио и 3D. Каталог использует один API-ключ. Используйте каталог, чтобы найти кандидатов, соответствующих задокументированным вами входным и выходным данным.
Для каждого кандидата запишите предполагаемую задачу, входные данные, которые вы будете отправлять, выходные данные, которые вы будете проверять, и результат, который направит вас к другому варианту. Эта запись даёт команде конкретный предмет для обсуждения. Один привлекательный пример полезен, но не является решением для продакшена.
Первый тест не обязан охватывать все граничные случаи. Он должен показать, соответствует ли путь к модели выбранным вами критериям проверки. Сохраните входные и выходные данные, чтобы следующее сравнение начиналось с той же исходной точки.
Настройте первую интеграцию
Когда у вас появится кандидат для тестирования, откройте getting-started documentation. Во введении OdiRouter рассматриваются ключи API, авторизация, идентификаторы моделей, примеры первых запросов и настройка SDK. Уточните эти детали, прежде чем превращать эксперимент в запрос приложения.
Храните конфигурацию отдельно от обрабатываемых медиафайлов или контента. Храните учётные данные в соответствии с принятой у вас практикой управления секретами, используйте выбранный идентификатор модели и сохраняйте допущения о входных данных вместе с запросом. Позднее проверяющий должен иметь возможность увидеть, что было протестировано, не восстанавливая это по памяти.
Сделайте первый запрос наблюдаемым. Зафиксируйте выбор модели, нечувствительные настройки, необходимые для воспроизведения, выходные данные и результат проверки. Если результат не достигает цели, по возможности меняйте по одному фактору за раз. Следующий тест даст ответ на вопрос, а не станет очередной попыткой угадать ответ.
Сравните стоимость, скорость и доступность.
Оценка должна быть частью плана интеграции. Прочитайте pricing page, когда сравниваете текущие цены на модели или конфигурации тестирования с бесплатными кредитами. OdiRouter определяет стоимость, скорость и доступность как факторы, влияющие на маршрутизацию запросов.
Используйте эти факторы как запись обоснования решения, а не как обещание, что каждый запрос будет вести себя одинаково. Более низкая стоимость имеет значение только в том случае, если результат соответствует критериям проверки. Быстрый ответ важен лишь в том случае, если он подходит для предполагаемого использования. Доступность имеет значение, когда рабочий процесс зависит от пути модели во время запроса.
Для первоначального сравнения используйте одинаковые входные данные и критерии проверки для каждого кандидата. Укажите контекст текущих опубликованных цен, время, затраченное в вашем собственном тесте, и то, соответствовал ли результат требованию. Если рабочая нагрузка меняется, проведите тестирование снова с новыми ограничениями.
Превратите прототип в повторяемый запрос
Прежде чем расширять интеграцию, убедитесь, что команда может ответить на следующие вопросы:
Какие входные данные допустимы и какой результат должен давать запрос?
Какой идентификатор модели тестируется и где находится официальное руководство по настройке?
Как команда будет проверять качество выходных данных до того, как они попадут к пользователю или в другой рабочий процесс?
Какие доказательства она будет использовать для сравнения стоимости, скорости и доступности для этой задачи?
Кто отвечает за следующее изменение, если тест не соответствует критериям приемки?
Когда эти ответы получены, следующий шаг ограничен и ясен. Выполните ограниченный запрос, проверьте его, затем решите, следует ли уточнить входные данные, протестировать другой путь к модели или интегрировать утверждённый рабочий процесс. Просмотрите models, прежде чем выбирать кандидатов. Используйте getting-started guide для тестового запроса. Проверьте current pricing information в ходе оценки.