Nos projetos de IA que desenvolvemos na Soamee, poucas coisas nos surpreendem tanto como a desproporção entre o custo de uma solução e o seu impacto real. Este é o caso de uma feature que custou menos de $30 por mês a implementar e que reduziu os tickets de suporte de um cliente SaaS 40% nas primeiras oito semanas.
Nenhum modelo grande. Nenhuma infraestrutura exótica. Apenas uma ideia simples, bem executada, com o modelo de linguagem adequado para a tarefa.
O Problema: a Equipa de Suporte Afogada em Perguntas Repetidas
Quando o cliente nos contactou, a sua equipa de suporte geria entre 800 e 1.200 tickets por mês. O problema não era a complexidade das consultas, mas o contrário: 60% dos tickets eram variantes das mesmas 30 perguntas.
“Como exporto os meus dados?”, “Posso mudar de plano a partir do painel?”, “Porque não recebi o e-mail de confirmação?”. Perguntas que qualquer pessoa que lesse a documentação poderia responder em dois minutos. Mas os utilizadores preferiam abrir um ticket em vez de procurar a resposta.
O custo direto era evidente: horas de agentes a responder perguntas cuja resposta já estava escrita. Mas o custo indireto era pior: os tickets complexos — os que realmente precisavam de intervenção humana — demoravam mais a receber atenção porque a fila estava bloqueada por perguntas simples.
A solução mais óbvia teria sido contratar mais agentes. Mas a equipa era pequena, o orçamento limitado, e escalar suporte humano não resolve o problema de fundo: a fricção entre o utilizador e a documentação existente.
A Ideia: E Se Simplesmente Respondêssemos às Fáceis?
O insight chave foi este: não precisamos de um agente de IA sofisticado. Precisamos de algo que leia as FAQs existentes e seja capaz de responder em linguagem natural quando um utilizador pergunta o mesmo com outras palavras.
RAG básico. Modelo pequeno e barato. Fallback para humano quando a confiança é baixa. Nada mais.
A tentação nestes projetos é sobre-engenheirar a solução. Adicionar memória conversacional, integrar o CRM, construir um agente multi-passo com acesso a APIs internas. Tudo isso pode fazer sentido em fases posteriores. Mas na fase zero, a pergunta correta é: qual é a feature mínima que resolve 80% do problema?
Neste caso, a resposta era clara: um auto-respondedor de FAQs baseado em pesquisa semântica e um LLM de baixo custo.
A Arquitetura: Simples por Design
O sistema que construímos tem quatro componentes e pode ser desenhado num guardanapo:
1. Base de Conhecimento Indexada
Pegámos nos 47 artigos da base de conhecimento existente do cliente (em formato Markdown) e processámo-los com um script de ingestão. Cada artigo é dividido em fragmentos de ~500 tokens com sobreposição de 50 tokens para preservar o contexto entre parágrafos. Cada fragmento é convertido num vetor de embeddings usando o modelo text-embedding-3-small da OpenAI (custo: $0,00002 por 1.000 tokens; a ingestão completa custou menos de $0,05).
Os vetores são armazenados numa base de dados vetorial leve (usámos Qdrant em instância própria, embora o Supabase com pgvector funcione igualmente bem para este volume).
2. Endpoint de Pesquisa Semântica
Quando um utilizador escreve uma consulta no widget de suporte, antes de abrir um ticket, o texto passa pelo nosso endpoint. É convertido em embedding, os 3 fragmentos mais relevantes são recuperados por similaridade de cosseno, e é construído um prompt com:
- A consulta original do utilizador
- Os 3 fragmentos de documentação recuperados
- Uma instrução de sistema que pede uma resposta concisa, no tom da marca, com a instrução explícita de não inventar informação não presente no contexto
3. LLM de Baixo Custo com Caching
O prompt resultante vai para Claude Haiku (ou GPT-4o-mini, conforme preferência). Estes modelos custam ~$0,001 por 1.000 tokens de entrada e ~$0,002 por 1.000 tokens de saída. Um prompt típico tem 600-800 tokens de entrada e gera 150-250 tokens de saída. O custo por consulta é de aproximadamente $0,0015-$0,0025.
O caching semântico é o elemento que mais reduz o custo em produção. Para as consultas mais frequentes (que representam 35-40% do volume total), o sistema devolve a resposta em cache sem chamar o LLM. O custo efetivo dessas consultas é virtualmente zero.
4. Lógica de Fallback
O sistema inclui um score de confiança baseado na pontuação de similaridade do resultado mais próximo. Se o fragmento mais relevante tiver uma similaridade inferior a 0,72 (limiar calibrado durante as primeiras semanas), o sistema não responde automaticamente. Em vez disso, mostra ao utilizador a documentação mais relevante encontrada e oferece a opção de abrir um ticket, com o contexto da pesquisa pré-preenchido para o agente.
Isto garante que o sistema só responde quando tem base para o fazer. A taxa de alucinações observada em produção foi inferior a 0,5%.
O Breakdown de Custos: $0,002 por Consulta
A tabela seguinte mostra o custo mensal real do sistema em produção, com um volume de ~1.000 consultas por mês:
| Componente | Detalhe | Custo/mês |
|---|---|---|
| Embeddings de consultas | 1.000 queries × ~300 tokens | ~$0,006 |
| LLM (Claude Haiku) | 600 consultas sem cache × ~1.000 tokens | ~$1,20 |
| Base de dados vetorial | Qdrant cloud (tier básico) | $10,00 |
| Servidor/API | Função serverless (AWS Lambda) | ~$2,00 |
| Re-ingestão semanal de docs | Atualização de conteúdo | ~$0,10 |
| Total | ~$13-15/mês |
Com caching ativado para as consultas mais frequentes, o custo efetivo por consulta resolvida é de $0,002. Para as consultas em cache, o custo é de $0,00.
O que antes custava horas de tempo de agente agora custa menos que um café.
Os Resultados: Oito Semanas Depois
Antes do sistema, a equipa processava uma média de 950 tickets por mês. Oito semanas após o deployment:
Redução de tickets: -40%
O sistema resolveu de forma autónoma 40% das consultas que antes geravam tickets. Não as desviou, não as ignorou: respondeu-lhes de forma satisfatória sem intervenção humana.
Tempo de resposta: média de 3 segundos
O tempo de resposta do sistema é praticamente instantâneo da perspetiva do utilizador. Comparado com o tempo de espera anterior (que podia ser de 4-24 horas conforme a carga da equipa), a melhoria percebida foi significativa.
Satisfação: 92% de avaliações positivas
Implementámos uma micro-avaliação no final de cada resposta automática (polegar para cima / polegar para baixo). 92% das respostas automáticas receberam avaliação positiva. Os restantes 8% resultaram em ticket com contexto pré-preenchido.
Tickets complexos com mais atenção
Com 40% menos de carga na fila, os agentes puderam dedicar mais tempo aos tickets que realmente precisavam. O tempo médio de resolução de tickets complexos reduziu de 18 horas para 11 horas.
O Que Nos Surpreendeu: Os Utilizadores Preferem IA para Perguntas Simples
O resultado mais inesperado não foi quantitativo mas qualitativo. Nas primeiras semanas, recebemos feedback anedótico de utilizadores que diziam preferir a resposta automática a esperar por um agente para perguntas simples.
A razão é intuitiva quando se pensa: se sabes que a tua pergunta é simples, a fricção de esperar resposta humana (por mínima que seja) parece desproporcional. Uma resposta instantânea, mesmo que de uma IA, elimina essa fricção.
Isto também nos ensinou algo sobre o design destes sistemas: a transparência importa. O widget indicava claramente “Resposta automática baseada na nossa documentação.” Não tentava passar por humano. E isso, longe de gerar desconfiança, gerou confiança: os utilizadores sabiam exatamente o que estavam a receber e porquê.
O Que Não Funcionou: Os Limites do Sistema
A honestidade é parte do design. Este sistema tem limites claros e é importante reconhecê-los.
Incidências técnicas complexas
Quando um utilizador reporta um erro com passos específicos de reprodução, logs de erro ou comportamentos inesperados, o sistema RAG não pode ajudar. A documentação não contém esse nível de especificidade. Estes casos vão sempre para agente humano, e devem fazê-lo.
Reclamações e situações emocionais
Um utilizador frustrado que há dias tem um problema não quer uma resposta da documentação. Quer sentir-se ouvido. O sistema deteta padrões de frustração no texto (palavras como “inaceitável”, “há semanas que espero”, “quero cancelar”) e escala diretamente para humano, sem tentar responder com documentação.
Perguntas que implicam contexto de conta
“Quantos utilizadores posso adicionar no meu plano atual?” parece uma pergunta de FAQ mas requer conhecer o plano específico do utilizador. Sem acesso ao CRM, o sistema responde com a informação genérica de planos e recomenda verificar nas configurações de conta. Na fase dois do projeto, está previsto adicionar um token de sessão que permita ao sistema conhecer o plano ativo do utilizador.
Onboarding de novos fluxos
Quando o produto lança uma nova feature, há um período de 1-2 semanas até a documentação estar atualizada e re-ingerida. Durante esse período, as perguntas sobre a nova feature vão para agente. É o único “lag” estrutural do sistema.
A Matemática: $30 por Mês vs. O Que Custa o Tempo de um Agente
Vamos pôr os números em perspetiva. Um agente de suporte dedicado numa empresa SaaS típica custa à empresa aproximadamente $3.000-4.000 por mês com todos os encargos. A sua capacidade de gestão de tickets, assumindo que dedica 70% do seu tempo a responder consultas, é de cerca de 400-600 tickets por mês.
O sistema de IA resolveu 380 tickets por mês (40% de 950) a um custo de $15. Se esses tickets tivessem sido geridos por um agente humano, teriam representado 65-95% da sua capacidade mensal.
Não estamos a dizer que a IA substitui o agente. Estamos a dizer que liberta o agente para fazer o trabalho que só um humano pode fazer bem.
O ROI neste caso foi de vários ordens de grandeza. E o investimento inicial de implementação foi recuperado nas primeiras duas semanas de operação.
Como Replicar Isto no Seu Produto
Se tem um SaaS com uma base de conhecimento existente e um volume de suporte que começa a ser um fardo, este é o caminho mais direto:
Semana 1: Audite os seus tickets dos últimos 3 meses. Classifique as consultas por categoria. Se 40-60% são perguntas cuja resposta já existe na sua documentação, tem um caso de uso claro.
Semana 2: Ingestão de documentação. Converta os seus artigos para Markdown se ainda não o estiverem, divida-os em fragmentos, gere embeddings. Este processo é técnico mas não complexo.
Semana 3: Construa o endpoint mínimo. Pesquisa semântica + prompt + LLM + lógica de fallback. Não adicione mais funcionalidade até isto funcionar.
Semana 4: Faça o deploy em modo shadow (a IA gera respostas mas um humano revê-as antes de enviar). Calibre o limiar de confiança. Ajuste o prompt com base nos erros que observar.
Semanas 5-8: Ative o modo autónomo para as categorias com maior confiança. Monitorize a taxa de satisfação. Itere.
O princípio subjacente é sempre o mesmo: comece pequeno, meça tudo, itere sobre dados reais.
Conclusão: A IA Não Tem de Ser Cara para Ser Útil
A narrativa dominante sobre IA nas empresas tende a girar em torno de grandes transformações, plataformas complexas e orçamentos de seis dígitos. Mas alguns dos impactos mais significativos que vimos nos nossos projetos vêm de features pequenas, bem definidas, que resolvem um problema concreto com tecnologia modesta.
$0,002 por consulta. $15 por mês. 40% menos tickets. 92% de satisfação.
Esses números não são excecionais porque a tecnologia é sofisticada. São excecionais porque a tecnologia é a adequada para o problema.
Se a sua equipa de suporte dedica tempo a responder perguntas que já estão respondidas na sua documentação, tem um problema que a IA pode resolver hoje, com modelos disponíveis publicamente, a um custo que não precisa de justificação executiva.
Na Soamee trabalhamos exatamente este tipo de projetos: soluções de IA práticas que geram impacto mensurável sem infraestrutura desnecessária. Se quiser explorar se algo assim faz sentido para o seu produto, conte-nos o contexto.