# ¿Cómo probar la compatibilidad de streaming y herramientas antes de cambiar de API LLM? > Prueba una migración de API LLM con casos de contrato registrados, no con una demostración de chat. Verifica texto en streaming, una herramienta forzada, argumentos fragmentados, varias llamadas, continuación tras el resultado, cancelación, errores y contabilidad de uso antes de enviar trabajo real. Una prueba de chat de diez minutos puede pasar por alto fallos importantes: llamadas duplicadas tras un reintento, JSON ejecutado antes del evento final, resultados devueltos con el rol incorrecto o una cancelación que deja una escritura activa. Una puerta de migración útil envía solicitudes fijas por el analizador y ejecutor reales y evalúa invariantes estructurales. La primera suite debe ser pequeña, determinista y comparable entre modelos. No pretende clasificar su inteligencia, sino demostrar que la nueva API puede controlar de forma segura el bucle existente. ## Define el contrato del que dependes Escribe el comportamiento exacto que necesita el cliente antes de probar al proveedor. Evita etiquetas vagas como “compatible con OpenAI”. | Área | Invariante requerido | Evidencia que conservar | |---|---|---| | Autenticación | El endpoint previsto acepta la clave | Estado e ID de solicitud | | Stream de texto | Los deltas forman un mensaje final | Eventos originales ordenados | | Stream de herramienta | La llamada termina antes de ejecutarse | Búfer y evento final | | Correlación | El resultado se asocia a la llamada correcta | Mapa de IDs | | Reintento | Cada llamada se ejecuta como máximo una vez | Registro de idempotencia | | Uso | Hay contadores o se marcan como no disponibles | Metadatos finales | La compatibilidad depende del modelo. Atlas Cloud ofrece varios formatos, así que consulta la guía actual de [`supported_apis`](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis) antes de elegir la ruta. ## Crea cuatro herramientas deterministas Utiliza casos que revelen fallos distintos: * `echo_json`: devuelve sin cambios los argumentos validados. * `read_fixture`: lee un archivo conocido del sandbox. * `delayed_value`: finaliza tras un retraso controlado. * `always_error`: devuelve un error estructurado estable. Usa esquemas estrictos con `additionalProperties: false` y un ID único para detectar ejecuciones duplicadas. Ningún caso debe depender del tiempo, búsquedas o un repositorio cambiante. ## Ejecuta una matriz por etapas Prueba sin streaming antes de activarlo y una llamada antes de varias. | Etapa | Comportamiento | Condición de aprobación | |---|---|---| | A | Devuelve texto | Llegan texto final y estado de parada | | B | Fuerza `echo_json` | Llegan nombre y argumentos válidos | | C | Transmite `echo_json` | Los fragmentos se ensamblan una vez | | D | Llama a dos lecturas | Ambos resultados se correlacionan | | E | Recibe un error | El modelo corrige o termina limpiamente | | F | Cancela a mitad del stream | No hay ejecución tardía | Mantén iguales el esquema y la intención semántica para todos los candidatos. Si el protocolo nativo exige otra envoltura, adapta solo la representación de red. ## Captura eventos por debajo del SDK Los objetos de alto nivel son cómodos en producción, pero pueden ocultar diferencias. Añade un transporte de depuración que registre cada evento con número de secuencia, ID de respuesta, índice de salida, ID de llamada, tipo y longitud del contenido ocultado. Los argumentos en streaming son incrementales. Ensámblalos por llamada y espera al evento final. Esta máquina de estados es más segura que analizar cada fragmento: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Rechaza transiciones hacia atrás y dobles ejecuciones. Si la conexión cae después de `EXECUTED` pero antes de entregar el resultado, usa una clave de idempotencia en vez de repetir una escritura. ## Prueba la ida y vuelta completa Una llamada válida es solo la mitad del contrato. Devuelve el resultado con el tipo de mensaje esperado y exige una respuesta final que cite un campo conocido. Prueba resultados grandes, vacíos, Unicode y errores estructurados. Limita el tamaño antes de reintroducirlo en el contexto; la migración puede parecer correcta hasta que una herramienta supera una suposición del adaptador. ## Compara invariantes, no prosa No falles la suite porque dos modelos escriban distinto. Comprueba propiedades observables: * Se eligió la herramienta esperada. * Los argumentos pasaron JSON Schema. * Todos los IDs fueron únicos y correlacionados. * Cada herramienta se ejecutó cero o una vez según lo previsto. * El bucle terminó dentro del presupuesto. * La respuesta final utilizó el resultado del caso. Guarda instantáneas específicas solo para depuración y mantén los criterios neutrales. ## Añade fallos y cancelaciones Desconecta tras el primer fragmento, tras completar la llamada y tras ejecutar la herramienta. Inyecta un 429, un timeout, JSON mal formado y un nombre desconocido. Comprueba si el cliente reintenta, continúa con seguridad o se detiene con un error útil. El error más peligroso es el reintento ambiguo que repite una operación con efectos. Exige idempotencia explícita para escrituras y falla si no se conoce la identidad de ejecución. ## Convierte la suite en puerta de publicación Mantén una prueba rápida para cada cambio de configuración y una matriz completa para actualizaciones de SDK o gateway. Guarda modelo, protocolo, URL base, hash del esquema, modo de streaming, versión del cliente y fecha. Atlas Cloud admite solicitudes con y sin streaming y permite explorar candidatos desde un [catálogo de modelos](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis). Ejecuta la misma puerta para cada modelo, porque compartir acceso no implica capacidades idénticas. ## Conclusión Prueba una migración LLM como un cambio de protocolo con estado. Usa herramientas deterministas, registra eventos originales, ensambla argumentos solo al finalizar, verifica la ida y vuelta e inyecta reintentos y cancelaciones. Promueve el nuevo modelo cuando apruebe el contrato, no porque una respuesta de chat parezca correcta. ## FAQ ### ¿Qué debe cubrir la primera prueba de compatibilidad? Empieza con una solicitud de texto sin streaming y una llamada forzada de solo lectura. Aíslan problemas del endpoint, autenticación, esquema y formato básico de respuesta. ### ¿Por qué registrar los eventos sin procesar? Los SDK pueden ocultar el orden y las diferencias de campos. Los eventos originales muestran cómo llegan identificadores, fragmentos, marcadores finales, errores y uso. ### ¿Puedo comparar proveedores exigiendo exactamente el mismo texto? Normalmente no. Compara invariantes estructurales, como llamadas válidas, campos obligatorios, número de ejecuciones, estado final y resultado de la tarea. ### ¿Cómo pruebo argumentos mal formados? Devuelve un error de validación estructurado y confirma que el bucle corrige o termina dentro de un presupuesto definido, sin ejecutar entradas inseguras. ### ¿La suite debe utilizar herramientas de escritura? Empieza con herramientas deterministas y de solo lectura. Añade una escritura aislada solo después de aprobar ensamblaje, validación, deduplicación y recuperación. ### ¿Con qué frecuencia debo ejecutar estas pruebas? Ejecuta un subconjunto antes de cada cambio de modelo o protocolo, y la suite completa cuando cambien SDK, esquemas, gateways o analizadores.