Zyski:
- Możliwość ustanowienia bezpiecznej architektury LLM w chmurze, która nie przechowuje klucza API na kliencie, ale przechodzi przez serwer proxy zaplecza
- Umiejętność pisania solidnych integracji, które zwiększają postrzeganą prędkość podczas przesyłania strumieniowego i delikatnego radzenia sobie z sytuacjami, takimi jak przekroczenia limitu czasu, błędy sieci i ograniczenia prędkości
- Możliwość obniżenia kosztów poprzez skrócenie wysyłanego tokena i zakwestionowanie konieczności danych osobowych zanim trafią one do chmury
Sztuczna inteligencja na urządzeniu jest potężna, ale ograniczona. Jeśli chcesz dodać do aplikacji naprawdę „inteligentnego asystenta czatu”, długie podsumowanie tekstu lub złożoną kreatywną produkcję, potrzebujesz modeli, które są zbyt duże, aby zmieścić się na telefonie. Tutaj wkracza do gry sztuczna inteligencja w chmurze: Twoja aplikacja łączy się z dużym modelem językowym (LLM) za pośrednictwem interfejsu API (interfejs programowania aplikacji – standardowy interfejs, w którym dwa programy wysyłają i odbierają między sobą dane). W tej jednostce dowiemy się, jak zintegrować chmurę LLM z aplikacją mobilną w sposób bezpieczny, szybki i oszczędny. Krytyczny nacisk zostanie położony na bezpieczeństwo: nieprawidłowo zainstalowana integracja LLM może spowodować wyciek klucza API i skutkować rachunkami wartymi tysiące funtów.
Złota zasada architektury: trzymaj klucz u klienta
Najbardziej niebezpiecznym błędem, jaki można popełnić przy integracji AI w chmurze, jest osadzenie klucza API (tajnego hasła uprawniającego do korzystania z usługi) bezpośrednio w kodzie aplikacji mobilnej. Aplikacje mobilne pobierane są na urządzenie użytkownika, a kod można odczytać metodą inżynierii wstecznej — analizując skompilowaną aplikację i sprawdzając, co się w niej znajduje. Jeśli Twój klucz znajduje się w aplikacji, ktoś może go wyodrębnić i wysyłać nieograniczone żądania z Twojego konta.
Prawidłowa architektura jest następująca: aplikacja mobilna wysyła żądania do Twojego własnego serwera backendowego (serwera proxy, który kontrolujesz); Klucz znajduje się tylko na serwerze; Serwer przechodzi do usługi LLM i zwraca odpowiedź do aplikacji. To oprogramowanie pośrednie zapewnia również ograniczenie prędkości, zapobieganie nadużyciom i kontrolę kosztów.
Podejście
gdzie jest klucz
Bezpieczeństwo
Klucz znajduje się w aplikacji (FAŁSZ)
W kliencie, publiczny
Wycieka, rachunek eksploduje
Klucz znajduje się w zapleczu (PRAWDA)
Na serwerze, ukryte
Bezpieczny, kontrolowany
Uwaga: gdy poprosisz sztuczną inteligencję o integrację z chmurą LLM, może ona dla Twojej wygody utworzyć przykład, który zapisze klucz bezpośrednio w kodzie aplikacji. Nigdy nie bierz tego na żywo. Pamiętaj, aby w monicie umieścić zdanie „Klucz API nie powinien znajdować się na kliencie, przejdź przez serwer proxy zaplecza”.
Przesyłanie strumieniowe: zwiększanie postrzeganej prędkości
Odpowiedzi LLM mogą być długie, a ich utworzenie w całości zajmuje kilka sekund. Pozostawienie użytkownika czekającego na pustym ekranie jest złym doświadczeniem. Rozwiązaniem jest przesyłanie strumieniowe — wyświetlanie odpowiedzi słowo po słowie w miarę jej generowania. Użytkownik monitoruje pisownię tekstu, tak jak w ChatGPT; dramatycznie zwiększa to postrzeganą szybkość i płynność. Przepływ na urządzeniach mobilnych oznacza dodawanie elementów (tokenów — fragmentów tekstu generowanych przez model) z serwera do interfejsu w miarę ich pojawiania się. Jawnie zażądaj przepływu podczas drukowania integracji z AI.
Wskazówka: dodaj przycisk „wstrzymaj” w odpowiedzi na przesyłanie strumieniowe. Użytkownik powinien mieć możliwość zatrzymania produkcji, gdy otrzyma odpowiedź, której potrzebuje; Poprawia to zarówno doświadczenie, jak i zmniejsza koszty, ograniczając niepotrzebne generowanie tokenów. W środku długiej odpowiedzi użytkownik mógł już znaleźć odpowiedź.
Zarządzanie kosztami, opóźnieniami i błędami
Cloud LLM wiąże się z kosztami pieniężnymi (opłata za token) i czasem (opóźnienie) przy każdym żądaniu. Niezbędne są trzy dyscypliny. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Opóźnienie: użyj przesyłania strumieniowego, ustaw limit czasu, powiadom użytkownika, jeśli sieć jest wolna. Błąd: awaria sieci, usługa może zwrócić 429 (zbyt wiele żądań) lub 500 (błąd serwera); obchodź się z każdym delikatnie, nie zawieszaj aplikacji. Ponadto LLM czasami daje bezsensowne lub nieprawidłowe (halucynacje) odpowiedzi; Dodaj warstwę weryfikacji odpowiedzi w krytycznych obszarach.
trzy mini etui
Przypadek 1 — Wyciek klucza. Startup umieścił klucz OpenAI bezpośrednio w swojej aplikacji React Native, aby szybko się z niej wydostać. Trzy tygodnie po wydaniu aplikacji klucz został poddany inżynierii wstecznej i w ciągu jednej nocy wykorzystano go o wartości 2400 USD. Zespół musiał unieważnić klucz i skonfigurować serwer proxy zaplecza. Lekcja: skrót wybrany dla wygody stał się najdroższą trasą.
Przypadek 2 — Zmniejszenie spadku wraz z przepływem. Aplikacja edukacyjna po raz pierwszy udostępniła funkcję pytań i odpowiedzi bez przesyłania strumieniowego; użytkownicy wychodzili po 6 sekundach bezczynnego oczekiwania. Po dodaniu przepływu pierwsze słowo zaczęło pojawiać się w ciągu 0,8 sekundy, a wskaźnik porzuceń spadł z 48% do 12%. Ten sam model, ta sama prędkość — tylko różnica w prezentacji.
Przypadek 3 – Kontrola kosztów. Jedna aplikacja wysyłała całą historię czatów do modelu z każdą wiadomością użytkownika; W długich rozmowach pojedyncze żądanie osiągnęło 8 000 tokenów, zawyżając koszt. Wysyłając tylko kilka ostatnich wiadomości i podsumowanie, zespół zmniejszył liczbę tokenów na żądanie o 70%, zmniejszając miesięczny rachunek o jedną trzecią. Lekcja: mierz to, co wysyłasz.
Słaba zachęta/silna zachęta
Słaby monit: „Dodaj czat taki jak ChatGPT do mojej aplikacji”.
Potężny monit: „Dodaj asystenta czatu do mojej aplikacji iOS/Swift. Architektura: aplikacja wysyła żądanie do mojego własnego backendu, klucz API LLM NIE znajduje się na KLIENCIE, przechodzi przez serwer proxy. – Odpowiedź przychodzi strumieniowo, wyświetlana słowo po słowie – Przycisk „Stop” przerywa produkcję – Z wdziękiem obsługuj przekroczenie limitu czasu, błąd sieci, sytuacje 429 i 500 – Skróć historię czatu: wyślij ostatnich 6 wiadomości + podsumowanie (kontrola kosztów) Wyjaśnij diagram architektoniczny najpierw, a następnie podaj oddzielnie kod klienta i proxy.”
Szablony do kopiowania
Szablon bezpiecznej architektury: „Zaprojektuj integrację Cloud LLM z moją [platformową] aplikacją. Reguła: klucz API tylko w zapleczu. Klient -> moje proxy -> LLM. W proxy: uwierzytelnianie, limit stawek na użytkownika, rejestrowanie żądań. Wypisz oddzielnie obowiązki klienta i serwera proxy, a następnie wyeksportuj kod.
Szablon transmisji strumieniowej: „Dodaj odpowiedź przesyłaną strumieniowo do tego ekranu czatu: – Dodawaj fragmenty do dymku wiadomości, gdy tylko się pojawią – Wyświetlaj kursor/animację podczas pisania – Przycisk „Zatrzymaj” anuluje transmisję – Zachowaj częściowy tekst i ostrzegaj, jeśli wystąpi błąd podczas kończenia transmisji [istniejący kod]”
Szablon opóźnienia kosztów: „Zmniejsz koszty i opóźnienia w tej integracji LLM: – Jak zmniejszyć liczbę wysyłanych tokenów (skrót historii, podsumowanie)? – W którym przypadku wystarczy mniejszy/tańszy model? – Zaproponuj strategię przekroczenia limitu czasu i ponownej próby [kod]”
Szablon tolerancji błędów: „Uczyń to wywołanie LLM odpornym: – Oddzielne zachowanie w przypadku braku sieci, przekroczenia limitu czasu, 429 (limit szybkości), 500 (serwer) – Nietechniczna, uprzejma wiadomość dla użytkownika – Notatka weryfikacyjna pod kątem ryzyka halucynacji w krytycznych odpowiedziach [kod]”
Typowe błędy
- Osadzanie klucza API w aplikacji. Najdroższy i najczęstszy błąd bezpieczeństwa; Klucz zdecydowanie leży z tyłu.
- Nie używam przepływu. Pozostawienie użytkownika czekającego na długie odpowiedzi odstraszy go.
- Wysyłanie całej historii czatów przy każdym żądaniu. Mnoży koszt tokena i opóźnienia.
- Omijanie warunków błędu. Jeśli 429/500/limit czasu nie zostanie rozwiązany, aplikacja ulegnie awarii lub zawiesi się.
- Uznanie odpowiedzi LLM za poprawną bez wątpienia. Halucynacja jest prawdziwa; Dodaj warstwę weryfikacyjną w obszarze krytycznym.
- Wysyłanie danych użytkownika do niepotrzebnego LLM. Zapytaj, czy dane osobowe są wymagane, czy też powinny być maskowane, zanim trafią do chmury.
Podsumowując
Cloud LLM oferuje wspaniałe możliwości, które nie mieszczą się na urządzeniu mobilnym, ale wymagają bezpieczeństwa i dyscypliny kosztowej. Złota zasada: klucz API nigdy nie znajduje się na kliencie, przechodzi przez serwer proxy zaplecza. Przepływ znacznie zwiększa postrzeganą prędkość i retencję; Obsługiwane przez przycisk „stop”. Koszt ustalany jest poprzez skrócenie przesłanego tokena; Odporność osiąga się poprzez umiejętne radzenie sobie ze wszystkimi przypadkami błędów. Odpowiedzi LLM mogą obejmować halucynacje; W krytycznych obszarach weryfikacja jest niezbędna, a dane osobowe są przeglądane przed wysłaniem ich do chmury.
Zadanie aplikacji
Poproś AI o projekt klienta + serwera proxy zaplecza, korzystając z „szablonu bezpiecznej architektury” dla funkcji „podsumowania tekstu” lub „czatu”. Sprawdź, czy klucz API znajduje się wyłącznie w zapleczu wygenerowanego projektu. Następnie wyodrębnij co najmniej dwa sposoby zmniejszenia tokenu wysyłanego za pomocą „wzorca opóźnienia kosztu” i napisz komunikat grzeczny, który będzie wyświetlany użytkownikowi w przypadku warunku błędu (np. 429).
lista kontrolna
- [ ] Sprawdziłem, że klucz API znajduje się w zapleczu, a nie na kliencie
- [ ] Przesłałem odpowiedź strumieniowo i dodałem przycisk „pauza”.
- [ ] Poradziłem sobie z przekroczeniem limitu czasu, błędem sieci, sytuacjami 429 i 500
- [ ] Zmniejszyłem przesłany token do poprzedniego skrótu/podsumowania
- [ ] Rozważałem w odpowiedzi LLM sprawdzenie pod kątem ryzyka halucynacji
- [ ] Przed przejściem do chmury sprawdziłem konieczność/maskowanie danych osobowych