Gemini: нет изображения или IMAGE_SAFETY — полное руководство по диагностике

Когда генерация изображений в Gemini как будто завершается без результата, самое важное — понять: «скрытый сбой» — это не одна единственная проблема. По состоянию на 15 марта 2026 года официальная документация Google разделяет как минимум четыре разных состояния, которые пользователи нередко путают между собой: блокировка на стороне промпта, блокировка изображения на стороне вывода, отсутствие сгенерированного изображения и технические сбои, не связанные с политикой, — например, неоднозначные промпты или ошибки в структуре запроса. Если рассматривать все четыре случая как «поломанную политику контента Gemini», вы будете снова и снова применять неверное исправление.

Если говорить кратко: когда входной промпт заблокирован, поле promptFeedback заполнено, а candidates не возвращается. Когда промпт принят, но сгенерированное изображение заблокировано на выходе, Google указывает, что candidates существует, content отсутствует, а finishReason объясняет причину остановки. Значение IMAGE_SAFETY в finishReason — это не то же самое, что NO_IMAGE, и ни одно из них не является текстовым отказом с STOP. Эти различия принципиально важны, поскольку каждое из них указывает на разный следующий шаг.

Это руководство посвящено конкретным сценариям, которые пользователи ищут по запросам вроде «скрытый сбой Gemini при генерации изображений», «исправить IMAGE_SAFETY» и «политика контента Gemini для изображений». Оно основано на актуальной документации Google, а не на устаревших материалах 2024 года о скандале с генерацией людей в Gemini. В нём также используются свежие треды с форума Google AI Developers за ноябрь–декабрь 2025 года, чтобы показать, где реальные ошибки до сих пор вводят пользователей в заблуждение, — особенно когда AI Studio или Gemini API не возвращают полезного изображения, хотя промпт выглядит безопасным.

Если вы столкнулись с более широкой проблемой отклонения промптов в разных моделях — не только при генерации изображений в Gemini — наше руководство по блокировке промптов из-за предупреждений безопасности охватывает ChatGPT, Gemini, Claude и Azure на уровне политики. Эта статья уже, но технически точнее: она посвящена правильной диагностике сбоев изображений Gemini прежде, чем вы начнёте переписывать промпты, смягчать фильтры или предполагать, что платформа недоступна.

Краткое содержание

• Прежде чем менять промпт, изучите структуру ответа. Наличие promptFeedback означает, что промпт был заблокирован до завершения генерации изображения.
• Если candidates существует, но content отсутствует, а finishReason равен IMAGE_SAFETY, изображение было отфильтровано на выходе после начала генерации.
• Если finishReason равен NO_IMAGE, Gemini принял запрос, но не создал изображение. Обычно это требует более явных инструкций по генерации изображения, повторной попытки или отладки структуры запроса.
• Ответ только с текстом — не всегда признак нарушения политики. На текущей странице ограничений генерации изображений Google сказано, что неоднозначные промпты могут возвращать текст без изображения.
• Настраиваемые параметры безопасности не отключают всю защиту. В документации Google по параметрам безопасности указано, что встроенная защита от базовых угроз остаётся активной и не может быть отключена.
• Не воспринимайте ошибки 404, 429 и 503 как проблемы политики контента. Если вы видите их — начните с нашего руководства по кодам ошибок Gemini 3 Pro Image.

Как определить, заблокировал ли Gemini промпт, изображение или просто ничего не сгенерировал

Большая часть времени при отладке тратится впустую из-за пропущенной классификации. Пользователи видят «нет изображения», предполагают «политика контента», а затем тратят 20 минут на переписывание промпта, который на самом деле не был проблемой. Документация Google по заблокированным ответам предлагает более правильный подход: сначала изучите структуру ответа, и только потом решайте, какой вид исправления имеет смысл.

Вот самый быстрый способ ориентироваться в ситуации:

В текущей документации Vertex AI Google чётко разграничивает блокировку промпта и блокировку ответа. Если промпт заблокирован, promptFeedback заполнен и нет никакого кандидата для проверки. Если заблокирован ответ — promptFeedback отсутствует, candidates присутствует, а отсутствующий content в сочетании с finishReason объясняют произошедшее. Именно поэтому сообщение UI-уровня вроде «не удалось создать изображение» слишком грубое, чтобы самостоятельно диагностировать проблему. Содержимое ответа API, как правило, информативнее, чем текст в интерфейсе.

