خروجی لو‌رفته یک شکست در منشأ داده است، نه هم‌راستایی

نشت یک باگ در جریان داده است

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

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

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

ردیابی آلودگی برای pipelineهای agent

ردیابی آلودگی ایده‌ای شناخته‌شده از سیستم‌های عامل و جریان اطلاعات امن است: داده را هنگام ورود به سیستم علامت‌گذاری کن، علامت را از طریق هر تبدیل منتشر کن، و عملیاتی را که داده علامت‌خورده را بدون آزادسازی صریح به یک مقصد نامطمئن می‌فرستد مسدود کن. pipelineهای agent به همان نظم نیاز دارند، متناسب‌شده با متن، تصاویر، embeddingها و tool callها.

برچسب‌گذاری در ورود

هر مصنوعی که وارد context window می‌شود باید حداقل دو فیلد داشته باشد:

یک کلاس حساسیت (برای مثال: عمومی، داخلی، محرمانه، داده شخصی)
یک شناسه منشأ (کدام کاربر، کدام بارگذاری، کدام connector، کدام نتیجه retrieval)

این برچسب‌ها باید در همان مرزی که مصنوع وارد اجرا می‌شود ضمیمه شوند، نه اینکه بعداً از محتوا استنتاج شوند. استنتاج دارای افت اطلاعاتی و در برابر حمله آسیب‌پذیر است. یک file descriptor، یک سطر پایگاه داده، یا یک رویداد بارگذاری می‌داند داده از کجا آمده؛ یک summariser نمی‌داند.

انتشار از طریق تبدیل

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

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

دروازه خروجی

هر مسیری که می‌تواند محتوا را بیرون از اجرا منتشر کند باید منشأ محتوای منتشرشده را بررسی کند. مسیرهای خروجی شامل:

پیام‌ها به کانال‌های خارجی
نوشتن فایل در فضای ذخیره‌سازی مشترک
tool callهایی که به APIهای شخص ثالث ارسال می‌کنند
صفحات رندرشده یا پیوست‌ها
logها و traceهایی که به سرویس‌های observability خارجی ارسال می‌شوند

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

یک نقطه اجرای حداقلی می‌تواند به‌صورت یک بررسی سیاست بیان شود:

def can_export(artefact, destination):
    if destination.allowed_sensitivity < artefact.sensitivity:
        return require_release(artefact, destination)
    return True

ویژگی مهم این است که این بررسی روی مسیر خروجی اجرا می‌شود، نه داخل مدل. نمی‌توان به مدل اعتماد کرد که به یاد بیاورد کدام ورودی‌ها حساس بودند؛ pi

تلقی retrieval به‌عنوان فقط‌خواندنی و generation به‌عنوان ایمن

Close-up view of a computer screen displaying code in a software development environment.

یک مدل ذهنی رایج pipeline را به فاز خواندن (retrieval، tool callها) و فاز نوشتن (generation، انتشار) تقسیم می‌کند. فاز خواندن ایمن فرض می‌شود چون فقط می‌خواند. فاز نوشتن ایمن فرض می‌شود چون فقط محتوای جدید می‌نویسد. این دو توسط context window به هم می‌پیوندند، و همان پیوند جایی است که منشأ داده از دست می‌رود. اگر retrieval برچسب نمی‌زند، و generation منتشر نمی‌کند، آنگاه فاز نوشتن هیچ راهی ندارد بداند که خروجی‌اش از بارگذاری خصوصی یک کاربر مشتق شده است.

راه‌حل این است که context window را به‌عنوان یک ساختار داده با منشأ در نظر بگیریم، نه به‌عنوان یک رشته مبهم. این یعنی framework agent، نه فقط application، باید برچسب‌ها را از طریق انواع پیام خود حمل کند.

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

فیلترهای خروجی معمولاً متن تولیدشده را برای الگوها اسکن می‌کنند: PII، اسرار، رشته‌های ممنوع. آن‌ها به‌ندرت تصاویر، صدا یا فایل‌های پیوست‌شده را بازرسی می‌کنند. یک agent که تصویر کاربر را به پیامی ضمیمه می‌کند ممکن است از هر فیلتر متنی عبور کند در حالی که تصویر را نشت می‌دهد. فیلتر یک caption بی‌ضرر می‌بیند؛ پیوست بررسی‌نشده می‌ماند.

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

یک قرارداد حداقلی

یک قرارداد کارآمد برای اجراهای agent آنقدر کوچک است که در چند خط بیان شود:

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

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

بده‌بستان هزینه عملیاتی و اصطکاک است. ردیابی منشأ به هر span بافت فراداده اضافه می‌کند، که مصرف token و پیچیدگی مهندسی را افزایش می‌دهد. دروازه‌های خروجی latency اضافه می‌کنند و می‌توانند workflowهای مشروع را مسدود کنند. workflowهای راززدایی بازبینی انسانی اضافه می‌کنند. این هزینه‌ها واقعی هستند، و تیم‌ها باید کلاس‌های حساسیت و مسیرهای خروجی‌ای که اجرا می‌کنند را محدود کنند نه اینکه از روز اول کنترل کامل جریان اطلاعات را بکوشند. یک قرارداد باریک و اجراشده روی مسیرهایی که اهمیت دارند ارزشمندتر از یک قرارداد گسترده و اجرانشده است.

جایگزین این است که همچنان نشت‌ها را شکست هم‌راستایی تلقی کنیم، و همچنان با تغییرات prompt و فیلترهای خروجی که نمی‌توانند تاریخچه داده را ببینند پاسخ دهیم. آن رویکرد همچنان دسته‌ای از شکست را از دست می‌دهد که در آن مدل اصلاً بدرفتاری نمی‌کند: صرفاً همان چیزی را منتشر می‌کند که pipeline جلویش گذاشته، چون هیچ‌چیز در pipeline تفاوت بین ورودی و صادرات را نمی‌دانست.

خروجی لو‌رفته یک شکست در منشأ داده است، نه یک شکست در هم‌راستایی مدل