تست رابط کاربری صوتی (VUI)؛ از ASR تا Voice AI

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

این راهنما یک روش عملی برای تست VUI، دستیار صوتی، ربات تلفنی و Voice AI ارائه می‌کند. از تعیین مرز ASR و NLU تا ساخت دیتاست فارسی، آزمون مکالمه چندمرحله‌ای، سنجه‌های درست، امنیت و حریم خصوصی، ابزارهای Alexa و Dialogflow و استقرار در CI را پوشش می‌دهیم.

نکته به‌روز: Google Conversational Actions از ۱۳ ژوئن ۲۰۲۳ متوقف شده است. بنابراین «Google Actions» دیگر هدف جاری برای ساخت و تست یک تجربه مکالمه سفارشی Google Assistant نیست. در مقابل، Alexa Skills همچنان فعال است، اما فهرست رسمی localeهای آن فارسی را شامل نمی‌شود. برای محصول فارسی، ممکن است به پشته سفارشی ASR/NLU/TTS، ربات تلفنی یا تجربه صوتی داخل وب و اپ نیاز داشته باشید.

تست رابط کاربری صوتی دقیقاً چه چیزی را می‌سنجد؟

یک VUI موفق باید در پایان به کاربر کمک کند وظیفه درست را با هزینه ذهنی و ریسک قابل‌قبول انجام دهد. دقت تبدیل گفتار به متن مهم است، اما نتیجه نهایی فقط به آن وابسته نیست. ممکن است transcript دقیق باشد و intent اشتباه انتخاب شود؛ intent درست باشد و API مبلغ نادرست دریافت کند؛ عملیات درست انجام شود و پاسخ TTS باعث سوءبرداشت شود.

برای جلوگیری از این ابهام، سیستم را به هفت لایه قابل‌آزمون تقسیم کنید:

1. دریافت صوت: میکروفون، wake word، فاصله، echo cancellation، codec و قطع‌شدن صدا.
2. ASR یا Speech-to-Text: تبدیل waveform به transcript و confidence.
3. NLU یا مدل عامل: intent، entity/slot، معنای جمله یا انتخاب ابزار.
4. مدیر مکالمه: context، وضعیت، repair، confirmation، cancel و session.
5. منطق و وابستگی: قوانین دامنه، API، پایگاه داده و سرویس بیرونی.
6. پاسخ و TTS: صحت محتوا، تلفظ، مکث، لحن، SSML و قابلیت فهم.
7. کانال و دستگاه: speaker، تلفن، خودرو، اپ، شبکه و محیط واقعی.

این مدل لایه‌ای، oracle را مشخص می‌کند. اگر تست متنی شبیه‌ساز پاس و تست دستگاه واقعی fail شود، احتمالاً باید capture، ASR، TTS یا channel را بررسی کنید؛ نه اینکه بی‌دلیل مدل NLU را دوباره آموزش دهید.

Speech recognition با speaker recognition فرق دارد

Speech recognition می‌پرسد «چه گفته شد؟»؛ speaker recognition یا voice biometrics می‌پرسد «چه کسی گفت؟». یک transcript دقیق، هویت گوینده را اثبات نمی‌کند. اگر محصول با صدا عملیات حساس انجام می‌دهد، آزمون احراز هویت، مجوز و مقاومت در برابر replay یا صدای ضبط‌شده باید جدا از دقت ASR طراحی شود.

پیش از تست، قرارداد تجربه صوتی را بنویسید

تیم‌ها اغلب مستقیم سراغ utteranceها می‌روند، در حالی که هنوز معلوم نیست چه تجربه‌ای باید ارائه شود. یک Voice Contract کوتاه بسازید:

فیلد	پرسش	نمونه
کاربر و کانال	چه کسی، روی چه دستگاهی و در چه محیطی؟	مشتری موبایل در محیط شهری
زبان و locale	کدام زبان، گویش، خط و منطقه؟	fa-IR، گفتار محاوره، Asia/Tehran
وظیفه	پیامد قابل‌مشاهده چیست؟	استعلام وضعیت مرسوله
ریسک	کدام سوءبرداشت قابل‌تحمل نیست؟	اعلام یا تغییر سفارش کاربر دیگر
مرز پلتفرم	کدام لایه را تیم کنترل می‌کند؟	ASR فروشنده؛ NLU و API داخلی
تأیید	چه عملی به confirmation نیاز دارد؟	لغو سفارش با بیان نتیجه
بازیابی	در no-input/no-match/timeout چه می‌شود؟	یک repair، سپس انتقال به اپراتور
شواهد	قبولی با چه artifact و آستانه‌ای؟	task success و خطای بحرانی صفر