Это также объясняет, почему некоторые пользователи называют проблему «скрытой». Сам ответ может и не быть скрытым, но поверхность, на которой пользователь работает, всё равно может казаться непрозрачной. В AI Studio, приложении Gemini или тонком интеграционном слое продукт может показать обобщённую ошибку или вовсе не отобразить слот для изображения. Если вы можете воспроизвести запрос через API или Vertex и проверить полный ответ, вы часто сразу узнаете, заблокировал ли системой промпт, изображение или просто ничего не создал.

Если у вас есть только симптомы AI Studio или приложения без необработанного содержимого ответа, воспользуйтесь этой быстрой последовательностью действий, прежде чем эскалировать проблему:

1. Начните новую сессию и явно попросите: «Создай изображение...» вместо того, чтобы отправлять короткое именное словосочетание.
2. Попробуйте крошечный безопасный тестовый промпт, например: «Создай изображение красной керамической кружки на деревянном столе».
3. Если безопасный тест проходит — вероятнее всего, причина в вашем исходном промпте или предшествующем контексте чата.
4. Если безопасный тест также не проходит — проверьте, работает ли тот же запрос через API или Vertex, или рассматривайте проблему как более широкую, связанную с поверхностью продукта, а не только с промптом.

Для команд эта классификация должна стать обязательным стандартом. Никогда не записывайте в лог просто «генерация изображения завершилась неудачей». Записывайте идентификатор модели, поверхность запроса, наличие promptFeedback, наличие candidates, итоговый finishReason, наличие частей inlineData с изображением и точную метку времени в UTC. Без этих данных ошибки политики, регрессии при выкатке и обычная неоднозначность промпта выглядят одинаково при разборе инцидентов.

Что на самом деле означают IMAGE_SAFETY, NO_IMAGE и STOP

Текущий справочник по API Gemini особенно важен для этой темы, поскольку указывает, какие перечисления относятся к блокировке промптов, а какие — к завершению кандидатов. Это разделение — основа правильной диагностики.

Блокировка на стороне промпта использует значения BlockReason. По состоянию на официальный справочник, последний раз обновлённый 12 января 2026 года, они включают SAFETY, BLOCKLIST, PROHIBITED_CONTENT и IMAGE_SAFETY. Завершение кандидата использует значения FinishReason. Для случаев с изображениями наиболее важны IMAGE_SAFETY, IMAGE_PROHIBITED_CONTENT, IMAGE_OTHER, NO_IMAGE и IMAGE_RECITATION. Даже если слова похожи, они не означают одного и того же в разных местах.

Начнём с STOP, поскольку именно он чаще всего вводит в заблуждение. На странице Google по ответственному ИИ для генерации изображений Gemini поясняется, что потенциально небезопасный запрос на изображение может вызвать текстовый отказ с FinishReason = STOP. Иными словами, система может вовсе не сигнализировать об «ошибке фильтра». Она может просто сказать «я не буду создавать это изображение» обычным текстом модели. Именно поэтому ответы только с текстом нужно читать, а не игнорировать.

IMAGE_SAFETY — другое. Когда вы видите finishReason = IMAGE_SAFETY, запрос продвинулся дальше, чем при блокировке промпта. Google документирует это как остановку безопасности на стороне вывода. Промпт был принят достаточно далеко, чтобы создать запись кандидата, но финальное содержимое изображения не было выдано. Вот почему многие пользователи ощущают, будто Gemini «начал, а потом тихо завис». На практике кандидат-изображение концептуально существует, но контент не был возвращён.

NO_IMAGE — снова другое. Это не означает автоматически «политика». Это означает, что изображение не было создано. Такое может произойти из-за неоднозначного запроса, из-за того что модель выбрала текстовое, а не графическое поведение, из-за незавершённой попытки генерации или из-за ошибки в структуре запроса или транспортном уровне, которая не позволила получить корректный ответ с изображением. На текущей странице ограничений генерации изображений Google прямо говорится, что Gemini может создать текст и не создать изображение при неоднозначном промпте, а также что модель может остановиться, не завершив работу. Это операционные исправления, а не интерпретации политики.

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

