NLP para clasificación de documentos: implementación práctica
El problema que todos tienen y pocos automatizan
Toda organización clasifica documentos. Facturas que van a contabilidad. Contratos que van a legal. Albaranes que van a logística. Reclamaciones que van a atención al cliente. Notificaciones judiciales que van al abogado correspondiente según la materia.
En la mayoría de las empresas, este proceso es manual: alguien abre el documento, lo lee (o al menos lo escanea con los ojos), decide de que tipo es y lo envía al destino correcto. Funciona con 10 documentos al día. Se rompe con 200. Y se convierte en cuello de botella con 1.000.
La clasificación automática de documentos con NLP (Natural Language Processing) resuelve este problema. No es ciencia ficción ni requiere un equipo de PhD. Con las herramientas actuales, un equipo de ingeniería competente puede tener un clasificador en producción en 4-8 semanas.
Pero la diferencia entre un prototipo que funciona en un notebook y un sistema que clasifica documentos reales en producción con un 95% de precisión es considerable. Este artículo cubre el camino completo.
Elegir el enfoque: tres opciones en 2025
Opción 1: LLM vía API (rápido, caro a escala)
El camino más rápido: enviar el documento a GPT-4, Claude o Gemini con un prompt que diga “clasifica este documento en una de estas categorías: [lista]” y parsear la respuesta.
Funciona sorprendentemente bien para prototipos y volúmenes bajos (< 100 documentos/día). La precisión out-of-the-box suele estar entre 85-92% para categorías bien definidas. No necesitas datos de entrenamiento, no necesitas infraestructura de ML, y la implementación se hace en un día.
El problema: coste y latencia. Clasificar un documento de 3 páginas con GPT-4 cuesta aproximadamente 0.02-0.05 USD (dependiendo de la longitud). Para 1.000 documentos diarios, eso son 600-1.500 USD al mes solo en clasificación. La latencia es de 2-5 segundos por documento, lo que puede ser inaceptable para flujos en tiempo real. Y dependes de un servicio externo para una función crítica.
Cuándo tiene sentido: prototipo rápido, volumen bajo, presupuesto disponible, o cuando las categorías cambian frecuentemente y no quieres reentrenar modelos.
Opción 2: Modelo pre-entrenado con fine-tuning (equilibrado)
Coges un modelo de lenguaje pre-entrenado (BERT, RoBERTa, DeBERTa, o sus variantes multilingües) y lo fine-tuneas con tus datos etiquetados para que clasifique tus categorías específicas.
El proceso: recopilas 200-500 documentos etiquetados por categoría (más si las categorías son ambiguas), fine-tuneas el modelo durante 3-5 epochs, evalúas con un test set, iteras. El resultado es un modelo que corre en tu infraestructura, clasifica un documento en 50-200ms, y cuesta prácticamente cero por inferencia.
La precisión típica con 300+ ejemplos por categoría: 93-97% para categorías bien definidas. Superior a la opción LLM vía API para categorías específicas de tu dominio, porque el modelo ha visto tus documentos reales.
Para documentos en español, BETO (BERT entrenado en corpus español) o XLM-RoBERTa (multilingüe) son los puntos de partida recomendados. Para inglés, DeBERTa-v3 es el que mejor rendimiento ofrece en benchmarks de clasificación.
Opción 3: Modelo clásico de ML (ligero, suficiente para muchos casos)
Si tus documentos son razonablemente distintos entre categorías (una factura no se parece a un contrato), un modelo clásico con TF-IDF + clasificador lineal (Logistic Regression, SVM) puede alcanzar 90-94% de precisión con mucho menos complejidad y coste que un transformer.
Este enfoque tiene sentido cuando: el volumen de documentos etiquetados es muy alto (> 10.000), la velocidad de inferencia es crítica (1-5ms por documento), o el equipo no tiene experiencia con deep learning y necesita algo mantenible.
No lo descartéis por “antiguo.” Hemos visto proyectos donde un SVM con features bien seleccionadas supera a un BERT fine-tuneado mal configurado. La herramienta correcta es la que tu equipo puede mantener en producción.
El flujo de etiquetado: dónde se gana o se pierde
El modelo es tan bueno como sus datos de entrenamiento. Y los datos de entrenamiento para clasificación de documentos necesitan etiquetas humanas. El flujo de etiquetado es, en la práctica, la fase más crítica y más subestimada del proyecto.
Definir las categorías
Parece obvio, pero no lo es. Las categorías deben ser:
- Mutuamente excluyentes. Un documento pertenece a una y solo una categoría. Si “factura-proveedor” y “factura” son dos categorías, el modelo va a confundirse porque son ambiguas.
- Exhaustivas. Toda documento que entre en el sistema debe encajar en alguna categoría. Si llega un tipo de documento no previsto, necesitas una categoría “otro” o un mecanismo de detección de outliers.
- Equilibradas (idealmente). Si tienes 2.000 facturas y 50 notificaciones judiciales, el modelo va a sesgar hacia facturas. Soluciones: oversampling de las categorías minoritarias, undersampling de las mayoritarias, o ajustar class weights en el entrenamiento.
En nuestros despliegues para despachos legales, las categorías típicas son: demanda, contestación, sentencia, auto, providencia, notificación, requerimiento, y otros. Para empresas logísticas: factura, albarán, packing list, BL (bill of lading), certificado de origen, DUA, y otros.
Herramientas de etiquetado
No etiquetes en un Excel. Usa una herramienta de annotation:
Label Studio (open source) es nuestra elección. Soporta texto, imágenes y documentos. Permite múltiples anotadores, cálculo de inter-annotator agreement, y exportación directa a formatos de entrenamiento. Se despliega en 10 minutos con Docker.
Prodigy (comercial, creadores de spaCy) es más eficiente para anotadores individuales con su interfaz de anotación activa. Más caro, pero reduce el tiempo de etiquetado un 30-50% gracias a su algoritmo de active learning que prioriza los documentos más informativos.
Cuántos documentos etiquetar
Regla práctica que hemos validado:
| Categorías | Documentos/categoría | Total mínimo |
|---|---|---|
| 3-5 | 200-300 | 600-1.500 |
| 6-10 | 300-500 | 1.800-5.000 |
| 11-20 | 500+ | 5.500+ |
Estos números son para fine-tuning de transformers. Para modelos clásicos (TF-IDF + SVM), necesitas 2-3x más. Para LLMs vía API, necesitas 0 (zero-shot) o 5-10 por categoría (few-shot).
La calidad importa más que la cantidad. 200 documentos perfectamente etiquetados superan a 1.000 con etiquetas ruidosas. Invierte en definiciones claras de categorías y en revisión de etiquetas.
Fine-tuning paso a paso
El flujo técnico para fine-tuning de un transformer (el caso más común en nuestros proyectos):
1. Preprocesamiento. Extraer texto de los documentos (PDF a texto con PyMuPDF o pdfplumber; imágenes con OCR vía Tesseract o un servicio como AWS Textract). Limpiar el texto: eliminar headers/footers repetidos, normalizar espacios, truncar a la longitud máxima del modelo (512 tokens para BERT, 1024 para modelos más recientes).
2. Split train/val/test. 70% train, 15% validation, 15% test. Estratificado por categoría para mantener las proporciones. El test set nunca se toca durante el entrenamiento; es tu métrica de verdad.
3. Entrenamiento. Usamos Hugging Face Transformers + PyTorch. Hiperparámetros iniciales: learning rate 2e-5, batch size 16, 3-5 epochs, warmup del 10%. Early stopping basado en F1-score en el validation set. Para BERT-base en español, el fine-tuning en una GPU A10 (disponible en Railway o en Lambda Labs por 0.73 USD/hora) tarda 15-30 minutos para un dataset de 2.000 documentos.
4. Evaluación. F1-score ponderado en el test set. Matriz de confusión para identificar dónde el modelo se equivoca. Si dos categorías se confunden sistemáticamente, el problema suele estar en la definición de las categorías, no en el modelo.
5. Calibración de confianza. El modelo produce probabilidades, no certezas. Calibramos un umbral de confianza: si la probabilidad de la categoría predicha es inferior al 85%, el documento se marca para revisión humana. Esto crea un flujo human-in-the-loop donde el modelo clasifica automáticamente el 80-90% de los documentos y escala los ambiguos a un operador.
Despliegue en producción
Un modelo en un Jupyter notebook no es un producto. El despliegue en producción requiere:
Servicio de inferencia. El modelo empaquetado como una API REST. Usamos FastAPI + uvicorn con el modelo cargado en memoria al arrancar. Para transformers, ONNX Runtime reduce la latencia de inferencia un 2-3x frente a PyTorch nativo. Para volúmenes altos, TorchServe o Triton Inference Server ofrecen batching y múltiples workers.
Pipeline de documentos. Un flujo que recibe el documento (vía API, email o carpeta compartida), extrae el texto, llama al servicio de inferencia, y ejecuta la acción correspondiente (mover a carpeta, crear tarea en Zoho, enviar a la persona adecuada). Airflow o Prefect para orquestar el flujo.
Monitorización. La precisión del modelo se degrada con el tiempo (data drift). Monitorizamos la distribución de confianza del modelo semanalmente. Si el porcentaje de documentos con confianza baja (< 85%) sube significativamente, es señal de que algo ha cambiado: nuevos tipos de documentos, cambios en el formato, o cambios en el vocabulario. Eso dispara un ciclo de re-etiquetado y re-entrenamiento.
Reentrenamiento. Los documentos que el modelo escala a revisión humana se convierten en nuevos datos de entrenamiento. El operador que revisa el documento confirma o corrige la categoría, y ese dato se incorpora al dataset de entrenamiento. Reentrenamos mensualmente o cuando la precisión cae por debajo del umbral aceptable (95% en nuestro caso).
Caso real: clasificación de notificaciones judiciales
Un despacho de abogados con 15 abogados y 4 áreas de práctica (civil, mercantil, laboral, penal) recibía 80-120 notificaciones judiciales al día por LexNET y DEHu. Cada notificación necesitaba ser clasificada por tipo (demanda, sentencia, auto, providencia, requerimiento) y asignada al abogado responsable según la materia y el número de procedimiento.
Un administrativo dedicaba 3 horas diarias a este triaje. El error humano (asignar una notificación al abogado equivocado) ocurría 2-3 veces por semana, con consecuencias potencialmente graves (plazos perdidos).
Implementamos un clasificador basado en BETO fine-tuneado con 1.800 notificaciones etiquetadas (6 categorías). El modelo alcanza un 96.2% de F1-score en el test set. Los documentos con confianza inferior al 90% (aproximadamente el 8% del total) se escalan a revisión humana.
Resultado: el triaje automático redujo el tiempo de clasificación de 3 horas a 20 minutos diarios (solo revisión de los escalados). Los errores de asignación bajaron de 2-3 semanales a 0-1. El ROI se alcanzó en 5 semanas.
Caso real: clasificación de documentos de envío
Una empresa logística procesaba 500+ documentos diarios asociados a envíos internacionales: facturas comerciales, packing lists, bills of lading, certificados de origen, DUAs, certificados fitosanitarios. Cada documento debía vincularse al expediente de envío correcto y clasificarse para su proceso aduanero.
El clasificador combina OCR + NLP + reglas de negocio. El OCR extrae texto de los PDFs (muchos son escaneos de mala calidad; usamos AWS Textract que maneja esto razonablemente bien). El modelo NLP (XLM-RoBERTa fine-tuneado con 3.200 documentos) clasifica el tipo de documento. Reglas de negocio extraen el número de referencia del envío y vinculan el documento al expediente.
Precisión de clasificación: 94.8%. Los documentos no clasificados con confianza se escalan a un operador que los revisa en una interfaz web y corrige la clasificación. Cada corrección alimenta el ciclo de reentrenamiento.
Errores que evitar
No midas solo accuracy. Un clasificador que predice “factura” para todo tiene 70% de accuracy si el 70% de tus documentos son facturas. Usa F1-score ponderado, precisión y recall por categoría. La matriz de confusión es tu mejor amiga.
No ignores la extracción de texto. Si el OCR produce basura, el clasificador NLP no puede hacer magia. Invierte en un OCR de calidad (Textract, Google Document AI) y en preprocesamiento de imágenes (binarización, corrección de rotación) antes de preocuparte por el modelo de clasificación.
No lances sin human-in-the-loop. Ningún modelo tiene 100% de precisión. Necesitas un flujo para los documentos que el modelo no clasifica con confianza. Si despliegas sin este flujo, vas a tener documentos mal clasificados que nadie detecta hasta que es demasiado tarde.
No entrenes con datos desequilibrados sin compensar. Si tu dataset tiene 2.000 facturas y 50 sentencias, el modelo aprenderá a ignorar las sentencias. Class weights, oversampling (SMOTE para features tabulares, duplicación + augmentation para texto) o focal loss resuelven el problema.
La clasificación de documentos con NLP no es el proyecto de IA más espectacular, pero es posiblemente el que mejor ratio esfuerzo-valor ofrece para la mayoría de las organizaciones. El volumen de documentos crece cada año. La capacidad de procesarlos manualmente, no. Para profundizar en cómo la gestión documental legal evoluciona de OCR a comprensión semántica, consulta nuestro artículo sobre gestión documental legal con IA. Y para llevar estos modelos a producción con las métricas adecuadas, nuestro whitepaper sobre MLOps cubre el proceso completo.