اگر پلتفرم شخص ثالث انتخاب کرده‌اید، پشتیبانی locale را از مستندات همان نسخه بررسی کنید. فهرست جاری localeهای Alexa Skills زبان‌هایی مانند انگلیسی، عربی، هندی و چند زبان اروپایی و آسیایی را نام می‌برد، اما فارسی در آن نیست. وجود صدای TTS فارسی در یک سرویس دیگر نیز لزوماً به معنای امکان انتشار Skill فارسی در Alexa نیست.

مرز کنترل تیم را صریح کنید

در Skill پلتفرمی، wake word، مدل پایه ASR و بخش‌هایی از TTS ممکن است خارج از اختیار تیم باشد؛ اما interaction model، endpoint، پاسخ، account linking و داده تحت کنترل شماست. در پشته سفارشی، مدل و زیرساخت بیشتری کنترل می‌شود و در مقابل بار ارزیابی، امنیت و عملیات هم بیشتر است. «مشکل از Alexa است» یا «مدل AI اشتباه کرد» تا وقتی لایه و شاهد مشخص نشده، تحلیل علت نیست.

Google Actions و Alexa Skills در سال ۲۰۲۶

Google Conversational Actions: هدفی تاریخی، نه پلتفرم جاری

صفحه رسمی پایان Conversational Actions توضیح می‌دهد که این تجربه‌های سفارشی Google Assistant از ۱۳ ژوئن ۲۰۲۳ دیگر برای کاربر و توسعه‌دهنده در دسترس نیستند. App Actions، Smart Home، Media Actions و مسیرهای دیگر Google موضوع‌های متفاوتی‌اند و نباید با Conversational Actions قدیمی یکی گرفته شوند.

اگر یک مجموعه تست قدیمی Google Action دارید، ارزش آن در دارایی‌های مستقل از پلتفرم است: نقشه intent، نمونه utterance، قوانین دامنه، سناریوهای repair، داده pronunciation و قرارداد API. آن‌ها را به پلتفرم جدید منتقل کنید؛ تست کنسول منقضی‌شده را به‌عنوان راهنمای امروز نگه ندارید.

Alexa Skills: شبیه‌ساز کافی نیست

راهنمای جاری تست و عیب‌یابی Alexa Skill ابزارهایی مانند simulator، ASK CLI، Utterance Profiler، برنامه Alexa، دستگاه واقعی و beta test را تفکیک می‌کند. هرکدام سؤال متفاوتی را جواب می‌دهند.

Utterance Profiler الکسا نشان می‌دهد یک عبارت چگونه به intent و slot نگاشت می‌شود، اما endpoint مهارت را فراخوانی نمی‌کند. پس قبولی در profiler، منطق backend، account linking، latency، کیفیت TTS یا رفتار روی دستگاه را اثبات نمی‌کند.

استراتژی تست VUI از متن تا اتاق واقعی

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

سطح	ورودی	چه چیزی جدا می‌شود؟	oracle اصلی
منطق دامنه	پارامتر ساختاریافته	ASR، NLU و کانال	نتیجه، invariant و side effect
NLU/Agent	متن	میکروفون و ASR	intent، slot، tool و policy
مکالمه	توالی turn متنی	آکوستیک	state، repair، confirmation و task
ASR corpus	فایل صوت + transcript مرجع	منطق کسب‌وکار	WER/CER و entity-critical error
E2E صوتی	صوت ضبط‌شده/پخش‌شده	کمتر	پیامد کاربر و trace هر لایه
دستگاه/محیط	گفتار انسان	هیچ‌کدام	task success، فهم‌پذیری و زمان
تولید	تعامل واقعی با رضایت/حداقل‌سازی	هیچ‌کدام	failure funnel و پیامد کاربر

برای endpoint و سرویس‌های بیرونی، مرز mock، component و محیط واقعی را با اصول تست یکپارچه‌سازی مشخص کنید. یک mock همیشه‌موفق نمی‌تواند timeout، پاسخ دیر، retry و اثر تکراری را نمایندگی کند.

تست ASR؛ دقت کل کافی نیست

برای هر فایل صوتی، transcript مرجع بازبینی‌شده و خروجی مدل را نگه دارید. رایج‌ترین سنجه، Word Error Rate است:

