Show HN: 500ms प्रतिक्रिया समय वाला वॉइस बॉट

 (fastvoiceagent.cerebrium.ai)
1 पॉइंट द्वारा GN⁺ 2024-06-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • वॉइस AI को सामान्य बातचीत की तरह तुरंत प्रतिक्रिया देनी चाहिए ताकि वह स्वाभाविक लगे, इसलिए इस डेमो का लक्ष्य 500ms voice-to-voice response है
  • मुख्य चुनौती उपयोगकर्ता द्वारा महसूस की जाने वाली latency को कम करना है, जिस पर नेटवर्क और मॉडल प्रोसेसिंग समय दोनों असर डालते हैं
  • यह डेमो optimization और deployment तरीकों के जरिए दिखाता है कि low-latency LLM interaction किस हद तक संभव है
  • implementation में वॉइस और multimodal conversational AI के लिए open source framework Pipecat का उपयोग किया गया है
  • वास्तविक प्रोडक्ट-स्तर का conversational voice bot बनाने के लिए सिर्फ मॉडल परफॉर्मेंस नहीं, बल्कि पूरे call path की latency management भी महत्वपूर्ण है

500ms वॉइस प्रतिक्रिया को लक्ष्य बनाने वाला डेमो

  • The World's Fastest Voice Bot Demo एक ऐसा डेमो है जो दिखाता है कि वॉइस-आधारित AI chatbot कितनी तेजी से प्रतिक्रिया दे सकता है
  • लक्ष्य voice-to-voice 500ms response time हासिल करना है
  • लोग सामान्य बातचीत में तेज प्रतिक्रिया की अपेक्षा करते हैं, इसलिए वॉइस AI interface में गति एक प्रमुख quality factor बन जाती है

latency कम करने की implementation दिशा

  • यह डेमो low-latency LLM interaction पर केंद्रित है
  • यह नेटवर्क latency और मॉडल latency दोनों को न्यूनतम करने के लिए optimized और deployed वॉइस AI chatbot की संभावनाएँ दिखाता है
  • बॉट को Pipecat से बनाया गया है
    • Pipecat वॉइस और multimodal conversational AI के लिए एक open source framework है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-06-28
