El Stack de IA Que Usamos en Producción: Modelos y Pipelines

El panorama de herramientas de IA a principios de 2026 es abrumador. Cada semana trae un nuevo framework, un nuevo modelo, una nueva base de datos vectorial que dice ser la más rápida, y una nueva capa de orquestación que promete simplificarlo todo. Para líderes de ingeniería tratando de construir sistemas de IA en producción, la relación ruido-señal nunca fue peor. Lo sabemos porque lo estuvimos navegando nosotros mismos -- entregando productos potenciados por IA y sistemas de agentes para clientes en fintech, energía y gobierno mientras el suelo se mueve debajo nuestro cada trimestre.

Este artículo es nuestro intento de cortar ese ruido. Estamos compartiendo las herramientas específicas, modelos y decisiones arquitectónicas que componen nuestro stack de IA en producción -- qué usamos, por qué lo elegimos, y qué deliberadamente elegimos no usar. Esto no es un framework teórico ni un cuadro comparativo de vendors. Es el stack corriendo en producción hoy, sirviendo usuarios reales, manejando casos borde reales, y costando dinero real. Lo compartimos porque la transparencia construye confianza, y porque desearíamos que más equipos hicieran lo mismo. Cuando los vendors publican benchmarks, optimizan para la demo. Cuando los profesionales comparten sus stacks, optimizan para la honestidad.

La Capa de Modelos: Eligiendo tus LLMs

Corremos una estrategia multi-modelo -- no porque esté de moda, sino porque ningún modelo individual es la opción correcta para cada tarea en un sistema de producción. Equivocarse en la estrategia de modelos significa gastar de más en capacidades que no necesitás o entregar menos calidad de la que los usuarios esperan.

Claude: Nuestro Modelo de Razonamiento Principal

Claude de Anthropic es nuestro modelo principal para razonamiento complejo, análisis de contexto largo, y seguimiento matizado de instrucciones. Lo usamos para decisiones de orquestación de agentes, análisis de documentos de 50-100 páginas de contratos, generación y revisión de código, y cualquier tarea donde seguir system prompts detallados con precisión importa más que la velocidad pura. La capacidad de extended thinking de Claude es particularmente valiosa para sistemas de agentes -- cuando un agente necesita planificar un workflow multi-paso, la diferencia de calidad versus otros modelos es medible. También dependemos de la confiabilidad de output estructurado de Claude. Los sistemas de producción no pueden tolerar JSON malformado, y para industrias reguladas esta confiabilidad es un requisito duro.

GPT-4o y Modelos Open-Source

GPT-4o de OpenAI sirve como nuestro fallback y nuestra opción para tareas multi-modales que involucran análisis de imágenes y patrones complejos de function calling. Lo mantenemos no como cobertura contra lock-in de vendor -- aunque eso es un beneficio -- sino porque ciertas tareas genuinamente rinden mejor en él. Pretender que un modelo gana en todo es ideología, no ingeniería.

Para tareas sensibles al costo y de alto volumen, desplegamos modelos open-source -- principalmente Llama 3 de Meta y Mistral. Estos manejan clasificación, extracción de entidades y resumen simple donde los costos de modelos de frontera son injustificables. Una tarea de clasificación corriendo 50,000 veces por día cuesta aproximadamente $100 por mes en Llama 3 versus $3,000 en Claude. La diferencia de calidad para clasificación binaria es despreciable; la diferencia de costo no lo es. Self-hosteamos usando vLLM para servir inferencia, dándonos control sobre latencia, disponibilidad y residencia de datos.

Orquestación: Conectando Agentes

La capa de orquestación es lo que convierte llamadas individuales a modelos en workflows de agentes coherentes. Gestiona estado, routea decisiones, maneja llamadas a herramientas y se recupera de fallos. Acertar esta capa es la diferencia entre una demo que impresiona y un sistema que funciona a las 3 AM de un sábado.

LangGraph para Workflows de Agentes

Usamos LangGraph como nuestra capa de orquestación principal. Modela los workflows de agentes como grafos dirigidos donde los nodos representan acciones y las aristas representan transiciones condicionales. La ventaja clave es el checkpointing -- LangGraph persiste el estado completo del agente en cada nodo, habilitando replay de ejecuciones fallidas desde el punto exacto de falla, aprobación human-in-the-loop en cualquier paso, y audit trails completos para compliance.

Orquestación Personalizada para Rutas Críticas

