Agentes de voz con RAG y function calling

Un agente de voz que solo puede conversar es una demo. Un agente de voz que puede llamar a tu CRM, buscar una cuenta, cobrar una tarjeta y actualizar un pedido es un producto. La diferencia es function calling y RAG. La parte difícil es cablear ambos en una conversación en streaming sin romper el presupuesto de latencia que hace que los agentes de voz se sientan naturales en primer lugar. Este post recorre qué hacen function calling y RAG por un agente de voz, las arquitecturas híbridas que se han vuelto estándar en 2026, cuándo el agente debe llamar a una herramienta versus cuándo debe seguir hablando y cómo SipPulse AI maneja la orquestación.

Por qué un agente de voz necesita herramientas y RAG

Las solicitudes reales de los clientes no se quedan en los datos de entrenamiento del LLM. El cliente pide su saldo de cuenta, el agente tiene que llamar a la API de facturación. El cliente pregunta por una característica del producto, el agente tiene que recuperar la documentación más reciente. El cliente quiere reagendar, el agente tiene que consultar la API de calendario y escribir la nueva reserva. Ninguna de estas solicitudes se responde solo con el prompt del modelo.

Dos patrones resuelven esto:

• Function calling: el LLM decide en mitad de la conversación que necesita llamar a una API, el runtime ejecuta la llamada, el resultado vuelve al siguiente turno del LLM
• RAG (Retrieval Augmented Generation): el agente recupera documentos relevantes de una base de conocimiento, los inyecta en el prompt y luego genera una respuesta anclada en el contenido recuperado

Function calling maneja estado dinámico (datos de cuenta, transacciones, inventario en tiempo real). RAG maneja conocimiento documentado (docs de producto, políticas, FAQs). Un agente de voz de producción típicamente usa ambos.

Function calling: la llamada a API en mitad de conversación

Function calling le permite al LLM decidir, en mitad de un turno, que necesita invocar una API. El modelo emite una llamada de herramienta estructurada con parámetros, el runtime la ejecuta y la respuesta se dobla de vuelta en el prompt para el siguiente paso de generación. Para el usuario, el agente dice "déjame revisar eso", una pausa de medio segundo ocurre, luego "tu saldo es $432,18". Todo el bucle se completa en menos de un segundo en un stack bien afinado.

La implementación importa. Function calling agrega latencia: la llamada API tiene que hacer ida y vuelta y el LLM tiene que generar una segunda respuesta. Los agentes de voz de producción manejan esto de tres formas:

• Hablar relleno mientras la llamada está en vuelo: "déjame buscar eso para ti" compra el tiempo de ida y vuelta
• Hacer streaming de resultados parciales: el agente empieza a hablar la respuesta en cuanto los primeros tokens llegan, no después de que la respuesta completa se genera
• Pre-buscar llamadas probables: si el cliente está preguntando por una cuenta, busca los datos de cuenta antes de que termine la oración

Un agente de voz que queda en silencio por 2 segundos mientras una llamada de herramienta se resuelve se siente roto. Un agente de voz que dice "revisando ahora" y continúa con suavidad se siente profesional.

RAG para voz: anclando al agente en tus datos

RAG convierte tu base de conocimiento en algo desde donde el agente de voz puede responder. El patrón: los documentos se trocean y se convierten en embeddings en una base de datos vectorial. Cuando el usuario hace una pregunta, el agente recupera los chunks más relevantes, los inyecta en el prompt del LLM como contexto y genera una respuesta anclada.

Para voz específicamente, RAG tiene restricciones más ajustadas que para chat:

• Latencia: la búsqueda vectorial tiene que completarse lo suficientemente rápido para caber en el presupuesto de conversación, idealmente bajo 100ms
• Precisión sobre recall: una recuperación equivocada se vuelve una respuesta hablada equivocada que el usuario no puede inspeccionar fácilmente
• Presupuesto de longitud: las respuestas habladas deben ser cortas, así que el contexto de RAG tiene que ser selectivo en lugar de volcar el chunk entero

