ফোন লাইনে একটি স্থানীয় এলএলএম বসানোর মাধ্যমে আমরা যা শিখেছি

প্রতিটি ম্যানেজড ভয়েস এআই প্ল্যাটফর্ম মিনিটে বিল করে। এটা যুক্তিসঙ্গত মনে হয় যতক্ষণ না আপনি একটি সাপোর্ট লাইনে এটি ব্যবহার শুরু করেন, কারণ একজন ভালো এজেন্টের পুরস্কার হলো আরও বেশি কল উত্তর দেওয়া, আর আরও বেশি কল উত্তর দেওয়ার পুরস্কার হলো একটি বড় ইনভয়েস। এটি যত ভালো হবে, খরচ ততই বাড়বে। একটি সাপোর্ট লাইনে, যা ঠিকই ভলিউম সামলাতে তৈরি, সেখানে এমন ইনসেনটিভ নেওয়া ভুল।

আমরা Vocale তৈরি করেছি ব্যবসায়িক ফোন লাইনের উত্তর দেওয়ার জন্য: এটি প্রথম রিং-এ কল ধরে, কোম্পানির নিজস্ব ম্যানুয়াল ও নীতিমালা অনুযায়ী উত্তর দেয়, এবং যখন সৎ উত্তর হয় যে কাউকে বিষয়টি দেখতে হবে, তখন একটি সাপোর্ট টিকিট খুলে। শুরুতে আমরা এমন একটি সিদ্ধান্ত নিয়েছিলাম যা পরবর্তীতে সবকিছুই নির্ধারণ করে দিয়েছে। এই প্ল্যাটফর্ম একটি পণ্যের পেছনে দুটি ইঞ্জিন ব্যবহার করে। হোস্টেড স্তরে, স্পিচ রিকগনিশন, রিজনিং এবং ভয়েস সিন্থেসিস তৃতীয় পক্ষের একটি API থেকে আসে এবং প্রতিটি মিনিটের ব্যবহার পরিমাপ করা হয়। স্ব-হোস্টেড স্তরে, এই তিনটিই ব্যবসার নিয়ন্ত্রণাধীন একটি GPU-তে চলে, কোনো অডিও বা ডকুমেন্ট ভবন থেকে বের হয় না, এবং একটি কলের জন্য বিদ্যুৎ খরচ হয়।

দুটি স্তরই কলকার দিক থেকে একইভাবে আচরণ করে। সেগুলো সেখানে নিয়ে যাওয়াটাই ছিল আকর্ষণীয় অংশ, এবং এটাই আমরা শিখেছি।

আসলে লুপে কী আছে

ভয়েস এজেন্ট হল মাইক্রোফোন লাগানো কোনো চ্যাটবট নয়। একটি কথোপকথনের পালা একটি শৃঙ্খলের মতো, এবং প্রতিটি লিঙ্ক এমন একটি বিলম্ব যোগ করে যা মানুষ শুনতে পারে।

অডিও WebRTC-র মাধ্যমে একটি LiveKit রুমে আসে। ভয়েস অ্যাক্টিভিটি ডিটেকশন (আমরা Silero ব্যবহার করি) নির্ধারণ করে কখন কলকারী আসলে কথা বলা শুরু করেছে এবং থেমেছে। বাফারকৃত অডিও Faster-Whisper-এ পাঠানো হয় এবং একটি ট্রান্সক্রিপ্ট হিসেবে ফিরে আসে। সেই টার্নটি Postgres-এ লেখা হয়, তারপর চ্যাটের প্রসঙ্গ এবং ইতিহাস ভাষা মডেলে পাঠানো হয়, যা আমাদের স্ব-হোস্টেড টিয়ারে vLLM দ্বারা পরিবেশিত Qwen3-8B। টোকেনগুলো ফিরে আসে, স্বাভাবিকীকৃত ও একত্রিত হয়ে সম্পূর্ণ বাক্যে রূপান্তরিত হয়, এবং তারপরই XTTS-v2-এ পৌঁছায়, যা সেগুলোকে অডিও ফ্রেমে রূপান্তরিত করে এবং WebRTC-র মাধ্যমে আবার পাঠায়।

চারটি মডেল, একটি ডাটাবেস রাইট, এবং একটি রাউন্ড ট্রিপ—সবই সেই বিরতির মধ্যে সম্পন্ন হয় যা একজন কলকারী নীরবতায় "হ্যালো?" বলার আগে সহ্য করে।

সেই চেইনটি লোকালভাবে চালানো কঠিন কাজ নয়। আলোচনা-গতিতে এটিকে লোকালভাবে চালানো, এমন হার্ডওয়্যারে যা একটি মাঝারি আকারের ব্যবসা সত্যিই কিনবে, এটাই প্রকৃতপক্ষে প্রকৌশলগত চ্যালেঞ্জ।

