بحران هویت مدل‌های هوش مصنوعی؛ ریسک پنهان جایگزینی مدل در لایه‌ی استنتاج

تصور کنید برای یک مدل پیشرفته و لبه (Frontier Model) هزینه پرداخت می‌کنید، اما در واقع خروجی‌های یک مدل ارزان‌تر، کوانتیده شده یا محدود شده را دریافت می‌کنید بدون اینکه متوجه شوید. این یک نقص فنی یا باگ ساده نیست، بلکه یک تغییر ساختاری در نحوه استقرار استنتاج (Inference) توسط شرکت‌هایی مثل Anthropic، Cursor و OpenRouter است.

در محیط‌های عملیاتی، نام مدل در یک درخواست API دیگر یک مشخصات فنی دقیق و الزام‌آور نیست، بلکه تنها به یک «راهنما» یا Hint تبدیل شده است. این وضعیت شکافی خطرناک میان آنچه توسعه‌دهنده در قرارداد می‌بندد و وزن‌های واقعی (Weights) که داده‌ها را پردازش می‌کنند، ایجاد می‌کند. این چرخش زمانی رخ می‌دهد که صنعت به سمت «روترهای» بهینه‌ساز هزینه حرکت می‌کند که تأخیر (Latency) و مخارج را بر دقت و پایبندی سخت‌گیرانه به مدل ترجیح می‌دهند.

مکانیسم‌های جایگزینی

هویت مدل‌ها در حال حاضر در سه محور متمایز متلاشی می‌شود: جایگزینی، تخریب و رانش. این فرآیندها اغلب در لایه API رخ می‌دهند و برای کاربر نهایی نامرئی هستند، مگر آنکه اشیاء پاسخ (Response Objects) را با دقت و وسواس بررسی کنند.

• جایگزینی (Substitution): زمانی رخ می‌دهد که یک طبقه‌بندی‌کننده (Classifier)، درخواست را به معماری کاملاً متفاوتی می‌فرستد. به عنوان مثال، Anthropic مستند کرده است که از اول ژوئیه ۲۰۲۶، درخواست‌های مسدود شده به Claude Fable 5 به‌طور خودکار به Opus 4.8 هدایت می‌شوند. اگرچه Anthropic در شیء پاسخ به کاربر اطلاع می‌دهد، اما درخواست اولیه برای مدل دیگری ارسال شده بود. در این سیستم، درخواست پیش از شروع تولید متن طبقه‌بندی می‌شود؛ اگر با یک دسته‌بندی حساس مطابقت داشته باشد، به مجموعه متفاوتی از وزن‌ها سپرده می‌شود.
• تخریب (Degradation): در این حالت از همان نام مدل استفاده می‌شود، اما سرویس‌دهی از طریق دقت کاهش‌یافته یا همان کوانتایزیشن (Quantization) صورت می‌گیرد. OpenRouter پارامتر کوانتایزیشن را دقیقاً به این دلیل نمایش می‌دهد که نقاط انتهایی کوانتیده ممکن است در برخی پرامپت‌های خاص، عملکرد ضعیف‌تری داشته باشند. به‌طور پیش‌فرض، درخواست‌ها بین ارائه‌دهندگانی که بر اساس قیمت مرتب شده‌اند، توزیع می‌شوند. نام در درخواست ثابت می‌ماند، اما محاسبات ریاضی در سمت سرور تغییر می‌کند.
• رانش (Drift): استفاده از نام‌های مستعار مانند latest- که در آن وزن‌ها به‌طور مخفیانه و بدون اطلاع کاربر به‌روزرسانی می‌شوند. هر نام مستعار latest- در محیط عملیاتی مانند یک وابستگی بدون نسخه (Unversioned Dependency) عمل می‌کند که در مانیفست‌های استاندارد بسته‌های نرم‌افزاری کاملاً غیرقابل پذیرش است.

ظهور روترهای هوش مصنوعی

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، کنترل روی لایه‌های میانی تعیین‌کننده است. این رویکرد با استراتژی‌های جدید مسیریابی لایه‌ای همسو است که هدف آن‌ها کاهش هزینه‌های عملیاتی بدون حذف کامل کیفیت است. شرکت Cursor اخیراً در ۲۲ ژوئیه ۲۰۲۶ ابزاری به نام Router را عرضه کرد. این سیستم از یک طبقه‌بندی‌کننده استفاده می‌کند که روی بیش از ۶۰۰ هزار درخواست واقعی آموزش دیده است تا پیش از انتخاب بهترین مدل، زمینه (Context)، پیچیدگی و دامنه هر پرسش را تحلیل کند.

