Прибыль:
- Возможность создать безопасную облачную архитектуру LLM, которая не хранит ключ API на клиенте, а проходит через внутренний прокси-сервер.
- Способность писать надежные интеграции, которые увеличивают воспринимаемую скорость потоковой передачи и аккуратно обрабатывают такие ситуации, как таймауты, сетевые ошибки и ограничения скорости.
- Возможность снизить стоимость за счет сокращения отправляемого токена и поставить под сомнение необходимость личных данных до того, как они попадут в облако.
Искусственный интеллект на устройстве — мощный, но ограниченный инструмент. Если вы хотите добавить в приложение по-настоящему «умного чат-помощника», обобщение длинных текстов или сложную творческую работу, вам нужны модели, которые слишком велики, чтобы поместиться на телефоне. Именно здесь в игру вступает облачный ИИ: ваше приложение подключается к большой языковой модели (LLM) через API (интерфейс прикладного программирования — стандартный интерфейс, в котором два программного обеспечения отправляют и получают данные друг другу). В этом модуле мы узнаем, как безопасно, быстро и экономично интегрировать облачный LLM в мобильное приложение. Критический акцент будет сделан на безопасность: неправильно установленная интеграция LLM может привести к утечке вашего ключа API и привести к выставлению счетов на тысячи фунтов.
Золотое правило архитектуры: держите ключ у клиента
Самая опасная ошибка, которую можно допустить при интеграции облачного AI, — это встроить API-ключ (секретный пароль, разрешающий использование сервиса) непосредственно в код мобильного приложения. Мобильные приложения загружаются на устройство пользователя, и код можно прочитать методом реверс-инжиниринга — анализа скомпилированного приложения и просмотра того, что у него внутри. Если ваш ключ находится внутри приложения, кто-то может извлечь его и сделать неограниченное количество запросов из вашей учетной записи.
Правильная архитектура такова: мобильное приложение отправляет запросы на ваш собственный backend-сервер (управляемый вами прокси-сервер); Ключ находится только на сервере; Сервер обращается к сервису LLM и возвращает ответ приложению. Это промежуточное программное обеспечение также обеспечивает ограничение скорости, предотвращение злоупотреблений и контроль затрат.
Подход
где ключ
Безопасность
Ключ находится в приложении (FALSE)
В клиенте, публично
Он протекает, купюра взрывается
Ключ находится в бэкэнде (ИСТИНА)
На сервере скрыто
Безопасный, контролируемый
Внимание: когда вы запрашиваете ИИ об интеграции облачного LLM, он может предоставить пример, который для вашего удобства записывает ключ непосредственно в код приложения. Никогда не принимайте это вживую. Обязательно включите в приглашение предложение «Ключ API не должен находиться на клиенте, используйте внутренний прокси».
Стриминг: увеличение воспринимаемой скорости
Ответы LLM могут быть длинными, и их полное представление может занять несколько секунд. Оставлять пользователя ждать на пустом экране — плохой опыт. Решение — потоковое — отображение ответа пословно по мере его формирования. Пользователь следит за написанием текста, как в ChatGPT; это значительно увеличивает воспринимаемую скорость и беглость речи. Поток на мобильных устройствах означает добавление фрагментов (токенов — фрагмента текста, созданного моделью) с сервера в интерфейс по мере их поступления. Явно запрашивайте поток при печати, интеграцию с AI.
Совет: добавьте кнопку «пауза» в ответ потоковой передачи. Пользователь должен иметь возможность остановить производство, когда получит желаемый ответ; Это одновременно улучшает качество обслуживания и снижает затраты за счет сокращения ненужной генерации токенов. В середине длинного ответа пользователь, возможно, уже нашел свой ответ.
Управление затратами, задержками и ошибками
Cloud LLM несет в себе денежные затраты (плату за токен) и временные затраты (задержку) для каждого запроса. Три дисциплины имеют важное значение. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Задержка: используйте потоковую передачу, установите тайм-аут, уведомите пользователя, если сеть работает медленно. Ошибка: сбой сети, сервис может вернуть 429 (слишком много запросов) или 500 (ошибка сервера); обращайтесь с каждым осторожно, не разрушайте приложение. Кроме того, LLM иногда дает бессмысленные или неверные (галлюцинации) ответы; Добавьте уровень проверки ответа в критических областях.
три мини-кейса
Случай 1 — Утечка ключа. Стартап встроил ключ OpenAI непосредственно в свое приложение React Native, чтобы быстро выйти из него. Через три недели после выпуска приложения ключ был реконструирован, и за одну ночь было использовано его на сумму 2400 долларов. Команде пришлось отозвать ключ и настроить серверный прокси. Урок: кратчайший путь, выбранный для удобства, стал самым дорогим маршрутом.
Случай 2 — Выпадение уменьшилось по мере увеличения потока. В образовательном приложении впервые реализована функция вопросов и ответов без потоковой передачи; пользователи выходили после 6 секунд простоя. Когда был добавлен поток, первое слово стало появляться через 0,8 секунды, а процент отказов снизился с 48% до 12%. Та же модель, та же скорость — просто разница в представлении.
Случай 3 — Контроль затрат. Одно приложение отправляло модели всю историю чата с каждым сообщением пользователя; В ходе долгих разговоров один запрос достиг 8000 токенов, что привело к завышению стоимости. Отправив только несколько последних сообщений и сводку, команда сократила количество токенов за запрос на 70 %, уменьшив ежемесячный счет на треть. Урок: измеряйте то, что отправляете.
Слабая подсказка / Сильная подсказка
Слабая подсказка: «Добавьте в мое приложение чат, например ChatGPT».
Мощная подсказка: «Добавьте чат-помощника в мое приложение iOS/Swift. Архитектура: приложение отправляет запрос на мой собственный бэкэнд, ключ LLM API НЕ находится на КЛИЕНТЕ, он проходит через прокси. - Ответ поступает в потоковом режиме, отображается слово за словом. - Кнопка «Стоп» прерывает производство. - Грамотная обработка тайм-аута, сетевых ошибок, ситуаций 429 и 500. - Сократите историю чата: отправьте последние 6 сообщений + сводку (контроль затрат). Объясните архитектуру. сначала диаграмму, затем дайте код клиента и прокси отдельно».
Копируемые шаблоны
Шаблон безопасной архитектуры: «Разработать облачную интеграцию LLM в мое приложение [платформы]. Правило: ключ API только в серверной части. Клиент -> мой прокси -> LLM. В прокси: аутентификация, ограничение скорости для каждого пользователя, регистрация запросов. Перечислите обязанности клиента и прокси отдельно, затем экспортируйте код».
Шаблон потоковой передачи: «Добавьте ответ потоковой передачи на этот экран чата: – Добавляйте фрагменты в всплывающее сообщение по мере их поступления – Покажите курсор/анимацию во время набора текста – Кнопка «Стоп» отменяет поток – Сохраняйте частичный текст и предупреждайте, если возникнет ошибка во время завершения потока [существующий код]»
Шаблон стоимости-задержки: «Снизить стоимость и задержку в этой интеграции LLM: — Как уменьшить количество отправленных токенов (аббревиатура истории, сводка)? — В каком случае достаточно меньшей/более дешевой модели? — Предложить стратегию тайм-аута и повторной попытки [код]»
Шаблон отказоустойчивости: «Сделайте этот вызов LLM устойчивым: — Отдельное поведение для отсутствия сети, таймаута, 429 (ограничение скорости), 500 (сервер) — Нетехническое, вежливое сообщение пользователю — Проверочное примечание против риска галлюцинаций в критических ответах [код]»
Распространенные ошибки
- Встраивание API-ключа в приложение. Самая дорогая и распространенная ошибка безопасности; Ключ определенно находится в задней части.
- Не использовать поток. Если оставить пользователя в ожидании длинных ответов, он отпугнет его.
- Отправка всей истории чата с каждым запросом. Это умножает стоимость токена и задержку.
- Обход ошибочных состояний. Если 429/500/timeout не адресован, приложение выйдет из строя или зависнет.
- Считаю ответ LLM правильным без вопросов. Галлюцинация реальна; Добавьте уровень проверки в критической области.
- Отправка пользовательских данных в ненужный LLM. Спросите, требуются ли персональные данные или их следует замаскировать перед отправкой в облако.
В итоге
Cloud LLM предоставляет на мобильные устройства большие возможности, которые не подходят для мобильных устройств, но требует безопасности и финансовой дисциплины. Золотое правило: ключ API никогда не находится на клиенте, он проходит через внутренний прокси. Поток значительно увеличивает воспринимаемую скорость и удержание; Поддерживается кнопкой «стоп». Стоимость определяется путем сокращения отправленного токена; Устойчивость достигается за счет корректной обработки всех случаев ошибок. Ответы LLM могут включать галлюцинации; В критически важных областях проверка имеет важное значение, и личные данные проверяются перед отправкой в облако.
Задача приложения
Запросите у ИИ проект клиентского + внутреннего прокси-сервера, используя «Шаблон безопасной архитектуры» для функции «обобщения текста» или «чата». Убедитесь, что ключ API находится только в серверной части созданного проекта. Затем извлеките как минимум два способа уменьшить токен, отправленный с помощью «Шаблона задержки стоимости», и напишите вежливое сообщение, которое будет отображаться пользователю в случае ошибки (например, 429).
контрольный список
- [ ] Я проверил, что ключ API находится на сервере, а не на клиенте.
- [ ] Я организовал потоковую передачу ответов и добавил кнопку «пауза»
- [ ] Я обработал тайм-аут, сетевую ошибку, ситуации 429 и 500.
- [ ] Я сократил отправленный токен с прежней аббревиатурой/сводкой
- [ ] Я рассмотрел проверку риска галлюцинаций в ответе LLM
- [ ] Я проверил необходимость/маскировку персональных данных перед переходом в облако