«کدام مدل را باید فراخوانی کنیم؟» زمانی پرسشی دربارهٔ API به نظر میرسید. در سازمانهای روزافزون، این پرسش بیشتر به مسئلهای دربارهٔ تأمین، مهندسی عملکرد و معماری تبدیل شده است.
این تغییر از یک تحول ساده ناشی میشود: اکنون مدلهای بسیاری وجود دارند که از طریق ارائهدهندگان متعددی عرضه میشوند و از نظر توانمندیها، قیمتها، الگوهای تأخیر، گزینههای استقرار و شرایط قراردادی تفاوتهای چشمگیری دارند. توافق اعلامشدهٔ Stripe برای خرید OpenRouter سیگنال مفیدی است. API واحد OpenRouter بیش از 400 مدل از بیش از 80 ارائهدهنده را پوشش میدهد و معیارهای مسیریابی آن شامل پیچیدگی کار، قیمت، سرعت، قابلیت اطمینان، تأخیر، توان عملیاتی و هزینههای اختصاصی ارائهدهنده است.
این شغل نوظهور لزوماً عنوانی جدید نیست. ممکن است میان مهندسی پلتفرم هوش مصنوعی، معماری، تأمین، عملیات استنتاج یا مهندسی محصول قرار بگیرد. اما مسئولیت آن در حال آشکارتر شدن است: تصمیمگیری دربارهٔ اینکه کدام مدل باید کدام کار را، تحت چه محدودیتهایی، با چه گزینهٔ جایگزینی و بر اساس چه شواهدی انجام دهد.
مسیریابی، تصمیمی سیاستگذاری است که در لباس زیرساخت پنهان شده است
یک مسیریاب سادهلوح میپرسد: «کدام مدل ارزانتر است؟» یک مسیریاب مفید پرسش دقیقتری مطرح میکند: «کمهزینهترین مدلی که الزامات کیفی، تأخیر، قابلیت اطمینان، حریم خصوصی و عملیاتی این درخواست را برآورده میکند، کدام است؟»
این الزامات بسته به کار متفاوتاند. یک دستهبندیکنندهٔ پشتیبانی مشتری ممکن است به خروجی ساختاریافتهٔ قابلپیشبینی و تأخیر کم نیاز داشته باشد. یک کار دشوار کدنویسی ممکن است استفاده از مدلی کندتر اما توانمندتر را توجیه کند. یک خط لولهٔ خلاصهسازی با حجم بالا ممکن است مدل کوچکتری را ترجیح دهد، بهویژه اگر کیفیت آن پس از آزمایش کافی باشد. یک گردشکار تحت نظارت مقررات ممکن است صرفنظر از قیمت توکن، به منطقهای خاص، سیاست نگهداری داده یا توافقی با ارائهدهندهای مشخص نیاز داشته باشد.
به همین دلیل، مسیریابی باید در بازبینیهای معماری بررسی شود، نه فقط در کد برنامه. مسیر انتخابشده چیزی بیش از یک صورتحساب را تعیین میکند. این مسیر میتواند بر محل نگهداری داده، میزان مواجهه با قطعیها، مشاهدهپذیری، سازگاری پاسخها، رفتار استفاده از ابزارها و میزان بازبینی انسانی موردنیاز در مراحل بعدی اثر بگذارد.
چهار حوزهٔ تخصصی پشت یک کارکرد مسیریابی جدی
1. تأمین: کل سرویس را مقایسه کنید، نه فقط قیمت اعلامشدهٔ توکن را
مقایسهٔ قیمت مدلها بهسادگی میتواند بهشکل نادرستی انجام شود. توکنهای ورودی و خروجی ممکن است نرخهای متفاوتی داشته باشند. ورودی ذخیرهشده، پردازش دستهای، سرویس اولویتدار و درخواستهای دارای زمینهٔ طولانی میتوانند محاسبه را تغییر دهند. قیمت اسمی یک ارائهدهنده نیز دربارهٔ تلاشهای مجدد، محدودیتهای نرخ، پشتیبانی، تعهدات حداقلی، خروجی داده و هزینهٔ مهندسی جابهجایی اطلاعات چندانی نمیگوید.
مسئول مسیریابی باید موجودی مدلها و ارائهدهندگان را با فیلدهایی مانند موارد زیر نگهداری کند:
- قیمتگذاری ورودی، خروجی، ذخیرهشده و دستهای؛
- محدودیتهای زمینه و خروجی؛
- محدودیتهای نرخ مستندشده و توان عملیاتی مشاهدهشده؛
- توزیعهای تأخیر، نه صرفاً میانگین تأخیر؛
- دسترسپذیری و رفتار هنگام پایان مهلت؛
- شرایط استفاده از داده، نگهداری، محل اقامت داده و قراردادها؛
- قابلیتهای پشتیبانیشده، از جمله فراخوانی ابزارها، خروجی ساختاریافته، بینایی و جریانسازی؛
- گزینههای جایگزینی و مهاجرت.
نتیجه، بیشتر به فهرست اقلام مواد اولیهٔ فناوری شباهت دارد تا فهرستی از نام مدلها. این فهرست باید هنگام تغییر قیمتها، سیاستها، نسخههای مدل یا حجم کسبوکار بازبینی شود.
2. مهندسی عملکرد: کار را اندازهگیری کنید، نه جدول رتبهبندی را
معیارهای عمومی میتوانند برای جهتیابی مفید باشند، اما تصمیمهای مسیریابی به آزمونهای ویژهٔ هر بارکاری نیاز دارند. مدلی که در یک معیار عمومی کدنویسی عملکرد خوبی دارد، ممکن است برای مخازن داخلی، قراردادهای نامگذاری، طرحوارههای ابزار یا کنترلهای امنیتی یک سازمان بهترین گزینه نباشد.
یک مجموعهٔ ارزیابی نماینده از درخواستهای واقعی بسازید و مطالب حساس را حذف یا کنترل کنید. نتایج مهم را برچسبگذاری کنید: درستی واقعی، JSON معتبر، انتخاب موفق ابزار، موفقیت آزمون کد، رفتار امتناع، نیاز به ارجاع و سبک قابلقبول. سپس هزینه، زمان تا نخستین توکن، تأخیر کل، نرخ پایان مهلت، نرخ تلاش مجدد و طول تکمیل را ثبت کنید.
نتیجه را خیلی زود به یک امتیاز واحد تقلیل ندهید. امتیاز وزنی میتواند یک حالت خرابی جدی را پنهان کند. برای مثال، مدلی با کیفیت میانگین عالی اما فراخوانیهای مکرر و نادرست ابزار ممکن است برای یک گردشکار خودکار نامناسب باشد. اگر پاسخهای یک مدل کندتر نیاز به بازبینی انسانی پرهزینه را کاهش دهند، آن مدل ممکن است از نظر اقتصادی ترجیحپذیر باشد.
از فرایند قهرمان و چالشگر استفاده کنید: یک مسیر فعلاً تأییدشده را حفظ کنید، گزینههای جایگزین را با همان پیکره آزمایش کنید و تنها زمانی یک چالشگر را ارتقا دهید که از آستانههای صریح کیفی و عملیاتی عبور کند. ادعاهای گزارششده از سوی ارائهدهنده باید بهعنوان ورودیهای یک برنامهٔ آزمون در نظر گرفته شوند، نه مدرکی دال بر اینکه یک مدل در محیط شما نیز عملکرد مشابهی خواهد داشت.
۳. معماری: انتخاب مدل را قابلجایگزینی کنید
وقتی فرضیات خاصِ مدل در سراسر یک برنامه نشت میکنند، مسیریابی پرهزینه میشود. یک طراحی تابآور، وظیفهٔ کسبوکار را از فراخوانی ارائهدهنده جدا میکند.
یک قرارداد داخلی برای قابلیتها تعریف کنید. این قرارداد میتواند مشخص کند که یک عملیات «دستهبندی» طرحوارهای ثابت، فیلدهای اطمینان یا خودداری از پاسخ، شناسهٔ مدل و شناسهٔ رهگیری برمیگرداند. یک عملیات «پیشنویس پاسخ» نیز میتواند محدودیتهای لحن، الزامات استناد و حداکثر بودجهٔ تأخیر را مشخص کند. سپس آداپتورهای ارائهدهندگان، این قرارداد را به APIهای مجزا ترجمه میکنند.
پرامپتها، طرحوارهها، تعریف ابزارها، قواعد ایمنی و سیاستهای مسیریابی را نسخهبندیشده نگه دارید. ثبت کنید که هر درخواست توسط کدام snapshot مدل و کدام ارائهدهنده پاسخ داده شده است. اطلاعات کافی برای بازتولید یک تصمیم را حفظ کنید، بدون اینکه محتوای حساس کاربر را بیدلیل نگه دارید.
جایگزینهای پشتیبان را آگاهانه طراحی کنید. یک جایگزین میتواند ارائهدهندهای دیگر، مدلی کوچکتر، یک گردشکار صفشده یا مسیر بازبینی انسانی باشد. این جایگزین نباید معنای وظیفه را بیسروصدا تغییر دهد. اگر خروجی ساختاریافته الزامی است، جایگزین باید از همان قرارداد پشتیبانی کند یا باعث یک تشدید کنترلشده شود.
۴. حکمرانی: تصمیم بگیرید چه زمانی نباید بهصورت خودکار مسیریابی کرد
برخی درخواستها نباید به ارزانترین مدل موجود—یا به هیچ مدل خارجی—ارسال شوند. سیاست مسیریابی به قواعد حذفی برای دادههای محرمانه، تصمیمهای پراهمیت، زبانهای پشتیبانینشده، زمینهٔ غیرمعمولاً طولانی یا اقداماتی که به یک مرحلهٔ تأیید انسانی نیاز دارند، احتیاج دارد.
تیمها همچنین باید بین در دسترس بودن فنی یک مدل و تأییدشدن آن برای یک کاربرد خاص تمایز قائل شوند. الزامات تدارکات و حقوقی ممکن است بر اساس واحد کسبوکار متفاوت باشد. یک مدل میتواند در ارزیابی عالی باشد و همچنان برای گردشکاری که شرایط مدیریت دادهٔ آن با سازمان سازگار نیست، غیرقابلاستفاده باشد.
یک جدول عملی برای مسیریابی
یک سیاست آغازین میتواند ساده و صریح باشد:
| کلاس وظیفه | هدف اصلی | مسیریابی ممکن | محرک تشدید |
|---|---|---|---|
| استخراج با حجم بالا | طرحوارهٔ معتبر و هزینهٔ پایین بهازای هر واحد | مدل کوچک یا متوسط با اعتبارسنجی سختگیرانهٔ خروجی | شکست طرحواره یا اطمینان پایین |
| تحلیل پیچیده | کیفیت و مدیریت شواهد | مدل توانمندتر با بودجهٔ تأخیر بیشتر | شواهد ناقص، ابهام یا علامت سیاستی |
| کمک تعاملی | پاسخ سریع از دید کاربر | مدل کمتأخیر، که ممکن است پس از آن پالایش انجام شود | اعتماد پایین یا درخواست کاربر برای عمق بیشتر |
| جریان کاری حساس | نحوه پردازش داده و قابلیت حسابرسیِ تأییدشده | ارائهدهنده مورد تأیید قرارداد یا استقرار کنترلشده | داده، اقدام یا حوزه قضاییِ تأییدنشده |
جدول دقیق بسته به سازمان متفاوت خواهد بود. نکته مهم این است که قواعد مسیریابی باید برای ذینفعان محصول، امنیت، مالی و مهندسی خوانا باشند، نه اینکه درون یک عبارت شرطی مدفون شوند.
این موضوع برای افرادی که در حال ساختن مسیر شغلی خود هستند چه معنایی دارد
قویترین نامزدها برای این کار، چند نوع مهارت و دانش را با هم ترکیب خواهند کرد. آنها باید بهاندازه کافی با یادگیری ماشین آشنا باشند تا بتوانند درباره قابلیتها و افت عملکرد استدلال کنند؛ بهاندازه کافی مهندسی سیستم بدانند تا تأخیر، تلاشهای مجدد، محدودیتهای نرخ و حالتهای خرابی را مدیریت کنند؛ بهاندازه کافی از امور مالی بدانند تا هزینه کل را مدلسازی کنند؛ و بهاندازه کافی با تدارکات و حاکمیت آشنا باشند تا تعهدات و محدودیتهای ارائهدهندگان را ارزیابی کنند.
آنها همچنین در نوشتن سوابق تصمیمگیری راحت خواهند بود. یک سابقه مفید توضیح میدهد که چرا یک مسیر انتخاب شده است، چه شواهدی از آن پشتیبانی میکند، چه ریسکهایی باقی ماندهاند و چه رویدادی باید ارزیابی مجدد را آغاز کند. این کار از حفظ کردن نام جدیدترین مدلها ارزشمندتر است، چون نام مدلها و قیمتها همچنان تغییر خواهند کرد.
یک پروژه نمونهکار فشرده میتواند این مهارت را بدون نیاز به یک سامانه تولیدی بزرگ نشان دهد. یک بارکاری را انتخاب کنید، یک مجموعه ارزیابیِ پالایششده ایجاد کنید، سه ارائهدهنده مدل یا مدل محلی را از طریق یک رابط مشترک به هم متصل کنید و کیفیت، اعتبار طرحواره، صدکهای تأخیر، نرخ خرابی و هزینه ماهانه برآوردشده را در چند حجم مختلف مقایسه کنید. برای ورودیهای حساس قواعد سیاستی و یک مسیر جایگزین اضافه کنید. روششناسی آزمون و محدودیتها را منتشر کنید.
درباره اینکه پروژه دقیقاً چه چیزی را اثبات میکند، دقیق باشید. این پروژه ثابت نمیکند که یک مدل در همه شرایط بهترین است. ثابت میکند که میتوانید مسئله مبهم انتخاب مدل را به یک سیاست عملیاتی قابل اندازهگیری تبدیل کنید.
نشانه شغلی
مسیریابی مدلها از نظر راهبردی اهمیت بیشتری پیدا میکند، زیرا هوشمندی دیگر یک وابستگی ثابت و واحد نیست. هوشمندی مجموعهای از خدمات با بدهبستانهای متفاوت و اقتصاد در حال تغییر است. تیمهایی که با این مجموعه مانند زیرساختی قابلجایگزین برخورد میکنند، ممکن است هزینهها را کاهش دهند، اما میتوانند مشکلات پنهان کیفیت، انطباق و قابلیت اطمینان نیز ایجاد کنند. تیمهایی که آن را یک تعهد دائمی به یک مدل واحد میدانند، ممکن است گزینههای بهتر را از دست بدهند.
رشته نوظهور میان این دو افراط قرار میگیرد: بهاندازهای انتزاعی که بتوان ارائهدهندگان را تغییر داد، بهاندازهای مشخص که کیفیت کار حفظ شود، و بهاندازهای مبتنی بر شواهد که بتوان انتخاب را توجیه کرد. این همان فرصت شغلی در حوزه مسیریابی مدلهاست—نه یکبار انتخاب کردن یک API، بلکه ساختن سامانه تصمیمی که همواره انتخابهای خوبی انجام دهد.
تام ویتفیلد ویراستار انسانیِ پاسخگو و مسئولِ AI Career Brief است و مهارتها، نقشها و حرکتهای هوشمندانه برای کار کردن در عصر هوش مصنوعی را پوشش میدهد.
