La pregunta ya no es si los LLMs son mejores que los modelos tradicionales de NLP. La pregunta útil es: ¿qué pieza de mi pipeline necesita cada enfoque? Esta lista de comprobación está pensada para equipos que ya tienen un producto en producción y dudan entre reemplazar su stack clásico (spaCy, scikit-learn, regex, CRF, embeddings estáticos) por un modelo generativo, o mantener ambos.
Cada punto es una decisión verificable, no una opinión. Si marcas menos de la mitad, probablemente no necesites migrar todavía.
1. Define la tarea antes de elegir tecnología
1.1 ¿Es extracción cerrada o comprensión abierta?
Si necesitas extraer campos con un esquema fijo (fechas, importes, CIF, entidades de un dominio concreto), un modelo supervisado tradicional con etiquetado propio suele ganar en precisión y coste. Los LLMs brillan cuando el esquema cambia cada semana o cuando la salida requiere razonamiento sobre el texto.
1.2 ¿Necesitas reproducibilidad exacta?
Un clasificador de regresión logística sobre TF-IDF devuelve la misma predicción con la misma entrada. Un LLM con temperatura mayor que cero, no. Si tu producto es auditoría, cumplimiento normativo o scoring, la determinación exacta pesa más que la fluidez.
1.3 ¿Hay una métrica de referencia?
Antes de cambiar nada, fija una línea base: F1 por clase en un conjunto de test congelado. Según documentación de proveedores de NLP clásico, en tareas de clasificación de texto con categorías bien definidas y miles de ejemplos etiquetados, los modelos lineales suelen alcanzar valores cercanos a los de modelos grandes, con una fracción del coste. Si no tienes esa línea base, no puedes justificar la migración.
2. Comprueba el coste real, no el de la demo
2.1 Latencia por petición
Un modelo clásico en CPU responde en milisegundos. Un LLM en la nube añade latencia de red y de generación. Para un buscador interno o un autocompletado, esa diferencia es visible para el usuario. Esto no funciona para X: no uses un LLM en el camino crítico de una interfaz que exige respuesta por debajo de 200 ms salvo que tengas caché agresiva o modelo local pequeño.
2.2 Coste por volumen
Haz la cuenta con tu tráfico real: tokens de entrada medios × peticiones × precio del modelo. Un clasificador tradicional entrenado una vez cuesta prácticamente lo mismo a 10.000 que a 10 millones de inferencias. Muchos equipos descubren en producción que el 80% de sus llamadas son a tareas triviales que un modelo clásico resolvía igual.
2.3 Coste de mantenimiento del etiquetado
El modelo clásico exige anotar datos. El LLM exige redactar prompts, evaluar sistemáticamente y vigilar cambios de versión del proveedor. Ambos tienen coste humano; elige el que tu equipo pueda sostener.
3. Verifica la calidad con datos propios
3.1 Prueba en el dominio, no en benchmarks públicos
Un LLM puede puntuar alto en un benchmark general y fallar en tu jerga. Caso concreto que aparece con frecuencia en equipos de soporte: un modelo clásico entrenado con tickets históricos identificaba correctamente la categoría de reclamación de facturación porque aprendió las abreviaturas internas de la empresa; el LLM general, sin ejemplos de esas abreviaturas en el prompt, las confundía con nombres de producto. La solución no fue descartar el LLM, sino añadir un paso de normalización previa con el modelo clásico.
3.2 Evalúa con estratificación por dificultad
Separa tu test en casos fáciles, ambiguos y adversariales. Es habitual que el LLM gane en ambiguos y empate o pierda en fáciles. Si tu distribución real es mayoritariamente fácil, el promedio engaña.
3.3 Mide alucinación, no solo acierto
En extracción, un campo inventado es peor que un campo vacío. Los modelos clásicos fallan devolviendo la etiqueta más probable; los LLMs pueden fabricar el valor. Define una métrica de abstención correcta.
4. Revisa requisitos de privacidad y despliegue
4.1 ¿Los datos pueden salir de tu infraestructura?
Si el texto contiene datos personales, contratos o información médica, el envío a una API externa exige revisión legal. Un modelo clásico local elimina ese vector por completo. Los LLMs autoalojados existen, pero cambian el perfil de coste: necesitas GPU y alguien que la mantenga.
4.2 ¿Necesitas funcionar sin conexión?
Dispositivos en campo, kioscos, entornos industriales: el modelo clásico embebido sigue siendo la opción pragmática. Un LLM pequeño cuantizado puede correr en local, pero su calidad en tareas complejas cae y debe validarse tarea por tarea.
5. Comprueba si el problema es de datos, no de modelo
5.1 Volumen de etiquetas disponibles
Con menos de unos cientos de ejemplos por clase, el modelo clásico se queda corto y el LLM con few-shot parte con ventaja. Con decenas de miles, la ventaja se estrecha y el coste por inferencia se vuelve el factor decisivo.
5.2 Deriva del dominio
Si tu vocabulario cambia rápido (nuevos productos, nuevas jergas), el modelo clásico se degrada y hay que reentrenar. El LLM absorbe mejor el cambio sin reentrenamiento, pero introduce variabilidad. Un patrón robusto es usar el LLM para generar etiquetas nuevas y el modelo clásico para servir a escala.
5.3 Idiomas y variedades
Los modelos clásicos multilingües existen, pero su rendimiento en variedades dialectales o en texto informal es irregular. Los LLMs suelen generalizar mejor en idiomas de bajos recursos. Aun así, verifica con muestras reales: no des por hecho que un modelo grande entiende tu variante local mejor que un modelo entrenado con tus datos.
6. Decide la arquitectura híbrida antes que la sustitución
6.1 Patrón de dos etapas
Modelo clásico para filtrar y clasificar el volumen alto; LLM solo para los casos que superan un umbral de confianza. Reduce coste y mantiene la calidad donde importa.
6.2 Patrón de generación de datos
Usa el LLM para etiquetar un lote inicial, revisa una muestra humana y entrena un modelo clásico con esas etiquetas. Es una forma documentada en la práctica de reducir el coste de anotación sin renunciar a un servidor determinista.
6.3 Patrón de respaldo
Si el LLM falla o devuelve una salida que no valida el esquema, cae al modelo clásico. Nunca dejes que un fallo de la API externa rompa tu flujo completo.
7. Lista de comprobación final antes de tocar producción
- ☐ Tengo una línea base medida con mi propio test, no con benchmarks públicos.
- ☐ He calculado coste y latencia con mi volumen real, no con una demo.
- ☐ Sé qué tareas requieren determinismo y cuáles toleran variabilidad.
- ☐ He revisado privacidad y ubicación de los datos con quien corresponda.
- ☐ Tengo una métrica de abstención, no solo de acierto.
- ☐ Existe un plan de respaldo si el proveedor cambia el modelo.
- ☐ He probado el enfoque híbrido antes de sustituir por completo.
- ☐ Documenté qué no sé: límites del modelo en mi dominio y casos sin cubrir.
Ninguno de estos puntos garantiza resultados. La evidencia del sector apunta a que los equipos que mantienen ambos enfoques obtienen mejor relación calidad-coste que los que apuestan todo a una sola tecnología, pero cada dominio tiene sus excepciones y conviene medirlas.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.