Primitivas Ensambladas vs. una Plataforma

Pasé mucho tiempo construyendo un canal telefónico para un chatbot usando primitivas en la nube: telefonía, un servicio de intents, un puente de funciones, un sintetizador de voz. Se lanzó, funcionó en producción y aprendí muchísimo haciéndolo.

Desde entonces fue reemplazado por una plataforma de agentes de voz diseñada para ese propósito, y el resumen honesto es que la plataforma es mejor en esto.

Lo que realmente cuesta usar "primitivas ensambladas"

Cada una de las primitivas era buena. El problema es que una conversación en tiempo real no es la suma de ellas, y cada brecha entre dos servicios era mía para resolver:

• Turn-taking — decidir cuándo el interlocutor terminó de hablar, cuándo el agente puede empezar y qué pasa cuando se interrumpen. Ningún servicio individual se encarga de esto. La unión entre ellos sí, y esa unión es código que tú escribiste.
• Barge-in — que el interlocutor interrumpa a mitad de frase significa cancelar la síntesis en curso, lo que convierte cada llamada descendente en algo que debe ser cancelable, cambiando los requisitos de idempotencia en lugares que no tienen nada que ver con voz.
• Contabilización de latencia — los interlocutores escuchan cada salto como silencio. Cada servicio era rápido por separado. El presupuesto se consumía en las uniones.
• Correlación — el recorrido de un interlocutor cruzando cuatro servicios significa trazas que mueren en cada límite a menos que diseñes la correlación desde el inicio. Yo la añadí durante el endurecimiento, que fue el momento equivocado.

Una plataforma construida para agentes de voz se encarga de esas uniones como parte de su producto. Eso no es una pequeña comodidad; es la mayor parte de la parte difícil.

Por qué no me arrepiento de haberlo construido

Dos razones, y ninguna es sentimental.

La primera es que las limitaciones solo se vuelven legibles construyéndolo. "Turn-taking es sutil" es una frase que puedes leer sin entender. Haber lanzado algo que falla en eso a las 2 am es un conocimiento distinto, y es lo que me permite evaluar el turn-taking de una plataforma en lugar de confiar en su palabra.

La segunda es que la parte debajo sobrevivió a la migración. La capa de integración debajo del canal es una fábrica sobre adaptadores que normalizan cada canal en un solo sobre, y la interfaz deliberadamente no dice nada sobre si una respuesta llega en dos segundos o doscientos milisegundos. Como el fulfillment nunca se ramificó según el canal, reemplazar todo el front end de voz no lo tocó.

Eso es lo que vale la pena generalizar: pon la abstracción donde no haya tanto cambio. Los proveedores, modelos y plataformas en este espacio cambian en escalas de meses. La forma de "una conversación con un usuario" cambia mucho más lento. Si tu abstracción está dibujada alrededor del proveedor, cada cambio de proveedor es una reescritura. Si está dibujada alrededor de la conversación, un cambio de proveedor es un adaptador.

Aún evaluando

La evaluación de otras plataformas de voz sigue en curso, corriendo en paralelo con la construcción actual en lugar de después.

Eso suena a indecisión y no lo es. Las limitaciones decisivas en un sistema de voz en producción frecuentemente no son técnicas — son contractuales, jurisdiccionales y sobre dónde se permite procesar datos. Esas limitaciones pueden cambiar independientemente de lo que haga ingeniería, y pueden invalidar una elección que fue correcta el día que se tomó.

Así que la postura útil no es "elige al ganador y deja de buscar." Es mantener la frontera de integración lo suficientemente clara para que la respuesta pueda cambiar sin que el sistema se afecte, y mantener un conocimiento actualizado de las alternativas para que si la respuesta cambia, la migración sea una decisión y no una emergencia.

Ya he estado en ambos lados de esa migración una vez. La segunda vez será más barata, enteramente por dónde está la unión.