- ProblemaLo que rodea al modelo para que sirva de algo: interfaces, RAG, conexiones y scripts.
Tener un modelo funcionando en casa es como tener un motor encima de la mesa: impresiona, hace ruido y no te lleva a ningún sitio. Para que sirva hace falta montar cosas alrededor. Aquí cuento las cuatro piezas que he ido añadiendo a mis modelos locales, qué problema resolvía cada una y qué falló por el camino.
La promesa del modelo que ya lo hace todo
En Ollama, LM Studio, llama.cpp y Unsloth, cuál uso para cada cosa dejé los modelos funcionando. Cargados, respondiendo, rápidos incluso. ¿Y luego qué?
Mis primeros días con un modelo instalado fueron un poco tristes. Lo tenía corriendo en un servidor, le preguntaba cosas desde la terminal un par de veces al día y, a la semana, me di cuenta de que para todo lo que de verdad necesitaba seguía abriendo Claude. Tenía un modelo en casa y no lo usaba para nada. Como la bicicleta estática que acaba de perchero.
Casi todos los vídeos terminan justo ahí: el modelo responde «¡Hola! ¿En qué puedo ayudarte?», el presentador sonríe y aparece el botón de suscribirse. Nadie cuenta el día siguiente, que es cuando descubres que un modelo que solo saluda no te ahorra ni un minuto. Este artículo va del día siguiente.
Por qué el modelo solo no basta
La IA local tiene un punto de partida muy limitado: un modelo produce texto y ya. No recuerda lo que hablasteis ayer, no ve tus documentos, no toca tus herramientas y no se pone a trabajar si tú no le escribes. Es un cerebro sin memoria, sin ojos y sin manos.
Tener la inteligencia artificial en local significa, sobre todo, que tus datos no salen de casa y que no dependes de un servicio ajeno. Ojo, eso no lo hace privado ni seguro por arte de magia: si la máquina está mal protegida, abierta a internet o comparte carpetas con quien no debe, los datos están en casa, pero expuestos. Pero para que eso sirva de algo hacen falta piezas alrededor. Yo he montado cuatro, y las cuento en el orden en que llegaron:
- Una interfaz para usarlo con comodidad.
- Búsqueda en mis documentos.
- Conexión con mis herramientas mediante MCP.
- Scripts que lanzan tareas sin que yo esté delante.
Ninguna es imprescindible por separado. Juntas, convierten un juguete en algo que uso.
Una interfaz para usarlo con comodidad
La primera pieza fue una interfaz web: Open WebUI, una aplicación de código abierto que da al modelo local una ventana parecida a la de ChatGPT, en el navegador. La instalé en el mismo servidor donde corre Ollama.
El problema que resolvía era muy concreto: quería usar el modelo desde cualquier ordenador de la red interna, incluido el portátil, sin abrir una terminal ni instalar nada en cada equipo. Y quería que otra persona de casa pudiera usarlo con su propio usuario, sin ver mis conversaciones. Con la interfaz, eso quedó resuelto en una tarde.
Lo que falló: tras una actualización se perdió la conexión con Ollama y la interfaz mostraba la lista de modelos vacía. Estuve un buen rato convencido de que había borrado los modelos, hasta que vi que era solo una dirección mal configurada. También la dejé una temporada accesible desde fuera de la red interna, sin pensarlo mucho, y cuando me di cuenta la volví a cerrar. Ahora solo se entra desde dentro o a través de una conexión segura a mi red.
Buscar en mis documentos
La segunda pieza es la que más me ha cambiado el uso. Buscar en tus documentos con un modelo funciona así, dicho en llano: cuando preguntas algo, un sistema busca primero en tus documentos los trozos que parecen relevantes y se los pasa al modelo junto con la pregunta, para que responda con ellos delante. A esto se le llama RAG, siglas en inglés de «generación aumentada por recuperación». El nombre asusta más que la idea.
No hay que confundirlo con afinar, que ya expliqué al hablar de Unsloth. Afinar cambia el modelo para que responda con un estilo o un criterio. RAG no toca el modelo: le pone delante la información justa cada vez que preguntas.
Monté la búsqueda en documentos que trae la propia interfaz web con unos 900 documentos: manuales técnicos de mis servidores, notas de proyectos y documentación de programas que uso a menudo.
Los resultados, con los pies en el suelo: en una prueba con 40 preguntas cuya respuesta conocía, acertó bien en unas 28, a medias en 7 y falló en 5. Los fallos fueron casi siempre del mismo tipo: la búsqueda traía trozos equivocados, por ejemplo, de un manual de una versión antigua, y el modelo respondía con total seguridad a partir de ellos. También las tablas de los PDF se troceaban mal y las respuestas con números eran las menos fiables. Tiempo por respuesta: entre 5 y 15 segundos, aceptable para consulta.
Lección: RAG funciona tan bien como los documentos que le das. Limpiar versiones viejas y duplicados mejoró más los resultados que cambiar de modelo.
Y tiene límites que conviene saber antes. El índice, la copia troceada que la búsqueda consulta, no se entera solo de los cambios: si actualizas un manual y no lo vuelves a indexar, el modelo sigue respondiendo con la versión vieja. Yo lo reindexo a mano cada vez que meto o quito una tanda de documentos. Tampoco entiende de permisos: lo que entra en el índice lo puede ver cualquiera que pregunte en esa colección. Por eso los documentos de clientes no están en la colección compartida de casa, sino en una aparte que solo ve mi usuario.
Conectarlo con mis herramientas vía MCP
La tercera pieza es la que le da manos al modelo. MCP (Model Context Protocol) es un estándar abierto que presentó Anthropic, la empresa de Claude, a finales de 2024, para conectar una inteligencia artificial con herramientas y datos: archivos, correo, bases de datos, el navegador. La comparación más útil es la de un enchufe universal: en lugar de hacer una conexión a medida para cada herramienta, basta con que ambos lados hablen el mismo idioma. El servidor MCP es el pequeño programa que hace de puente con cada herramienta concreta y le dice al modelo qué puede hacer con ella.
Con los modelos locales monté tres conexiones: una de lectura de una carpeta de documentos de trabajo, una de consulta a una base de datos de inventario de mis máquinas y una para leer el calendario. Las tres de solo lectura. Aquí los modelos locales sufren más que los grandes: los pequeños a veces no entendían bien cuándo usar cada herramienta o la llamaban con datos mal puestos; con un modelo de 14B o más, la cosa mejoró bastante.
Y el riesgo, que no quiero pasar por alto: instalar un MCP es dar permisos. Ese pequeño programa puede leer, y a veces escribir, en lo que le conectes. Hay que saber de dónde viene, quién lo mantiene y qué puede tocar. Mis fronteras, en corto: solo instalo servidores MCP de origen conocido y revisados; cada uno ve una carpeta o una tabla, nunca todo; las contraseñas y claves de acceso van en un fichero aparte que no ve el modelo; cualquier acción que escriba o borre pide confirmación; y cada llamada queda apuntada en un registro que miro cuando algo no cuadra. Los que uso a diario y cómo los instalo lo cuento con más calma en Cómo conecté la inteligencia artificial con mis herramientas.
Scripts que lanzan tareas
La cuarta pieza es la menos vistosa y la que más horas me ahorra: scripts, pequeños programas que lanzan tareas solos a una hora o cuando pasa algo. Uno clasifica cada noche los correos de una cuenta de avisos y me deja un resumen por la mañana; otro resume los registros de los servidores y marca lo que parece raro; otro etiqueta los documentos nuevos que caen en una carpeta compartida. Corren en dos de mis servidores internos, los mismos donde está Ollama.
Antes, varias de estas cosas las habría montado en n8n, la herramienta de automatización por bloques. Ahora la uso menos porque los agentes la están sustituyendo: el resumen de registros lo tenía en n8n y lo rehíce con un agente que escribió el script entero en una tarde. Lo cuento con detalle en Por qué ya no necesito n8n.
Conviene separar tres cosas que se parecen. Un script hace siempre lo mismo, paso a paso, y el modelo solo rellena un hueco, como resumir o clasificar. Una herramienta, como un MCP, es algo que el modelo puede decidir usar mientras habla contigo. Un agente decide él solo qué pasos dar y puede ejecutar órdenes en la máquina, y ese es el que más cuidado pide. Mis scripts corren con un usuario propio sin permisos de administrador y solo pueden escribir en su carpeta; a un agente con permiso para ejecutar lo que quiera no lo dejo solo en un servidor.
Lo que falló: el script de correos se atascó una noche con un mensaje enorme, con adjuntos de varios megas, y se quedó colgado hasta el día siguiente sin avisar. Ahora tiene un tiempo máximo y me manda un aviso si algo no termina.
Cuándo sustituye a la de pago y cuándo no
Lo local me basta en tres tipos de trabajo. Cuando hay datos de clientes que no quiero sacar de casa: la clasificación de documentos de un cliente se hace entera en local. Cuando la tarea es repetitiva y de mucho volumen: resumir y clasificar unos 150 correos y documentos al día sin pagar por cada uno. Y cuando me basta con buscar en mis propios documentos.
Vuelvo a Claude cuando hace falta razonar con cuidado, cuando hay código de por medio que importa o cuando la tarea tiene muchos pasos encadenados. Ahí la diferencia se nota enseguida, y no por poco.
Mis cifras, aproximadas: en torno a un 30 % de las tareas automáticas corren en local; el resto sigue en la nube. El ahorro en consumo de modelos de pago lo calculo en unos 20 euros al mes, que no paga ni de lejos la luz y las horas invertidas. El balance completo, con números, está en ¿Para qué me sirve tener la inteligencia artificial en casa?.
La lista mínima para un fin de semana
Si quieres montar algo usable en un fin de semana, esta es la lista que me habría gustado tener:
- Un programa sencillo para mover el modelo: LM Studio u Ollama.
- Un modelo pequeño que quepa con holgura en tu equipo.
- Una interfaz web para usarlo con comodidad.
- Una carpeta de documentos con búsqueda, pocos y bien elegidos.
- Una conexión MCP de solo lectura, de un origen que conozcas.
- Un script sencillo que haga una sola tarea al día.
Lo que no haría el primer fin de semana: abrir nada a internet, dar permisos de escritura, afinar modelos ni conectar datos de clientes.
¿Qué hay de verdad en la promesa del modelo que ya lo hace todo? Que el modelo es la pieza más famosa y la menos suficiente. Lo útil está alrededor. Si todo esto compensa, lo cuento en ¿Para qué me sirve tener la inteligencia artificial en casa?.
Alternativas de la comunidad 0
Todavía nadie ha propuesto una alternativa a este caso. Puedes ser quien empiece.
Proponer una alternativa