IMAGE_PROHIBITED_CONTENT строже, чем IMAGE_SAFETY. Он указывает на запрещённую категорию, а не просто на настраиваемую классификацию безопасности. В руководстве по фильтрам безопасности Vertex отмечается более широкий момент: некоторые категории не настраиваются, особенно там, где речь идёт о запрещённом контенте. Если вы столкнулись с IMAGE_PROHIBITED_CONTENT, не думайте в терминах «как заставить это пройти». Думайте в терминах «этот запрос пересекает границу политики».

Один тонкий, но важный момент: одна и та же метка может появляться на разных уровнях. IMAGE_SAFETY может присутствовать как в BlockReason на стороне промпта, так и в FinishReason на стороне кандидата. Поэтому нельзя диагностировать проблему только по строке перечисления. Нужно знать, где именно она появилась. Возвращала ли модель кандидата? Был ли заполнен promptFeedback? Отсутствовал ли content? Эти структурные подсказки важнее самого слова.

Практическое правило простое:

• promptFeedback присутствует: начните с классификации на стороне промпта.
• finishReason = STOP: прочитайте текст отказа и воспринимайте его как отказ модели.
• finishReason = IMAGE_SAFETY: воспринимайте это как фильтрацию на стороне вывода.
• finishReason = NO_IMAGE: воспринимайте это как «принято, но изображение не создано» до доказательства обратного.

Этот подход решит больше случаев, чем любой универсальный совет «переписать промпт».

Быстрые исправления для ответов только с текстом и других скрытых сбоев, не связанных с политикой

Текущая страница ограничений генерации изображений Gemini — самая полезная официальная страница для этого раздела, поскольку подтверждает то, что многие разработчики узнают только методом проб и ошибок: некоторые случаи отсутствия изображения — вовсе не отказы из-за политики. Это проблемы формы генерации. Если пропустить этот раздел и перейти сразу к настройке политики, вы ошибочно диагностируете множество сбоев.

Первое исправление до неловкости простое, но работает на удивление часто: явно попросите изображение. Если ваш промпт читается как анализ, мозговой штурм или написание подписи, Gemini может вернуть текст. В формулировках самого Google сказано, что модель может создать только текст и не создать изображение, если промпт неоднозначен. Поэтому вместо «Спокойный японский магазин на закате» напишите: «Создай изображение спокойного японского магазина на закате, стиль кинематографической фотографии, композиция 16:9». Эта одна дополнительная инструкция может изменить режим выбора модели.

Второе исправление — убедиться, что вы действительно запросили вывод изображения так, как того ожидает ваш SDK. В разных SDK одно и то же поле называется чуть по-разному, но суть одна: запросите вывод изображения, а не просто обобщённое мультимодальное завершение. Если вы используете новый Gemini SDK и забыли указать модальность ответа с изображением, модель всё равно может ответить текстом, поскольку с её точки зрения вы задали общий вопрос о генерации контента, а не строгий запрос на генерацию изображения.

Вот минимальный пример на Python, который явно указывает намерение получить изображение:

python
from google import genai
from google.genai import types

client = genai.Client(api_key="YOUR_API_KEY")

response = client.models.generate_content(
    model="gemini-2.5-flash-image",
    contents="Generate an image of a ceramic coffee cup on a walnut desk, soft morning light, editorial product photo.",
    config=types.GenerateContentConfig(
        response_modalities=["IMAGE"]
    )
)

Если ответ содержит только текст, не останавливайтесь на «Gemini сломан». Изучите возвращённые части. Если вы получили только текстовые части без inlineData, вы имеете дело с проблемой выбора режима или структуры запроса — до тех пор, пока содержимое ответа не докажет обратное.

Третье исправление — выполнять повторные попытки для незавершённых генераций дисциплинированно. На странице ограничений генерации изображений Google, последний раз обновлённой 14 марта 2026 года, говорится, что модель может остановить генерацию контента, даже не завершив её, и прямо рекомендуется повторить попытку или изменить промпт. Это не разрешение бездумно повторять попытки 30 раз. Это означает, что небольшое количество контролируемых повторных попыток разумно, когда содержимое ответа указывает на неполную генерацию, а не на остановку политики. На практике одна немедленная повторная попытка и одна с изменённым промптом достаточно, чтобы понять, является ли сбой временным.

