Por Juste Thales Gnimavo (CEO, ZeroSuite) y Claude Opus 5.5 (Claude Code)
Déblo Duo es un intérprete de voz en tiempo real: cada persona habla su idioma y oye a la otra en el suyo. Por qué existe Déblo Duo explica el producto. Este artículo cubre una sesión, el 4 de noviembre de 2026. Es la historia de una medición que rompió una regla que el propio CEO había fijado, y de por qué lanzamos igualmente.
El problema: cada turno llegaba solo
Duo funciona sobre Gemini Live Translate. Una sesión live por sentido: una escucha al anfitrión y le habla al invitado, la otra hace lo contrario. Cada sesión solo conocía lo que oía. No sabía lo que la otra persona acababa de decir.
Para la mayoría de los idiomas basta. Para el chino, no. El chino hablado tiene muchas palabras que suenan igual y significan cosas distintas. Un intérprete humano las resuelve con la conversación. En nuestra prueba, la palabra que había que acertar era « sac », una bolsa. Nuestro intérprete no tenía conversación. Tenía una frase cada vez.
El CEO había adelantado esta tarea en la cola a propósito. También fijó la restricción antes de escribir código: la corrección podía costar como mucho +300 ms de latencia.
El primer banco no era concluyente
Ya existía un banco de pruebas de una sesión anterior del mismo día. Claude lo releyó antes de construir sobre él, y no se sostenía.
El brief decía « espagnol et arabe justes dans toutes les variantes ». El banco anterior daba el elemento de prueba árabe en 5/6 con contexto y 8/8 sin él, lo que significaría que el contexto empeoraba el árabe. Pero cada celda tenía entre 2 y 8 ejecuciones, y se habían perdido 58 sesiones de 180 por desconexiones 1011. Con esos tamaños, 5/6 frente a 8/8 no permite concluir nada. Además, el código del banco solo existía en el scratchpad de una sesión cerrada. Claude lo recuperó, lo llevó al repositorio, lo excluyó de las imágenes de producción y lo volvió a ejecutar.
El nuevo banco usó 15 clips de audio pregenerados, como mucho dos conexiones simultáneas, y tres variantes:
- A: el comportamiento actual, sin contexto.
- S: una sesión por sentido, refrescada con las últimas frases del otro lado.
- P: una sesión nueva y precalentada en cada turno, con contexto.
Lo que decían los números
La tabla es parcial: 246 líneas de resultados de unas 450, porque el banco seguía en marcha cuando se tomó la decisión. Las diferencias que muestra no son ajustadas.
| Idioma | Elemento de prueba, A | Elemento de prueba, S | Primera palabra mediana, A → S | p90, A → S |
|---|---|---|---|---|
| Chino | 0/14 | 14/14 | 2,2 → 3,1 s | 3,9 → 4,0 s |
| Japonés | 11/13 | 14/14 | 2,0 → 3,1 s | 4,7 → 4,8 s |
| Español | 14/14 | 14/14 | 2,0 → 1,9 s | 3,8 → 3,8 s |
| Árabe | 12/12 | 12/12 | 3,3 → 3,5 s | 4,3 → 5,0 s |
El chino pasó de 0 de 14 a 14 de 14. El japonés, de 11/13 a 14/14. El español y el árabe ya acertaban y siguieron acertando. La alarma del árabe era ruido.
La variante P daba la misma exactitud que S, con una primera palabra a 4,4-5,2 s de mediana: dos o tres segundos más lenta que hoy. Eso es entre siete y diez veces el límite del CEO. La descartamos.
La variante S costaba alrededor de un segundo de latencia mediana en chino y en japonés. El p90 apenas se movía. Sigue siendo más de tres veces el límite.
Por qué rompimos el límite
Claude no escondió la diferencia ni la redondeó a la baja. El log la nombra: « écart assumé au critère de latence », una desviación asumida respecto al criterio de latencia.
El argumento era simple. Una palabra equivocada no es un error menor. Cuando el intérprete convierte « bolso » en otra palabra que suena igual, el anfitrión no entiende, vuelve a preguntar y espera una nueva respuesta. Esa ida y vuelta cuesta más de cinco segundos. Un segundo más en cada turno en chino, frente a más de cinco segundos en cada turno en que la palabra sale mal, que en el banco era siempre.
El CEO aceptó el intercambio, y aceptó también que no sería perfecto: « l'hôte redemande, comme dans la vie réelle ». Entre dos personas con un intérprete humano, una palabra mal oída también provoca una segunda pregunta. El objetivo no es cero repeticiones. El objetivo es que la repetición no sea lo normal.
Hay algo que el contexto no corrige. El precio japonés « 10 dollars 50 » siguió mal en ambas variantes: acertó 1 vez de 6 sin contexto y 0 de 7 con él. Es una propiedad del modelo, no de lo que le enviamos. Lo anotamos y lo dejamos.
Cómo entra el contexto
Las decisiones de diseño, cada una escrita en el log con la forma de revertirla:
- Cada sentido guarda las 3 últimas frases finales de cada lado, como mucho 240 caracteres por línea.
- Las líneas del otro lado entran en las instrucciones de la sesión al abrirse, bajo un preámbulo breve: usarlas para resolver ambigüedades, no pronunciarlas nunca, mantener los números exactos.
- Solo entran las frases de origen, no sus traducciones. El brief pedía ambas. El banco midió solo el origen (14/14), y la traducción duplica la longitud sin información nueva.
- El primer cambio ocurre cuando el otro lado ha dicho 30 caracteres en total. Eso descarta un « Bonjour. » aislado.
- Como mucho dos intentos por sentido. Después, el contexto se refresca en cada rotación natural.
Abrir antes de cerrar
El cambio más interesante no fue el contexto. Fue la rotación.
Para cambiar las instrucciones de una sesión live hace falta una sesión nueva. El código anterior cerraba la sesión actual y luego abría la siguiente. Nuestro búfer de reconexión cubre 3 segundos de audio. Abrir una sesión tarda entre 2 y 7 segundos. Así que cada rotación ya tenía un hueco, antes de empezar este trabajo. El log también descubrió que las rotaciones voluntarias se contaban dentro del límite de reconexiones, como si fueran fallos.
El código nuevo abre primero la sesión siguiente, en reserva, la alimenta con silencio y la sustituye en la siguiente pausa. Si la reserva no logra abrirse, la sesión anterior sigue. Si no llega ninguna pausa en 45 segundos, la reserva se descarta. Una reserva por sentido, tres por minuto como máximo. La facturación no cambió.
La primera prueba del CEO en producción, entre las 13:42 y las 13:50 UTC, no mostró ningún cambio en dos llamadas de tres. El log decía standby_dropped reason=no_pause. El detector de pausas vigilaba cualquier actividad, y el modelo emite audio de salida de forma continua, así que la sesión nunca parecía inactiva. El único contexto recibido llegó por una reconexión tras un corte. La simulación sin red, con un cliente Live falso, no modelaba una salida de audio continua. La corrección fue medir las pausas sobre las transcripciones. Claude volvió a ejecutar después los cinco escenarios sin red con salida de audio continua: 5 de 5.
La prueba, a las 13:55 UTC
El worker se reinició a las 13:54 UTC. El CEO volvió a llamar, de francés a chino, con dos dispositivos. Los logs del worker, en solo lectura:
13:55:40 interpreter.context_wanted direction=b_to_a chars=84 attempt=1
13:55:42 interpreter.switch direction=b_to_a why=context waited_s=1.9 context_lines=1
13:55:42 interpreter.session_open direction=b_to_a connection=2 connect_ms=326 context_lines=1 prewarmed=true
13:55:58 interpreter.session_close direction=a_to_b connection=1 lifetime_s=32.5 reason=server_closed:APIError
13:55:59 interpreter.session_open direction=a_to_b connection=2 connect_ms=490 context_lines=1 prewarmed=falseEl cambio llegó 1,9 s después de la frase del anfitrión. La sesión anterior se cerró y la nueva tomó el relevo en el mismo milisegundo, porque ya estaba abierta. El otro sentido también recibió contexto, mediante una reconexión tras un corte del lado de Google. En esa llamada, a las 13:56 UTC, el CEO oyó « sac », la palabra correcta. En el conjunto de sus pruebas, juzgó bueno el contexto: « sac » reconocido la mayoría de las veces, errores residuales aceptados.
Esto es lo que quedó probado, dónde y cuándo: un sentido que cambia con contexto sobre una sesión precalentada, el otro que recibe contexto al reconectar, y la palabra buscada correcta en una llamada real. No es una tasa medida sobre un día de tráfico.
Recuadro: la misma mañana, 10 caracteres en 8
Ese mismo día, más temprano y en otra sesión, el CEO había informado de que la transcripción de una presentación estaba vacía. Los logs del worker mostraban llamadas terminadas con 5, 3 y 5 turnos, y el envío de la transcripción respondía 422 las tres veces.
La causa era un campo. En modo presentación, la dirección se escribe to-<idioma>. to-zh-Hans tiene 10 caracteres. El campo admitía 8. Las cuatro sesiones de ese día incluían chino. Los éxitos anteriores, no. El límite pasó a 24, y una sonda a las 01:54 UTC confirmó que el servidor ahora acepta to-zh-Hans y sigue rechazando un valor de 30 caracteres. Las transcripciones de esas cuatro sesiones solo existían en la memoria del worker. Se perdieron para siempre.
Lo que sigue abierto
- La tasa de desconexiones 1011 en producción no está medida. Los logs solo conservan el contenedor actual, 171 líneas tras un reinicio. El diseño protege la reserva frente a ellas, porque la sesión anterior sigue, pero no tenemos una tasa.
- Cortes
APIErrorrecurrentes del lado de Google: hubo sesiones que vivieron 57 s y 32 s en dos llamadas del día. La reconexión los cubre dentro del búfer de 3 segundos, pero cada uno es un posible hueco de audio. Los contaremos durante un día completo antes de tocar nada. - El modo presentación queda fuera de la reserva a propósito: hasta tres sesiones por presentación duplicarían su exposición al 1011. Su propia rotación suave sigue midiendo las pausas sobre la actividad; con audio de salida continuo, solo rota en el límite duro, 570 s.
- La tabla del banco es parcial, 246 líneas de unas 450.
- El contexto viene del habla del otro participante. Solo puede orientar la traducción de su propia llamada.
La lección
El CEO fijó +300 ms antes de cualquier medición. La medición dijo un segundo. Había dos salidas fáciles: mantener la regla en silencio y lanzar un intérprete de chino que se equivoca de palabra cada vez, o romperla en silencio y esperar que nadie lo comprobara. El log no hace ni lo uno ni lo otro. Escribe la diferencia, la razón y la respuesta del CEO una al lado de la otra.
Un límite de latencia existe para proteger la conversación. Cuando la opción más barata rompe la conversación más a menudo que la más lenta, el límite ha hecho su trabajo al obligar a comparar. No le corresponde ganar la comparación.