WER = (جایگزینی + حذف + درج) ÷ تعداد واژه‌های متن مرجع

مستند رسمی ارزیابی دقت Speech-to-Text مایکروسافت همین سه مؤلفه را برای WER شرح می‌دهد. با این حال، یک WER واحد می‌تواند خطای مهم را پنهان کند: اشتباه «پانزده» با «پنجاه» فقط یک واژه است، اما اثرش از حذف یک کلمه پرکننده بسیار بیشتر است.

سنجه را به ریسک و زیرگروه بشکنید

• WER و در فارسی، در صورت نیاز CER پیش و پس از normalization؛
• نرخ خطای موجودیت‌های بحرانی مانند مبلغ، تاریخ، نام و شناسه؛
• درصد جمله‌های کاملاً درست برای فرمان‌های کوتاه؛
• نرخ خطا به تفکیک دستگاه، فاصله، SNR، شبکه و نوع محیط؛
• نرخ خطا به تفکیک گروه‌های گفتاریِ ازپیش‌تعریف‌شده و دارای نمونه کافی؛
• اختلاف نسخه کاندید با baseline روی همان corpus منجمد.

آستانه جهانی مانند «WER زیر ۵٪» برای همه دامنه‌ها معتبر نیست. ابتدا baseline و پیامد خطا را تعیین کنید. ممکن است برای جست‌وجوی موسیقی WER بالاتر قابل‌قبول باشد، اما در عدد حساب، دارو یا آدرس، معیار بحرانی باید جدا و سخت‌گیرانه باشد.

Normalization نباید خطای معنایی را پنهان کند

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

ساخت دیتاست صوتی قابل‌اعتماد

دیتاست خوب فقط هزار فایل صوتی نیست؛ باید توزیع استفاده و ریسک را نمایندگی و lineage روشنی داشته باشد.

مانیفست هر نمونه

• شناسه ناشناس نمونه و نسخه dataset؛
• transcript خام و مرجع نرمال‌شده؛
• intent، slotها و برچسب critical entity؛
• locale، الگوی گفتار و در صورت رضایت، ویژگی گروه مطالعه؛
• دستگاه، میکروفون، فاصله، codec، sample rate و کانال؛
• نوع نویز، نسبت سیگنال به نویز و روش mix؛
• منشأ، رضایت، مجوز استفاده، مدت نگهداری و محدودیت دسترسی؛
• train/dev/test split و fingerprint برای جلوگیری از leakage.

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

ماتریس آکوستیک کوچک ولی هدفمند

به جای ترکیب کامل همه عوامل، بر مسیرهای بحرانی و pairwise/risk-based sampling تمرکز کنید:

• فاصله نزدیک و far-field؛
• اتاق ساکت، تلویزیون، ترافیک، خودرو و گفت‌وگوی پس‌زمینه؛
• صدای آرام، سریع، بریده، نجوا یا speech impairment در دامنه مطالعه؛
• میکروفون موبایل، هدست، اسپیکر و تلفن ۸ کیلوهرتز؛
• echo از پاسخ خود دستگاه و barge-in کاربر؛
• packet loss، jitter، قطع شبکه و reconnect.

فایل نویز، gain و seed ترکیب را نگه دارید تا شکست بازتولید شود. «تست در کافی‌شاپ» بدون اندازه‌گیری و مانیفست، آزمایش تکرارپذیر نیست.

تست NLU؛ intent و slot را جدا بسنجید

برای مدل intent-based، مجموعه آزمون باید نمونه مثبت، paraphrase، نمونه نزدیک به intent رقیب، عبارت خارج از دامنه و ورودی ناقص داشته باشد. فقط accuracy کل را گزارش نکنید:

• precision، recall و F1 هر intent؛
• confusion matrix برای intentهای نزدیک؛
• دقت exact و normalized هر slot؛
• نرخ false accept برای فرمان خارج از دامنه؛
• کالیبراسیون confidence و رفتار نزدیک آستانه؛
• عملکرد روی utterance دیده‌نشده، نه تکرار نمونه آموزش.

نمونه‌های سخت فارسی

