HOSTKEY a écrit un pipe pour son bot : Gemma 4 répond en 5–7 secondes, Qwen 3 en 30–40

L'hébergeur HOSTKEY explique pourquoi il n'a pas réussi à construire son bot de support technique Remote Hands Request (RHR, demandes d'intervention physique sur les serveurs) avec les réglages standard d'OpenWebUI. L'équipe a remplacé ces réglages par un pipe, un plugin Python qui intercepte la requête avant son envoi au modèle et lui fait suivre une chaîne d'étapes fixe. Le choix de Gemma 4 tient au temps de réponse : avec le mode réflexion désactivé, elle répond en 5–7 secondes sur un ensemble de deux cartes A4000 de 16 Go.

Sur le même matériel, Qwen 3 réfléchit 30–40 secondes, et Gemma 4 ne lui cède que de très peu en qualité. L'auteur de l'analyse est Alexandre Kazantsev, responsable du service documentation et contenu de HOSTKEY.

Pourquoi les réglages du modèle ne suffisaient pas

Au départ, HOSTKEY pensait qu'un modèle custom reposant sur une base ouverte, avec des outils et une base de connaissances connectés, suffirait pour le bot. À titre d'exemple, l'auteur prend le modèle hostkeyrurhr, fondé sur gemma4:26b-a4b-it-qat. Ses réglages activent Function Calling en mode Legacy, fixent temperature à 0,2 et désactivent la réflexion dans Ollama. Ils connectent aussi la collection de connaissances hostkey_ru, qui couvre la documentation client. Les outils sont status_ru_mcp et docs_url_ru : vérification du fonctionnement du site, d'Invapi et des datacenters en Russie, ainsi que requête MCP sur les configurations de VPS, de serveurs dédiés et sur le trafic réseau.

À la question sur un VPS bon marché en Allemagne, le modèle n'a pas appelé l'outil get_vps_list, qui renvoie la liste des VPS avec leurs prix par localisation. La réponse était plausible, mais elle reprenait les instructions de la documentation au lieu de données issues du système. Le mode Native a aggravé la situation : même le RAG cessait de fonctionner. Lors d'une requête via l'API, par exemple avec CURL, on reçoit un tool_call brut avec un content vide, et c'est au client d'appeler l'outil puis de relancer le modèle. Rien ne garantit que l'outil sera appelé, que les données figureront dans la réponse, qu'elles ne se mélangeront pas au RAG et que la réponse sera en russe.

En mode Legacy, les données des outils sont injectées dans le contexte général, le plus souvent dans le prompt système. Cette méthode fonctionne avec n'importe quel modèle, mais le modèle peut compliquer inutilement l'appel, produire un JSON invalide ou ignorer l'outil. En mode Native, seule la liste des outils est transmise au modèle, via un paramètre d'API dédié. Qwen3 fonctionne bien dans les deux modes, tandis que Gemma 4, même dans sa version it (Instruction-Tuned), exige un traitement spécifique en Native. C'est le pipe qui s'en charge.

Des griefs structurels s'y sont ajoutés :

• Un seul modèle, avec un seul gros prompt système et une seule température, choisit l'action et rédige la réponse.
• L'ordre des appels n'est pas contrôlé, alors qu'il fallait : recherche par mots-clés, puis outils de disponibilité du serveur et MCP Invapi, puis réponse avec RAG.
• Le RAG ne peut pas être désactivé pendant l'appel des outils, si bien que les données se mélangent.
• Il n'y a pas de post-traitement : vérification de la langue, suppression des fins de texte techniques, rejet des réponses bouche-trou et fallback.
• L'utilisateur voit une interface « figée » pendant que plusieurs requêtes vers le LLM et le MCP s'exécutent.

Qu'est-ce qu'un pipe et comment fonctionne hostkeyru_rhr_pipe

Un pipe est une classe Python dotée d'une méthode pipe. Elle reçoit le corps de la requête et renvoie une chaîne, un JSON ou un flux. En interne, elle peut appeler le LLM autant de fois que nécessaire, invoquer des outils MCP, modifier le prompt et activer ou désactiver le RAG.

Dans l'interface d'OpenWebUI, le pipe apparaît comme un modèle à part : on peut lui attribuer des droits et l'appeler via l'API, et dans les clients externes, il suffit de remplacer le nom du modèle custom par celui du pipe. Les pipes se créent dans l'Admin Panel, section Function. HOSTKEY n'utilise pas du tout les Valves, ces paramètres configurables du pipe, stockés en base de données et visibles dans le panneau d'administration : il est plus simple de réécrire les prompts et les valeurs dans le code.

Le pipe hostkeyru_rhr_pipe assure le support en russe. La génération finale part vers le modèle custom hostkeyrurhr, avec RAG activé, mais le pipe effectue toute la préparation en amont. Il reçoit body (messages, modèle, indicateurs, tool_ids, features), tools (dictionnaire des outils MCP disponibles) et __event_emitter__, le canal par lequel les statuts sont envoyés dans le chat. Au lieu d'une barre immobile, l'utilisateur voit défiler un fil : « J'analyse la requête », « J'extrais les mots-clés », « Je cherche dans la documentation », « J'utilise un outil », « Je génère la réponse finale ». Sans ce fil, les utilisateurs quittent souvent le chat sans attendre le résultat.

Le texte de la requête est extrait du dernier message de l'utilisateur par du code, sans réseau de neurones, en tenant compte des messages multimodaux, c'est-à-dire des listes de blocs « texte + image ».

Phase −1 : une cascade de trois niveaux

L'ancien pipe ne vérifiait pas si la demande relevait bien du RHR. « Établissez-moi une facture » et « ssh ne fonctionne pas » recevaient donc la même réponse, et la charge du service qui s'occupe des serveurs augmentait. Le nouveau pipe introduit une cascade où chaque niveau ne s'active que si le précédent n'a pas donné de réponse tranchée.

Niveau 1 : le keyword guard (_keyword_prefilter), en Python pur. Il cherche deux jeux de marqueurs : RHR_KEYWORDS (ssh, перезагруз, raid, сеть, dns, не отвеч) et CLIENT_SOFTWARE_SIGNALS (код сайта, конфиг nginx, wordpress, laravel). Si seules des clés RHR sont trouvées, le résultat est in_scope=True, edge, 0,9. Si seuls des signaux logiciels sont trouvés, c'est in_scope=False, client_software, 0,9. Si les deux jeux sont présents, ou aucun, la fonction renvoie None et la requête passe au niveau suivant.

Niveau 2 : le classificateur LLM (_classify_rhr_scope) sur gemma4nothink, un modèle de base à réflexion désactivée, à température 0. Le prompt intègre le règlement RHR_REGULATION, cinq règles critiques, huit exemples few-shot et un format strict de réponse JSON. En cas d'échec, quel qu'il soit, la fonction renvoie in_scope=True, unknown, 0,0 : le client n'est donc pas écarté.

Niveau 3 : le recheck (_recheck_rhr_scope) protège contre un rejet à tort. Il ne se lance que si la première passe a renvoyé in_scope=False, la catégorie client_software ou unknown, et un confidence situé dans la plage [0,7 ; 0,85]. Il n'y a pas de revérification pour billing, client_area, legal, sales, abuse ni pour edge.

Exemples tirés du tableau de l'auteur : « ssh ne fonctionne pas » se règle au premier niveau ; « je veux me faire rembourser » se règle au deuxième, classé billing avec 0,95, et reçoit un avertissement ; « il se passe un truc bizarre avec le serveur » part en fail-open avec une réponse ordinaire.

Phase 0 : recherche dans la documentation

Une première requête courte part vers gemma4nothink et transforme la question de l'utilisateur en 2–3 mots-clés pour la recherche dans la documentation.