Используйте рабочий процесс DeepSeek R1 API только после проверки того, какой идентификатор модели может использовать ваша учетная запись OdiRouter в настоящее время. В общедоступном OdiRouter model catalog DeepSeek указан среди провайдеров; также в нём описан один из процессов работы с API-ключом для изучения моделей и цен. Прежде чем приложение начнёт зависеть от имени модели, считайте каталог источником достоверной информации.
Это руководство по работе с моделью, ориентированной на рассуждения: как определить идентификатор модели, выполнить небольшой запрос, задать контракт вывода и протестировать важные для продукта сценарии. В нём не предполагаются фиксированные цена, ограничение контекста, результаты бенчмарков или возможность дообучения для DeepSeek R1. Эти сведения могут меняться, поэтому при разработке проверяйте актуальные каталог и документацию.
Проверьте каталог перед написанием интеграции
Откройте OdiRouter model catalog и отфильтруйте модель или провайдера, которых хотите протестировать. Затем ознакомьтесь с model list documentation. В нём описан каталог моделей, доступных для текущего API-ключа, и поддерживается фильтрация по категории, провайдеру, модальности и ключевому слову.
Поместите возвращённый идентификатор модели в конфигурацию. Так он не будет разбросан по коду запросов, а контролируемую смену модели будет значительно проще протестировать. Скопированный фрагмент кода никогда не должен становиться источником истины для изменяемого идентификатора.
До отправки запроса определите, что именно вам нужно оценить. Вашему приложению могут понадобиться краткий ответ, структурированный JSON, объяснение кода или классификация. Выберите конфигурацию модели, которая отвечает этому требованию на репрезентативных входных данных.
Создайте ключ и отправьте небольшой запрос
В OdiRouter quick start описаны вход в систему, создание API-ключа и подготовка аккаунта к использованию в production. Не размещайте ключ в системе контроля версий и загружайте его через среду развертывания. Сведения о базовом URL и аутентификации смотрите в поддерживаемом LLM setup documentation.
Общедоступный каталог моделей включает пример запроса Chat Completions. Заменяйте заполнитель только после того, как определите идентификатор модели, который в настоящее время доступен вашей учётной записи:
curl https://api.odirouter.ai/v1/chat/completions \
-H "Authorization: Bearer $ODIROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "<MODEL_ID_FROM_CATALOG>",
"messages": [
{
"role": "user",
"content": "Summarize the following support ticket in three factual bullet points: ..."
}
]
}'Начните с небольшого безвредного ввода. Проверьте, что аутентификация проходит успешно, определённый идентификатор модели принимается, а клиент получает ожидаемую структуру ответа. Не следует размещать секретные данные о производстве в блокноте, консоли браузера, заявке или примере ответа.
Напишите временный контракт, который может проверить приложение.
Многие сбои интеграции начинаются с недостаточно четко сформулированного запроса. Фраза "Проанализируйте это" предоставляет как звонящему, так и модели слишком много пространства для заполнения пробелов. Краткий контракт должен описывать задачу, входные данные, ограничения и требуемый формат вывода.
Для процесса поддержки задачей может быть «извлечь проблему и запрошенное действие». Входными данными является текст обращения. В ограничениях можно указать, что ответ не должен выдумывать факты и может цитировать идентификатор только в том случае, если он присутствует в обращении. Выходными данными может быть небольшой JSON-объект с фиксированными полями. Это даёт приложению чёткий объект для проверки.
Храните инструкции вместе с запросом, которому они нужны. В многошаговом процессе передавайте факты и решения, необходимые следующему шагу, вместо того чтобы просить последующий запрос восстановить скрытый контекст. Сохраняйте исходные входные данные и разобранный вывод только в том случае, если это соответствует политике обработки данных и ожиданиям пользователя.
Тестируйте поведение до выпуска в production
Создайте небольшой набор для оценки из случаев, которые продукт действительно обрабатывает. Включите обычные примеры, неполные входные данные, противоречивые инструкции, длинные входные данные и случаи, которые следует отклонить или передать человеку. Определите, что должен содержать успешный ответ и чего он содержать не должен.
Классифицируйте неудачи, а не рассматривайте их как одну проблему. Отсутствующее поле, недопустимый JSON, неподтверждённое утверждение и чрезмерно длинный ответ требуют разных реакций. В качестве оптимального изменения можно использовать более понятную схему вывода, проверку на стороне приложения, другой запрос, другую конфигурацию модели или путь ручной проверки.
Один впечатляющий ответ еще не доказывает надежность поведения. Повторяемый набор тестов позволяет сравнивать изменение промпта, изменённый идентификатор модели или выпуск приложения. Убедитесь, что тестовые данные соответствуют используемой учетной записи и политике обработки данных.
Сохраняйте контроль над приложением.
Приложение должно обеспечивать авторизацию, доступ к данным, ограничения скорости запросов, повторные попытки и окончательные действия. Проверяйте структурированный вывод до того, как он попадёт в базу данных, сообщение клиенту, команду или платёжный процесс. Запрашивайте подтверждение или используйте явный этап проверки перед действием, имеющим последствия.
Устанавливайте тайм-ауты запросов и осознанно выбирайте поведение повторных попыток. Повторяйте только те сбои, которые безопасно повторять. Для операций, которые могут дважды создать внешнее действие, используйте идемпотентную архитектуру. Логируйте достаточно метаданных для отладки запроса, удаляйте секреты и не храните конфиденциальное содержимое промптов, если это не разрешено политикой и ожиданиями пользователя.
Когда результат содержит фактические рекомендации, цитаты или извлечённые идентификаторы, проверяйте информацию, на основе которой будет действовать ваш продукт. Ответ модели может помочь процессу, не заменяя обычные бизнес-правила.
Продолжите с текущей информацией OdiRouter
После того как первый запрос заработает, вернитесь к OdiRouter model catalog, чтобы сравнить текущие варианты для данного сценария использования. Используйте documentation для сведений об интеграции, pricing page для актуальной коммерческой информации и процесс регистрации когда будете готовы создать учётную запись.
Для ознакомления с моделями прочитайте исходный DeepSeek-R1 repository вместе с текущим каталогом OdiRouter. Явно фиксируйте выбор модели, результаты оценки и меры защиты для production в собственных записях приложения.