• محاوره: «بفرست»، «واریزش کن»، «بزن به حسابش»؛
• عدد و واحد: «یه و نیم میلیون»، «۱۵۰ تومن»، ریال در برابر تومان؛
• نفی و اصلاح: «نه، به علی نه، به عالیه»؛
• زمان نسبی: «پس‌فردا عصر» با تقویم و منطقه زمانی مشخص؛
• نام و برند با code-switch: نام انگلیسی میان جمله فارسی؛
• هم‌آواها و نام‌های نزدیک؛
• گونه‌های نویسه‌ای در log و oracle: ی/ی، ک/ک و ارقام فارسی/لاتین.

اگر از phrase bias یا custom vocabulary استفاده می‌کنید، فقط بهبود واژه هدف را نسنجید. bias زیاد می‌تواند واژه مشابه را اشتباه به عبارت محبوب تبدیل کند. Phrase set و custom class احتمال تشخیص واژه‌های دامنه را تغییر می‌دهند و پشتیبانی آن‌ها به مدل و زبان وابسته است؛ بنابراین نسخه تنظیمات و اثر جانبی آن‌ها نیز بخشی از آزمون است.

تست Voice AI مولد؛ golden response کافی نیست

عامل‌های مبتنی بر مدل زبانی ممکن است برای یک ورودی پاسخ‌های متفاوت ولی قابل‌قبول تولید کنند. مقایسه exact string شکننده است؛ اما حذف oracle هم درست نیست. انتظار را در چند لایه تعریف کنید:

1. مسیر: آیا ابزار/flow درست انتخاب شد؟
2. آرگومان: آیا مبلغ، زمان، شناسه و واحد دقیق‌اند؟
3. سیاست: آیا پیش از عملیات حساس تأیید یا احراز هویت انجام شد؟
4. grounding: آیا ادعا فقط از منبع مجاز آمده و ارجاع قابل‌ردیابی است؟
5. پیامد: آیا task بدون side effect اضافی کامل شد؟
6. پاسخ: آیا محتوا صحیح، کوتاه، قابل‌فهم و بدون افشای داده است؟

ارزیابی داخلی Playbookهای Dialogflow CX نمونه‌ای از استفاده test case، environment، انتظار ابزار/flow و سنجه پاسخ است. حتی اگر پلتفرم دیگری دارید، اصل نسخه‌بندی agent، prompt، tool schema، model و dataset را حفظ کنید.

برای Voice AI مولد، علاوه بر کیفیت، misuse را آزمایش کنید: دستور تزریق‌شده در صدای کاربر یا محتوای بازیابی‌شده، فراخوانی ابزار خارج از allowlist، افشای system prompt یا داده کاربر دیگر، تکرار عملیات پس از timeout و پیروی از دستور ناسازگار با policy. پروفایل NIST AI ۶۰۰-۱ برای هوش مصنوعی مولد چارچوبی برای شناسایی و مدیریت ریسک در کل چرخه عمر می‌دهد؛ جای تست دامنه و threat model محصول را نمی‌گیرد.

تست جریان مکالمه و مدیریت state

یک گفت‌وگوی موفق فقط happy path نیست. state machine یا نمودار turnها را به تست تبدیل کنید:

• no-input، no-match و confidence پایین؛
• اصلاح slot: «نه، سه‌شنبه نه، پنج‌شنبه»؛
• ارجاع: «همان آدرس قبلی» و ضمیر مبهم؛
• پرسش خارج از مسیر و بازگشت به کار اصلی؛
• Help، Repeat، Back، Cancel و Start over در هر state؛
• session timeout، resume و state منقضی؛
• interrupt یا barge-in هنگام پخش پاسخ؛
• دو کاربر یا صدای تلویزیون در یک جلسه؛
• API timeout پیش و پس از commit و جلوگیری از side effect تکراری؛
• handoff به انسان یا کانال دیداری با حفظ حداقل context لازم.

تأیید صریح را با خود عملیات تست کنید

برای عملیات برگشت‌ناپذیر، سیستم باید خلاصه‌ای کوتاه و بدون ابهام ارائه کند: «انتقال ۱۵۰ هزار تومان به عالیه رضایی؛ تأیید می‌کنید؟» تست کنید پاسخ‌هایی مثل «آره، ولی فردا»، سکوت، «شاید»، صدای شخص دیگر یا پاسخ پس از انقضای session عملیات را ناخواسته اجرا نکنند. بعد از تأیید هم idempotency و وضعیت نامعلوم وابستگی را بسنجید.

تعداد turn کمتر همیشه بهتر نیست. یک confirmation اضافه ممکن است اصطکاک ایجاد کند، اما در ریسک مالی از اجرای سریع اشتباه ارزشمندتر است. برای ارزیابی طبیعی بودن، فهم‌پذیری و بار ذهنی، آزمون فنی را با تست کاربردپذیری با کاربران هدف ترکیب کنید.

