1 puntos por GN⁺ 2026-03-25 | 1 comentarios | Compartir por WhatsApp
  • Para resolver la pérdida de ingresos por no contestar llamadas en un taller de alta gama, se desarrolló “Axle”, una recepcionista con IA que atiende llamadas reales
  • La IA se construyó sobre Retrieval-Augmented Generation (RAG), por lo que ofrece respuestas precisas basadas en información real de servicios y precios recopilada del sitio web
  • Se integraron Vapi, Deepgram, ElevenLabs, FastAPI, MongoDB Atlas y otros servicios para implementar conexión telefónica, reconocimiento y síntesis de voz, y almacenamiento del historial de conversaciones
  • La calidad de voz se ajustó con un tono natural y una estructura de frases cortas, para dar respuestas cercanas pero profesionales a los clientes
  • Más adelante se planea expandirlo con sistema de reservas, alertas por SMS y un panel de devoluciones de llamada, y la conclusión clave es que en los agentes de voz especializados para negocios lo esencial es la base de conocimiento y el diseño de escalamiento

Proceso de construcción de la recepcionista con IA

  • Se construyó una recepcionista con IA personalizada llamada “Axle” para resolver el problema de un hermano que opera un taller automotriz de lujo y estaba perdiendo miles de dólares al mes por no contestar llamadas
  • No se diseñó como un simple chatbot, sino como un agente de voz capaz de contestar llamadas reales y responder consultas de clientes con información real sobre precios, horarios, políticas y más
  • El proyecto se dividió en tres etapas: construcción de la base de conocimiento (pipeline RAG)conexión telefónica e integración con el servidorajuste de la calidad de voz y del tono conversacional

Paso 1: construir el cerebro (pipeline RAG)

  • Se usó Retrieval-Augmented Generation (RAG) para que la IA respondiera basándose en datos reales
    • Con un LLM usado de forma directa existía el riesgo de alucinaciones (hallucination), como dar precios incorrectos, así que se restringió para que respondiera solo con información real
  • Mediante scraping de datos del sitio web se recopilaron más de 21 documentos, incluyendo tipos de servicio, precios, tiempos estimados, horarios, formas de pago, garantías y políticas de autos de préstamo
  • La base de conocimiento se almacenó en MongoDB Atlas, y se generaron embeddings vectoriales de 1024 dimensiones con el modelo Voyage AI (voyage-3-large)
    • La búsqueda semántica se realizó mediante un índice de Atlas Vector Search
  • Cuando entra una pregunta del cliente, la consulta se transforma con el mismo modelo de embeddings para recuperar los 3 documentos más similares semánticamente
  • Se utilizó Anthropic Claude (claude-sonnet-4-6) para generar respuestas tomando como contexto los documentos recuperados
    • El prompt del sistema incluía reglas como: “no usar información fuera de la base de conocimiento, mantener respuestas breves y conversacionales, y si no sabe, ofrecer una devolución de llamada”
  • Como resultado, desde la terminal ya podía responder con precisión preguntas como “¿Cuánto cuesta el cambio de aceite?” con el precio real y el detalle del servicio

Paso 2: conectar un número telefónico real

  • Para conectar el cerebro de la IA con un sistema telefónico real, se usó la plataforma Vapi
    • Ofrece compra de números telefónicos, reconocimiento de voz con Deepgram, síntesis de voz con ElevenLabs y llamadas de función en tiempo real
  • Se construyó un servidor webhook con FastAPI
    • Vapi envía las preguntas del cliente al endpoint /webhook como solicitudes tool-calls
    • El servidor las pasa al pipeline RAG, recibe la respuesta de Claude y la devuelve a Vapi
    • Para mantener una velocidad de conversación natural, era necesario minimizar la latencia
  • Con Ngrok se expuso el servidor local mediante una URL HTTPS pública, permitiendo pruebas en tiempo real incluso durante el desarrollo
  • Configuración del asistente de Vapi

    • Se conectaron al webhook un saludo inicial y dos herramientas (answerQuestion, saveCallback)
    • El sistema responde preguntas o, si no sabe, solicita nombre y teléfono para guardar una devolución de llamada
    • La memoria conversacional permite mantener el contexto de interacciones previas
    • Así puede manejar consultas encadenadas como: “¿Cuál es su horario?” → “Entonces, ¿cuánto cuesta cambiar las llantas?”
  • Guardar registros de llamadas en MongoDB

    • Se registran número de origen, pregunta, respuesta, si hubo transferencia a un humano y la marca de tiempo
    • Las solicitudes de devolución de llamada se guardan en una colección separada, callbacks, para contacto posterior
    • Esto permite analizar patrones de consultas y volumen de llamadas

