Criando UX Rápida e Encantadora com LLMs em Mobile: Uma Arquitetura de Produção

Antes, a métrica relevante era "tempo até o primeiro token" — o tempo após enviar um prompt até o primeiro caractere renderizar no navegador. Hoje, aplicativos modernos não apenas vomitam palavras soltas. A experiência é multimodal. O app renderiza uma unidade CX significativa por vez. A métrica "tempo até o primeiro chunk" ficou mais apropriada. A chave: modelos são lentos. Você não pode esperar tudo de uma vez e precisará de formas diferentes de medir latência.

Loading Screens

Spinners de loading clássicos e skeleton screens são ótimos, mas têm um problema com features de IA. Se aparecerem por mais de 3 a 5 segundos, o usuário pensa que algo está lento ou algo deu errado. Para experiências de estilo conversacional, você pode mostrar "thinking" e ficar tranquilo. Mas e se a feature com IA não faz parte de uma conversa?

Após revisar centenas de designs de features com IA, apps tentam construir experiências "thinking" sem usar a palavra thinking. Dois padrões aparecem:

1. Mostrar CX existente com estilo diferente — gradientes, cores brilhantes, ícone de IA — mesmo que ainda seja só uma weather app
2. O produto evolui para lidar com a latência de forma útil

Amazon Lens faz isso bem: enquanto o modelo prepara a resposta, o usuário vê o objeto sendo rastreado. É envolvente e permite que forneça input — se selecionar outra coisa, o modelo sabe em que quer focar. Comparar com Gemini Live ou Copilot: você abre a câmera e pergunta algo, mas não sabe o que os modelos estão processando até receber a resposta.

Design Conversacional

Screenshots do ChatGPT e de um app de notícias popular mostram um padrão comum: layout dinâmico, estrutura em cards e infinite scroll. Design conversacional segue um padrão simples de construir um news feed: recuperar informação mais relevante e escolher o template CX certo para cada pedaço.

Dois pontos importantes para engenheiros frontend: reutilizar pedaços de CX existentes e renderização dinâmica.

Reutilizando Componentes

Quando apresenta resultados de busca em um app hipotético de reserva de voos, você mostra cartões formatados com informações legíveis. Se precisa construir uma feature com IA, é essencial reutilizar esse mesmo elemento. O nível de informação permanece igual, você mantém identidade de marca e usuários sabem ler.

Se o sistema que alimenta esses pequenos pedaços CX já funciona bem na página de busca ou página de detalhe, é ótima oportunidade de fine-tuná-los para seu caso de uso com IA.

Em resposta do app de reserva de voos, em vez de apenas usar output do modelo (texto denso que demora para entender), você mostra uma CX multimodal legível com resposta e perguntas de acompanhamento.

Server-Driven UI

Este padrão é útil não só para features com IA, mas para qualquer CX dinâmica. Engenheiros backend adoram construir APIs — é tudo que fazem. Mas quando você pede lógica específica do cliente, recusam. APIs que entregam costumam ser gigantes. Por exemplo, um flight card retorna 10 mil linhas de JSON porque sim — têm toda informação do voo. Clientes não precisam disso tudo.

Server-driven UI resolve isso: você precisa de um view model para frontend com informação suficiente para renderizar ao cliente.

Backend for Frontend (BFF)

BFF é parte de server-driven UI, não um padrão próprio. Neste ponto, o frontend tem info suficiente para saber o que renderizar. BFF mostra COMO renderizar — lógica específica de plataforma (Android mostra spinner diferente, iOS precisa de outro), tudo entra aqui.

A melhor parte: BFF prepara um payload de ação muito detalhado. Exemplo: o que fazer quando alguém clica no cartão de voo, o que fazer com long press em uma pergunta. Esses pequenos detalhes movem todo peso para backend, fazendo o cliente não saber nada sobre o que está acontecendo.

Server-driven UI não é tudo preto ou branco — é um espectro sobre quanto você quer controlar o que o cliente renderiza. Você precisa encontrar equilíbrio entre controle e esforço para construir.

