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

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

این ایده پشت گاردریل‌های دروازه هوش مصنوعی است.

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

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

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

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

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

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

این نیاز به قضاوت محصول را حذف نمی‌کند. بلکه یک مکان برای اجرای آن ایجاد می‌کند.

گاردریل‌های خوب باید به چهار سؤال پاسخ دهند:

• آیا این درخواست برای ارسال به یک مدل ایمن است؟
• آیا خروجی این مدل برای نمایش به یک کاربر ایمن است؟
• آیا مدل بر اساس شواهدی که برنامه ارائه داده است باقی مانده است؟
• چه اتفاقی افتاد و آیا تیم می‌تواند تصمیم را بعداً ممیزی کند؟

چه چیزی را باید قبل از فراخوانی مدل اعتبارسنجی کرد؟

اعتبارسنجی ورودی خطرات را قبل از رسیدن به مدل شناسایی می‌کند.

دسته اول تزریق درخواست است. یک کاربر، سند، صفحه وب، یا نتیجه ابزار ممکن است شامل دستورالعمل‌هایی باشد که طراحی شده‌اند تا درخواست سیستم را نادیده بگیرند، زمینه مخفی را افشا کنند، یا مدل را مجبور کنند ابزاری را که نباید استفاده کند، فراخوانی کند. OWASP Top 10 برای برنامه‌های LLM تزریق درخواست و اختیار بیش از حد را به عنوان خطرات اصلی برنامه‌های LLM به دلیل خاصی در نظر می‌گیرد: مدل ممکن است دستورالعمل‌ها را دنبال کند، اما محصول همچنان مسئول نتیجه است.

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

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

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

چه چیزی را باید قبل از اینکه کاربر خروجی را ببیند اعتبارسنجی کرد

اعتبارسنجی خروجی مشکلات را پس از تولید اما قبل از نمایش شناسایی می‌کند.

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

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

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

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

هدف این نیست که هر پاسخ کامل باشد. هدف جلوگیری از شکست‌های قابل پیش‌بینی است که به مکان‌هایی برسند که هزینه‌بر هستند.

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

یک محافظ تنها زمانی مفید است که محصول بداند با نتیجه چه کاری انجام دهد.

برای مسائل کم‌ریسک، ممکن است برنامه از کاربر بخواهد درخواست را بازبینی کند. برای خروجی‌های غیرپشتیبانی‌شده، ممکن است برنامه با یک پاسخ ایمن جایگزین پاسخ دهد و توضیح دهد که نمی‌تواند نتیجه را تأیید کند. برای اقدامات پرریسک، ممکن است برنامه اجرا را به یک بازبین انسانی ارسال کند.

سخت‌ترین تصمیم این است که چگونه با شکست‌های سیستم محافظ برخورد کنیم. اگر اعتبارسنجی در دسترس نباشد، آیا برنامه باید باز شکست بخورد و ادامه دهد یا بسته شکست بخورد و درخواست را مسدود کند؟

هیچ پاسخ جهانی وجود ندارد.

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

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

نقش ShareAI را شفاف نگه دارید

ShareAI به سازندگان کمک می‌کند استفاده از هوش مصنوعی را به یک بازار و لایه API متصل کنند. سازندگان می‌توانند استنتاج را از طریق ShareAI هدایت کنند، مدل‌ها را از بازار مدل شفاف چند ارائه‌دهنده, انتخاب کنند و زمانی که برنامه خودشان استفاده از هوش مصنوعی را تولید می‌کند، یک حاشیه تنظیم کنند.

این موضوع ShareAI را مالک مدل ایمنی محصول شما نمی‌کند.

سازنده همچنان مالک است:

• احراز هویت و مجوز کاربر.
• سیاست محتوای خاص برنامه.
• اعتبارسنجی درخواست و خروجی.
• مجوزهای ابزار و جریان‌های تأیید.
• مدیریت خطاهای مرتبط با مشتری.
• ثبت وقایع، نظارت، و بررسی پشتیبانی.
• تصمیمات مربوط به حریم خصوصی و انطباق.

