گزارش توسعه‌دهندگان: حذف کامل لغزش‌های قصد با طبقه‌بندی دو‌لایه

اگر امروز یک عامل هوش مصنوعی می‌سازید که میان چندین ابزار مختلف جابه‌جا می‌شود، احتمالاً با کابوس «مسیریابی اشتباه» دست‌وپنجه نرم می‌کنید. یک اشتباه کوچک در تشخیص قصد کاربر، می‌تواند باعث شود عامل شما به‌جای ارسال ایمیل، شروع به استعلام قیمت کند و کل تجربه کاربری را تخریب کند. مهندسی یک «نردبان اعتماد» (Confidence Ladder) تضمین می‌کند که هیچ درخواستی از کاربر «یتیم» نماند و از شکست‌های رایج جلوگیری می‌کند؛ جایی که عوامل هوش مصنوعی درخواست را به مجموعه ابزار غلط هدایت می‌کنند.

طبق گزارش فنی منتشر شده در وب‌سایت dev.to در تاریخ ۱ اوت ۲۰۲۶، استفاده از یک سامانه مسیریابی ترکیبی (Hybrid Routing) که Regex را با تطبیق معنایی (Semantic Matching) ترکیب می‌کند، می‌تواند صحت طبقه‌بندی را به نزدیکی ۱۰۰٪ برساند. این رویکرد ترکیبی در واقع پاسخی به این چالش است که چرا جست‌وجوی برداری خالص در مواجهه با داده‌های صنعتی شکست می‌خورد و نیاز به ساختارهای هیبریدی را توجیه می‌کند. این روش با پر کردن شکاف بین الگوهای شناخته‌شده و زبان محاوره‌ای، اجازه نمی‌دهد هیچ درخواستی بدون پاسخ بماند یا به ابزار غلط ارسال شود.

مشکل: سقف محدودیت‌های Regex

بسیاری از توسعه‌دهندگان مسیر خود را با عبارت‌های منظم یا Regex آغاز می‌کنند، اما این روش به‌سرعت به یک سقف سخت برخورد می‌کند. Regex برای الگوهای شناخته‌شده بسیار مؤثر است، اما در مواجهه با عبارت‌بندی‌های ناشناخته شکست می‌خورد. برای مثال، استفاده از الگویی مانند QUOTING_PATTERN = r'sea.*freight|air.*freight|quote|quotation|rate' می‌تواند اصطلاحات استاندارد صنعت حمل‌ونقل را به‌طور بهینه مدیریت کند. درخواستی مثل «هزینه حمل دریایی به فرانکفورت چقدر است؟» یا «استعلام قیمت DDP به CDG» به‌طور کامل با این الگو تطبیق می‌یابد.

با این حال، داده‌های عملیاتی (Production Data) داستان متفاوتی را روایت می‌کنند: پوشش Regex معمولاً در حدود ۶۰ تا ۷۰ درصد متوقف می‌شود. زبان طبیعی اغلب از این کلمات کلیدی اجتناب می‌کند. عبارت‌هایی مثل «بپرس حمل هوایی از XX به YY چقدر می‌شود»، «از هنگ‌کنگ به لس‌آنجلس، قیمت چنده؟» یا «این محموله چقدر می‌شه؟» را در نظر بگیرید. این جملات محاوره‌ای یا به‌طور کامل با الگو تطبیق نمی‌یابند یا بدتر از آن، با صحنه (Scene) غلطی تطبیق می‌یابند.

دشوارترین موارد، درخواست‌هایی هستند که به‌جای تطبیق کلمات کلیدی، به درک معنایی واقعی نیاز دارند. درخواستی مانند «این ایمیل را برای سانی فوروارد کن» شامل هیچ کلمه کلیدی مربوط به ایمیل نیست، اما واضح است که قصد کاربر «فوروارد کردن» است. Regex به‌سادگی نمی‌تواند چنین مواردی را شناسایی کند. بینش اصلی این است که Regex در الگوهای شناخته‌شده خوب است، در حالی که تحلیل معنایی (Semantics) در عبارت‌های ناشناخته می‌درخشد. این دو به‌جای جایگزینی، مکمل یکدیگر هستند.

