مسیریابی مدل وقتی عملی است که به کار محصول گره خورده باشد
مسیریابی بین مدل‌ها وقتی ارزش مهندسی دارد که اختلاف هزینه، تأخیر، و توان واقعاً روی کار محصول نشسته باشد. تا وقتی هر درخواست یک خرید لحظه‌ای بدون سیاست است، جدول مسیر فقط یک `if` قایم‌شده پشت اسم هوشمند است.
کلمه مهم، سنجیده است. مسیریابی وقتی کار می‌کند که کلاس کار پایدار باشد: دسته‌بندی، پیش‌نویس، کدنویسی، استخراج، تحلیل با زمینه بلند. وقتی هر درخواست تبدیل به مناقصه زنده شود، تیم نمی‌تواند بگوید چرا این بار این مدل جواب داد و بار بعد آن یکی. اعتماد کاربر هم با همین ناپایداری می‌ریزد.
چه آسان‌تر شده و چه سخت مانده
آسان‌تر شده که چند مدل را در یک محصول کنار هم بگذاری و برای کار ارزان مدل ارزان‌تر را صدا بزنی. امن‌تر نشده، مگر اینکه شکست، سقف هزینه، و رفتار جایگزین صریح باشد. سخت مانده همان چیزی که پلتفرم حل نمی‌کند: تعریف کار. اگر مرز وظیفه مبهم است، مدل بهتر فقط راه سریع‌تری برای ادامه آشفتگی می‌دهد.
از دید فول‌استک ارزش وقتی واقعی است که شکل اپ عوض شود. شاید یک مسیر هم‌زمان بالاخره باید ناهم‌زمان شود چون مدل قوی‌تر کندتر است. شاید یک قابلیت گران را بشود فقط روی تکه سخت گذاشت، نه روی کل محصول. قابلیت خام تا این جراحی را نکند در نقشه راه جا نمی‌گیرد.
جدول مسیر، نه زیرکی
جدول را به زیرکی ترجیح می‌دهم. دسته کار را بنویس. ارائه‌دهنده پیش‌فرض را بنویس. قاعده تشدید را بنویس. نتیجه را به تفکیک مسیر اندازه بگیر. تیم چیزی دارد که می‌تواند ببیند و بهتر کند. انتخاب مدل تبدیل به رفتار نامرئی محصول نمی‌شود.
شکل حداقلی که در کد می‌ماند یک نقشه است، نه یک سرویس انتزاعی بزرگ. ورودی‌اش نوع کار است، نه نام مدل. خروجی‌اش یک مسیر نام‌دار با مدل، سقف توکن، مهلت، و مدل جایگزین. لاگ و trace باید نام مسیر را داشته باشند. اگر در حادثه نمی‌توانی بگویی این درخواست از کدام ردیف جدول آمده، جدول را نساخته‌ای. شرط پراکنده ساخته‌ای.
تشدید را هم محصول کن نه غافلگیری. مثلاً استخراج فاکتور پیش‌فرضش مدل ارزان است. اگر اعتبار طرح شکست خورد، یک بار با مدل قوی‌تر تکرار می‌شود و نتیجه دوباره از همان اعتبارسنج رد می‌شود. اگر باز شکست خورد، کار به صف انسان می‌رود. این سه حالت را می‌شود تست کرد. «هر بار بهترین مدل را خود سیستم انتخاب کند» را نمی‌شود.
یک گردش کار، نه کل محصول
اگر بخواهم این را در سیستم زنده بیاورم از کوچک شروع می‌کنم. یک گردش کار که اصطکاکش روشن است. همان مسیر را بهتر می‌کنم و می‌بینم تجربه، خطای قابل دیدن، صدای پشتیبانی، یا پیچیدگی مهندسی واقعاً عوض شده یا فقط دمو هیجان‌انگیزتر شده.
اطرافش را اپ باید سنگین کند نه مدل. رابط تایپ‌دار، مرز روشن بین کار مدل و منطق اپ، و تحمل کمتر برای پهن شدن پرامپت نامرئی. اهرم تازه پلتفرم را اول خرج قابلیت اطمینان، وضوح، و جور بودن با محصول کن، نه خرج جاه‌طلبی بیشتر.
اشتباه تکراری این است که فکر کنی بهبود پلتفرم خودبه‌خود معماری دورش را ارتقا می‌دهد. نمی‌دهد. اگر کسی نمی‌تواند توضیح دهد فراخوانی گران کجا است و چرا، انتشار جدید فقط آشفتگی را ارزان‌تر یا سریع‌تر می‌کند.
کی مسیریابی نکنی
اگر یک مدل همین حالا بار را خوب تحمل می‌کند، منطق مسیر اضافه ممکن است فقط پیچیدگی بیاورد. دو کلاینت، دو شکل خطا، دو صورت‌حساب، دو مجموعه محدودیت نرخ. این‌ها رایگان نیستند. تا وقتی کلاس کار دوم واقعاً به مدل دیگر نیاز دارد، پیش‌فرض واحد را نگه دار.
خطر دیگر مسیر مات است. اگر کاربر نمی‌فهمد چرا یک ویژگی از یک درخواست به درخواست بعد جور دیگری رفتار می‌کند، اعتماد زود می‌ریزد. تفاوت مدل را یا در محصول پنهان کن و با ارزیابی ثابت نگه دار، یا اگر تفاوت قابل دیدن است عمدی و قابل توضیح کن. رفتار شانسی بین دو مدل هیچ‌کدام نیست.
تکه‌های کسل هنوز اعتماد را می‌سازند. حالت خطا، زمان پاسخ، retry، لاگ، و دست‌به‌دست به کد معمولی اپ همان قدر مهم‌اند که خود انتخاب مدل. مسیر ارزان که خطا را قورت می‌دهد و مسیر گران که مهلت ندارد، هر دو محصول را بدتر می‌کنند.
این هفته
یک گردش کار موجود را انتخاب کن که از این تغییر سود روشن می‌برد. کل محصول را یک‌جا از نو طراحی نکن. مرز کار را تنگ کن تا بهبود داخل یک مسیر قابل اندازه‌گیری بنشیند، نه داخل یک پرامپت غول یا لایه ارکستراسیون پهن.
دور تأخیر، شکست، و هزینه همان مسیر دید بگذار، به تفکیک نام مسیر. فرض‌هایی را که با این جدول عوض شده بنویس. کدام کار دیگر حق مدل گران ندارد. کدام کار اگر اعتبار شکست خورد حق تشدید دارد. همین یادداشت معمولاً بحث معماری را بیشتر جلو می‌برد تا یک هفته آزمایش هیجانی.
مسیریابی بالاخره عملی است چون اکوسیستم پهن‌تر شده و بده‌بستان روشن‌تر. مفید می‌ماند وقتی کسل، صریح، و بسته به قصد محصول باشد.
مشاهده‌پذیری مسیر را با محصول قاطی نکن
نام مدل در UI مشتری معمولاً نویز است. نام مسیر در ابزار داخلی لازم است. پشتیبانی باید بتواند بگوید این کاربر از مسیر استخراج ارزان آمده یا از تشدید. مالی باید بتواند هزینه را به قابلیت ببندد نه به یک کلید API مشترک. اگر این دو را قاطی کنی، یا به کاربر جزئیات فروشنده نشان می‌دهی که فردا دروغ می‌شود، یا داخل شرکت هیچ‌کس نمی‌داند پول کجا رفته.
ارزیابی را هم به ردیف جدول گره بزن نه به «مدل هفته». مجموعه موردها مال کار است: استخراج باید این فیلدها را درست پر کند، دسته‌بندی باید این برچسب‌ها را پایدار برگرداند. وقتی مدل ردیف را عوض می‌کنی، همان موردها را دوباره می‌زنی. اگر ارزیابی فقط وقتی مدل جدید مد است اجرا شود، جدول مسیر یک نظر شخصی است.
و مهاجرت را ارزان نگه دار. نام مسیر در کد محصول بماند. شناسه مدل فقط داخل پیکربندی همان ردیف. فردا که نام تجاری مدل عوض شد، فراخوانی‌های اپ نباید عوض شوند. این همان انضباطی است که برای درگاه پرداخت داری: اپ «پرداخت» را صدا می‌زند، نه نام نسخه SDK را در ده فایل.
پرسش‌های کوتاه
**روتر را خود مدل انتخاب کند؟** برای آزمایش داخلی شاید. برای محصول، ردیف جدول باید در کد و لاگ باشد. انتخاب پنهان مدل را نمی‌شود بازبینی کرد.
**چند مسیر در نسخه اول؟** دو تا کافی است: پیش‌فرض و یک تشدید با قاعده مشخص. مسیر سوم را وقتی اضافه کن که داده نشان دهد کلاس کار جدا است.
**اگر مدل پیش‌فرض فردا ضعیف شد؟** جدول را عوض کن، فراخوانی‌های پراکنده را نه. به همین دلیل نام مسیر باید پایدارتر از نام مدل باشد.