¿Python vs Rust para NLP en producción? ¿Está NLTK/Spacy obsoleto frente a Hugging Face?

Cooking

Llevo años en NLP y veo una división brutal. Por un lado, el ecosistema Python (PyTorch, TensorFlow, spaCy, Transformers) domina la investigación y prototipado. Por otro, cada vez más empresas piden Rust (o Go) para microservicios de inferencia por temas de rendimiento y seguridad de memoria.

Mi debate: ¿Vale la pena reescribir pipelines de NLP en Rust para ganar un 30-40% de velocidad, o es mejor optimizar Python con Cython/ONNX Runtime? ¿Y qué pasa con frameworks "clásicos" como NLTK? ¿Los modelos de Hugging Face los han dejado obsoletos para tareas serias?

Ejemplo de mi dilema en Python:

# Esto es lento en grandes volúmenes
texts = ["...", "..."]
results = [pipeline(t, model="dslim/bert-base-NER") for t in texts]

¿Alternativa en Rust? ¿O simplemente usar batch processing y llamarlo un día?

Pottery

Rust es una exageración para el 90% de los casos. He migrado un servicio de clasificación de texto de Flask a Rust (usando tokenizers de HF y ONNX) y la ganancia real en latencia fue del 15%, con el triple de tiempo de desarrollo. El cuello de botella suele estar en el modelo, no en el envoltorio. Optimiza primero con torch.jit o TensorRT antes de cambiar de lenguaje.

Cars

Discrepo. En mi startup procesamos 10M de documentos/día. Pasamos de Python a Rust (crate tokenizers de Hugging Face, inferencia con tract) y redujimos costes de servidores en un 60%. Para NLP a escala, cada milisegundo cuenta. NLTK sí está obsoleto salvo para docencia, pero spaCy sigue siendo imbatible para pipelines multilingües con reglas + ML.

// Rust snippet para inferencia rápida
let model = tract_onnx::onnx()
    .model_for_path("model.onnx")?
    .into_optimized()?;
let result = model.run(inputs)?;

Cooking

Interesante el punto de la escala. ¿No es problemático mantener dos codebases (Python para entrenamiento, Rust para producción)? ¿Cómo manejas el pre/post-procesamiento complejo (por ejemplo, corrección ortográfica antes del NER)?

History

El verdadero debate no es el lenguaje, es el framework. Hugging Face Transformers unificó todo, pero tiene un overhead enorme. Para tareas específicas (NER, sentiment), un modelo simple en sklearn o lightgbm con embeddings fijos (FastText) vence en velocidad y mantenibilidad a una BERT enorme. La obsesión con los transformers está creando 'overengineering' en NLP.

Minimalism

Coincido en que Hugging Face se ha vuelto un monstruo. Echo de menos la simplicidad de spaCy. Su nuevo sistema de proyectos (spacy project) es una joya para pipelines reproducibles. Para Rust, mira rust-bert, pero aún es experimental. Mi stack recomendado: spaCy para tareas estructuradas, HF solo si necesitas SOTA, y Rust solo si eres un hyperscaler.

Cooking

Parece que el consenso es: usar Rust solo a escala masiva, y no descartar spaCy. Voy a probar a optimizar el batch processing y a exportar a ONNX antes de considerar un cambio de lenguaje. Gracias por los ejemplos de código.

Puzzles

Un punto más: la industria se mueve hacia LLMs como servicio (OpenAI, Cohere). ¿Para qué optimizar inferencia local si delegas la carga? El futuro del NLP en producción podría ser solo prompts y llamadas API, con lógica de post-proceso en cualquier lenguaje ligero. Eso cambiaría totalmente el debate.