Четвёртое исправление — уменьшить неоднозначность, вызванную смешанными задачами. Многие неудачные промпты просят Gemini анализировать, резюмировать, сравнивать и генерировать изображение — всё в одном обороте. Это увеличивает вероятность получить ответ с приоритетом текста, особенно в интеграциях в стиле чата. Разделяйте эти задачи. Если вам нужно, чтобы модель поняла изображение и затем создала новое, сначала выполните шаг рассуждения, затем шаг генерации. Чем более однозадачным является запрос, тем проще диагностировать, что пошло не так.

Пятое исправление — изучить, как отправляются входные изображения. В одном полезном треде на форуме от 3 ноября 2025 года сообщалось, что редактирование изображений работало с inlineData, но возвращало только текст, когда запрос использовал fileData определённым образом. Ответчик от Google показал рабочий шаблон загрузки, и первоначальный автор впоследствии подтвердил, что схема работает. Вывод не в том, что «никогда не используйте файлы». Вывод в том, что транспорт запроса может изменять поведение, а результат только с текстом не означает автоматически политики контента. Если fileData даёт сбой, а inlineData работает с тем же безопасным промптом, вы, скорее всего, имеете дело с проблемой интеграции, а не с вердиктом модерации.

Шестое исправление — соблюдать задокументированные ограничения на количество входных изображений. На текущей странице ограничений Google говорится, что Gemini 2.5 Flash Image лучше всего работает не более чем с 3 входными изображениями, тогда как Gemini 3 Pro Image следует использовать с 14 входными изображениями или меньше. Если вы добавляете слишком много ссылок в один запрос, систему становится труднее интерпретировать и отлаживать. Даже если жёсткий лимит не достигнут, сложные стеки ссылок увеличивают вероятность деформированных или непригодных выходных данных. При сортировке скрытых сбоев меньшее количество входных изображений упрощает воспроизведение.

Седьмое исправление — проверить очевидный операционный уровень прежде, чем пересматривать содержание. Если тот же промпт и содержимое запроса работали вчера, а теперь дают ошибку 404, 429 или 503, вы не смотрите на изменение политики контента. Вы смотрите на маршрутизацию, квоту или пропускную способность. Вот почему мы рекомендуем использовать эту статью в связке с нашим руководством по стабильному каналу Gemini 3 Pro Image, когда проблема кажется системной, а не специфичной для промпта.

Наконец, не игнорируйте хронологию. Если безопасный промпт внезапно перестаёт работать в узком временном окне, а несколько пользователей на форуме сообщают о похожих симптомах — это подсказка о регрессии. В треде форума Google AI Developers от 25 ноября 2025 года описывалось, как безопасные фотографические рабочие процессы начали давать сбои почти без объяснений со стороны политики, а затем частично восстановились примерно за 48 часов. Это не доказательство для каждого случая, но напоминание о том, что поведение платформы меняется со временем. Иногда правильное исправление — не «придумать лучший эвфемизм». Оно звучит так: «запишите точную временну́ю метку, создайте минимальное воспроизведение и убедитесь, что регрессия шире вашего аккаунта».

Быстрые исправления для IMAGE_SAFETY и блокировок промптов в рамках политики

Здесь много онлайн-советов становятся небрежными. Советовать пользователям «обойти безопасность Gemini» — и плохое руководство, и противоречит Политике допустимого использования генеративного ИИ Google, которая прямо запрещает попытки обойти средства защиты от злоупотреблений или фильтры безопасности. Правильный вопрос — не «как мне обойти фильтры?». Правильный вопрос — «как выразить законный запрос достаточно ясно, чтобы Gemini мог правильно его классифицировать?»

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

Например, если вы редактируете изображения для fashion или продуктовой съёмки, избегайте расплывчатых промптов вроде «сделай более сексуальным» или «взрослая атмосфера» — они могут вытолкнуть безопасный запрос в сторону явно сексуальной интерпретации. Более безопасная и чёткая версия звучит примерно так: «Создай студийное фото бежевого хлопкового спортивного бюстгальтера на белом бесшовном фоне, каталожное освещение, без модели, без акцента на позу, стиль розничного продуктового фото». Вторая версия по-прежнему коммерчески полезна, но убирает множество неоднозначных сигналов, которые могут вытолкнуть запрос в IMAGE_SAFETY.

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

