Un asistente RAG sobre WebGPU, del CMS al navegador.

WebGPU permite al navegador utilizar la GPU para calcular. Aquí realiza la inferencia: aplicar los pesos de un modelo para producir un embedding o generar texto. Esta ejecución local evita llamar a una API de generación alojada para cada respuesta. Requiere un navegador, controladores y recursos GPU compatibles, en una página HTTPS.

La existencia de navigator.gpu no basta. La aplicación comprueba el adaptador físico y rechaza un adaptador de software alternativo. Los ensayos reales utilizaron la Adreno 830 del Samsung Galaxy S25 Ultra en Samsung Internet y una GPU NVIDIA Ampere en ordenador. Las capacidades y los límites de buffers varían: la marca del navegador o la memoria total del teléfono no garantizan que un formato funcione.

Gemma 4 E2B utiliza LiteRT-LM, con @litert-lm/core fijado en 0.17.1, backend GPU_ARTISAN explícito, contexto de 4.096 tokens y thinking desactivado. La API Web LiteRT-LM sigue siendo una versión preliminar, validada aquí en los dispositivos probados. Los embeddings E5 siguen otra ruta: ONNX Runtime Web con WebGPU. Antes de esta elección se probaron varios exports ONNX, WebLLM/MLC y motores compactos.

Los motores compactos experimentales también requirieron trabajo en shaders WGSL, pesos cuantificados y caché de estados. La ruta Nanbeige 4.2 debe respetar las dos pasadas de su arquitectura: eliminar una para ahorrar tiempo no sería una optimización equivalente. Un formato ligero o un modelo pequeño no basta; sus operaciones deben ejecutarse correctamente en esa GPU y mantener una cadena RAG fiable.

La integración requirió dos Web Workers independientes. El SDK LiteRT usa importScripts y arranca en un worker clásico; el worker de embeddings es un módulo JavaScript. Esto mantiene el modelo de respuesta cargado durante la búsqueda E5 y la interfaz disponible. La cancelación cubre ambos workers; una pérdida de GPU libera los motores y muestra un error útil.

El CMS selecciona páginas publicadas, fichas de conocimiento autorizadas e información de formularios admisibles. El texto preparado se divide con el tokenizer real del embedding: fragmentos de 400 tokens con solapamiento de 40 tokens, título limitado y comprobación de 512 tokens tras añadir el prefijo. Un fragmento demasiado largo se rechaza en lugar de perder información silenciosamente.

Multilingual E5 Base, perfil seleccionado, produce vectores de 768 dimensiones. Se utiliza query: para preguntas y passage: para documentos. La salida aplica media enmascarada y normalización L2. La indexación y la búsqueda deben realizar las mismas operaciones: un vector con la longitud correcta puede ser numéricamente incorrecto.

En móvil, la ruta MatMulInteger de ciertos exports cuantificados no era compatible con el motor empleado. Una herramienta reproducible conserva los pesos INT8 pero adapta las operaciones matriciales a FP32 portable. Los artefactos E5 se verifican mediante SHA-256 y cuatro referencias numéricas, con coseno mínimo de 0,999. Las referencias se calculan fuera del navegador; la inferencia del visitante sigue utilizando WebGPU.

MariaDB conserva los vectores en una columna VECTOR(1024). Las dimensiones restantes se rellenan con ceros, manteniendo el coseno. Cada índice está vinculado a su perfil de embedding y cada fragmento a su huella de contenido. Los lotes obsoletos y los vectores no normalizados se rechazan.

En cada pregunta, el servidor ordena por distancia coseno, filtra el idioma y las fuentes aún publicadas, aplica el umbral configurado y limita los fragmentos de un mismo documento. La configuración ilustrada conserva cuatro fragmentos y un umbral de 0,75. E5 Small, de 384 dimensiones y unos 118 MB frente a 279 MB de Base, está disponible para nuevos ensayos; requiere su propio índice y no se obtiene recortando vectores Base.

Una pregunta como «¿y el mantenimiento?» resulta difícil de buscar sin el tema anterior. Una primera pasada genera una consulta autónoma a partir de la solicitud, los intercambios recientes y la referencia opcional. Se limpia la salida para no convertir comentarios del modelo en consultas. Si falla la reformulación sin error fatal del motor, se puede buscar la pregunta original.

La búsqueda conserva la pregunta y su reformulación cuando aportan consultas distintas. El servidor combina sus clasificaciones mediante reciprocal rank fusion: fusiona los rangos de los fragmentos en vez de dejar que la reformulación sustituya completamente la solicitud. Así se reduce el riesgo de perder un detalle importante.

La memoria persistente es opcional y se guarda en IndexedDB, en el navegador del visitante: hasta 60 intercambios durante 7 días. Cada entrada incluye pregunta, respuesta, vector, idioma, perfil de embedding y fecha. Las entradas caducadas se eliminan al acceder; el usuario puede desactivar o borrar la memoria. Si el almacenamiento no está disponible, la conversación continúa sin persistencia.

