رابط صوتی بهتر برای فارسی: زبان فقط رونویسی نیست

یک رابط صوتی فارسی ممکن است نرخ خطای واژه قابل‌قبولی داشته باشد و درست در لحظه مهم شکست بخورد. شاید بیشتر جمله درست رونویسی شود، اما نام ذی‌نفع اشتباه باشد، مبلغ تومان به ریال فهمیده شود، تاریخ محاوره‌ای به روز نادرست تبدیل شود یا کد انگلیسی محصول با خط فارسی نوشته شود. از نگاه کاربر این‌ها خطای جزئی متن نیستند؛ کار انجام نشده یا اقدام پرریسکی آماده شده است.

مسئله طراحی از تشخیص خودکار گفتار بزرگ‌تر است. مسیر تولید شامل دریافت صوت، تشخیص مرز گفتار، شناسایی زبان و گونه، رونویسی، نرمال‌سازی متن، استخراج قصد و موجودیت، کنترل سیاست، اصلاح مکالمه و تبدیل متن به گفتار است. هر لایه برای فارسی تصمیم خاص خود را دارد. افزودن گزینه fa-IR به یک مدل چندزبانه، بومی‌سازی محصول نیست.

منابع باز جدید ارزیابی را عملی‌تر کرده‌اند، اما همان منابع نشان می‌دهند یک امتیاز کلی کافی نیست. برنامه فارسی Common Voice موزیلا گفتار خوانده‌شده و خودانگیخته جامعه‌محور فراهم می‌کند. FLEURS مجموعه ارزیابی چندزبانه‌ای با حدود دوازده ساعت صوت برای هر زبان است. معیار جامع بازشناسی گفتار فارسی یا PSRB شرایط زبانی و صوتی متنوع را می‌سنجد و گزارش می‌کند سامانه‌هایی که در فارسی معیار خوب‌اند، در لهجه منطقه‌ای، گفتار کودک و برخی پدیده‌های زبانی افت می‌کنند. این‌ها نقطه شروع‌اند، نه جانشین تماس‌های واقعی یک بانک، درمانگاه یا خدمت عمومی.

پیش از انتخاب مدل، قرارداد صوتی را تعریف کنید

ابتدا بنویسید رابط دقیقاً چه چیزی را قول می‌دهد و اجازه انجام چه اقدامی را دارد. دستیار محدود رزرو نوبت با عامل بانکی که انتقال وجه آماده می‌کند یکسان نیست. برای هر کار پشتیبانی‌شده این موارد را روشن کنید:

• گوینده، منطقه، سن، کانال و وضعیت نویزی مورد انتظار؛
• زبان و الگوی جابه‌جایی فارسی و انگلیسی در محدوده؛
• موجودیت‌های لازم با دقت کامل مانند نام، تاریخ، نشانی، مبلغ، دارو و شناسه؛
• زمان پاسخ، قطع‌کردن صدای عامل و ادامه مکالمه؛
• اقدام‌های نیازمند تأیید صریح یا بازبین انسانی؛
• سیاست نگهداری صوت، متن و داده مشتق‌شده.

این قرارداد مانع یک خطای رایج می‌شود: تیم دیکته عمومی را می‌سنجد اما محصول تراکنشی عرضه می‌کند. جمله «فارسی پشتیبانی می‌شود» آزمون‌پذیر نیست. جمله «دستیار با فارسی رسمی و محاوره‌ای تهرانی، در شرایط صوتی مشخص، نوبت می‌گیرد و نام و تاریخ را دقیق تأیید می‌کند» قابل آزمون است.

این کار باید کنار راهبرد بومی‌سازی پردازش زبان فارسی انجام شود، زیرا گفتار همان مسئله خط، واژگان، بازیابی و حاکمیت محتوای متن را به ارث می‌برد.

پیکره ارزیابی را شبیه استفاده واقعی بسازید

گفتار خوانده‌شده با گفتار خودانگیخته فرق دارد. پیکره خوانده‌شده برای مقایسه کنترل‌شده مفید است، ولی تماس‌گیرنده مکث می‌کند، جمله را از نو آغاز می‌کند، حرف خود را اصلاح می‌کند، روی صدای عامل صحبت می‌کند و عبارت رایج را کوتاه می‌گوید. واژگان حوزه نیز توزیع را عوض می‌کند: مشتری لجستیک نام خیابان و کد رهگیری، بیمار نام دارو و اندازه و کاربر پشتیبانی نام انگلیسی مدل را وسط جمله فارسی می‌گوید.

