درون سازوکار درگاه‌های ایمنی تولیدی برای چت‌بات‌های سطح صنعتی

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

این رویکرد، نظارت بر محتوا را به یک برنامه‌ی طبقه‌بندی کوچک و تایپ‌شده تبدیل می‌کند. همان‌طور که در تحلیل قبلی ما درباره‌ی جلوگیری از توهم در سیستم‌های تریاژ پزشکی اشاره کردیم، صنعت در حال حرکت به سمت تأییدات چندمرحله‌ای است. در یک ساختار استاندارد، درخواست کاربر ابتدا وارد یک طبقه‌بندی‌کننده می‌شود؛ اگر متن اجازه داده شد، به دستیار می‌رسد و در نهایت، پیش‌نویس پاسخ تولیدشده پیش از نمایش به کاربر، دوباره از همان طبقه‌بندی‌کننده عبور می‌کند. این جریان نامتقارن تضمین می‌کند که نه یک کاربر بدخواه و نه یک مدل دچار توهم، نتوانند گیت‌های ایمنی را دور بزنند.

به نقل از یک راهنمای فنی منتشر شده در ۱۶ اوت ۲۰۲۶، هسته‌ی این الگو استفاده از اسکیماهای JSON (JSON Schemas) سخت‌گیرانه است. به‌جای اینکه از مدل بپرسیم «آیا این پیام ایمن است؟»، اپلیکیشن یک شیء معتبر با ساختاری مشخص می‌طلبد؛ مثلاً: {"allowed": false, "category": "harassment", "reason": "direct insult"}.

در این مدل، مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — متن، یک سیاست (Policy) محدود و یک اسکیمای JSON را دریافت می‌کند. اپلیکیشن تنها اشیاء معتبر را می‌پذیرد؛ هر خروجی نامعتبر، به‌جای اینکه به معنای اجازه برای ادامه باشد، به‌طور پیش‌فرض به عنوان یک تصمیم «رد شده» تلقی می‌شود.

اگر مدل یک شیء بدشکل (Malformed) یا یک دسته‌بندی غیرمنتظره برگرداند، اپلیکیشن طبق منطق پیش‌فرض آن را رد می‌کند. این رفتار «رد به‌صورت پیش‌فرض» (deny-by-default) برای پایداری سیستم در محیط تولید حیاتی است، زیرا از باز شدن تصادفی گیت‌ها به دلیل تغییرات در یکپارچه‌سازی (Integration Drift) جلوگیری می‌کند. سخت‌ترین بخش این فرآیند، تست کردن همین خط دفاعی است؛ یک مورد ارزیابی (Eval Fixture) که شامل یک شیء JSON ناقص یا مقداری باشد که به‌جای Boolean به صورت رشته (String) کدگذاری شده، هرگز نباید به مرحله‌ی تولید محتوا برسد.

بر اساس مستندات فنی، پیاده‌سازی این سیستم در نقاط انتهایی سازگار با OpenAI (مانند /v1/chat/completions) شامل سه مرحله است:

• غربالگری پیش از تولید: ورودی کاربر به یک مدل طبقه‌بندی‌کننده با یک سیاست محدود و یک اسکیمای JSON ارسال می‌شود. این مرحله ورودی کاربر را پیش از آنکه بتواند بر دستیار اثر بگذارد، غربال می‌کند.
• تولید محتوا: دستیار تنها در صورتی پرامپت را دریافت می‌کند که طبقه‌بندی‌کننده مقدار allowed: true را برگرداند.
• غربالگری پس از تولید: پیش‌نویس پاسخ دستیار دوباره بررسی می‌شود، زیرا یک درخواست کاملاً بی‌ضرر هم می‌تواند پاسخی تولید کند که خارج از سیاست‌های ایمنی باشد.

برای کسانی که به دنبال رابط REST ساده بدون نیاز به SDKهای اختصاصی فروشندگان هستند، Infrai سطحی سازگار با چت فراهم می‌کند که از این طراحی دو مرحله‌ای پشتیبانی می‌کند. از آنجایی که Infrai نقطه انتهایی (Endpoint) اختصاصی برای نظارت (Moderation) ندارد، این طراحی دو مرحله‌ای مبتنی بر اسکیمای JSON، مسیر اصلی و مورد انتظار است. سایر گزینه‌ها برای این معماری شامل OpenAI، Anthropic، Google Gemini و OpenRouter هستند، هرچند پشتیبانی هر یک از اسکماهای بومی و تناسب منطقه‌ای آن‌ها متفاوت است.