Paso 3: ajustar la calidad de voz

  • Considerando la diferencia entre respuestas en texto y respuestas por voz, fue necesario optimizar la entrega para voz
    • Una frase que suena natural al leerla puede escucharse extraña cuando se dice en voz alta
  • Elección de voz en ElevenLabs

    • Tras probar unas 20 voces, la voz “Christopher” resultó la más natural y la más adecuada para el ambiente del taller
    • Las voces demasiado robóticas o excesivamente alegres no funcionaban bien
  • Ajustes al prompt del sistema

    • Se usaron frases cortas, se eliminó Markdown y se quitaron expresiones innecesarias como “¡Buena pregunta!”
    • Los precios se pronuncian en lenguaje natural (“forty-five dollars”)
    • Las respuestas se limitaron a entre 2 y 4 oraciones
    • El objetivo era lograr una voz humana, cercana y profesional
  • Pruebas del flujo de escalamiento (devolución de llamada)

    • Si llega una pregunta que no está en la base de conocimiento, la IA dice que no lo sabe, pide nombre y número, y guarda los datos en MongoDB
    • Luego el dueño del taller puede dar seguimiento personalmente
  • Escritura de pruebas de integración

    • Se validaron el pipeline RAG, el manejo del webhook y el flujo completo
    • También se incluyó el manejo de casos límite, como solicitudes incorrectas, ausencia de resultados de búsqueda o falta del número para devolución de llamada

Configuración del stack tecnológico

  • Vapi (integración con Deepgram y ElevenLabs) — número telefónico, reconocimiento de voz, síntesis de voz y llamadas de función
  • Ngrok — túnel HTTPS para desarrollo local
  • FastAPI + Uvicorn — servidor webhook
  • MongoDB Atlas — base de conocimiento, búsqueda vectorial, registros de llamadas y cola de devoluciones de llamada
  • Voyage AI (voyage-3-large) — embeddings de texto semánticos
  • Anthropic Claude (claude-sonnet-4-6) — generación de respuestas basadas en la base de conocimiento
  • Python — con pymongo, voyageai, anthropic, fastapi
  • Copilot CLI — herramienta de automatización de compilaciones

Siguientes pasos

  • Actualmente la IA ya completa la parte de responder preguntas y recopilar solicitudes de devolución de llamada
  • El siguiente objetivo es agregar integración con calendario para reservas en tiempo real, alertas por SMS, panel de gestión de devoluciones de llamada, refuerzo de seguridad y despliegue en Railway
  • Cuando esté terminado, podrá operar 24/7 y evitar pérdidas de ingresos por llamadas no atendidas
  • La parte más difícil no fue el código, sino lograr un tono de voz adecuado para el taller
  • Lección principal: no usar un LLM en bruto tal cual para un agente de voz especializado en negocios
    • Debe basarse en una base de conocimiento real y es indispensable diseñar el flujo de respuesta cuando no sabe algo (escalamiento)
    • Eso no es una excepción, sino una función central

