HOSTKEY escribió un pipe para su bot: Gemma 4 responde en 5–7 segundos; Qwen 3, en 30–40

El proveedor de hosting HOSTKEY explicó por qué no pudo construir su bot de soporte técnico Remote Hands Request (RHR, solicitudes de mantenimiento físico de servidores) con los ajustes estándar de OpenWebUI. El equipo sustituyó esos ajustes por un pipe: un plugin de Python que intercepta la solicitud antes de enviarla al modelo y la lleva por una cadena fija de pasos. La elección de Gemma 4 se explica por el tiempo de respuesta: con el modo de razonamiento desactivado, responde en 5–7 segundos en un conjunto de dos tarjetas gráficas A4000 de 16 GB.

Qwen 3 tarda 30–40 segundos con el mismo hardware, y en calidad Gemma 4 se queda solo ligeramente por detrás. El autor del análisis es Alexander Kazantsev, jefe del departamento de documentación y contenido de HOSTKEY.

Por qué los ajustes del modelo no bastaban

Al principio, en HOSTKEY esperaban que para el bot bastara con un modelo personalizado sobre una base abierta, con herramientas y una base de conocimientos conectadas. Como ejemplo, el autor toma el modelo hostkeyrurhr, basado en gemma4:26b-a4b-it-qat. En sus ajustes están activados Function Calling en modo Legacy y temperature 0,2, el razonamiento en Ollama está desactivado y se ha conectado la colección de conocimientos hostkey_ru con la documentación para clientes. Las herramientas son status_ru_mcp y docs_url_ru: comprobación del funcionamiento del sitio web, de Invapi y de los centros de datos en Rusia, además de una consulta MCP de configuraciones de VPS, servidores dedicados y tráfico de red.

Ante la pregunta sobre un VPS barato en Alemania, el modelo no recurrió a la herramienta get_vps_list, que devuelve una lista de VPS con precios por ubicación. La respuesta resultó verosímil, pero era un resumen de las instrucciones de la documentación, no datos del sistema. El modo Native empeoró el panorama: dejó de funcionar incluso el RAG.

Al hacer la solicitud por API, por ejemplo con CURL, llega un tool_call desnudo con el content vacío, y es el cliente quien debe llamar a la herramienta y volver a consultar al modelo. No hay garantías de que se llame a la herramienta, de que los datos lleguen a la respuesta, de que no se mezclen con el RAG ni de que la respuesta esté en ruso.

En modo Legacy, los datos de las herramientas se mezclan con el contexto general, casi siempre en el prompt del sistema. Este método funciona con cualquier modelo, pero el modelo puede complicar en exceso la llamada, producir un JSON no válido o ignorar la herramienta. En modo Native, al modelo solo se le pasa la lista de herramientas mediante un parámetro especial de la API. Qwen3 funciona bien en ambos modos, mientras que Gemma 4, incluso en la versión it (Instruction-Tuned), requiere un tratamiento especial en Native. De ello se encarga el pipe.

A esto se sumaron objeciones estructurales:

• Un único modelo, con un único prompt de sistema extenso y una sola temperatura, es el que elige la acción y también el que responde.
• El orden de las llamadas no está controlado, y hacía falta este: búsqueda por palabras clave, después las herramientas de disponibilidad del servidor y MCP Invapi, y por último la respuesta con RAG.
• No se puede desactivar el RAG mientras se llama a las herramientas, por lo que los datos se mezclan.
• No hay posprocesamiento: comprobación del idioma, recorte de colas de servicio, descarte de respuestas vacías de relleno y fallback.
• El usuario ve una interfaz «colgada» mientras se ejecutan varias consultas al LLM y a MCP.

Qué es un pipe y cómo funciona hostkeyru_rhr_pipe

Un pipe es una clase de Python con un método pipe. Recibe el cuerpo de la solicitud y devuelve una cadena, un JSON o un flujo. Por dentro, puede llamar al LLM tantas veces como haga falta, invocar herramientas MCP, cambiar el prompt y activar o desactivar el RAG.

En la interfaz de OpenWebUI, el pipe aparece como un modelo independiente: se le pueden asignar permisos y llamarlo por API, y en los clientes externos basta con sustituir el nombre del modelo personalizado por el del pipe. Los pipes se crean en Admin Panel, en la sección Function. HOSTKEY no usa Valves en absoluto (son los parámetros configurables del pipe, que se guardan en la base de datos y son visibles en el panel de administración): resulta más sencillo reescribir los prompts y los valores directamente en el código.

El pipe hostkeyru_rhr_pipe atiende el soporte en ruso. La generación final va al modelo personalizado hostkeyrurhr con el RAG activado, y el pipe hace toda la preparación antes de ese paso. Recibe body (mensajes, modelo, flags, tool_ids, features), tools (un diccionario de las herramientas MCP disponibles) y __event_emitter__, el canal por el que se envían los estados al chat. En lugar de una barra inmóvil, el usuario ve una secuencia de mensajes: «Analizo la solicitud», «Extraigo las palabras clave», «Busco documentación», «Uso una herramienta», «Elaboro la respuesta final». Sin esa secuencia, los usuarios suelen abandonar el chat sin esperar el resultado.

El texto de la solicitud se extrae del último mensaje del usuario mediante código, sin redes neuronales, y teniendo en cuenta los mensajes multimodales, es decir, las listas de bloques «texto + imagen».

Fase −1: una cascada de tres escalones

El pipe anterior no comprobaba si una solicitud era de tipo RHR. Por eso, tanto «emítanme una factura» como «ssh no funciona» recibían la misma respuesta, y crecía la carga del departamento que atiende los servidores. El nuevo pipe incorpora una cascada en la que cada escalón solo se activa si el anterior no ha dado una respuesta inequívoca.

Escalón 1: keyword guard (_keyword_prefilter), en Python puro. Busca dos conjuntos de marcadores: RHR_KEYWORDS (ssh, перезагруз, raid, сеть, dns, не отвеч) y CLIENT_SOFTWARE_SIGNALS (код сайта, конфиг nginx, wordpress, laravel). Si solo se encuentran claves RHR, el resultado es in_scope=True, edge, 0,9. Si solo se encuentran señales de software, el resultado es in_scope=False, client_software, 0,9. Si aparecen ambos conjuntos o ninguno, devuelve None y la solicitud pasa al siguiente escalón.

Escalón 2: clasificador LLM (_classify_rhr_scope) en gemma4nothink, el modelo base con el razonamiento desactivado, a temperatura 0. El prompt incluye integrados el reglamento RHR_REGULATION, cinco reglas críticas, ocho ejemplos few-shot y un formato estricto de respuesta en JSON. Ante cualquier fallo devuelve in_scope=True, unknown, 0,0, es decir, no se descarta al cliente.

Escalón 3: recheck (_recheck_rhr_scope), que protege frente a descartes erróneos. Solo se activa si la primera pasada devolvió in_scope=False, la categoría client_software o unknown, y una confidence dentro del rango [0,7; 0,85]. Para billing, client_area, legal, sales, abuse y edge no hay revisión.

Ejemplos de la tabla del autor: «ssh no funciona» se resuelve en el primer escalón; «quiero que me devuelvan el dinero» se resuelve en el segundo como billing con 0,95 y recibe una advertencia; y «algo raro pasa con el servidor» pasa a fail-open con una respuesta normal.

Fase 0: búsqueda en la documentación

Una primera consulta corta va a gemma4nothink y convierte la pregunta del usuario en 2–3 palabras clave para buscar en la documentación.