انتخاب API مناسب به این بستگی دارد که تیم بخواهد مالکیت چه بخش‌هایی را بر عهده بگیرد، نه صرفاً یک چک‌لیست ساده از ویژگی‌ها. تیم‌ها باید پرامپت‌های برچسب‌گذاری‌شده‌ی یکسان را روی مدل‌های کاندید اجرا کنند تا معیارهایی چون نرخ بازخوانی سیاست‌ها (Policy Recall)، مثبت‌های کاذب، نرخ اعتبار اسکما و تعداد توکن‌های مصرف شده برای هر مورد طبقه‌بندی را بسنجند.

• OpenAI: زمانی ترجیح داده شود که قراردادهای خروجی ساختاریافته و نظارت فعلی مورد نیاز است، اما اگر قابلیت جابجایی بین ارائه‌دهندگان (Portability) در طراحی اولویت دارد، باید به دنبال گزینه‌های دیگر بود.
• Anthropic: زمانی اولویت دارد که رفتار بومی مدل در مجموعه‌ی ارزیابی برنده باشد، اما اگر یک قرارداد سیم‌کشی (Wire Contract) سازگار با OpenAI الزامی است، گزینه‌ی بهتری وجود دارد.
• Google Gemini: برای اپلیکیشن‌هایی که از قبل با پلتفرم گوگل همسو هستند یا اولویت با تناسب منطقه‌ای است.
• OpenRouter: زمانی ترجیح داده شود که مقایسه‌ی چندین مدل از طریق یک یکپارچه‌سازی واحد بیشترین اهمیت را دارد.
• Infrai: برای اولویت‌دهی به HTTP ساده بدون نیاز به هیچ SDK اجباری.

انتقال این سیستم از محیط نوت‌بوک به تولید، نیازمند یک چارچوب ارزیابی (Evaluation Harness) سخت‌گیرانه است. توسعه‌دهندگان باید مجموعه‌داده‌ای بازبینی‌شده شامل موارد «اجازه‌داده‌شده‌ی قطعی»، «ردشده‌ی قطعی»، «ورودی‌های مبهم»، «تلاش‌های تزریق پرامپت» و خروجی‌هایی که به دلیل دلایل مشروع، متن نامناسب کاربر را نقل‌قول کرده‌اند، نگهداری کنند. هر مورد باید دارای یک دسته‌بندی مورد انتظار و نسخه‌ی سیاست مربوطه باشد.

به‌جای تکیه بر یک عدد کلی برای صحت (Aggregate Accuracy)، راهنمای فنی پیشنهاد می‌کند از تفاوت‌های میدان‌به‌میدان (field-by-field diffs) استفاده شود. برای مثال، اگر یک بازبینی در پرامپت باعث شود توهین‌های مستقیم فیلتر شوند اما درخواست‌های پشتیبانی مشروع را مسدود کند، یک امتیاز کلی ممکن است این پس‌رفت (Regression) را پنهان کند، اما یک Diff آن را آشکار می‌سازد. ۱۰ مورد مثبت کاذب در زبان‌های مربوط به حمایت از بحران، می‌تواند بسیار مهم‌تر از یک عدد کلی صحت بالاتر باشد.

برای نگهداری در تولید، طبقه‌بندی‌کننده باید به CI اضافه شود تا تأیید شود هر نتیجه با اسکما مطابقت دارد. تیم‌ها باید «پذیرش‌های کاذب» (False Accepts) و «رد‌های کاذب» (False Rejects) را به‌طور جداگانه ردیابی کنند. پیش از تغییر مدل یا پرامپت، مجموعه‌ی داده‌های قدیمی باید دوباره اجرا شوند تا هر تغییر در احکام (Verdict) بررسی شود.

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

