# Asistente IA RAG en el navegador | SDX Development

> Caso SDX: WebGPU, embeddings E5, reformulación, memoria local, revisión de respuestas y pruebas móviles para un asistente RAG administrable.

Asistente IA RAG · SDX

## Un asistente RAG sobre WebGPU, del CMS al navegador.

Una aplicación IA completa: conocimientos del CMS, búsqueda vectorial, memoria local y respuestas redactadas y revisadas en la GPU del visitante.

- IA y RAG
- Generación en el navegador
- CMS y móvil
[Todos los proyectos](https://sdx-development.com/es/casos-de-exito)

[![Asistente público SDX: pregunta en francés sobre el precio de una web y respuesta generada en Chrome, con enlaces a las fuentes.](https://sdx-development.com/media/assistant-rag-sdx/assistant-desktop.webp)Ampliar captura](https://sdx-development.com/media/assistant-rag-sdx/assistant-desktop.webp)

Asistente público SDX: pregunta en francés sobre el precio de una web y respuesta generada en Chrome, con enlaces a las fuentes.

 

01 / RAG

## Convertir los contenidos en respuestas útiles

Las páginas de una web explican una oferta, sus precios y su funcionamiento. Sin embargo, el visitante no siempre sabe dónde buscar. El objetivo era permitirle preguntar y obtener una respuesta relacionada con la información publicada.

He desarrollado esta aplicación en la propia web de SDX Development. Es un proyecto interno, disponible en producción, que combina búsqueda documental, modelos locales, administración de conocimientos e interfaz de conversación.

### Mi intervención

Diseño del flujo RAG, integración en el CMS, ejecución de modelos en el navegador, comprobación de respuestas y pruebas en ordenador y en un Samsung Galaxy S25 Ultra.

Proyecto

Aplicación interna · SDX Development

Uso

Preguntas sobre servicios y contenidos de la web

Interfaz

Asistente web gestionado en el CMS

Entrega

En producción · septiembre de 2026

02 / RAG

## De la pregunta a una respuesta con fuentes

El RAG conecta la generación de texto con información recuperada de un índice documental. En esta aplicación, el navegador y el servidor de la web se reparten el trabajo.

1. ### Conocimientos

El CMS prepara un índice a partir de los contenidos seleccionados y de información añadida por el administrador.
2. ### Búsqueda

El navegador calcula una representación de la pregunta. El servidor busca los fragmentos pertinentes en el índice y devuelve sus fuentes.
3. ### Redacción local

Un modelo ejecutado en el navegador redacta la respuesta utilizando los fragmentos encontrados. Una búsqueda adicional puede enriquecer el contexto.
4. ### Comprobación

Una comprobación local examina el borrador antes de mostrarlo. Si la información es insuficiente, el asistente propone contactar con la empresa.

La generación se ejecuta en el dispositivo del visitante con acceso a la GPU. El servicio no funciona completamente sin conexión: descarga modelos y consulta el servidor para recuperar fuentes. Las preguntas sin respuesta pueden conservarse para ampliar los conocimientos.

### Una cadena RAG repartida entre navegador y servidor

El servidor conserva los conocimientos y recupera los fragmentos. El navegador ejecuta la reformulación, los embeddings, la redacción y la revisión. La memoria local y opcional es un tercer recurso: ayuda a seguir la solicitud sin sustituir las fuentes documentales.

1. Navegador · GPU local

#### Pregunta y contexto reciente

La solicitud actual, los últimos intercambios y, si está activada, una referencia web pública facilitada por el visitante.
2. Navegador · GPU local

#### Reformulación de la búsqueda

El modelo transforma la solicitud en una consulta documental autónoma. La pregunta original se conserva junto con la reformulación.
3. Navegador · GPU local

#### Embeddings E5

Las consultas se convierten en vectores calculados con WebGPU y enviados a la API del sitio.
4. Servidor del sitio · PHP / MariaDB

#### Búsqueda vectorial y fusión

El índice selecciona fragmentos del idioma adecuado, aplica el umbral de similitud y combina los resultados. Devuelve textos, títulos y enlaces.
5. Navegador · GPU local

#### Memoria local pertinente

Si el visitante lo autoriza, IndexedDB recupera una pregunta anterior relacionada. Complementa los intercambios recientes sin convertir su antigua respuesta en prueba.
6. Navegador · GPU local

#### Redacción de un borrador privado

El modelo utiliza las instrucciones del CMS, la pregunta, el contexto de conversación y los fragmentos recuperados. El borrador aún no se muestra.
7. Navegador · GPU local

#### Revisión y búsqueda correctiva

El mismo modelo contrasta el borrador con las fuentes. Si se rechaza: como máximo una nueva búsqueda y una segunda redacción.
8. Navegador · GPU local

#### Respuesta, fuentes y siguiente paso

El borrador aceptado se muestra con las fuentes. Si faltan datos suficientes, se ofrece contacto humano. Un intercambio admisible puede guardarse localmente.

Antes de las preguntas: el administrador prepara el contenido y calcula sus embeddings en su navegador. Los vectores documentales se guardan en el servidor. Los 855 fragmentos del índice validado no se recalculan en el teléfono de cada visitante.

EJECUCIÓN

## WebGPU: ejecutar realmente la IA en el dispositivo

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.

Los pesos Gemma E2B ocupan 2.008.432.640 bytes, unos 2 GB. Se descargan como flujo y se conservan en Cache Storage cuando la cuota lo permite, sin crear un array JavaScript de dos gigabytes. Se verifican la revisión y el tamaño esperado. Una caché eliminada o no disponible puede obligar a descargar de nuevo; este coste es distinto del tiempo de respuesta tras la carga.

CONOCIMIENTOS

## Preparar un índice fiable con embeddings compatibles

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.

El embedding es común a móvil y ordenador en esta versión. Elegir uno distinto por dispositivo exigiría dos índices completos y validar sus resultados. Los modelos que redactan las respuestas ya tienen selección independiente por perfil.

CONTEXTO

## Reformular la solicitud y recuperar memoria local pertinente

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.

Los conocimientos documentales aportan pruebas; el historial reciente sigue la conversación; la memoria local recuerda una necesidad anterior. La memoria no modifica los pesos del modelo ni el índice documental del sitio.

CALIDAD

## Redactar, revisar y corregir antes de mostrar la respuesta

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 velocidad se mejoró mediante motores, formatos y carga. Retirar las fuentes o la revisión habría cambiado el servicio y haría incomparables las duraciones.

03 / CMS

## Un asistente administrable más allá de la burbuja

El CMS reúne los ajustes que mantienen útil al asistente: conocimientos, comportamiento, modelos y apariencia.

### Elegir los conocimientos

Selección de contenidos, información complementaria y preparación del índice documental.

### Adaptar los modelos

Modelos de respuesta distintos para móvil y ordenador, seleccionados en el cliente. El modelo de embeddings es configurable.

### Probar antes de activar

Pruebas de respuesta y validación en la administración antes de ofrecer el asistente al público.

### Definir el comportamiento

Nombre, bienvenida, instrucciones y funciones disponibles, con opción de orientar la petición hacia un contacto.

### Adaptar la apariencia

Colores, avatar, posición y vista previa. Aura ajustable: movimiento, dirección, velocidad y expansión máxima.

### Completar lo que falta

Las preguntas no cubiertas ayudan a identificar conocimientos que añadir antes de volver a probar el recorrido.

### Pantallas reales de administración

CMS de producción capturado en Chrome el 27 de septiembre de 2026. El encuadre muestra funciones del asistente y excluye la barra de cuenta. El formulario de conocimiento está vacío; la vista de apariencia contiene una conversación de demostración.

[![Modelos: selección independiente para ordenador y móvil, E5 Base, cuatro fragmentos y umbral de 0,75. Los 855 fragmentos están vectorizados.](https://sdx-development.com/media/assistant-rag-sdx/admin-models.png)Ampliar captura](https://sdx-development.com/media/assistant-rag-sdx/admin-models.png)

Modelos: selección independiente para ordenador y móvil, E5 Base, cuatro fragmentos y umbral de 0,75. Los 855 fragmentos están vectorizados.

[![Conocimientos: creación de fichas, importación de texto o Markdown, ayuda de redacción y autorización explícita de uso por el asistente.](https://sdx-development.com/media/assistant-rag-sdx/admin-knowledge.png)Ampliar captura](https://sdx-development.com/media/assistant-rag-sdx/admin-knowledge.png)

Conocimientos: creación de fichas, importación de texto o Markdown, ayuda de redacción y autorización explícita de uso por el asistente.

[![Apariencia: avatar, posición, colores y vista de conversación. Efectos e invitación tienen ajustes propios.](https://sdx-development.com/media/assistant-rag-sdx/admin-appearance.png)Ampliar captura](https://sdx-development.com/media/assistant-rag-sdx/admin-appearance.png)

Apariencia: avatar, posición, colores y vista de conversación. Efectos e invitación tienen ajustes propios.

04 / MOBILE

## Una conversación pensada para el teléfono

Shadow DOM aísla el widget de los estilos del sitio. En Android, la lectura exige seguir el teclado y la zona realmente visible.

- ### Espacio para la respuesta

La ventana utiliza la altura disponible y oculta launcher-shell durante la conversación. Los controles secundarios quedan plegados para dejar espacio a los mensajes.
- ### Teclado y envío accesibles

VisualViewport aporta altura y desplazamiento cuando se abre el teclado Android. La ventana los sigue; el campo crece de 44 a un máximo de 96 px y el envío queda accesible.
- ### Pantalla encendida cuando es posible

Screen Wake Lock se solicita durante la conversación, se recupera al volver al primer plano y se libera al cerrar. El navegador o el sistema pueden rechazarlo; no cambia ajustes permanentes del teléfono.

[![La misma conversación en el diseño móvil: captura de la web pública con un ancho de 390 px en Chrome.](https://sdx-development.com/media/assistant-rag-sdx/assistant-mobile.webp)Ampliar captura](https://sdx-development.com/media/assistant-rag-sdx/assistant-mobile.webp)

La misma conversación en el diseño móvil: captura de la web pública con un ancho de 390 px en Chrome.

**36 s**

para la pregunta sobre precios probada en el S25 Ultra

05 / Medir en un dispositivo real

## Medir en un dispositivo real

El 27 de septiembre de 2026, en Samsung Internet, el asistente público respondió a una pregunta sobre el precio de una web corporativa en aproximadamente 36 segundos, incluyendo comprobación y fuentes. Recuperó el rango publicado de 1.500 a 5.000 € sin IVA.

Medición puntual con los archivos del modelo ya descargados; no garantiza el mismo tiempo para todas las consultas. La descarga inicial es grande. Las preguntas complejas o una búsqueda correctiva pueden superar un minuto. El hardware y el acceso a la GPU del navegador influyen en el resultado.

## Dos perfiles, una misma base de conocimientos

Móvil

Gemma 4 E2B · LiteRT-LM

Ordenador

Gemma 4 E2B · LiteRT-LM

Búsqueda documental

Multilingual E5 Base

Configuración de producción tras las pruebas del 27 de septiembre de 2026: Gemma E2B está seleccionado en ambos perfiles independientes. La elección se apoya en calidad y medidas reales.

## Cómo las pruebas cambiaron la elección de modelos

Medidas del 27 de septiembre de 2026. Las duraciones cubren una solicitud RAG hasta la respuesta revisada, con pesos ya descargados. Incluyen búsqueda y varias pasadas, no solo decodificación.

| Dispositivo / candidato | Duración observada | Resultado |
| --- | --- | --- |
| S25 Ultra · Samsung Internet · Gemma 4 E2B | 36,11 s | Pregunta de precio: respuesta completa y revisada, 1.500–5.000 € sin IVA. |
| Ordenador · Chrome / NVIDIA Ampere · Gemma 4 E2B | 12,25 s | Misma pregunta: 114 tokens; el control también rechaza un precio falso. |
| Mismo ordenador · Nanbeige 4.2 Compact | 120,73 s | Respuesta nominal correcta, 238 tokens; aceptación errónea del borrador falso. |
| Mismo ordenador · Gemma E2B · validación final | 13,06 s | Prueba real registrada en el CMS y activación del modelo común a ambos perfiles. |

Las respuestas tienen distinta longitud y la reformulación puede cambiar los fragmentos recuperados: no es una clasificación universal. El contraensayo presentaba 15.000–100.000 € frente a fuentes de 1.500–5.000 €. La respuesta simple correcta de Nanbeige no bastaba para validar su revisor.

Gemma E2B también trató una objeción de precio en 15,02 s y mantenimiento en 12,99 s. Una promesa falsa «24 horas por 100 euros» y una facturación exacta no publicada terminaron en contacto humano en 25,91 s y 23,59 s. No inventar información formaba parte de la prueba.

Los ensayos móviles mostraron que una descarga pequeña no garantiza una cadena fiable: varios candidatos perdieron la GPU, repitieron texto o fallaron la revisión. Los exports ONNX probados de Qwen 3.5 4B y Gemma 3 4B no dieron respuesta final en ordenador en esta ruta. Esto describe esos exports y motores, no todos los usos de esos modelos.

Los embeddings se midieron por separado en el S25 con pesos en caché: Base, 4,275 s para carga, comprobaciones y primera pregunta, después 90–103 ms; Small, 3,487 s y después 24–27 ms. El pequeño ensayo de clasificación utilizaba cinco fragmentos, no los 855 del sitio. La mayor espera procedía de las pasadas de respuesta: cambiar solo el embedding no la habría resuelto.

DATOS

## Definir qué permanece local y qué llega al servidor

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.

La arquitectura no es completamente offline ni promete que todos los datos permanezcan en el teléfono. Búsqueda documental, referencias y seguimiento de preguntas pendientes son funciones distintas que deben explicarse según el alcance elegido.

PUBLICACIÓN

## Vincular ajustes, pruebas reales de GPU y activación

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.

El resultado es una aplicación integrada en el CMS, con una cadena reproducible y límites conocidos. El éxito consiste en responder útilmente con apoyo documental, no en el número de parámetros.

## Referencias técnicas

Las decisiones y medidas proceden de las pruebas del proyecto. Estas referencias explican las tecnologías y no garantizan rendimiento en un dispositivo concreto.

- [WebGPU · W3C](https://www.w3.org/TR/webgpu/)
- [LiteRT-LM · Google AI Edge](https://developers.google.com/edge/litert-lm/js)
- [ONNX Runtime · WebGPU](https://onnxruntime.ai/docs/tutorials/web/ep-webgpu.html)
- [Multilingual E5 · Microsoft Research](https://huggingface.co/intfloat/multilingual-e5-base)

## Una aplicación concreta del RAG en una web pública

El visitante puede consultar los contenidos y verificar las fuentes. El administrador puede ampliar los conocimientos, configurar el asistente y probar sus respuestas. El proyecto cubre toda la cadena, desde la edición del contenido hasta su uso en una conversación.

[Descubrir los servicios de IA y RAG](https://sdx-development.com/es/ia-rag-automatizacion)

## Más proyectos por descubrir

![Idea to Software](https://sdx-development.com/media/idea-to-software/agenda.webp)

Software y productos de gestión

### Idea to Software

Un ERP que conecta expedientes, planificación con restricciones, inventario, facturación y portal de clientes, con ITS Report para la inspección por vídeo.

[Explorar el proyecto : Idea to Software](https://sdx-development.com/es/casos-de-exito/idea-to-software)

![Résiliner](https://sdx-development.com/media/resiliner/home.webp)

Sitios web profesionales

### Résiliner

Una web industrial con CMS a medida: contenidos técnicos, método C.A.R.E., referencias, franquicia y solicitudes de diagnóstico.

[Explorar el proyecto : Résiliner](https://sdx-development.com/es/casos-de-exito/resiliner)

¿Y tu proyecto?

## Tus contenidos pueden convertirse en una interfaz de conversación.

Documentación, catálogo, procedimientos o servicios: definamos las fuentes, los usuarios y las respuestas esperadas para crear un asistente útil para tu actividad.

- Fuentes identificadas
- Un alcance adaptado a tus usuarios
- Respuestas que comprobar

[Hablar de mi asistente IA](https://sdx-development.com/es/contacto)[Descubrir el enfoque IA y RAG](https://sdx-development.com/es/ia-rag-automatizacion)

---

[Consultar la página HTML](https://sdx-development.com/es/casos-de-exito/asistente-ia-rag)
