Rafa's Brain · thread 39
terça-feira, 23 de junho de 2026[Rafael Matias] Bro, verifica o que se passa com o default profile do Hermes, o skander, o problema creio que foi ter ficado preso com sub agentes, podes verificar o que se passa e se podes resolver? O Daniel esvia-lhe audios pelo telegram e ele apenas fica em typing... infinito, veriifica o que se passa por favor
Resolvido no **default profile / Skander**. ## O que encontrei Não era principalmente sub-agentes. O bloqueio vinha de duas coisas: 1. **Transcrição de áudio demasiado pesada** - O default profile estava com: - `stt.local.model: large-v3` - `stt.local.device: cuda` - Mas o CUDA falhou: - `cublas64_12.dll is not found` - Hermes caiu para CPU e tentou transcrever um áudio de **559.9s / ~9m20s** com `large-v3`. - Resultado real nos logs: áudio recebido às **12:04**, só terminou a transcrição às **12:40**. Daí o `typing...` infinito. 2. **Background review a competir com turns reais** - O Skander estava a entrar em loops de pós-turno: - `Review the conversation above and upda…
[Rafael Matias] Como podemos fazer com qu isto nunca mais aconteça? Mesmo quando os audios são pesados, para nunca cair para o CPU?
Sim. A forma correta é **fail-closed**, não “tentar ajudar” caindo para CPU. ## Verdade técnica Neste Hermes atual, o `local` STT usa `faster-whisper` e o código tem fallback hardcoded: ```text CUDA falha → retry em CPU int8 ``` Mesmo que no `config.yaml` exista algo tipo `allow_cpu_fallback: false`, pelo que verifiquei o caminho atual de `tools/transcription_tools.py` **não honra esse campo**. Ele tenta `device="auto"` e, se CUDA falhar por libs/driver, força CPU. Portanto, para “nunca mais CPU”, temos 3 níveis. ## Melhor solução prática ### 1. Não usar `local` para o Skander principal Configurar o default/Skander para STT cloud: ```yaml stt: enabled: true provider: groq groq: model: whisper…
[Rafael Matias] ok, boa, agora precisamos de verificar o porquê, do bot responder dezenas de vezes á mensagem, parece que enquanto vai formando a resposta, vai dando automaticamente o output para o usuario, como podemos prevenir isso? Apenas queremos que dê 1 resposta
Sim. Verifiquei e apliquei a prevenção no **default profile / Skander**. ## Causa O profile tinha gateway streaming ativo: ```yaml streaming: enabled: true transport: auto ``` E Telegram também estava explicitamente com streaming: ```yaml display: platforms: telegram: streaming: true ``` Isso faz o bot enviar/editar output enquanto a resposta está a ser formada. Em condições normais devia editar a mesma mensagem, mas no Telegram pode parecer spam / dezenas de mensagens dependendo de overflow, cliente, falhas de edit, ou fluxo de streaming. Como vocês querem **1 única resposta final**, o comportamento certo é desligar streaming e mensagens intermédias. ## O que alterei Backup criado: ``…
[Rafael Matias] bro, quanto aos audios, o bot acabour de responder ao audio, apenas com uma transcrição do audio, em vez de ser a resposta ao audio, verifica denovo o que se passa
Verifiquei. Havia **duas coisas diferentes** a acontecer. ## 1. O “responder só com transcrição” era um echo explícito do Hermes O código do gateway fazia isto por design: 1. recebia áudio 2. transcrevia 3. enviava ao utilizador uma mensagem visível tipo: ```text 🎙️ "transcrição do áudio..." ``` 4. só depois passava a mesma transcrição ao agente para ele responder Isto faz parecer que o bot “respondeu com a transcrição”, mesmo quando a transcrição também está a ser passada ao agente. Encontrei estes caminhos em `gateway/run.py`: - áudio normal - áudio em pending queue - áudio que interrompe uma resposta em curso - áudio drenado após uma resposta Todos tinham envio de `🎙️ "...transcrição..."`. ## O qu…