প্রথম পাঠ: বাধা একটি পণ্য বৈশিষ্ট্য, কোনো ব্যতিক্রম নয়

কলকারীরা এজেন্টের কথার ওপর কথা বলেন। তারা এটা ক্রমাগত করে, এবং তারা ঠিক তখনই করে যখন তারা যথেষ্ট শুনে ফেলে, যা সাধারণত বিশ-শব্দের উত্তরের প্রায় ছয়টি শব্দেই হয়। একজন এজেন্ট যদি কথা চালিয়ে যায়, তাহলে সেটি এমনভাবে ত্রুটিপূর্ণ মনে হয় যেখান থেকে ফিরে আসা কঠিন, কারণ মানবিক প্রবৃত্তি হলো জোরে কথা বলা, এবং তখন দুই পক্ষই একসঙ্গে এমন একটি সিস্টেমে কথা বলছে যা কারো কথাই শুনছে না।

আউটগোয়িং অডিও বন্ধ করাটাই স্পষ্ট অর্ধেক। যে অর্ধেকটি মিস করা সহজ তা হলো ট্রান্সক্রিপ্ট। যদি এজেন্টের নিজস্ব রেকর্ডে এখনও সে যা বলতে চেয়েছিল তার পুরো বাক্যটি থাকে, তাহলে কথোপকথনটি এমন একটি কল থেকে চালিয়ে যাওয়া হয় যা আসলে কখনোই হয়নি। "আপনি যে দ্বিতীয় বিকল্পটির কথা উল্লেখ করেছিলেন" সম্পর্কে একটি ফলো-আপ প্রশ্ন করুন, এবং এজেন্ট আত্মবিশ্বাসের সাথে এমন কিছু উত্তর দেবে যা কলকারী কখনোই শোনেনি।

সুতরাং যখন বক্তৃতা সনাক্ত হয়, আমরা অডিও বন্ধ করি এবং তারপর এজেন্টের সংরক্ষিত পালাকে প্রকৃতপক্ষে উচ্চস্বরে যা বলা হয়েছে তার মধ্যে সীমাবদ্ধ করি। কথোপকথনটি চালিয়ে যায় কলকারী যে কলটি অনুভব করেছে সেখান থেকে, সিস্টেম যেটি পরিকল্পনা করেছিল সেখান থেকে নয়।

পাঠ দুই: আপনি বিলম্ব দূর করতে পারবেন না, তাই আপনাকে তা পূরণ করতে হবে

যখন কোনো প্রশ্নে তথ্যের প্রয়োজন হয়, এজেন্ট উত্তর দেওয়ার আগে সূচিবদ্ধ নথিগুলো অনুসন্ধান করে। সেই অনুসন্ধানটি এতটাই দীর্ঘ হয় যে তা কথার ফাঁক হিসেবে শোনা যায়। ফোন কলের নীরবতা নিরপেক্ষ নয়। এটি উদ্বেগজনক।

আমরা প্রায় অর্ধ সেকেন্ডের মধ্যে একটি সংক্ষিপ্ত, স্বাভাবিক ফিলার চালু করি, এবং যদি রিট্রিভাল (তথ্য আহরণ) আগে ফিরে আসে তবে তা বাতিল করি। এটি একটি ছোট আচরণ, কিন্তু এর প্রভাব ব্যাপক: এটি রিট্রিভালকে প্রয়োজনীয় সময় দেয়, এবং সেই সময়ের একটুও কলারকে 'ডেড এয়ার' (নীরবতা) হিসেবে অনুভূত হয় না।

এই বিষয়টি স্ব-হোস্টেড স্তরে আরও বেশি গুরুত্বপূর্ণ, কম নয়। একটি GPU-তে চলমান লোকাল মডেলের ল্যাটেন্সি বৈশিষ্ট্য হাইপারস্কেলার API-এর থেকে আলাদা, এবং তা সবসময়ই খারাপ নয়। বরং সেগুলো ভিন্নভাবে বিতরণ করা থাকে। কথোপকথনটিকে পরিবর্তনশীল ল্যাটেন্সি সহনশীল করে ডিজাইন করার ফলে আমরা এজেন্টের অনুভূতিতে কোনো পরিবর্তন না এনে মডেলগুলো কোথায় চলবে তা পরিবর্তন করতে পেরেছি।

তৃতীয় পাঠ: লিখিত পাঠ্য জোরে পড়তে হয় না

টাকার পরিমাণ, তারিখের সংখ্যা, সময়, সংক্ষিপ্তরূপ, পণ্যের কোড। এগুলো সবই স্ক্রিনে ঠিকই আছে, কিন্তু কণ্ঠে ভুল শোনায়। একটি স্পিচ মডেলকে "1,250.00 by 15/03" দিন, এবং আপনি এমন কিছু শুনবেন যা কোনো মানুষ কখনোই উচ্চস্বরে বলেনি।

