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