Fine-Tuning vs RAG para Móvil: Por qué RAG sigue necesitando un servidor

La generación aumentada por recuperación (RAG) es la respuesta estándar a "¿cómo le doy conocimiento de dominio a mi IA?" Recuperar documentos relevantes, inyectarlos en el prompt, dejar que el modelo responda con contexto. Funciona bien para aplicaciones web con infraestructura de servidor.

En móvil, RAG tiene un problema estructural. El paso de recuperación requiere una base de datos vectorial. Esa base de datos vive en un servidor (reintroduciendo la dependencia del servidor) o en el dispositivo (consumiendo almacenamiento y RAM significativos). Ninguna opción es limpia para móvil.

Fine-tuning adopta un enfoque diferente. En lugar de buscar conocimiento en el momento de la inferencia, lo integra en los pesos del modelo durante el entrenamiento. El modelo conoce tu dominio sin necesidad de recuperar nada.

Cómo funciona RAG (y por qué necesita infraestructura)

El pipeline estándar de RAG:

1. Fase de indexación: Divide tus documentos en fragmentos, genera vectores de embedding, almacénalos en una base de datos vectorial
2. Fase de consulta: Convierte la pregunta del usuario en un embedding, busca en la base de datos vectorial fragmentos similares, recupera los 3-5 mejores resultados
3. Fase de generación: Inyecta los fragmentos recuperados en el prompt junto con la pregunta del usuario, envía al LLM

La dependencia del servidor

El paso 2 requiere una búsqueda de similitud vectorial. Del lado del servidor, esto usa bases de datos como Pinecone, Weaviate o pgvector. Son servicios del lado del servidor.

Para móvil, tienes dos opciones:

RAG del lado del servidor: La pregunta del usuario se envía a tu servidor, que realiza la recuperación y llama a la API del LLM. Esta es la arquitectura más común, pero significa que cada consulta requiere un viaje de ida y vuelta por la red. Vuelves a la dependencia de la nube con todos sus problemas: latencia, fallo sin conexión, problemas de privacidad y costos continuos de infraestructura.

RAG en el dispositivo: Almacena la base de datos vectorial localmente en el teléfono. Esto elimina el servidor pero crea nuevos problemas:

• La base de datos vectorial consume 100MB-1GB+ de almacenamiento adicional dependiendo del tamaño de tu corpus
• La generación de embeddings para consultas requiere ejecutar un modelo separado (típicamente 50-100MB)
• SQLite con extensiones vectoriales es la opción más práctica pero tiene capacidad limitada
• La huella total en el dispositivo (LLM + modelo de embeddings + base de datos vectorial) puede superar los 3-4GB
• Actualizar la base de conocimiento requiere descargar nuevos vectores, no solo un cambio de modelo

Cómo funciona Fine-Tuning

Fine-tuning enseña al modelo tu conocimiento de dominio durante el entrenamiento:

1. Preparación de datos: Formatea tu conocimiento de dominio como pares de pregunta-respuesta, conversaciones o ejemplos de instrucción-respuesta
2. Entrenamiento: Ejecuta fine-tuning con LoRA en un modelo base (1-3B parámetros) con tus datos
3. Exportación: Convierte a GGUF, cuantiza, despliega en el dispositivo
4. Inferencia: El modelo responde desde el conocimiento aprendido. Sin paso de recuperación.

El archivo de pesos del modelo es el único artefacto. Sin base de datos vectorial, sin modelo de embeddings, sin infraestructura de recuperación.

La comparación

Cuándo RAG es mejor

RAG tiene ventajas genuinas en escenarios específicos:

Base de conocimiento que cambia rápidamente. Si tu contenido cambia diariamente (noticias, inventario, precios), fine-tuning no puede seguir el ritmo. RAG recupera los documentos más recientes. Pero considera: ¿cuántas funciones de IA móvil realmente necesitan actualizaciones de conocimiento en tiempo real?

Bases de conocimiento muy grandes. Si tu conocimiento de dominio abarca millones de documentos, fine-tuning en un modelo de 1-3B no puede absorberlo todo. RAG recupera el subconjunto relevante. Pero de nuevo: ¿cuántas apps móviles necesitan buscar millones de documentos localmente?