Hacker News की राय

  • वाकई तेज़। बढ़िया और साफ़-सुथरा। लगता है speed बाकी सब पर भारी पड़ती है। comments पढ़ने के बाद ही मुझे robotic voice का ध्यान गया
    मैंने customer support के लिए AI बनाया था, जिसमें average response time 24–48 घंटे से घटकर कुछ सेकंड हो गया था
    एक customer को “Hello Bitch, your package will be picked up by USPS today...” जैसा message चला गया, लेकिन customer ने “thank you so much” जवाब दिया और CSAT में full marks दे दिए। इतनी गंभीर गलती के बावजूद speed सब पर भारी पड़ती है

    • मुझे नहीं लगता कि हर कोई ऐसे react करेगा। कुछ लोगों के लिए एक-दूसरे को bitch कहना रोज़मर्रा की बोलचाल हो सकती है, इसलिए training data में आ गया होगा, लेकिन दूसरों के लिए ऐसा बिल्कुल नहीं हो सकता
    • मज़ेदार बात यह है कि इस समस्या को #profanity tag जोड़कर और message को अगले agent को pass करने के तरीके से fix किया गया
      लेकिन सबसे active sales engineer अब prospects के लिए demo नहीं कर पा रहा था। कई awkward calls हुईं जिनमें AI बस respond ही नहीं करता था, क्योंकि उसका surname Dick था
    • solution यह हो सकता है कि message को एक और LLM से pass कराया जाए, जो गालियां हटाकर उसे जितना हो सके उतना विनम्र बना दे। हालांकि इसे चलाने की लागत 2 गुना से भी ज़्यादा हो जाएगी
    • शायद वह customer का नाम ही रहा हो। कम से कम customer ने अपना नाम ऐसा ही enter किया हो सकता है

  • बहुत, बहुत अच्छा। अगर मैंने सही समझा, तो यह Cerebrium को दिखाने के लिए teaser app जैसा लगता है, लेकिन इसमें killer app बनने की काफी संभावना है। iPad पर test करने पर reported latency 1400ms से 400ms के बीच थी, और lower end पर experience बहुत smooth लगा
    इस level की speed पर कुछ chat workflows में multi-step approach ज़रूरी या संभव हो सकती है। पहले तुरंत response दें, और उसी दौरान लंबी data/info/RAG query अलग से चलाएं, फिर information वाला result बाद में आगे संभाल ले
    इंसान भी ऐसे ही काम करते हैं। जवाब शुरू करते हुए अपने विचार व्यवस्थित करने के लिए कई fillers इस्तेमाल करते हैं
    अभी ज़्यादातर workflows में या तो एक ही बार prompt फेंका जाता है, या background में parsing → query → generation होती है, लेकिन low-latency response संभव हो जाए तो बेहतर flow शायद कुछ ऐसा होगा: “[कान में 3 सेकंड के लिए Llama 8B] → query → [query result को शामिल करने वाला 55 सेकंड का Llama 70B/GPT-4 आदि]”

    • Cerebrium की तरफ़ से। feedback के लिए बहुत धन्यवाद, और खुशी है कि आपका experience अच्छा रहा
      इस application को आसानी से extend या implement किया जा सकता है, इसलिए आप इसे अपनी ज़रूरत के हिसाब से modify कर सकते हैं। किसी दूसरे LLM, speech recognition, speech synthesis model पर switch कर सकते हैं, prompt बदल सकते हैं और RAG जैसी चीज़ें भी implement कर सकते हैं
      Daily के साथ मिलकर हमने engineers पर focus किया। मकसद था कि use case और preference के हिसाब से application को बहुत flexible तरीके से बदला जा सके, और boring infra setup का बोझ कम हो
      इसे extend करने के तरीके यहां और देख सकते हैं: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
    • मुझे भी यही curiosity थी। क्या एक छोटा और efficient LLM संभव है, जो actual full workload चलाए बिना general task complexity का estimate लगा सके?
      अगर complexity को continuous value के तौर पर score किया जा सके, तो लंबी round trip का इंतज़ार करने के बजाय पता चल सकता है कि “हाँ, ज़रा रुकिए। मैं देखता हूँ” जैसा response पहले भेजना चाहिए या नहीं

  • cross-platform browsers के लिए voice activity detection module के रूप में https://github.com/ricky0123/vad है। यह Silero के VAD network को ONNX में port किया गया है। cross-platform का मतलब है कि यह Firefox में भी चलता है। WebRTC session की ज़रूरत नहीं, सिर्फ़ mic access चाहिए, इसलिए यह ज़्यादा सरल है। यह भी दिलचस्प है कि browsers ऐसी capability native option के तौर पर दें
    browser-based text-to-speech engines भी हैं, और वे लगातार तेज़ और बेहतर quality वाले हो रहे हैं। अच्छा होगा अगर browser में बेहतरीन TTS default रूप से included हो
    GPT-4o ने low latency के लिए automatic speech recognition, understanding और voice response generation को एक ही model में रखा है, जो काफी अच्छा idea लगता है। अभी तक release नहीं हुआ है, तो लगता है किसी न किसी रूप में scalability या quality की समस्या है
    इसी तरह audio input/output और visual input तक वाले open integrated multimodal large language models बनाने वाले लोग भी शायद होंगे
    latency और cost optimization के लिहाज़ से single combined model कितना ज़रूरी और optimal है, यह जानने की उत्सुकता है
    दिया गया breakdown interesting है। अगर संभव हो, तो voice generation, और शायद शुरुआत वाली speech transcription या speech understanding तक, ज़्यादा models device पर चलाना बेहतर लगता है। STUN का इंतज़ार कौन करना चाहेगा?

    • मुझे लगता है desktop environment को standard interface वाली service के रूप में speech-to-text conversion provide करना चाहिए। stdin जैसा, लेकिन voice के लिए अलग interface जैसा
      apps default रूप से सुन नहीं रहे होंगे, इसलिए ignore करेंगे, लेकिन transcriber replaceable होगा और सभी apps में इस्तेमाल किया जा सकेगा
    • इन numbers के हिसाब से, अगर speech recognition और speech synthesis device पर भी process हों और बाकी सब वैसा ही रहे, तो सिर्फ़ 120ms कम होंगे। बचा हुआ 639ms hardware/network latency और data को LLM के अंदर-बाहर ले जाने में जाता है। फिर भी यह desired speed से धीमा है
      logically हमें phoneme level पर सोचना होगा। LLM output को आखिरी phoneme तक काफी तेज़ी से catch up करना होगा, ताकि endpoint detect होते ही “तुरंत” response दिया जा सके, और इसके लिए पूरी chain में end-to-end latency लगभग 200ms होनी चाहिए
      उसके करीब पहुंचने के लिए शायद अलग architecture चाहिए। इंसानी speech processing की तरह: आने से पहले predicted phonemes के आधार पर audio stream से आगे चलना, और actual received audio को सिर्फ़ हल्के confirmation signal की तरह इस्तेमाल करना कि current output buffer खाली करना है या फिर reprocess करना है
      speculative decoding से कुछ हद तक पहुंचा जा सकता है, लेकिन audio/text mixed pipeline में यह मुश्किल लगता है। शुरुआत में ही audio को text में बदलकर फिर वापस audio में न बदलना कहीं बेहतर है
    • यह announcement मेरे बनाए जा रहे काम पर पूरी तरह भारी पड़ गई, लेकिन rick0123/VAD और WebSocket इस्तेमाल करने वाला एक simple assistant implementation है
      https://github.com/charlesyu108/voiceai-js-starter

  • खुद इस्तेमाल करके देखा तो मज़ेदार लगा। इस हफ्ते की शुरुआत में मैंने june-va इस्तेमाल किया था, लेकिन लंबा response time इसकी उपयोगिता को काफी कम कर रहा था। तेज़ response एक शानदार feature है, और यह कहीं ज़्यादा बातचीत जैसा महसूस होता है
    मज़ेदार बात यह थी कि जब मैंने इसे कोई कहानी सुनाने को कहा, तो यह एक बार में सिर्फ एक वाक्य जवाब देता था, इसलिए अगली लाइन सुनने के लिए मुझे “yes”, “aha”, “please continue” कहना पड़ता था
    फिर हमारी ऐसी बातचीत हुई। “आह, लगता है मैंने तुम्हारा राज़ जान लिया!” “कृपया बताइए” “तुम छोटा context बनाए रखकर short response time हासिल करते हो” “बिल्कुल सही”

    • सच कहूँ तो वह तरीका ठीक है। छोटे context के अलावा छोटे जवाब निश्चित रूप से अच्छे हैं। अभी ChatGPT voice mode में कुछ पूछो तो 1 मिनट का GPT-स्टाइल लंबा भाषण सुनने को मिलता है, इसके मुकाबले यह बेहतर है

  • बहुत प्रभावशाली। बेहद तेज़, शायद कुछ ज़्यादा ही तेज़, लेकिन लगता है यही मुख्य बात है। सबसे प्रभावशाली चीज़ यह है कि VAD और interruption handling को जिस तरह ट्यून किया गया है। अब तक किसी agent के साथ हुई बातचीत में यह साफ़ तौर पर सबसे natural सुनाई दिया। public होते ही ज़रूर इस्तेमाल करना चाहूँगा

  • marketing में 500 लिखा है, लेकिन calculation 759 दिखाती है

    • उसे ही marketing कहते हैं
    • मेरे test में 1400ms का एक outlier था, और करीब 10 बार 400~500ms के बीच रहा। marketing number fair लगा
    • 500 transcription/LLM/TTS stages का समय है, यानी server पर data पहुँचने के बाद response वापस भेजने तक का समय। बाकी encoding, network traffic जैसी कई non-AI extra latency लगती है
    • table की latency देखी गई heuristics या average पर आधारित है। असल में conversation के हिसाब से कुछ बड़े latency components काफी कम हो सकते हैं

  • मुझे भी voice inference का इंतज़ार है। OpenAI के GPT-4o launch से पहले मैंने WebSocket-based Faster Whisper implementation खुद बनाया था। मेरे interview coach concept https://intervu.trueforma.ai और sales pitch coach https://sales.trueforma.ai implementations उनके सामने पीछे रह गए
    VAD को भरोसेमंद तरीके से चलवा नहीं पाया, इसलिए default push to talk रखा। सब कुछ LattePanda पर चला रहा हूँ। Groq का hosted Whisper जोड़ने की कोशिश कर रहा था
    boring corporate-style conversations से ऊबकर LLM के लिए Groq का uncensored Llama3 इस्तेमाल करने का idea पसंद है। latency घटाना और examples से सीखना चाहता हूँ। demo भी इस्तेमाल करना चाहता हूँ, लेकिन लगता है बहुत भीड़ है, इसलिए bot के साथ conversation में जा नहीं पा रहा
    अगर एक साथ सिर्फ 3 लोग भी inference try करें, तो मेरा LattePanda पिघल जाएगा

  • निजी तौर पर मैं https://github.com/foges/whisper-dictation को Groq के llama-70b के साथ इस्तेमाल करता हूँ
    बोलना शुरू करता हूँ, website पर जाकर loading खत्म होने के बाद llama-70b चुनता हूँ, तब तक बोलना भी खत्म हो जाता है, इसलिए additional wait time 0 है। सुनने से पढ़ना कहीं तेज़ है, इसलिए मेरे लिए यह बिल्कुल fit बैठता है

  • अभी भी Firefox इस्तेमाल करता हूँ

    • मैंने यह client UI बनाया है, और सच में Firefox support करना चाहता था
      end-user के नज़रिए से voice-to-voice latency मापने का तरीका चाहिए था, और user के बोलना बंद करने का समय detect करके timer start करने और bot से audio आते ही उसे stop करने के लिए Silero voice activity detection(https://github.com/snakers4/silero-vad) सबसे भरोसेमंद लगा
      Silero onnx-runtime और wasm से चलता है। Firefox पर भी कुछ हद तक काम करता है, लेकिन VAD expected से ज़्यादा बार गलत behave करता है, जिससे latency numbers काफी अजीब हो जाते हैं। फिर भी इसे ज़रूर काम करवाना चाहता हूँ और अभी कोशिश कर रहा हूँ
      UI VAD code यहाँ है: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
    • सिर्फ warning message पर भरोसा करने की ज़रूरत नहीं है। latest Firefox में ठीक काम करता है। demo भी शानदार है
    • मुझे पसंद नहीं कि हर कोई सिर्फ Chromium को target करके develop करता है
    • HN पर Firefox इस्तेमाल करने वाले लोग काफी होंगे, ऐसा लगता है
    • Firefox 127 में पूरी तरह काम करता है

  • वाकई प्रभावशाली
    Apple का Siri अभी भी ऐसी ही बातचीत करवा पाता है जिसमें लोग एक-दूसरे की बात काटते हैं, रुकते हैं, fail होता है, और आखिर में आप बस यह उम्मीद करते रह जाते हैं कि कम से कम कोई basic जवाब मिल जाए