Почему ИИ обрывает ответ на полуслове — 3 причины и как починить

Знакомо: просишь ИИ длинный ответ, он бодро печатает — и вдруг обрывается на полуслове. Ни точки, ни конца. Первая мысль — «сломалось». Но почти всегда это не баг, а лимит: ответ упёрся в невидимую стену. Разберём три причины, от самой частой к редкой, и как каждую проверить и починить.

Причина 1. Упёрся в лимит длины ответа (самая частая)

У каждого запроса к модели есть потолок: сколько токенов (кусочков текста) она может выдать в ответ. Задаётся он параметром max_tokens. Дошёл ответ до потолка — обрыв на полуслове, даже если модель ещё не закончила мысль.

Как проверить. Обрыв случается примерно на одной и той же длине? Ответ всегда «недоговаривает» в одном месте? Если сервис возвращает причину завершения (finish_reason), при этой проблеме там будет length — «упёрся в лимит», а не stop — «сам закончил». Это железный признак.

Как починить. Подними max_tokens — дай модели больше места на ответ. Просишь развёрнутый разбор — ставь потолок с запасом. Если код за тебя писал ИИ, скорее всего он поставил маленькое значение по умолчанию — найди его и увеличь.

Причина 2. Переполнилось контекстное окно

У модели есть общий «стол» — контекстное окно. На нём должно уместиться всё сразу: твой запрос, вся история переписки и сам ответ. Места конечно. Если запрос уже занял почти весь стол, ответу просто некуда лечь — и он обрывается или вовсе не начинается.

Как проверить. Обрыв полез после того, как переписка стала длинной? Или ты суёшь в запрос огромный текст/документ? Чем больше влезло на входе, тем меньше осталось на выходе. Если раньше отвечало нормально, а «под конец разговора» стало рубить — это оно.

Как починить. Освободи стол. Не тащи в каждый запрос всю переписку — оставь только нужное. Длинный документ разбей на куски или сожми в краткое содержание. Приём, когда модель работает не со всем текстом, а только с нужным найденным куском, называется RAG — он как раз спасает от переполнения контекста.

Причина 3. Оборвался стриминг или сеть

Третье — уже не про лимиты, а про дорогу. Когда ответ печатается по словам, это стриминг: модель шлёт кусочки по сети. Если соединение моргнуло или сработал таймаут, поток обрывается на полуслове — при этом сама модель ответ, может, и дописала.

Как проверить. Обрыв случайный — то на этом месте, то на другом, каждый раз по-разному? Причины завершения length нет, длина каждый раз разная? Тогда дело не в лимите, а в связи. Сетевой обрыв капризен и непостоянен — этим он и отличается от упёршегося лимита.

Как починить. Обрабатывай обрыв потока как ошибку и повторяй запрос (retry). Подними таймаут, если ответы длинные и не успевают дойти. И не считай оборванный поток концом ответа — проверяй, что модель реально закончила, а не просто замолчала провод.

Быстрый разбор: с чего начать

Чтобы не гадать, иди по признакам:

• Обрыв на одной длине, причина length → это лимит max_tokens (причина 1). Подними лимит.
• Резать начало под конец долгой переписки или на огромном тексте → переполнен контекст (причина 2). Почисти стол.
• Обрыв случайный, в разных местах → сеть или стриминг (причина 3). Ставь retry.

Девять обрывов из десяти — это первая причина. Начни с неё.

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

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

Это можно вылечить промптом?

Частично. Попросить «уложись в 5 пунктов» помогает не упереться в лимит — короткий ответ просто не дорастает до потолка. Но если тебе нужен длинный ответ, промпт не поможет: лимит задаётся настройкой max_tokens, а не вежливой просьбой. Сначала подними потолок, а уже потом управляй длиной словами.