Una vez que tienes la infraestructura básica funcionando – un modelo cargado, un runtime configurado y la memoria suficiente – el siguiente paso es aplicar esa capacidad a casos de uso específicos. RAG, agentes locales, fine-tuning y multimodalidad son las cuatro áreas donde los LLM locales generan más valor práctico.
Esta guía cubre la capa de aplicación: cómo construir sistemas RAG confiables, cómo dar herramientas a un agente local de forma segura, cuándo y cómo hacer fine-tuning con LoRA/QLoRA, y qué considerar al usar modelos multimodales o desplegar en dispositivos edge.
Este artículo forma parte de una serie técnica sobre IA local.
Contexto largo: atención costosa
El contexto largo suena atractivo: 128K, 256K o incluso 1M de tokens en un solo prompt. Es útil, pero tiene costes reales.
Más contexto significa:
- Más memoria de caché KV
- Procesamiento de prompts más lento
- Más trabajo de atención
- Evaluaciones más difíciles
- Más formas en que el texto irrelevante puede distraer al modelo
La calidad también puede decaer con la distancia. Un modelo puede manejar bien el final de un documento largo mientras pierde detalles críticos enterrados cerca del principio.
Cuándo usar contexto largo
Usa el contexto largo para: análisis de documentos completos, cortes de código fuente, revisión legal o técnica, síntesis de transcripciones, razonamiento con múltiples archivos y como fallback de RAG cuando la recuperación falla.
No trates el contexto largo como un reemplazo de la recuperación (retrieval). Es un complemento. Usa RAG para grandes corpus y el contexto largo para la evidencia final seleccionada.
Hábitos prácticos
- Pon las instrucciones críticas cerca del principio y cerca del final
- Usa encabezados de sección y delimitadores
- Pide citas vinculadas a fragmentos de la fuente
- Comprime el historial irrelevante
- Usa memoria de resumen en lugar de un historial de chat infinito
Piensa en el contexto largo como atención costosa, no como un cuaderno gratuito.
RAG supera a los prompts gigantes
RAG significa Generación Aumentada por Recuperación (Retrieval-Augmented Generation). En lugar de meter toda la información en el prompt, recuperas fragmentos relevantes de una base de conocimiento y le das solo esos fragmentos al modelo.
Arquitectura de un sistema RAG local
Un buen sistema RAG local suele tener:
- Ingestión de documentos: Carga de archivos PDF, DOCX, TXT, HTML, etc.
- Análisis (parsing): Extracción de texto estructurado
- Fragmentación (chunking): División del texto en unidades manejables
- Embeddings: Conversión de texto a vectores numéricos
- Índice vectorial: Almacenamiento y búsqueda por similitud
- Recuperación: Búsqueda de los fragmentos más relevantes
- Reranking: Reordenamiento por relevancia
- Construcción del prompt: Ensamblaje del contexto con las instrucciones
- Generación de la respuesta: El modelo responde basado en la evidencia recuperada
- Comprobaciones de fundamentación: Verificación de que la respuesta se basa en la evidencia
Cada etapa es un punto de fallo potencial.
El chunking: el asesino silencioso
La estrategia de fragmentación es el factor más subestimado en RAG. Los fragmentos de tamaño fijo sin solapamiento pueden dividir frases y perder contexto. El chunking semántico o el chunking jerárquico con recuperación del documento padre suelen funcionar mejor, pero no hay una respuesta universal.
Debes evaluar el tamaño del chunk, el solapamiento y las reglas de división en tus documentos reales.
Reranking: el rescatador
Un buen reranker puede rescatar una recuperación mediocre. Ningún reranker puede arreglar fragmentos que perdieron la respuesta durante la ingestión. El reranker reordena los resultados por relevancia, pero no puede crear información que no estaba en los fragmentos originales.
Documentos y trabajo de conocimiento
Para documentos privados, los LLM locales brillan: resúmenes de transcripciones de reuniones, revisión de contratos, Q&A de documentación técnica, síntesis de notas de investigación, redacción de correos, búsqueda de políticas, asistentes de soporte interno y flujos de trabajo de cumplimiento se benefician todos de mantener el material fuente cerca de la máquina u organización que lo posee.
Flujo de trabajo para documentos
- Analiza los documentos cuidadosamente
- Preserva los metadatos de página y sección
- Fragmenta semánticamente
- Usa embeddings y rerankers
- Pide citas al modelo
- Separla la respuesta de las fuentes del razonamiento general
- Evalúa la fidelidad de las citas
No asumas que el modelo sabe lo que hay en tus documentos. Solo sabe lo que le pones en el prompt o lo que recuperas en el contexto.
Recomendaciones por tipo de documento
- Transcripciones de reuniones: Preserva las etiquetas de hablante y las marcas de tiempo
- Revisión de contratos: Fragmenta por cláusula o sección en lugar de por un conteo arbitrario de tokens
- Q&A de documentación técnica: Incluye números de página o anclajes de sección en los fragmentos recuperados para que el modelo pueda citar las fuentes con precisión
Para el trabajo con documentos, tu parser y tu recuperador importan tanto como el modelo.
Agentes locales con protecciones
Un LLM local se vuelve mucho más útil cuando puede usar herramientas: búsqueda de archivos, comandos de shell, automatización de navegador, bases de datos, ejecución de código, calendarios, sistemas de tickets, APIs internas, bases de datos vectoriales, domótica, robótica o dispositivos edge.
El uso de herramientas cambia el modelo de seguridad. Un chatbot que alucina es molesto. Un agente con acceso al sistema de archivos puede borrar datos. Un agente con acceso al navegador puede filtrar secretos. Un agente con acceso a la shell puede dañar la máquina más rápido de lo que puedes leer los logs.
Capas de seguridad para agentes
- Limita el alcance: Da al agente solo los directorios, APIs, acceso de red y credenciales que realmente necesita
- Restringe la ejecución: Usa sandboxes, contenedores, usuarios de privilegios mínimos, confirmaciones para acciones destructivas y argumentos de herramientas validados por esquema
- Trata las entradas como hostiles: Los documentos recuperados, las páginas web, los tickets y los correos pueden contener inyección de prompts
- Mantén un registro de auditoría: Registra llamadas a herramientas, versiones del modelo, prompts y aprobaciones sin volcar secretos en los logs
Las salidas estructuradas ayudan, pero no son una frontera de seguridad. Los esquemas JSON, la decodificación restringida y las firmas de funciones hacen que las llamadas a herramientas sean más fáciles de validar. No prueban que el modelo entendió la solicitud, eligió la acción segura o evitó instrucciones inyectadas.
Para un uso de herramientas serio, pon los controles de política fuera del modelo.
Programando con modelos locales
La programación es uno de los mejores casos de uso para LLM locales porque los prompts a menudo incluyen código privado, la latencia importa, la iteración es frecuente, los costes de API pueden crecer rápidamente y los modelos locales pueden integrarse con editores, shells, grep, ejecutores de tests y flujos de trabajo de parches.
Configuración óptima para programación
La configuración de programación más fuerte no es un chatbot desnudo. Es un modelo instruct capaz de código conectado a:
- Contexto de repositorio dirigido
- Recuperación sobre el codebase
- Rutas de archivos
- Fragmentos relevantes
- Ejecución de tests
- Un bucle de parches
Prácticas recomendadas
- Mantén la decodificación determinista o con temperatura baja
- Pide parches en lugar de consejos vagos
- Ejecuta tests automáticamente
- Mantén un pequeño conjunto de evaluaciones con bugs y tareas reales
- No dejes que un modelo local reescriba una base de código grande sin revisión
El hecho de ser local no hace que un agente de código sea sabio. Solo hace que el contexto sea privado, el bucle más barato y la integración más fácil de controlar.
Ajuste fino (Fine-tuning) con LoRA
El fine-tuning cambia el comportamiento del modelo mediante el entrenamiento con datos adicionales. Para usuarios locales, los métodos más importantes son LoRA y QLoRA.
LoRA congela el modelo base y entrena pequeños adaptadores de bajo rango (low-rank). Esto reduce los parámetros entrenables y te permite mantener múltiples adaptadores ligeros. QLoRA extiende esto al entrenar a través de un modelo base cuantizado en 4 bits hacia adaptadores LoRA.
Cuándo hacer fine-tuning
Haz fine-tuning cuando necesites:
- Un estilo de escritura constante
- Un formato de salida específico para un dominio
- Un comportamiento repetitivo de clasificación o extracción
- La fiabilidad del formato de llamadas a herramientas
- Una personalidad de asistente especializada
- Una adaptación de dominio que el RAG no pueda resolver
- Un mejor rendimiento de un modelo pequeño en una tarea estrecha
Cuándo NO hacer fine-tuning primero
Prueba este orden antes de considerar fine-tuning:
- Plantilla de chat correcta
- Mejores prompts
- Mejor modelo
- Mejor decodificación
- RAG
- Reranking
- Ejemplos de pocos disparos (few-shot)
- Finalmente: Fine-tuning
La mayoría de los problemas que parecen «el modelo no entiende mi dominio» son en realidad «mi prompt es vago, mi plantilla es errónea o mi recuperación está rota».
Plan de fine-tuning
Un buen plan incluye: datos limpios, divisiones de entrenamiento/validación/prueba, evaluaciones de línea base, comportamientos objetivo claros, revisión de seguridad, comprobaciones de sobreajuste (overfitting), evaluaciones de regresión, versionado de adaptadores, revisión de licencia y un plan de reversión.
Multimodalidad local
Los modelos multimodales locales aceptan imágenes y, a veces, audio o vídeo, además del texto. Los ecosistemas de pesos abiertos modernos incluyen cada vez más estos modelos.
El coste oculto
La entrada no textual se convierte en tokens también. Los codificadores de visión (vision encoders) añaden memoria. Los parches de imagen consumen contexto. El audio y el vídeo pueden hacer explotar el presupuesto de entrada. Las plantillas multimodales también son más fáciles de errar que las plantillas de solo texto.
Un solo modelo de alta resolución puede consumir miles de tokens en la ventana de contexto. Si estás ejecutando un modelo multimodal localmente, cuenta los tokens de imagen de la misma manera que cuentas los tokens de texto. Vienen del mismo presupuesto.
Limitaciones actuales
- Los modelos VLM pequeños pueden alucinar detalles visuales
- La fiabilidad del OCR varía
- Los gráficos y las tablas siguen siendo difíciles
- Para flujos de trabajo serios de documentos o imágenes, evalúa con muestras reales
No confíes en una demo de una foto simple para probar la calidad de extracción de facturas.
Despliegue en el borde
Los modelos pequeños son cada vez más útiles en teléfonos, portátiles, robots, puertas de enlace IoT, dispositivos de fábrica, vehículos, dispositivos médicos, equipos de campo offline y aplicaciones de navegador. El borde no es solo una versión pequeña de la estación de trabajo. Tiene un conjunto diferente de restricciones.
Restricciones del edge
- Baja memoria
- Bajo consumo de energía
- Límites térmicos
- Conectividad intermitente
- Requisitos de privacidad
- Latencia en tiempo real
- Ventanas de contexto pequeñas
- Comportamiento de fallback predecible
Configuración práctica en el edge
Usa un modelo de 0.5B a 4B, cuantización agresiva, prompts cortos, esquemas fijos, flujos de trabajo asistidos por herramientas, embeddings locales, caché y sin historial de chat innecesario.
Cuando la conectividad cae, un modelo local que sigue funcionando es más valioso que un modelo más grande que falla. El futuro de la IA local no es solo modelos gigantes de estación de trabajo. Es también modelos pequeños haciendo trabajos útiles cerca de los datos.
Runbook de operación
Usa esto como la puerta final antes de confiar en un modelo local para trabajo real.
Elige y ajusta
- Elige una familia de modelos adecuada a la tarea
- Lee la licencia
- Confirma los requisitos de hardware
- Elige un nivel de cuantización
- Estima la factura completa de memoria (no solo los pesos)
Carga y formato
- Prefiere safetensors o GGUF de fuentes reputadas
- Evita archivos pickle no confiables
- Verifica el tokenizer y la plantilla de chat
- Establece la longitud del contexto intencionalmente
- Elige los parámetros de decodificación para la tarea
Evalúa y opera
- Prueba con prompts representativos
- Mide el tiempo hasta el primer token y la velocidad de decodificación
- Rastrea el pico de memoria
- Evalúa la recuperación antes de añadir RAG
- Sandboxing de herramientas antes de añadir agentes
- Realiza fine-tuning solo después de que los métodos más simples fallen
Versiona todo lo que importa
Modelo, cuantización, runtime, prompt, plantilla de chat, adaptador, modelo de embedding, reranker, conjunto de evaluaciones y perfil de hardware. Los sistemas locales son más fáciles de controlar solo cuando puedes reproducir lo que ejecutaste.
Preguntas frecuentes
¿Qué es RAG y por qué es mejor que pegar un PDF entero?
RAG (Retrieval-Augmented Generation) recupera fragmentos relevantes de una base de conocimiento en lugar de meter todo el documento en el prompt. Es más eficiente en memoria, más rápido y produce respuestas más fundamentadas porque el modelo solo ve la evidencia relevante.
¿Cuándo debo hacer fine-tuning en lugar de usar RAG?
Haz fine-tuning cuando necesites un estilo de escritura constante, un formato de salida específico, un comportamiento repetitivo de clasificación o una adaptación de dominio que el RAG no pueda resolver. Prueba RAG primero: es más barato y más fácil de mantener.
¿Es seguro darle herramientas a un LLM local?
Solo si implementas protecciones: sandboxes, usuarios sin privilegios, validación de esquemas, confirmaciones para acciones destructivas y registro de auditoría. Un agente con acceso al sistema de archivos puede causar daños reales.
¿Los modelos multimodales locales son útiles?
Sí, para tareas específicas como OCR de documentos, análisis de imágenes técnicas o extracción de tablas. Pero evalúa con muestras reales: los modelos pequeños pueden alucinar detalles visuales y la fiabilidad varía según el tipo de imagen.