Como construir uma recepcionista de IA para uma oficina de carros de luxo - Parte 1

• Para resolver a perda de receita causada por chamadas não atendidas em uma oficina premium, foi desenvolvida a recepcionista de IA ‘Axle’, capaz de atender ligações reais
• A IA foi construída com base em Retrieval-Augmented Generation (RAG), fornecendo respostas precisas com base em informações reais de serviços e preços coletadas do site
• Integrando Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas e outros, foram implementados conexão telefônica, reconhecimento e síntese de voz, e armazenamento do histórico de conversas
• A qualidade da voz foi ajustada com tom natural e estrutura de frases curtas, oferecendo respostas amigáveis e profissionais aos clientes
• No futuro, a solução deve ser expandida com sistema de agendamento, alertas por SMS e dashboard de callbacks; para agentes de voz especializados em negócios, base de conhecimento e design de escalonamento são essenciais

---

Processo de construção da recepcionista de IA

• Foi criada uma recepcionista de IA personalizada, ‘Axle’, para resolver o problema do irmão da autora, que administra uma oficina automotiva de alto padrão e perdia milhares de dólares por mês por não conseguir atender chamadas
• Em vez de um simples chatbot, ela foi projetada como um agente baseado em voz capaz de atender telefonemas reais e responder a dúvidas de clientes com base em informações reais, como preços, horário de funcionamento e políticas
• O projeto foi dividido em três etapas: construção da base de conhecimento (pipeline RAG) → conexão telefônica e integração com servidor → ajuste da qualidade da voz e do tom da conversa

Etapa 1: Construindo o cérebro (pipeline RAG)

• Foi usada a abordagem Retrieval-Augmented Generation (RAG) para que a IA respondesse com base em dados reais
  • Como o uso de um LLM puro traz risco de alucinação (hallucination), como informar preços incorretos, as respostas foram limitadas a informações reais
• Por meio de scraping dos dados do site, foram coletados mais de 21 documentos, incluindo tipos de serviço, preços, tempo estimado, horário de funcionamento, formas de pagamento, garantia e política de carro reserva
• A base de conhecimento foi armazenada no MongoDB Atlas, e embeddings vetoriais de 1024 dimensões foram gerados com o modelo Voyage AI (voyage-3-large)
  • A busca semântica foi realizada por meio do índice Atlas Vector Search
• Quando chega uma pergunta do cliente, a consulta é convertida com o mesmo modelo de embeddings para buscar os 3 documentos semanticamente mais semelhantes
• O modelo Anthropic Claude (claude-sonnet-4-6) foi usado para gerar a resposta com base nos documentos recuperados
  • O prompt de sistema inclui regras como “não usar informações fora da base de conhecimento, manter a resposta concisa e conversacional e, se não souber, sugerir callback”
• Como resultado, no terminal já era possível responder com precisão a perguntas como “Qual é o custo da troca de óleo?”, com preços e detalhes reais do serviço

Etapa 2: Conectando a um número de telefone real

• Para conectar o cérebro da IA a um sistema telefônico real, foi usada a plataforma Vapi
  • Ela oferece compra de número de telefone, reconhecimento de voz com Deepgram, síntese de voz com ElevenLabs e chamadas de função em tempo real
• Foi criado um servidor de webhook com FastAPI
  • O Vapi envia as perguntas dos clientes para o endpoint /webhook como requisições tool-calls
  • O servidor encaminha isso ao pipeline RAG, recebe a resposta do Claude e a envia de volta ao Vapi
  • Foi necessário minimizar a latência para manter uma velocidade de conversa natural
• Com Ngrok, o servidor local foi exposto por meio de uma URL HTTPS externa, permitindo testes em tempo real durante o desenvolvimento

• Configuração do assistente no Vapi

  • A saudação e duas ferramentas (answerQuestion, saveCallback) foram conectadas ao webhook
  • O sistema responde às perguntas ou, caso não saiba, coleta nome e telefone para registrar um callback
  • O recurso de memória de conversa mantém o contexto dos diálogos anteriores
  • Assim, ele consegue lidar com perguntas encadeadas como “Qual é o horário de funcionamento?” → “Então quanto custa trocar os pneus?”

• Armazenamento dos logs de chamadas no MongoDB

  • São registrados número de origem, pergunta, resposta, se houve encaminhamento para atendimento humano e timestamp
  • Solicitações de callback são armazenadas separadamente na coleção callbacks, permitindo contato posterior
  • Isso torna possível analisar padrões de dúvidas dos clientes e volume de chamadas

Etapa 3: Ajustando a qualidade da voz

• Considerando a diferença entre respostas em texto e respostas por voz, foi necessário otimizar a entrega para voz
  • Frases que parecem naturais por escrito podem soar artificiais quando faladas

• Escolha da voz no ElevenLabs

  • Após testar cerca de 20 vozes, a voz ‘Christopher’ foi a que soou mais natural e mais adequada ao ambiente da oficina
  • Vozes excessivamente robóticas ou exageradamente alegres não funcionaram bem