تست TTS، SSML و پاسخ شنیداری

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

• تلفظ نام فارسی، برند، مخفف، URL، مبلغ و تاریخ؛
• مکث پیش و پس از عدد یا گزینه مهم؛
• سرعت و بلندی نسبی در محیط هدف؛
• خواندن درست ریال/تومان، ممیز، درصد و شماره پیگیری؛
• تفاوت سؤال، هشدار و تأیید در prosody؛
• رفتار markup نامعتبر یا tag پشتیبانی‌نشده؛
• fallback متنی/دیداری و امکان تکرار یا کندترخواندن؛
• عدم خواندن کامل OTP، شماره کارت یا داده حساس در فضای مشترک.

استاندارد SSML ۱.۱ از W3C کنترل‌هایی برای تلفظ، مکث، pitch، rate و دیگر جنبه‌های سنتز تعریف می‌کند؛ اما هر موتور زیرمجموعه و رفتار خاص خود را دارد. تست schema به تنهایی ثابت نمی‌کند خروجی طبیعی یا حتی قابل‌فهم است.

دسترس‌پذیری: Voice-only یک ضدالگو است

صدا برای بعضی کاربران فناوری کمکی است و برای بعضی دیگر مانع. کاربر ناشنوا یا کم‌شنوا، فرد دارای اختلال گفتار، محیط شلوغ یا موقعیت نیازمند سکوت باید مسیر جایگزین داشته باشد. صفحه W3C درباره Speech Recognition و دسترس‌پذیری تفاوت speech recognition با شناسایی گوینده و نقش این فناوری در دسترسی را توضیح می‌دهد.

در تست، این موارد را پوشش دهید:

• هم‌ارزی کارکردی متن، لمس یا اپراتور برای وظیفه اصلی؛
• caption/transcript برای پاسخ صوتی در کانال دارای نمایشگر؛
• زمان کافی، repeat، تنظیم سرعت و لغو آسان؛
• پیام خطای قابل‌اقدام به جای تکرار بی‌پایان «متوجه نشدم»؛
• آزمون با کاربران دارای معلولیت مرتبط، بدون ادعای شبیه‌سازی تجربه آن‌ها؛
• حفظ تمرکز و کنترل‌های قابل‌نام‌بردن در تجربه چندوجهی.

برای ارزیابی کامل محصول چندوجهی، از راهنمای تست دسترس‌پذیری و WCAG ۲.۲ استفاده کنید؛ قبولی مدل صوتی معادل انطباق رابط وب یا اپ نیست.

امنیت و حریم خصوصی VUI

صدا و transcript می‌توانند داده شخصی، اطلاعات سلامت، نشانی، نام مخاطب یا فرمان مالی داشته باشند. threat model باید capture تا حذف را پوشش دهد:

• فعال شدن ناخواسته و ضبط بیش از نیاز؛
• replay، صدای پخش‌شده و جعل گوینده؛
• استفاده از voice biometrics به‌عنوان تنها عامل برای عمل پرریسک؛
• confused deputy: کاربر مجاز به شنیدن است اما مجاز به تغییر نیست؛
• session کاربر قبلی روی دستگاه مشترک؛
• افشای transcript، raw audio یا token در log و ابزار analytics؛
• تزریق فرمان به agent مولد و فراخوانی ابزار غیرمجاز؛
• retry و اجرای تکراری پس از قطع شبکه؛
• نگهداری نامحدود ضبط‌ها یا استفاده ثانویه بدون مجوز.

برای Alexa Skills، الزامات امنیت و حریم خصوصی Amazon مواردی مانند اعتبارسنجی درخواست، HTTPS، account linking، privacy notice و محدودیت دریافت/خواندن برخی اطلاعات حساس با صدا را بیان می‌کند. این‌ها حداقل پلتفرم‌اند؛ تحلیل حقوقی و ریسک محصول خودتان همچنان لازم است.

شواهد را بدون ساختن مخزن نظارتی جمع کنید

برای trace هر turn یک correlation ID غیرقابل‌حدس، نسخه مدل/agent، intent/tool، latency لایه‌ها و outcome نگه دارید. raw audio را فقط اگر هدف، مجوز، دسترسی و مدت نگهداری روشن دارد ذخیره کنید. در داشبورد و defect، متن حساس را redact و دسترسی به replay را ثبت کنید.