Второй безопасный шаблон переформулировки за пределами fashion — заменить неоднозначность сцены аудиторией и форматом. Вместо «сцена травмы протестующего из истории», которая может быть отнесена к классификации насилия, попробуйте: «Создай нефотографическую образовательную иллюстрацию для стенда музея об истории борьбы за гражданские права в 1960-х, стиль постера, без видимых ран, акцент на плакаты толпы и полицейские заграждения». Такая переформулировка не гарантирует одобрения, но даёт модели более безопасную и чёткую целевую точку вывода, чем расплывчатый запрос на драматическую сцену.

Блокировки на стороне промпта и остановки IMAGE_SAFETY на стороне вывода требуют несколько разных ментальных моделей. Когда сам промпт заблокирован, система говорит вам, что запрос не должен продвигаться в том виде, в каком он сформулирован. Когда промпт принят, но финальное изображение заблокировано, система говорит вам, что созданный визуальный результат пересёк границу, даже если входной текст не был отклонён на входе. Практический ответ в обоих случаях — убрать неоднозначные или чувствительные визуальные сигналы, но блокировка на стороне вывода особенно выигрывает от снижения реализма, уменьшения чувственной подачи, исключения деталей с акцентом на тело или переосмысления сцены вокруг нечувствительного объекта, а не пограничного визуала.

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

Ещё одно важное исправление — изолировать задачу по изображению от окружающего контекста разговора. В длинных чатах модель видит больше, чем вашу последнюю строку. Если в предыдущих оборотах обсуждались насилие, сексуальность, травма, преступность или темы, чувствительные с точки зрения безопасности, последующий запрос на изображение может унаследовать этот контекст. Если промпт неожиданно начинает давать сбои — попробуйте новую сессию только с точной инструкцией по генерации изображения и минимально необходимым исходным изображением. Это один из самых чистых способов отличить «загрязнение контекста» от жёсткой границы политики.

Также помните, что «работало раньше» — не то же самое, что «должно работать всегда». Данные сообщества от 24 декабря 2025 года показывают, что законные промпты для нижнего белья в электронной коммерции всё ещё могли заканчиваться IMAGE_SAFETY в Vertex AI Studio, даже после того как пользователь сообщал о смягчённых настройках сексуального контента. Это не означает, что документация Google неверна. Это означает, что фильтрация на стороне вывода всё ещё может перевесить то, что пользователь ожидает от регулируемых настроек. Правильная позиция заключается не в том, что «Google игнорирует свои собственные элементы управления». Правильная позиция: «регулируемые настройки существуют, но встроенная защита и защита на уровне вывода всё равно могут решить, что изображение не следует возвращать».

Если ваш случай явно находится в запрещённой категории — остановитесь на этом. Границы политики Google не созданы для того, чтобы их обходить с помощью инженерии промптов. Если ваш случай законен и всё равно блокируется — задокументируйте точную модель, регион, дату, сигнал содержимого ответа и анонимизированный промпт, затем эскалируйте с этой информацией. Точность полезнее, чем десять дополнительных попыток переформулировки.

Что параметры безопасности Gemini могут изменить, а что — нет

Здесь многие рейтинговые страницы рассказывают историю наполовину правильно и поэтому вводят в заблуждение. Да, у Gemini есть настраиваемые параметры безопасности. Нет, это не означает, что каждый отказ от изображения поддаётся настройке.

В текущей документации по параметрам безопасности, последний раз обновлённой 15 января 2026 года, говорится, что настраиваемые категории охватывают четыре области: домогательства, разжигание ненависти, явный сексуальный контент и опасный контент. Это звучит широко, но на той же странице также говорится, что существует встроенная защита от базовых угроз, которую нельзя настроить вовсе. Простыми словами: можно настроить некоторые фильтры, но нельзя отключить всю систему безопасности.

На той же официальной странице также говорится, что если вы не устанавливаете порог явно, порог блокировки по умолчанию равен Off для моделей Gemini 2.5 и 3. Это важно, поскольку многие устаревшие руководства всё ещё советуют пользователям вручную устанавливать наиболее разрешительный порог просто для того, чтобы базовая генерация изображений заработала. По состоянию на текущую документацию это предположение устарело. Если вы не получаете желаемого результата, причина часто не в том, что «вы забыли ослабить пороги». Более вероятно — неоднозначный промпт, фильтрация на стороне вывода или ненастраиваемая защита.

Используйте таблицу поверхностей управления ниже как проверку реальности:

