¿Tiene sentido un modelo local pequeño + RAG para un dominio estrecho?
Para casos de uso muy específicos, un modelo de 2B parámetros combinado con una base vectorial bien construida puede superar a un modelo grande sin contexto. Por qué el RAG compensa las limitaciones del modelo.
La combinación más eficiente para dominios estrechos
Un LLM grande como GPT-4o tiene conocimiento paramétrico amplio pero genérico. Si le preguntas sobre el proceso de alta de un cliente en tu sistema específico, responderá con buenas intenciones pero inventando detalles. La alternativa no es necesariamente un LLM más grande — es un LLM pequeño con un retriever que le pasa el contexto correcto en el momento correcto.
Este patrón — modelo local pequeño + RAG con base vectorial del dominio — tiene una lógica clara: el modelo no necesita "saber" el dominio, necesita saber razonar sobre lo que el retriever le entrega. La calidad del output depende más de la calidad de los chunks recuperados que del número de parámetros del modelo.
El principio: en un dominio estrecho con buena base vectorial, un Gemma 2:2B con RAG puede dar respuestas más precisas que un GPT-4o sin contexto. El conocimiento relevante está en los chunks, no en los pesos.
Cuándo funciona y cuándo no
✓ Casos donde funciona bien
•Soporte técnico con documentación interna indexada
•Chatbot de onboarding de empleados con políticas de empresa
•Asistente de código con convenciones del repositorio en el RAG
•FAQ de producto con respuestas pre-redactadas como contexto
✗ Casos donde falla
•Razonamiento multi-paso complejo (el modelo pequeño no lo resuelve bien)
•Preguntas que requieren síntesis de muchos documentos distintos
•Generación de código en lenguajes o frameworks poco representados en el RAG
•Dominio que cambia rápidamente (el índice queda obsoleto)
Qué hace que el RAG compense las limitaciones del modelo
En un sistema RAG, el retriever hace el trabajo pesado de encontrar información relevante. El LLM recibe un prompt que incluye esa información y solo tiene que extraer la respuesta correcta de un texto ya localizado. Esta tarea (extraction + synthesis de contexto dado) es mucho más fácil que generation desde conocimiento paramétrico — y un modelo de 2B parámetros puede hacerla razonablemente bien.
La clave está en la calidad del chunking y el embedding. Si los chunks son demasiado grandes (pierde precisión semántica) o demasiado pequeños (pierde contexto), el retriever pasa información subóptima y ni un modelo grande puede compensarlo. El esfuerzo de ingeniería está más en construir bien el índice que en escalar el modelo.
Tamaño de chunk
256–512 tokens por chunk con overlap del 20%. Ajustar según densidad del contenido.
Modelo de embedding
text-embedding-3-small (OpenAI) o all-MiniLM-L6-v2 (local/gratuito) para español.
Número de chunks recuperados (k)
Empezar con k=3. Más chunks = más contexto pero mayor riesgo de distractor.
El takeaway
¿Quieres aplicar esto en tu equipo?
En Kuuli Technologies llevamos estas metodologías a equipos reales. Escríbenos si quieres una sesión de trabajo o una consultoría sobre agentes IA y SDD.