این تمایز مهم است. ShareAI می‌تواند از اقتصاد محصول هوش مصنوعی شما پشتیبانی کند، اما محافظ‌ها بخشی از قرارداد برنامه‌ای هستند که با مشتریان خود می‌بندید.

اگر در حال اجرای یک جریان کاری Builder هستید، با مستندات ShareAI و مرجع API, شروع کنید، سپس یکپارچه‌سازی را با بررسی‌های سیاست خود و قابلیت مشاهده ترکیب کنید.

یک چک‌لیست پیاده‌سازی عملی

از این چک‌لیست هنگام افزودن محافظ‌ها به تماس‌های مدل تولید استفاده کنید:

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

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

سوالات متداول

محافظ‌های دروازه هوش مصنوعی چیست؟

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

آیا ShareAI یک موتور محافظ هوش مصنوعی ارائه می‌دهد؟

این مقاله ShareAI را به عنوان یک موتور محافظ معرفی نمی‌کند. ShareAI به سازندگان کمک می‌کند به مدل‌ها دسترسی پیدا کنند، استفاده از هوش مصنوعی را هدایت کنند و ترافیک برنامه را کسب درآمد کنند. سازندگان باید کنترل‌های ایمنی، سیاست، ثبت و بررسی خاص محصول را در پشته برنامه خود پیاده‌سازی کنند.

چرا باید هم درخواست‌ها و هم خروجی‌ها اعتبارسنجی شوند؟

اعتبارسنجی درخواست‌ها ورودی‌های ناامن یا دستکاری‌شده را قبل از رسیدن به مدل شناسایی می‌کند. اعتبارسنجی خروجی‌ها پاسخ‌های ناامن، غیرپشتیبانی‌شده، ناقص یا ناقض سیاست را قبل از مشاهده توسط کاربر یا سیستم پایین‌دستی شناسایی می‌کند.

تزریق درخواست چیست؟

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

اعتبارسنجی خروجی باید چه چیزی را بررسی کند؟

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

آیا هر درخواست مسدود شده باید به یک شکل شکست بخورد؟

خیر. یک ویژگی طوفان فکری می‌تواند متفاوت از یک جریان کاری مالی یا ابزار مدیریت حساب پاسخ دهد. پاسخ را با ریسک مطابقت دهید: از کاربر بخواهید بازنگری کند، یک گزینه امن نشان دهید، برای بررسی ارسال کنید یا کاملاً مسدود کنید.

شکست باز در مقابل شکست بسته چیست؟

شکست باز به این معناست که برنامه زمانی که سیستم محافظ در دسترس نیست ادامه می‌دهد. شکست بسته به این معناست که برنامه درخواست را تا زمانی که اعتبارسنجی در دسترس باشد مسدود می‌کند. جریان‌های کاری با ریسک بالا معمولاً رفتار سخت‌گیرانه‌تری نسبت به ویژگی‌های پیش‌نویس با ریسک پایین سزاوار هستند.

محافظ‌ها چگونه بر درآمدزایی سازنده تأثیر می‌گذارند؟

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

آیا محافظ‌ها جایگزین بررسی انسانی می‌شوند؟

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

آژانس‌ها چگونه باید به محافظ‌ها فکر کنند؟

آژانس‌ها باید محافظ‌ها را به عنوان بخشی از تحویل مشتری در نظر بگیرند. سیاست، ثبت، تشدید و رفتار بررسی را قبل از راه‌اندازی تعریف کنید، به‌ویژه زمانی که ویژگی هوش مصنوعی با داده‌های مشتری یا ابزارهای خارجی در تماس است.

آیا محافظ‌های دروازه فقط برای شرکت‌های بزرگ هستند؟

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

اولین محافظی که باید اضافه شود چیست؟

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