Responsabilidade Frontend

Frontend não costuma receber crédito por lidar com esses casos de uso em evolução. Apps com IA funcionam melhor quando você fornece mais informação sobre si — informação crítica como acesso à câmera ou chat privado. Frontend está na frente do usuário e agora tem mais responsabilidade.

Compreensão de Query

Query understanding é uma parte importante de qualquer sistema de busca e também essencial para sistemas com IA. É geralmente a primeira chamada de serviço fora do frontend e adiciona clareza a perguntas de clientes.

Query understanding categoriza queries — clientes tentando buscar algo vs. clientes tentando encomendar algo. Adiciona clareza sobre o cliente: qual moeda prefere? No app de reserva de voos, query understanding coleta que esse cliente sempre prefere voos diretos.

Quanto mais você sabe sobre a query, melhor a resposta. Com features de IA, há uma responsabilidade adicionada: query understanding agora precisa saber sobre capacidades do app. Este é o primeiro serviço fora do frontend que realmente sabe sobre frontend.

Exemplo: quando cliente faz API call para a feature de IA, backend precisa saber o que cliente está vendo. Neste caso, URL da página de voos, informação de origem/destino e input necessário. Backend faz decisões melhores. Query understanding coleta essa informação no começo para outros serviços downstream se beneficiarem.

Isso não é RAG (Retrieval-Augmented Generation). Você apenas está adicionando clareza à query do cliente.

Orchestrator

Orchestrator tem menos a ver com frontend, então não entraremos em detalhe. Para uma query de usuário dada, orchestrator faz três coisas: coleta informação de sistema de recuperação de informação, escolhe o prompt certo e aguarda modelo responder, fazendo sentido do que volta.

O modelo não sabe nada por si. Alguém precisa alimentar toda informação para obter a resposta certa.

Escolhendo o Prompt Certo

Isso não é tanto sobre frontend, mas aguarde. Você provavelmente ouviu sobre "prompt engineering". Quando perguntou ao ChatGPT o que é um prompt, recebeu: "Um prompt é um conjunto de instruções fornecidas a um modelo para extrair output desejado."

Com o que prompt engineering tem a ver com frontend? Para fazer o LLM decidir qual CX certo mostrar para a query, o prompt precisa revelar capacidades do app ao modelo. Em qualquer sistema em larga escala, bits e pedaços evoluem ao longo do tempo. Especialmente usando server-driven UI, novos elementos CX são adicionados constantemente e, às vezes, um elemento é removido. O LLM precisa saber quais opções tem para escolher a certa.

Modelos podem resumir emails, entender e escrever código. Também podem escolher CX certo quando você permite. Não é fácil perfeição em prompt engineering — é fácil começar e ir longe, mas muito difícil ficar perfeito.

Exemplo de Prompt

Usando o app de reserva de voos: cliente pergunta "Não consigo fazer meu voo matinal. Há opções para voar à tarde?". É uma simples pergunta de recuperação de informação. Você quer o sistema responder com resposta formatada multimodal bonita. Texto sozinho bastaria, mas você prefere a versão visual.

O prompt deve incluir instruções sobre como construir essa UI.

Em um template simples, há detalhes do prompt, instruções para modelo, dados de entrada e, mais importante, output schema — como você quer o modelo responder.

No system prompt, o modelo é configurado para decidir qual componente UI é melhor para a query e sempre responder no formato esperado.

Contexto é moldado assim:

• Contexto do usuário ajuda o modelo aprender sobre o usuário. Você quer que modelo cumprimente usuário para qualquer pergunta
• Modelo é fornecido com dados para responder qualquer pergunta. Cliente perguntou "Quais são meus voos alternativos?"
• A parte mais importante: você está fazendo o modelo olhar quais opções CX estão disponíveis

Exemplo simplificado: você oferece duas opções. Quando mostra voos disponíveis, escolha um destes dois — lista de voos ou carrossel. Se há centenas de opções, escolha lista. Se há 4-5 opções, escolha carrossel. Também instrui como construir essa CX. Quando escolher componente, também enquadre o data spec para esse modelo CX.