بر اساس گزارش‌های دسترسی زودهنگام از سه حساب کاربری، این مسیریابی می‌تواند نسبت به ارسال همه درخواست‌ها به Opus 4.8، حدود ۳۰ تا ۵۰ درصد در هزینه‌ها صرفه‌جویی کند. با اینکه Cursor قوانین مسیریابی خود را منتشر کرده است، اما نام مدل‌های خاصی که به هر نوع وظیفه اختصاص یافته‌اند را فاش نکرده است.

از منظر مهندسی، این رویکرد درست و منطقی است. Cursor روتر خود را در یک تست آنلاین A/B ارزیابی کرد و «رضایت کاربر» را به عنوان سیگنال پاداش بهینه کرد. اما از منظر قراردادی، «رضایت» با «تطابق با مشخصات» یکی نیست. کاربری که متوجه جابجایی مدل نمی‌شود، گواهی بر کیفیت روتر است، اما گواهی بر تحویل مشخصات فنی مورد توافق نیست.

تضاد در حقوق تجاری

این وضعیت یک پرسش بنیادی در حقوق تجاری ایجاد می‌کند: آیا توصیف مدل، بخشی از شرایط معامله بود؟ اگر یک فراخوانی API مانند فروش کالا بود، پاسخ ساده بود. ماده ۲-۳۱۳(۱)(b) قانون UCC آمریکا، هر توصیفی از کالا که بخشی از اساس معامله باشد را یک ضمانت صریح تطابق (Express Warranty of Conformity) می‌داند. به همین ترتیب، قانون فروش کالاهای هند (۱۹۳۰) در ماده ۱۵ از دکترین «فروش بر اساس توصیف» برای رسیدن به همین نتیجه استفاده می‌کند.

اما APIهای استنتاج معمولاً به عنوان «نرم‌افزار به عنوان سرویس» (SaaS) میزبان شناخته می‌شوند. این موضوع نزاع را از قوانین ضمانت کالا به قراردادهای حقوق مشترک (Common-law Contract) می‌برد، جایی که نتیجه به مستندات و جزئیات چانه‌زنی‌ها بستگی دارد. ابهام در اینجا بسیار زیاد است: قراردادهای سازمانی قیمت را به ازای هر مدل تعیین می‌کنند، کارت‌های مدل (Model Cards) مختص هر مدل هستند و اسناد انطباق، نسخه‌های خاصی را نام می‌برند. با این حال، لایه مسیریابی با این نام‌ها تنها به عنوان «راهنما» برخورد می‌کند.

اگر یک قرارداد، یک شناسه مدل (Model ID) خاص را تثبیت کرده باشد (به جای تعریف قابلیت)، رفتار مدل می‌تواند به‌طور مادی تغییر کند بدون اینکه هیچ خطایی صادر شود. اگر طرفین بر سر یک «نام» معامله کرده باشند، جایگزینی مدل یک نقض قرارداد است. اما اگر آن‌ها بر سر یک «قابلیت» معامله کرده باشند، جایگزینی پذیرفتنی است؛ هرچند این کار مستلزم تعریفی از «کیفیت لبه» (Frontier Quality) است که بتواند در برابر بازجویی‌های دادگاه دوام بیاورد—تعریفی که هنوز وجود ندارد.

ریسک‌های قانونی و اثباتی

شدیدترین اثر این موضوع در دادگاه‌ها دیده می‌شود. طبق قواعد فدرال شواهد (FRE) ۹۰۱(b)(9)، برای احراز اصالت یک خروجی، باید فرآیند یا سیستمی که آن را تولید کرده توصیف شود و نشان داده شود که آن فرآیند نتیجه‌ای دقیق تولید می‌کند. مواد ۹۰۲(۱۳) و ۹۰۲(۱۴) نیز اجازه می‌دهند سوابق تولید شده توسط سیستم‌های الکترونیکی یا داده‌های تأیید شده با هش (Hash)، از طریق گواهینامه خود-احراز شوند.

قانون شواهد هند (Bharatiya Sakshya Adhiniyam, 2023) در ماده ۶۳ کار مشابهی انجام می‌دهد و پذیرش یک رکورد الکترونیکی را مشروط به گواهینامه‌ای می‌کند که رکورد و نحوه تولید آن را شناسایی کند. تمام این مقررات فرض می‌کنند که شما می‌توانید سیستم را به‌طور دقیق نام ببرید.