Para rutas críticas de producción -- agentes de procesamiento de pagos, workflows sensibles a la seguridad -- usamos máquinas de estado TypeScript personalizadas en lugar de un framework. Los frameworks agregan capas de abstracción, y las capas de abstracción agregan modos de falla. Cuando un workflow procesa transacciones financieras, cada línea de código de orquestación debería ser explícita, testeable, y libre de actualizaciones de dependencias de terceros que podrían cambiar el comportamiento. Es más código que LangGraph, pero la compensación vale la pena donde la confiabilidad supera la velocidad de desarrollo.

Bases de Datos Vectoriales y Embeddings

Usamos tres bases de datos vectoriales para tres contextos de despliegue. Pinecone es nuestro default para despliegues cloud-native -- gestionado, escalable, con aislamiento de tenants basado en namespaces. pgvector es nuestra opción cuando la aplicación ya corre en PostgreSQL, manteniendo vectores junto a datos relacionales y eliminando una base de datos separada que operar. Weaviate se despliega para clientes on-premise -- agencias gubernamentales e instituciones financieras con residencia de datos estricta -- corriendo containerizado dentro de su infraestructura con búsqueda híbrida nativa.

Para embeddings, text-embedding-3-large de OpenAI es nuestro default para aplicaciones en inglés. Para trabajo multilingüe -- una porción significativa de nuestros proyectos en América Latina y Europa -- embed-multilingual-v3.0 de Cohere supera a las alternativas en recuperación cross-language. Para despliegues on-premise, usamos modelos open-source como BGE-large y E5-mistral, corriendo en las mismas instancias GPU que nuestros LLMs para mantener todo el pipeline autocontenido.

Pipeline RAG: De Documentos a Respuestas

La calidad de un sistema RAG depende mucho más del pipeline de recuperación que del modelo de generación -- un modelo de frontera con mal contexto produce malas respuestas igual de confiadamente que produce buenas.

Chunking Consciente del Tipo de Documento

Abandonamos las estrategias de chunking universal temprano. Chunks de tamaño fijo con overlap funcionan para artículos e informes pero destrozan contratos, especificaciones y estados financieros. Nuestro enfoque: los contratos legales se chunkean por cláusula, los docs técnicos por sección, los informes financieros por tabla y narrativa por separado. También mantenemos relaciones padre-hijo entre chunks para que el sistema pueda traer contexto circundante cuando se recupera un fragmento -- eliminando el modo de falla RAG más común de devolver un fragmento relevante que carece del contexto para interpretarlo correctamente.

Reranking y Búsqueda Híbrida

Reranking es consistentemente la mejora de calidad individual más grande en nuestros pipelines RAG. Usamos Cohere Rerank para despliegues gestionados y modelos cross-encoder para setups on-premise. Agregar reranking a un pipeline de búsqueda vectorial baseline mejora la precisión de respuestas en un 15-25% a través de tipos de documentos. Agrega 100-200ms de latencia, pero la mejora de calidad lo hace innegociable.

Combinamos esto con búsqueda híbrida -- combinando similitud vectorial con matching de keywords BM25 -- para cada sistema de producción. La búsqueda vectorial pura falla en consultas de coincidencia exacta para números de contrato, SKUs de productos e identificadores de regulaciones. La implementación agrega complejidad, pero perder un documento obviamente relevante porque no es semánticamente cercano a la consulta es demasiado dañino como para aceptarlo.

Evaluación y Monitoreo

Un sistema de IA sin evaluación es un pasivo. Cada sistema de producción recibe una suite de evaluación personalizada: precisión de extracción, completitud y tasa de alucinación para procesamiento de documentos; tasa de completación de tareas, relevancia y adherencia al tono para agentes conversacionales. Las herramientas off-the-shelf te dan métricas genéricas. Los frameworks personalizados te dan las métricas que realmente correlacionan con la satisfacción del usuario.

Para dimensiones subjetivas de calidad, usamos un patrón de LLM-as-judge -- Claude como el modelo juez, puntuando outputs en una escala de 1-5 con razonamiento obligatorio para cada puntuación. No es un reemplazo para evaluación humana sino un filtro escalable que captura regresiones y marca casos borderline. Para aplicaciones críticas en dominios legales y financieros, expertos de dominio revisan una muestra estadística de outputs semanalmente, proveyendo la verdad base para calibrar la evaluación automatizada.

Para observabilidad, corremos LangSmith capturando cada llamada a LLM, invocación de herramienta, y decisión de agente como una traza. Dashboards personalizados de Grafana trackean lo que al liderazgo le importa: costo por día por modelo y cliente, percentiles de latencia, tasas de completación de tareas, y scores de calidad. Cada dólar de inferencia de IA se atribuye a un cliente, proyecto y caso de uso específico -- no como higiene financiera, sino para impulsar decisiones de optimización.

