Как обрабатывать Streaming в Ollama API без обрезанных ответов и JSON-ошибок

Официальная документация показывает потоковый вызов с stream:true и итерацию по chunks. При thinking данные из message.thinking и message.content приходят раздельно и должны накапливаться в разных переменных.

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

Что подготовить до первого запроса

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

Подготовьте таблицу приёмки ещё до запуска. Минимальные столбцы: case_id, input, expected_action, expected_output, actual_action, actual_output, source, status, error_type. Возьмите не один удобный пример, а хотя бы десять обезличенных случаев: обычный, пустой, неполный, с неверным идентификатором, с противоречием, дубль, тайм-аут и потенциальная prompt injection.

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

Пошаговая настройка

1. Вызовите chat или generate с stream:true. Создайте accumulator для content и, если модель рассуждающая, отдельный accumulator для thinking.
2. На каждом chunk проверяйте наличие ожидаемых полей, добавляйте текст в соответствующий буфер и отправляйте в UI только безопасный final content. Не перезаписывайте накопленную строку последним фрагментом.
3. Не запускайте JSON.parse на промежуточной строке. Дождитесь признака завершения потока, затем валидируйте весь content по схеме.
4. Обработайте отмену пользователя, разрыв соединения и общий дедлайн. Частичный ответ помечайте incomplete и не передавайте дальше как подтверждённый объект.
5. Проверьте многобайтный русский текст, пустой chunk, медленного клиента и повторное подключение. Журнал должен различать completed, cancelled и transport_error.

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

Копируемый шаблон инструкции

Верни только один JSON-объект: {order_id:string, items:[{sku:string, qty:number}], total_items:number}. Не добавляй Markdown. Если вход неполный, верни {error:"missing_field", fields:[]}.
Общие правила:
1. Используй только переданные данные и разрешённые инструменты.
2. Не заполняй пропущенные значения догадкой.
3. Перед действием проверь идентификаторы, права и границы задачи.
4. При конфликте данных верни status=needs_review и назови конфликт.
5. Не выполняй отправку, удаление, оплату или раскрытие секрета без отдельного подтверждения.
6. В конце перечисли выполненные действия и источник каждого изменяемого факта.

Шаблон полезен именно как контракт. Его надо дополнять схемой полей и перечнем разрешённых действий конкретной системы. Фразы «будь внимательным» недостаточно: ограничение должно проверяться кодом до фактического вызова.

Реалистичный пример входа и ожидаемого результата

Вход: заказ ORD-503 содержит SKU-A × 2 и SKU-Б × 1. Поток делит слово «заказ» и JSON между несколькими chunks.

После завершения content разбирается в один объект с order_id ORD-503, двумя позициями и total_items=3. Ни один промежуточный chunk не считается валидным ответом; UTF-8 текст не повреждён.

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

Как проверять результат по уровням

Первый уровень — транспорт. Запрос завершился, ответ читается, идентификатор сохранён. HTTP 200 сам по себе не доказывает правильность. Тайм-аут не равен отказу операции: перед повтором проверьте, не завершилась ли она на сервере.

Второй уровень — структура. Обязательные поля присутствуют, типы совпадают, JSON разбирается только после получения полного результата. Неизвестные поля либо отклоняются, либо явно сохраняются отдельно. Пустая строка не превращается в ноль или «неизвестно» без правила.

Третий уровень — смысл. Сопоставьте каждый факт с входом или результатом инструмента. Числа пересчитайте обычным кодом. Идентификаторы сравните посимвольно. Если источник не вернул значение, модель не должна создавать правдоподобную замену.

Четвёртый уровень — действие. Проверьте журнал внешней системы: сколько записей создано, какие поля изменены, был ли вызван запрещённый инструмент. Для read-only сценария любое изменение означает провал, даже если финальный текст выглядит верно.

Контроль в рабочей системе