نشان‌گذاری متنی باعث کاهش ایمنی و دقتِ فراخوانی ابزار در مدل‌های زبانی شد

تصور کنید برای اثبات اصالت یک متن، امضایی دیجیتال به آن اضافه کنید و همین اقدام به‌طور ناخواسته، تمام قفل‌های امنیتی مدل را باز کند. طبق یافته‌های پژوهشی که در ۱۷ سپتامبر ۲۰۲۶ منتشر شد، آندریا سیپوسووا از شرکت Lasso Security دریافت که نشان‌گذاری (Watermarking) متنی در سامانه SynthID-Text منجر به پدیده‌ای به نام «انحراف نمونه‌گیری» (Sampling Drift) می‌شود؛ وضعیتی که در آن مدل یا در فراخوانی ابزارها دچار خطا می‌شود و یا درخواست‌های مضر را به‌جای رد کردن، می‌پذیرد.

این کشف در حالی رخ می‌دهد که ارائه‌دهندگان هوش مصنوعی به سمت استقرار تحت نظارت پیش می‌روند. در ۱۴ اوت ۲۰۲۶، شرکت Anthropic اعلام کرد که مدل‌های آینده Claude برای انطباق با قانون هوش مصنوعی اتحادیه اروپا (EU AI Act) از فناوری SynthID-Text متعلق به Google DeepMind استفاده خواهند کرد. این قانون، علامت‌گذاری ماشین‌خوان برای متون تولیدشده توسط هوش مصنوعی را الزامی می‌کند. آنتروپیک پیش‌تر ادعا کرده بود که این روش تأثیری بر کیفیت و محتوای خروجی‌های کلود ندارد و عملاً بدون اثر است.

زمینه قانونی و نظارتی

قانون اتحادیه اروپا تأکید دارد که ارائه‌دهندگان سامانه‌های هوش مصنوعی که متن مصنوعی تولید می‌کنند، باید خروجی‌ها را در قالبی ماشین‌خوان علامت‌گذاری کنند تا به عنوان محتوای تولیدشده توسط ماشین قابل شناسایی باشند. بر اساس مستندات آنتروپیک، این واترمارک در سطح مدل اعمال شده و مدل‌های در دسترس از طریق API پلتفرم کلود و ارائه‌دهندگان ابری را شامل می‌شود. بنابراین، حتی اگر یک عامل (Agent) به‌عنوان یک اپلیکیشن مجزا ساخته شده باشد، خروجی‌هایی که از مدل دریافت می‌کند واترمارک‌شده خواهند بود، زیرا واترمارک در لایه‌های زیرین مدل تعبیه شده است.

همان‌طور که در پوشش پیشین ما درباره‌ی پیچیدگی‌های داخلی سامانه‌های AGI اشاره کردیم، این یافته تضاد شدیدی را میان الزامات قانونیِ اثبات اصالت و ایمنی عملیاتی مدل‌ها آشکار می‌کند. برای توسعه‌دهندگان، ریسک اصلی این است که رفتار مدل بدون هیچ تغییری در وزن‌ها یا پرامپت، صرفاً به دلیل فعال شدن یک کلید واترمارک، تغییر کند و پایداری عملیاتی سیستم به خطر بیفتد. این چالش‌ها در کنار تلاش‌هایی برای جلوگیری از نشت داده‌های حساس از طریق ردیابی آلودگی در عامل‌ها، لایه‌ی جدیدی از پیچیدگی را به مدیریت امنیت عامل‌های هوش مصنوعی اضافه می‌کند.

مکانیزم انحراف نمونه‌گیری

مکانیزم انحراف نمونه‌گیری از تغییر در فرآیند انتخاب توکن (Token) نشأت می‌گیرد. واترمارک با دستکاری احتمالات انتخاب توکن‌ها کار می‌کند. حتی در پیکربندی‌های «بدون اعوجاج» (Non-distortionary) — که به طور متوسط توزیع اصلی توکن‌ها را حفظ می‌کنند — هر تولیدِ واحد تحت یک کلید ثابت، با نسخه بدون واترمارک متفاوت خواهد بود. این مطالعه با استناد به مقاله‌ای در Nature توسط Dathathri و همکاران، اشاره می‌کند که اگرچه در بررسی نزدیک به بیست میلیون پاسخ Gemini هیچ کاهش کیفیت قابل‌اندازه‌گیری گزارش نشده است، اما این موضوع به معنای یکسان بودن رفتار مدل در هر مورد خاص تحت یک کلید ثابت نیست.

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