• Ajustes no prompt de sistema

  • Frases curtas, remoção de Markdown e eliminação de expressões desnecessárias como “Ótima pergunta!”
  • Os preços são pronunciados em linguagem natural (“forty-five dollars”)
  • As respostas foram limitadas a 2–4 frases
  • O objetivo era implementar uma voz humana amigável e profissional

• Teste do fluxo de escalonamento (callback)

  • Quando a pergunta não está na base de conhecimento, a IA diz que não sabe, pede nome e número e armazena isso no MongoDB
  • Depois, o dono da oficina pode fazer o contato de acompanhamento pessoalmente

• Criação de testes de integração

  • Foram validados o pipeline RAG, o processamento do webhook e o fluxo completo
  • Também foram incluídos casos de borda, como requisições inválidas, ausência de resultados na busca e número de callback ausente

Composição da stack técnica

• Vapi (integração com Deepgram & ElevenLabs) — número de telefone, reconhecimento de voz, síntese de voz e chamadas de função
• Ngrok — túnel HTTPS para desenvolvimento local
• FastAPI + Uvicorn — servidor de webhook
• MongoDB Atlas — base de conhecimento, busca vetorial, logs de chamadas e fila de callbacks
• Voyage AI (voyage-3-large) — embeddings de texto para busca semântica
• Anthropic Claude (claude-sonnet-4-6) — geração de respostas com base na base de conhecimento
• Python — com pymongo, voyageai, anthropic, fastapi
• Copilot CLI — ferramenta de automação de build

Próximos passos

• Atualmente, a IA já concluiu as funções de resposta a perguntas e coleta de callbacks
• Os próximos objetivos são integração com calendário para agendamentos em tempo real, alertas por SMS, dashboard de gerenciamento de callbacks, reforço de segurança e deploy no Railway
• Quando estiver completa, poderá operar 24 horas por dia e evitar perda de receita por chamadas não atendidas
• A parte mais difícil não foi o código, mas sim implementar um tom de voz adequado para a oficina
• Lição principal: não use um LLM bruto diretamente em agentes de voz especializados para negócios
  • É indispensável baseá-lo em uma base de conhecimento real e projetar o fluxo de resposta quando ele não souber (escalonamento)
  • Isso não é exceção, e sim uma funcionalidade central

[GN⁺]

Comentários do Hacker News

• Já trabalhei como consultor de serviços (responsável pelo atendimento/recepção). O sistema descrito no artigo provavelmente não funcionaria na prática

  1. Se não houver histórico de reparo igual, a chance de o orçamento estar errado é alta. Em alguns estados, um orçamento incorreto pode até gerar problemas legais
  2. O estoque e os preços das peças mudam o tempo todo. Se o sistema não refletir isso, só vai causar confusão
  3. Trabalhos novos já são complexos desde a escolha das peças. Quanto mais premium o carro, mais complicado fica
  4. A parte útil seria algo como notificações de retirada do veículo. Ou seja, avisar automaticamente quando estiver pronto ou atualizar o andamento
     Esse tipo de desenvolvimento vai além de simples arrogância e chega a ser perigoso. Se for feito com base em suposições sem validação, coloca o sustento de outras pessoas em risco
  • Também não sou especialista, mas concordo com essa pose. Se precisa de recepcionista, o natural é contratar uma pessoa. É difícil entender entregar o negócio a uma solução de IA não validada. Não sei se é só por não querer gerenciar gente ou por seguir modinha
  • Na verdade existe uma solução mais simples. Basta permitir que quem está trabalhando embaixo do carro atenda o telefone com um speakerphone hands-free. Se usar um modelo local de reconhecimento de voz, ainda dá para mencionar tecnologia de rede neural, e o custo fica em algo como 200 a 300 dólares com microfone incluído
  • Mas, vendo o texto original, essa oficina já tem serviços fixos e tabela de preços. Então, a menos que seja um caso de orçamento personalizado, os problemas acima não se aplicam
  • Chamar isso de “perigoso” parece exagero. O desenvolvedor está ajudando o negócio do irmão, e mesmo sem perfeição, se a conversão de clientes subir só 10% já vale muito a pena
  • Notificações de carro pronto ou atualizações de andamento já eram possíveis com sistemas de TTS há anos. Não precisa necessariamente de LLM

• A concessionária Subaru da minha região permite escolher um assistente de IA ao marcar serviço por telefone. Usei e funcionou com mais precisão e rapidez do que uma pessoa. O sistema de pedidos por IA da Taco Bell também foi excelente. Nesses casos, não faz diferença não falar com um humano, e se precisar sempre dá para transferir para uma pessoa

