ES
Una protección HTTP compartida da coherencia a las llamadas Java a modelos
Consistent LLM Call Handling Across Java Frameworks: A Reference Implementation and Benchmark · arXiv:2610.25480
En palabras sencillas
Los programas Java pueden llamar a modelos de lenguaje mediante distintos frameworks de cliente. Estos clientes pueden reaccionar de manera diferente si un proveedor tarda en responder, envía un error o corta una transmisión de datos antes de tiempo.
El artículo presenta seis reglas de fiabilidad compartidas y una biblioteca Java que las aplica en el punto donde las solicitudes y respuestas pasan por HTTP. En pruebas con fallos programados, las tres rutas de cliente protegidas se comportaron de forma parecida y cumplieron casi todas las reglas en las comprobaciones aplicables.
Un primer fragmento tardío todavía dejó al descubierto el compromiso que supone elegir un tiempo de espera.
La investigación
Cuando falla un proveedor de modelos, los frameworks de cliente para Java pueden gestionar de manera distinta los reintentos, los tiempos de espera y los flujos interrumpidos. ¿Puede una capa compartida aplicar las mismas reglas de fiabilidad en varios frameworks y en un cliente Java sencillo?
El artículo pone a prueba esta pregunta con un contrato que especifica qué debe garantizar la gestión de una llamada.
Un contrato de seis cláusulas y una protección HTTP compartida para Java aplican las mismas reglas ante fallos de proveedor en tres rutas de cliente Java.
Un fallo del proveedor puede recibir un tratamiento distinto según el cliente Java. ¿Puede una capa compartida hacer que todos sigan las mismas reglas de fiabilidad?
El artículo responde con un contrato de seis cláusulas y una biblioteca Java situada en el límite HTTP, debajo de dos frameworks o de un cliente Java sencillo.
En pruebas con fallos programados, los clientes protegidos de Spring AI, LangChain4j y Java sencillo cumplieron las seis cláusulas en casi todas las comprobaciones aplicables y coincidieron en los intentos y los tipos de fallo registrados.
Esto respalda una gestión coherente en las rutas probadas; el retraso del primer evento de un flujo todavía dejó al descubierto un compromiso con el tiempo de espera.
La evidencia procede de fallos programados compatibles con OpenAI y de llamadas que solo tuvieron éxito a un servidor local. No muestra cómo responde la protección ante fallos reales de proveedores bajo carga, otros protocolos de proveedor o versiones posteriores de los frameworks. El estudio también prueba una sola política de tiempo de espera.
Qué muestran las pruebas
- Un contrato de fiabilidad compartido
El artículo aporta un contrato de fiabilidad con seis cláusulas y una biblioteca Java que lo aplica bajo Spring AI, LangChain4j o directamente en una aplicación Java. La pregunta es si una capa HTTP compartida puede hacer que estas rutas de cliente gestionen los fallos de proveedor de forma coherente.
El contrato abarca los reintentos, las demoras solicitadas por el proveedor, la integridad de los flujos, los tiempos de espera ante el silencio, el registro de los resultados de las llamadas y la visibilidad de cada intento HTTP.
- Los frameworks se comportaron de forma distinta
La evaluación comparó primero Spring AI y LangChain4j sin la protección. Usó quince fallos de proveedor programados, llamadas síncronas y de transmisión continua, y los valores predeterminados o ajustes explícitos de cada framework.
Cada caso combinaba un escenario, un cliente, un modo y una configuración. Cada comprobación aplicable vinculaba una cláusula del contrato con un caso; solo se aprobaba si esa cláusula se cumplía en todas las repeticiones (tres repeticiones, salvo los escenarios de tiempo de espera S14 y S15, que se ejecutaron una vez).
Se omitieron las cláusulas que no correspondían. En estas comprobaciones de cláusula y caso, Spring AI cumplió la cláusula en 72 de 77 comprobaciones aplicables con los valores predeterminados y en 76 de 83 con ajustes explícitos; LangChain4j cumplió la cláusula en 47 de 77 y 51 de 83, respectivamente. Esto muestra que su gestión de fallos existente difería en estas pruebas.
- Los clientes protegidos coincidieron
A continuación, los mismos fallos programados pusieron a prueba las tres rutas de cliente con la protección. Cada una cumplió las seis cláusulas en 90 de 91 pares aplicables de cláusula y caso, y los clientes protegidos coincidieron en los intentos, las pausas entre reintentos y los tipos de fallo registrados.
Como la comparación más amplia también variaba los frameworks y sus ajustes, este resultado respalda que la capa compartida aporta coherencia en las rutas probadas; no permite aislar la protección como única diferencia en todas las comparaciones.
- Persistió un compromiso con el tiempo de espera
El mismo caso problemático fue un flujo cuyo primer fragmento llegó después de 8.5 segundos. Con un tiempo de espera de tres segundos para el primer evento, la protección interpretó el silencio como ausencia de respuesta y reintentó; en una prueba adicional con un tiempo de espera de diez segundos, los tres clientes completaron el flujo en un solo intento.
Esta comparación deja claro el compromiso que implica elegir un tiempo de espera: antes del primer evento, la protección no puede distinguir entre un flujo lento y un proveedor que no responde.
- La evidencia de éxito tiene límites
Las llamadas a un servidor local de modelos aportan una comprobación independiente: las 700 tuvieron éxito y la protección no rechazó ninguna respuesta ni flujo operativo. Esto respalda la gestión de respuestas exitosas en esta configuración, mientras que las pruebas con el proveedor programado evalúan fallos a nivel de protocolo.
El artículo también midió la latencia mediana adicional de la protección en llamadas exitosas al proveedor programado, pero sus evaluaciones no establecen cómo se comportaría ante fallos reales de proveedor o bajo carga.
Detalles
- Autores del paper original
- Oleksandr Klymenko
- Enviado a arXiv
- Licencia
- arXiv non-exclusive