Ошибка thought_signature в Nano Banana 2 (400 INVALID_ARGUMENT) возникает, когда ваши многооборотные API-запросы не содержат поле thought_signature, которое модель вернула в предыдущем ответе. Nano Banana 2 (gemini-3.1-flash-image-preview) использует расширенное мышление, генерирующее зашифрованные токены рассуждений, и каждый последующий запрос в рамках одного диалога должен включать эти подписи в неизменном виде. Исправление простое: извлеките поле thoughtSignature из каждого ответа API и передайте его обратно в истории диалога следующего запроса. Если вы используете функции чата официального Google Gen AI SDK, это обрабатывается автоматически, но если вы обращаетесь к REST API напрямую, используете OpenAI-совместимые эндпоинты или работаете через платформы вроде Dify или n8n, вам необходимо обрабатывать это вручную.
Что такое ошибка Thought Signature и зачем она нужна Nano Banana 2?
Когда вы отправляете многооборотный запрос к Nano Banana 2, и API отвечает 400 INVALID_ARGUMENT: Unable to submit request because it has an invalid thought signature for content at index N, вы столкнулись с одной из самых распространённых — и самых раздражающих — ошибок семейства моделей Gemini 3. Эта ошибка не означает, что ваш API-ключ неверен или запрос некорректен в традиционном смысле. Она означает, что внутренняя цепочка рассуждений модели была нарушена, потому что из истории диалога отсутствует необходимая часть контекста.
Чтобы понять, почему это происходит, нужно знать, как модели Gemini 3 обрабатывают «мышление». Когда Nano Banana 2 (идентификатор модели: gemini-3.1-flash-image-preview, документация Google AI, март 2026) обрабатывает ваш запрос, она выполняет расширенное мышление — внутренний этап рассуждений, который помогает модели спланировать ответ перед генерацией результата. Этот этап мышления создаёт зашифрованную строку под названием thought_signature, которая по сути является сжатым представлением процесса рассуждений модели. Представьте это как сохранение в видеоигре: модели нужно это сохранение, чтобы когерентно продолжить диалог в следующем ходе. Без него модель не может проверить, что полученная история диалога соответствует тому, что она действительно сгенерировала, и отклоняет запрос с ошибкой 400.
Критическая деталь, на которой спотыкается большинство разработчиков, заключается в том, что эта подпись генерируется даже когда вы явно устанавливаете thinkingConfig: { thinkingBudget: 0 } или отключаете мышление. Процесс мышления всё равно запускается «под капотом», и подпись всё равно создаётся и требуется. Официальная документация Google подтверждает, что токены мышления всегда тарифицируются независимо от конфигурации мышления (ai.google.dev/thought-signatures, март 2026). Это застаёт врасплох многих разработчиков — они полагают, что отключение мышления означает возможность игнорировать поле подписи, и получают ошибку 400 уже на втором ходе. Если вы боролись с этой ошибкой при создании рабочих процессов редактирования изображений в диалоге, вы не одиноки: проблемы на GitHub в Dify (#2262), CherryStudio (#11391), n8n, OpenClaw (#5001) и Pipecat (#3557) — все они восходят к одной и той же коренной причине. Для более широкого обзора других ошибок NB2 помимо thought signatures смотрите наше полное руководство по устранению неполадок Nano Banana 2.
Когда Thought Signatures обязательны, а когда нет?
Понимание того, когда необходимо передавать thought signatures обратно, а когда их можно безопасно игнорировать, является ключом к предотвращению этой ошибки во всей вашей кодовой базе. Правила отличаются для моделей Gemini 3 и Gemini 2.5, а также снова меняются для сценария генерации изображений Nano Banana 2. Неправильное решение означает либо ненужную сложность в коде, либо неожиданные ошибки 400 в продакшене.
Для моделей Gemini 3 (gemini-3-flash-preview, gemini-3-pro-preview) thought signatures обязательны для всех сценариев вызова функций. Это означает, что если ваше приложение использует инструменты или вызовы функций с Gemini 3, вы должны извлекать и возвращать thought signature в каждом последующем ходе — без исключений. Последовательные вызовы функций особенно сложны, поскольку каждый шаг в последовательности генерирует собственную подпись, и все они должны быть включены, когда вы отправляете результаты функций обратно. Параллельные вызовы функций работают по другой схеме: только первая часть functionCall в ответе несёт подпись, поэтому вам нужно захватить и вернуть только её. Для обычных текстовых многооборотных диалогов без вызовов функций подписи рекомендуются, но не принуждаются в Gemini 3 — то есть вы не получите ошибку 400 при их пропуске, но Google рекомендует их включать для оптимального качества ответов.
Для моделей Gemini 2.5 правила более мягкие. Thought signatures необязательны во всех случаях — вызовы функций, текстовые диалоги, всё. Модель принимает запросы как с подписями, так и без них. Однако если вы разрабатываете код, который должен работать и с Gemini 2.5, и с Gemini 3, самый безопасный подход — всегда передавать обратно всё, что модель возвращает, включая подписи.
Nano Banana 2 (gemini-3.1-flash-image-preview) относится к особой категории, поскольку используется преимущественно для многооборотной генерации и редактирования изображений. Когда вы генерируете изображение, а затем просите модель отредактировать его в следующем ходе, thought signature обязательна. Это основной сценарий использования, который приводит большинство разработчиков к этой ошибке, и он менее документирован, чем сценарий с вызовом функций. Практическое правило простое: если вы строите любой многооборотный рабочий процесс с NB2 — будь то генерация изображения с последующей доработкой, диалог о визуальном контенте или цепочка редактирования изображений — вы должны обрабатывать thought signatures. Подробное сравнение возможностей NB2 с другими моделями смотрите в нашем сравнении Nano Banana Pro и Nano Banana 2.
Исправление ошибки в многооборотной генерации изображений
Многооборотное редактирование изображений — это основной сценарий использования Nano Banana 2, и именно здесь большинство разработчиков впервые сталкиваются с ошибкой thought signature. Рабочий процесс прост — сгенерировать изображение, затем попросить модель его изменить — но обработка подписи добавляет критически важный шаг, который легко пропустить. Вот полный поток с выделением извлечения подписи на каждом этапе.
Реализация на Python с использованием Google Gen AI SDK:
pythonimport google.generativeai as genai import base64 genai.configure(api_key="YOUR_API_KEY") model = genai.GenerativeModel("gemini-3.1-flash-image-preview") response = model.generate_content( "Generate a photo of a golden retriever playing in a park", generation_config=genai.GenerationConfig( response_modalities=["TEXT", "IMAGE"] ) ) # Step 2: Extract the thought signature and image from the response thought_signature = None image_data = None text_response = "" for part in response.candidates[0].content.parts: if hasattr(part, "thought_signature") and part.thought_signature: thought_signature = part.thought_signature if hasattr(part, "inline_data") and part.inline_data: image_data = part.inline_data if hasattr(part, "text") and part.text: text_response += part.text print(f"Signature captured: {thought_signature[:30]}...") # Step 3: Build the multi-turn history WITH the signature history = [ # Your original request {"role": "user", "parts": [{"text": "Generate a photo of a golden retriever playing in a park"}]}, # The model's response — MUST include thought_signature {"role": "model", "parts": []} ] # Reconstruct the model's response parts with the signature for part in response.candidates[0].content.parts: part_dict = {} if hasattr(part, "text"): part_dict["text"] = part.text if hasattr(part, "inline_data") and part.inline_data: part_dict["inline_data"] = { "mime_type": part.inline_data.mime_type, "data": part.inline_data.data } if hasattr(part, "thought_signature") and part.thought_signature: part_dict["thought_signature"] = part.thought_signature history[-1]["parts"].append(part_dict) # Step 4: Send the edit request with complete history edit_response = model.generate_content( contents=history + [ {"role": "user", "parts": [{"text": "Now add a red frisbee in the dog's mouth"}]} ], generation_config=genai.GenerationConfig( response_modalities=["TEXT", "IMAGE"] ) ) # Step 5: Extract the NEW signature for potential further edits new_signature = None for part in edit_response.candidates[0].content.parts: if hasattr(part, "thought_signature") and part.thought_signature: new_signature = part.thought_signature print(f"Edit successful! New signature: {new_signature[:30]}...")
Критически важный шаг — это шаг 3: при восстановлении истории диалога предыдущий ответ модели должен содержать поле thought_signature точно в том виде, в каком оно было возвращено. Если вы его удалите, упростите ответ до одного текста и данных изображения или забудете пройтись по всем частям, следующий ход завершится ошибкой 400. Каждый ответ генерации изображений от NB2 будет содержать thought signature где-то в своих частях — ваша задача сохранить её без изменений.
Реализация на TypeScript:
typescriptimport { GoogleGenerativeAI } from "@google/generative-ai"; const genAI = new GoogleGenerativeAI("YOUR_API_KEY"); const model = genAI.getGenerativeModel({ model: "gemini-3.1-flash-image-preview" }); // The easiest approach: use the chat interface const chat = model.startChat({ generationConfig: { responseModalities: ["TEXT", "IMAGE"] } }); // Turn 1: Generate image (signature handled automatically by SDK) const result1 = await chat.sendMessage("Generate a photo of a sunset over mountains"); // Turn 2: Edit image (SDK passes signature automatically) const result2 = await chat.sendMessage("Add a silhouette of a person hiking"); // Turn 3: Refine further const result3 = await chat.sendMessage("Make the colors more vibrant and add lens flare");
В примере на TypeScript используется интерфейс чата SDK, который обрабатывает управление подписями автоматически. Если вы можете использовать этот подход, он полностью устраняет весь класс ошибок thought signature. SDK внутренне отслеживает все подписи и включает их в последующие запросы без какого-либо ручного вмешательства. Это безусловно рекомендуемый подход для большинства приложений. Подробности о ценах на генерацию изображений NB2 смотрите в нашем обзоре цен Nano Banana 2 API.
Обработка стриминга, параллельных вызовов и режима совместимости с OpenAI
Потоковые ответы, параллельные вызовы функций и режим совместимости с OpenAI — каждый из них привносит свои пограничные случаи с thought signature, которые могут незаметно нарушить работу вашего приложения. Случай со стримингом особенно коварен, поскольку включает тонкое взаимодействие между тем, как работают парсеры потоков, и тем, где подпись фактически появляется в потоке ответов.
Стриминг: ловушка пустой текстовой части
Когда вы используете стриминг с NB2 или любой моделью Gemini 3, thought signature приходит не в первом чанке и даже не в предсказуемом промежуточном. Она приходит в последнем чанке потока, и вот в чём подвох: последний чанк часто содержит часть с пустой текстовой строкой (text: "") наряду с полем thought_signature. Большинство парсеров потоков проверяют if chunk.text:, чтобы решить, обрабатывать ли чанк, а пустая строка вычисляется как false в большинстве языков. Это означает, что ваш парсер молча пропускает единственный чанк, содержащий подпись, и следующий ход завершается ошибкой 400.
Исправление состоит в том, чтобы явно проходить по частям, а не полагаться на вспомогательные свойства:
python# WRONG: Loses signature in empty text chunks signature = None for chunk in response: if chunk.text: # Empty string = False = signature lost! result += chunk.text # CORRECT: Check all parts in every chunk signature = None full_text = "" for chunk in response: for part in chunk.candidates[0].content.parts: if hasattr(part, "thought_signature") and part.thought_signature: signature = part.thought_signature if hasattr(part, "text") and part.text: full_text += part.text
Этот паттерн гарантирует захват подписи независимо от того, в каком чанке она появляется и является ли сопутствующая текстовая часть пустой. Влияние на производительность незначительное — вы просто проходите по частям, которые и так бы обрабатывали — но улучшение надёжности существенное.
Параллельные вызовы функций
Когда Gemini 3 возвращает несколько вызовов функций в одном ответе (параллельный вызов функций), только первая часть functionCall несёт thought signature. Последующие части вызовов функций в том же ответе не имеют собственных подписей. Когда вы возвращаете результаты функций, вам нужно включить подпись из этой первой части вызова функции в свой ответ. Это задокументировано в официальных документах Google, но легко упускается, когда вы сосредоточены на обработке самих вызовов функций. Если вы обрабатываете вызовы функций в цикле и извлекаете подписи из каждого, вы обнаружите, что значение есть только у первого — и эта единственная подпись и передаётся обратно.
Режим совместимости с OpenAI
Если вы обращаетесь к моделям Gemini через OpenAI-совместимый эндпоинт (типичный случай при миграции с OpenAI или использовании сервисов-шлюзов), thought signature находится в совершенно другом месте ответа. Вместо thought_signature на уровне части, она вложена в extra_content.google.thought_signature в объекте сообщения. Это ловит многих разработчиков, которые мигрируют свой код с OpenAI на работу с Gemini — они реализуют обработку подписей на основе документации нативного API Gemini, но уровень совместимости с OpenAI структурирует ответ по-другому. Исправление — проверить альтернативный путь к полю при использовании режима совместимости:
python# Native Gemini API signature = part.thought_signature # OpenAI Compatibility Mode signature = message.get("extra_content", {}).get("google", {}).get("thought_signature")
Оба пути необходимо обрабатывать, если ваше приложение поддерживает несколько режимов API. Для продакшен-приложений, которые должны работать как с нативными, так и с совместимыми эндпоинтами, мы рекомендуем абстрагировать извлечение подписи в вспомогательную функцию, которая проверяет оба местоположения.
Продвинутые обходные пути — фиктивные подписи и миграция моделей
В официальной документации Google скрыт обходной путь, который ни одна другая статья не выделяла заметно: фиктивные thought signatures. Когда у вас есть история диалога, которая не была сгенерирована Gemini 3 — например, если вы мигрируете с другой модели, вставляете синтетический контекст диалога или восстанавливаете историю из базы данных, которая не сохраняла подписи — вы можете использовать специальную строку-заглушку вместо реальной подписи.
Google предоставляет две официальные строки фиктивных подписей, которые обходят валидатор подписей (ai.google.dev/thought-signatures FAQ, март 2026):
python# Option 1: The recommended dummy signature dummy_signature = "context_engineering_is_the_way_to_go" # Option 2: Alternative dummy signature dummy_signature = "skip_thought_signature_validator"
Когда вы включаете любую из этих строк в качестве значения thought_signature в ходе модели в истории диалога, API принимает её без валидации. Это невероятно полезно для нескольких сценариев: миграция существующих историй диалогов с GPT-4 или Claude на Gemini 3, восстановление диалогов из баз данных, которые не были спроектированы для хранения thought signatures, вставка системных контекстных ходов, которые никогда не проходили через модель, и тестирование многооборотных рабочих процессов без необходимости реальных подписей.
Однако есть важные оговорки, которые нужно понимать, прежде чем полагаться на фиктивные подписи в продакшене. Фиктивная подпись сообщает модели, что контекст мышления соответствующего хода недоступен, а значит модель не может проверить связность рассуждений этого хода. Для рабочих процессов с вызовом функций в Gemini 3 это может привести к немного сниженному качеству ответов, поскольку модель не может обратиться к своей исходной цепочке рассуждений. Для NB2 с редактированием изображений использование фиктивной подписи на ходе генерации изображения означает, что модель может не идеально «помнить» свои творческие решения, что может повлиять на качество последующих правок. Подход с фиктивными подписями лучше всего работает как инструмент миграции или запасной вариант, а не как постоянная замена правильного управления подписями.
Практическое дерево решений ясно: если вы можете извлекать и сохранять реальные подписи, всегда делайте это. Если у вас есть устаревшая история без подписей, используйте фиктивные подписи, чтобы разблокировать миграцию, вместо перестроения всей истории диалогов с нуля. А если вы делаете прототип или тестируете, фиктивные подписи позволяют сосредоточиться на бизнес-логике, не беспокоясь о механизме подписей.
Платформенные исправления для Dify, CherryStudio, n8n и других
Ошибка thought signature — это не просто проблема сырого API, это также широко распространённая проблема на платформах и инструментах разработки ИИ. Когда вы используете модели Gemini 3 через Dify, CherryStudio, n8n или аналогичные платформы, внутренняя обработка сообщений платформы часто удаляет или теряет thought signature при управлении ходами диалога. Это означает, что у вас могут быть совершенно правильные учётные данные API и конфигурация модели, но вы всё равно получите ошибку 400, потому что платформа тихо отбрасывает поле, о котором не знает.
Dify — в настоящее время наиболее затронутая платформа. Система управления историей сообщений Dify удаляет нестандартные поля из ответов модели перед сохранением, и thought_signature обрабатывается как нестандартное поле. Это означает, что многооборотные диалоги с моделями Gemini 3 стабильно завершаются сбоем после первого хода. Проблема отслеживается в GitHub issue #2262, и pull request для её исправления ожидает рассмотрения. Тем временем обходной путь состоит в том, чтобы обойти встроенную интеграцию Gemini в Dify и использовать узел HTTP Request для прямого вызова API Gemini с собственным управлением историей диалога. Это требует больше настройки, но даёт полный контроль над телом запроса и ответа.
CherryStudio имеет более тонкую проблему. Десктопный клиент сохраняет thought signatures во время обычного потока диалога, но теряет их при использовании кнопки «Перегенерировать». Когда CherryStudio перегенерирует ответ, он восстанавливает историю диалога без исходной подписи от перегенерируемого хода, что вызывает ошибку 400. Обходной путь прост: избегайте использования «Перегенерировать» и вместо этого начните новый диалог или перефразируйте сообщение как новый ход. Эта проблема отслеживается в GitHub issue #11391.
n8n сталкивается с той же фундаментальной проблемой, что и Dify — его узел Gemini не сохраняет поле thought signature в состоянии диалога между выполнениями рабочего процесса. Для пользователей n8n рекомендуемый подход — использовать узел HTTP Request вместо специализированного узла Gemini, что даёт прямой контроль над API-нагрузкой. Вы можете сохранять полный ответ (включая подписи) в данных рабочего процесса n8n и вручную восстанавливать историю диалога в последующих ходах.
LangChain уже исправил эту проблему в версии 0.3.x и более поздних. Если вы используете более старую версию, обновление до последнего релиза автоматически решает обработку thought signature. Класс ChatGoogleGenerativeAI в LangChain теперь сохраняет все метаданные ответов, включая thought signatures, при построении истории диалога.
OpenClaw и другие сервисы API-шлюзов, предлагающие OpenAI-совместимые эндпоинты для моделей Gemini, имеют другую проблему: они могут не пересылать поле extra_content.google.thought_signature из ответа в режиме совместимости с OpenAI. Обходной путь — использовать нативный эндпоинт API Gemini через шлюз вместо OpenAI-совместимого эндпоинта, или настроить шлюз для сохранения всех полей ответа.
Для всех платформ универсальным запасным вариантом является обходной путь с фиктивной подписью, описанный в предыдущем разделе. Если платформа удаляет вашу реальную подпись, вы можете вставить "context_engineering_is_the_way_to_go" в качестве значения подписи в историю диалога, чтобы поддерживать работу, хотя и с упомянутыми выше оговорками по качеству.
Готовый к продакшену обработчик Thought Signature
Для продакшен-приложений, которым необходима надёжная обработка thought signature во всех сценариях — редактирование изображений, вызовы функций, стриминг и несколько режимов API — вот переиспользуемый класс-обработчик, инкапсулирующий все пограничные случаи, рассмотренные в этом руководстве.
pythonclass ThoughtSignatureHandler: """Manages thought signatures across multi-turn Gemini conversations.""" DUMMY_SIGNATURES = [ "context_engineering_is_the_way_to_go", "skip_thought_signature_validator" ] def __init__(self): self.signatures = {} # turn_index -> signature def extract_from_response(self, response, turn_index: int) -> str | None: """Extract thought signature from a Gemini API response.""" sig = None if hasattr(response, "candidates") and response.candidates: for part in response.candidates[0].content.parts: if hasattr(part, "thought_signature") and part.thought_signature: sig = part.thought_signature break if sig: self.signatures[turn_index] = sig return sig def extract_from_stream(self, stream, turn_index: int): """Extract signature from streaming response, yielding chunks.""" sig = None for chunk in stream: if hasattr(chunk, "candidates") and chunk.candidates: for part in chunk.candidates[0].content.parts: if hasattr(part, "thought_signature") and part.thought_signature: sig = part.thought_signature yield chunk if sig: self.signatures[turn_index] = sig def extract_from_openai_compat(self, message: dict, turn_index: int) -> str | None: """Extract signature from OpenAI-compatible response format.""" sig = (message.get("extra_content", {}) .get("google", {}) .get("thought_signature")) if sig: self.signatures[turn_index] = sig return sig def get_signature(self, turn_index: int, fallback_dummy: bool = False) -> str | None: """Get stored signature for a turn, with optional dummy fallback.""" sig = self.signatures.get(turn_index) if sig is None and fallback_dummy: return self.DUMMY_SIGNATURES[0] return sig def build_history_part(self, part_data: dict, turn_index: int) -> dict: """Ensure a model response part includes its thought signature.""" sig = self.signatures.get(turn_index) if sig and "thought_signature" not in part_data: part_data["thought_signature"] = sig return part_data
Этот обработчик покрывает три основных сценария извлечения (стандартный ответ, стриминг и совместимость с OpenAI), сохраняет подписи по индексу хода и предоставляет откат к фиктивным подписям, когда реальные недоступны. Метод extract_from_stream является генератором, который прозрачно возвращает чанки, захватывая при этом подпись из того чанка, который её содержит — вы можете встроить его в существующий код стриминга без изменения логики обработки.
Для приложений на TypeScript эквивалентный паттерн ещё проще, поскольку можно использовать интерфейс чата SDK, который обрабатывает всё автоматически. Если же необходимо использовать прямые REST-вызовы в TypeScript, применяйте ту же логику извлечения с использованием опциональной цепочки:
typescriptconst extractSignature = (response: any): string | undefined => { return response?.candidates?.[0]?.content?.parts ?.find((p: any) => p.thoughtSignature)?.thoughtSignature; };
При создании продакшен-систем рекомендуется также реализовать обработку ограничений скорости наряду с управлением подписями, поскольку NB2 имеет строгие ограничения скорости, которые в сочетании с ошибками подписей могут создавать запутанные режимы сбоев. Подробности смотрите в нашем полном руководстве по лимитам Nano Banana 2. Для команд, которым нужна более высокая пропускная способность или смягчённые ограничения скорости для генерации изображений NB2, сервисы вроде laozhang.ai предлагают альтернативный доступ к API по конкурентным ценам ($0,05 за изображение против стандартных ~$0,067 при 1K токенов).
FAQ — Частые вопросы о Thought Signature
Всегда ли Nano Banana 2 возвращает thought_signature в ответе?
Да. Каждый ответ от NB2 и других моделей Gemini 3 включает thought signature, даже когда мышление установлено в «выкл.» или thinkingBudget равен 0. Процесс мышления всегда запускается внутренне, и подпись всегда генерируется. Вы не можете отказаться от генерации подписи — вы можете только выбрать, передавать её обратно или нет (и передавать нужно всегда).
Что произойдёт, если я использую неправильную подпись или подпись из другого диалога?
API отклонит запрос с той же ошибкой 400 INVALID_ARGUMENT. Подписи криптографически привязаны к конкретному ходу диалога, который их сгенерировал. Нельзя менять подписи между диалогами или между ходами в рамках одного диалога. Подпись каждого хода должна использоваться ровно один раз, точно в той позиции, где она была сгенерирована.
Обрабатывает ли официальный Google Gen AI SDK thought signatures автоматически?
Да, когда вы используете интерфейс чата SDK (model.startChat() в TypeScript или model.start_chat() в Python). SDK внутренне управляет всей историей диалога, включая thought signatures. Если вы используете model.generate_content() напрямую с вручную составленной историей диалога, вы отвечаете за управление подписями самостоятельно.
Можно ли сохранять thought signatures в базе данных для дальнейшего использования?
Да, и вам следует это делать, если ваше приложение должно возобновлять диалоги между сессиями. Сохраняйте полный ответ модели, включая thought signature для каждого хода. При возобновлении восстанавливайте историю диалога со всеми сохранёнными подписями. Если у вас есть ходы, где подписи не были сохранены (устаревшие данные), используйте фиктивную подпись "context_engineering_is_the_way_to_go" в качестве заглушки.
Тарифицируется ли поле thought_signature? Учитывается ли оно в использовании токенов?
Токены мышления, генерирующие подпись, всегда тарифицируются независимо от настройки thinkingBudget (ai.google.dev, март 2026). Однако сама строка подписи — это компактное зашифрованное представление, которое не увеличивает значительно размер запроса при обратной передаче. Влияние на тарификацию заключается в начальных вычислениях мышления, а не в передаче подписи.
Почему ошибка говорит «invalid thought signature» вместо «missing thought signature»?
Сообщение об ошибке Unable to submit request because it has an invalid thought signature for content at index N охватывает оба случая: отсутствующие подписи (когда поле полностью отсутствует) и повреждённые подписи (когда поле существует, но содержит некорректные данные). Часть «at index N» указывает, какой ход в вашей истории диалога проблематичен — проверьте ответ модели по этому индексу, чтобы убедиться, что он включает оригинальную thought signature.