Единици
1. Вовед во вештачката интелигенција во развојот на мобилните телефони: улоги, граници, автентикација и безбедност 2. Генерирање на мобилни кодови со вештачка интелигенција: Котлин, Свифт и развој на повеќе платформи 3. Дизајн на интерфејс и генерирање на код за интерфејс со вештачка интелигенција 4. ВИ на уредот: Core ML, TensorFlow Lite и ML Kit 5. Интеграција на Cloud AI и LLM API: разговор, проток и безбедност 6. Тест генерирање со вештачка интелигенција: Тестови за единица, интерфејс и автоматизација 7. Дебагирање и анализа на падови со вештачка интелигенција 8. Перформанси и оптимизација на батеријата: Брзи и ефикасни апликации со вештачка интелигенција 9. Приватност, дозволи и безбедно користење 10. Издание во продавницата: App Store, Google Play и AI компатибилност 11. Проект од крај до крај, одговорна употреба на вештачка интелигенција и патоказ во професијата
Единица 5 / 11

Интеграција на Cloud AI и LLM API: разговор, проток и безбедност

Добивки:

  • Способност да се воспостави безбедна архитектура на облак LLM која не го задржува клучот API на клиентот, туку поминува низ заден прокси
  • Способност за пишување робусни интеграции што ја зголемуваат воочената брзина со стриминг и нежно се справуваат со ситуации како што се временските прекини, мрежни грешки и ограничувања на брзината
  • Способност да се намалат трошоците со скратување на испратениот токен и да се преиспита потребата од лични податоци пред да отидат во облакот

Вештачката интелигенција на уредот е моќна, но ограничена. Кога сакате да додадете вистински „паметен асистент за разговор“, резимирање на долг текст или сложено креативно производство во апликацијата, ви требаат модели кои се преголеми за да се вклопат на телефон. Овде влегува во игра облак AI: вашата апликација се поврзува со голем јазичен модел (LLM) преку API (Application Programming Interface - стандарден интерфејс каде што два софтвери испраќаат и примаат податоци еден до друг). Во оваа единица ќе научиме како да го интегрираме cloud LLM во мобилна апликација на безбеден, брз и свесен начин за трошоците. Критичкиот акцент ќе биде ставен на безбедноста: неправилно инсталираната интеграција на LLM може да го протече вашиот API клуч и да резултира со сметки во вредност од илјадници фунти.

Златното правило на архитектурата: чувајте го клучот на клиентот

Најопасната грешка што може да се направи во интеграцијата со вештачка интелигенција во облакот е да се вметне клучот API (тајната лозинка што го овластува користењето на услугата) директно во кодот на мобилната апликација. Мобилните апликации се преземаат на уредот на корисникот и кодот може да се прочита со обратно инженерство - парсирање на компајлираната апликација и гледање што има внатре. Ако вашиот клуч е во апликацијата, некој може да го извлече и да прави неограничени барања од вашата сметка.

Правилната архитектура е оваа: мобилната апликација испраќа барања до вашиот сопствен заднински сервер (прокси-серверот што го контролирате); Клучот се наоѓа само на серверот; Серверот оди на услугата LLM и го враќа одговорот на апликацијата. Овој среден софтвер, исто така, обезбедува ограничување на брзината, спречување на злоупотреба и контрола на трошоците.

Пристап

каде е клучот

Безбедност

Клучот е во апликацијата (FALSE)

Во клиент, јавно

Протекува, сметката експлодира

Клучот е во задниот дел (ВИСТИНСКИ)

На серверот, скриен

Безбедно, контролирано

Внимание: кога барате од вештачката интелигенција за интеграција на cloud LLM, таа може да произведе пример што ќе го запише клучот директно во кодот на апликацијата за ваша погодност. Никогаш не го земајте ова во живо. Не заборавајте да ја вклучите реченицата „Клучот API не треба да биде на клиентот, поминете низ проксито за заднина“ во промптот.

Стриминг: зголемување на воочената брзина

Одговорите на LLM може да бидат долги и да бидат потребни неколку секунди за да се произведат во целост. Оставањето на корисникот да чека на празен екран е лошо искуство. Решението е стриминг - прикажување на одговорот збор по збор, како што се генерира. Корисникот го следи правописот на текстот, како во ChatGPT; ова драматично ја зголемува воочената брзина и флуентност. Проток на мобилен значи додавање парчиња (токени - дел од текстот произведен од моделот) од серверот до интерфејсот додека тие пристигнуваат. Експлицитно побарајте проток при печатење на интеграција со вештачка интелигенција.

Совет: додајте копче „пауза“ во одговорот на стриминг. Корисникот треба да може да го запре производството кога ќе го добие одговорот што го сака; Ова го подобрува искуството и ги намалува трошоците со намалување на непотребното генерирање на токени. Во средината на долгиот одговор, корисникот можеби веќе го нашол својот одговор.

Управување со трошоци, доцнење и грешки

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 за да излезе брзо. Три недели по објавувањето на апликацијата, клучот беше обратно конструиран и преку ноќ беше направена употреба во вредност од 2.400 долари. Тимот мораше да го отповика клучот и да постави заднински прокси. Лекција: кратенката преземена за погодност стана најскапата рута.