عملکرد و قابلیت اطمینان در مکالمه

میانگین latency کافی نیست. زمان را مرحله‌بندی کنید:

• پایان گفتار تا تشخیص end-of-utterance؛
• ASR، NLU/agent، API/tool و تولید پاسخ؛
• شروع TTS و زمان تا شنیدن اطلاعات مفید؛
• p50، p95 و p99 هر مرحله بر اساس journey؛
• نرخ timeout، قطع، retry، handoff و abandonment؛
• رفتار در burst، تماس هم‌زمان، محدودیت quota و خرابی منطقه‌ای.

یک response یک‌ثانیه‌ای که اطلاعات اشتباه دارد سریع اما بی‌کیفیت است. latency را کنار task success و correctness ببینید. طراحی workload، percentile و معیار پذیرش در برنامه تست عملکرد به تفصیل آمده است.

بازیابی باید بخشی از گفت‌وگو باشد

اگر API دیر پاسخ داد، سیستم نباید سکوت طولانی، اجرای پنهان یا retry نامحدود داشته باشد. تست کنید آیا پیام پیشرفت، امکان لغو، شناسه پیگیری و نتیجه قطعی ارائه می‌شود. در وضعیت commit نامعلوم، کاربر نباید با تکرار فرمان تراکنش دوم بسازد.

Oracle و قالب تست مکالمه

یک test case خوب فقط «ورودی و پاسخ مورد انتظار» نیست. این قالب را نسخه‌بندی کنید:

id: fa-pay-017
risk: انتقال به گیرنده اشتباه پس از اصلاح نام
channel: mobile-voice
locale: fa-IR
precondition: user_authenticated, two_similar_contacts
turns:
  - user: "صد و پنجاه هزار تومن برای علی بفرست"
    expect: intent=transfer, amount_irr=1500000, recipient=ambiguous
  - agent: explicit_clarification_without_disclosure
  - user: "علی نه، عالیه رضایی"
    expect: recipient_id=contact_284, state=awaiting_confirmation
  - agent: "انتقال ۱۵۰ هزار تومان به عالیه رضایی؛ تأیید می‌کنید؟"
  - user: "بله"
    expect: tool=transfer_once, idempotency_key=present
invariants:
  - no_transfer_before_explicit_confirmation
  - no_full_account_number_spoken
  - exactly_one_ledger_entry
evidence: transcript, layer_trace, tool_request_redacted, audio_review

برای پاسخ‌های مولد، متن دقیق را فقط در جاهایی قفل کنید که الزام قانونی یا ایمنی دارد. در بقیه موارد، invariant، نکات الزامی، نکات ممنوع، ابزار و outcome را assert کنید.

اتوماسیون و CI برای تست دستیار صوتی

«تا حد امکان خودکار کنید» راهبرد نیست. هر lane باید هدف، بودجه زمان و artifact داشته باشد:

Lane	اجرا	دامنه	Gate
Commit	هر تغییر	منطق دامنه، schema، policy و unit	invariant بحرانی
Pull Request	هر PR	NLU متن، dialogue state، mock API	regression intent/slot/tool
Nightly	شبانه	corpus صوت، نویز، integration واقعی محدود	delta نسبت به baseline
Pre-release	کاندید انتشار	دستگاه، انسان، TTS، امنیت و دسترس‌پذیری	ریسک/waiver نام‌دار
Production	پیوسته	failure funnel، latency، repair، outcome	alert و rollback/disable policy

جزئیات انتخاب تست پایدار و هزینه نگهداری در راهنمای اتوماسیون تست آمده است. تست صوتی flaky را صرفاً retry نکنید؛ فایل، seed نویز، نسخه مدل، trace و خروجی خام را نگه دارید و علت nondeterminism را طبقه‌بندی کنید.

نسخه‌هایی که باید در artifact ثبت شوند

• interaction model یا prompt و tool schema؛
• مدل ASR/NLU/LLM/TTS و تنظیمات decoding؛
• dataset، normalization و rubric؛
• کد endpoint و قرارداد API؛
• locale، device/OS/app/firmware؛
• شبکه، محیط، فایل صوتی و noise transform؛
• زمان اجرا و feature flagها.

داشبوردی که محل خرابی را نشان دهد

یک «نرخ موفقیت VUI» برای تصمیم کافی نیست. قیف بسازید:

Invocation → Capture → ASR → Intent/Tool → Slot/Argument → Confirmation → API Outcome → Response Heard → Task Success

برای هر مرحله نرخ شکست، latency و مسیر repair را ثبت کنید. سپس سنجه‌ها را بر journey، locale، نسخه و کانال بشکنید. نمونه سبد متوازن:

• task success و critical task success؛
• critical entity error و false action rate؛
• intent F1 و slot accuracy؛
• میانگین و توزیع turn تا تکمیل؛
• no-match، reprompt، cancel، handoff و abandonment؛
• p95 latency پایان گفتار تا پاسخ مفید؛
• تکرار رخداد حریم خصوصی/امنیتی؛
• شکاف نتیجه میان cohortهای گفتاری معتبر.

هدف‌گذاری یک عدد می‌تواند رفتار را منحرف کند: کم کردن turn با حذف confirmation خطرناک است و پایین آوردن no-match با پذیرفتن intent اشتباه بدتر. هر معیار باید guardrail مخالف داشته باشد. برای ساخت تعریف، مخرج، منبع و مالک هر شاخص از راهنمای متریک‌های تست نرم‌افزار کمک بگیرید.

مثال جامع: ربات صوتی فارسی پیگیری مرسوله

یک فروشگاه ایرانی ربات تلفنی دارد که وضعیت سفارش را با شماره موبایل و کد سفارش اعلام و در صورت تأخیر درخواست پیگیری ثبت می‌کند.

ریسک‌ها و کنترل‌ها

• شناسه اشتباه: ارقام فارسی/لاتین، مکث و تکرار؛ checksum و read-back بخش‌بندی‌شده.
• افشای سفارش: تطبیق هویت قبل از بیان جزئیات و mask کردن داده.
• تاریخ مبهم: منطقه Asia/Tehran و نمایش/خواندن تقویم توافق‌شده.
• وضعیت کهنه: timestamp و منبع پاسخ؛ fallback در خرابی شرکت حمل.
• ثبت تکراری پیگیری: idempotency و اعلام شناسه پرونده موجود.
• عدم فهم نام شهر: clarification محدود و انتقال به اپراتور.

مجموعه آزمون

1. منطق tracking با شناسه ساختاریافته و APIهای success/not-found/timeout؛
2. ۱۰۰ utterance متنی برای intentهای وضعیت، پیگیری، لغو و اپراتور؛
3. corpus صوتی رضایت‌دار با سرعت، لهجه و کانال تلفن هدف؛
4. آزمون ارقام: «صفر نهصد و دوازده»، مکث، اصلاح و digit grouping؛
5. جریان چند turn شامل اشتباه، repair، session timeout و resume امن؛
6. بار هم‌زمانی کمپین، خرابی API حمل و circuit breaker؛
7. شنیدن پاسخ روی تلفن ارزان، speaker و محیط شلوغ؛
8. replay، session کاربر قبلی، log redaction و retention؛
9. آزمون با کاربران هدف و مسیر کلیدی بدون صدا.

قبولی وقتی است که task بحرانی برای گروه‌ها و کانال‌های تعریف‌شده در محدوده باشد، افشای داده و اقدام اشتباه صفر بماند، latency از بودجه تجاوز نکند و هر شکست در trace به یک لایه منتسب شود.

برنامه ۳۰روزه پیاده‌سازی

هفته اول: مرز و baseline

• سه journey مهم و سه failure تحمل‌ناپذیر را انتخاب کنید.
• Voice Contract و نقشه هفت‌لایه را بنویسید.
• پشتیبانی locale، داده، هزینه و دسترسی پلتفرم را تأیید کنید.

هفته دوم: مجموعه طلایی

• utteranceهای متنی مثبت، رقیب، خارج‌دامنه و repair بسازید.
• ۵۰ تا ۱۰۰ نمونه صوتی مرجع برای journey بحرانی جمع کنید.
• Normalization، rubric و مانیفست نسخه‌دار را تثبیت کنید.

هفته سوم: اتوماسیون و trace

• تست منطق، NLU/agent، dialogue و contract را در CI وارد کنید.
• correlation ID و latency هر لایه را اضافه کنید.
• audio regression شبانه و artifact شکست را راه‌اندازی کنید.

هفته چهارم: واقعیت و تصمیم انتشار

