¿Gemini 3.8 Live o Extended Thinking en Famulor?

El 15 de septiembre de 2026, Google presentó dos nuevos modelos de voz a voz: Gemini 3.8 Live, diseñado para un diálogo fluido y de baja latencia, y Gemini 3.8 Live Extended Thinking, orientado a tareas más complejas y de varios pasos. Según el registro de cambios de Famulor del 17 de septiembre de 2026, ambos modelos ya forman parte de la selección de modelos en tiempo real de Famulor.

La pregunta útil no es qué modelo es universalmente mejor. Es: ¿Qué tipo de retraso y fallo es menos aceptable en tu llamada? Un razonamiento adicional puede ralentizar innecesariamente un flujo de calificación de citas breve. En un proceso de reprogramación con varios pasos, reglas y llamadas a herramientas, una falta de razonamiento puede aumentar la probabilidad de errores en el proceso.

Puntos clave

• Gemini 3.8 Live es el punto de partida para pasos de conversación rápidos y frecuentes.
• Extended Thinking debe reservarse para pruebas con tareas genuinamente complejas, no para cada llamada por defecto.
• Famulor indica que la selección manual de modelos es visible con el complemento Fallbacks & Guardrails; de lo contrario, Famulor utiliza su selección automática recomendada.
• Decide basándote en pruebas idénticas a través de la ruta telefónica real, no solo en los benchmarks del proveedor.

¿Qué hay de nuevo en Gemini 3.8 Live?

El anuncio de Google del 15 de septiembre de 2026 describe ambos como modelos Live nativos que procesan el habla directamente y pueden ejecutar herramientas de forma asíncrona mientras la conversación continúa. Google posiciona el modelo estándar para escala y fluidez en el diálogo, mientras que Extended Thinking añade más razonamiento en segundo plano para tareas complejas.

Las páginas técnicas de los modelos trazan una frontera más clara:

• Gemini 3.8 Live es la recomendación predeterminada de Google para experiencias de agentes de voz de baja latencia sin retrasos inducidos por el razonamiento. Admite llamadas a funciones asíncronas y razonamiento intercalado.
• Gemini 3.8 Live Extended Thinking se dirige a tareas complejas de varios pasos que requieren un razonamiento de fondo más sólido. Google también señala que el procesamiento asíncrono puede continuar después de lo que parece ser el final de un turno de conversación.

Estas son descripciones de productos de Google, no evidencia de rendimiento independiente para tu caso de uso telefónico. Los resultados de los benchmarks publicados por Google no se midieron con tu número de teléfono, tus prompts, tus herramientas o tus perfiles de llamante. Pueden ayudar a formar una hipótesis de prueba, pero no deben reemplazar una prueba de aceptación en producción.

¿Cómo se exponen los modelos en Famulor?

Famulor describe Realtime como un modo de motor en el que un modelo escucha y habla. Según la documentación de Models & Voices actual, Famulor selecciona los modelos utilizados por defecto. Un catálogo de modelos compatibles se vuelve visible, y la selección manual está disponible, cuando Fallbacks & Guardrails se incluye en el espacio de trabajo activo.

La entrada del registro de cambios de Gemini 3.8 destaca cuatro puntos prácticos:

1. Ambas variantes de 3.8 Live forman parte de la selección Realtime.
2. Sin el complemento, Famulor mantiene su selección automática recomendada.
3. Extended Thinking puede ayudar con preguntas más exigentes, pero puede sentirse más lento.
4. Las mejoras en Realtime también cubren la ejecución de herramientas, las terminaciones completas de palabras y los tramos de audio en silencio.

Verifica siempre la disponibilidad real en el espacio de trabajo activo en Settings → Plan. Este artículo no garantiza un derecho de plan específico ni la disponibilidad permanente de un modelo.

¿Cuándo es Gemini 3.8 Live el mejor punto de partida?

Comienza con Gemini 3.8 Live cuando la llamada consista en decisiones cortas y repetitivas donde el ritmo conversacional sea lo más importante. Ejemplos típicos incluyen:

• horarios de apertura, comprobaciones de estado y preguntas frecuentes simples;
• calificación de leads con unos pocos criterios claros;
• solicitudes de citas con un conjunto pequeño de campos obligatorios;
• enrutamiento por intención, idioma o ubicación;
• llamadas cortas a herramientas cuyos resultados puedan confirmarse inmediatamente.

“Rápido” no debería convertirse en un umbral de milisegundos inventado. Lo que importa es si la experiencia se siente natural para quien llama: ¿el asistente reconoce la solicitud lo suficientemente pronto, evita interrumpir al interlocutor y permanece claro después de una llamada a una herramienta?