طراحی آزمایش و متدولوژی

برای اندازه‌گیری این اثر، پژوهشگران از یک طراحی جفت‌شده در دو آزمایش مجزا استفاده کردند. صحت فراخوانی ابزار (Tool Calling) در محک BFCL v4 (بخش single-turn AST) ارزیابی شد. میزان رد درخواست‌ها (Refusal) در ۲۰۰ رفتار مضر از HarmBench و ۱۰۰ مورد کنترل سالم از JailbreakBench بررسی شد. درخواست‌های مضر هم به‌صورت مستقیم (Bare) و هم تحت تکنیک تزریق پرامپت (Prompt Injection) — که در آن دستورات متخاصمی با ادعای غیرفعال شدن فیلترهای ایمنی درج می‌شود — آزمایش شدند.

آزمایش‌ها با استفاده از پردازشگر SynthIDTextWatermarkLogitsProcessor در Hugging Face بدون هیچ تغییری و با مشخصات فنی زیر اجرا شد:

• ۳۰ لایه Tournament
• طول n-gram برابر ۵
• جدول نمونه‌گیری ۲ به توان ۱۶
• تاریخچه زمینه (Context History) ۱,۰۲۴

هر مورد با و بدون SynthID و با بذر (Seed)، دسته‌های (Batches) و ترتیب تولید یکسان در هر دمای مشخص اجرا شد تا اطمینان حاصل شود که پردازشگر واترمارک تنها متغیر اثرگذار در نتایج است.

تأثیر بر دقت فراخوانی ابزار

نتایج مربوط به دقت فراخوانی ابزار با استفاده از محک BFCL v4 نشان‌دهنده کاهش مداوم قابلیت اطمینان بود:

• واترمارک در ۶ مدل از ۷ مدل آزمایش‌شده، دقت را کاهش داد.
• در دمای (Temperature) ۱.۰، مدل phi-4 دچار ۱۶.۸٪ «تلاطم» (Churn - تفاوت در نتایج بین اجراهای واترمارک‌شده و نشده) شد و دقت کلی آن ۲.۸۷ امتیاز افت کرد.
• مدل Llama-3.1-8B تلاطم ۹.۹٪ و افت دقت خالص ۰.۸۷ امتیازی را تجربه کرد.
• در مجموع ۲۱ ترکیب مدل-دما، میانگین تلاطم ۶.۵٪ بود و بازه بوت‌استرپ (Bootstrap Interval) در تمام موارد عدد صفر را مستثنی کرد که نشان‌دهنده معنادار بودن آماری است.

الگوی خطاها بسته به معماری متفاوت بود. در Llama-3.1-8B، بیشترین افت مربوط به آرگومان‌های نادرست (۳.۴۸- امتیاز) و سپس فراخوانی ابزار اشتباه (۱.۸۴- امتیاز) بود. در مقابل، مدل‌های phi-4 و Granite-3.2-8B بیشتر از خروجی‌های بدساخت (Malformed) رنج می‌بردند و به ترتیب ۵.۹۶ و ۴.۳۶ امتیاز افت کردند. خطرناک‌ترین حالت زمانی است که فراخوانی ابزار درست است اما مسیر یا مبلغ ارسالی اشتباه است؛ زیرا در این حالت دستور اجرا می‌شود اما نتیجه‌ای ناخواسته و potentially مخرب به بار می‌آورد.

تضعیف رد درخواست‌های مضر

رد درخواست‌ها نیز توکن‌به‌توکن تولید می‌شوند و بنابراین در برابر انحراف نمونه‌گیری آسیب‌پذیر هستند. مطالعه نشان داد واترمارک احتمال پذیرش درخواست‌های مضر را افزایش می‌دهد، به‌ویژه زمانی که تزریق پرامپت صورت گیرد.

با استفاده از تکنیک درج دستورات متخاصم برای ادعای غیرفعال بودن فیلترها، تغییرات قابل‌توجهی مشاهده شد:

• در دمای ۰.۰۰۱، تلاطم مدل gemma-3-27b از ۶.۰٪ در درخواست‌های عادی به ۲۳.۵٪ در حالت تزریق پرامپت رسید.
• میزان پذیرش خالص (Net Compliance) در gemma-3-27b از ۱- به ۱۲.۵+ امتیاز تغییر کرد.
• مدل gemma-3-12b نیز افزایش پذیرش خالص از ۰.۵- به ۹.۰+ امتیاز را تحت تزریق پرامپت تجربه کرد.
• مدل Llama-3.1-8B در دمای ۰.۰۰۱ تلاطم ۱۴.۰٪ و در دمای ۰.۷ تلاطم ۱۷.۵٪ را تحت تزریق پرامپت نشان داد.