Документация Vertex AI по безопасности добавляет ещё один важный нюанс: коды отклонения промптов могут включать PROHIBITED_CONTENT, а заблокированные ответы могут заканчиваться связанными с безопасностью причинами завершения, тогда как сам заблокированный контент скрыт. Это означает, что существуют уровни применения политики. Запрос может завершиться неудачей из-за настраиваемой категории, ненастраиваемой категории или самого сгенерированного вывода. Если вы смотрите только на один регулятор, вы видите лишь часть системы.

Вот как правильно говорить о BLOCK_NONE или других разрешительных порогах в 2026 году: они могут снизить дополнительную настраиваемую блокировку для определённых категорий, но они не являются мастер-переключателем для всего поведения безопасности изображений. Если вы видите, что законный запрос всё равно возвращает IMAGE_SAFETY, это не автоматически свидетельство сломанной настройки. Это может просто означать, что классификатор на уровне вывода или встроенная защита всё же решили не возвращать изображение.

Для команд, создающих продуктовые процессы поверх Gemini, инженерный вывод ясен. Относитесь к параметрам безопасности как к одному входу системы, а не ко всей системе. Создавайте логирование и UX, способные объяснить: «Этот запрос попал под блокировку безопасности изображений на стороне вывода», а не просто «Генерация не удалась». Чем точнее ваш продукт называет сбой, тем меньше вероятность того, что пользователи сочтут ваше приложение нестабильным или ненадёжным.

Сбои API, AI Studio, Vertex AI и приложения — не одно и то же

Многие плохие статьи говорят о «Gemini», как будто существует один универсальный продуктовый интерфейс. Это не так. Одно и то же семейство моделей может ощущаться очень по-разному в зависимости от того, используете ли вы сырой Gemini API, Vertex AI, AI Studio или потребительское приложение Gemini.

Сырой API и Vertex AI — лучшие места для отладки, поскольку позволяют проверять структуру ответа. Вы можете видеть promptFeedback, candidates, отсутствующий content и finishReason. Именно поэтому техническая диагностика должна начинаться там, когда это возможно. Если вы используете только UI-слой, вы отлаживаете по симптомам, а не по данным.

AI Studio занимает промежуточную позицию. Он достаточно близок к платформе, чтобы быть полезным, но всё ещё является поверхностью продукта со своими UX-решениями, собственным циклом выпуска и периодическими регрессиями. Вот почему два человека могут сообщать о «скрытом сбое Gemini», хотя только один из них на самом деле сталкивается с блокировкой политики. Другой, вероятно, сталкивается с ошибкой структуры запроса, регрессией продукта или поведением, специфичным для поверхности, которое API сделал бы более очевидным.

Потребительское приложение Gemini ещё дальше от содержимого ответа. Доступность приложения, права на тарифный план, состояние выкатки функции и ограничения на уровне UI — всё это может повлиять на то, работает ли создание изображений на вид. Если вы отлаживаете серьёзный рабочий процесс — не полагайтесь только на симптомы приложения. По возможности воспроизводите через API или AI Studio, чтобы видеть, является ли проблема политикой, возможностью или поведением поверхности продукта.

Регион и доступность модели также усложняют картину. В треде сообщества от 20 апреля 2025 года сообщалось, что переключение на серверное расположение us решило ошибку «не найдено» для gemini-2.0-flash-exp-image-generation. Это не проблема политики контента, но пользователи часто воспринимают её как «Gemini image не работает». Урок шире конкретной экспериментальной модели: регион, маршрутизация и состояние развёртывания могут имитировать сбои политики в восприятии пользователей.

То же самое касается квоты и перегрузки. Пользователь, получающий 429 или 503, всё равно может описывать результат как «ничего не создано». Если ваши логи показывают исчерпание квоты или недоступность сервиса — прекратите думать о политике контента. Начните с квоты и пропускной способности. Мы рассматриваем это отдельно в нашем руководстве по ограничениям частоты запросов Gemini API и связанной статье о кодах ошибок Gemini image, упомянутой ранее.

Лучшая практика для команд поддержки — задавать три вопроса, прежде чем предлагать какое-либо исправление промпта:

1. Какую поверхность вы используете: API, Vertex AI, AI Studio или приложение?
2. Есть ли у вас необработанное содержимое ответа или только сообщение UI?
3. Воспроизводится ли сбой с минимальным безопасным промптом в новой сессии?

Эти три вопроса отделяют половину ложных обращений о «политике контента» от реальных ложноположительных срабатываний безопасности.

