10 arquiteturas de IA para atendimento ao cliente
⏱ 21 min·⭐ 80 XP
Ao terminar: Você desenha uma arquitetura de atendimento com IA na AWS escolhendo o modelo pelo prazo de resposta, não só pela qualidade.
O que une estas dez arquiteturas
As dez arquiteturas desta família resolvem problemas de atendimento, e todas batem na mesma restrição: alguém está esperando. Isso muda a engenharia. Onde não há usuário na frente, o lote resolve por metade do preço; aqui o prazo até a primeira resposta é requisito de produto, e é ele que elimina candidatos de modelo antes de qualquer discussão de qualidade.
A segunda restrição é o custo do erro. Atendimento é a superfície pública da empresa: uma resposta errada com tom confiante vira captura de tela. Por isso aparece em quase todos os dez desenhos uma saída explícita para o humano — não como exceção de falha, mas como caminho de primeira classe que o desenho prevê, instrumenta e mede.
| # | Problema | A decisão que transfere |
|---|---|---|
| 1 | Contact center com fila alta e respostas inconsistentes | Modelo pequeno e rápido vence modelo grande quando a latência é o requisito: o alvo era resposta em ≤2,5 s |
| 2 | Chamadas de voz em volume, com risco de resposta errada | Escalonamento é caminho de primeira classe, não exceção — 15 mil chamadas/dia exigem que a saída para humano seja parte do desenho |
| 3 | Escalonamento excessivo do agente virtual para humano | Agente que consulta o estado real do pedido escalona menos: a redução de até 40% vem de ter ferramenta, não de prompt melhor |
| 4 | Assistente de concessionária sem acesso à informação oficial | RAG sobre documento oficial substitui treinar modelo: o acervo muda toda semana, e treino não acompanha |
| 5 | Atendimento fora do horário sem cobertura humana | Autonomia se conquista por escopo estreito: o agente só age no que tem ferramenta e permissão |
| 6 | Assistente de compras que não conhece o catálogo | Recomendação precisa de duas fontes: conhecimento (catálogo) e estado (estoque). Só a primeira gera sugestão de produto esgotado |
| 7 | Cliente pergunta em português e o acervo está em inglês | Traduzir o acervo uma vez custa menos que traduzir toda consulta — e preserva o termo técnico |
| 8 | Resumo de conversa para o próximo atendente | Resumo é trabalho de fundo: ninguém espera, então lote custa metade |
| 9 | Detecção de intenção antes de acionar o modelo grande | Classificar com serviço especializado antes de gerar é a alavanca de custo mais ignorada em atendimento |
| 10 | Agente de voz com interrupção do usuário | O que define a percepção é o tempo até o primeiro som, não o total |
#1
ProblemaContact center com fila alta e respostas inconsistentes
A decisão que transfereModelo pequeno e rápido vence modelo grande quando a latência é o requisito: o alvo era resposta em ≤2,5 s
#2
ProblemaChamadas de voz em volume, com risco de resposta errada
A decisão que transfereEscalonamento é caminho de primeira classe, não exceção — 15 mil chamadas/dia exigem que a saída para humano seja parte do desenho
#3
ProblemaEscalonamento excessivo do agente virtual para humano
A decisão que transfereAgente que consulta o estado real do pedido escalona menos: a redução de até 40% vem de ter ferramenta, não de prompt melhor
#4
ProblemaAssistente de concessionária sem acesso à informação oficial
A decisão que transfereRAG sobre documento oficial substitui treinar modelo: o acervo muda toda semana, e treino não acompanha
#5
ProblemaAtendimento fora do horário sem cobertura humana
A decisão que transfereAutonomia se conquista por escopo estreito: o agente só age no que tem ferramenta e permissão
#6
ProblemaAssistente de compras que não conhece o catálogo
A decisão que transfereRecomendação precisa de duas fontes: conhecimento (catálogo) e estado (estoque). Só a primeira gera sugestão de produto esgotado
#7
ProblemaCliente pergunta em português e o acervo está em inglês
A decisão que transfereTraduzir o acervo uma vez custa menos que traduzir toda consulta — e preserva o termo técnico
#8
ProblemaResumo de conversa para o próximo atendente
A decisão que transfereResumo é trabalho de fundo: ninguém espera, então lote custa metade
#9
ProblemaDetecção de intenção antes de acionar o modelo grande
A decisão que transfereClassificar com serviço especializado antes de gerar é a alavanca de custo mais ignorada em atendimento
#10
ProblemaAgente de voz com interrupção do usuário
A decisão que transfereO que define a percepção é o tempo até o primeiro som, não o total
1. Contact center com fila alta e resposta inconsistente
A fila cresce porque cada atendente resolve o mesmo caso de um jeito diferente, e o tempo médio reflete isso. O requisito que a operação impõe não é "responder bem": é responder em até 2,5 segundos, porque acima disso o cliente percebe silêncio na linha e desiste.
Canal de voz
Amazon Connectfila, gravação e transferência
Transcribefala → texto em fluxo, sem esperar o fim
Amazon Lexresolve a intenção rotineira sem gerar texto
Modelo
Bedrockporta única de modelo, sem endpoint para gerenciar
Claude Haikuescolhido pelo prazo, não pelo teto de qualidade
Conhecimento
Knowledge Basesprocedimento e política vigentes
Saída e medida
Atendente humanorecebe a conversa com resumo
p95 até o 1º somo requisito que decide o modelo
- → áudio em fluxo
- → transcrição parcial
- → só o que exige geração
- → perfil de inferência
- → consulta
- → trecho citável
- → áudio sintetizado em streaming
- → transfere com resumo
- → mede cada resposta
- Integração de apps
- IA e machine learning
- Fora da AWS
- Conceito de arquitetura
Modelo pequeno com recuperação boa vence modelo grande sem ela quando o requisito é tempo. E a consistência que faltava não estava no modelo: estava em ter uma fonte única de política para recuperar.
- O prazo entra antes do modelo. O requisito de 2,5 s até o primeiro som é declarado antes de escolher o modelo — e é ele que elimina candidatos. Escolher o modelo primeiro e depois tentar caber no prazo é a ordem que faz o projeto voltar do começo.
- Lex resolve o que não precisa de geração. Saldo, status de pedido e horário de funcionamento são consulta, não redação. Classificar a intenção antes evita a chamada mais cara e é a alavanca de custo mais ignorada em atendimento.
- Modelo pequeno ganha por prazo. Haiku não foi escolhido por ser barato: foi escolhido porque cabe no orçamento de latência. Quando o requisito é tempo, o modelo grande é tecnicamente melhor e operacionalmente inviável.
- A consistência vem do acervo, não do modelo. O que fazia cada atendente responder diferente era a política estar em seis lugares. Recuperar do acervo vigente é o que torna a resposta uniforme — e trocar de modelo não resolveria isso.
- A transferência humana é caminho, não falha. Quando a confiança cai ou o assunto sai do escopo, o desenho transfere com o resumo do que já foi dito. Transferência sem contexto faz o cliente repetir tudo, e é aí que a satisfação cai mais que na espera.
Cadeia de serviçosConnect → Lex/Transcribe → Bedrock (Claude Haiku) → Knowledge Bases → transferência humana
A decisão que transfereModelo pequeno e rápido vence modelo grande quando a latência é o requisito: o alvo era resposta em ≤2,5 s
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [1]
2. Chamada de voz em volume, com risco de resposta errada
Em volume de dezenas de milhares de chamadas por dia, a pergunta deixa de ser "o modelo acerta?" e passa a ser "o que acontece nas que ele erra?". Um por cento de erro em 15 mil chamadas são 150 clientes por dia — e sem caminho de saída eles viram reclamação pública.
Canal
Amazon Connectfluxo de contato e fila
Transcribe em fluxodevolve parcial, para o modelo começar antes do ponto final
Modelo com barreira
Guardrailsentrada e saída, com registro da recusa
Bedrocka porta; o perfil de inferência fixa o modelo
Clauderesponde ou declara que não sabe
Escalonamento
Regra de saídaconfiança baixa, tema sensível, pedido do cliente
Atendente humanocom transcrição e resumo em tela
Operação
CloudWatchtaxa de escalonamento por motivo
- → áudio em fluxo
- → antes do modelo
- → entrada aprovada
- → perfil de inferência
- → antes de falar
- → avalia a saída
- → escalona
- → responde
- → motivo do escalonamento
- Integração de apps
- IA e machine learning
- Conceito de arquitetura
- Fora da AWS
- Gestão e governança
Escalonamento não é o que acontece quando a arquitetura falha: é parte da arquitetura. Em volume alto, o caminho de exceção precisa de instrumentação, contexto e regra nomeada — igual ao caminho felizy.
- Guardrails nas duas pontas. Na entrada ele barra o que não deveria virar contexto; na saída, o que não deveria ser falado. Só na saída é tarde: o dado sensível já entrou no prompt, no registro e no cache.
- A regra de saída é explícita e nomeada. Três motivos disparam humano: confiança baixa, tema na lista sensível e pedido direto do cliente. Regra nomeada é regra auditável — "quando o bot não souber" não é implementável.
- O humano recebe contexto, não uma linha zerada. A transcrição e o resumo chegam junto. É o que evita o pior momento do atendimento automatizado: o cliente contar tudo de novo depois de já ter contado.
- A taxa de escalonamento é métrica de produto. Ela sobe quando o acervo envelhece e cai quando o escopo cresce. Medida por motivo, ela diz o que corrigir; medida no agregado, só diz que algo piorou.
- O volume é o que torna o desenho obrigatório. Em cem chamadas por dia, a exceção cabe no improviso. Em quinze mil, o caminho de exceção é o que define a operação — e por isso ele é desenhado primeiro, não depois.
Cadeia de serviçosConnect → Transcribe (fluxo) → Bedrock → Guardrails → escalonamento humano
A decisão que transfereEscalonamento é caminho de primeira classe, não exceção — 15 mil chamadas/dia exigem que a saída para humano seja parte do desenho
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [2]
3. Escalonamento excessivo do agente virtual
O agente virtual transfere quase tudo para humano, e a economia não aparece. A causa quase nunca é o modelo: é ele não ter acesso ao estado real do pedido, então qualquer pergunta concreta ("onde está minha entrega?") só pode terminar em transferência.
Canal
Clientejá autenticado — o escopo da consulta sai da sessão
API Gatewayautenticação e limite de taxa
Laço do agente
Claude com ferramentasdecide qual ferramenta chamar
Memória de sessãoo que já foi perguntado e resolvido
Ferramentas de leituraVPC
consultarPedidosó leitura, escopo por cliente
consultarFaturasó leitura
Sistema de atendimentoa fonte do estado real
Medida
Taxa de transferênciapor intenção, não no agregado
- → pergunta + sessão
- → sessão autenticada
- → lê e grava
- → pedido
- → fatura
- → consulta por cliente
- → consulta por cliente
- → estado real
- → transferiu ou resolveu
- Fora da AWS
- Rede e entrega
- IA e machine learning
- Banco de dados
- Compute
- Conceito de arquitetura
Agente que consulta o estado real transfere menos. O ganho vem de dar ferramenta, não de escrever prompt melhor — e a próxima ferramenta a construir é a que a taxa de transferência por intenção aponta.
- A causa é falta de ferramenta, não prompt ruim. Sem ferramenta, o agente só tem duas saídas para pergunta concreta: inventar ou transferir. Um prompt melhor faz ele transferir com mais elegância — o número não muda.
- Ferramenta de leitura primeiro. Consultar não tem efeito colateral: erra sem estragar. Começar por leitura entrega a maior parte da redução com a menor parte do risco.
- O escopo mora na ferramenta. A ferramenta recebe o identificador da sessão autenticada e consulta só aquele cliente. Deixar o filtro para o prompt é o que transforma pergunta esperta em vazamento entre clientes.
- Memória de sessão evita a repetição. Sem ela, o agente pergunta o número do pedido três vezes na mesma conversa — e o cliente pede humano por irritação, não por incapacidade do modelo.
- A métrica é por intenção. A taxa agregada esconde o padrão: em geral duas ou três intenções concentram as transferências, e é nelas que a próxima ferramenta rende.
Cadeia de serviçosBedrock (Claude) com ferramentas de sistema de atendimento + memória de sessão
A decisão que transfereAgente que consulta o estado real do pedido escalona menos: a redução de até 40% vem de ter ferramenta, não de prompt melhor
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [3]
4. Assistente sem acesso à informação oficial
O assistente responde sobre produto usando o que o modelo aprendeu na internet — que está desatualizado e, em alguns pontos, errado. O acervo oficial (manual, boletim técnico, tabela de preço) muda toda semana, e nenhum treino acompanha esse ritmo.
Canal
Cliente ou vendedorpergunta sobre produto, preço e disponibilidade
API Gatewayautenticação, cota e limite de taxa
Runtime do agente
AgentCore Runtimesessão, identidade e rastro gerenciados
Clauderesponde só com o que recuperou
Acervo oficial
S3 — manuais e boletinsa fonte de verdade versionada
Knowledge Basesingestão incremental por evento
Citação verificadao trecho existe no documento apontado
Frescor
EventBridgeboletim novo entra na mesma hora
- → pergunta sobre o produto
- → sessão
- → contexto da sessão
- → consulta
- → trechos + fonte
- → valida antes de devolver
- → resposta com fonte
- → documento novo
- → ingestão incremental
- Fora da AWS
- Rede e entrega
- IA e machine learning
- Armazenamento
- Conceito de arquitetura
- Integração de apps
RAG sobre documento oficial substitui treinar modelo quando o acervo muda mais rápido que o ciclo de treino. E a citação não é enfeite: é o que transforma alucinação em erro que dá para detectar.
- Treinar não resolve acervo que muda toda semana. Ajuste fino congela o conhecimento no momento do treino. Quando o boletim de quinta contradiz o manual de janeiro, só a recuperação sabe disso.
- A ingestão é por evento, não agendada. Documento novo no S3 dispara a ingestão. "Sincroniza toda noite" é uma decisão legítima — mas é uma decisão, e o usuário precisa saber que a resposta pode ter um dia de atraso.
- Citação é o que torna o erro detectável. Sem fonte, alucinação e acerto são indistinguíveis para quem lê. Com fonte, quem duvida confere — e o erro para de se propagar como verdade.
- Validar que o trecho existe. Modelo cita documento que não contém o trecho. Conferir a citação contra o texto recuperado transforma alucinação em falha que o código pega, sem julgamento humano.
- O runtime gerenciado é encanamento, não a solução. AgentCore entrega sessão, identidade e rastro sem você construir. O que ele não entrega é o critério de qualidade da resposta — esse continua sendo trabalho seu.
Cadeia de serviçosBedrock AgentCore → Knowledge Bases sobre manuais e boletins → resposta com citação
A decisão que transfereRAG sobre documento oficial substitui treinar modelo: o acervo muda toda semana, e treino não acompanha
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [4]
5. Atendimento fora do horário sem cobertura humana
Entre 22h e 7h não há ninguém, e o cliente que quer reagendar uma entrega fica para o dia seguinte. Autonomia real exige que o agente *aja* — e agir sem supervisão humana só é aceitável se o escopo do que ele pode fazer for pequeno e nomeado.
Canal
Clientefora do horário comercial
Canal de mensagemonde o cliente já está, fora do horário comercial
Agente autônomo
AgentCoreteto de passos e de gasto por sessão
Claudedecide qual ferramenta e se pede confirmação
Ações permitidasVPC
reagendarEntregaescrita, com confirmação do cliente
consultarStatusleitura
CRM e logísticao sistema de registro da entrega
Trilha e limite
Trilha de açãoquem, o quê, quando, com qual argumento
Fila para o humanoo que sai do escopo espera as 7h
- → mensagem às 3h
- → texto + identidade
- → sessão com teto de passos
- → leitura
- → escrita
- → consulta o status
- → grava o reagendamento
- → registra a ação
- → fora do escopo
- Fora da AWS
- IA e machine learning
- Compute
- Gestão e governança
- Integração de apps
Autonomia não vem de confiar mais no modelo: vem de reduzir o que ele pode fazer. Duas ferramentas, teto de passos e trilha por ação — e o que não cabe nisso espera o humano, dito ao cliente sem rodeio.
- Autonomia se conquista por escopo estreito. O agente só age no que tem ferramenta. Duas ações permitidas e nada mais: a lista de ferramentas É a fronteira de autonomia, e ela é lida no código, não inferida do prompt.
- Leitura e escrita são ferramentas separadas. Separar permite permissão diferente para cada uma — e permite liberar a leitura para todos os casos enquanto a escrita fica em dois. Uma ferramenta que lê e escreve não dá para autorizar pela metade.
- O que sai do escopo espera, e o cliente sabe. A fila para humano é a resposta honesta: "isso eu não resolvo, alguém te responde às 7h". Melhor que tentar e errar às 3h da manhã sem ninguém para corrigir.
- Trilha por ação, com o argumento. De manhã alguém vai perguntar por que a entrega do cliente X mudou de dia. Sem argumento registrado, a resposta é "o agente decidiu" — que não é resposta.
- O teto de gasto mora no runtime. Sessão sem teto de passos é orçamento sem teto. Agente noturno em laço roda oito horas sem ninguém olhando — o limite precisa ser do código, não da vigilância.
Cadeia de serviçosAgentCore autônomo → ferramentas de agendamento e CRM → registro de trilha
A decisão que transfereAutonomia se conquista por escopo estreito: o agente só age no que tem ferramenta e permissão
Origem da informaçãoCaso público documentado, com fonte citada no catálogo — fonte [5]
Quiz rápido
Um agente de voz precisa responder em até 2,5 s até o primeiro som. Qual decisão de arquitetura vem PRIMEIRO?
6. Assistente de compras que não conhece o catálogo
O assistente recomenda produto que não existe mais ou está esgotado. A causa é ele ter só uma fonte: o catálogo indexado, que descreve o produto mas não sabe quantos há em estoque agora. Conhecimento e estado são coisas diferentes, e confundi-las gera recomendação inútil.
Canal
Compradorquer o produto, não a busca
API Gatewaysessão e limite de taxa
Lambdamonta a sessão
Agente
Bedrock Agentsorquestra as duas fontes
Claudeorquestra as duas fontes e filtra o esgotado
Conhecimento (o quê)
Knowledge Basesdescrição, ficha técnica, resenha
Estado (agora)VPC
Grupo de ação: estoqueconsulta em tempo real
Estoquemuda a cada pedido
- → o que estou procurando
- → sessão
- → pedido do comprador
- → ferramentas disponíveis
- → o que combina com o pedido
- → candidatos
- → tem em estoque?
- → quantidade agora
- → disponibilidade
- → só o que existe e está disponível
- Fora da AWS
- Rede e entrega
- Compute
- IA e machine learning
- Banco de dados
Recomendação precisa de duas fontes: conhecimento indexado para o que combina e estado consultado para o que existe. Indexar estado é a confusão que gera a sugestão perfeita de um produto esgotado.
- Duas fontes, dois papéis. O acervo indexado responde "o que combina"; o estoque responde "o que existe agora". Só a primeira gera a sugestão perfeita de um produto esgotado.
- Estado não entra no índice vetorial. Indexar quantidade é indexar algo que muda a cada minuto — o índice fica errado assim que é escrito. Estado se consulta; conhecimento se indexa.
- A ordem economiza chamada. Recuperar candidatos primeiro e conferir estoque só dos poucos que sobraram é mais barato que conferir o catálogo inteiro. A ordem das duas consultas é decisão de custo.
- O filtro final é do código. Pedir ao modelo "não sugira esgotado" é confiar em instrução. Remover o esgotado da lista antes de montar a resposta é garantia.
- O grupo de ação é o adaptador. Quem chama o serviço de estoque é a sua função, com o argumento validado. O modelo pede; o código decide se aquilo é um pedido legítimo.
Cadeia de serviçosAPI Gateway → Lambda → Bedrock Agents → Knowledge Bases de catálogo + grupo de ação de estoque
A decisão que transfereRecomendação precisa de duas fontes: conhecimento (catálogo) e estado (estoque). Só a primeira gera sugestão de produto esgotado
Origem da informaçãoArquitetura de referência publicada pela AWS — fonte [6]
7. Cliente pergunta em português, acervo está em inglês
A documentação de produto está em inglês e os clientes perguntam em português. Traduzir cada pergunta e cada resposta em tempo de consulta multiplica latência e custo por chamada — e degrada justamente o termo técnico, que é o que precisava chegar inteiro.
Ingestão (uma vez)
S3 — acervo em inglêsdocumentação como o fornecedor publica, em inglês
Translate + glossáriotermo técnico e nome de produto preservados
Índice bilínguetrecho original e traduzido, mesmo id
Consulta (toda vez)
Cliente em PT-BRdigita na língua dele, sem tradutor no caminho
Claude multilíngueentende a pergunta sem tradutor no caminho
Resposta
Resposta em PT-BRcita o documento original
- → lote, uma vez
- → indexa as duas versões
- → pergunta em PT-BR
- → busca nas duas línguas
- → trechos
- → texto em PT-BR
- → resposta + fonte original
- Armazenamento
- IA e machine learning
- Fora da AWS
- Conceito de arquitetura
Traduzir o acervo uma vez custa menos que traduzir toda consulta — e preserva o termo técnico, que é justamente o que a tradução em tempo de consulta estraga.
- O custo está no lugar errado. Traduzir na consulta paga por chamada, para sempre. Traduzir na ingestão paga uma vez por documento. O acervo muda devagar; a consulta, não.
- Glossário vence prompt para terminologia. Nome de produto e termo técnico não devem ser traduzidos. Glossário é determinístico: não depende de o modelo lembrar a instrução naquela chamada.
- Indexar as duas versões, com o mesmo identificador. A busca acha pelo português; a citação aponta o documento original em inglês. Quem quiser conferir vai à fonte, não à tradução.
- O modelo já é multilíngue. Não é preciso tradutor entre o cliente e o modelo: ele entende a pergunta em português e responde em português. O tradutor existe para o ACERVO, não para a conversa.
- A resposta cita o original. Traduzir a citação esconde a fonte de quem precisa verificar. A resposta é em português; a referência aponta o documento como ele existe.
Cadeia de serviçosBedrock multilíngue + Translate no acervo indexado, não na consulta
A decisão que transfereTraduzir o acervo uma vez custa menos que traduzir toda consulta — e preserva o termo técnico
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
8. Resumo de conversa para o próximo atendente
Quando o cliente volta, o atendente novo lê trinta minutos de transcrição ou pergunta tudo de novo. O resumo resolve — e ninguém está esperando por ele no momento em que a chamada termina, o que muda completamente a engenharia e o preço.
Origem
Amazon Connectfluxo de contato, fila e gravação
Contact Lenstranscrição e sentimento já prontos
S3transcrição do dia
Processamento de fundo
Inferência em lotejanela de horas, sem ninguém esperando
Bedrockresumo com ação pendente e tom
Destino
CRMresumo na ficha do cliente
CloudWatchcusto por resumo
- → áudio da chamada
- → transcrição
- → acumula a janela
- → lote de transcrições
- → resumo estruturado
- → custo por resumo
- Integração de apps
- Armazenamento
- Conceito de arquitetura
- IA e machine learning
- Fora da AWS
- Gestão e governança
O que ninguém espera não deve ser feito sob demanda. Reconhecer que o resumo é trabalho de fundo corta o custo pela metade — e a economia vem da janela de entrega, não de trocar o modelo.
- Ninguém está esperando — então é lote. O resumo é lido horas depois, quando o cliente volta. Latência não é requisito, e a inferência em lote custa cerca de metade da sob demanda.
- A transcrição já existe. Contact Lens já transcreve e analisa sentimento. Reprocessar áudio com outro serviço é pagar duas vezes pelo mesmo dado.
- O resumo tem forma, não é texto livre. Três campos: o que o cliente queria, o que foi resolvido e o que ficou pendente. Resumo em prosa livre o atendente não lê — ele tem 20 segundos.
- O destino é o sistema que o atendente já abre. Resumo em painel separado não é lido. Ele precisa aparecer na ficha do cliente, no sistema onde o atendimento acontece.
- O custo por resumo é a métrica que decide o escopo. Com o número por resumo, dá para decidir se resume toda chamada ou só as que passaram de cinco minutos. Sem ele, a decisão é chute.
Cadeia de serviçosConnect Contact Lens → S3 → Bedrock em lote → CRM
A decisão que transfereResumo é trabalho de fundo: ninguém espera, então lote custa metade
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
9. Detecção de intenção antes do modelo grande
Toda mensagem que entra vira chamada ao modelo de linguagem, inclusive "obrigado", "ok" e "qual o horário de vocês". A conta cresce proporcional ao volume, e a maior parte desse volume não exigia geração de texto nenhuma.
Entrada
Mensagem do clientemetade é saudação, status ou agradecimento
Comprehendclassificação, entidade, sentimento
RoteamentoVPC
Roteadordecide por classe, no código
Resposta de modelo fixosaudação, horário, status
Geração
Bedrocksó o que exige redação
Claudesó o que exige redação chega aqui
Medida
% que chega ao modeloa alavanca de custo desta arquitetura
- → texto cru
- → classe + confiança
- → rotina
- → exige geração
- → perfil de inferência
- → fração roteada ao modelo
- Fora da AWS
- IA e machine learning
- Compute
- Conceito de arquitetura
Classificar com serviço especializado antes de gerar é a alavanca de custo mais ignorada em atendimento. A métrica que mede o ganho é a fração de mensagens que chega ao modelo — e ela cabe num painel.
- Classificar é ordens de magnitude mais barato que gerar. Comprehend cobra por unidade de texto classificado; o modelo cobra por token gerado. Para decidir se a mensagem é uma saudação, o segundo é desperdício.
- O roteador é código, com a classe e a confiança. A decisão não pode ser do modelo — seria pagar a chamada que se quer evitar. É uma condicional no seu código sobre a classe devolvida.
- Resposta fixa para o que é fixo. Horário de funcionamento não muda por cliente. Modelo fixo é mais rápido, mais barato e não erra — três vantagens que geração nenhuma oferece aqui.
- Confiança baixa vai para o modelo, não para o modelo fixo. Quando o classificador não tem certeza, o caminho seguro é gerar. Errar a classe e responder com texto fixo produz a resposta errada com aparência de resposta oficial.
- A métrica é a fração que chega ao modelo. Ela é a alavanca: cair de 100% para 35% corta dois terços do custo de inferência sem tocar em modelo, prompt ou cache.
Cadeia de serviçosComprehend (classificação) → roteamento → Bedrock só no que exige geração
A decisão que transfereClassificar com serviço especializado antes de gerar é a alavanca de custo mais ignorada em atendimento
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
10. Agente de voz com interrupção do usuário
O agente de voz responde certo, e o cliente desliga. O motivo é ritmo: dois segundos de silêncio numa ligação parecem uma eternidade, e um agente que não pode ser interrompido soa como gravação — que é exatamente o que o cliente aprendeu a evitar.
Áudio
Amazon Connectáudio bidirecional
Transcribe em fluxoparciais, não só o final
Detecção de faladispara o corte quando o cliente fala
Geração em fluxoVPC
Bedrock em fluxoprimeiros tokens já saem
Segmentadorcorta a resposta em frases
Voz
Pollysintetiza frase por frase
Cache de frase fixasaudação e confirmação já prontas
- → áudio do cliente
- → parcial
- → tokens em fluxo
- → frase 1, frase 2…
- → frase já sintetizada
- → áudio
- → CORTA
- → energia do canal
- Integração de apps
- IA e machine learning
- Compute
- Banco de dados
Em voz, a percepção é definida pelo tempo até o primeiro som e pela capacidade de ser interrompido — não pela latência total nem pela qualidade do texto. As duas exigem fluxo em todo o caminho.
- Otimize o primeiro som, não o total. A resposta inteira levar três segundos é aceitável; o silêncio inicial passar de um é o que soa como queda de ligação. São métricas diferentes e só uma delas o cliente percebe.
- Segmentar por frase é o que permite começar antes de terminar. Esperar a resposta completa para sintetizar soma as duas latências. Cortar na primeira frase faz a síntese começar enquanto o modelo ainda escreve.
- Interromper exige poder descartar. Quando o cliente fala, o que está na fila de áudio precisa ser jogado fora. Agente que termina a frase por cima do cliente é pior que agente lento.
- Frase fixa é cacheada, não sintetizada. "Um momento, vou verificar" é sempre igual. Sintetizar de novo é gastar tempo e dinheiro no trecho onde a latência mais aparece: o começo.
- Transcrição parcial alimenta o modelo antes do ponto final. Esperar o cliente terminar a frase inteira para começar a pensar adiciona a duração da fala à latência percebida. A parcial deixa o trabalho começar junto.
Cadeia de serviçosConnect → transcrição em fluxo → Bedrock em fluxo → Polly por frase, com corte na fala do usuário
A decisão que transfereO que define a percepção é o tempo até o primeiro som, não o total
Origem da informaçãoPadrão composto — a topologia que se repete, sem cliente nomeado
Perguntas frequentes
❓ Qual modelo usar em atendimento de voz com IA na AWS?
Use o menor modelo que cabe no orçamento de latência — em voz, tipicamente um modelo rápido como Claude Haiku no Bedrock. O requisito manda: acima de cerca de dois segundos até o primeiro som, o cliente percebe silêncio e desliga, então o modelo grande é tecnicamente melhor e operacionalmente inviável. A qualidade que falta vem da recuperação do acervo oficial e do escalonamento para humano, não de trocar por um modelo maior.
❓ Como reduzir o custo de IA em atendimento ao cliente?
A maior alavanca é classificar antes de gerar: mandar toda mensagem ao modelo de linguagem é o desperdício típico, porque saudação, horário e status de pedido são consulta, não redação. Um classificador especializado como o Comprehend roteia, e só o que exige geração chega ao modelo. A métrica a acompanhar é a fração de mensagens que chega ao modelo — cair de 100% para 35% corta dois terços do custo sem mexer em modelo nem em prompt.
❓ Por que o agente virtual transfere tanto para o atendente humano?
Quase sempre porque ele não tem acesso ao estado real do pedido, e não porque o modelo seja fraco. Sem ferramenta que consulte o sistema de atendimento, qualquer pergunta concreta como "onde está minha entrega" só pode terminar em transferência ou invenção. Dar ferramentas de leitura com escopo por cliente autenticado reduz a transferência de verdade; melhorar o prompt só faz o agente transferir com mais elegância.
Fixando
Quiz rápido
Um assistente de compras recomenda produtos esgotados. Onde está o defeito?
Quiz rápido
Numa operação de 15 mil chamadas por dia, por que o escalonamento para humano é desenhado como caminho de primeira classe?
💡
Próximo passo
A próxima família de arquiteturas é **Documento, extração e processamento inteligente** — mesma estrutura: dez soluções, cada uma com o desenho completo e a decisão que ela transfere. Se o que falta é praticar em vez de ler — nenhum destes desenhos tem código, de propósito, porque quem constrói é a trilha 100 Laboratórios de Arquitetura AWS —, comece por um laboratório da família equivalente.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…