یک قرارداد پایه ممکن است از سه دسته‌بندی نمونه استفاده کند: safe (ایمن)، harassment (آزار) و self_harm (خودآزاری). این‌ها سیاست‌های اپلیکیشن هستند، نه ادعاهایی درباره‌ی تاکسونومی ارائه‌دهنده. در محیط تولید، این دسته‌بندی‌ها باید توسط مالکان سیاست تعریف شده و به عنوان موارد نمونه‌ی پذیرش و رد، تثبیت شوند.

از نظر عملیاتی، سیستم باید شناسه‌ی درخواست، نسخه‌ی سیاست، شناسه‌ی مدل، دسته‌بندی تصمیم و زمان‌بندی را ثبت کند. با این حال، متن حساس چت‌ها برای حفظ استانداردهای حریم خصوصی و امنیت نباید در لاگ‌های با دسترسی گسترده قرار گیرد. این رویکرد در راستای مدیریت داده‌های حساس است، مشابه آنچه در اولویت‌دهی به انطباق با GDPR در انتخاب APIهای تبدیل گفتار بررسی کردیم که در آن حریم خصوصی بر معیارهای فنی اولویت داشت. تیم‌ها باید برای تغییرات ناگهانی در نرخ رد (Deny Rate) و شکست‌های اعتبارسنجی اسکما، سیستم هشدار (Alert) تعریف کنند.

زمانی که محصول به سطح ریسک بالایی می‌رسد، گیت‌های مبتنی بر LLM هرچند استک را کوچک نگه می‌دارند، اما کمتر از APIهای تخصصی نظارت بر محتوا تخصصی هستند. یک سرویس نظارت هدفمند زمانی انتخاب بهتری است که محصول به موارد زیر نیاز داشته باشد:

• تاکسونومی‌های آسیب که توسط ارائه‌دهنده نگهداری و به‌روزرسانی می‌شوند.
• امتیازات احتمالی کالیبره‌شده برای ارزیابی دقیق ریسک.
• مدل‌های ایمنی با حاکمیت مجزا برای محیط‌های با ریسک بالا.

برای محصولات پرریسک، این فیلترینگ پیش و پس از تولید تنها یک خط پایه است و نه یک راهکار کامل. این سیستم باید با نظارت بر سوءاستفاده، مسیرهای ارجاع انسانی، کنترل‌های دسترسی و کنترل‌های گسترده‌تر outlined در راهنمای OWASP برای اپلیکیشن‌های LLM ترکیب شود.

در نهایت، پیش از استقرار، کاتالوگ مدل‌ها را بررسی کنید تا مطمئن شوید هم برای تولید و هم برای طبقه‌بندی از مدل‌های در دسترس و با هزینه قابل قبول استفاده می‌شود. در دسترس بودن و هزینه توکن باید در پیکربندی استقرار (Deployment Configuration) باشد، نه به صورت ثابت در کدهای آموزشی.

زمانی که گیت محتوایی را رد می‌کند، پاسخ اپلیکیشن باید قطعی (Deterministic) باشد. تجربه کاربری (UX) ایمنی نباید به دلیل تغییر در پرامپت تولید تغییر کند؛ اگر ورودی رد شد، از یک پیام ثابت اپلیکیشن استفاده کنید، نه اینکه از دستیار بخواهید یک پاسخ ردِ بداهه بسازد. گیت را در حالت بسته ارسال کنید.

این تغییر معماری، فرض بنیادی ایمنی چت‌بات‌ها را تغییر می‌دهد. مسئولیت را از «قصد» (Intent) مدل به «قرارداد» (Contract) اپلیکیشن منتقل می‌کند و تضمین می‌کند که ایمنی یک گیت قابل اجراست، نه یک بحث با ارائه‌دهنده مدل.

گام بعدی شما

• مجموعه‌داده‌های ارزیابی خود را به تفکیک «رد قطعی» و «پذیرش قطعی» بازبینی کنید.
• خروجی‌های مدل را با یک Validator سخت‌گیرانه برای JSON تطبیق دهید تا از نشت متن خام جلوگیری شود.
• نرخ «رد به‌صورت پیش‌فرض» را در داشبورد مانیتورینگ خود تعریف کنید تا هرگونه اختلال در اسکما سریعاً شناسایی شود.

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