Рабочий процесс диагностики для многократного использования

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

Начните с небольшого классификатора в логах вашего приложения. Это не элегантная теория. Это операционная гигиена.

python
def classify_gemini_image_result(resp):
    if getattr(resp, "prompt_feedback", None):
        return {
            "kind": "prompt_blocked",
            "block_reason": getattr(resp.prompt_feedback, "block_reason", "UNKNOWN"),
        }

    candidates = getattr(resp, "candidates", None) or []
    if not candidates:
        return {"kind": "no_candidates"}

    candidate = candidates[0]
    finish_reason = getattr(candidate, "finish_reason", "UNKNOWN")
    content = getattr(candidate, "content", None)
    parts = getattr(content, "parts", None) if content else None

    has_inline_image = False
    has_text = False
    if parts:
        for part in parts:
            if getattr(part, "inline_data", None):
                has_inline_image = True
            if getattr(part, "text", None):
                has_text = True

    return {
        "kind": "candidate_returned",
        "finish_reason": finish_reason,
        "has_inline_image": has_inline_image,
        "has_text": has_text,
        "content_missing": content is None,
    }

Код не обязан быть сложным. Он просто должен каждый раз отвечать на шесть вопросов:

1. Был ли присутствует promptFeedback?
2. Возвращались ли какие-либо candidates?
3. Каков был итоговый finishReason?
4. Отсутствовал ли content?
5. Возвращались ли какие-либо части inlineData с изображением?
6. Вернула ли модель текст вместо изображения?

После того как у вас есть эта классификация, остальная часть рабочего процесса становится намного надёжнее.

Вот рабочий процесс, который мы рекомендуем использовать в продакшене:

1. Захватите необработанное содержимое ответа, а не только строку ошибки, обращённую к пользователю.
2. Классифицируйте сбой, используя структурные поля выше.
3. Воспроизведите с минимальным безопасным промптом в новой сессии.
4. Если минимальный безопасный промпт работает — проблема, вероятно, в формулировке промпта или контексте чата.
5. Если минимальный безопасный промпт завершается неудачей таким же образом — проверьте структуру запроса, регион, идентификатор модели и текущий статус платформы.
6. Если поведение внезапно изменилось при том же содержимом запроса — запишите точное время UTC и поверхность для эскалации.
7. Только после классификации решайте, следует ли переписывать, повторять, ждать или переключиться на другой маршрут.

Также записывайте переменные, которые действительно помогают при анализе первопричин:

• идентификатор модели
• используемая поверхность
• регион или конечная точка
• количество входных изображений
• были ли входные данные в виде inlineData или файлов
• запрашивалась ли модальность вывода изображения
• хеш промпта
• временна́я метка UTC
• версия SDK или клиента

Эти данные спасут вас каждый раз, когда появляется регрессия. Когда поддержка спросит «Можете ли вы воспроизвести?» — у вас уже будет ответ. Когда тред на форуме предположит ошибку при выкатке — вы будете знать, совпадают ли ваши сбои по дате и поверхности. И когда окажется, что сбой — это просто проблема структуры запроса, вы не будете тратить неделю, называя это проблемой безопасности.

Когда ждать, эскалировать или использовать резервный маршрут

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

Ждите и повторяйте, когда данные указывают на незавершённую генерацию, а не на твёрдую блокировку. Страница ограничений изображений Google прямо говорит, что генерация может остановиться до завершения. Это зелёный свет для ограниченной стратегии повторных попыток. Правильная версия этого контролируема: повторите сразу один раз, затем один раз с немного более чётким промптом. Если тот же классифицированный сбой повторяется — прекратите воспринимать его как временный.

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

Эскалируйте, когда ранее работавший безопасный рабочий процесс внезапно ломается, особенно если:

• тот же минимальный промпт раньше работал
• сбой начался в узком временном окне
• несколько пользователей или тредов на форуме сообщают о похожем поведении
• проблема воспроизводится в новых сессиях

При эскалации отправляйте минимальное, но полное воспроизведение:

• название модели
• поверхность
• регион
• точная временна́я метка
• анонимизированный промпт
• наличие promptFeedback
• finishReason
• отсутствие content

Это делает ваш отчёт пригодным для использования. «Gemini снова тихо завис» — нет.

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