Infraestructura y el Patrón de API Gateway

Los servicios de agentes están containerizados con Docker en Kubernetes, auto-escalando basados en profundidad de cola en lugar de utilización de CPU -- porque los workloads de IA son I/O-bound esperando APIs de modelos, no CPU-bound. Para inferencia self-hosted, vLLM corre en instancias GPU con batching dinámico, escalando a cero fuera de horario. Un único API gateway maneja autenticación, rate limiting, lógica de retry, routing de modelos, y tracking de costos para cada request de LLM saliente. Este gateway es el chokepoint a través del cual fluye todo el gasto en IA, convirtiéndolo en el lugar natural para enforcement de presupuestos y recolección de telemetría.

Lo Que Elegimos No Usar (y Por Qué)

Las herramientas que rechazás revelan tanto sobre tu filosofía de ingeniería como las herramientas que adoptás. Estas son las tecnologías notables que evaluamos y deliberadamente descartamos.

• CrewAI -- Demasiado opinionado sobre patrones de interacción de agentes para producción. LangGraph provee las mismas capacidades multi-agente con control explícito sobre cada transición.
• Chroma -- Sólido para prototipado pero la madurez operativa para workloads de producción (connection pooling, HA, backups) no cumplía nuestros estándares. Lo revisamos periódicamente.
• Haystack -- Abstracción de pipeline limpia pero ecosistema y soporte de comunidad significativamente menores que LangChain/LangGraph.
• Modelos de razonamiento fine-tuneados -- Resultados consistentemente peores que modelos de frontera bien prompteados, con alta carga de mantenimiento. Sí hacemos fine-tuning de modelos de embedding para recuperación domain-specific, donde el ROI es claro.
• AutoGen -- Endurecimiento para producción insuficiente. La interacción de agentes basada en conversación hacía difícil el debugging, y la ausencia de checkpointing persistente fue un deal-breaker para workflows empresariales.

Cómo Evolucionó Nuestro Stack en 18 Meses

A mediados de 2024, corríamos GPT-4 como nuestro único modelo, chains de LangChain crudas para orquestación, Chroma para almacenamiento vectorial, y logging básico. El sistema funcionaba para demos pero se desmoronaba bajo carga de producción. Para fines de 2024, Claude 3.5 Sonnet había reemplazado a GPT-4 como nuestro modelo principal, Pinecone y pgvector habían reemplazado a Chroma, y LangGraph había reemplazado a chains de LangChain -- mejorando inmediatamente el debugging y testing.

Durante 2025, agregamos Cohere Rerank (nuestra mayor mejora de calidad individual), construimos frameworks de evaluación personalizados, desplegamos LangSmith, e introdujimos el patrón de API gateway. Entrando a 2026, el foco cambió a madurez: orquestación personalizada para rutas críticas, loops de evaluación humana, modelos self-hosted para clientes con datos sensibles, y pipelines de LLM-as-judge. El stack es más complejo que hace 18 meses, pero cada componente gana su lugar resolviendo un problema que realmente tuvimos -- no un problema que imaginamos.

Principios Detrás de Nuestras Elecciones

• Usá el modelo correcto para cada tarea, no el mejor modelo para todas las tareas. El model cascading no es solo optimización de costos -- es un principio arquitectónico.
• Sé dueño de tu ruta crítica. Los frameworks son excelentes para workflows no críticos, pero el código de producción crítica debería ser explícito y libre de cambios de dependencias upstream.
• Medí antes de optimizar. Cada optimización que hicimos fue impulsada por brechas de calidad medidas en producción, no por preocupaciones teóricas.
• La simplicidad operativa se acumula. Una herramienta ligeramente menos capaz que tu equipo puede operar con confianza supera a una herramienta superior que requiere experiencia especializada.
• La transparencia es una feature. Cuando los clientes preguntan qué modelos usamos y cómo evaluamos la calidad, respondemos con especificaciones.

Nuestro stack va a seguir evolucionando -- el panorama de herramientas de IA se mueve demasiado rápido para que cualquier arquitectura sea permanente. Pero los principios son estables: medí todo, sé dueño de tus rutas críticas, usá la herramienta correcta para cada trabajo, y sé honesto sobre qué funciona. Si estás construyendo sistemas de IA en producción y querés comparar notas, o si necesitás un equipo que ya navegó estas decisiones, nos encantaría la conversación. Explorá nuestros servicios de IA y machine learning en /services/ai-development.