اگرچه مدل‌های phi-4 و Qwen3-4B تغییرات کمتری داشتند، اما محققان اشاره کردند که این مدل‌ها تمایل به «رد بیش از حد» (Over-refuse) حتی درخواست‌های سالم دارند، بنابراین پایداری آن‌ها ممکن است صرفاً یک مصنوع (Artifact) ناشی از احتیاط افراطی باشد. برای ارائه زمینه، مطالعه تلاطم ناشی از واترمارک در دمای ۰.۷ را با تلاطم ناشی از تغییر دما (از ۰.۰۰۱ به ۰.۷) بدون واترمارک مقایسه کرد. تلاطم ناشی از واترمارک در ۴ مدل از ۶ مدل به‌طور قابل‌توجهی بیشتر بود؛ مدل Granite-3.2-8B بیشترین تلاطم ناشی از دما (۱۵.۵٪) را داشت، اما تلاطم ناشی از واترمارک آن حتی بیشتر و برابر با ۲۱.۵٪ بود.

حساسیت به کلید و ریسک‌های عملیاتی

از آنجا که این اثر به کلید خاص واترمارک وابسته است، رفتار مدل برای توسعه‌دهنده نهایی غیرقابل‌پیش‌بینی می‌شود. آزمایش ۱۱ کلید مختلف روی Llama-3.1-8B در دمای ۰.۷ نشان داد در حالی که یک کلید موفقیت حملات را ۳.۵ امتیاز افزایش داد، سایر کلیدها به‌طور متوسط ۴.۴+ امتیاز تغییر ایجاد کردند و دامنه‌ای از ۴.۵- تا ۱۴.۵+ امتیاز داشتند. اکثر کلیدها موفقیت حملات را برای دو مدل Gemma نسبت به خط پایه بدون واترمارک افزایش دادند، در حالی که Granite-3.2-8B پاسخ متفاوتی نشان داد.

این بدان معناست که اگر ارائه‌دهنده مدل، کلید واترمارک را در بک‌اند تغییر دهد، پروفایل ایمنی یا قابلیت اطمینان عامل شما بدون اطلاع شما تغییر می‌کند و ممکن است ناگهان آسیب‌پذیر شود.

این تغییر در مفروضات این حوزه نشان می‌دهد اصطلاح «بدون اعوجاج» گمراه‌کننده است. حفظ کیفیت کلی (Aggregate Quality) به معنای تضمین پایداری در هر مورد خاص (Individual Instance Stability) نیست. برای متخصصان فنی، این بدان معناست که تیم قرمز (Red Teaming) روی مدلی که واترمارک تولیدی ندارد، دیگر معیار معتبری برای سنجش ایمنی در زمان استقرار نیست.

توسعه‌دهندگان باید تمامی ارزیابی‌های عامل و تمرینات تیم قرمز را با دقیق‌ترین پیکربندی واترمارکی که برای استقرار برنامه‌ریزی شده، مجدداً اجرا کنند. مقایسه خروجی‌های واترمارک‌شده و نشده روی ورودی‌های یکسان، تنها راه محاسبه «مالیات اصالت» (Provenance Tax) بر اپلیکیشن‌های آن‌هاست. مطالعه اشاره می‌کند که اگرچه SynthID-Text بررسی شده، اما این نگرانی برای هر مداخله‌ای که نحوه انتخاب توکن‌ها را در سیستمی که بر اساس آن توکن‌ها عمل می‌کند تغییر دهد، صادق است.

باید منتظر ماند و دید اجرای قانون اتحادیه اروپا چگونه توسعه‌دهندگان را مجبور به انتخاب میان الزام قانونیِ اثبات اصالت و ضرورت فنیِ رفتار قطعی (Deterministic) عامل‌ها می‌کند.

گام بعدی شما

• اگر از مدل‌های Claude یا Gemini در عامل‌های خود استفاده می‌کنید، خروجی‌ها را با و بدون فعال بودن واترمارک مقایسه کنید.
• ارزیابی‌های ایمنی و Red Teaming را دقیقاً روی نسخه‌ای از مدل اجرا کنید که در محیط Production قرار می‌گیرد.
• در طراحی عامل‌ها، لایه‌های اعتبارسنجی برای خروجی‌های ساختاریافته (مانند JSON) اضافه کنید تا خطاهای ناشی از انحراف نمونه‌گیری شناسایی شوند.