Assistente de voz local: stack completa validada em casa primeiro

Quando alguém pergunta "como vocês estão construindo o assistente de voz da Eleva?", a resposta honesta é: ainda não estamos. Estamos testando a stack no PC do fundador. O que vai para o mercado — quando for — já vai ter rodado por meses em uso real. Este post é o registro do estado técnico em abril de 2026.

Princípio 1 da Labs aplicado

Não comercializar nada que não tenha rodado internamente primeiro. Para este projeto específico (assistente de voz residencial privado), isso significa 4 fases sequenciais:

1. Fase 1 — Pessoal local no PC do fundador. 91% técnico concluído em 22/abr.
2. Fase 2 — Ponte para a casa via Raspberry Pi + Home Assistant. Hardware adquirido, deploy em sequência.
3. Fase 3 — Casa inteligente com estratégia híbrida de dispositivos (Voice PE + ESP32-S3-BOX-3 + Atom Echo por cômodo). Uso pessoal + prototipagem da oferta comercial.
4. Fase 4 — Linha comercial dual pela Eleva Smart (Premium + Maker + Showroom interno). Só ativa quando as 3 anteriores tiverem sido validadas por uso real.

Nenhuma menção pública comercial foi feita ainda. Este post é técnico-interno, no canal Labs. A página institucional da Eleva tem teaser editorial sem revelar stack.

Por que não Alexa, Google ou Siri

Nenhuma crítica. As três fazem o que se propõem fazer. O problema é outro: elas não resolvem a pergunta que cresce na base de clientes de automação residencial de alto padrão — quem escuta quando você fala com a sua casa?

Quem usa Alexa/Google/Siri aceita um trade-off: conveniência em troca de áudio transitando para servidores de empresas estrangeiras, processamento na nuvem, dados de rotina alimentando sistemas que o morador não controla. Para uma parcela do mercado — a parcela com perfil técnico ou com preocupação regulatória — esse trade-off deixou de ser aceitável.

A gente queria saber se é possível fazer diferente com hardware e software que já existem abertamente. Sem patente proprietária, sem stack fechada, sem dependência de nenhuma big tech específica.

Stack escolhida para Fase 1

Decidimos por componentes com contrato aberto e comunidade ativa. A ausência de qualquer item dessa lista não quebra o projeto — eles são substituíveis entre si.

O benchmark que decidiu o padrão

Rodamos a mesma pergunta em 5 modelos locais — "quando um imóvel comercial precisa de AVCB?" — que é uma pergunta trivial para qualquer engenheiro brasileiro que trabalha com prevenção de incêndio. É exatamente o tipo de pergunta que um assistente de voz rodando em casa precisa acertar.

Dos 5 modelos:

• qwen2.5:14b — ÚNICO correto. Identificou AVCB como "Auto de Vistoria do Corpo de Bombeiros", explicou obrigatoriedade e propósito.
• qwen2.5:7b — parcialmente correto. Acertou o contexto geral mas subestimou a obrigatoriedade como regra.
• llama3.1:8b — alucinou. Inventou que AVCB é "Avaliação de Valor de Construção".
• llama3.2:3b — alucinou. Inventou "Avance Comercializado pela Bolsa (ACVB)".
• mistral:latest — alucinou. Confundiu com crédito imobiliário.

Conclusão operacional: qwen2.5:14b é o padrão absoluto quando a pergunta envolve domínio técnico brasileiro (norma ABNT, regulamentação, siglas do ecossistema). Fallback para modelos mais rápidos só em tarefas sem necessidade de fato brasileiro (reformular texto, traduzir, classificar). Decisão documentada, regra escrita. Não negociamos.

Arquitetura dos 4 workspaces isolados

A regra de independência das marcas Talvera (princípio D2 da arquitetura) vira desenho técnico concreto. Cada marca tem workspace próprio, com documentos próprios, system prompt próprio e, no caso dos modelos Ollama customizados, layer próprio com parâmetros de inferência calibrados pelo tom da marca:

• Talvera Holding — 8 docs (identidade, política IA, governança, plano estratégico). System prompt de chief of staff. Temperature 0.35.
• Previne Incêndio — 44 docs (POPs operacionais, comercial, marketing, financeiro, landings). System prompt institucional técnico. Temperature 0.30.
• Eleva Smart — 26 docs (catálogo, parceiros B2B, sistema CRM, operação). System prompt consultivo aspiracional sem emoji. Temperature 0.50.
• Veritas Perícias — 26 docs (POPs periciais, NBR 14.653, calculadora MCDDM). System prompt formal pericial com privacidade vinculante. Temperature 0.25.

Total: 104 documentos curados, embedados em LanceDB. Quando o fundador pergunta algo em Previne Incêndio, a recuperação vetorial só busca nos 44 docs da Previne. Zero vazamento entre contextos.

Os 4 modelos customizados Ollama

Paralelo ao AnythingLLM, criamos 4 modelos Ollama customizados — cada um com o system prompt embutido no próprio modelo. São úteis em 3 casos:

1. Fallback — se o AnythingLLM não estiver aberto, o fundador digita ollama run previne-incendio "..." direto no terminal.
2. Integração com HA (Fase 2) — o Home Assistant vai consumir esses modelos via API Ollama em 192.168.50.52:11434, sem precisar do AnythingLLM no meio.
3. Scripts e N8N — automações que geram rascunhos via API sem interface humana.

Os Modelfiles ficam versionados junto com o projeto. Quando o system prompt de um workspace muda, o Modelfile correspondente é regenerado com um único comando. Idempotência total.

Resultado da Fase 1 até aqui

Validação automatizada das 12 perguntas-teste (3 por workspace) — feita sem RAG, só com system prompt embutido nos modelos Ollama customizados — passou em 11 de 12 (91,7%). A única ressalva foi heurística (uma keyword esperada não apareceu exatamente como a regra procurava; a resposta em si estava correta).

Com RAG ativo no AnythingLLM, a taxa esperada é próxima de 100% — a recuperação dos chunks dos documentos corretos vai preencher os gaps de conhecimento factual específico.

O que ficou pendente do lado humano:

• Instalar AnythingLLM Desktop (não conseguimos automatizar — as URLs diretas do instalador estão protegidas por tracking).
• Configurar o wizard inicial (5 telas, 5 minutos).
• Criar os 4 workspaces (temos script que faz em 3 minutos via API, com instruções prontas).
• Teste de voz end-to-end (microfone → pergunta → resposta falada).
• Assinar a ata formal de fechamento.

Próxima fase: casa

Hardware adquirido. Raspberry Pi 4 8GB aguardando ligamento. Quando ligar, o HA do Raspberry vira cérebro de voz no ambiente físico, consumindo o Ollama do PC pela LAN. Wyoming Whisper e Wyoming Piper cuidam de STT/TTS locais. Pipeline pronto para a primeira instalação de Voice PE oficial no momento em que a curva de uso justificar o investimento.

Documentação detalhada da Fase 2 está pronta e aguarda o Raspberry ser ligado — workspaces/FASE_2_RaspberryPi_HomeAssistant.md no repositório interno do projeto.

Sobre o nome

Internamente o projeto chama "Assistente IA" ou "Projeto Assistente de Voz". O nome comercial eventual — se a Fase 3 validar uso real — ainda não está definido.

E não vai ser definido antes de três coisas acontecerem: busca de disponibilidade no INPI, consulta com advogado especialista em propriedade intelectual, mapeamento de patentes ativas de concorrentes diretos (há pelo menos um relevante nos EUA — não é novidade global). Essas três tarefas estão no backlog como bloqueio formal antes de qualquer comunicação pública com nome comercial.

O que isso tem a ver com o que a Labs publica

Tem tudo a ver com o método. Em vez de escrever «a Labs vai lançar um assistente de voz revolucionário», escrevemos que estamos testando em casa, com stack aberta, a partir de componentes que qualquer pessoa tecnicamente competente consegue reproduzir.

Quando o assunto virar produto, o post vai ser diferente — mais sobre pacote, mais sobre ticket, mais sobre canal. Por agora, este é o registro técnico. Arquivado, datado, revisitável. É assim que vamos fazendo.