Unidade 5 / 11

Integração Cloud AI e LLM API: Chat, Flow e Segurança

Ganhos:

  • Capacidade de estabelecer uma arquitetura LLM em nuvem segura que não mantém a chave de API no cliente, mas passa por um proxy back-end
  • Capacidade de escrever integrações robustas que aumentam a velocidade percebida com streaming e lidar suavemente com situações como tempos limite, erros de rede e limites de velocidade
  • Capacidade de reduzir custos encurtando o token enviado e questionar a necessidade de dados pessoais antes de irem para a nuvem

A IA no dispositivo é poderosa, mas limitada. Quando você deseja adicionar um verdadeiro “assistente de bate-papo inteligente”, resumo de texto longo ou produção criativa complexa a um aplicativo, você precisa de modelos grandes demais para caber em um telefone. É aqui que a IA na nuvem entra em ação: seu aplicativo se conecta a um modelo de linguagem grande (LLM) por meio de uma API (Application Programming Interface – a interface padrão onde dois softwares enviam e recebem dados um para o outro). Nesta unidade aprenderemos como integrar o Cloud LLM em um aplicativo móvel de maneira segura, rápida e econômica. A ênfase crítica estará na segurança: uma integração LLM instalada incorretamente pode vazar sua chave de API e resultar em contas no valor de milhares de libras.

A regra de ouro da arquitetura: manter a chave no cliente

O erro mais perigoso que pode ser cometido na integração de IA na nuvem é incorporar a chave API (a senha secreta que autoriza o uso do serviço) diretamente no código do aplicativo móvel. Os aplicativos móveis são baixados para o dispositivo do usuário e o código pode ser lido por engenharia reversa – analisando o aplicativo compilado e vendo o que há dentro dele. Se sua chave estiver dentro do aplicativo, alguém poderá extraí-la e fazer solicitações ilimitadas de sua conta.

A arquitetura correta é esta: o aplicativo móvel envia solicitações para seu próprio servidor backend (o servidor proxy que você controla); A chave reside apenas no servidor; O servidor vai para o serviço LLM e retorna a resposta ao aplicativo. Esse middleware também fornece limite de velocidade, prevenção de abusos e controle de custos.

Abordagem

onde está a chave

Segurança

A chave está no aplicativo (FALSO)

No cliente, público

Vaza, a conta explode

A chave está no back-end (TRUE)

No servidor, oculto

Seguro, controlável

Cuidado: quando você solicita à IA integração LLM na nuvem, ela pode produzir um exemplo que grava a chave diretamente no código do aplicativo para sua conveniência. Nunca leve isso ao vivo. Certifique-se de incluir a frase "A chave de API não deve estar no cliente, passe pelo proxy backend" no prompt.

Streaming: aumentando a velocidade percebida

As respostas do LLM podem ser longas e levar segundos para serem produzidas na íntegra. Deixar o usuário esperando em uma tela em branco é uma experiência ruim. A solução é o streaming – exibindo a resposta palavra por palavra, à medida que ela é gerada. O usuário monitora a ortografia do texto, como no ChatGPT; isso aumenta drasticamente a velocidade e a fluência percebidas. Fluxo no celular significa adicionar pedaços (tokens – o pedaço de texto produzido pelo modelo) do servidor à interface à medida que chegam. Solicite explicitamente o fluxo ao imprimir a integração com IA.

Dica: adicione um botão “pause” na resposta do streaming. O usuário deve ser capaz de interromper a produção quando obtiver a resposta desejada; Isso melhora a experiência e reduz custos, reduzindo a geração desnecessária de tokens. No meio da longa resposta, o usuário pode já ter encontrado a resposta.

Gerenciamento de custos, atrasos e erros

O Cloud LLM acarreta custo monetário (taxa por token) e custo de tempo (latência) com cada solicitação. Três disciplinas são essenciais. Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible. Latência: use streaming, defina o tempo limite, notifique o usuário se a rede estiver lenta. Erro: interrupção da rede, serviço pode retornar 429 (muitas solicitações) ou 500 (erro do servidor); manuseie cada um com cuidado, não trave o aplicativo. Além disso, o LLM às vezes dá respostas sem sentido ou incorretas (alucinações); Adicione uma camada de verificação da resposta em áreas críticas.

três mini cases

Caso 1 – Chave vazada. Uma startup incorporou a chave OpenAI diretamente em seu aplicativo React Native para sair rapidamente. Três semanas após o lançamento do aplicativo, a chave passou por engenharia reversa e US$ 2.400 em uso foram feitos durante a noite. A equipe teve que revogar a chave e configurar um proxy de back-end. Lição: o atalho tomado por conveniência tornou-se o caminho mais caro.

Caso 2 — O dropout diminuiu com o fluxo. Um aplicativo educacional lançou pela primeira vez seu recurso de perguntas e respostas sem streaming; os usuários estavam saindo após 6 segundos de espera ociosa. Quando o fluxo foi adicionado, a primeira palavra começou a aparecer em 0,8 segundos e a taxa de abandono caiu de 48% para 12%. Mesmo modelo, mesma velocidade – apenas uma diferença na apresentação.