یک مجموعه آزمون رضایت‌مندانه و نسخه‌دار با برش‌های مستقل بسازید. فارسی رسمی و محاوره‌ای، چند منطقه، سن و صدا، کانال آرام و نویزی، گوشی و بلندگو، جمله کوتاه و بلند، جابه‌جایی زبان و گفتار قطع‌شده باید حضور داشته باشند. ویژگی حساس را از روی صدا حدس نزنید. فقط فراداده لازم برای ارزیابی را با رضایت روشن و مسیر حذف ثبت کنید.

داده باز پوشش را بیشتر می‌کند، اما مجوز، توزیع گوینده، شیوه ضبط، کیفیت متن و هدف جمع‌آوری آن باید مستند باشد. برای نمونه ManaTTS منبع تبدیل متن به گفتار فارسی و دستور ساخت پیکره است و داده غیررسمی همراه آن برای سنجش تشخیص گفتار هنگام هم‌ترازی به‌کار رفته است. این منبع برای پرسش مشخص مفید است، ولی ثابت نمی‌کند عامل تراکنشی برای همه فارسی‌زبانان کار می‌کند.

آزمون را از آموزش و تنظیم پرامپت جدا نگه دارید. صوت، متن مرجع، هدف نرمال‌سازی، برچسب موجودیت و نتیجه مورد انتظار مکالمه را با هم نسخه‌گذاری کنید. اگر تفسیر محصول از تاریخ یا مبلغ عوض شد، نسخه تازه بسازید؛ پاسخ قدیمی را بی‌صدا بازنویسی نکنید.

نرمال‌سازی فارسی یک سیاست محصول است

متن خام ASR الزاماً همان مقداری نیست که برنامه باید ذخیره کند. این جمله را در نظر بگیرید:

«بیست و سوم تیر ساعت پنج و نیم، برای دکتر نادری»

سامانه باید تاریخ را با تقویم و منطقه زمانی مورد نظر کاربر، ساعت را به 17:30 و نام را دقیق تبدیل کند. با این حال متن اولیه باید در اختیار مرحله بعد بماند تا تبدیل برگشت‌ناپذیر، ابهام را پنهان نکند.

تصمیم‌های تکرارشونده فارسی شامل شکل فارسی و عربی ی/ي و ک/ك، رقم فارسی و عربی و لاتین، فاصله و نیم‌فاصله، صورت نوشتاری و گفتاری عدد، تاریخ شمسی و میلادی و گاهی قمری، ریال و تومان، کوتاه‌سازی محاوره‌ای و نام و شناسه انگلیسی است.

نرمال‌سازی یونیکد را آگاهانه اجرا کنید و سپس قواعد زبانی اضافه کنید؛ جایگزینی ساده نویسه کافی نیست. برای داده مهم سه نمایش را نگه دارید: قطعه صوتی، رونویسی لفظی و مقدار نرمال‌شده برنامه. همچنین ثبت کنید کدام نسخه قاعده مقدار نهایی را ساخته است.

برای پول، تاریخ، نشانی و هویت پس از ASR از parser نوع‌دار و اعتبارسنجی قطعی استفاده کنید. مدل زبانی می‌تواند نامزد بسازد، اما حساب و تبدیل تقویم باید قابل آزمون باشد. اگر «سه و نیم» بسته به متن می‌تواند ۳٫۵ واحد یا ساعت ۳:۳۰ باشد، مکالمه باید ابهام را حل کند، نه اینکه حدس بزند.

فراتر از نرخ خطای واژه اندازه بگیرید

WER مفید است، ولی همه واژه‌ها را هم‌وزن می‌بیند. جایگزینی یک واژه پرکننده و اشتباه‌کردن نام گیرنده هر دو یک substitution محسوب می‌شوند. نرخ خطای نویسه برای املا و تفاوت خط کمک می‌کند، اما باز هم موفقیت کار را نشان نمی‌دهد.

کارت امتیاز باید دست‌کم این معیارها را داشته باشد:

1. WER و CER برای هر برش: همراه فاصله اطمینان و تعداد گوینده و جمله، نه فقط میانگین کل.
2. نرخ خطای موجودیت بحرانی: دقت لفظی و نرمال‌شده نام، مبلغ، تاریخ، نشانی و اصطلاح حوزه را جدا بسنجید.
3. دقت قاب معنایی: آیا قصد درست و همه slotهای لازم استخراج شده‌اند؟
4. تکمیل کار و خروج امن: کاربر کار را تمام کرد، به انسان رسید یا پس از چند اصلاح رها کرد؟
5. نرخ اقدام نادرست: چند بار سامانه اقدام پیامددار اشتباه را اجرا یا آماده کرد؟
6. بار اصلاح: تعداد پرسش روشن‌کننده، تکرار، تصحیح و انتقال به ازای هر کار کامل.
7. شکاف برش‌ها: تفاوت عملکرد در لهجه، کانال، نویز، رسمیت و سن که اخلاقی جمع شده است.
8. تأخیر: از پایان گفتار تا متن موقت، متن نهایی و نخستین پاسخ صوتی در صدک ۵۰ و ۹۵.

برای موجودیت بحرانی دروازه سخت‌تری از متن مکالمه بگذارید. خلاصه پشتیبانی شاید خطای سطحی کوچکی را تحمل کند؛ مبلغ انتقال نه. تصمیم انتشار باید با بدترین برش مرتبط و پیامد آن گره بخورد، نه میانگین.

اصلاح مکالمه را به فارسی طراحی کنید

اطمینان پایین اجتناب‌ناپذیر است، اصلاح بد نه. درخواست تکرار کل جمله کار اضافی به کاربر می‌دهد و اغلب همان خطا را بازتولید می‌کند. فقط بخش نامطمئن را بپرسید:

«مبلغ را سه میلیون تومان گفتید؟»

«نام خانوادگی “نادری” است یا “نظری”؟»

نوع تأیید باید با پیامد متناسب باشد. انتقال پول، دارو، رضایت حقوقی، تغییر نشانی و مشخصه هویتی حتی با اطمینان صوتی بالا تأیید صریح می‌خواهند. برای جست‌وجوی کم‌خطر، تأیید ضمنی کافی است.

واژگان اصلاح به بازبینی بومی نیاز دارد. ادب فارسی یک کلید «رسمی» نیست. عبارت اداری می‌تواند دور و عبارت بسیار محاوره‌ای در درمان یا مالی نامناسب باشد. ضمیر، عنوان، طول نوبت، نشانه قطع و عذرخواهی را با کاربران همان بافت بسنجید. معماری عامل صوتی در تولید باید اطمینان ASR، اطمینان موجودیت، حالت سیاست و سابقه اصلاح را به مدیر مکالمه نشان دهد، نه اینکه همه را پشت یک پاسخ تولیدی پنهان کند.

تبدیل متن به گفتار را جداگانه بسنجید

کیفیت TTS از نتیجه ASR معلوم نمی‌شود. فهم‌پذیری، تلفظ، تکیه، ریتم، سرعت، تناسب عاطفی و ثبات میان قطعه‌ها را مرور کنید. واژه قرضی انگلیسی، نام خاص، مخفف، عدد و واژه مرکب به واژه‌نامه تلفظ یا سازوکار override نیاز دارند.

از شنونده بومی و آزمون مبتنی بر کار استفاده کنید. امتیاز میانگین نظر برای مقایسه صدای کلی مفید است، اما پرسش درک و شمار خطای تلفظ را اضافه کنید. بررسی کنید مبلغ، تاریخ، نام دارو یا رمز یک‌بارمصرف در بار نخست درست فهمیده می‌شود. زمان قطع‌کردن و بازیابی پس از barge-in را بسنجید؛ صدای زیبا اگر به کاربر گوش ندهد رابط خوبی نیست.

بدون حق و رضایت مستند، صدای شخص را شبیه‌سازی نکنید. هرجا اشتباه‌گرفتن صدا با انسان مهم است، مصنوعی‌بودن آن را آشکار کنید. واژه‌نامه تلفظ و ضبط سفارشی را داده تولید بدانید، نه فایل موقت لپ‌تاپ توسعه‌دهنده.

عرضه را مرحله‌ای و قابل بازگشت کنید

چهار دروازه عملی پیشنهاد می‌شود:

آفلاین: صوت منجمد و نتیجه برچسب‌خورده را بسنجید، دسته خطای بحرانی را دستی مرور و با خط مبنای تولید مقایسه کنید.

سایه: سامانه جدید را روی ترافیک زنده رضایت‌مندانه اجرا کنید، بدون اینکه مکالمه را کنترل کند. عملکرد برش‌ها، تأخیر و اختلاف با مسیر فعلی را ثبت کنید.

اقدام محدود: کار کم‌پیامد را برای گروه کوچک فعال کنید، تأیید و خروج فوری به انسان را الزامی نگه دارید.

گسترش: تنها زمانی پوشش را زیاد کنید که دقت موجودیت، بار اصلاح، نرخ اقدام اشتباه و نتیجه کاربر در محدوده بماند. trigger بازگشت را به معیار زنده وصل کنید.

