اگر امروز برای مدیریت هزینه‌های استنتاج مدل‌های مختلف یک مسیریاب (Router) طراحی می‌کنید، احتمالاً یک حفره امنیتی بزرگ در سیستم خود ایجاد کرده‌اید. حقیقت این است که مسیریابی در هوش مصنوعی، پیش از آنکه یک مسئله مالی باشد، یک تصمیم حیاتی درباره جابه‌جایی داده‌ها است.
به نقل از گزارشی که در ۸ اوت ۲۰۲۶ در وب‌سایت dev.to منتشر شد، نادیده گرفتن این تفاوت منجر به ایجاد ریسک‌های حقوقی شدید می‌شود؛ چراکه استفاده از یک مدل ارزان‌تر زمانی بی‌معنی است که آن مدل اصلاً اجازه دسترسی به داده‌های حساس را نداشته باشد. همان‌طور که در تحلیل‌های قبلی ما درباره امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به لایه‌های بهینه‌سازی بدون در نظر گرفتن حریم خصوصی، بزرگ‌ترین نقطه ضعف زیرساخت‌های فعلی است. در واقع، استفاده از روترهای ساده بدون در نظر گرفتن پیچیدگی‌های عملیاتی می‌تواند منجر به افزایش دوبرابری هزینه‌های عامل‌های هوشمند شود.
اکثر تیم‌های توسعه در حال حاضر درخواست‌ها را بر اساس قابلیت مدل، تأخیر (Latency) — که شبیه زمان انتظار برای رسیدن غذا در رستوران است — و محدودیت‌های نرخ ارسال مسیریابی می‌کنند. اما یک درخواست به هوش مصنوعی زاینده (Generative AI) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — صرفاً یک پرامپت ساده نیست؛ بلکه مجموعه‌ای از جزئیات مشتری، زمینه‌های تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند — و کدهای منبع است.
به همین دلیل، هر تصمیم مسیریابی در واقع یک تصمیم امنیتی است. شرکت VectorNode برای حل این مشکل، سلسله‌مراتبی را پیشنهاد می‌کند که با طبقه‌بندی داده‌ها آغاز می‌شود. این رویکرد در راستای مدیریت بارهای کاری بر اساس ریسک و استدلال است که جایگزینی بهینه‌تری برای مدل‌های تک‌رویکردی محسوب می‌شود. در این مدل، درخواست‌ها باید به چهار دسته تقسیم شوند:
- عمومی (Public): محتوایی که برای استفاده خارجی است.
- داخلی (Internal): دانش غیرعمومی شرکت.
- محرمانه (Confidential): سوابق مشتریان، قراردادها و کدهای منبع.
- محدود (Restricted): اطلاعات بسیار حساس با کنترل دسترسی شدید.
بر اساس مستندات این رویکرد، مسیریاب ابتدا باید مدل‌های تاییدشده برای آن کلاس داده را فیلتر کند. تنها پس از عبور از این دروازه امنیتی است که سیستم می‌تواند مدل‌ها را از نظر هزینه و سلامت مقایسه کند. این تغییر، مسیریابی را از یک مسئله انتخاب ساده به یک سیاست عملیاتی تبدیل می‌کند.
داده‌ها اغلب در اعماق گردش‌کار پنهان هستند. برای مثال، یک درخواست RAG ممکن است شامل اسناد داخلی بازیابی‌شده باشد. چون مدل تمام زمینه (Context) را دریافت می‌کند، سیاست داده‌ای باید پیش از ارسال هرگونه تاریخچه گفتگو یا نتیجه بازیابی اعمال شود.
منطق جایگزینی (Fallback) نیز ریسک‌های جدی دارد. طبق گزارش‌ها، وقتی مسیر اصلی شکست می‌خورد، برنامه‌ها به‌طور خودکار درخواست را به مدل دیگری می‌فرستند. اگر مدل جایگزین برای آن کلاس داده تاییدنشده باشد، یک نشت امنیتی رخ می‌دهد. این موضوع ما را با ریسک‌های پنهان جایگزینی مدل در لایه‌ی استنتاج مواجه می‌کند که می‌تواند منجر به بحران هویت مدل‌ها شود. جایگزین‌های امن باید شامل مدل‌های تاییدشده کوچک‌تر یا ارجاع به نظارت انسانی باشند.
در این میان، پاک‌سازی داده‌ها (Redaction) می‌تواند پلی برای دسترسی به مدل‌های بیشتر باشد. با حذف صریح نام‌ها، ایمیل‌ها یا URLهای داخلی، یک درخواست می‌تواند برای طیف گسترده‌تری از مدل‌ها واجد شرایط شود. این فرآیند باید یک گام صریح در گردش‌کار باشد، نه یک فرض پیش‌فرض.
در نهایت، تیم‌ها باید تصمیمات سیاستی را ثبت کنند. یک گزارش خطا باید شامل پروفایل طبقه‌بندی داده، مسیرهای تاییدشده و وضعیت پاک‌سازی باشد. بدون این سوابق، شرکت نمی‌تواند ثابت کند که درخواست‌ها مطابق با سیاست‌های امنیتی بوده‌اند.
بهینه‌سازی هزینه هدفی درست است، اما باید بعد از تعریف مرزهای داده رخ دهد. بهترین مسیر، سریع‌ترین یا ارزان‌ترین نیست، بلکه امن‌ترین مسیری است که اجازه مدیریت آن داده را دارد.
گام بعدی شما
- معماری مسیریاب خود را بازبینی کنید و لایه طبقه‌بندی داده را پیش از لایه هزینه قرار دهید.
- برای هر کلاس داده (عمومی تا محدود)، فهرستی از مدل‌های تاییدشده (Allow-list) تهیه کنید.
- مکانیزم Fallback خود را بررسی کنید تا مطمئن شوید مدل جایگزین، سطح دسترسی داده را نقض نمی‌کند.
اما مدیریت این سیاست‌ها در مقیاس هزاران درخواست در ثانیه، چالش‌های سخت‌افزاری جدیدی ایجاد می‌کند — به تحلیل ما درباره بهینه‌سازی GPU در لایه‌های مسیریابی مراجعه کنید.
گفتگو