El modelo estándar también es sensato cuando los casos complejos se derivan a un humano o a un asistente especializado. En ese diseño, no es necesario que cada llamada simple soporte el coste de un razonamiento más profundo.

¿Cuándo deberías probar Extended Thinking?

Extended Thinking merece una ruta de prueba separada cuando varios pasos dependen entre sí y una decisión intermedia prematura sería costosa o difícil de corregir. Ejemplos incluyen:

• reprogramación que combina disponibilidad, reglas de tarifas y restricciones del cliente;
• un caso de servicio con preguntas de diagnóstico, recuperación de conocimiento y creación de tickets;
• una oferta de recuperación de clientes con exclusiones y reglas de aprobación;
• un flujo de reserva con varias llamadas a herramientas asíncronas;
• un proceso en el que el asistente debe explicar el progreso mientras el trabajo en segundo plano continúa.

Más razonamiento no es permiso para una autonomía ilimitada. Continúa definiendo explícitamente las herramientas permitidas, las confirmaciones obligatorias, las condiciones de parada y las transferencias. Los pagos, cambios de contrato, información médica y otras acciones trascendentales deben mantener una confirmación adecuada o aprobación humana en el flujo de trabajo.

Matriz de decisión: ¿flujo conversacional o profundidad de razonamiento?

Esta matriz es un punto de partida, no una clasificación de proveedores. Si tu escenario encaja en ambas columnas, divide el flujo: enruta las solicitudes simples a través de la ruta rápida y las solicitudes complejas a través de una ruta delimitada con más razonamiento o una transferencia humana.

Cómo realizar una prueba A/B justa en Famulor

1. Mantén constante el diseño de la conversación

Utiliza el mismo prompt del sistema, herramientas, fuentes de conocimiento, voz e intenciones de prueba para ambas variantes. Cambia solo la selección del modelo. De lo contrario, no podrás atribuir una mejora de forma fiable.

La descripción general del modo de motor de Famulor actual también marca un límite importante: Realtime expone menos controles a nivel de componente que una tubería compuesta por STT, LLM y TTS. Si necesitas una marca específica o una voz clonada, confirma primero que Realtime es la arquitectura adecuada. Famulor ya tiene una guía de arquitectura Realtime frente a pipeline; este artículo se centra solo en elegir entre los nuevos modelos Gemini 3.8 Live.

2. Define un conjunto de pruebas pequeño y exigente

No pruebes solo el camino feliz. Un conjunto útil incluye al menos:

• una solicitud simple sin herramienta;
• una llamada a herramienta exitosa;
• una llamada a herramienta lenta o fallida;
• una corrección del interlocutor en medio del proceso;
• un detalle ambiguo;
• una solicitud fuera de las acciones permitidas;
• una transferencia humana;
• una llamada repetida con una intención similar pero no idéntica.

Puntúa por separado la finalización de la tarea, la precisión de los datos capturados, la secuencia de herramientas, el flujo conversacional, el manejo de interrupciones y la calidad de la transferencia. Evita colapsarlos en un solo promedio demasiado pronto.

3. Prueba sobre la ruta telefónica real

Las demos en navegador y las grabaciones de proveedores no muestran cómo se comporta tu asistente a través de números de teléfono, redes y dispositivos reales. Repite los mismos casos con teléfonos móviles típicos, ruido de fondo, velocidades de habla y acentos. Registra fallos observables como “herramienta ejecutada dos veces”, “corrección ignorada” o “largo silencio antes de la confirmación”.

4. Establece reglas de parada y aceptación por adelantado

Un modelo no debería ganar porque una llamada impresionante suene inusualmente bien. Define los fallos P0 antes de probar, como acciones trascendentales no confirmadas, parámetros de herramienta incorrectos, datos obligatorios faltantes o una transferencia fallida. Un solo P0 no debería compensarse con una prosodia fluida.

Ejemplo práctico: reprogramación de citas de servicio

Una empresa de servicios quiere automatizar las llamadas de reprogramación entrantes. El asistente debe capturar el número de orden de trabajo, recuperar la cita existente, verificar los espacios disponibles, considerar la cobertura de los técnicos y crear la nueva reserva solo después de una confirmación explícita.

Para el caso sencillo (un número de orden válido, un espacio disponible y confirmación inmediata), Gemini 3.8 Live es un punto de partida plausible. La conversación debe ser corta y el resultado de la herramienta debe confirmarse directamente.

Para el caso difícil (múltiples órdenes, una dirección ambigua, dos consultas de calendario y una regla de tarifas), el equipo prueba Extended Thinking. El asistente puede anunciar pasos intermedios, pero debe resumir la fecha, la franja horaria y la orden antes de realizar un cambio. Si una regla no puede resolverse con confianza, transfiere la llamada en lugar de adivinar.

