Skip to main content

Обзор

gemini-3-pro-image-preview (то есть Nano Banana Pro) применяет строгие механизмы контроля безопасности контента и будет отклонять несоответствующие запросы на нескольких уровнях. Простое сообщение «сбой генерации» не помогает пользователям понять проблему. Хорошая обработка ошибок должна:
  • Точно определять причину отклонения — различать нарушения правил контента, ограничения базы знаний и технические ошибки
  • Предоставлять понятные сообщения пользователю — превращать технические ошибки в объяснения, которые легко понять
  • Предлагать практические рекомендации — подсказывать пользователям, как изменить запрос, чтобы он сработал
  • Сохранять полные технические сведения — для отладки разработчиками
Когда запрос возвращает HTTP 200, но изображения нет, обычно это решение, связанное с безопасностью, принятое на стороне Google. Прозрачный прокси APIYI просто передаёт результат как есть — мы тоже хотим, чтобы наши клиенты успешно генерировали изображения. Логику определения и сообщений нужно реализовать на стороне вашего приложения.

Политика модерации контента Google (Обновление 2026)

Генерация изображений Google использует двухуровневый механизм безопасности:
  1. Настраиваемые фильтры: охватывают четыре категории — домогательства, разжигание ненависти, контент сексуально откровенного характера и опасный контент — и настраиваются через safetySettings
  2. Встроенные защиты: всегда активны для базовых вредоносных сценариев (например, безопасности детей) и не могут быть отключены через параметры
Явно запрещенный контент включает: сексуальное насилие и эксплуатацию детей (CSAE), насильственный экстремизм/терроризм, интимные изображения без согласия (NCII), самоповреждение, контент сексуально откровенного характера, разжигание ненависти, а также домогательства и травлю.
В феврале 2026 года, после запуска Nano Banana 2, Google значительно ужесточила свои политики в отношении людей и авторского права, добавив/усилив следующие частые сценарии отклонения (данные по состоянию на май 2026 года (UTC+8)):
  • Публичные фигуры / знаменитости: фотореалистичные, узнаваемые реальные люди
  • Подмена лица (faceswap)
  • Переодевание / изменение внешности реальных людей
  • Подделка финансовой информации или информации о заказе
  • Известные объекты интеллектуальной собственности (например, Disney, начиная с 23 января 2026 года)
  • Удаление водяных знаков и контент, связанный с несовершеннолетними
По-прежнему разрешены: вымышленные персонажи, стилизованные портреты и иллюстрированные фигуры.
Официальные документы политики Google (скопируйте и откройте их самостоятельно):
  • Запрещенная политика использования Generative AI: policies.google.com/terms/generative-ai/use-policy
  • Справочник по распространенным ошибкам генеративного контента: ai.google.dev/api/generate-content

Три основных диагностических индикатора

Проверяйте в порядке приоритета, от высшего к низшему:

1. candidatesTokenCount (наивысший приоритет) ⭐

  • Location: response.usageMetadata.candidatesTokenCount
  • Meaning: количество token в сгенерированном API содержимом кандидата
  • Rule: значение 0 означает, что запрос был полностью отклонён на этапе модерации контента — содержимое кандидата вообще не было сгенерировано. Это самый строгий тип отклонения.

2. finishReason (второй приоритет)

  • Location: response.candidates[0].finishReason
  • Rule: любое значение, отличное от STOP, указывает на аномальное завершение, требующее особой обработки
Последние значения finishReason, связанные с изображениями (обратите внимание, что серия Nano Banana добавила специфичные для изображений значения с префиксом IMAGE_):

3. Пояснение отклонения текста (важно)

  • Location: response.candidates[0].content.parts[].text
  • Rule: когда finishReason равно STOP, но parts содержит только text и не содержит данных изображения, API возвращает пояснение отклонения, а не изображение. Текст может быть на китайском или английском, например:

Краткая справка по сценариям ошибок

Порядок обработки (порядок принятия решений)

Реализация кода (основное)

Объедините проверки выше в одну функцию парсинга:
Умное определение ключевых слов (необязательно, для более точных сообщений):
Самая распространенная ошибка: часть, содержащая thoughtSignature, все еще может содержать важные text. Всегда сначала собирайте текст, а затем решайте, нужно ли пропускать — иначе пояснение причины отклонения теряется, и пользователи видят только «сбой генерации».

Сообщения для конечных пользователей

Принципы оформления: ясно и кратко, позитивные рекомендации, практичность, без обвинений. Рекомендуемые шаблоны:
Рекомендации по поэтапному отображению:
  • Конечные пользователи: по умолчанию показывайте только дружелюбное объяснение + предложение по исправлению
  • Бизнес / поставщики инструментов: по умолчанию раскрывайте технические подробности (finishReason, candidatesTokenCount и т. д.)
  • Разработчики: предоставьте переключатель «развернуть/свернуть» для просмотра полного ответа JSON

Лучшие практики

  1. Проверяйте строго по приоритету: candidatesTokenCountfinishReasonparts → извлечение данных → обнаружение ключевых слов
  2. Собирайте текст до проверки thoughtSignature, чтобы не потерять объяснение отказа
  3. Сохраняйте полный ответ: инструменты разработки и тестирования всегда должны сохранять необработанный JSON для устранения неполадок
  4. Поддерживайте текст отказа на китайском и английском языках: Google может вернуть текст на китайском или английском, поэтому сопоставление по ключевым словам должно покрывать оба варианта
  5. Плавная деградация: выдавайте конкретное сообщение, когда интеллектуальное обнаружение успешно срабатывает; иначе показывайте текст API напрямую; иначе используйте дружественное имя finishReason; и только затем переходите к общему сообщению
  6. Никогда не показывайте «неизвестная ошибка»: всегда включайте практическую рекомендацию или полный ответ

Частые вопросы

Фильтрация безопасности Google имеет элемент случайности и зависит от контекста: содержимое reference image и способ объединения prompt влияют на решение. Попробуйте изменить формулировку или использовать более косвенное выражение.
candidatesTokenCount: 0 или finishReason: PROHIBITED_CONTENT → проблема с контентом; Failed to fetch или HTTP-ошибка → техническая проблема; текстовое объяснение API → обычно проблема с контентом.
Многоуровневое отображение: по умолчанию показывайте дружелюбное объяснение + предложение по исправлению; при необходимости раскрывайте технические детали; в режиме разработки показывайте полный JSON-ответ.
Нет. Достаточно таблицы сопоставления и универсального fallback: reasonMessages[finishReason] || , а затем отображайте исходное значение.

Связанное чтение