Ситуация
В мобильном Jarvis у меня есть очень простая проверка качества: я нажимаю кнопку и смотрю, сколько времени проходит до момента, когда результат действительно появляется на телефоне.
В одном из сценариев всё выглядело почти комично. Jarvis уже создал десять изображений для карусели, сервер честно закончил работу, а телефон ещё больше минуты показывал ожидание. Иногда в конце он вообще сообщал, что функция недоступна.
То есть результат есть, но для меня как для пользователя его как будто нет.
Сначала я, конечно, посмотрел не туда. Подумал про генерацию, скорость сети, таймауты и сам телефон. На самом деле проблема была гораздо прозаичнее: я заставил мобильное приложение тащить все изображения внутри одного JSON-ответа.
Что происходило внутри
Сервер брал десять готовых PNG-файлов, превращал их в длинные текстовые строки и складывал внутрь JSON. Ответ раздувался примерно до 17,5 МБ. Телефон должен был дождаться всего файла, разобрать его, снова превратить строки в изображения и только после этого что-то показать.
Технически схема была рабочая. В этом и была ловушка. На хорошем соединении большой ответ всё-таки доходил, поэтому тест говорил: «всё нормально». А реальный сценарий говорил обратное.
Если сеть обрывалась в самом конце, терялся весь результат. Если срабатывал таймаут, уже созданные картинки выглядели как ошибка генерации. Если я повторял запрос, система могла снова запускать дорогую работу, хотя файлы давно лежали на сервере.
Почему я не стал просто увеличивать таймаут
Самое очевидное решение — дать телефону ещё минуту. Оно же самое бесполезное.
Я мог увеличить таймаут, сильнее сжать изображения или попросить пользователя просто подождать. Но тогда я бы не исправил продукт. Я бы лишь сделал неправильную схему чуть терпеливее.
И вот тут стал виден главный вопрос: зачем вообще класть картинки внутрь служебного ответа, если сервер уже умеет отдавать их как обычные файлы?
Что я изменил
Я разделил команду и тяжёлый результат.
Теперь основной ответ короткий. Он сообщает, что создано, сколько файлов готово и по каким проверяемым ссылкам их можно получить. Сами изображения телефон загружает отдельно — обычным способом и по мере необходимости.
Для пользователя это выглядит естественно: интерфейс быстро получает структуру результата, начинает показывать готовые файлы и не держит один огромный запрос до последнего байта. Сохранение в галерею осталось отдельным действием — я сам решаю, что действительно хочу оставить на устройстве.
Отдельным тестом я запретил возврат к старому inline-режиму. Это важно: такие решения любят незаметно возвращаться, потому что на локальной машине «и так работает».
Что изменилось
Функция снова стала похожа на мобильную функцию, а не на проверку терпения.
Если генерация не закончилась — это одна понятная ошибка. Если не загрузился отдельный файл — другая. Один сбой больше не обесценивает девять изображений, которые уже готовы.
Для меня здесь важнее даже не выигранные секунды. Исчезло ощущение случайности: сегодня функция открылась, завтра зависла, послезавтра попросила начать всё сначала. Я наконец могу отдельно видеть, где закончилась работа AI и где началась обычная доставка файлов.
Ограничения
Ссылки тоже требуют дисциплины. Нужно контролировать срок их жизни, доступ и связь с конкретной версией результата. Нельзя допустить, чтобы одна и та же ссылка завтра незаметно показывала другой файл.
Короткий ответ также не означает, что все изображения появляются мгновенно. Зато теперь интерфейс может честно показывать прогресс и повторять загрузку одного файла, не запуская всю работу заново.
И, конечно, не любой файл нужно выносить отдельно. Маленькие данные вполне могут жить внутри ответа. Для меня граница проходит там, где удобство API начинает ухудшать реальный пользовательский сценарий.
Итог
Иногда AI уже всё сделал, а продукт всё ещё заставляет человека ждать. Проблема не в модели, не в телефоне и не в мощности сервера. Просто результат едет не тем транспортом.
В моём случае решение оказалось довольно земным: сервер создаёт файлы, короткий манифест связывает их с конкретным результатом, телефон показывает, а я решаю, что сохранить.
Jarvis не стал умнее. Он просто перестал таскать десять картинок внутри одного JSON. И именно после этого функция наконец начала ощущаться рабочей.