تصور کنید برنامهنویسی هستید که میخواهد سریعاً یک سیستم تحلیل تماس را پیاده کند، اما به جای نوشتن چند خط کد، باید ساعتها درگیر دریافت توکنهای دسترسی و پذیرش لایسنسهای پیچیده شود. این همان سد بزرگی است که بسیاری از توسعهدهندگان هنگام استفاده از مدلهای پیشرفته برای تفکیک گوینده با آن مواجه میشوند. آیا واقعاً پردازش سیگنالهای پایه میتواند در تفکیک سادهی گوینده، عملکرد بهتری نسبت به مدلهای پیچیده هوش مصنوعی داشته باشد؟ توسعهدهنده کتابخانه AudioTrace ثابت کرده است که پاسخ مثبت است. او نشان داد که اندازهگیری ویژگیهای فیزیکی یک شکلموج (Waveform)، اغلب قابلاعتمادتر از تخمین آنها توسط یک مدل است، بهویژه زمانی که تجربه کاربری در اولویت باشد.
طبق گزارش سازندگان کتابخانه AudioTrace، در بسیاری از محیطهای عملیاتی، توسعهدهندگان برای جداسازی گوینده به pyannote متکی هستند. این ابزار قدرتمند است، اما یک «مدل گیتدار» (Gated Model) است؛ به این معنا که پیش از دانلود وزنهای مدل، کاربر باید یک حساب Hugging Face داشته باشد، توکنی دریافت کند و یک قرارداد لایسنس را امضا کند. برای کاربری که صرفاً یک کتابخانه را از طریق pip نصب میکند و میخواهد نتیجه را ببیند، این فرآیند یک مانع ورود شدید ایجاد میکند. بدون توکن، هر نوبت گفتگو با برچسب unknown باز میگردد و منجر به ایجاد یک «دیواری از ناشناسان» میشود که باعث میشود کاربران تازهوارد از سیستم فاصله بگیرند.
همانطور که در تحلیلهای پیشین ما دربارهی بهینهسازی هزینههای استنتاج اشاره کردیم، تمایل به استفاده از سنگینترین مدل برای سادهترین وظایف، یک تلهی رایج در توسعه است. این چالش در مدیریت منابع، بهویژه زمانی که بحث پایش توکنها برای مهار هزینههای استنتاج مطرح میشود، بیش از پیش نمایان میگردد. برای حل این مشکل، سازنده AudioTrace ابتدا دو جایگزین برای مدلهای گیتدار را تست کرد. روش اول، یک «جایگزین ساده» (Naive Alternator) بود که هر بار مدل تشخیص گفتار (مانند Whisper) قطعهای جدید میساخت، برچسب گوینده را عوض میکرد. اما این روش شکست خورد، چون Whisper بر اساس جملات قطعهبندی میکند، نه بر اساس تغییر گوینده. برای مثال، اگر یک عامل پشتیبانی بگوید: «سلام! ممنون که تماس گرفتید. چطور میتوانم امروز به شما کمک کنم؟»، مدل Whisper این عبارت را به سه قطعه تقسیم میکند. در این حالت، سیستم جایگزین، برچسب را در میانه یک گفته تغییر میدهد و به غلط، بخشهای مختلف یک جمله را به هر دو طرف (عامل و مشتری) نسبت میدهد.
راهکار موفق، تغییر نگاه از «تخمین» به «سنجش» بود. به جای اینکه از مدل بخواهند حدس بزند چه کسی حرف میزند یا یک راهکار مدلمحور را تحمیل کند، توسعهدهنده این سوال را پرسید: «چه چیزی به طور فیزیکی در صوت وجود دارد که دو گوینده را از هم متمایز میکند؟». در یک تماس پشتیبانی معمولی، عامل و مشتری معمولاً زیروبمی (Pitch) صدای noticeably متفاوتی دارند. این یک ویژگی فیزیکی از شکلموج است که پردازش سیگنال میتواند آن را به صورت ارزان و دقیق اندازهگیری کند، شبیه به تنظیم دقیق یک رادیو برای گرفتن فرکانس خاص. در واقع، نادیده گرفتن این لایه فیزیکی اغلب منجر به شکست عاملهای صوتی در مقیاس عملیاتی میشود، زیرا مدلها لایهی صوتی را بهدرستی درک نمیکنند.
بر اساس مستندات فنی این پروژه، پیادهسازی این سیستم با استفاده از کتابخانههای librosa و numpy انجام شده و یک تفکیک دوطرفه بر اساس فرکانس بنیادی (f0) را اجرا میکند. این فرآیند از مکانیزمهای دقیق زیر پیروی میکند:
- سنجش زیروبمی: کتابخانه از تابع
librosa.pyinبرای محاسبه میانگین فرکانس بنیادی (بر حسب هرتز) در هر قطعه از متن تبدیلشده استفاده میکند. - محدوده فرکانسی: سیستم به طور خاص بخشهای صوتی (Voiced Segments) را در بازهای بین نت C2 تا C7 فیلتر میکند.
- خوشهبندی: کد با استفاده از
np.medianروی تمام فرکانسهای معتبر، یک حد آستانه (Threshold) را محاسبه میکند. - تخصیص برچسب: قطعات صوتی به دو گروه تقسیم میشوند؛ خوشهی با فرکانس پایین به برچسب اول (مثلاً «عامل هوش مصنوعی») و خوشهی با فرکانس بالا به برچسب دوم (مثلاً «مشتری») اختصاص مییابد.
به نقل از گزارش این تیم، این متد قطعی (Deterministic) تنها با چند ده خط کد اجرا میشود و در میلیثانیهها بدون نیاز به GPU — که مانند کرایه یک آشپزخانه صنعتی برای پردازش است — پاسخ میدهد. این مسیر «راهاندازی صفر» (Zero-setup) است؛ یعنی کاربر بلافاصله بعد از نصب، نتیجه را میبیند. در عین حال، سیستم همچنان به کاربر اجازه میدهد تا در صورت نیاز به کیفیت بالاتر — مثلاً برای مدیریت سه گوینده یا بیشتر، صحبتهای همزمان (Overlapping) و مواردی که دو نفر صدای بسیار مشابهی دارند — با وارد کردن hf_token به pyannote بازگردد.
این چرخش، یک اصل کلیدی در مشاهدهپذیری (Observability) عملی است و بر تنشی رو به رشد در توسعه AI اشاره دارد: عادت به استفاده از بزرگترین مدل ممکن بدون توجه به ماهیت وظیفه. با پرسیدن این سوال که «کدام سیگنال واقعاً حضور دارد؟» به جای «کدام مدل را باید دانلود کنم؟»، توسعهدهندگان میتوانند ابزارهایی بسازند که ارزانتر باشند و استدلال درباره آنها سادهتر باشد. چون این اندازهگیری برای اجرا روی تکتک تماسها مقرونبهصرفه است، برای شناسایی عقبگردها (Regressions) بسیار مؤثرتر است.
برای کاربر نهایی، این یعنی AudioTrace اکنون میتواند یک گزارش ساختاری (CallReport) شامل برچسبهای گوینده، کیفیت، تحلیل احساسات، تأخیر (Latency) و هزینه را بدون نیاز به اعتبارنامههای خارجی تولید کند.
گام بعدی شما
- اگر در حال توسعه ابزارهای تحلیل تماس هستید، ابتدا سنجش فرکانس (Pitch) را برای تفکیک گویندگان امتحان کنید تا هزینه استنتاج را به صفر نزدیک کنید.
- از کتابخانه librosa برای تحلیل طیفنگاشت صداها در محیطهای محلی استفاده کنید.
- بررسی کنید آیا تغییر در پرامپتهای شما، تأخیر یا لحن عامل را تغییر داده است.
در ادامه، این پروژه قصد دارد این سیگنالها را با استفاده از OpenTelemetry spans در کنار ردیابیهای LangChain و LangSmith در خطوط لوله CI/CD ادغام کند. این قابلیت به تیمها اجازه میدهد تا اگر تغییری در پرامپت باعث شد عامل کندتر، سردتر یا کمتر متعهد به قوانین شود، ساخت (Build) را به طور خودکار شکست دهند (Fail करें).
گفتگو