Conectar OpenAI o Anthropic a su producto: la elección, el prompt y el contexto que nadie presupuesta

A qué proveedor (OpenAI o Anthropic) se le pregunta en casi todas las llamadas iniciales como si fuera la decisión más importante del proyecto. Rara vez lo es. Ambos APIs realizan salidas estructuradas, ambos realizan llamadas a herramientas/funciones, ambos flujos y las diferencias que importan (tamaño de la ventana de contexto, precio por token, qué tan estrictamente un modelo sigue un esquema, cómo se comporta en instrucciones ambiguas) se deciden probando sus indicaciones reales con sus datos reales, no mediante una tabla de clasificación de referencia.

Las decisiones que de verdad moldean la construcción llegan después: cómo se escribe y versiona el prompt como código en vez de ajustarlo en un playground y olvidarlo, cómo se valida una respuesta antes de que su app confíe en ella, y cómo gestiona el contexto cuando una conversación, un documento o un trabajo por lotes supera lo que cabe en una llamada.

1. OpenAI contra Anthropic rara vez es la decisión que importa

Elijo según el trabajo, no por lealtad de marca: cuál tiene un soporte de salidas estructuradas más estricto para un pipeline cargado de esquemas, cuál tiene una ventana de contexto que realmente contiene el documento en cuestión, qué nivel de precio aguanta el volumen de llamadas esperado, y - infravalorado - cuál tiene un comportamiento de rechazo que encaja con un caso de uso cercano a un tema sensible. Dos proveedores distintos pueden «funcionar» en una demo y divergir con fuerza en cuanto usuarios reales mandan casos límite reales.

Mantengo al proveedor detrás de un único adaptador fino en el código precisamente para que esta decisión sea reversible. Un cliente que pida cambiar de proveedor a los seis meses por un cambio de precios, un límite de tasa o la deprecación de un modelo debería recibir un cambio de configuración y una ronda de pruebas de regresión de prompts, no una reescritura.

2. La ingeniería de prompts es una especificación, probada como tal

Un prompt que vive en la cabeza de un solo desarrollador, se ajusta en un playground de chat y sale a producción en cuanto «se ve bien» en tres ejemplos, es un pasivo en cuanto el tráfico crece más allá de esos tres ejemplos. Escribo los prompts como archivos versionados, con un pequeño conjunto de prueba de entradas reales y formas de salida esperadas, y los pruebo en regresión igual que haría con una función - sobre todo antes de cambiar de modelo o proveedor.

Las salidas estructuradas y las llamadas a herramientas/funciones son lo que hace que un prompt sea siquiera comprobable: en vez de calificar texto libre a ojo, compruebo que un payload JSON cumple un esquema y que sus valores satisfacen las reglas de negocio. Eso es el verdadero entregable de la «ingeniería de prompts» en un proyecto real, no un párrafo ingenioso.

3. Gestión del contexto: la parte que nadie presupuesta

Toda integración de LLM acaba encontrándose con una conversación, un documento o un trabajo por lotes más grande que la ventana de contexto, y lo que pasa después decide si la función se mantiene barata y precisa o se vuelve lenta y empieza a alucinar. Añadir ingenuamente cada mensaje al historial funciona en la demo y luego se rompe en silencio: los costes suben en cada turno, la latencia sube con ellos, y pasado un punto el modelo empieza a perder de vista la pregunta real enterrada bajo turnos antiguos.

El arreglo es una mezcla de recortar turnos viejos, resumir lo anterior en vez de repetirlo, y recuperar solo la porción relevante mediante embeddings y una base de datos vectorial cuando la fuente es un documento en vez de una conversación. La entrada multimodal - una imagen o una página de PDF - es solo otro tipo de contexto que gestionar igual: cuenta contra la misma ventana y necesita la misma disciplina sobre qué es lo que realmente tiene que estar ahí.

Conclusión: la llamada a la API es la parte más pequeña de la integración

Conectar un LLM a un producto no va sobre todo de la llamada al modelo - es el adaptador que hace intercambiable al proveedor, el prompt tratado como una especificación probada, el esquema que atrapa una respuesta malformada antes de que llegue a un usuario, y la estrategia de contexto que sigue funcionando después de la primera conversación de demo fácil. Yo construyo todo eso alrededor de cual de OpenAI o Anthropic encaje de verdad con el trabajo. Escriba por el formulario qué quiere que el LLM haga dentro de su producto, y le diré qué necesita de verdad la integración.