• Esse tipo de post de blog conta só metade da história. Fico curioso para saber se a receita realmente aumentou, se os clientes se importaram por ser um bot e se houve casos de falha

  • Na verdade, esse problema já podia ser resolvido antes da IA com serviços de assistente virtual. Por 200 a 1000 dólares por mês já daria conta, e você só estaria recuperando receita que já estava perdendo. IA é apenas uma ratoeira mais complexa, e num serviço premium o atendimento humano passa muito mais confiança
  • Provavelmente isso ainda não foi testado em produção o suficiente. Coisas como endereço de e-mail são difíceis para um LLM transcrever com precisão. Em resposta de voz em tempo real, a Anthropic foi lenta, enquanto a Groq ficou muito rápida, abaixo de 200 ms
  • Uma vez eu precisava trocar o vidro do carro com urgência, mas o sistema automático de voz insistia em pedir informações desnecessárias, então desliguei. Para um agendamento simples pode servir, mas em situações especiais no fim você precisa falar com uma pessoa
  • Esse tipo de tentativa é razoável. Só que o desempenho real ainda é uma incógnita. Parece um teste de tornassol que separa otimistas e pessimistas da IA

• Hoje em dia vejo de forma bastante positiva os assistentes telefônicos baseados em LLM. Quando liguei para o suporte da Mint Mobile, o LLM entendeu tudo com naturalidade e resolveu meu problema em 1 minuto. Antes isso teria significado mais de 20 minutos de espera

  • O LLM tem pronúncia clara, não sofre com ruído de headset e é fácil de entender. Claro, há casos horrorosos como o chatbot com LLM do eBay, mas um sistema bem implementado funciona muito bem
  • O suporte por chat da Amazon é parecido. O LLM organiza as informações do pedido antes, e a pessoa só faz a aprovação final. É eficiente
  • Ainda assim, fico me perguntando por que isso não pode ser resolvido pelo app, em vez de precisar usar um LLM. No fim parece uma falha do processo de desenvolvimento
  • Tive uma experiência parecida. Fiz uma pergunta técnica, o LLM respondeu corretamente, e depois um atendente humano assumiu, mas acabou sendo menos especializado. Mesmo assim economizou tempo
  • É muito melhor do que os robôs antigos, e chatbots com RAG já são úteis a ponto de substituir busca em documentação. Por exemplo, o chatbot do manager.io respondia direto em vez de me mandar para a documentação, e isso foi conveniente

• Segundo o texto, a oficina está perdendo milhares de dólares por mês por não conseguir atender o telefone. Se for assim, contratar uma recepcionista terceirizada por algo em torno de 500 dólares por mês teria um ROI muito melhor

  • Na verdade, só uma caixa postal de voz já resolveria parte do problema. Seja IA ou caixa postal, alguns clientes vão desligar de qualquer jeito
  • Além disso, se já há trabalho demais a ponto de não conseguirem atender o telefone, é bem provável que também não tenham capacidade de absorver mais clientes
  • Um amigo meu usa um serviço terceirizado de recepção, que cobre das 9h às 17h por 150 libras por mês. Ele só reorganiza a agenda à noite. Se o que o texto diz for verdade, a oficina já deve estar operando a 100% da capacidade
  • Um bom service writer é caro, mas vale o preço. Ele inspira confiança no cliente e depois pode até acabar assumindo o negócio
  • No fim, esse ROI parece mais um efeito publicitário do curso de IA que o blog está tentando promover

• Hoje em dia, se percebo que é atendimento de robô, desligo na hora. Mas logo a voz de IA deve chegar a um ponto em que não dá para distinguir de uma pessoa. Quando isso acontecer, a confiança nas ligações pode desmoronar. E-mail e LinkedIn já estão inundados de spam de IA, então muita gente migrou para o telefone, mas isso também pode acabar em breve

  • Ainda assim, se for cair na caixa postal eu provavelmente desligaria do mesmo jeito, então não há grande prejuízo
  • Se a IA entende errado o que eu digo e no fim me transfere para uma pessoa, eu preciso contar a mesma história duas vezes, o que é cansativo
  • Recentemente, pesquisando carros, entrei em contato com várias concessionárias e só depois percebi que todos eram atendentes com nomes falsos baseados em LLM. A velocidade de resposta era rápida demais e parecia estranha

• Disseram que “isso não é um chatbot genérico”, mas na prática não passa de um chatbot genérico modelo 2026

• Vi a página “About” do blog e lá diz que o autor se inspirou em um influenciador que ficou rico aprendendo a programar. Mas esse tipo de postura está bem longe da cultura de engenharia que eu gostaria de ver

• Fico um pouco triste com as pessoas usando IA para escrever blogs pessoais

  • Ainda assim, vejo com bons olhos o fato de ele ter sido honesto sobre isso. A maioria das pessoas não tem muita experiência com escrita e acha que consegue um “texto bem escrito” usando LLM. Para elas, talvez um texto escrito por IA nem pareça ruim

• Será que RAG é realmente necessário aqui? Se for só tabela de preços e horário de funcionamento, tudo isso cabe tranquilamente na janela de contexto

  • Provavelmente era um projeto com fins de aprendizado. Eu mesmo às vezes uso uma arquitetura exagerada em projetos pessoais para aprender
  • Em conversas por voz, o problema maior é a latência. Se o site tiver várias páginas, pode fazer sentido usar RAG para buscar rapidamente só uma parte e deixar o LLM formular a resposta detalhada
  • Seria mais simples simplesmente colocar o site inteiro e a tabela de preços no contexto
  • Também concordo. Esse volume de informação dá para processar de uma vez sem problema
  • No geral, essa arquitetura é exagerada