همه درخواست‌ها یک مدل نمی‌خواهند
خلاصه یک پیام کوتاه با تحلیل چند سند متعارض نیاز یکسانی ندارد. مسیریابی مدل تصمیم می‌گیرد هر درخواست به کدام مدل مجاز برسد. مستندات Amazon Bedrock نمونه‌ای از مسیریابی هوشمند با موازنه کیفیت و هزینه را شرح می‌دهد؛ دامنه مدل‌ها و قابلیت آن به سرویس وابسته است.
در معماری سازمانی، انتخاب مدل باید از سیاست داده آغاز شود. ارزان‌تر یا سریع‌تر بودن یک سرویس نمی‌تواند مجوز ارسال اطلاعات محرمانه به آن ایجاد کند. فهرست مقصدهای مجاز باید پیش از هر تصمیم بهینه‌سازی اعمال شود.
برای ادامهٔ این بحث، مقالهٔ «چه زمانی یک مدل کوچک برای سازمان کافی است؟» را در دانشنامهٔ لیان بخوانید.
پیشنهاد اجرایی: ابتدا مسیرهای ساده
سه گروه آزمایشی تعریف کنید: کارهای کوتاه و کم‌ریسک، پاسخ مبتنی بر سند و تحلیل پیچیده. برای هر گروه مدل مجاز، حد زمان و معیار کیفیت بنویسید. یک مسیر ثابت قابل‌توضیح اغلب نقطه شروع بهتری از طبقه‌بند مبهمی است که دلیل انتخابش معلوم نیست.
در پاسخ دانش‌محور، کیفیت بازیابی را پیش از ارتقای مدل بررسی کنید. فرستادن سؤال به مدل بزرگ‌تر وقتی سند درست در زمینه وجود ندارد، لزوماً پاسخ را معتبر نمی‌کند. مشکل داده و مشکل توان مدل را در گزارش خطا جدا نگه دارید.
مسیر جایگزین باید همان محدودیت‌ها را حفظ کند
وقتی مدل اصلی در دسترس نیست، مسیر جایگزین نیز باید محدودیت جغرافیای داده، مجوز ابزار و قالب خروجی را رعایت کند. تغییر بی‌صدای مدل ممکن است کیفیت استخراج یا رفتار ابزار را عوض کند؛ نسخه مدل و دلیل تغییر مسیر باید قابل‌ردیابی باشد.
بازگشت به مدل گران‌تر را محدود کنید تا خطای پیاپی به هزینه نامحدود تبدیل نشود. در برخی سناریوها توقف روشن و ارجاع به کارشناس بهتر از ادامه خودکار با مقصدی است که شرایط لازم را ندارد.
ارزیابی جداگانه هر شاخه
برای هر مسیر، داده آزمون مستقل داشته باشید و نرخ پاسخ پذیرفته، تأخیر، هزینه و ارجاع به انسان را ثبت کنید. سپس کل هزینه انجام کار موفق را مقایسه کنید؛ قیمت هر توکن فقط بخشی از هزینه است و تلاش مجدد یا بازبینی دستی نیز اثر دارد.
پس از تغییر نسخه مدل، همان آزمون‌ها را تکرار کنید. صرفه‌جویی حاصل از مسیریابی فقط وقتی ارزش دارد که کیفیت موردنیاز و مرز داده حفظ شود. نتیجه را با اعداد همان سناریوی سازمان گزارش کنید، نه وعده درصدی عمومی.
سه مسیر نمونه برای یک دستیار سازمانی
برای شروع، سه کار مشخص انتخاب کنید: استخراج چند فیلد از یک نامه، پاسخ مستند به پرسش آیین‌نامه و تحلیل چند سند دارای تعارض. برای هر کار، خروجی مطلوب، داده مجاز، ابزار لازم و سقف زمان را بنویسید. این دسته‌بندی پیشنهادی را با نمونه واقعی بسنجید؛ کوتاه بودن پرسش لزوماً نشانه ساده بودن مسئله نیست و یک جمله کوتاه می‌تواند به تصمیم حساس درباره قرارداد مربوط باشد.
ابتدا مشخص کنید هر درخواست اجازه ورود به کدام محیط پردازش را دارد، سپس از میان گزینه‌های مجاز انتخاب کنید. اگر سند فقط در محیط داخلی قابل‌پردازش است، مسیر ارزان‌تر خارجی از ابتدا واجد شرایط نیست. در نمونه آزمایشی، همین محدودیت را با ورودی ساختگی دارای برچسب محرمانگی امتحان کنید. مسیریاب باید علت انتخاب و گزینه‌های حذف‌شده را در گزارش فنی قابل‌بررسی نگه دارد، بدون اینکه اطلاعات حساس را در گزارش عمومی تکرار کند.
چه زمانی درخواست را به مدل دیگری ببریم؟
ارتقای مسیر را به نشانه قابل‌ارزیابی متصل کنید. برای استخراج، شکست کنترل فیلد یا تعارض سند می‌تواند دلیل بازبینی باشد؛ برای پرسش مستند، نبود شاهد مناسب ابتدا مسئله بازیابی است. فرستادن همان سؤال بی‌منبع به مدل گران‌تر، منبع معتبر خلق نمی‌کند. اگر مسئله از ناخوانا بودن تصویر یا نبود مجوز است، مسیر درست ممکن است درخواست ورودی بهتر یا توقف باشد.
برای هر نوع شکست، یک اقدام و سقف تلاش تعیین کنید. نمونه پیشنهادی این است که خطای موقت سرویس از پاسخ نامعتبر جدا شود و تلاش دوباره بودجه مستقل داشته باشد. حداقل اطلاعات موردنیاز را به مرحله بعد منتقل کنید و دلیل ارتقا را حفظ کنید. اجرای زنجیره‌ای چند مدل بدون معیار توقف می‌تواند هزینه را بالا ببرد و در نهایت همان پاسخ نادرست را با ظاهر مطمئن‌تری برگرداند.
هزینه هر کار موفق را حساب کنید
در یک دوره آزمایشی، برای هر درخواست مسیر اولیه، تعداد تلاش، زمان کل، هزینه پردازش و نتیجه بازبینی را ثبت کنید. سپس هزینه کل را بر تعداد کارهایی تقسیم کنید که تعریف قبولی را واقعاً گذرانده‌اند. درخواست ناموفق یا پاسخ نیازمند اصلاح سنگین را موفق نشمارید. این تعریف کمک می‌کند مدل ارزان با تکرار زیاد، به‌اشتباه گزینه اقتصادی‌تر دیده نشود.
گزارش را بر اساس نوع کار هم تفکیک کنید. ممکن است یک مسیر برای استخراج ساده مناسب و برای تحلیل تعارض ضعیف باشد. زمان کارشناس، هزینه بازیابی و پردازش سند را در مقایسه نهایی لحاظ کنید و بازه اندازه‌گیری را بنویسید. اگر قیمت یا مدل عوض شد، فرض‌های محاسبه باید قابل‌به‌روزرسانی باشند. عدد میانگین بدون شرح ترکیب درخواست‌ها، برای تصمیم ظرفیت و بودجه قابل‌اتکا نیست.
انتشار تدریجی سیاست مسیریابی
ابتدا تصمیم مسیر جدید را بدون تغییر پاسخ واقعی ثبت کنید و با تصمیم کارشناسی مقایسه کنید؛ این اجرای سایه در اینجا یک پیشنهاد ارزیابی است. پس از رفع خطاهای روشن، دامنه محدودی از کارهای کم‌اثر را به سیاست جدید بدهید. نسخه سیاست، فهرست مدل‌های مجاز و شرایط بازگشت را ثبت کنید تا افت کیفیت به یک تغییر مشخص قابل‌نسبت دادن باشد.
خرابی گزینه اصلی را هم آزمایش کنید. مسیر جایگزین باید همان محدودیت داده، مجوز ابزار و قرارداد خروجی را رعایت کند؛ اگر چنین گزینه‌ای ندارید، توقف کنترل‌شده از انتقال بی‌قاعده مناسب‌تر است. برای کاربر زمان انتظار و وضعیت کار را روشن نگه دارید. تحویل موفق این پروژه شامل سیاست انتخاب، مجموعه آزمون، گزارش کیفیت و هزینه و راه بازگشت است؛ صرفاً جابه‌جایی خودکار بین چند نام مدل، مسیریابی قابل‌بهره‌برداری نمی‌سازد.
پرسش‌های متداول
آیا مسیریابی همیشه هزینه را کم می‌کند؟
خیر. هزینه طبقه‌بندی، تلاش مجدد و افت کیفیت می‌تواند صرفه‌جویی را از بین ببرد.
در خرابی مدل می‌توان هر مقصدی را انتخاب کرد؟
خیر. مسیر جایگزین باید همچنان سیاست داده و قابلیت‌های لازم را داشته باشد.
منابع
- Amazon Web ServicesIntelligent prompt routingOfficial documentation
مطالعهٔ بیشتر در دانشنامهٔ لیان
- لیان داتا پارسچه زمانی یک مدل کوچک برای سازمان کافی است؟برای مقایسهٔ مدل‌های سبک و اجرای محلی، معیارهای کیفیت فارسی، ظرفیت سخت‌افزار و هزینهٔ نگهداری را در لیان دنبال کنید.
- لیان داتا پارسهزینه واقعی هر کار با هوش مصنوعی چقدر است؟برای محاسبهٔ هزینه فراتر از توکن، مطلب لیان هزینهٔ داده، ابزار، زیرساخت و بازبینی انسانی را در کنار کیفیت نتیجه بررسی می‌کند.