Случај 2 - Опаѓањето се намалува со протокот. Апликација за образование прво ја објави својата функција за прашања и одговори без пренос; корисниците излегуваа по 6 секунди чекање во мирување. Кога беше додаден проток, првиот збор почна да се појавува за 0,8 секунди, а стапката на напуштање падна од 48% на 12%. Истиот модел, иста брзина - само разлика во презентацијата.

Случај 3 - Контрола на трошоците. Една апликација ја испраќаше целата историја на разговор до моделот со секоја корисничка порака; Во долгите разговори, едно барање достигна 8.000 токени, што ги надува трошоците. Со испраќање само на последните неколку пораки и резиме, тимот ги намали токените по барање за 70%, намалувајќи ја месечната сметка на една третина. Лекција: измерете што испраќате.

Слаб промпт / Силен промпт

Слаб потсетник: „Додај разговор како ChatGPT во мојата апликација“.

Моќен потсетник: „Додај асистент за разговор на мојата апликација за iOS/Swift. Архитектура: апликацијата испраќа барање до мојот сопствен заднина, клучот LLM API НЕ е на КЛИЕНТ, тој оди преку прокси. - Одговорот доаѓа преку стриминг, се прикажува збор по збор - Копчето „Стоп“ го прекинува производството - Ракувајте со 5, тајно време40 и мрежно исклучување. Скратете ја историјата на разговорот: испратете ги последните 6 пораки + резиме (контрола на трошоците) Прво објаснете го архитектонскиот дијаграм, а потоа одделно дајте му го кодот на клиентот и прокси.

Шаблони за копирање

Шаблон за безбедна архитектура: „Дизајнирајте ја интеграцијата на облакот LLM во мојата [платформа] апликација. Правило: клуч за API само во задниот дел. Клиент -> мојот прокси -> LLM. Во прокси: автентикација, ограничување на стапката по корисник, евиденција на барања. Наведете ги одделно одговорностите на клиентот и проксито, а потоа извезете го кодот."

Шаблон за стриминг: „Додајте одговор од стриминг на овој екран за разговор:- Додајте фрагменти на балонот со пораки кога пристигнуваат- Прикажи курсор/анимација додека пишувате- копчето „Стоп“ нека го откаже преносот- Зачувај делумен текст и предупреди ако има грешка додека преносот завршува [постоечки код]“

Шаблон за цена-латентност: „Намалете ги трошоците и доцнењето во оваа интеграција на LLM:- како да го намалам испратениот токен (кратенка од историјата, резиме)?- Во кој случај е доволен помал/поевтин модел?- Предложете истек на време и повторно обидете се стратегија[код]“

Шаблон за толеранција на грешки: „Направете го овој повик LLM еластичен:- Одделно однесување без мрежа, истек на време, 429 (ограничување на стапката), 500 (сервер) - Нетехничка, љубезна порака до корисникот- Забелешка за верификација против ризик од халуцинации во критичните одговори[шифра]“

Вообичаени грешки

  • Вградување на клучот API во апликацијата. Најскапата и најчеста безбедносна грешка; Клучот дефинитивно лежи на задниот дел.
  • Не користење на проток. Оставањето на корисникот да чека долги одговори ќе го избрка корисникот.
  • Испраќање на целата историја на разговор со секое барање. Ги множи токенните трошоци и латентноста.
  • Заобиколувајќи ги условите за грешка. Ако 429/500/timeout не се адресира, апликацијата ќе падне или ќе замрзне.
  • Сметајќи го одговорот на LLM како точен без прашање. Халуцинацијата е реална; Додајте слој за верификација во критична област.
  • Испраќање на кориснички податоци до непотребни LLM. Прашајте дали личните податоци се потребни или треба да бидат маскирани пред да одат во облакот.

Сумирано

Cloud LLM носи одлични способности кои не се вклопуваат во уредот на мобилниот, но бара безбедност и дисциплина на трошоците. Златно правило: клучот API никогаш не е на клиентот, тој оди преку заднинскиот прокси. Протокот значително ја зголемува воочената брзина и задржување; Поддржано со копчето „стоп“. Трошокот се одредува со скратување на испратениот токен; Отпорноста се постигнува со благодатно ракување со сите случаи на грешки. Одговорите на LLM може да вклучуваат халуцинации; Во критичните области, проверката е од суштинско значење и личните податоци се прегледуваат пред да се испратат во облакот.

Задача за апликација

Побарајте дизајн на клиент + прокси-заднина од вештачката интелигенција користејќи го „шаблонот за безбедна архитектура“ за функција „сумирање на текст“ или „разговор“. Потврдете дека клучот API се наоѓа само во задниот дел во генерираниот дизајн. Потоа извлечете најмалку два начина да го намалите токенот испратен со „Одложена шема на трошоци“ и напишете ја учтивата порака што ќе му се прикаже на корисникот за состојба на грешка (на пр. 429).

листа за проверка

  • [ ] Потврдив дека клучот API се наоѓа во задниот дел, а не на клиентот
  • [ ] Го направив преносот на одговорот и додадов копче „пауза“.
  • [ ] Се справив со истек на време, мрежна грешка, 429 и 500 ситуации
  • [ ] Го намалив доставениот токен со минатата кратенка/резиме
  • [ ] Размислував за валидација против ризикот од халуцинации во одговорот на LLM
  • [ ] Ја проверив неопходноста/маскирањето на личните податоци пред да отидам на облакот