# Content parts в API провайдера: проверка структуры до генерации

Как валидировать строковый content и массив text/image parts до запуска модели: роли, вложенные поля, негативные fixtures и границы поддержки.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-message-content-parts-contract/
Language: ru

Мультимодальный запрос отличается от текстового не только размером вычислительной нагрузки. На границе API он может содержать массив объектов разных типов вместо одной строки. Ошибка в форме вложенного объекта должна обнаруживаться до дорогостоящего выполнения, но корректная форма сама по себе ещё не доказывает поддержку изображения выбранной моделью. Проверка провайдера разделяет эти уровни и сохраняет точный источник отказа.

## Опишите допустимые формы content

[Публичная схема OpenRouter](https://openrouter.ai/docs/api_reference/overview) показывает строковый content и content parts с отдельными типами. Она также связывает допустимые формы с ролями сообщения. Используйте конкретную выбранную схему, а не правило «любое поле с названием content принимает массив».

В собственном контракте укажите, какие типы частей действительно обрабатываются endpoint. Если модель поддерживает только текст, принятие произвольного image object не должно выглядеть как подтверждённая мультимодальная функция. Не переносите возможности одного backend на весь каталог под одним публичным алиасом.

## Разделите последовательность проверок

Первый слой — корректность JSON. Второй — форма сообщения и вложенных полей. Третий — допустимость типа части для выбранной модели. Затем могут потребоваться получение исходных данных, подготовка и выполнение. Эти стадии следует различать в диагностике, даже если внешнее сообщение ошибки остаётся кратким.

[RFC 8259](https://www.rfc-editor.org/rfc/rfc8259.html) определяет представление JSON, но не смысл image_url или роли user. Успешный разбор документа означает только прохождение первого слоя. Клиентский объект может быть валиден синтаксически и непригоден для интерфейса из-за неверного типа или обязательного вложенного свойства.

## Составьте маленькую матрицу входов

Начните с короткой текстовой части. Добавьте вторую текстовую часть, затем один synthetic image reference с контролируемым источником, если функция заявлена поддержанной. Негативные варианты меняют по одному признаку: неизвестный type, отсутствующий URL, неверный тип вложенного значения либо недопустимая роль.

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

## Проверьте вложенные ограничения

[JSON Schema для объектов](https://json-schema.org/understanding-json-schema/reference/object) описывает required и additionalProperties. Эти механизмы помогают отделить обязательное поле от лишнего свойства, но поведение конкретного сервиса зависит от его полной схемы. При поддержке нескольких версий набор допустимых полей может различаться.

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

## Сохраните пределы conformance

Прошедший структурный fixture не подтверждает распознавание объектов на изображении, допустимость всех размеров или качество ответа. Для этого нужен отдельный модельный тест с известным результатом и ресурсными пределами. Аналогично успешный ответ одной модели не устанавливает возможности любой реплики сервиса.

Контекст вычислений описан в [мультимодальном GPU-хостинге](/ru/journal/multimodal-gpu-hosting/), а выбор артефакта — в [проверке Qwen3-VL](/ru/journal/qwen3-vl-vram-requirements/). Эти темы дополняют контракт content parts, сохраняя различие между формой запроса, доставкой данных и полезным результатом модели.