Existe además una búsqueda semántica local. El vector de la pregunta actual se compara con preguntas anteriores del mismo idioma y perfil; el mejor resultado que supere el umbral puede enriquecer el contexto. Los intercambios recientes tienen prioridad. Una respuesta antigua generada no se reutiliza como fuente factual: solo la pregunta anterior pertinente aporta contexto distante.

El prompt combina el rol y las instrucciones del CMS, la última solicitud, el historial útil y los fragmentos recuperados. Las fuentes se presentan como datos separados de las instrucciones del sistema. El borrador permanece privado: la interfaz muestra el progreso y después la respuesta aceptada. La espera incluye varias pasadas de inferencia, no solo la redacción visible.

Una segunda pasada del mismo modelo evalúa si el borrador responde a la pregunta y si las fuentes sostienen los datos esenciales. LiteRT utiliza la herramienta local emit_result para los intercambios estructurados, sin acción externa. Se validan el JSON y los tipos requeridos. Un JSON válido no garantiza que el juicio sea correcto.

Un fallo real mostró contextos distintos: el redactor veía hasta 1.250 caracteres por fragmento, pero el revisor solo 650. Un rango de precios situado más abajo podía faltar durante la revisión. Ambas pasadas reciben ahora las mismas fuentes con el límite de 1.250 caracteres, evitando exigir una comprobación con pruebas que se han ocultado al revisor.

Si se rechaza el borrador, puede ejecutarse una búsqueda correctiva y redactarse una segunda versión. El proceso tiene límites: dos borradores como máximo y una búsqueda adicional. También se filtran repeticiones y comentarios internos. Si no hay una respuesta admisible, se explica la limitación y se ofrece contacto.

Se conservan los contadores nativos; se rechazan salidas vacías o que alcancen el límite de tokens. No se inventa una señal de finalización que el SDK no exponga. El control reduce algunos errores, pero utiliza el mismo modelo y también puede equivocarse. Se prueba con borradores falsos y datos ausentes; las fuentes siguen siendo consultables.

La inferencia de respuesta y la memoria persistente se ejecutan en el dispositivo. El servicio sigue conectado: descarga modelos y bibliotecas, envía vectores de búsqueda y recibe textos fuente. Un embedding no garantiza anonimato. Las preguntas no cubiertas pueden guardarse en el CMS para mejorar conocimientos, hasta 90 días sin una nueva solicitud y con un máximo de 5.000 preguntas por sitio.

Las API controlan el ámbito del sitio, las sesiones de administración y las protecciones CSRF correspondientes. Se comprueban perfil, dimensiones, valores finitos y normalización de los vectores. La búsqueda excluye páginas retiradas y formularios no autorizados; las fichas en borrador no se publican en las respuestas.

Cuando se activa la lectura de referencias web, el servidor puede leer una URL pública del visitante. Se verifican protocolos, direcciones y redirecciones para bloquear redes privadas. La descarga tiene límites de tamaño y tiempo. Se extrae texto sin ejecutar scripts; sigue siendo una referencia externa, no una instrucción del sistema.

El asistente puede ayudar a completar un formulario autorizado con información expresamente facilitada. Se validan esquema de campos, idioma, formulario y duración de validez. Se preservan los valores existentes, nunca se marca automáticamente el consentimiento y no se envía ningún formulario sin acción del usuario.

El CMS prepara las fuentes, retoma la indexación, sigue los fragmentos pendientes y ofrece una prueba real. Los perfiles de respuesta móvil/tableta y ordenador son independientes. La detección utiliza información del navegador y del dispositivo: estrechar una ventana de ordenador no cambia al perfil móvil.

La prueba está vinculada al modelo, la configuración y la búsqueda realizada. Cambiar modelo, instrucciones o índice invalida la validación correspondiente y exige otra prueba y reactivación. Las firmas de configuración evitan conservar una activación basada en un ensayo obsoleto. Los ajustes puramente visuales mantienen la validación de respuestas.

La verificación incluyó generación real en GPU, coherencia numérica de embeddings, precios y mantenimiento, promesas falsas y cifras no publicadas. Las correcciones móviles se comprobaron con teclado abierto, apertura y cierre de la ventana, botón de envío accesible y ausencia de desbordamiento. La publicación respalda el ámbito afectado y verifica las páginas públicas.

Quedan objetivos concretos: ampliar preguntas de validación, medir descargas iniciales y cuotas, comprobar más combinaciones navegador/GPU y comparar nuevos exports sobre Adreno. Una aplicación nativa podría usar otros aceleradores; la inferencia alojada reduciría la carga del teléfono. Estas alternativas cambiarían la arquitectura y no se presentan como ya entregadas.