تصور کنید وکیلی یک استناد جعلی را در یک لوایح دادگاهی ارائه دهد. روند جریمه‌ها آغاز می‌شود و دادگاه می‌پرسد کدام مدل این استناد را تولید کرده است؟ لاگ‌های شرکت حقوقی می‌گوید Fable 5، اما لاگ‌های ارائه‌دهنده نشان می‌دهد یک طبقه‌بندی‌کننده فعال شده و Opus 4.8 پاسخ داده است. یا در حالتی دیگر، درخواست از طریق یک روتر IDE عبور کرده که مدلی را انتخاب کرده است که شرکت دیگر نمی‌تواند آن را بازسازی کند، با دقتی که هرگز مشخص نکرده بود و روی نسخه‌ای که مدت‌هاست بازنشسته شده است. در اینجا زنجیره custody در نقطه توزیع (Dispatcher) می‌شکند، نه در خود مدل.

این منجر به یک «مشکل کشف» (Discovery Problem) می‌شود. تصمیمات مسیریابی اکنون به واقعیت‌های تعیین‌کننده تبدیل شده‌اند. این بدان معناست که لاگ‌های طبقه‌بندی‌کننده روتر، تخصیص‌های مدل به ازای هر درخواست و متادیتای دقت، باید از فروشندگانی استخراج شوند که در حال حاضر هیچ تعهدی به نگهداری آن‌ها ندارند.

طیف افشای اطلاعات

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

در مقابل، OpenRouter تغییرات کوانتایزیشن را در مستندات خود قرار داده است. چون این یک تنظیم opt-out (خروج اختیاری) است و مسیر پیش‌فرض ارزان‌ترین مسیر است، رگولاتورها ممکن است آن را یک «الگوی تاریک» (Dark Pattern) ببینند که در سایر بخش‌های مصرف‌کننده رایج است.

طبق دکترین فریب FTC، یک بازنمایی زمانی قابل پیگرد است که «مادی» باشد و احتمالاً مصرف‌کننده معقول را گمراه کند. ادعاهای عملکرد عینی نیز نیازمند مبنایی معقول هستند. برخی تحلیلگران اشاره کرده‌اند که ادعاهایی مانند «۶۰ درصد ارزان‌تر، بدون افت کیفیت» بدون ارائه متدولوژی منتشر شده بیان می‌شوند.

همچنین ریسک قانون رقابت وجود دارد. پیش‌نویس‌های پژوهشی درباره «مسدودسازی عمودی» در بازارهای استنتاج، چارچوبی رفتاری بر اساس شفافیت مسیریابی، برابری کیفیت سرویس و عدم تبعیض به سبک FRAND پیشنهاد می‌کنند. روتری که همزمان فروشنده مدل‌های دست اول است، ریسک تبدیل شدن به یک موتور «ترجیح‌دهنده خود» (Self-preferencing Engine) را دارد.

به سوی هویت قابل تصدیق

قراردادهای ایستا نمی‌توانند رویدادهای زمان اجرا (Runtime) را حل کنند. صنعت به تغییر به سمت «هویت قابل تصدیق مدل» نیاز دارد. این شامل یک تاییدیه امضا شده است که با هر پاسخ بازگردانده شود و خروجی را به یک چندتایی (Tuple) از موارد زیر متصل کند:

• شناسه مدل سرویس‌دهنده
• هش وزن‌ها (Weights Hash)
• سطوح دقت (Precision Levels)
• هش پرامپت سیستمی

چنین سیستمی به یک کلید متکی است که ریشه در تایید سخت‌افزاری دارد، چیزی که پلتفرم‌های GPU با محاسبات محرمانه (Confidential Computing) اکنون از آن پشتیبانی می‌کنند. زیربنای این سیستم نیمه‌کاره است: اشیاء پاسخ در حال حاضر نام مدل سرویس‌دهنده را حمل می‌کنند. آنچه کم است، ویژگی‌ای است که آن را از نظر قانونی مفید کند: اینکه نتوان آن را به دروغ ادعا کرد و خریدار بتواند بدون اعتماد به فروشنده، آن را تایید کند.

یک هش در هدر پاسخ، دقیقاً همان کاری را برای هویت مدل انجام می‌دهد که ماده ۹۰۲(۱۴) FRE برای داده‌های کپی‌شده انجام می‌دهد—یعنی تبدیل یک پرسش فاکت مورد مناقشه به یک گواهینامه. مسیریابی مهندسی خوبی است، اما در حال حاضر یک جایگزینی ثبت‌نشده، بدون امضا و غیرقابل تایید از چیزی است که برای آن معامله شده است. شناسه مدل به‌طور مخفیانه به یک شناسه قانونی تبدیل شده است؛ زمان آن رسیده که تصمیم بگیریم این شناسه واقعاً چه چیزی را شناسایی می‌کند.

گام بعدی شما

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

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.