• دستگاه، نویز، کاربرپذیری، دسترس‌پذیری و امنیت را اجرا کنید.
• شکاف cohortها و critical entity error را مرور کنید.
• ریسک باقی‌مانده، waiver و trigger غیرفعال‌سازی را نام‌دار ثبت کنید.

ضدالگوهای رایج تست VUI

• اعتماد به simulator: شبیه‌ساز متنی میکروفون، ASR، TTS و محیط را دور می‌زند.
• یک WER برای همه: خطای مبلغ و واژه پرکننده وزن یکسان ندارند.
• ساخت corpus از TTS تنها: گفتار مصنوعی نماینده تنوع انسان نیست.
• نرمال‌سازی بی‌ردپا: تبدیل واحد و عدد ممکن است نقص واقعی را پنهان کند.
• golden string برای Agent مولد: روی policy، tool، argument و outcome تمرکز کنید.
• ذخیره همه صوت‌ها برای «بعداً»: هدف، رضایت، retention و دسترسی باید پیشاپیش روشن باشد.
• Voice-only: کانال جایگزین و نیاز کاربران دارای معلولیت را فراموش نکنید.
• گزارش خطای «AI»: layer trace و artifact لازم است تا مالک اصلاح معلوم شود.
• انتخاب پلتفرم پیش از locale: پشتیبانی فارسی را از محصول دیگری استنتاج نکنید.
• بهینه‌سازی تعداد turn: سرعت نباید confirmation یا ایمنی را حذف کند.

جمع‌بندی

تست رابط کاربری صوتی زمانی تصمیم‌ساز است که وظیفه واقعی کاربر را از capture تا outcome دنبال کند. ASR، NLU یا Agent، state مکالمه، API، TTS و دستگاه هرکدام oracle و مالک متفاوت دارند. دیتاست نسخه‌دار، معیارهای ریسک‌محور، شواهد لایه‌ای، تست دستگاه و بازخورد تولید این اجزا را به هم متصل می‌کنند.

برای بازار ایران، انتخاب پلتفرم و locale بخشی از QA است: Alexa Skill فارسی در فهرست جاری پشتیبانی نمی‌شود و Google Conversational Actions نیز سال‌هاست متوقف شده است. راه درست ممکن است یک پشته سفارشی، ربات تلفنی یا تجربه صوتی داخل اپ باشد. نام فناوری مهم‌تر از این سؤال نیست: آیا کاربر فارسی‌زبان، در کانال و محیط واقعی، می‌تواند کار درست را بدون سوءبرداشت و افشای داده انجام دهد؟

سؤالات متداول

مهم‌ترین سنجه تست ASR چیست؟

WER نقطه شروع رایجی است، اما به تنهایی کافی نیست. نرخ خطای موجودیت‌های بحرانی، جمله کاملاً درست، CER برای تحلیل فارسی، شکاف گروه‌ها و task success را نیز بسنجید. آستانه باید از ریسک و baseline محصول بیاید.

آیا می‌توان تست VUI را کاملاً خودکار کرد؟

خیر. منطق، NLU، state، contract و بخش زیادی از corpus صوتی قابل‌اتوماسیون‌اند؛ اما فهم‌پذیری TTS، استفاده در محیط واقعی، دسترس‌پذیری و تجربه گروه‌های کاربر به ارزیابی انسانی و دستگاه واقعی نیاز دارند.

آیا Google Actions هنوز برای دستیار صوتی سفارشی قابل‌استفاده است؟

Google Conversational Actions از ۱۳ ژوئن ۲۰۲۳ خاموش شده است. مسیرهای دیگری مانند App Actions یا Smart Home موضوع و قابلیت متفاوت دارند. برای مکالمه سفارشی باید گزینه جاری مناسب کانال خود را ارزیابی کنید.

آیا Alexa Skills از فارسی پشتیبانی می‌کند؟

در فهرست رسمی جاری localeهای Alexa Skills، فارسی وجود ندارد. این موضوع را با وجود احتمالی صدای فارسی در سرویس TTS دیگری یکی ندانید. برای تجربه فارسی معمولاً باید کانال یا پشته دیگری را بررسی کنید.

برای Agent صوتی مولد چه چیزی را assert کنیم؟

به‌جای قفل کردن همه پاسخ‌ها به یک متن، انتخاب ابزار، آرگومان دقیق، قواعد مجوز و تأیید، منبع پاسخ، side effect، افشای داده و موفقیت task را assert کنید. برای عبارت‌های قانونی یا ایمنی می‌توان متن دقیق را هم ثابت نگه داشت.