«حفاظ مستقل»؛ راهکاری برای مدیریت محتوای مدل‌های زبانی در شرکت‌ها

تصور کنید مدیر فناوری شرکتی هستید که می‌خواهد از هوش مصنوعی استفاده کند، اما وحشت از این دارد که مدل، اسرار تجاری یا داده‌های مشتریان را در پاسخ به کاربران لو دهد. برای حل این چالش، یک معماری حفاظتی جدید با استفاده از مدل Gemini 3.5-flash-lite ثابت کرد که شرکت‌ها می‌توانند بدون تکیه بر فیلترهای سازنده مدل، سیاست‌های سخت‌گیرانه‌ای را اعمال کنند. طبق مستندات منتشر شده در ۳۱ اوت ۲۰۲۶، این پیاده‌سازی نشان می‌دهد که یک لایهٔ کاربردی مستقل می‌تواند اطلاعات حساس را پیش از رسیدن به کاربر نهایی، رهگیری و مسدود کند.

زمینه و ریشه‌ها

اصطلاح «حفاظ» (Guardrail) ریشه در زبان انگلیسی حدود سال ۱۸۶۰ دارد. در ابتدا، این واژه به ریل‌های اضافی اشاره داشت که در پیچ‌های تند راه‌آهن نصب می‌شدند تا از خروج قطار از ریل و واژگونی آن جلوگیری کنند. در ساخت‌وسازهای عمران نیز، این اصطلاح برای نرده‌های ایمنی در منازل و پیاده‌روها به کار می‌رود. در دنیای هوش مصنوعی، یک حفاظ دقیقاً همین نقش را ایفا می‌کند؛ یعنی سدی در برابر تولید محتوای ناامن، شکست‌های امنیتی و توهم (Hallucination) — یعنی وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد، مثل دوستی که خاطره‌ای را اشتباه تعریف می‌کند.

بیشتر ابزارهای هوش مصنوعی زاینده (Generative AI) بر اساس احتمال توکن‌های بعدی کار می‌کنند. این فرآیند شامل توکن‌سازی (Tokenization) است؛ یعنی تبدیل متن خام به واحدهای کوچک به نام توکن. یک توکن می‌تواند یک کلمه کامل، بخشی از یک کلمه، اعداد یا نمادها باشد. سپس این توکن‌ها به نمایش‌های عددی تبدیل می‌شوند تا مدل بتواند زمینه (Context) را درک کند. به دلیل همین ماهیت احتمالی و تصادفی، یک پرامپت مشابه می‌تواند نتایج متفاوتی داشته باشد که گاهی منجر به نشت تصادفی داده‌های حساس یا تولید توهم می‌شود. برای سازمان‌ها، این پیش‌بینی‌ناپذیری یک شکاف نظارتی بزرگ ایجاد می‌کند که مدیریت دستی آن تقریباً غیرممکن است.

برای رفع این مشکل، این پروژه از یک پشتهٔ فنی خاص برای ایجاد یک سد ایمنی قابل تأیید استفاده کرده است. بخش بک‌اند با C# / .NET 10 به همراه EF Core و SQLite برای ذخیره‌سازی سبک و مستقل طراحی شده و بخش فرانت‌اند بر پایه React 19 و TypeScript بنا شده است.

جزئیات فنی

انتخاب این پشته فنی بر اساس مزایای خاص یکپارچگی و یادگیری صورت گرفته است:

• بک‌اند: C# / .NET 10 و EF Core انتخاب شدند زیرا متعلق به یک اکوسیستم واحد هستند و هماهنگی (Orchestration) را بهینه می‌کنند.
• پایگاه داده: SQLite به دلیل اینکه خودکفا و سبک است و به هیچ وابستگی خارجی نیاز ندارد، برگزیده شد.
• فرانت‌اند: ReactJS و TypeScript به دلیل نزدیکی ساختاری به C# استفاده شدند که منجر به کاهش منحنی یادگیری برای توسعه‌دهندگان شد.
• مدل زبانی (LLM): مدل Gemini 3.5-flash-lite به دلیل سرعت بالا، رایگان بودن و سهولت در پیکربندی از طریق API Key حساب گوگل انتخاب شد.

سازوکار حفاظ (Guardrail Mechanism)

این سیستم از طریق یک فرآیند تأیید دو مرحله‌ای عمل می‌کند:

• تولید: پرامپت کاربر به مدل زبانی اصلی ارسال می‌شود تا پاسخی خام تولید کند. در این پروژه، فیلترهای محتوایی سازنده مدل (Provider-side filters) عمداً غیرفعال شده‌اند تا خطرات استفاده از ابزارهای «خام» هوش مصنوعی به وضوح نمایان شود.
• قضاوت: برنامه پاسخ تولید شده را دوباره به مدل می‌فرستد — اما این بار مدل در نقش یک داور ظاهر می‌شود — تا محتوا را با لیست موضوعات ممنوعه (که توسط کاربر و با جداکننده سمی‌کولون تعریف شده‌اند) تطبیق دهد.

اگر «داور» تخلفی از سیاست‌ها شناسایی کند، سیستم خروجی را با یک پیام استاندارد مانند «محتوای غیرمجاز» (Conteúdo não permitido) جایگزین می‌کند. این رویکرد بر اساس مفهوم مدل زبانی به‌مثابه داور (LLM-as-a-judge) است. توسعه‌دهنده برای اهداف آموزشی از یک مدل برای هر دو نقش استفاده کرده، اما هشدار می‌دهد که در محیط‌های عملیاتی (Production) باید از دو مدل متفاوت استفاده کرد تا احتمال خطاهای مثبت یا منفی (False Negatives) کاهش یابد.

این روش، مسئولیت ایمنی را از دوش ارائه‌دهنده هوش مصنوعی به دوش مالک برنامه منتقل می‌کند. با تبدیل حفاظ به یک لایه مستقل، شرکت‌ها می‌توانند سیاست‌های استفاده را در لحظه به‌روزرسانی کنند، بدون اینکه منتظر تغییرات جهانی در فیلترهای امنیتی گوگل یا OpenAI بمانند.

برای توسعه‌دهنده، این یعنی هوش مصنوعی از یک «جعبه سیاه» به ابزاری کنترل‌شده تبدیل می‌شود. در این ساختار، ریسک نشت اطلاعات با یک حسابرسی عینی از هر توکن تولید شده کاهش می‌یابد. برای پشتیبانی از این هدف، برنامه شامل یک لاگ تاریخچه برای بازرسی است که ثبت می‌کند چه سوالی پرسیده شده و آیا پاسخ مسدود شده است یا خیر.

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

برای پیاده‌سازی این مدل در پشته فنی خود، ابتدا فهرستی سخت‌گیرانه از کلمات کلیدی حساس سازمان خود را تعریف کنید و سپس دقت مدل «داور» را با مجموعه‌ای از موارد شکست شناخته‌شده (Failure Cases) آزمایش کنید.

گام بعدی شما

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

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