Volver al inicio

Asistente de Voz en Tiempo Real con IA: Historia de Éxito en Backend

Un equipo de desarrolladores de backend construyó un asistente de voz con IA en tiempo real para equipos de ventas usando RAG, LLMs locales y tuberías de datos optimizadas. La solución ofrece tiempos de respuesta de menos de 2 segundos mientras asegura la seguridad de los datos mediante despliegue on-premise.

Cómo Construimos un Asistente de IA en Tiempo Real en 6 Meses
Advertisement 728x90

Desarrollando un Asistente de IA de Voz en Tiempo Real: El Viaje del Equipo Backend

El asistente de IA de voz 'Suffler' apoya a los gerentes de ventas durante llamadas en vivo. El sistema clasifica servicios, detecta objeciones, utiliza RAG para recuperar datos relevantes y genera sugerencias de texto en tiempo real. La entrada proviene de segmentos de texto generados por el servicio de transcripción de Voximplant. Se impone una ventana de latencia obligatoria de 1,5 a 2 segundos. Pila tecnológica: Python, FastAPI, PostgreSQL, modelos BERT ajustados y Qwen 8B local. Se requirió despliegue on-premise para cumplir con normas de seguridad.

Un equipo de 12 desarrolladores backend sin experiencia previa en ML dominó los fundamentos en seis meses y lanzó con éxito una versión piloto.

Prototipo Funcional en Tres Semanas

En las primeras tres semanas, el equipo entregó un prototipo operativo:

Google AdInline article slot
  • Procesamiento de transcripciones de llamadas como datos de entrada.
  • Dos clasificadores BERT: uno para más de 15 servicios y otro para más de 15 tipos de objeciones, entrenados con 1.500 ejemplos anotados.
  • Bases de datos vectoriales FAISS con descripciones de servicios y guiones.
  • Integración mediante prompts usando GPT.
  • Interfaz basada en Django para mostrar sugerencias en tiempo real.

El prototipo mostró un retraso de 10 a 15 segundos, pero convenció a los responsables de la viabilidad de la idea.

Evolución Arquitectónica: Reduciendo la Complejidad

El diseño monolítico inicial incluía una pipeline personalizada basada en Whisper, múltiples clasificadores, fine-tuning de LLM, base de datos vectorial con bucles de retroalimentación y estimación de desarrollo entre 12 y 18 meses con alto riesgo.

Abandonar el fine-tuning. En lugar de reentrenar Qwen o Llama con guiones de ventas, el equipo adoptó RAG: el modelo extrae contexto relevante directamente de una base de conocimiento bajo demanda. Esto reduce las alucinaciones y elimina esfuerzos extensos de anotación.

Google AdInline article slot

Usar un transcriptor listo. Voximplant entrega segmentos de texto vía REST, ahorrando dos meses de desarrollo de una pipeline interna de audio.

Simplificar los clasificadores. Un detector multiclase de objeciones se sustituyó por un clasificador binario (objeción presente/ausente). El LLM realiza el análisis detallado durante la generación. Ejecutar inferencia en un servidor GPU mejoró significativamente la velocidad.

Búsqueda JSON en lugar de bases vectoriales. Las bases de conocimiento (servicios, guiones) se almacenan como JSON estructurado en memoria. Más rápida que FAISS o Weaviate, sin latencia de red.

Google AdInline article slot

LLM local frente a nube. APIs en la nube como GPT o DeepSeek introducían retrasos de 7 a 20 segundos y estaban bloqueadas por políticas de seguridad. Ejecutar Qwen 8B localmente en un servidor GPU logró tiempos de respuesta de ~2 segundos con salidas concisas.

Interfaz ligera. Una página simple de Django que muestra sugerencias reemplazó la integración compleja con CRM.

Pipeline Final de Procesamiento en Tiempo Real

El sistema funciona así:

  • Recibir texto desde Voximplant.
  • Clasificación binaria con BERT (servicio + objeción).
  • Búsqueda RAG en base de datos JSON en memoria.
  • Generar prompt para Qwen 8B.
  • Mostrar sugerencia en la interfaz.

La latencia total permanece por debajo de 2 segundos.

Etiquetado de Datos: Abrazando Pragmatismo

Etiquetar 200 diálogos tomó semanas debido a la necesidad de comprensión contextual. Los gerentes de ventas etiquetaron más rápido, pero no estaban disponibles a escala.

Solución: enfocarse en detección binaria. El LLM maneja los detalles de la objeción durante la generación. Los ciclos de iteración se acortaron drásticamente.

Latencia como Restricción Absoluta

Las conversaciones en vivo exigen respuestas en menos de 2 segundos. Las APIs en la nube resultaron poco confiables. Qwen 8B local (vs. 32B) sacrifica algo de detalle por velocidad — una compensación necesaria.

Seguridad e Aislamiento

Flujo completamente on-premise:

  • Transcripción de Voximplant (única dependencia externa).
  • Procesamiento e identificación internos.
  • Respuestas generadas por LLM local.

Sin máscara de PII: evitó un sobrecosto de 200–500 ms, redujo riesgos de distorsión de datos y ahorró un mes de trabajo de desarrollo.

Conclusiones Clave

  • RAG frente al fine-tuning acelera el lanzamiento y minimiza el esfuerzo de etiquetado.
  • Clasificación binaria + LLM simplifica la detección de objeciones sin pérdida de calidad.
  • Qwen 8B local equilibra adecuadamente velocidad y precisión para uso en tiempo real.
  • Búsqueda JSON supera a bases vectoriales para bases de conocimiento pequeñas y estructuradas.
  • Despliegue on-premise resuelve simultáneamente problemas de seguridad y latencia.

— Editorial Team

Advertisement 728x90

Leer después