بر اساس راهنمای فنی مذکور در dev.to، یک معماری دو لایه با جداسازی «لایه دقیق» (Exact Layer) از «لایه مبهم» (Fuzzy Layer) این مشکل را حل می‌کند. لایه دقیق، کلمات کلیدی قطعی (Deterministic) را با تأخیر نزدیک به صفر و بازدهی بسیار بالا مدیریت می‌کند. سپس لایه مبهم، تمام موارد باقی‌مانده را با استفاده از جاسازی‌های معنایی (Semantic Embeddings) شکار می‌کند. این ساختار تأکیدی بر این نکته دارد که چرا لایه معنایی پیش‌شرطِ دقت در پرس‌و‌پاسخ‌های داده‌محور است تا بتوان به نتایجی قابل اعتماد رسید.

موتور معنایی (The Semantic Engine)

لایه مبهم به مدل all-MiniLM-L6-v2 متکی است؛ یک مدل Sentence-BERT سبک که متن را به بردارهایی با ۳۸۴ بُعد تبدیل می‌کند. این بردارها در یک پایگاه‌داده برداری به نام Chroma ذخیره و کوئری می‌شوند.

برای تعیین قصد (Intent)، سیستم درخواست کاربر را با «نمونه‌های اولیه صحنه» (Scene Prototypes) مقایسه می‌کند. این نمونه‌ها در واقع عبارت‌های واقعی کاربران در تاریخچه داده‌ها هستند که بر اساس قصد طبقه‌بندی شده‌اند. برای مثال، یک نمونه اولیه برای صحنه «استعلام قیمت» (Quoting) می‌تواند شامل جمله «هزینه حمل هوایی از هنگ‌کنگ به لس‌آنجلس چقدر است؟» باشد، در حالی که نمونه اولیه صحنه «ایمیل» شامل جملاتی مثل «پاسخ ایمیل سانی را برایم بفرست» یا «یک ایمیل به ایجنت گوانگژو بزن» خواهد بود.

تنظیم برای دقت (Tuning for Precision)

دقت سیستم به «آستانه شباهت» (Similarity Threshold) بستگی دارد که نیاز به تنظیمات سیستماتیک دارد. داده‌های زیر توازن بین میزان پوشش و خطای طبقه‌بندی را نشان می‌دهد:

• آستانه ۰.۴۵: پوشش حدود ۹۰٪، اما ۱۵٪ خطای طبقه‌بندی. درخواست‌هایی مثل «وضعیت پرواز را چک کن» به‌اشتباه به بخش استعلام قیمت هدایت می‌شوند.
• آستانه ۰.۵۰: پوشش حدود ۸۲٪ و ۸٪ خطای طبقه‌بندی. یک نقطه میانه، اما «فوروارد کردن ایمیل» همچنان به‌طور مکرر اشتباه تشخیص داده می‌شود.
• آستانه ۰.۵۵: پوشش حدود ۷۵٪ و تنها ۳٪ خطای طبقه‌بندی. این نقطه، بهینه‌ترین حالت پیش‌فرض (A-priori) است.

با افزایش آستانه به ۰.۵۵، سیستم خطاهای طبقه‌بندی را به تنها ۳٪ کاهش می‌دهد. این یک نقطه بهینه (Sweet Spot) قابل قبول است: سیستم ترجیح می‌دهد یک نتیجه «گمشده» داشته باشد (که در آن کوئری به یک صحنه عمومی بازمی‌گردد) تا اینکه یک نتیجه «غلط» تولید کند؛ زیرا یک صحنه غلط به معنای استفاده عامل از ابزارهای اشتباه است. رسیدن به این پیکربندی ۰.۵۵ مستلزم یک هفته کامل تنظیمات (Tuning) بود.

برای سرکوب بیشتر خطاها، یک «بررسی حاشیه» (Margin Check) پیاده‌سازی شده است. صرفاً عبور از آستانه برای نتیجه اول کافی نیست؛ بلکه شکاف بین شباهت رتبه اول و دوم نیز باید از حاشیه ۰.۱ عبور کند. این کار مانع از حدس زدن عامل در زمانی می‌شود که دو قصد (مانند وضعیت پرواز و استعلام قیمت حمل هوایی) از نظر معنایی به هم نزدیک (Adjacent) هستند. اگر تفاوت بین امتیاز اول و دوم کمتر از ۰.۱ باشد، تطبیق رد می‌شود تا از خطاهای مرزی مبهم جلوگیری شود.