আমরা ভাষা মডেল এবং স্পিচ মডেলের মধ্যে একটি নরম্যালাইজেশন লেয়ার ব্যবহার করি যা সিন্থেসিসে যাওয়ার আগে পরিমাণ, তারিখ, সময় এবং সংক্ষিপ্ত রূপগুলোকে প্রতিটি ভাষার জন্য তাদের কথ্য রূপে পুনঃলিখন করে। ভোকাল ছয়টি ভাষায় চলে, এবং এই লেয়ারটি প্রতিটি ভাষার জন্য আলাদা কারণ নিয়মগুলো প্রকৃতপক্ষে ভিন্ন। কোনো শর্টকাট নেই যেখানে আপনি একবার ইংরেজির জন্য লিখে তা অনুবাদ করে ফেলবেন।

এটি সিস্টেমের সবচেয়ে কম আকর্ষণীয় উপাদান এবং এজেন্টটি মানুষ না ফোন ট্রি মনে হচ্ছে কিনা তার উপর এর প্রভাব সবচেয়ে বেশি।

পাঠ চার: সীমা নির্ধারণ করে VRAM, কম্পিউট নয়

এটিই সেই বিষয় যা আমাদের সবচেয়ে বেশি অবাক করেছে, এবং এটিই হার্ডওয়্যার আকার নির্ধারণের পদ্ধতি সবচেয়ে বেশি পরিবর্তন করে।

একটি লাইভ ভয়েস সেশন কলের সময়জুড়ে তার মডেলগুলোকে ভিডিও মেমরিতে ধরে রাখে। তাই সমান্তরালতা কাঁচা থ্রুপুট দ্বারা নয়, VRAM দ্বারা সীমাবদ্ধ। আপনার এমন একটি কার্ড থাকতে পারে যার কম্পিউট ক্ষমতা অব্যবহৃত, কিন্তু সে আর একটি কল নিতে পারবে না, কারণ মডেলগুলো রাখার জন্য কোনো জায়গা নেই।

আরও খারাপ, যদি আপনি ফ্রেমওয়ার্ককে ডিফল্টভাবে GPU পুল করতে দেন, তাহলে স্পিচ এবং ভাষা সম্পর্কিত কাজ একই কার্ডে চলে এবং একে অপরকে রিসোর্স থেকে বঞ্চিত করে। এর লক্ষণ কোনো ত্রুটি নয়। এটি এমন একটি সমস্যা যেখানে লোডের অধীনে কথোপকথন ধীর হয়ে যায়, যা কোনো একক উপাদানের দোষে হয় না। আমরা এখন প্রতিটি কার্ডে সেশন বরাদ্দ করি এবং কাজের চাপ স্পষ্টভাবে বিভিন্ন কার্ডে ভাগ করি।

যদি আপনি স্ব-হোস্টেড ডিপ্লয়মেন্টের পরিকল্পনা করেন, তাহলে প্রথমেই ভিডিও মেমোরির বিপরীতে সমান্তরাল কলগুলো গণনা করুন। বাকি সবকিছু সেই সংখ্যা থেকে নির্ধারিত হবে।

যা অপরিবর্তিত থাকে

গ্রাউন্ডিং অপরিবর্তিত থাকে। উভয় স্তরেই এজেন্ট মডেলের মেমোরি থেকে নয়, বরং ব্যবসার আপলোড করা ডকুমেন্ট থেকে উত্তর দেয়: যে কোনো তথ্যের প্রয়োজন এমন একটি প্রশ্ন একটি অনুসন্ধানকে ট্রিগার করে, এবং প্রাপ্ত ফলাফল থেকে উত্তরটি একত্রিত করা হয়। যখন কোনো প্রাসঙ্গিক তথ্য পাওয়া যায় না, তখন সেটি জানিয়ে একটি টিকিট খুলতে প্রস্তাব করাই সঠিক উত্তর, এবং এজেন্ট ঠিক সেটাই করে। একটি ছোট স্থানীয় মডেল আরও বেশি কাল্পনিক তথ্য তৈরি করার অনুমতি নয়, কারণ মডেলটি প্রথম থেকেই সত্যের উৎস নয়। তথ্য পুনরুদ্ধারই (Retrieval) মূল উৎস।

হ্যান্ডওভারও পরিবর্তিত হয় না। যখন এজেন্ট সাহায্য করতে পারে না, তখন কলকারী লাইনে থাকা অবস্থায় এটি বিষয়, যোগাযোগকারী এবং অগ্রাধিকারের তথ্য সংগ্রহ করে, টিকিট ফাইল করে এবং ট্রান্সক্রিপ্ট সংযুক্ত করে।

