HOSTKEY escreveu um pipe para o bot: Gemma 4 responde em 5–7 segundos, Qwen 3 em 30–40

A provedora de hospedagem HOSTKEY explicou por que não conseguiu montar o bot de suporte técnico Remote Hands Request (RHR, solicitações de manutenção física de servidores) com as configurações padrão do OpenWebUI. A equipe substituiu as configurações por um pipe, um plugin em Python que intercepta a requisição antes do envio ao modelo e a conduz por uma cadeia fixa de etapas. A escolha pelo Gemma 4 se explica pelo tempo de resposta: com o modo de raciocínio desativado, ele responde em 5–7 segundos em um conjunto de duas placas de vídeo A4000 de 16 GB.

O Qwen 3, no mesmo hardware, leva 30–40 segundos para pensar, e em qualidade o Gemma 4 fica só um pouco atrás. O autor da análise é Aleksandr Kazantsev, chefe do departamento de documentação e conteúdo da HOSTKEY.

Por que as configurações do modelo não bastaram

No início, a HOSTKEY achava que bastaria um modelo customizado sobre uma base aberta, com ferramentas e base de conhecimento conectadas. Como exemplo, o autor usa o modelo hostkeyrurhr, baseado em gemma4:26b-a4b-it-qat. Nas configurações dele, o Function Calling está ativado no modo Legacy, a temperature é 0,2, o raciocínio no Ollama está desativado e a coleção de conhecimento hostkey_ru, com a documentação para clientes, está conectada. As ferramentas são status_ru_mcp e docs_url_ru: verificação do funcionamento do site, da Invapi e dos data centers na Rússia, além de uma consulta MCP às configurações de VPS, servidores dedicados e tráfego de rede.

Diante da pergunta sobre um VPS barato na Alemanha, o modelo não acionou a ferramenta get_vps_list, que retorna a lista de VPS com preços por localização. A resposta pareceu plausível, mas era apenas um resumo de instruções da documentação, e não dados do sistema. O modo Native piorou o quadro: até o RAG deixou de funcionar. Em uma requisição via API, por exemplo com CURL, chega um tool_call cru com content vazio, e cabe ao cliente chamar a ferramenta e consultar o modelo de novo. Não há garantia de que a ferramenta será chamada, de que os dados entrarão na resposta, de que não se misturarão com o RAG nem de que a resposta virá em russo.

No modo Legacy, os dados das ferramentas são injetados no contexto geral, na maioria dos casos no prompt de sistema. O método funciona com qualquer modelo, mas o modelo pode complicar demais a chamada, gerar um JSON inválido ou ignorar a ferramenta. No modo Native, o modelo recebe apenas a lista de ferramentas, por meio de um parâmetro específico da API. O Qwen3 funciona bem nos dois modos, mas o Gemma 4, mesmo na versão it (Instruction-Tuned), exige tratamento especial no Native. Quem cuida disso é o pipe.

Somaram-se a isso problemas estruturais:

• Um único modelo, com um único prompt de sistema grande e uma única temperatura, escolhe a ação e também responde.
• A ordem das chamadas não é controlada, e a necessária era esta: busca por palavras-chave, depois ferramentas de disponibilidade do servidor e MCP Invapi, e então a resposta com RAG.
• Não é possível desativar o RAG durante a chamada das ferramentas, por isso os dados se misturam.
• Não há pós-processamento: verificação de idioma, remoção de trechos de serviço no final, descarte de respostas-padrão e fallback.
• O usuário vê uma interface “travada” enquanto várias requisições ao LLM e ao MCP são executadas.

O que é um pipe e como funciona o hostkeyru_rhr_pipe

Um pipe é uma classe Python com o método pipe. Ele recebe o corpo da requisição e retorna uma string, um JSON ou um stream. Por dentro, pode chamar o LLM quantas vezes for preciso, acionar ferramentas MCP, alterar o prompt e ativar ou desativar o RAG.

Na interface do OpenWebUI, o pipe aparece como um modelo separado: é possível atribuir permissões a ele e chamá-lo pela API, e em clientes externos basta trocar o nome do modelo customizado pelo nome do pipe. Os pipes são criados no Admin Panel, na seção Function. A HOSTKEY não usa Valves, parâmetros configuráveis do pipe que ficam armazenados no banco de dados e aparecem no painel de administração: é mais simples reescrever prompts e valores no código.

O pipe hostkeyru_rhr_pipe atende o suporte em russo. A geração final vai para o modelo customizado hostkeyrurhr, com RAG ativado, e o pipe faz toda a preparação antes disso. Ele recebe body (mensagens, modelo, flags, tool_ids, features), tools (dicionário das ferramentas MCP disponíveis) e __event_emitter__, o canal pelo qual os status são enviados ao chat. Em vez de uma barra parada, o usuário vê uma sequência de status: “Analisando a solicitação”, “Extraindo palavras-chave”, “Buscando documentação”, “Usando ferramenta”, “Gerando a resposta final”. Sem essa sequência, os usuários costumam sair do chat sem esperar o resultado.

O texto da requisição é extraído da última mensagem do usuário por código, sem redes neurais, e considera também mensagens multimodais, ou seja, listas de blocos “texto + imagem”.

Fase −1: cascata de três camadas

O pipe anterior não tinha a verificação “isto é uma requisição RHR?”. Por isso, “emitam uma fatura para mim” e “o ssh não funciona” recebiam a mesma resposta, e a carga sobre o departamento que cuida dos servidores crescia. O novo pipe ganhou uma cascata em que cada camada seguinte só entra em ação se a anterior não tiver dado uma resposta inequívoca.

Camada 1: keyword guard (_keyword_prefilter) em Python puro. Ele procura dois conjuntos de marcadores: RHR_KEYWORDS (ssh, perezagruz, raid, rede, dns, não responde) e CLIENT_SOFTWARE_SIGNALS (código do site, config do nginx, wordpress, laravel). Se só forem encontradas chaves RHR, o resultado é in_scope=True, edge, 0,9. Se só forem encontrados sinais de software, é in_scope=False, client_software, 0,9. Se houver os dois conjuntos ou nenhum, retorna None e a requisição segue adiante.

Camada 2: classificador LLM (_classify_rhr_scope) no gemma4nothink, o modelo base com raciocínio desativado, com temperature 0. O prompt traz embutidos o regulamento RHR_REGULATION, cinco regras críticas, oito exemplos few-shot e um formato estrito de resposta em JSON. Em qualquer falha, retorna in_scope=True, unknown, 0,0, ou seja, o cliente não é barrado.

Camada 3: recheck (_recheck_rhr_scope), que protege contra bloqueios indevidos. Ele só é acionado se a primeira passagem tiver retornado in_scope=False, a categoria client_software ou unknown, e se a confidence estiver no intervalo [0,7; 0,85]. Para billing, client_area, legal, sales, abuse e edge não há nova checagem.

Exemplos da tabela do autor: “ssh não funciona” é resolvido na primeira camada; “quero meu dinheiro de volta” é resolvido na segunda, como billing com 0,95, e recebe um aviso; já “algo estranho com o servidor” cai no fail-open e recebe uma resposta normal.

Fase 0: busca na documentação

A primeira requisição curta vai para o gemma4nothink e transforma a pergunta do usuário em 2–3 palavras-chave para a busca na documentação.