نسخه مدل، بسته زبان، قاعده نرمال‌سازی، پرامپت، واژه‌نامه تلفظ و پیکربندی تشخیص پایان گفتار در manifest انتشار قرار می‌گیرد. به‌روزرسانی خاموش فروشنده می‌تواند بدون تغییر کد برنامه رفتار را عوض کند. چک‌لیست آمادگی عملیاتی هوش مصنوعی برای مالکیت، بازگشت و پاسخ رخداد مکمل مناسبی است.

ریسک حریم خصوصی، امنیت و بازنمایی

صدا بیش از واژه‌ها اطلاعات دارد. ضبط ممکن است صدای افراد دیگر، رسانه پس‌زمینه، داده سلامت یا شناسه را دربر بگیرد؛ در بعضی کاربردها و حوزه‌های قضایی voiceprint داده زیست‌سنجی است. جمع‌آوری را کمینه کنید، احراز هویت را از رونویسی عمومی جدا سازید، داده مانده را رمزگذاری و دسترسی را نقش‌محور کنید و حذف را در صوت خام، برش، برچسب، نسخه پشتیبان و سامانه فروشنده بیازمایید.

تزریق دستور می‌تواند صوتی باشد: تلویزیون، فایل پخش‌شده یا گوینده دوم شاید فرمان بدهد. متن تشخیص‌داده‌شده را ورودی نامطمئن بدانید. اقدام را به نشست احرازشده ببندید، مجوز ابزار را مستقل از خروجی مدل اعمال و برای عملیات مهم تأیید بگیرید.

شکاف لهجه را هم به‌عنوان مشکل کاربر معرفی نکنید. محدودیت شناخته‌شده را منتشر، کانال متن و انسان ارائه و جمع‌آوری داده را بدون بهره‌کشی به سوی شرایط کم‌پوشش هدایت کنید. پوشش بهتر تعهد مستمر خدمت است.

پرسش‌های رایج

آیا مدل پایه چندزبانه برای فارسی کافی است؟

می‌تواند خط مبنای خوبی باشد، اما شاهد آمادگی محصول نیست. آن را روی لهجه، کانال، موجودیت، جابه‌جایی زبان و اقدام مورد نظر بسنجید و فقط بر اساس شواهد، تطبیق حوزه و اصلاح اضافه کنید.

آیا همه متن‌ها را به فارسی معیار تبدیل کنیم؟

خیر. استانداردسازی برای جست‌وجو و منطق پایین‌دست مفید است، اما ممکن است معنا یا قصد گوینده را پاک کند. متن لفظی را نگه دارید و مقدار نرمال‌شده را جدا و با قاعده قابل ردیابی بسازید.

مهم‌ترین معیار چیست؟

در رابط تراکنشی، دقت موجودیت بحرانی و نرخ اقدام نادرست معمولاً از WER کلی مهم‌تر است. در دیکته، WER و زمان ویرایش شاید اصلی باشد. معیار را از کار و پیامد انتخاب کنید.

پیکره آزمون چه زمانی تازه شود؟

با تغییر محصول، واژگان، کانال یا جمعیت کاربر، نمونه مرورشده اضافه کنید. یک مجموعه regression ثابت برای مقایسه زمانی و یک مجموعه چالش تازه برای خطاهای نو نگه دارید.

منابع — بازبینی‌شده در ۲۰۲۶-۰۷-۳۰

• بنیاد موزیلا، Common Voice فارسی: زمینه داده گفتار خوانده‌شده و خودانگیخته جامعه‌محور.
• Conneau و همکاران، FLEURS: طراحی و دامنه ارزیابی چندزبانه.
• Sedghiyeh و همکاران، PSRB: تفاوت خطای ASR فارسی میان گویندگان و شرایط.
• Salehi و همکاران، ManaTTS فارسی: ساخت پیکره TTS و داده ارزیابی گفتار غیررسمی.
• کنسرسیوم یونیکد، صورت‌های نرمال‌سازی یونیکد: تعریف نرمال‌سازی نویسه؛ قواعد محصول فارسی همچنان باید جدا طراحی شوند.

پیکره عمومی نماینده کامل ترافیک تولید نیست و نتیجه مقاله‌ها با preprocessing، split و قاعده نرمال‌سازی متفاوت، مستقیم قابل مقایسه نیست. پیش از استفاده، مجوز و datasheet فعلی هر مجموعه را دوباره بررسی کنید.