En productos de ingeniería (soporte técnico, documentación, búsqueda interna, observabilidad, herramientas para desarrolladores), la decisión entre RAG (Retrieval-Augmented Generation) y fine-tuning rara vez es “uno u otro”. Lo correcto es entender qué problema exacto estás resolviendo, qué riesgo toleras (alucinaciones, filtración de datos, regressions), y cómo vas a medir calidad y costo de extremo a extremo.
1) Qué optimiza cada enfoque (y qué no)
RAG: mejor acceso a conocimiento cambiante
- Ventaja principal: incorpora información reciente sin re-entrenar el modelo (docs, tickets, runbooks, PRDs).
- Trade-off: el resultado depende del retrieval (chunking, embeddings, filtros, ranking) y de la capacidad del modelo para “usar” evidencia.
- Riesgo típico: respuestas plausibles pero sin respaldo (baja faithfulness) si el contexto recuperado es irrelevante o insuficiente.
Fine-tuning: mejor comportamiento y formato
- Ventaja principal: mejora consistencia en estilo, estructura, tono, clasificación, extracción y patrones de razonamiento frecuentes en tu dominio.
- Trade-off: no “aprende” instantáneamente tu conocimiento cambiante; si tu información rota semanalmente, el tuning se queda atrás.
- Riesgo típico: overfitting, regressions, y costo operacional de datasets/entrenamientos/validación.
Regla práctica: si el problema es “¿qué dice nuestra fuente de verdad hoy?”, empieza con RAG. Si el problema es “¿cómo debe responder/actuar el sistema?” (formato, decisión, clasificación, pasos), considera fine-tuning o instrucciones + ejemplos.
2) Métricas: no midas solo “accuracy”
En producción, un asistente falla por múltiples puntos: recuperación, prompt, modelo, políticas, UX. Por eso conviene separar métricas por capa y luego medir el impacto final.
Métricas de retrieval (RAG)
- Recall@k: en qué % de casos al menos un documento relevante aparece en los
kprimeros. - MRR / nDCG: calidad del ranking (relevantes más arriba = mejor).
- Cobertura de fuente: % de respuestas con evidencia citada desde repositorios “permitidos” (runbooks vs chats).
- Freshness: antigüedad promedio de los documentos usados cuando el caso requiere actualidad.
Métricas de generación (RAG y tuning)
- Answer Relevance: responde lo que se preguntó (no divaga).
- Faithfulness / Groundedness: lo afirmado está soportado por el contexto provisto.
- Citation precision/recall: las citas apuntan a evidencia correcta (y no omiten evidencia clave).
- Formato/estructura: cumplimiento de esquema (JSON válido, checklist, pasos reproducibles).
Métricas de producto (las que deciden)
- Tiempo a resolución: soporte, incidentes, debugging.
- Deflection rate: % de consultas que no requieren escalamiento humano.
- CSAT/QA: revisión humana por muestreo (incluye severidad de fallo).
- Latencia P50/P95 y costo por tarea: tokens + retrieval + reranking + tool calls.
- Regressions: comparación contra baseline (modelo anterior/prompt anterior) con umbrales de alerta.
3) Evaluación: offline, online y “red-team”
Offline (antes de desplegar)
Construye un set de evaluación representativo: tickets reales anonimizados, preguntas frecuentes internas, incidentes, tareas de ingeniería. Etiqueta lo mínimo viable: respuesta esperada, fuentes correctas, y criterios de fallo.
- Golden set: 200–1000 casos con etiquetas estables para detectar regressions.
- Stress set: casos raros: ambigüedad, docs contradictorias, cambios recientes, queries largas.
- Adversarial: prompt injection, solicitudes fuera de política, y “jailbreaks” contextualizados.
Online (A/B o shadow)
Cuando el riesgo es alto, usa shadow mode: el sistema responde “en paralelo” sin afectar al usuario y solo registras métricas. Luego pasas a A/B con guardrails.
Revisión humana con severidad
No basta “correcto/incorrecto”. Clasifica fallos por severidad:
- Sev1: inventa comandos peligrosos, recomienda cambios de infraestructura riesgosos, expone datos.
- Sev2: respuesta incorrecta que puede causar retrabajo significativo.
- Sev3: respuesta incompleta, pero útil con ajustes.
4) Comparativa operativa (con ejemplos reales de ingeniería)
| Caso | RAG | Fine-tuning |
|---|---|---|
| Asistente de soporte con runbooks que cambian | Excelente: recupera runbook vigente + tickets similares | Útil para plantillas de respuesta y clasificación, no para “último procedimiento” |
| Búsqueda de código/arquitectura interna | Buena si indexas repos y diagramas; sensible a chunking | Mejora patrones de explicación y resúmenes, pero no sustituye indexación |
| Generación de tests con estilo del equipo | Ayuda si recuperas ejemplos similares; a veces inconsistente | Fuerte: aprende convenciones, frameworks y estructura esperada |
| Extracción a JSON (incidentes, postmortems, logs) | No es necesario salvo para definiciones y catálogos | Muy efectivo: alta tasa de cumplimiento de esquema |
5) Diseño de un RAG que funcione en productos de ingeniería
Chunking y metadatos
En ingeniería, el contexto útil suele ser estructurado: secciones de runbooks, snippets de código, decisiones de arquitectura. Evita chunks demasiado grandes (ruido) o demasiado pequeños (pierde sentido). Añade metadatos: repositorio, servicio, versión, entorno, fecha, owner.
Reranking y filtros por “fuente de verdad”
Si mezclas wiki, chats y tickets, el modelo puede “preferir” anécdotas. Prioriza documentos con autoridad: runbooks aprobados, RFCs, docs versionadas. Un reranker mejora relevancia cuando el embedding por sí solo no captura intención.
Citas y respuestas condicionadas
Para reducir riesgo, fuerza un patrón: respuesta + citas + incertidumbre. Si no hay evidencia suficiente, el asistente debe decirlo y pedir información (servicio, entorno, versión, logs).
6) Cuándo (sí) hacer fine-tuning en un producto
El fine-tuning paga cuando tienes: (1) un patrón de tareas repetible, (2) ejemplos de alta calidad, y (3) una definición clara de “correcto”. Situaciones comunes:
- Clasificación y routing: categorizar tickets, asignar equipo, priorizar severidad con criterios internos.
- Salida estructurada: extraer campos de incidentes, changelogs, resúmenes técnicos a JSON/plantillas.
- Estilo y consistencia: respuestas con tono de marca, formato de runbook, pasos reproducibles.
- Reducción de prompts enormes: si dependes de instrucciones largas, tuning puede estabilizar.
7) Estrategia híbrida: RAG + tuning (lo más común)
Una receta práctica: usa RAG para el conocimiento (qué hay en tus fuentes) y un modelo ajustado para el comportamiento (cómo responde, qué estructura sigue, cómo cita). Esto suele mejorar métricas de groundedness y formato sin perder frescura.
8) Un marco de decisión (rápido y accionable)
- Define el output: texto libre vs JSON vs acción (tool call). Si es estructura estricta, tuning gana.
- Define la “fuente de verdad”: si cambia rápido, RAG es obligatorio.
- Mide por capa: retrieval (Recall@k), generación (faithfulness) y producto (tiempo/costo).
- Controla el riesgo: políticas, citas, límites de acciones, y fallback a humano en Sev1.
- Itera con regressions: cualquier mejora debe mantener (o mejorar) umbrales en el golden set.
Si quieres llevar esto a práctica, tu próximo paso es construir un dataset de evaluación con casos reales y definir un tablero mínimo: Recall@k, faithfulness, tasa de escalamiento y costo por tarea. Con eso, la decisión RAG vs fine-tuning deja de ser opinión y se vuelve ingeniería.