DeepSeek API: как проверить developer role и ошибку совместимости

Начните с минимального воспроизводимого запроса

Создайте отдельный staging fixture с одной нейтральной пользовательской фразой и одной проверяемой ролью. Уберите инструменты, длинную историю, вложения и бизнес-логику. Цель теста — увидеть только форму входа, класс ответа и безопасный идентификатор версии адаптера. Если одновременно меняются пять полей, невозможно понять, что именно вызвало несовместимость.

Сохраните дату проверки, имя локального адаптера, маршрут, тип ответа и нормализованную категорию ошибки. Не записывайте полный текст сообщения, URL клиента, секреты или заголовки. Документация поставщика и поведение gateway могут изменяться независимо; один удачный запрос не становится вечным правилом для production.

Не подменяйте роль без явного решения приложения

Иногда команда пытается при ошибке автоматически заменить developer на system или склеить инструкции с пользовательским текстом. Такое преобразование меняет смысл, границы данных и контроль доступа. Его нельзя считать техническим retry. Сначала решите, допустим ли другой формат для вашего продукта, и только потом реализуйте отдельный, тестируемый путь.

Хороший адаптер принимает разрешённые роли через allowlist, проверяет тип контента и создаёт небольшой внутренний объект. Доменный слой решает, может ли сценарий продолжаться. Неизвестная роль переводит операцию в состояние requires_review либо возвращает понятную ошибку интерфейсу; она не должна молча попадать в prompt другого tenant.

Разделите ошибку контракта и временный сбой

HTTP-ошибка, timeout и неверная роль требуют разных действий. Контрактная ошибка означает: остановить автоматический повтор, сохранить категорию и показать разработчику версию входного fixture. Временная недоступность не подтверждает, что формат стал неверным, но также не разрешает повторять рискованное действие без собственной защиты от дублей.

Сделайте таблицу локальных состояний: accepted, rejected_by_validation, needs_review и unknown_outcome. Пользователь должен видеть честный статус, а не ложное «сообщение отправлено». Если ответ не удалось классифицировать, не расширяйте список разрешённых полей по одному случаю — сначала исследуйте staging и текущую спецификацию.

Защитите rollout feature flag и версией конфигурации

Привязывайте формат сообщений к версии конфигурации, а не к неявной ветке кода. Feature flag позволяет включить новый адаптер для синтетического или небольшого внутреннего потока, собрать безопасные метрики и откатиться без изменения ключей или сетевой топологии. Flag не подтверждает доступность модели и не заменяет контрактный тест.

Критерием отката может быть рост неизвестных ролей, несоответствие схемы или запретный side effect в тесте. Не используйте расплывчатое «ответ стал хуже»: определите наблюдаемое условие до запуска. После rollback сохраните короткую запись о версии и причине, чтобы повторное изменение не вернуло ту же ошибку через другой SDK.

Логируйте структуру, а не содержание диалога

Для диагностики обычно достаточно operation ID, tenant, имени адаптера, версии схемы, разрешённой роли, размера сообщения и категории проверки. Полный prompt и ответ модели повышают риск утечки и редко нужны для первого шага. Если тестовый пример необходим, храните отдельный искусственный fixture с вымышленными значениями и ограниченным сроком доступа.

Нельзя отправлять в телеметрию upstream key, Authorization, cookie или содержимое инструкций под видом отладки роли. Проверьте это отдельным тестом: лог должен содержать только allowlisted поля. Такой контроль описывает ваше приложение, а не правила хранения, доступность или поведение внешнего сервиса.

Закройте задачу регрессионным набором

В CI добавьте сценарии для разрешённой роли, неизвестной роли, неверного типа контента, пустого массива, чужого tenant и неожиданного поля в ответе. Каждый сценарий должен подтверждать отсутствие сетевого side effect и предсказуемый локальный статус. Эти проверки выполняются без реального ключа и остаются полезными при замене SDK.

Дальше сопоставьте текущий результат с материалами о совместимости DeepSeek и OpenAI-compatible API, контрактных тестах tools и карте ошибок AI API. Ссылки помогают построить проверку, но финальное решение всегда принимает тест вашего маршрута.

Безопасный server-side пример

Пример показывает только локальную логику приложения. Он не делает сетевой вызов, не содержит реальных ключей и не доказывает поддержку endpoint. Перед подключением рабочего маршрута сверяйте актуальный договор и API-контракт.

export function validateMessages(messages, tenantId) {
  const allowedRoles = new Set(['user', 'developer']);
  if (!Array.isArray(messages) || !tenantId) return { ok: false, state: 'rejected_by_validation' };
  for (const message of messages) {
    if (!allowedRoles.has(message?.role) || typeof message?.content !== 'string') {
      return { ok: false, state: 'requires_review' };
    }
  }
  return { ok: true, adapterVersion: 'roles-v1' }; // local validation only
}

Критерий готовности

Сценарий можно расширять только после того, как проверка формы входа, прав, локального статуса и отсутствия секрета в журнале прошла на синтетических данных. Неизвестный ответ — причина остановить конкретный адаптер и провести сверку, а не причина ослабить ограничение.

Граница ответственности и данных

Не передавайте в браузер, обычный журнал, тикет или статью API-ключи, заголовок Authorization, cookie, ключи поставщиков, полный prompt либо персональные данные. Для расследования используйте минимальные технические метаданные и синтетические fixtures.

Контроль перед выпуском

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

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

Полезные материалы

DeepSeek API Docs · OWASP Input Validation Cheat Sheet

FAQ

Нужно ли автоматически заменить developer на system?

Нет. Это изменение смысла, а не безопасный retry. Сначала подтвердите допустимый формат для своего сценария на staging, добавьте отдельную версию адаптера и проверьте права, изоляцию tenant и регрессии.

Что сохранить при ошибке совместимости?

Сохраните локальный operation ID, версию адаптера, дату, разрешённую категорию ошибки и минимальные метаданные. Не сохраняйте ключи, Authorization, полный prompt, cookie или персональные данные.

Доказывает ли успешный тест поддержку на будущее?

Нет. Он подтверждает только наблюдаемый сценарий в момент проверки. После смены маршрута, SDK, модели или схемы повторите тест и держите feature flag для контролируемого отката.

Следующий шаг

Продолжите с материалами: DeepSeek и OpenAI-compatible API · Контрактные тесты tools · Карта ошибок моделей. Затем протестируйте интеграцию на staging до production-трафика.