فهرست مقاله
منظور از تلفن هوشمند سازمانی در این مقاله، پاسخ‌گوی تماس با استفاده از هوش مصنوعی و دانش سازمان است. تماس‌گیرنده پرسش خود را بیان می‌کند و سامانه باید آن را بفهمد، اطلاعات معتبر پیدا کند و پاسخ مناسب بدهد. برای بعضی درخواست‌ها، یک اقدام مجاز یا انتقال به کارشناس لازم است. چنین سامانه‌ای با اتصال یک مدل به خط تلفن کامل نمی‌شود؛ کیفیت تماس، مرجع اطلاعات و حدود اختیار باید هم‌زمان طراحی شوند.
مثال این راهنما یک سازمان فرضی با پرسش‌های ساعات کاری، شرایط خدمت و پیگیری درخواست است. معماری ارائه‌شده پیشنهاد مهندسی است و به معنای پیاده‌سازی همهٔ قابلیت‌ها در یک محصول یا اثبات عملکرد آن نیست. پیش از انتخاب فناوری، مشخص کنید سامانه کدام نیاز را پاسخ می‌دهد، چه اطلاعاتی را نباید ارائه کند و در چه موقعیتی باید از ادامهٔ پاسخ خودکار خارج شود. همین تصمیم‌ها معیار طراحی و آزمون خواهند بود.
۱. مسیر صوت را با نیاز مکالمه انتخاب کنید
راهنمای عامل‌های صوتی OpenAI دو رویکرد را توضیح می‌دهد: پردازش مستقیم صوت در گفت‌وگوی بلادرنگ و زنجیرهٔ تبدیل گفتار به متن، پردازش و تبدیل پاسخ به گفتار. در رویکرد زنجیره‌ای، متن میانی را می‌توان بررسی یا تغییر داد و اجزا را مستقل عوض کرد. این تفاوت برای طراحی مهم است، اما به‌تنهایی برتری یک رویکرد را برای همهٔ تماس‌ها ثابت نمی‌کند. انتخاب به کنترل مورد نیاز و ویژگی تجربهٔ مکالمه بستگی دارد.
در نمونهٔ پیشنهادی، از یک وظیفهٔ محدود شروع کنید و رفت‌وبرگشت کامل آن را بسنجید. فقط سرعت مدل را اندازه نگیرید؛ دریافت صوت، تشخیص پایان نوبت، بازیابی دانش و پخش پاسخ نیز زمان می‌گیرند. قطع کردن پاسخ توسط تماس‌گیرنده، مکث و تکرار سؤال را هم امتحان کنید. اگر سامانه به شنیدن پرسش تازه ادامه نمی‌دهد، پاسخ درست قبلی تجربهٔ خوبی نمی‌سازد. شرایط شبکه و تجهیزات آزمون را ثبت کنید تا نتیجه قابل مقایسه بماند.
۲. دانش سازمان را به شواهد قابل بررسی تبدیل کنید
در راهنمای دانش سازمانی و RAG مسیر بازیابی شواهد پیش از ساخت پاسخ توضیح داده شده است. مرجع محتوا باید صاحب مشخص و وضعیت اعتبار داشته باشد. یک فایل قدیمی، حتی اگر در جست‌وجو مرتبط به نظر برسد، لزوماً مرجع پاسخ امروز نیست. برای هر موضوع، مشخص کنید چه سندی معتبر است و در صورت تناقض میان منابع چه کسی تصمیم می‌گیرد. مدل نباید با حدس، سیاست سازمان را انتخاب کند.
مستندات بازیابی OpenAI استفاده از ذخیرهٔ برداری و جست‌وجوی معنایی را شرح می‌دهد. این قابلیت جای قواعد اعتبار و دسترسی را نمی‌گیرد. در طراحی پیشنهادی، شواهد انتخاب‌شده همراه شناسهٔ سند و نسخه به مسیر پاسخ می‌رسند. پاسخ صوتی می‌تواند کوتاه باشد، اما ثبت داخلی باید اجازه دهد تیم بفهمد اطلاعات از کدام مرجع آمده‌اند. وقتی شواهد کافی نیست، توضیح ابهام یا انتقال به کارشناس را به‌عنوان خروجی مجاز تعریف کنید.
۳. پاسخ دادن را از انجام اقدام جدا کنید
پرسیدن ساعت کاری و تغییر وضعیت یک درخواست، اختیار یکسانی نمی‌خواهند. برای اطلاعات عمومی، پاسخ از مرجع معتبر ممکن است کافی باشد؛ برای اقدام، هویت، مجوز و دادهٔ ورودی باید با قواعد برنامه بررسی شوند. متن مدل نباید به‌تنهایی اجازهٔ تغییر ایجاد کند. در مثال فرضی پیگیری، خواندن وضعیت درخواست هم ممکن است وابسته به احراز هویت باشد. عمومی بودن شمارهٔ تلفن سازمان، اطلاعات همهٔ پرونده‌ها را عمومی نمی‌کند.
برای هر ابزار، دامنهٔ ورودی، نتیجه و حالت خطا را بنویسید. راهنمای قرارداد ورودی ابزارها به این موضوع می‌پردازد. قبل از اقدام حساس، نتیجهٔ فهم درخواست را به شکل روشن به تماس‌گیرنده برگردانید و قواعد تأیید مناسب کاربرد را اجرا کنید. درخواست تکراری را هم در آزمون قرار دهید تا تکرار گفتار به اجرای چندبارهٔ یک عملیات تبدیل نشود. این بخش پیشنهاد معماری است؛ وجود مدل یا پروتکل اتصال ابزار، اجرای درست این کنترل‌ها را تضمین نمی‌کند.
۴. انتقال به کارشناس و حریم داده را طراحی کنید
انتقال باید برای درخواست خارج از دامنه، ابهام حل‌نشده و انتخاب خود تماس‌گیرنده در دسترس باشد. مشخص کنید کدام زمینه برای ادامهٔ کار لازم است: موضوع، مرحلهٔ انجام‌شده و دلیل انتقال. انتقال همهٔ متن مکالمه به هر مقصد، تصمیم پیش‌فرض مناسبی نیست. مقصد باید در دسترس باشد و رفتار زمان انتظار یا عدم پاسخ روشن بماند. مسیر انسانی، بخشی از تجربهٔ اصلی سامانه است و باید همان‌قدر جدی آزموده شود.
راهنمای OWASP دربارهٔ افشای اطلاعات حساس خطر خروج دادهٔ حساس از سامانه‌های مبتنی بر مدل را مطرح می‌کند. در طراحی پیشنهادی، مجوز دسترسی در برنامه و پیش از ورود شواهد به پاسخ بررسی می‌شود. مدت نگهداری صوت و متن، افراد دارای دسترسی و نیاز واقعی عیب‌یابی را نیز مشخص کنید. اطلاعات آزمایشی ساختگی، جای استفادهٔ بی‌ضابطه از مکالمهٔ واقعی را در مراحل اولیه می‌گیرد؛ دادهٔ واقعی فقط با قواعد روشن وارد فرایند شود.
۵. موفقیت را در سطح وظیفهٔ تماس بسنجید
ارزیابی را به لایه‌ها تقسیم کنید: فهم گفتار، بازیابی مرجع، صحت پاسخ، اجرای اقدام و انتقال. در ارزیابی گفتار فارسی نمونه‌های محاوره‌ای و خطاهای مؤثر بر وظیفه بررسی شده‌اند. در اینجا نیز نام خدمات، اعداد، مکث و اصلاح جمله مهم‌اند. یک پاسخ روان ممکن است به سؤال دیگری تعلق داشته باشد؛ نتیجهٔ مورد انتظار هر سناریو باید از قبل نوشته شود تا قضاوت فقط به پسندیدن متن وابسته نباشد.
برای شروع، یک مجموعهٔ محدود از تماس‌های ساختگی با نیاز مشخص، شاهد معتبر و خروجی مورد انتظار آماده کنید. موارد بدون شاهد، دسترسی نامجاز، درخواست تکراری و کارشناس در دسترس نیست را هم بگنجانید. پس از اصلاح هر لایه، آزمون کل مسیر را دوباره اجرا کنید. صفحهٔ تلفن هوشمند نقطهٔ معرفی حوزهٔ محصول است؛ این راهنما چارچوب بررسی آن را ارائه می‌کند. توسعهٔ دامنه زمانی منطقی‌تر است که حدود پاسخ، قواعد اقدام و معیار پذیرش وظیفهٔ قبلی روشن شده باشند.
منابع و مطالعهٔ بیشتر
- معماری عامل‌های صوتی؛ OpenAI
- بازیابی دانش و ذخیرهٔ برداری؛ OpenAI
- Sensitive Information Disclosure؛ OWASP
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