Caso 3 — Controle de custos. Um aplicativo estava enviando todo o histórico de bate-papo para a modelo com cada mensagem do usuário; Em longas conversas, uma única solicitação chegava a 8 mil tokens, inflacionando o custo. Ao enviar apenas as últimas mensagens e um resumo, a equipe reduziu os tokens por solicitação em 70%, reduzindo a fatura mensal para um terço. Lição: meça o que você envia.

Alerta fraco / Alerta forte

Prompt fraco: "Adicionar um bate-papo como o ChatGPT ao meu aplicativo."

Prompt poderoso: "Adicionar um assistente de bate-papo ao meu aplicativo iOS/Swift. Arquitetura: o aplicativo envia uma solicitação para meu próprio backend, a chave da API LLM NÃO está no CLIENTE, ela passa pelo proxy. - A resposta vem em streaming, exibida palavra por palavra - O botão 'Parar' interrompe a produção - Lidar com tempo limite, erro de rede, situações 429 e 500 normalmente - Encurtar o histórico de bate-papo: enviar as últimas 6 mensagens + resumo (controle de custos)Explicar o diagrama arquitetônico primeiro e depois forneça o código do cliente e do proxy separadamente."

Modelos copiáveis

Modelo de arquitetura segura: "Projete a integração do LLM na nuvem em meu aplicativo [plataforma]. Regra: chave de API apenas no back-end. Cliente -> meu proxy -> LLM. No proxy: autenticação, limite de taxa por usuário, registro de solicitação. Liste as responsabilidades do cliente e do proxy separadamente e, em seguida, exporte o código."

Modelo de streaming: "Adicione uma resposta de streaming a esta tela de bate-papo: - Adicione trechos ao balão de mensagem conforme eles chegam - Mostre um cursor/animação enquanto digita - Faça com que o botão 'Parar' cancele o stream - Preservar texto parcial e avisar se houver um erro enquanto o stream está terminando [código existente]"

Modelo de latência de custo:"Reduza o custo e a latência nesta integração LLM:- Como faço para reduzir o token enviado (abreviação do histórico, resumo)?- Nesse caso, um modelo menor/mais barato é suficiente?- Sugerir tempo limite e estratégia de nova tentativa[código]"

Modelo de tolerância a falhas: "Torne esta chamada LLM resiliente: - Comportamento separado para nenhuma rede, tempo limite, 429 (limite de taxa), 500 (servidor) - Mensagem educada e não técnica para o usuário - Nota de verificação contra risco de alucinação em respostas críticas [código]"

Erros comuns

  • Incorporando a chave API no aplicativo. O bug de segurança mais caro e comum; A chave definitivamente está no back-end.
  • Não usando fluxo. Deixar o usuário esperando por respostas longas irá afastá-lo.
  • Envio de todo o histórico do chat a cada solicitação. Ele multiplica o custo e a latência do token.
  • Ignorando condições de erro. Se 429/500/timeout não for resolvido, o aplicativo irá travar ou congelar.
  • Considerando a resposta do LLM como correta, sem questionamentos. A alucinação é real; Adicione camada de verificação na área crítica.
  • Envio de dados do usuário para LLM desnecessário. Pergunte se os dados pessoais são necessários ou devem ser mascarados antes de irem para a nuvem.

Resumindo

Cloud LLM traz ótimos recursos que não cabem no dispositivo móvel, mas exigem segurança e disciplina de custos. Regra de ouro: a chave da API nunca está no cliente, ela passa pelo proxy backend. O fluxo aumenta muito a velocidade e a retenção percebidas; Suportado pelo botão "parar". O custo é determinado pela redução do token enviado; A resiliência é alcançada ao lidar com todos os casos de erro com elegância. As respostas do LLM podem incluir alucinações; Em áreas críticas, a verificação é essencial e os dados pessoais são revisados ​​antes de serem enviados para a nuvem.

Tarefa de aplicativo

Solicite um design de cliente + proxy de back-end da IA usando o “modelo de arquitetura segura” para um recurso de “resumo de texto” ou “bate-papo”. Verifique se a chave de API reside apenas no back-end do design gerado. Em seguida, extraia pelo menos duas maneiras de reduzir o token enviado com o "padrão de atraso de custo" e escreva a mensagem educada a ser exibida ao usuário para uma condição de erro (por exemplo, 429).

lista de verificação

  • [] Verifiquei que a chave da API reside no back-end e não no cliente
  • [ ] Fiz o streaming da resposta e adicionei um botão ‘pause’
  • [] Lidei com timeout, erro de rede, situações 429 e 500
  • [] Reduzi o token enviado com a abreviatura/resumo anterior
  • [] Considerei a validação contra o risco de alucinações na resposta do LLM
  • [ ] Verifiquei a necessidade/mascaramento de dados pessoais antes de ir para a nuvem