একই আচরণের বিপরীতে উভয় স্তর তৈরি করার মূল কারণই এটি। এদের মধ্যে পরিবর্তন করা একটি কনফিগারেশন, পুনর্নির্মাণ নয়।

তাহলে কোনটি আপনি চালাবেন?

সত্যি বলতে: হোস্টেড দিয়ে শুরু করুন।

হোস্টেড স্তর হল আপনার লাইনের এজেন্ট আসলে কতটা উপকারী তা জানতে সবচেয়ে দ্রুততম উপায়, এবং এটি একটি পণ্য-সংক্রান্ত প্রশ্ন, অবকাঠামো-সংক্রান্ত নয়। আমাদের নিজস্ব কনসোল এটিকে প্রতি কল মিনিটে প্রায় ছয় সেন্ট হিসেবে পরিমাপ করেছে। দিনে কয়েক ডজন কল গ্রহণকারী একটি ব্যবসার জন্য, এটি প্রথমে অপ্টিমাইজ করার মতো কোনো আইটেম নয়।

সেলফ হোস্টিং দুইটি সীমার উপর ভিত্তি করে লাভজনক হয়, এবং সেগুলো ভিন্ন সীমা।

প্রথমটি হল পরিমাণ। মিটারকৃত খরচ গ্রহণের সাথে সাথে বাড়ে, হার্ডওয়্যারের খরচ বাড়ে না, তাই একটি ক্রসওভার পয়েন্ট রয়েছে যেখানে GPU-ই সস্তা হয়ে যায়। সেই বিন্দুটি কোথায় অবস্থান করছে তা আপনার কল ভলিউমের উপর নির্ভর করে, এবং অনুমান করার চেয়ে আপনাকে এটি পরিমাপ করা উচিত। Vocale মিটারগুলি ঠিক এই কারণেই প্রতিটি মডেল এবং প্রতিটি সংস্থার জন্য ব্যয় পরিমাপ করে: API এবং কার্ডের মধ্যে পছন্দটি একটি যুক্তি নয়, বরং একটি সংখ্যার ভিত্তিতে হওয়া উচিত।

দ্বিতীয় সীমাটির অর্থের সাথে কোনো সম্পর্ক নেই। কিছু ব্যবসা নিয়ন্ত্রক, ক্লায়েন্ট চুক্তি বা নীতির কারণে কল অডিও, ট্রান্সক্রিপ্ট বা অভ্যন্তরীণ নথি তৃতীয় পক্ষের কাছে পাঠাতে পারে না। তাদের জন্য স্থানীয় স্তর কোনো অপ্টিমাইজেশন নয়। এটি এই পণ্যের একমাত্র সংস্করণ যা বিদ্যমান থাকতে পারে, এবং প্রতি মিনিটের কোনো মূল্য না থাকায় হোস্টেড স্তর গ্রহণযোগ্য করে তোলে।

যেকোনো ভয়েস এআই বিক্রেতাকে মূল্যায়ন করার সময় এই দুইটি সীমা আলাদা করে দেখা উচিত। একটি প্ল্যাটফর্ম যদি শুধুমাত্র মিটারযুক্ত ইনফারেন্স অফার করে, তাহলে তারা নীরবে সিদ্ধান্ত নিয়েছে যে দ্বিতীয় সীমাটি আপনার ক্ষেত্রে প্রযোজ্য নয়।

সংক্ষিপ্ত সংস্করণ

আজকাল সাপোর্ট লাইনে লোকাল ইনফারেন্স ব্যবহারিক। মডেলগুলো যথেষ্ট ভালো, এবং টুলিং (vLLM, Faster-Whisper, XTTS-v2, LiveKit) এতটাই পরিপক্ক যে পাইপলাইন আর ঝুঁকি নয়।

ঝুঁকিগুলো হল সেগুলো যা কেউ ডেমোতে দেখায় না: বাধা পড়া, আপনি যখন ভাবছেন তখনও উপস্থিত শোনা যাওয়া, মানুষের মতো সংখ্যাগুলো জোরে জোরে পড়া, এবং জানা যে আসলে একটি কার্ডে কতগুলো কথোপকথন ফিট করে। এগুলো ঠিকঠাক করে ফেললে হোস্টেড API এবং আপনার নিজস্ব GPU-এর মধ্যে পছন্দটি ঠিক সেই রকম হয়ে যায়, যেমনটি হওয়া উচিত ছিল: এটি আপনার বাজেটে একটি সীমা, না যে আপনি কী তৈরি করতে পারবেন তার উপর কোনো বাধা।

• Local LLM
• Voice AI
• Self-hosted
• RAG
• vLLM
• LiveKit
• Support automation