Esta prueba no asume que Extended Thinking completa automáticamente más reprogramaciones correctamente. Comprueba si la arquitectura de razonamiento añadida produce menos fallos de proceso medibles en este flujo de trabajo definido sin ralentizar la conversación más allá de un nivel aceptable.

¿Qué señala la comunidad de profesionales?

Señal de la comunidad, no evidencia de producto: En una publicación en Show HN del 10 de septiembre de 2026, los desarrolladores de IA de voz dicen que las llamadas de prueba manuales repetidas y los casos de producción inesperados les motivaron a construir una plataforma de simulación. El hilo tuvo una participación limitada cuando se revisó. No prueba la efectividad del proyecto ni la calidad de ningún modelo, pero respalda una pregunta de prueba útil: ¿es suficiente una buena llamada de demostración o el flujo de trabajo es estable en muchos escenarios reproducibles?

La distinción es deliberada: Google y Famulor respaldan las afirmaciones sobre las características y disponibilidad del producto. Hacker News proporciona una señal de los profesionales sobre una preocupación operativa. No puede reemplazar la documentación oficial ni tu propia evaluación.

¿Qué límites deberías documentar antes del lanzamiento?

• Sin transferencia de benchmarks: Las puntuaciones de Google no son automáticamente tus resultados de producción.
• Sin garantía de disponibilidad: Los planes, catálogos y la selección automática pueden cambiar; verifica el espacio de trabajo activo.
• Sin cumplimiento automático: La elección del modelo no establece la permisibilidad legal ni reemplaza las revisiones de privacidad, grabación y consentimiento.
• Sin autonomía ilimitada: Los permisos de herramientas, confirmaciones y transferencias siguen siendo decisiones de diseño.
• Sin prueba única: Los cambios en prompts, herramientas, conocimiento o modelos requieren pruebas de regresión.
• Sin sustituto para la selección de arquitectura: Si una voz TTS específica o un control a nivel de componente es obligatorio, una tubería o una cascada pueden ser más adecuadas.

Conclusión: Elige por perfil de tarea, no por nombre de modelo

Gemini 3.8 Live es el punto de partida lógico para conversaciones fluidas y frecuentes en tiempo real. Extended Thinking es una opción dirigida cuando el razonamiento de varios pasos y las herramientas asíncronas pueden ofrecer un beneficio real en el proceso. “Más pensamiento” no es una mejora de calidad universal; debe sopesarse frente al flujo conversacional, los modos de fallo y las necesidades de escalada.

La decisión más clara proviene de una comparación controlada con el mismo prompt, herramientas y escenarios telefónicos reproducibles. Solo una variante que supere tus puertas de calidad predefinidas en tu propio flujo de trabajo debería llegar al tráfico de producción.

Prueba ambas variantes de Realtime con el mismo conjunto de llamadas

Primero comprueba si la selección manual de modelos está disponible en tu espacio de trabajo de Famulor. Luego construye una ruta simple y una compleja y compara ambas variantes mediante llamadas de prueba reales. Comienza con la documentación de Realtime de Famulor.

Preguntas frecuentes sobre Gemini 3.8 Live en Famulor

¿Puede cada espacio de trabajo de Famulor seleccionar Gemini 3.8 Live manualmente?

No. Famulor indica que la selección de modelos es visible cuando Fallbacks & Guardrails está incluido en el espacio de trabajo activo. Sin el complemento, Famulor utiliza su selección automática recomendada. Verifica el plan actual en tu espacio de trabajo.

¿Es Extended Thinking siempre más preciso?

Eso no se puede afirmar universalmente. Google lo posiciona para tareas complejas de varios pasos. Si hace que tu flujo de trabajo sea más fiable, debe probarse con escenarios, herramientas y criterios de aceptación idénticos.

¿Qué modelo debería usar para la calificación de citas simple?

Gemini 3.8 Live es el punto de partida natural cuando capturas unos pocos campos y confirmas llamadas a herramientas cortas. Aun así, prueba las interrupciones, correcciones y fallos de herramientas sobre la ruta telefónica real.

¿Cuándo debería probar Extended Thinking?

Cuando varias reglas, búsquedas o herramientas dependen entre sí y una decisión intermedia errónea sería difícil de corregir. Continúa definiendo confirmaciones, límites y transferencias claras.

¿Reemplaza Realtime a una tubería STT-LLM-TTS?

No para todos los casos de uso. Realtime proporciona una ruta de conversación integrada con menos controles a nivel de componente. Si debes controlar componentes o una voz TTS específica por separado, evalúa una tubería o una cascada.

¿Es suficiente una llamada de prueba exitosa para el lanzamiento?

No. Utiliza casos normales, de fallo y extremos reproducibles, prueba condiciones telefónicas reales y repite el conjunto después de cambios relevantes.