Elegir entre un modelo de lenguaje grande (LLM) y un pipeline clásico de procesamiento de lenguaje natural (NLP) no es una cuestión de moda, sino de encaje técnico. Esta lista de comprobación está pensada para que la uses como filtro antes de comprometer presupuesto, infraestructura o un equipo entero en una dirección equivocada. Cada punto incluye el matiz que solemos aprender a golpes: cuándo la respuesta obvia falla.
Cómo usar esta checklist
No es un cuestionario de sí o no. Marca cada casilla con evidencia (una prueba, un documento, una medición), no con una intuición. Si no puedes rellenar una casilla con datos, esa casilla es precisamente donde tu proyecto se romperá en producción.
1. Define la tarea con precisión quirúrgica
1.1 ¿Es una tarea cerrada o abierta?
Clasificar 40.000 tickets en 12 categorías fijas es una tarea cerrada. Resumir conversaciones heterogéneas es una tarea abierta. Los modelos tradicionales (regresión logística sobre TF-IDF, SVM, CRF para etiquetado de secuencias, modelos de temas como LDA) siguen siendo competitivos en tareas cerradas con vocabulario estable y fronteras bien definidas. Los LLM brillan cuando la salida no se puede enumerar de antemano.
1.2 ¿La etiqueta correcta es inequívoca?
Si dos personas expertas no coinciden al etiquetar el mismo ejemplo, un LLM tenderá a producir respuestas plausibles pero inconsistentes entre ejecuciones, y un modelo clásico simplemente aprenderá el ruido. Antes de elegir tecnología, mide el acuerdo entre anotadores. Sin esa métrica, cualquier comparación posterior es humo.
1.3 ¿Necesitas extracción estructurada o generación?
Extraer entidades, relaciones y fechas de contratos es un problema de extracción. Un LLM puede hacerlo con formato JSON forzado, pero un modelo de reconocimiento de entidades entrenado con datos propios suele ser más barato por documento, más rápido y más estable ante variaciones de formato. La generación libre, en cambio, es territorio casi exclusivo de los LLM.
2. Audita tus datos antes de auditar modelos
2.1 Volumen y desbalanceo
Con 300 ejemplos etiquetados por clase, un modelo clásico bien ajustado puede ser suficiente. Con 30, ninguno de los dos funcionará bien, y el LLM necesitará ejemplos en el prompt (aprendizaje en contexto) o ajuste fino, que no sale gratis. Comprueba el desbalanceo: en clasificación de fraude o de incidencias críticas, la clase minoritaria es la que importa y la que menos datos tiene.
2.2 Dominio y jerga
Un LLM generalista conoce el español estándar, pero no necesariamente la jerga interna de tu empresa, códigos de producto o abreviaturas de tu sector. Los modelos clásicos tampoco, pero su entrenamiento es más barato y puedes inyectar vocabulario controlado sin reentrenar un modelo de miles de millones de parámetros.
2.3 Sensibilidad y residencia del dato
Si el texto contiene datos personales, historiales clínicos o información bajo secreto contractual, enviar cada documento a una API externa exige una evaluación de riesgos que muchas organizaciones no han hecho. Los modelos clásicos se ejecutan en tu propia infraestructura con menos superficie de exposición. Los LLM autoalojados existen, pero cambian por completo el cálculo de costes y de equipo necesario.
3. Calcula el coste real, no el coste por token
3.1 Coste por inferencia frente a coste por mantenimiento
El precio por token de un LLM parece bajo hasta que multiplicas por millones de documentos y añades reintentos, validaciones y tokens de contexto. Un modelo clásico tiene un coste de inferencia casi despreciable, pero arrastra un coste de mantenimiento: reentrenamientos periódicos, gestión de features, deriva del modelo (data drift). La pregunta correcta no es cuál es más barato hoy, sino cuál lo será dentro de dos años con tu volumen proyectado.
3.2 Latencia y experiencia de usuario
Un clasificador lineal responde en milisegundos; una llamada a un LLM con contexto largo puede tardar segundos. Si la tarea está en la ruta crítica de una interfaz (autocompletado, moderación en tiempo real, enrutamiento de chats), esa diferencia es decisiva. He visto equipos migrar un clasificador de intenciones a un LLM y descubrir que el tiempo de respuesta se multiplicaba por diez sin mejora perceptible en la precisión.
3.3 Coste de evaluación
Evaluar un LLM es más caro y más difuso que evaluar un clasificador: necesitas conjuntos de referencia, criterios de calidad a veces subjetivos y revisión humana. Presupuesta ese esfuerzo antes de empezar; según documentación del sector, la evaluación suele consumir más tiempo del previsto.
4. Comprueba la reproducibilidad y la auditabilidad
4.1 ¿Necesitas explicar cada decisión?
En sectores regulados (seguros, banca, salud, administración pública) a menudo hay que justificar por qué un sistema rechazó una solicitud. Un modelo de regresión con coeficientes interpretables o un árbol de decisión se explica con relativa facilidad. Un LLM genera una justificación en lenguaje natural que puede sonar convincente y no corresponder al razonamiento real. La explicabilidad aparente es un riesgo, no una ventaja.
4.2 ¿La salida debe ser idéntica ante la misma entrada?
Los LLM con muestreo estocástico no lo garantizan. Puedes fijar temperatura a cero, pero eso no elimina todas las fuentes de variación (versiones del modelo, cambios del proveedor, contexto). Los modelos clásicos son deterministas por diseño. Si tu caso de uso exige auditoría repetible, esto pesa más que unos puntos de precisión.
4.3 Versionado y dependencia de proveedor
Un LLM alojado puede cambiar de comportamiento sin aviso cuando el proveedor actualiza el modelo. Tu pipeline clásico solo cambia cuando tú lo cambias. Documenta cómo vas a fijar versiones y qué harás si el proveedor retira la que usas.
5. Valora el esfuerzo de ingeniería y el equipo
5.1 ¿Tienes quien mantenga prompts o quien mantenga features?
Un LLM traslada el trabajo desde la ingeniería de características hacia el diseño de prompts, la validación de salidas y las pruebas de regresión. Un modelo clásico exige perfiles más orientados a datos y estadística. Ninguna de las dos rutas es gratis; elige la que tu equipo pueda sostener en el tiempo.
5.2 Salidas no estructuradas y validación
Si el LLM devuelve texto libre, necesitarás capas de validación, reintentos y manejo de errores. Si devuelve JSON forzado, necesitarás esquemas estrictos y tolerancia a fallos de formato. Cuenta esas piezas en el diseño; no son un detalle.
5.3 Pruebas de regresión
Con modelos clásicos, una suite de pruebas con métricas fijas suele bastar. Con LLM, conviene mantener un conjunto dorado de casos y comparar respuestas entre versiones, aceptando cierta variabilidad. Si no tienes ese conjunto, no tienes forma de saber si una actualización mejoró o empeoró el sistema.
6. Revisa las limitaciones que nadie menciona en las demos
6.1 Alucinaciones en tareas de extracción
Un LLM puede inventar una fecha que no aparece en el documento si el formato se lo sugiere. En extracción de datos, esto es un fallo silencioso y peligroso. Los modelos clásicos de etiquetado de secuencias tienen sus propios errores, pero suelen ser errores de omisión o de frontera, no invenciones.
6.2 Degradación con entradas largas o ruidosas
El rendimiento de un LLM cae cuando el texto es muy largo, contiene tablas mal convertidas o mezcla idiomas. En un caso real de clasificación de correos de soporte, el pipeline clásico con limpieza específica superaba al LLM en los mensajes con citas anidadas y firmas, porque esas partes confundían al modelo generativo. La lección: la limpieza previa importa en ambos mundos, y a menudo más que el modelo elegido.
6.3 Idiomas y variantes dialectales
Un LLM multilingüe puede funcionar aceptablemente en muchos idiomas, pero un modelo clásico entrenado con datos locales puede superarlo en una variante concreta. Si tu corpus es muy específico, prueba antes de asumir que el modelo grande gana.
6.4 Lo que no funciona bien con LLM
Tareas de altísima precisión con consecuencias legales, decisiones que deben ser idénticas y auditables, procesamiento masivo con latencia mínima y presupuesto ajustado, y clasificación de vocabulario muy cerrado con datos etiquetados abundantes. En esos casos, el LLM añade coste y opacidad sin ventaja clara.
6.5 Lo que no funciona bien con modelos clásicos
Generación de texto coherente, resumen abstractivo, diálogo abierto, adaptación a instrucciones nuevas sin reentrenar y comprensión de matices pragmáticos (ironía, intención implícita). Forzar un modelo clásico a hacer esto produce resultados rígidos y frágiles.
7. Diseña el experimento antes de decidir
7.1 Conjunto de evaluación representativo
Reúne ejemplos reales, incluidos los casos raros y los ambiguos. Un conjunto de evaluación sesgado hacia casos fáciles favorece al LLM porque impresiona en lo general; los casos difíciles son los que revelan diferencias.
7.2 Métricas alineadas con el negocio
Precisión, exhaustividad y F1 son el punto de partida, pero pregunta qué error cuesta más. En moderación de contenido, un falso negativo puede ser grave; en clasificación de leads, un falso positivo molesta al equipo comercial. La métrica debe reflejar esa asimetría.
7.3 Prueba híbrida
La dicotomía es falsa en muchos casos. Un patrón habitual es usar un modelo clásico para filtrar el 80% de los casos fáciles y reservar el LLM para los ambiguos. O usar embeddings y búsqueda semántica (herederos de técnicas clásicas) junto a un LLM para generar la respuesta final. Documenta esa arquitectura como una opción más, no como un fracaso de la comparación.
8. Checklist final de decisión
- He definido la tarea y sé si es cerrada o abierta.
- He medido el acuerdo entre anotadores humanos.
- Conozco el volumen, el desbalanceo y la calidad de mis datos.
- He calculado coste por inferencia y coste de mantenimiento a dos años.
- He comprobado la latencia admisible en mi caso de uso.
- Sé si necesito explicabilidad y reproducibilidad estricta.
- Tengo un plan de versionado y dependencia de proveedor.
- Mi equipo puede sostener el enfoque elegido (prompts o features).
- He identificado los fallos silenciosos peligrosos en mi dominio.
- He probado ambos enfoques con un conjunto de evaluación representativo.
- He considerado una arquitectura híbrida antes de descartarla.
Si has marcado todo con evidencia y no con intuición, la decisión entre LLM y NLP clásico deja de ser una apuesta y se convierte en una elección documentada. Y si aún no puedes marcar alguna casilla, esa es tu siguiente tarea, no la elección del modelo.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.