Si quieres que un modelo de lenguaje —Claude, GPT, Gemini, el que sea— razone sobre lo que se dijo en una llamada, la vía obvia es pasarle la transcripción entera. Es también la cara, y por un margen que sorprende.
Medido sobre una grabación real de 70 minutos de prosa variada, contando con el
tokenizador o200k_base:
| Lo que le mandas al LLM | Palabras | Tokens |
|---|---|---|
| Transcripción completa | 10.429 | 15.410 |
| Resumen estructurado | 294 – 422 | 484 – 673 |
Entre veinte y treinta veces menos tokens de entrada.
El rango no es dejadez: resumir no es determinista. La misma grabación, resumida dos veces, dio 484 y 673 tokens. Publicar solo el número bueno habría quedado mejor y habría sido menos cierto.
Y el ahorro crece con la duración. La transcripción crece en línea recta con los minutos de audio; el resumen no. En un corte de tres minutos da igual. En un archivo de llamadas es la diferencia entre una factura que se puede pagar y una que no.
Aquí es donde la mayoría de artículos sobre «optimización de tokens» se callan.
Un resumen es una pérdida de información deliberada. Si tu prompt depende de una cita literal, del momento exacto en que se dijo algo, o de un dato que aparece una sola vez y de pasada —un número de pedido, un importe, un apellido—, el resumen puede no traerlo.
Y en grabaciones cortas no ahorra nada. Sobre un corte de 90 segundos, el mismo script que mide todo esto reporta 1,2×: el resumen es casi tan largo como la transcripción. Por debajo de unos cinco minutos, no merece la pena.
La regla práctica con la que nos manejamos:
Resumen para «¿de qué iba esto y qué hay que hacer?». Transcripción para «¿qué dijo exactamente?».
/v1/summarize devuelve summary y transcript en la misma respuesta. Eliges en tu
código cuál de los dos sube al LLM, y no pagas dos veces por decidirlo.
Si al tercero solo le llega el resumen, la grabación y la transcripción literal nunca salen de tu proveedor de voz. Menos superficie expuesta, y una transferencia internacional menos que justificar en tu registro de tratamientos.
Hay un detalle en el ejemplo que publicamos y que conviene copiar aunque no uses nuestro código: el payload que genera pone el resumen en el turno del usuario y avisa, en el turno de sistema, de que ese texto es datos, no instrucciones. Todo lo que sale de una transcripción vino de un audio que tú no controlas. Alguien puede haber dicho en voz alta, a propósito, algo con forma de orden.
El ejemplo ejecutable —resume aquí, mide lo que te has ahorrado y escribe el payload exacto que mandarías— está en uttera-examples/llm-tokens. No envía nada a ningún tercero: te deja leer lo que vas a pagar antes de pagarlo.
¿Algo que añadir o que corregir? Escríbenos a support@uttera.ai. Si nos corriges, editamos la entrada y te damos crédito.
Uttera