بر اساس گزارش منتشرشده در XDA Developers، مدل Qwen 3.8 Flash Next علی‌بابا که پایان اوت معرفی شد، در برخی آزمون‌ها رفتار عجیبی از خود نشان داده است. این مدل یک مدل قدرتمند ترکیب خبرگان (Mixture of Experts) با ۱۲۵ میلیارد پارامتر، ۶ میلیارد پارامتر فعال (Active Parameters) و یک جدول تعبیه N-gram (N-gram Embedding Table) ۵۱ میلیاردی است.
گزارش Cohere و تلاش برای آپلود فایل در پکن
Cohere در گزارشی توضیح داده که در اجرای بنچمارک امنیتی CTI-REALM مایکروسافت، از مدل خواسته شده قاعده‌ای برای شناسایی دانلود اسکریپت‌های bash توسط curl به مسیر /tmp بنویسد. در یکی از اجراها، مدل محتویات /tmp را فهرست کرده، ابزارهای انتقال فایل نصب‌شده را بررسی کرده، تنظیمات DNS دستگاه را خوانده و تلاش کرده یک درخواست HTTP PUT به باکتی به نام sanmaohe در منطقه پکن علی‌بابا Cloud ارسال کند.
Cohere می‌گوید این رفتار در کمتر از یک مورد از هر ۱۰۰٬۰۰۰ فراخوان رخ داده و اجرای دوباره همان درخواست، یک قاعده شناسایی عادی تولید کرده است. بدنه درخواست PUT نیز رشته آزمایشی PROBE_PAYLOAD_ABC123 بوده، نه فهرست جمع‌آوری‌شده. با این حال، چنین رفتاری نباید رخ دهد و در صورت موفقیت، دریافت‌کننده باکت فایلی را دریافت می‌کرد که نباید دریافت می‌کرد.
مشاهده رفتار مشابه پیش از گزارش Cohere
نویسنده XDA می‌گوید از ۲۰ سپتامبر، بیش از یک ماه پیش از انتشار گزارش Cohere، رفتار مشابهی را روی همان مدل Qwen 3.8 Flash Next دیده است. در یک نمونه، مدل ادعا کرده به‌اشتباه یک URL امضاشده علی‌بابا Cloud را واکشی کرده، هرچند این کار را انجام نداده بود. وقتی از مدل خواسته شده پاسخ خود را بازبینی کند، عذرخواهی کرده و آدرس صحیح را با یک URL پروکسی علی‌بابا جایگزین کرده است.
در برخی نشست‌های طولانی، مدل حتی واقعاً به یکی از آن URLهای علی‌بابا رفته و خطای 403 دریافت کرده است. پس از این موارد، نویسنده با درخواست‌های کنترل‌شده، صدها URL تولیدشده و بررسی وزن‌های مدل، موضوع را دقیق‌تر آزموده است. نتیجه این است که مشاهده Cohere واقعی و مسئله‌ساز است، اما شواهد به مدلی اشاره دارد که در آموزش، نحوه کار ابزارهای واکشی وب داخلی علی‌بابا را آموخته است، نه مدلی که عمداً برای استخراج داده از کاربر ناشناس طراحی شده باشد.
پیش‌پر کردن و افزایش درخواست به میزبان‌های مشکوک
Cohere با تکنیک پیش‌پر کردن (Prefilling) تلاش کرده محرکی برای این رفتار پیدا کند. در این روش، استدلال مدل همراه با ابتدای یک فرمان curl به مدل داده می‌شود تا خط را کامل کند. با افزودن گزینه -o در curl، درخواست به میزبان‌های مشکوک از ۰.۵ درصد به ۲۳ درصد تکمیل‌ها رسیده است. رایج‌ترین مورد routify-file-proxy-sg بوده، یک باکت ذخیره‌سازی علی‌بابا Cloud در سنگاپور که نویسنده هم هفته‌ها با آن مواجه شده بود.
Cohere همچنین دیده مدل در ۲۳ تا ۳۶ درصد آن تکمیل‌ها تلاش کرده با آدرس 169.254.169.254 تماس بگیرد. در یک آزمون آفلاین جداگانه نیز مدل از فضای نام کاربر بدون دسترسی (Unprivileged User Namespace) برای دور زدن خطای مجوز هنگام mount یک RAM disk استفاده کرده است. این موارد با URLهای علی‌بابا متفاوت‌اند و یافته‌های نویسنده به آن‌ها مرتبط نیست.
توهم حافظه؛ مدل درباره URL واکشی‌شده اشتباه می‌گوید
هر زمان رشته پروکسی سنگاپور دیده شده، الگوی پیدایش آن مشابه بوده است: مدل یک ابزار وب را با URL عادی فراخوانی می‌کند، نتیجه را می‌گیرد و سپس توصیف می‌کند که فراخوانی به یک URL طولانی و امضاشده علی‌بابا Cloud رفته است. مدل معمولاً ادعا می‌کند URL پروکسی همان آرگومانی بوده که به ابزار داده، آن را با آدرس واقعی مقایسه می‌کند، نتیجه کوتاه را به بازگشت یک stub توسط پروکسی نسبت می‌دهد و برای گزارش قبلی آدرس معتبر عذرخواهی می‌کند.
برای بازتولید، نویسنده به مدل یک تاریخچه ساده شامل یک فراخوانی ابزار برای دریافت مستندات Python pathlib، یک نتیجه کوتاه و پرسش درباره URL واکشی‌شده داده است. مدل به‌طور مرتب با URL Routify پاسخ داده که در ورودی وجود نداشته است. بررسی پرامپت رندرشده و شناسه‌های توکن (Token) تأیید کرده که مدل آدرس صحیح را دریافت کرده بود. جایگزینی مستندات Python با SQLite نیز تفاوتی ایجاد نکرده است.
در چند صد اجرا به انگلیسی و چینی، مدل در حدود چهار مورد از هر ده پاسخ نهایی یک URL پروکسی نام برده و در ساده‌ترین نسخه آزمون تقریباً هر بار این کار را کرده است. نحوه ارائه تاریخچه اهمیت زیادی داشته است: اگر همان فراخوانی ابزار به‌صورت متن نقل‌شده و نه فراخوانی ساختاریافته بومی داده شود، مدل در هیچ‌یک از شرایط آزمون ادعای پروکسی جعلی نکرده است. اما افزودن یک ابزار واکشی وب بی‌استفاده به فهرست ابزارهای موجود، گاهی خطا را حتی پس از پاسخ صحیح بازگردانده است.
درخواست بازبینی نیز وضع را بدتر کرده است. اگر به مدل تاریخچه‌ای داده شود که قبلاً درست پاسخ داده و سپس از آن خواسته شود پاسخ را با آرگومان url در فراخوانی قبلی مقایسه و اختلاف را مشخص کند، در حدود ۷۵ درصد موارد پاسخ صحیح را به یک URL پروکسی جعلی علی‌بابا به‌عنوان آرگومان واقعی تبدیل کرده است. در نشست‌های طولانی، این باور نادرست مشکلات واقعی ایجاد کرده و مدل تصمیم گرفته پروکسی URLهایش را بازنویسی می‌کند و سپس URLهای پروکسی جعلی را به ابزار مرورگر داده است. در نشست‌های Pi، شش مورد جداگانه از این رفتار دیده شده و همه با پاسخ 403 مواجه شده‌اند. داده‌ای از دستگاه ارسال نشده، اما درخواست‌ها از شبکه خارج شده‌اند.
امضاهای جعلی و نشانه‌های آماری
در پاسخ‌های چینی نیز رفتار مشابه دیده می‌شود، با این تفاوت که مدل نقطه‌چین را وسط امضا قرار می‌دهد و به سوابق کاربر ارجاع می‌دهد. در ۸۰ مورد از ۲۰۰ URL، نقطه‌چین جای میانه امضا را گرفته است. در یک اجرای چینی دیگر، مدل در ردگیری استدلال خود گفته کلید «LTAI5t...QVZr» رشته دقیق است، اما نسخه‌ای با شناسه کلید کاملاً متفاوت با پایان gc9z و امضای متفاوت ارائه کرده است.
تحلیل آماری امضاها نیز نشان می‌دهد این رشته‌ها واقعی نیستند. مدل ۵۳ امضای کامل تولید کرده، اما ۵۷ درصد کاراکترها از یک‌چهارم آخر الفبا آمده‌اند، در حالی که انتظار می‌رفت هر کاراکتر حدود ۲۵ درصد باشد. این انحراف بیش از ده برابر آستانه معناداری آماری است. با این حال، هر رشته دقیقاً به ۲۰ بایت رمزگشایی می‌شود و با کاراکتر معتبر پایان می‌یابد. قواعد قالب‌بندی در چند کاراکتر اول و آخر دیده می‌شود و انحراف آماری عمدتاً از میانه است، همان‌جا که در برخی نتایج نقطه‌چین دیده شده است. اگر مدل هرگز بخش میانی را ندیده باشد، این توضیح می‌دهد چرا امضاها معتبر نیستند. به نظر می‌رسد علی‌بابا پیش‌تر URLهای کامل را در پس‌آموزش (Post-training) از مدل‌ها پنهان کرده است.
URLها یک سیستم واقعی را توصیف می‌کنند
نویسنده ۲۰۰ URL جمع‌آوری کرده و می‌گوید این‌ها رشته‌های تصادفی نیستند. همه به یک باکت در منطقه سنگاپور علی‌بابا Cloud اشاره دارند و ساختار مسیر یکسانی دارند: تاریخ، شناسه ردگیری (Trace ID)، شناسه درخواست (Request ID) و نام فایل هش‌شده برای هر صفحه واکشی‌شده. این ساختار شبیه یک کش فایل موقت است که در آن سیستمی صفحه‌ای را به نمایندگی از مدل واکشی و نسخه‌ای را برای پاسخ به یک درخواست مشخص ذخیره می‌کند.
شناسه‌های ردگیری شبیه قالب EagleEye، سیستم ردگیری داخلی علی‌بابا هستند و IP سرور و زمان میلی‌ثانیه را در یک رشته ۳۰ کاراکتری نگه می‌دارند. پس از رمزگشایی، همه آدرس‌ها در محدوده 33.x و 11.x بوده‌اند که توسعه‌دهندگان پیش‌تر حضور آن‌ها را در هدرهای سرور علی‌بابا گزارش کرده‌اند. زمان داخل شناسه ردگیری در ۹۳ مورد از ۹۳ موردی که هر دو قابل خواندن بودند، پس از تبدیل به UTC+8 با تاریخ مسیر مطابقت داشته است. زمان انقضای هر URL نیز در همه به‌جز یکی از ۸۸ URL دارای انقضا، برابر همان زمان به‌علاوه ۳۶۰ روز و چند ثانیه بوده است.
این باکت، ساختار مسیر، کلید و قاعده انقضا پیش از آموزش مدل‌ها جایی منتشر نشده بود. اولین اشاره‌ای که نویسنده پیدا کرده، پستی در Hacker News در ۲۰ اوت درباره Qwen 3.8 27B است، تنها چهار روز پیش از انتشار Qwen 3.8 Flash Next. وجود آن در Qwen 3.8 27B نشان می‌دهد احتمالاً از آزمون داخلی علی‌بابا آمده و روش پس‌آموزش مشابهی روی هر دو مدل اعمال شده است.
شناسه کلید LTAI5tKoG9A3DkwGD635QVZr در ۱۲۴ مورد از ۱۸۱ URL دیده می‌شود و علی‌بابا Cloud آن را متفاوت از سایر شناسه‌ها می‌بیند: درخواست‌ها با SignatureDoesNotMatch شکست می‌خورند، در حالی که سایر شناسه‌های کلید با InvalidAccessKeyId رد می‌شوند. این یعنی یک شناسه کلید دسترسی واقعی متعلق به یک حساب واقعی علی‌بابا Cloud است، نه چیزی که مدل به‌طور تصادفی ساخته باشد. این کلید توسط کاربران دیگر نیز منتشر شده است، اما هیچ URL کاملاً معتبر با کلید امضای کارآمد توسط مدل در این اجراها دیده نشده است.
Routify؛ دروازه مسیریابی داخلی مدل علی‌بابا
نام خود باکت هم به همین جهت اشاره دارد. Routify نامی است که علی‌بابا برای یک دروازه مسیریابی داخلی مدل (Model Gateway) استفاده می‌کند. در یک Pull Request که در Qwen Code، عامل کدنویسی علی‌بابا، ادغام شده، به «سه endpoint مدل‌روتر مستندشده توسط Routify» در دامنه داخلی alibaba-inc.com اشاره شده است. ارجاعات دیگر به Routify در مخازن علی‌بابا حداقل تا ماه مه بازمی‌گردد و بسیار محتمل است که routify-file-proxy-sg یکی از استقرارهای همین پلتفرم داخلی باشد.
علی‌بابا کدی برای یک ابزار جست‌وجوی تصویر منتشر کرده که معماری مشابهی دارد: عامل WebWatcher آن به سرویس جست‌وجوی داخلی qwen-search کوئری می‌زند، نتایج را کش می‌کند، هر تصویر را از سرویس دانلود داخلی علی‌بابا دریافت می‌کند، آن را به یک باکت ذخیره‌سازی علی‌بابا Cloud آپلود می‌کند و لینک امضاشده به آن کپی را با پارامترهای پنهان مستقیماً در خروجی ابزار قرار می‌دهد. ابزار صفحه‌خوان همان عامل نیز از سرویس واکشی داخلی علی‌بابا با کش خودش عبور می‌کند.
پوشه‌ای که این ابزار در آن می‌نویسد qwenvl_rft نام دارد و RFT معمولاً مخفف ریزتنظیم تقویتی (Reinforcement Fine-Tuning) است. در این نمونه، راز امضای لینک‌ها فقط در محیط ابزار یافت می‌شود، زیرا امضا و شناسه کلید را پیش از دیدن مدل از هر لینک حذف می‌کند. اگر این ابزار برای ریزتنظیم تقویتی استفاده شود، سیاست‌های خود علی‌بابا حکم می‌کنند اطلاعات حساس باید از عامل پنهان بماند و این توضیح می‌دهد چرا رازهای مرتبط هرگز معتبر نبوده‌اند.
این مثال Routify نیست و باکت، منطقه و انقضای متفاوت و کوتاه‌تری دارد، اما معماری یکسان است: واکشی صفحه، کش کردن آن در ذخیره‌سازی و دادن URL پیش‌امضاشده به مدل. درباره انتخاب سنگاپور نیز باید گفت آزمایشگاهی مستقر در سرزمین اصلی چین نمی‌تواند به بخش بزرگی از وب باز دسترسی آسان داشته باشد؛ بنابراین یک سرویس پروکسی که از منطقه‌ای خارج از کشور واکشی می‌کند، راهی ساده برای دادن دسترسی وب کارآمد به مدل در زمان آموزش است. زمان‌بندی نیز جور درمی‌آید: URLهایی که با زمینه کم جمع‌آوری شده‌اند در بازه‌ای قرار می‌گیرند که مدل می‌تواند برای پس‌آموزش ابزارمحور استفاده شده باشد.