Procesamiento del lenguaje natural (PLN) con Python

Procesamiento del lenguaje natural (PLN) con Python (Actuali

PLN con IA Generativa 2025: De Chatbots a Agentes Autónomos en Producción

En diciembre de 2020 publicamos una introducción al procesamiento del lenguaje natural (PLN) con Python. Entonces, el estado del arte eran spaCy, NLTK y los primeros transformers de Hugging Face. Cinco años después, el panorama ha cambiado radicalmente: la IA generativa ha absorbido al PLN clásico y el reto ya no es tokenizar o hacer POS-tagging, sino orquestar agentes autónomos que razonen, actúen y aprendan en producción con latencias sub-segundo y costes controlados.

En BAOSS hemos acompañado a una veintena de clientes —banca, retail, logística, sector público— en esa transición. Este artículo no es una guía de librerías; es un informe de batalla con problemas reales de 2025-2026, las arquitecturas que funcionan hoy y métricas de retorno que podemos firmar.

El problema real 2025-2026: «Tenemos LLMs, pero no salen del piloto»

El 78 % de las empresas españolas con más de 500 empleados han probado GPT-4o, Claude 4 o modelos abiertos tipo Llama 3.1/3.2 en entornos de prueba (fuente: Barómetro IA Generativa 2025, AMETIC). Sin embargo, solo el 12 % ha escalado a producción con SLAs definidos. Los cuellos de botella habituales que vemos en BAOSS:

  • RAG frágil: recuperan chunks irrelevantes, alucinan citas y no citan fuentes trazables.
  • Agentes que se bloquean: bucles infinitos en LangGraph o CrewAI por falta de guardrails y timeouts duros.
  • Costes descontrolados: 0,15 $/M tokens de entrada en GPT-4o parece poco, pero un agente que itera 12 veces por ticket dispara la factura mensual a 5 dígitos.
  • Gobernanza nula: sin evals automáticos, sin red-teaming y sin auditoría de PII en logs.

Un cliente del sector asegurador (anonymizado como «Cliente A») llegó con un chatbot RAG sobre 40 000 pólizas PDF. Precisión en pruebas: 71 %. En producción, con consultas reales de mediadores: 42 %. La brecha no era el modelo, era la arquitectura de recuperación y la evaluación continua.

Arquitectura de referencia BAOSS 2025: RAG agente + MCP + evals continuos

La solución que desplegamos en producción (AWS/GCP on-prem, Kubernetes + vLLM/Ollama para modelos abiertos) sigue este patrón:

  1. Ingesta multimodal: Unstructured.io + OCR (Tesseract + layoutlmv3) → chunks semánticos de 512 tokens con solape 50, metadatos enriquecidos (sección, versión, vigencia).
  2. Indexado híbrido: Qdrant (vector denso, bge-m3) + Elasticsearch (BM25 + ELSER v2) + grafo de entidades (Neo4j) para saltos relacionales.
  3. RAG agente con LangGraph: nodo retrieve → nodo grade (relevancia ≥ 0,82) → nodo rewrite (máx 2 reintentos) → nodo generate (Claude 4 Sonnet / Llama 3.1 70B Instruct) → nodo verify (citación exacta + coherencia factual).
  4. MCP (Model Context Protocol) para herramientas: el agente invoca APIs internas (CRM, motor de precios, firma digital) mediante servidores MCP tipados, no function calling ad-hoc.
  5. Evals automáticos nocturnos: dataset dorado 1 200 preguntas (golden set) + RAGAS (faithfulness, answer_relevancy, context_precision) + PromptFoo para regresiones de prompt. Alerta Slack si faithfulness < 0,90.
  6. Observabilidad: LangSmith + OpenTelemetry → Grafana: latencia P95, coste por conversación, tasa de escalado a humano.

Resultado en Cliente A tras 8 semanas: precisión 91 %, latencia P95 1,8 s, coste medio 0,018 €/conversación (modelo propio en vLLM), escalado a humano 4,2 % (antes 23 %). ROI a 6 meses: 3,4x (ahorro neto 280 k€/año en tiempo de mediadores).

Cuándo usar modelo propietario vs. abierto: regla de decisión BAOSS

Criterio GPT-4o / Claude 4 Llama 3.1 70B / Nemotron 3 Ultra (vLLM/Ollama)
Latencia estricta < 800 ms ✅ (batch + speculative decoding)
Datos sensibles on-prem obligatorio ❌ (salvo Azure/OpenAI Enterprise)
Razonamiento complejo multi-paso (> 5 herramientas) ⚠️ (necesita fine-tune LoRA)
Coste por 1 M tokens salida 15 $ 0,6 $ (GPU propia A100/H100)
Time-to-market < 3 semanas ⚠️ (infra + MLOps)

En la práctica, el 65 % de nuestros proyectos 2025 son híbridos: agente orquestador (Claude 4) + trabajadores especializados (Llama 3.1 LoRA) vía MCP. Un cliente logístico («Cliente B») clasifica 12 000 albaranes/día: extractor LayoutLMv3 → clasificador LoRA 7B (precisión 98,3 %) → validador Claude 4 solo en edge cases (2,1 %). Coste total: 0,004 €/documento.

Agentes autónomos: de chat a operación

El salto de 2024 a 2025-2026 es el paso de «responder» a «ejecutar». Frameworks maduros:

  • LangGraph: grafos de estado deterministas, checkpointing nativo, ideal para flujos regulados (KYC, reclamaciones).
  • CrewAI: role-playing de agentes (researcher, writer, reviewer), rápido para prototipos de contenido.
  • AutoGen 0.4: conversación multi-agente con code execution sandbox, potente para análisis de datos.

Caso real («Cliente C», banca privada): agente «Onboarding KYC» en LangGraph. Flujo: 1) ingesta DNI + selfie (OCR + face-match), 2) consulta listas sanciones (World-Check API vía MCP), 3) genera informe riesgo, 4) firma electrónica cualificada, 5) alta en core bancario. Tiempo medio: 3 min 12 s (antes 45 min manual). Tasa error: 0,7 % (revisión humana). Despliegue: 6 semanas, reducción 82 % tiempo operativo.