Atribución de fuentes. RAG puede señalar el documento específico que informó su respuesta. Los modelos con fine-tuning no pueden citar fácilmente sus fuentes. Si tu función requiere "aquí está la fuente" junto a la respuesta, RAG tiene ventaja.

Cuándo Fine-Tuning es mejor

Para la mayoría de casos de uso de IA móvil, fine-tuning gana:

Tu conocimiento es estable. Documentación de producto, políticas de empresa, terminología de dominio, reglas de la industria. Estos cambian mensual o trimestralmente, no diariamente. Fine-tuning absorbe este conocimiento de forma limpia.

Tu tarea es específica. Clasificación, resumen, preguntas y respuestas sobre un dominio acotado, generación de contenido en un estilo específico. Estas tareas se benefician del conocimiento profundo de dominio integrado en el modelo, no de la recuperación de documentos.

Necesitas soporte offline. Los modelos con fine-tuning funcionan idénticamente sin conexión. RAG (incluso en el dispositivo) es más lento y complejo offline.

Quieres simplicidad. Un archivo (el modelo GGUF) vs tres componentes (LLM + modelo de embeddings + base de datos vectorial). Menos complejidad significa menos cosas que pueden fallar.

Te importa la velocidad. La inferencia con fine-tuning no tiene paso de recuperación. El tiempo hasta el primer token es 50-200ms vs 200-500ms para RAG en el dispositivo.

El enfoque híbrido

Algunas apps móviles se benefician de un enfoque híbrido:

• Modelo con fine-tuning para conocimiento de dominio, estilo y ejecución de tareas
• Búsqueda local (por palabras clave o SQLite FTS5 simple) para contenido específico del usuario (notas, mensajes, documentos)
• RAG del lado del servidor como mejora opcional cuando hay conexión, para tareas que exceden el conocimiento del modelo en el dispositivo

El modelo con fine-tuning maneja el 90% de las consultas. La búsqueda local maneja el contenido específico del usuario. El RAG del lado del servidor maneja los casos extremos raros que necesitan conocimiento más amplio, pero solo cuando hay conectividad disponible.

Ejemplo práctico

Escenario: Un chatbot de soporte al cliente para una app móvil.

Enfoque RAG: Almacena tus 500 artículos de soporte en una base de datos vectorial. En cada pregunta del usuario, recupera los 3 artículos más relevantes, inyéctalos en el prompt, genera una respuesta. Requiere infraestructura de servidor o 500MB+ de vectores en el dispositivo.

Enfoque fine-tuning: Convierte tus 500 artículos de soporte en 2,000 ejemplos de entrenamiento de pregunta-respuesta. Haz fine-tuning de un modelo 3B. El modelo aprende tu producto, tu terminología y tu estilo de soporte. Despliega el archivo GGUF de 1.7GB. No se necesita recuperación.

Resultado: El modelo con fine-tuning responde desde conocimiento internalizado. Latencia de respuesta: 100-200ms. Almacenamiento: 1.7GB (solo el modelo). Offline: funciona. Costo de infraestructura: $0/mes después del despliegue.

Plataformas como Ertas simplifican el camino de fine-tuning: sube tus artículos de soporte o pares de pregunta-respuesta, entrena con LoRA, exporta GGUF, despliega. El conocimiento de dominio está en el modelo, no en una base de datos.

La decisión

Si tu app móvil necesita IA con conocimiento de dominio:

1. ¿El conocimiento es estable (se actualiza mensualmente o menos)? Fine-tuning.
2. ¿La app necesita funcionar offline? Fine-tuning.
3. ¿La base de conocimiento tiene menos de 10,000 documentos? Fine-tuning.
4. ¿El conocimiento cambia diariamente? Considera RAG del lado del servidor con fine-tuning como respaldo.
5. ¿Necesitas citación de fuentes? Considera RAG para esas funciones específicas.

Para la mayoría de los casos de uso de IA móvil, fine-tuning es más simple, más rápido, más barato y más confiable que RAG.