Если реальная проблема — производственная непрерывность, а не использование потребительского приложения, ретрансляционный слой может быть разумным решением. laozhang.ai — один из совместимых с OpenAI вариантов ретрансляции для команд, которым нужна унифицированная маршрутизация API вместо одной официальной конечной точки. Это не исправление для запрещённых запросов и не должно преподноситься таким образом. Это операционный выбор для надёжности, согласованности интеграции или мультимодельной маршрутизации. Если это ваша задача — сначала сравните компромиссы канала, а не рассматривайте политику и маршрутизацию как одну и ту же проблему.

Более широкий урок состоит в том, что «скрытый сбой Gemini image» — это не единственный класс ошибок. Иногда правильный ответ — «ваш промпт пересёк границу». Иногда — «структура вашего запроса неверна». Иногда — «Google принял промпт, но отфильтровал финальное изображение». И иногда — «модель вовсе не создала изображение». Чем быстрее вы называете правильный класс, тем быстрее прекращаете тратить время на неправильное исправление.

Ещё одна производственная привычка, которую стоит выработать: храните анонимизированный пакет для воспроизведения для каждого инцидента безопасности изображений, дошедшего до пользователя. Пакет должен содержать название модели, временну́ю метку UTC, регион, поверхность запроса, использовался ли запрос только с текстом или с редактированием изображения, количество входных изображений, были ли они отправлены как загруженные файлы или встроенные данные изображения, итоговую причину блокировки или завершения, а также хеш промпта и читаемый анонимизированный промпт. Это звучит утомительно, но превращает расплывчатую жалобу в инженерный артефакт, с которым можно работать. Это также позволяет сравнивать инциденты за несколько недель и видеть, связано ли изменение с одной поверхностью, одним семейством моделей, одним шаблоном промпта или одним новым выпуском продукта.

Тот же пакет для воспроизведения полезен, когда вам нужно решить, оставаться ли на официальном маршруте или добавить резервные мощности. Если 95% ваших сбоев — явно блокировки на стороне промпта, дополнительные слои маршрутизации не решат основную проблему. Если сбои группируются вокруг незавершённых генераций, ответов только с текстом или внезапных регрессий поверхности, которые исчезают на другом маршруте, — тогда операционная избыточность начинает иметь смысл. Это различие защищает команды от покупки инфраструктуры для решения того, что в действительности является проблемой дизайна промптов, и защищает от обвинения промптов в том, что на самом деле является проблемой доступности.

Часто задаваемые вопросы

Наиболее полезная ментальная модель проста: сначала классифицируйте, потом исправляйте. Текущая документация Google, проверенная в период с 12 января по 14 марта 2026 года, уже говорит нам, что сбои изображений Gemini делятся на блокировки на стороне промпта, блокировки на стороне вывода, результаты без изображения и проблемы генерации, не связанные с политикой. Как только вы читаете содержимое ответа через эту призму, IMAGE_SAFETY, NO_IMAGE и ответы только с текстом перестают выглядеть как один загадочный блоб политики контента.

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

Если вы запомните только одно из этой статьи — запомните вот что: promptFeedback говорит вам, что промпт был заблокирован, finishReason = IMAGE_SAFETY говорит, что выходное изображение было заблокировано, а finishReason = NO_IMAGE говорит, что Gemini фактически не создал изображение. Это три разные операционные ветви, и именно потому, что их воспринимают как одну, большинство сессий по устранению неполадок с изображениями Gemini ходят по кругу.

Почему Gemini возвращает текст вместо изображения?

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

Почему BLOCK_NONE или ослабленная настройка безопасности не исправляет IMAGE_SAFETY?

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

В чём разница между IMAGE_SAFETY и NO_IMAGE?

IMAGE_SAFETY означает, что выходное изображение было заблокировано после того, как запрос продвинулся достаточно далеко, чтобы создать запись кандидата. NO_IMAGE означает, что изображение не было создано. Правильное исправление для NO_IMAGE часто — ясность или повторная попытка, а не интерпретация политики.

Почему промпт, который работал на прошлой неделе, вдруг перестал работать?

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

Безопасно ли продолжать повторять один и тот же неудачный запрос?

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

Официальные источники: заблокированные ответы в Vertex AI, справочник по API Gemini, параметры безопасности Gemini, ограничения генерации изображений Gemini, генерация изображений Gemini и ответственный ИИ, а также Политика допустимого использования генеративного ИИ Google.