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
LangGraphoCrewAIpor 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:
- Ingesta multimodal:
Unstructured.io+ OCR (Tesseract + layoutlmv3) → chunks semánticos de 512 tokens con solape 50, metadatos enriquecidos (sección, versión, vigencia). - Indexado híbrido:
Qdrant(vector denso,bge-m3) +Elasticsearch(BM25 + ELSER v2) + grafo de entidades (Neo4j) para saltos relacionales. - 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). - 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.
- Evals automáticos nocturnos: dataset dorado 1 200 preguntas (golden set) +
RAGAS(faithfulness, answer_relevancy, context_precision) +PromptFoopara regresiones de prompt. Alerta Slack si faithfulness < 0,90. - 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) +Presidiopara 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
chunkerdellama-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_toobligatorio 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

