مسیریابی شرطی درخواست‌ها؛ چه وقت پاسخ بدهیم و چه وقت ارجاع دهیم؟

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

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

مسیریابی شرطی در جریان کار

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

مثال درسنامه؛ دروازه‌ی کیفیت محتوا

درسنامه‌ی مایکروسافت جریانی را نشان می‌دهد که یک آموزش فنی را خودکار تولید و منتشر می‌کند. ایجنت نویسنده بر اساس یک طرح کلی و چند منبع وب، پیش‌نویس آموزش را می‌نویسد. ایجنت بازبین پیش‌نویس را بررسی می‌کند؛ مثلاً آیا طولش از حداقل تعیین‌شده بیشتر است.

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

خروجی ساختاریافته برای شرط

برای اینکه شرط قابل‌اعتماد باشد، خروجی بازبین باید ساختاریافته باشد، نه متن آزاد. در نمونه‌ی مایکروسافت، بازبین یک شیء با سه فیلد برمی‌گرداند: نتیجه‌ی بررسی (بله یا خیر)، دلیل و محتوای پیش‌نویس. طرح‌واره‌ی JSON تضمین می‌کند این سه فیلد همیشه وجود دارند.

یال‌های شرطی هم با یک تابع شرط ساخته می‌شوند. این تابع خروجی بازبین را می‌گیرد و بررسی می‌کند نتیجه برابر مقدار مورد انتظار است یا نه. یک یال برای «بله» به انتشار می‌رود و یال دیگر برای «خیر» به بازگرداندن دلیل. اگر شرط روی متن آزاد نوشته می‌شد، کوچک‌ترین تغییر در لحن مدل جریان را خراب می‌کرد.

حلقه‌ی بازنگری

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

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

مسیریابی درخواست‌ها در ورودی دستیار

کاربرد دوم مسیریابی شرطی، در ورودی دستیار است. هر پیامی که می‌رسد، باید به مسیر درست برود. در یک دستیار آموزشی، پیام دانشجو ممکن است یکی از این‌ها باشد: سؤال محتوایی درباره‌ی دوره، مشکل دسترسی مثل ورود به حساب، یا درخواست پشتیبانی مثل بازپرداخت.

چرا مسیریابی لازم است؟

هر کدام از این مسیرها ابزار و داده‌ی خودش را دارد. سؤال محتوایی با RAG روی اسناد دوره جواب داده می‌شود. مشکل دسترسی به ابزارهای حساب کاربری نیاز دارد که فقط برای کاربر احرازشده مجازند. درخواست بازپرداخت باید به تیم انسانی برسد.

مسیریابی سه مزیت دارد. هزینه کم می‌شود، چون سؤال ساده به مدل ارزان‌تر می‌رود. کیفیت بالا می‌رود، چون هر مسیر ابزار و دستورالعمل تخصصی خودش را دارد. و امنیت بیشتر می‌شود، چون ابزارهای حساس فقط در مسیری در دسترس‌اند که کنترل دسترسی دارد.

مسیریاب با خروجی ساختاریافته

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

from enum import Enum
from pydantic import BaseModel, Field
from openai import OpenAI

class Route(str, Enum):
    content = "content"          # سؤال درباره‌ی محتوای دوره
    account = "account"          # ورود، رمز عبور، دسترسی
    support = "support"          # پرداخت و بازپرداخت
    unclear = "unclear"          # مبهم
    out_of_scope = "out_of_scope"

class Decision(BaseModel):
    route: Route
    confidence: float = Field(ge=0, le=1)
    topics: list[str]

client = OpenAI()

def decide(message: str) -> Decision:
    prompt = "پیام دانشجو را دسته‌بندی کن. اگر مطمئن نیستی unclear بگذار. اگر چند موضوع دارد همه را در topics بنویس.\n\n" + message
    return client.responses.parse(model="gpt-5-mini", input=prompt, text_format=Decision).output_parsed

دسته‌های «مبهم» و «خارج از دامنه» عمداً وجود دارند. بدون آن‌ها، مدل مجبور است هر پیامی را در یکی از سه دسته‌ی اصلی بگذارد؛ حتی وقتی مطمئن نیست.

قواعد مسیر پس از تصمیم

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

امنیت؛ مسیر حساس فقط با احراز هویت

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

این قاعده در کد اعمال می‌شود، نه در پرامپت. مسیریاب ممکن است فریب بخورد، اما کدی که پیش از ارسال وضعیت ورود را بررسی می‌کند، فریب نمی‌خورد.

حالت‌های مرزی

سه حالت مرزی را جداگانه طراحی کنید. پیام مبهم، مثل «کار نمی‌کند»، باید به یک پرسش روشن‌کننده برسد: «منظورتان ورود به حساب است یا پخش ویدئوی درس؟». پیام خارج از دامنه باید پاسخی مؤدبانه بگیرد که بگوید دستیار در چه زمینه‌هایی کمک می‌کند.

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

سناریوی عملی؛ مسیریاب پیام‌های دانشجو

پیام دانشجو ممکن است سؤال محتوایی، مشکل دسترسی یا درخواست پشتیبانی باشد. مسیریاب باید هر پیام را به ابزار یا تیم مناسب برساند. نمودار زیر مراحل این مسیریاب را نشان می‌دهد.

ورودی و معیار پذیرش

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

معیار پذیرش دو بخش دارد: دقت مسیر انتخاب‌شده و کیفیت برخورد با پیام چندموضوعی. دقت را برای هر دسته جداگانه بسنجید. مسیریابی که دسته‌ی پرتکرار را خوب و دسته‌ی حساس را بد تشخیص دهد، قابل‌قبول نیست.

نمونه‌ی شکست؛ درخواست حساس در مسیر عمومی

شکستی که باید عمداً دنبالش بگردید این است: درخواست حساس به شاخه‌ی عمومی که کنترل دسترسی ندارد فرستاده شود. مثلاً کاربری که وارد نشده، درخواست تغییر ایمیل حساب را طوری بنویسد که شبیه سؤال محتوایی به نظر برسد.

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

تمرین عملی؛ مسیریاب با حالت‌های مرزی

خروجی این تمرین یک مسیریاب با مسیر روشن برای حالت مبهم و خارج از دامنه است:

1. تابع decide را پیاده کنید و بیست پیام نمونه‌ی برچسب‌دار را با آن دسته‌بندی کنید.
2. قواعد جدول بالا را در کد پیاده کنید؛ به‌خصوص قاعده‌ی احراز هویت برای مسیر حساب.
3. دقت هر دسته را جداگانه گزارش کنید و نمونه‌ی شکست را بازسازی کنید.

مشخص کنید کدام بخش را واقعاً اجرا کرده‌اید و کدام هنوز فرض است.

سخن پایانی

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

در قسمت بعد بازبینی خروجی ایجنت و استفاده از کد برای اصلاح خطا با معیار قابل سنجش را می‌بینیم.

این آموزش بر پایه‌ی نمونه‌های گردش کار شرطی Microsoft Agent Framework در مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.