Печалби:
- Възможност за установяване на сигурна облачна LLM архитектура, която не запазва API ключа на клиента, а преминава през back-end прокси
- Възможност за писане на стабилни интеграции, които увеличават възприеманата скорост с поточно предаване и внимателно се справят със ситуации като изчакване, мрежови грешки и ограничения на скоростта
- Възможност за намаляване на разходите чрез съкращаване на изпратения токен и поставяне под въпрос на необходимостта от лични данни, преди да отиде в облака
AI на устройството е мощен, но ограничен. Когато искате да добавите наистина „интелигентен асистент за чат“, обобщаване на дълъг текст или сложна творческа продукция към приложение, имате нужда от модели, които са твърде големи, за да се поберат на телефон. Това е мястото, където AI влиза в действие: вашето приложение се свързва с голям езиков модел (LLM) чрез API (интерфейс за програмиране на приложения – стандартният интерфейс, при който два софтуера изпращат и получават данни един към друг). В този модул ще научим как да интегрираме облачен LLM в мобилно приложение по безопасен, бърз и съобразен с разходите начин. Критичният акцент ще бъде върху сигурността: неправилно инсталирана LLM интеграция може да изтече вашия API ключ и да доведе до сметки на стойност хиляди лири.
Златното правило на архитектурата: дръжте ключа на клиента
Най-опасната грешка, която може да бъде направена при облачната AI интеграция, е вграждането на API ключа (тайната парола, която разрешава използването на услугата) директно в кода на мобилното приложение. Мобилните приложения се изтеглят на устройството на потребителя и кодът може да бъде прочетен чрез обратно инженерство - анализиране на компилираното приложение и виждане какво има вътре в него. Ако вашият ключ е в приложението, някой може да го извлече и да прави неограничени заявки от вашия акаунт.
Правилната архитектура е следната: мобилното приложение изпраща заявки до вашия собствен бекенд сървър (прокси сървърът, който контролирате); Ключът се намира само на сървъра; Сървърът отива до услугата LLM и връща отговора на приложението. Този междинен софтуер също така осигурява ограничаване на скоростта, предотвратяване на злоупотреби и контрол на разходите.
подход
къде е ключът
сигурност
Ключът е в приложението (FALSE)
В клиента, публично
Изтича, банкнотата гръмва
Ключът е в бекенда (ВЯРНО)
На сървъра, скрит
Безопасен, контролируем
Внимание: Когато поискате от AI облачна интеграция на LLM, той може да създаде пример, който записва ключа директно в кода на приложението за ваше удобство. Никога не приемайте това на живо. Не забравяйте да включите изречението „Ключът за API не трябва да е на клиента, преминете през задния прокси“ в подканата.
Поточно предаване: увеличаване на възприеманата скорост
Отговорите на LLM могат да бъдат дълги и да отнемат секунди, за да бъдат произведени в тяхната цялост. Оставянето на потребителя да чака на празен екран е лошо изживяване. Решението е стрийминг - показване на отговора дума по дума, докато се генерира. Потребителят следи правописа на текста, както в ChatGPT; това драматично увеличава възприеманата скорост и плавност. Flow on mobile означава добавяне на парчета (жетони — част от текста, произведен от модела) от сървъра към интерфейса, когато пристигнат. Изрично изискване на потока при отпечатване на интеграция към 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/изчакване не е адресирано, приложението ще се срине или ще замръзне.
- Като се има предвид отговорът на LLM като правилен без въпрос. Халюцинацията е истинска; Добавете слой за проверка в критична зона.
- Изпращане на потребителски данни до ненужен LLM. Попитайте дали личните данни са необходими или трябва да бъдат маскирани, преди да отидат в облака.
В обобщение
Cloud LLM предлага страхотни възможности, които не се побират на устройството в мобилното устройство, но изисква сигурност и дисциплина на разходите. Златно правило: API ключът никога не е на клиента, той минава през бекенд проксито. Потокът значително увеличава възприеманата скорост и задържане; Поддържа се от бутон "стоп". Цената се определя чрез съкращаване на изпратения токен; Устойчивостта се постига чрез грациозно обработване на всички случаи на грешка. Отговорите на LLM могат да включват халюцинации; В критични области проверката е от съществено значение и личните данни се преглеждат, преди да бъдат изпратени в облака.
Задача за приложение
Поискайте дизайн на клиент + бекенд прокси от AI, като използвате „шаблон за защитена архитектура“ за функция „резюмиране на текст“ или „чат“. Уверете се, че API ключът се намира само в бекенда в генерирания дизайн. След това извлечете най-малко два начина за намаляване на токена, изпратен с „Модел на забавяне на разходите“ и напишете учтивото съобщение, което да се показва на потребителя при състояние на грешка (напр. 429).
контролен списък
- [ ] Проверих, че API ключът се намира в бекенда, а не на клиента
- [ ] Направих отговора поточно и добавих бутон „пауза“.
- [ ] Обработих изчакване, мрежова грешка, 429 и 500 ситуации
- [ ] Намалих изпратения токен с миналото съкращение/резюме
- [ ] Обмислих валидиране срещу риска от халюцинации в отговора на LLM
- [ ] Проверих необходимостта/маскирането на лични данни, преди да отида в облака