Las recomendaciones de herramientas son más útiles cuando vienen con contexto. "Usamos X" significa muy poco sin saber el tamaño del equipo, el tipo de trabajo, las restricciones de costo, y los problemas específicos para los que se eligió cada herramienta. Así que antes del stack: somos un equipo de ingenieros que construye integraciones de IA y software personalizado para empresas en etapas tempranas y de crecimiento en LATAM y EE. UU. La mayor parte de nuestro trabajo implica integrar IA en productos existentes en lugar de construir productos nativos de IA desde cero.
Con ese contexto, así es como luce nuestro stack ahora y por qué.
Claude es nuestro modelo principal para integraciones en producción. La gran ventana de contexto maneja el procesamiento de documentos largos que surge regularmente en casos de uso legales, financieros y de operaciones. La fiabilidad en el seguimiento de instrucciones reduce la carga de ingeniería de prompts en aplicaciones de salida estructurada. Usamos la API de Anthropic directamente —sin envoltura— lo que nos da control total sobre la lógica de reintentos, el almacenamiento en caché y el manejo de errores.
Para aplicaciones donde el costo es la restricción dominante y la tarea está suficientemente bien definida para ejecutarse en un modelo más pequeño, evaluamos GPT-4o-mini y Claude Haiku contra el caso de uso específico antes de comprometernos. Los modelos frontier no siempre son la respuesta correcta.
Nos hemos alejado de LangChain para la mayoría de los proyectos nuevos. La capa de abstracción agrega complejidad que ralentiza la depuración y crea problemas de dependencia en las actualizaciones. Para cadenas simples y pipelines de RAG, escribimos la lógica de orquestación directamente. Para flujos de trabajo multi-agente, actualmente estamos evaluando el Anthropic Agent SDK junto con implementaciones personalizadas.
El principio: usar el enfoque de orquestación más simple que funcione. Cada capa de abstracción agrega una superficie de fallo. Si una llamada directa a la API resuelve el problema, usa una llamada directa a la API.
Postgres con pgvector es nuestro predeterminado para implementaciones de RAG donde el volumen de datos cabe dentro de una sola instancia de base de datos. Reduce significativamente la complejidad operativa en comparación con ejecutar una base de datos vectorial dedicada. Para mayor escala o arquitecturas multi-tenant, usamos Pinecone.
Modelo de embedding: el text-embedding-3-small de OpenAI cubre la mayoría de los casos de uso a un costo que tiene sentido para el volumen en producción. Para contenido en español, probamos modelos multilingües explícitamente —la calidad del embedding se degrada en texto en español con modelos entrenados principalmente en corpus en inglés.
Esta es el área donde la mayoría de los equipos invierten insuficientemente. Usamos una combinación de LLM como juez (Claude evaluando salidas contra una rúbrica) y revisión humana de muestras aleatorias. Para sistemas en producción, seguimos la precisión, la latencia y las tasas de revisión humana como métricas operativas junto con las métricas estándar de infraestructura.
Cada integración de IA que enviamos tiene un conjunto de evaluación antes de que salga en vivo. Eso no es negociable. El conjunto de evaluación es lo que nos permite actualizar modelos, cambiar prompts, y responder a los comentarios de producción sin volar a ciegas.
LangSmith para rastrear llamadas de LLM en desarrollo. En producción, registramos todas las entradas, salidas y latencia en nuestra infraestructura de logging estándar y construimos dashboards encima. El objetivo es poder responder: qué recibió el modelo, qué devolvió, cuánto tiempo tardó, y qué pasó a continuación.
El comportamiento del modelo que parece correcto en conjunto puede ocultar fallos sistemáticos en patrones de entrada específicos. El rastreo hace visibles esos patrones.
AWS para la mayoría de los despliegues. Lambda para endpoints de IA sin estado con patrones de tráfico variable. ECS para servicios más complejos y con estado. S3 para almacenamiento de documentos y gestión de conjuntos de datos de evaluación.
Para clientes en México con requisitos de residencia de datos, usamos AWS São Paulo o US East según el contexto regulatorio específico. Ese matiz regional importa y se omite en las discusiones de stack que asumen un despliegue basado en EE. UU.
El espacio de herramientas para agentes se está moviendo rápido. La fiabilidad de los flujos de trabajo de agentes de múltiples pasos es lo que más estamos evaluando activamente —las demos son impresionantes, pero la fiabilidad de grado de producción para agentes requiere una infraestructura que aún no existe completamente. Actualizaremos esto cuando tengamos más datos de producción.
%20(1)-2.svg)