1 comentarios

 
GN⁺ 2026-03-25
Comentarios de Hacker News
  • Antes trabajé como asesor de servicio (encargado de recepción). No creo que el sistema del que habla el artículo vaya a funcionar en la práctica

    1. Si no existe un historial de reparación idéntico, es muy probable que la cotización sea incorrecta. En algunos estados, una cotización equivocada puede causar problemas legales
    2. El inventario y los precios de las piezas cambian constantemente. Si el sistema no refleja eso, solo va a generar confusión
    3. Los trabajos nuevos ya son complejos desde la selección de piezas. Cuanto más premium es el vehículo, más complicado se vuelve
    4. La única parte realmente útil sería algo como las notificaciones de recogida del vehículo. O sea, para avisar automáticamente cuándo está listo o cómo va el progreso
      Este tipo de desarrollo no solo es arrogancia; también es peligroso. Si se construye con puras suposiciones y sin validación, se pone en riesgo el sustento de otras personas
    • Yo tampoco soy experto, pero entiendo esa sensación de presumir. Si hace falta una recepcionista, lo natural sería contratar a una persona. Cuesta entender que le confíen el negocio a una solución de IA no probada. No sé si es porque no quieren gestionarlo o si solo están siguiendo la moda
    • En realidad hay una solución todavía más simple. Basta con que la persona que trabaja debajo del auto pueda contestar llamadas con un speakerphone manos libres. Si usan un modelo local de reconocimiento de voz, hasta pueden mencionar tecnología de redes neuronales, y el costo con micrófono incluido sería de apenas 200 a 300 dólares
    • Pero viendo el texto original, este taller ya tiene servicios fijos y una lista de precios. Así que, salvo cuando se necesite una cotización personalizada, los problemas de arriba no aplicarían
    • Decir que es “peligroso” parece exagerado. El desarrollador está ayudando al negocio de su hermano, y aunque no sea perfecto, si la conversión de clientes sube aunque sea un 10%, ya tendría valor
    • Las notificaciones de vehículo listo o las actualizaciones de progreso ya eran posibles con un sistema TTS desde hace años. No hace falta un LLM
  • El concesionario Subaru de mi zona deja elegir un asistente de IA al hacer una cita por teléfono. Lo probé y funcionó con más precisión y rapidez que una persona. Lo mismo me pasó con los pedidos por IA de Taco Bell, que me parecieron excelentes. En casos así no se pierde nada por no hablar con una persona, y si hace falta siempre se puede pedir que te pasen con alguien

  • Este tipo de entradas de blog cuentan solo la mitad de la historia. Me gustaría saber si realmente aumentaron los ingresos, si a los clientes les importó que fuera un bot y si hubo casos de falla

    • De hecho, este problema ya podía resolverse antes de la IA con un servicio de asistente virtual. Con 200 a 1000 dólares al mes alcanzaba, y en el fondo se trataba de recuperar ingresos que ya se estaban perdiendo. La IA no es más que una ratonera más complicada, y si se trata de un servicio premium, la atención humana transmite mucha más confianza
    • Probablemente todavía no ha habido suficiente prueba en condiciones reales. Cosas como una dirección de correo electrónico son difíciles de transcribir con precisión para un LLM. En respuesta de voz en tiempo real, Anthropic era lento y Groq era muy rápido, por debajo de 200 ms
    • Una vez necesité con urgencia un reemplazo de vidrio automotriz, pero el sistema automático de voz seguía pidiendo información innecesaria, así que colgué. Para una cita simple quizá funcione, pero en situaciones especiales al final sí necesitas hablar con una persona
    • Este tipo de intento es razonable. Lo que todavía no se sabe es su rendimiento real. Parece una prueba de tornasol para separar a los optimistas y pesimistas de la IA
  • Últimamente veo con bastante buenos ojos a los asistentes telefónicos basados en LLM. Cuando llamé al soporte de Mint Mobile, el LLM entendió todo de forma natural y me resolvió el problema en un minuto. Antes habría tenido que esperar más de 20 minutos

    • El LLM habla con pronunciación clara, no tiene ruido de headset y es fácil de entender. Claro, hay casos desastrosos como el chatbot LLM de eBay, pero un sistema bien implementado funciona de maravilla
    • El soporte por chat de Amazon es parecido. El LLM organiza antes la información del pedido y la persona solo da la aprobación final. Es eficiente
    • Aun así, me pregunto por qué no puede resolverse desde la app y hay que usar un LLM. Al final parece una falla del proceso de desarrollo
    • Yo tuve una experiencia similar. Hice una pregunta técnica y el LLM respondió correctamente; luego siguió un agente humano, pero resultó menos experto. Aun así, ahorré tiempo
    • Es muchísimo mejor que los robots de antes, y los chatbots basados en RAG ya son tan útiles que hasta reemplazan la búsqueda en documentación. Por ejemplo, el chatbot de manager.io me respondió directamente en vez de mandarme a leer documentos, y eso fue muy cómodo
  • Según el texto, el taller está perdiendo miles de dólares al mes por no poder contestar llamadas. Si es así, tener una recepcionista tercerizada por unos 500 dólares al mes tendría un ROI mucho mejor

    • De hecho, con un buzón de voz ya se resolvería parte del problema. Sea IA o buzón, algunos clientes igual van a colgar
    • Además, si ya tienen tanto trabajo que no pueden atender el teléfono, es muy probable que tampoco tengan capacidad para recibir más clientes
    • Un amigo mío usa un servicio de recepción tercerizado que cubre de 9 a 5 por 150 libras al mes. Él solo reorganiza la agenda por la noche. Si lo que dice el artículo es cierto, entonces el taller ya debe estar trabajando al 100% de su capacidad
    • Un buen service writer sale caro, pero vale totalmente la pena. Genera mucha confianza en el cliente y hasta podría terminar quedándose con el negocio más adelante
    • Al final, ese ROI solo parece el efecto publicitario del curso de IA que el blog quiere promocionar
  • Hoy en día, si siento que me atiende un robot, cuelgo de inmediato. Pero parece que pronto la voz de IA va a llegar a un punto en el que no se distinga de una persona. Cuando eso pase, tal vez se derrumbe la confianza en las llamadas. El correo electrónico y LinkedIn ya están inundados de spam generado por IA, así que mucha gente se movió al teléfono, pero eso también podría desaparecer pronto

    • Igual, si termina mandándome al buzón de voz, también voy a colgar, así que no habría diferencia
    • Si la IA malinterpreta lo que digo y al final me transfiere con una persona, me cansa tener que contar lo mismo dos veces
    • Hace poco estuve buscando auto y contacté a varios concesionarios; solo después me di cuenta de que todos eran supuestos asesores con nombres falsos basados en LLM. Respondían tan rápido que se sentía raro
  • Dijeron que “esto no es un chatbot de propósito general”, pero en la práctica no deja de ser un chatbot de propósito general modelo 2026

  • Vi la página “About” del blog, y ahí dice que el autor se inspiró en un influencer que se hizo rico aprendiendo a programar. Pero esa actitud está bastante lejos del tipo de cultura de ingeniería que yo quisiera ver

  • Me deprime un poco que la gente esté escribiendo blogs personales con IA

    • Aun así, valoro que lo haya dicho con honestidad. La mayoría no tiene mucha experiencia escribiendo y cree que con un LLM obtiene “texto bien escrito”. Para esas personas, tal vez un texto hecho por IA ni siquiera les parezca malo
  • ¿De verdad hace falta RAG aquí? Si solo se trata de una lista de precios y horarios, todo cabe dentro de la ventana de contexto

    • Probablemente haya sido un proyecto hecho para aprender. A veces yo también uso una arquitectura excesiva en proyectos personales para experimentar y aprender
    • En una conversación por voz, el problema mayor es la latencia. Si el sitio tiene varias páginas, usar RAG para traer rápido solo una parte y dejar que el LLM genere la respuesta detallada podría ser eficiente
    • Sería más simple meter todo el sitio web y la lista de precios en el contexto
    • También estoy de acuerdo. Esa cantidad de información se puede procesar de una sola vez sin problema
    • En general, esta arquitectura está sobredimensionada