Ao ponto: temos feito tudo para garantir que modelo entenda a query, tenha todos os fatos para respondê-la e conheça as opções CX disponíveis. Quando recebe o prompt, modelo responde, frequentemente token por token e em streaming. Orchestrator então acumula até ver um chunk significativo e vai de volta para BFF.

Por exemplo, se envia de volta cartão de voo com número de voo, seu BFF toma responsabilidade de digerir, preparar para a view. Acontece para cada chunk. A menos que trabalhe em uma dessas empresas, vai chamar um provedor de modelo externo. Qualquer coisa compartilhada é ainda relevante, não importa qual provedor escolha. Pode haver pequenas nuances em estrutura de prompt, mas jogando com isso, você entenderá o jeito certo.

Além do Chat

Três anos se passaram desde ChatGPT e quase todas features saíram em estilo conversacional, construindo aplicação de chat. Estão realmente tentando mostrar forças de um large language model. Do ponto de vista de desenvolvedor de app, você não vai ver mudança maior ou feature de IA maior fora dessa configuração conversacional.

Porém, notou que features de IA começaram aparecer lentamente em pequenos pedaços em lugares onde você não espera. Google Journal tem muitas features de IA e não sente que você está conversando com Gemini — que realmente aprecia.

IA no Frontend

Trazendo você de volta ao frontend com perspectiva ligeiramente diferente: pense em construir app com IA que depende de informação muito crítica — câmera, acesso a chat privado. Às vezes não há opção de levar informação crítica para fora do cliente frontend.

Pense em adicionar chatbot de IA ao WhatsApp. End-to-end encryption está ativada. Agora frontend precisa evoluir para lidar com essa responsabilidade. Não é só renderizar coisas para cliente. Vai fazer peso pesado.

O app de journal que mostrou antes: modelo que alimenta essa feature de IA roda inteiramente no cliente. Dados do journal entry nunca deixam o dispositivo. Vamos falar sobre IA no frontend. Não é algo novo. Existia muito antes de ChatGPT.

Bom exemplo: credit card scanner. Scanner roda inteiramente no dispositivo, nunca faz upload para backend. Lê números, validade, nome e submete só essa informação para outra firma. É feito de forma que é compatível com padrões de pagamento.

A necessidade de rodar local language model começou agora. Depois de todos esses novos casos de uso de IA, há necessidade de fazer truly private inference.

On-Device AI

Trazer IA para o dispositivo não é pura conveniência — é sobre dar privacidade real ao seu cliente enquanto ainda oferece poder de IA. Há desafios. Modelos grandes não cabem em dispositivos. Você precisa de modelos menores quantizados (reduzidos) que rodam com latência muito baixa. O trade-off é qualidade da resposta — modelos menores podem não ser tão bons quanto Claude 3 ou GPT-4.

Você tem opções. Se você tem informação crítica no frontend, você pode executar modelo inteiro no dispositivo. Você também pode executar parte do modelo no dispositivo e parte na cloud — modelo híbrido. Depende do seu caso de uso.

Features privadas que rodam on-device ganham tração. Amazon tinha journal entry AI, Apple tem Apple Intelligence, Google tem Gemini Nano no Pixel. Modelagem é hard. Você precisa entender seu usuário, o quanto de privacidade eles querem vs. o quanto de qualidade eles precisam.

Para apps mobile, você provavelmente vai usar frameworks como Core ML (iOS), MediaPipe (multiplataforma), ou ONNX Runtime. Esses abstraem muito da complexidade.

Concluindo: construir conversational AI features em escala é desafio. Você precisa ser inteligente sobre como você apresenta latência do modelo, como você reutiliza componentes existentes, como você usa server-driven UI para tornar seu sistema flexível. Com tudo isso em mente, você pode construir experiências de IA rápidas e encantadoras no mobile que sua comunidade vai adorar.