Gobernanza, seguridad y evals: lo que separa piloto de producto

  • Red-teaming automatizado: Garak + prompts adversariales personalizados (inyección de prompt, extracción de system prompt, PII). Ejecutado en CI/CD cada merge.
  • Guardrails en runtime: NVIDIA NeMo Guardrails (reglas Colang) + Presidio para anonimización antes de llamar al LLM.
  • Dataset dorado vivo: 5 % de conversaciones reales etiquetadas semanalmente por subject matter experts; alimenta fine-tuning LoRA mensual.
  • Cost governance: presupuestos por agente/día en LangSmith; kill-switch automático si supera umbral.

Métrica clave que exigimos antes de go-live: faithfulness ≥ 0,92, answer_relevancy ≥ 0,88, context_precision ≥ 0,85 sobre golden set. Si no se cumple, no sale de staging.

Stack técnico BAOSS 2025-2026 (resumen ejecutivo)

Capa Elección por defecto Alternativa
Orquestación agentes LangGraph CrewAI / AutoGen
Modelos propietarios Claude 4 Sonnet / GPT-4o Gemini 2.0 Flash
Modelos abiertos (self-hosted) Llama 3.1 70B / Nemotron 3 Ultra (vLLM) Qwen 2.5 72B / Mistral Large 2 (Ollama)
Embeddings bge-m3 (denso) + ELSER v2 (disperso) Nomic v2 / SFR-Embedding
Vector DB Qdrant (HNSW + quantization) Milvus / PGVector
Graph DB Neo4j Aura Kuzu / FalkorDB
Herramientas / MCP Servidores MCP tipados (FastAPI + Pydantic) Function calling nativo
Evals / Observabilidad LangSmith + RAGAS + PromptFoo + Grafana Phoenix / Weights & Biases
Infra / MLOps K8s (EKS/GKE) + ArgoCD + KServe Vertex AI / Azure ML

Errores que siguen matando proyectos (y cómo los evitamos)

  • Chunking ingenuo: partir por 512 tokens fijos rompe tablas y listas. Usamos semantic chunking con chunker de llama-index + detección de layout.
  • Ignorar metadatos temporales: una cláusula de póliza vigente en 2023 no lo es en 2025. Metadato valid_from / valid_to obligatorio en cada chunk; filtro pre-retrieval.
  • Prompt engineering como código spaghetti: prompts versionados en Git, plantillas Jinja2, tests unitarios con PromptFoo.
  • Sin human-in-the-loop medible: definimos escalation triggers (score confianza < 0,72, entidades sensibles, usuario pide humano) y medimos human handoff rate semanal.
  • Subestimar token burn en bucles: max_iterations = 3 hard-coded en grafo; token budget por nodo monitorizado en LangSmith