پیاده‌سازی درخت تصمیم

جریان کار با تطبیق Regex (لایه ۱) آغاز می‌شود. اگر هیچ نتیجه‌ای یافت نشد، کوئری وارد لایه معنایی (لایه ۲) می‌شود. سیستم متن را به بردار تبدیل کرده و در Chroma برای یافتن نتایج برتر (معمولاً n_results=3) جست‌وجو می‌کند. اگر نتیجه هم از آستانه ۰.۵۵ و هم از حاشیه ۰.۱ عبور کند، به صحنه مربوطه هدایت می‌شود. در غیر این صورت، در یک صحنه جایگزین عمومی (General Fallback Scene) قرار می‌گیرد تا اطمینان حاصل شود هیچ درخواستی یتیم نمی‌ماند.

استراتژی نمونه‌های اولیه (Prototype Strategy)

مسیریابی با کیفیت بالا نیازمند یک رویکرد منضبط در طراحی نمونه‌های اولیه بر اساس سه اصل محوری است:

• کمیت و تنوع: حفظ حداقل ۵ نمونه واقعی برای هر صحنه. برای صحنه استعلام قیمت، این شامل قیمت‌های حمل دریایی، هوایی، DDP، DAP و قیمت‌های چندوجهی (Multimodal) می‌شود.
• اصالت: هر نمونه اولیه باید یک عبارت واقعی کاربر باشد که از مکالمات تاریخی جمع‌آوری شده است، نه مثال‌های ساختگی.
• تمایز: نمونه‌های مربوط به صحنه‌های مختلف باید از نظر معنایی قابل تمایز باشند. اگر نمونه‌های دو صحنه متفاوت بیش از حد به هم نزدیک باشند، کیفیت تطبیق کاهش می‌یابد.
• نگهداری: به‌روزرسانی ماهیانه نمونه‌ها. جمع‌آوری عبارت‌های تطبیق‌نیافته از صحنه جایگزین و ارزیابی نیاز به نمونه‌های جدید، چرا که نحوه بیان کاربران به مرور تغییر می‌کند (Drift).

عملکرد و مصالحه‌ها (Performance and Trade-offs)

این رویکرد، یک «دیوار کور از Regexها» را به یک سیستم مهندسی‌شده تبدیل می‌کند. از نظر عملکرد، بازیابی برداری در Chroma سریع است (کمتر از ۱۰ میلی‌ثانیه) و تأخیر آن برای کاربر نهایی نامحسوس است. با این حال، مصالحه‌های فنی وجود دارد:

• مزایا: پوشش بسیار بالا برای عبارت‌های بدون کلمه کلیدی؛ مکمل بودن Regex و معنایی (لایه دقیق کف را نگه می‌دارد و لایه مبهم سقف را بالا می‌برد)؛ قابلیت گسترش آسان نمونه‌های اولیه.
• معایب: بارگذاری اولیه کند (دانلود مدل و ساخت ایندکس Chroma حدود ۳۰ ثانیه زمان می‌برد)؛ وابستگی به کیفیت Embedding (تغییر ورژن مدل می‌تواند پایداری را تغییر دهد)؛ تنظیم آستانه همچنان تجربی است و هنوز مکانیزم خودکار ندارد؛ و مشکل «راه‌اندازی سرد» (Cold Start) برای صحنه‌های جدید.

برای یک توسعه‌دهنده کاربردی، این به معنای تغییر در طرز فکر است. شما دیگر به دنبال یک تطابق دقیق نیستید، بلکه در حال انجام دقیق‌ترین قضاوت در یک محدوده احتمالی هستید. ریسک «قضاوت غلط» بسیار پرهزینه‌تر از ریسک «از دست دادن» (Missing) است. پس از عرضه این طبقه‌بندی دو لایه، صحت کلی از ۸۰٪ به نزدیکی ۱۰۰٪ رسید.

در گام بعدی، باید به سراغ «کانتینرهای خط لوله ترکیبی» (Composite Pipeline Containers) بروید تا گزارشات پیچیده‌ای که حاوی چندین قصد متمایز هستند را مدیریت کنید؛ مثلاً یک گزارش واحد که شامل درخواست قیمت، پیگیری پرداخت و یک مورد مالی باشد و یک تک-صحنه (Single Scene) نتواند آن را مدیریت کند.