Los sistemas de RAG nativo sincronizan las bases de conocimiento de la empresa directamente en la memoria del agente. La sobrecarga de mantenimiento importa tanto como el setup inicial: cuando una política cambia, los embeddings tienen que reconstruirse, o el agente cita con confianza la política vieja.

Speech-to-speech híbrido y cascada

Muchas implementaciones en 2026 son híbridas: speech-to-speech para small talk y aperturas con carga emocional, con cascada de respaldo (STT, LLM, TTS como componentes separados) cuando una llamada de herramienta o búsqueda RAG es necesaria. El razonamiento se divide:

• Modelos speech-to-speech (un solo modelo recibe audio y produce audio) ganan en latencia de apertura. Son geniales para "Hola, ¿en qué puedo ayudar?" y reconocimientos cortos y emocionales.
• Pipelines en cascada dan la mayor flexibilidad, el uso más limpio de herramientas y la elección de qué LLM y TTS intercambiar. Son necesarios en el momento en que el agente tiene que llamar a una API o recuperar de una base de conocimiento.

El patrón correcto depende del caso de uso. Un agente de reserva que siempre necesita llamar a una API de calendario se queda en cascada de punta a punta. Una recepcionista amable que mayormente maneja small talk se beneficia de speech-to-speech para aperturas y cascada solo cuando la intención escala. Nemotron de NVIDIA, lanzado en CES 2026, y la API GPT-4o realtime son las dos opciones canónicas de speech-to-speech; ambos soportan function calling, con cascada típicamente todavía preferida para orquestación compleja de herramientas.

Cuándo el agente NO debe llamar a una herramienta

El otro lado del function calling es la moderación. Un agente de voz que llama a una herramienta para cada pregunta es lento. El prompting de producción incluye una política clara sobre cuándo llamar:

• Buscar datos que el agente no conoce (saldo de cuenta, estado de pedido, disponibilidad de producto)
• Tomar una acción (reservar, cancelar, cobrar, actualizar)
• Verificar un hecho cuando hay duda (¿este producto sigue disponible?, ¿el precio cambió?)

Pero no:

• Saludar al cliente (no se necesita herramienta)
• Confirmar entendimiento (el LLM puede parafrasear sin ayuda)
• Manejar rechazos o pedidos fuera de alcance (el agente debe seguir instrucciones de seguridad, no llamar a una herramienta para pensarlo)

La disciplina importa porque cada llamada innecesaria a herramienta agrega latencia y costo.

Dónde encaja SipPulse AI

SipPulse AI soporta function calling y RAG nativamente en el prompt del agente. Declaras las herramientas a las que el agente tiene acceso, el runtime maneja el ida y vuelta del LLM, el TTS en streaming habla relleno mientras las herramientas resuelven. RAG puede tirar de cualquier base de datos vectorial vía APIs estándar, y el scaffold del prompt facilita imponer reglas de "responde solo desde el contexto recuperado" para reducir la alucinación.

NIVA, nuestro constructor por bloques, le permite a no ingenieros configurar qué agentes tienen qué herramientas, enrutar la conversación entre agentes especializados según la intención y combinar bloques de agente de voz con pasos clásicos de IVR. Un agente de retención con herramientas de búsqueda profunda de cuenta y un agente de facturación con herramientas de pago pueden vivir en el mismo flujo con un handoff limpio.

Habla con una demo de function calling en sippulse.ai/demos y mira la latencia por llamada en el visor de telemetría de ejemplo. Cuando function calling está en el bucle, el timing por etapa en el payload del webhook hace fácil ver si la latencia se esconde en la llamada API o en la segunda pasada del LLM.

Lee también

• Arquitectura de agentes de voz: STT, LLM, TTS y el presupuesto de latencia
• Construyendo agentes de voz sobre WebRTC: el stack de producción
• Evaluando agentes de voz en producción: WER, MOS, latencia

Conclusión

Un agente de voz que llama a APIs y se ancla en tu base de conocimiento es la diferencia entre un juguete de chat y un producto. Function calling y RAG cargan costos de latencia y complejidad, y speech-to-speech híbrido más cascada es el patrón dominante de producción en 2026. Prueba nuestra demo para sentir function calling en acción o habla con el equipo para conectar SipPulse AI a tus herramientas y datos.