دستیار هوشمند پاسخگویی به مشتری
اگر تیکتهای پشتیبانی یک ماه را دستهبندی کنید، معمولاً الگوی روشنی بیرون میآید: بخش قابل توجهی پرسشهای تکراریاند که جوابشان جایی مستند است. شرایط گارانتی، مراحل مرجوعی، سازگاری قطعات، وضعیت سفارش.
این همان لایهای است که یک دستیار هوشمند میتواند بردارد. نکته این است که برداشتنش با «نصب یک چتبات» اتفاق نمیافتد.
اول: بفهمید چه چیزی را میخواهید خودکار کنید
پیش از هر تصمیم فنی، تیکتهای سه ماه گذشته را دستهبندی کنید. معمولاً به چهار دسته میرسید:
پرسشهایی که جوابشان در سند هست. هدف اصلی. اینجاست که بازده واقعی است.
پرسشهایی که جوابشان در داده است. «سفارشم کجاست؟» جوابش در سامانه شماست، نه در سند. این دسته به اتصال نیاز دارد نه به سند.
پرسشهایی که جوابشان هیچجا نیست. موارد خاص و قضاوتی. اینها به کارشناس میروند و باید هم بروند.
شکایت. حتی وقتی جوابش معلوم است، مشتری عصبانی را نباید به ربات سپرد.
سهم هر دسته، تصمیم شما را میسازد. اگر دستهٔ اول کوچک است، پروژه هوش مصنوعی بازده کمی دارد و مسئله شما مستندسازی است، نه دستیار.
معماریای که کار میکند
دستیاری که از دانش عمومی مدل جواب بدهد، برای پشتیبانی خطرناک است: میتواند با اطمینان بگوید گارانتی هجده ماه است در حالی که دوازده ماه است — و شما یک تعهد ایجاد کردهاید.
پس پاسخ باید از اسناد خودتان بیاید. سازوکارش RAG است: ابتدا متن مرتبط از مستندات پیدا میشود، بعد مدل فقط از همان متن جواب میسازد و منبعش را نشان میدهد.
برای دستهٔ دوم — پرسشهای دادهمحور — یک لایه اضافه لازم است: اتصال خواندنی به سامانه سفارش. توجه کنید که این هنوز «عامل» نیست؛ فقط میخواند. تفاوتش را در عامل هوشمند یا چتبات نوشتهایم.
چیزی که بیشتر از دقت اهمیت دارد
سامانهای که هشتاد درصد درست جواب میدهد و بیست درصد با اطمینان اشتباه میگوید، از سامانهای که شصت درصد جواب میدهد و بقیه را میگوید نمیدانم، بیاعتمادتر است.
پس دو رفتار غیرقابل مذاکرهاند:
گفتن «نمیدانم». وقتی متن مرتبطی پیدا نشد، دستیار باید همین را بگوید و به کارشناس ارجاع دهد.
ارجاع سریع و بیاصطکاک. مشتری باید بتواند در هر لحظه بگوید «با آدم صحبت میکنم» و برسد. دستیاری که راه فرار ندارد، تجربه را بدتر از نبودنش میکند.
و یک قاعده سوم که کمتر گفته میشود: تاریخچه گفتوگو باید به کارشناس منتقل شود. مشتریای که ده پیام با ربات رد و بدل کرده و بعد مجبور شود همه را از اول برای کارشناس تعریف کند، از قبل عصبانیتر است.
احراز هویت، مرزی که باید روشن باشد
تا وقتی پاسخها عمومیاند، هویت مهم نیست. لحظهای که دستیار به داده مشتری دسترسی پیدا میکند، همهچیز عوض میشود.
قاعده ساده: هر پاسخی که مبتنی بر داده شخص است، فقط بعد از احراز هویت. و دسترسی دستیار باید محدود به همان مشتری باشد، نه دسترسی کلی به پایگاه داده که با نام مشتری فیلتر میشود — این دو از نظر امنیتی یکی نیستند.
زبان فارسی
کیفیت بازیابی در فارسی به نرمالسازی متن وابسته است: نیمفاصله، «ی» و «ک» عربی در برابر فارسی، اعداد فارسی و لاتین. بدون آن، سامانه با اسناد سالم هم جوابهای ضعیف میدهد.
مسئله دوم، زبان محاوره است. مشتری «چند وقت ضمانت داره؟» مینویسد، نه «مدت گارانتی چقدر است». تنها راه قابل اتکای سنجش این، استفاده از تیکتهای واقعی خودتان بهعنوان مجموعه آزمون است. تفصیلش در چالشهای پردازش زبان فارسی هست.
سنجهها
سنجهای که بیشتر از همه گمراه میکند «تعداد گفتوگو» است. چهار عدد معنادارتر:
نرخ حل بدون ارجاع — چند درصد گفتوگوها بدون کارشناس تمام شدهاند. هدف اصلی همین است.
زمان اولین پاسخ — که معمولاً بیشترین بهبود را نشان میدهد.
نرخ پاسخ قاطعِ غلط — تنها عددی که باید نزدیک صفر باشد و تنها عددی که با نمونهگیری دستی به دست میآید.
نرخ ارجاع به کارشناس — که پایینآمدنش همیشه خوب نیست. اگر ارجاع کم شده ولی شکایت زیاد شده، دستیار دارد مشتری را در بنبست نگه میدارد.
مسیر راهاندازی
با یک محصول یا یک دسته پرسش شروع کنید، نه با کل دانش سازمان.
پنجاه پرسش واقعی از تیکتها با جواب درستشان جمع کنید. این مجموعه، معیار سنجش شماست و بدون آن نمیتوانید بگویید سامانه بهتر شده یا نه.
اول در حالت پیشنهاد به کارشناس راه بیندازید: دستیار پاسخ را آماده میکند و کارشناس تأیید یا اصلاح میکند. این مرحله دو فایده دارد — ریسکی ندارد، و اصلاحهای کارشناس بهترین داده برای بهبود سامانه است.
و وقتی نرخ پاسخ قاطعِ غلط در همان دامنه به عدد قابل قبولی رسید، مستقیم در اختیار مشتری بگذارید.
سازمانهایی که این ترتیب را رعایت کردهاند در چند هفته به سامانهای قابل اتکا رسیدهاند؛ آنهایی که مستقیم از «چتبات برای همهچیز» شروع کردهاند، معمولاً بعد از چند ماه آن را خاموش کردهاند.