ضربه خطرناک کش: بازاستفاده پاسخ هوش مصنوعی بدون تکرار خطا

ت

تیم ژرف ای‌آی

۱۵ مرداد ۱۴۰۵۱۴ دقیقه مطالعه
ضربه خطرناک کش: بازاستفاده پاسخ هوش مصنوعی بدون تکرار خطا

یک دستیار پشتیبانی پاسخ می‌دهد: «کارکنان می‌توانند تا سقف ۱۵۰۰ دلار برای لپ‌تاپ هزینه کنند.» چند دقیقه بعد، کارمند دیگری پرسشی شبیه می‌پرسد و پاسخ ذخیره‌شده را در کمتر از صد میلی‌ثانیه می‌گیرد. سامانه یک فراخوان مدل را حذف کرده است؛ اما هم‌زمان از این واقعیت گذشته که کارمند دوم در شرکت تابعه دیگری کار می‌کند، ارز متفاوتی دارد و مشمول سیاستی است که همان صبح بازنگری شده است.

دو پرسش در فضای embedding به هم نزدیک بودند، اما به یک تصمیم اشاره نمی‌کردند.

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

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

پشت واژه «کش هوش مصنوعی» چهار سازوکار متفاوت پنهان است

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

لایهآنچه بازاستفاده می‌شودآیا پاسخ نهایی قبلی تکرار می‌شود؟کنترل اصلی
کش پیشوند یا پرامپت ارائه‌دهندهمحاسبه پیشوند کاملاً یکسان، معمولاً وضعیت key/value توجهخیر؛ مدل ادامه‌ای تازه می‌سازدجداسازی ارائه‌دهنده، برابری دقیق پیشوند، سیاست نگهداری
کش دقیق پاسخپاسخ نهایی قبلی برای درخواست و وضعیت سامانه یکسانبلهکلید کامل و قطعی، تازگی و ابطال
کش معنایی پاسخپاسخ قبلی برای درخواستی که فقط مشابه استبلهدروازه هم‌ارزی، دامنه مجوز، محدودیت پیامد و سنجش بازاستفاده غلط
کش بازیابی یا ابزارنتیجه جست‌وجو، سند پردازش‌شده، خروجی ابزار یا ویژگی مشتقغیرمستقیم؛ شاهد کش‌شده پاسخ تازه را شکل می‌دهدنسخه منبع، مجوز، زمان مشاهده و انقضای وابستگی

لایه نخست اغلب امن‌ترین بهینه‌سازی است؛ محاسبه را بازاستفاده می‌کند اما نتیجه قبلی را جای نتیجه تازه نمی‌نشاند. راهنمای فعلی کش پرامپت OpenAI می‌گوید ضربه به تطابق دقیق پیشوند نیاز دارد و مدل همچنان پاسخ تازه تولید می‌کند. مستندات کش پرامپت Anthropic نیز برابری کامل بخش‌های کش‌شده را لازم می‌داند و بسته به بستر، جداسازی در سطح workspace یا سازمان را شرح می‌دهد. این‌ها واقعیت‌های ویژه ارائه‌دهنده‌اند که در تاریخ انتشار بازبینی شده‌اند، نه تضمین عمومی برای همه سرویس‌ها.

کش معنایی پاسخ ادعای بزرگ‌تری دارد: دو درخواست متفاوت آن‌قدر هم‌معنا هستند که پاسخ یکی جای دیگری بنشیند. پژوهش سال ۲۰۲۶ با عنوان از ضربه دقیق تا «به‌اندازه کافی نزدیک» صریحاً می‌گوید بازاستفاده معنایی فرض‌های کلاسیک کش را می‌شکند. شباهت می‌تواند نامزد پیدا کند؛ ثابت نمی‌کند کاربر، مجوز، تاریخ، سیاست، منبع یا اقدام موردنیاز یکسان است.

انضباط HTTP را وام بگیرید، نه فقط واژه کش را

کش بالغ HTTP برای ذخیره و بازاستفاده شرط دارد. RFC 9111 کلید کش، تازگی، اعتبارسنجی، Vary، private و قاعده درخواست احرازشده را تعریف می‌کند. پاسخ فقط چون موجود است دوباره مصرف نمی‌شود؛ ابعاد مرتبط درخواست باید منطبق و پاسخ باید تازه، صریحاً مجاز به سرو کهنه یا با موفقیت اعتبارسنجی شده باشد.

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

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

واقعیت تأییدشده را از معماری پیشنهادی جدا کنید

چند واقعیت مرز کار را روشن می‌کند. کش پرامپت می‌تواند پیشوند یکسان را بدون تکرار خروجی نهایی بازاستفاده کند. HTTP بازاستفاده را با کلید، مجوز و تازگی محدود می‌کند. NIST AI 600-1 محتوای غلطی را که با اطمینان ارائه می‌شود، یعنی confabulation، از ریسک‌های هوش مصنوعی مولد می‌شمارد و برای اطلاعات با تمامیت بالا، شاهد، زنجیره نگهداری و انتظار روشن درباره پایان اعتبار را مهم می‌داند. OWASP LLM02:2025 هشدار می‌دهد زمینه برنامه مدل زبانی ممکن است داده شخصی، مالی، سلامت، اعتبارنامه، سند حقوقی و اطلاعات محرمانه کسب‌وکار داشته باشد و کنترل دسترسی و پاک‌سازی داده را توصیه می‌کند.

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

پیش از انتخاب پایگاه داده، کش‌پذیری کار را تعیین کنید

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

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

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

هویت کامل تصمیم را در کلید کش بسازید

کش دقیق فقط نسبت به کلید خودش دقیق است. hashکردن آخرین پیام کاربر کافی نیست. پیش از lookup یک پاکت هویت canonical بسازید:

بُعد کلیدنمونهخطر حذف آن
tenant_id و principal_scopeسازمان، نقش و مجموعه مجوزضربه از مرز مشتری یا دسترسی عبور می‌کند
purposeتوضیح عمومی، راهنمای کارمند، بازبینی تحلیلگریک متن برای هدفی مجاز و برای هدف دیگر ممنوع است
locale و jurisdictionfa-IR، en-GB، کشور حاکمترجمه، ارز، تقویم و زمینه حقوقی معنا را تغییر می‌دهد
release_idمدل، پرامپت، ابزار و سیاست ایمنیرفتار قدیمی از یک استقرار ظاهراً کامل جان سالم به‌در می‌برد
knowledge_idsnapshot پیکره، ساخت نمایه و نسخه منابعپاسخ از منبع اصلاح یا لغوشده بیشتر عمر می‌کند
retrieval_policyفیلتر، top-k، reranker و شرط دسترسیمسیرهای شاهد متفاوت در یک کلید فرو می‌ریزند
output_contractشِما، الزام ارجاع و اقدام مجازمتن آزاد جایی مصرف می‌شود که شاهد ساختاریافته لازم است
time_boundaryزمان مشاهده یا بازه معتبرواقعیت زنده ناخواسته بی‌زمان می‌شود
sensitivityعمومی، داخلی، محرمانه و محدودنگهداری، رمزگذاری، اشتراک و حذف متفاوت است

release_id را به همان ترکیبی متصل کنید که گذرنامه انتشار هوش مصنوعی ثبت می‌کند. ویرایش پرامپت، تغییر مجوز ابزار، جابه‌جایی alias مدل، بازسازی بازیابی یا تغییر سیاست ایمنی باید حتی با جمله ثابت کاربر، هویت تازه بسازد.

مقدار حساس خام را وارد کلید قابل مشاهده نکنید. شناسه canonical یا keyed، نگاشت آن و مخزن کش را محافظت کنید.

کنار هر پاسخ قابل بازاستفاده، پاکت شاهد نگه دارید

پاسخ کش‌شده فقط متن و زمان انقضا نیست. شروط تولید را نیز ذخیره کنید:

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

این پاکت پاسخ می‌دهد: «کدام کاربران می‌توانند آن را ببینند؟»، «چه شاهدی آن را معتبر کرده؟»، «کدام انتشار آن را ساخته؟» و «چه رویدادی باید آن را لغو کند؟» این نظم مکمل مشاهده‌پذیری کیفیت داده است؛ منبع ممکن است به‌موقع برسد اما پاسخ کش‌شده هنوز معنای قبلی را حمل کند.

تازگی را از وابستگی‌ها استخراج کنید

یک TTL دلخواه مسئله واقعی ابطال را پنهان می‌کند. تازگی پاسخ را از کوتاه‌عمرترین وابستگی و رویدادهای صریح محاسبه کنید.

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

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

وابستگی نسخه‌دار و نمایه معکوس بسازید تا هر رویداد ورودی‌های متأثر را پیدا کند. اگر ابطال به جست‌وجوی متن مبهم پاسخ نیاز دارد، معماری در لحظه ضروری شکست می‌خورد. «حذف همه» کنترل اضطراری مفیدی است، اما جای lineage را نمی‌گیرد.

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

بازاستفاده معنایی را پشت دروازه هم‌ارزی بگذارید

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

  1. مستأجر و دامنه مجوز یکسان؛
  2. هدف، زبان، حوزه قضایی و قرارداد خروجی یکسان؛
  3. شناسه انتشار، دانش، بازیابی و سیاست ایمنی یکسان؛
  4. همه وابستگی‌ها تازه و لغونشده؛
  5. نبود موجودیت مستثنا مانند شناسه حساب، تاریخ، مبلغ، شماره پرونده یا فعل اقدامی که تصمیم را تغییر دهد؛
  6. مجازبودن بازاستفاده معنایی برای کلاس پیامد کار؛
  7. قبولی آزمون هم‌ارزی معنا، نه فقط نزدیکی.

آزمون آخر می‌تواند قاعده، classifier کوچک و verifier را ترکیب کند، اما verifier هم خطاپذیر است. باید روی negative دشوار سنجیده شود: جمله‌های بسیار شبیهی که نفی، عامل، تاریخ، ارز، آستانه، حوزه قضایی یا اقدام را عوض می‌کنند. در صورت تردید verifier، کش باید miss شود.

هرگز اعتمادبه‌نفس تولیدشده را مجوز بازاستفاده ندانید. حذف قطعی و مجموعه آزمون برچسب‌دار مستقل ارجح است. شباهت زیاد برای جست‌وجو مفید است؛ مرز تأیید نیست.

مثال عملی: دستیار دوزبانه سیاست تأمین‌کننده

دستیار خریدی را در نظر بگیرید که سیاست را به فارسی و انگلیسی توضیح می‌دهد. قاعده‌ای عمومی می‌گوید خرید بالاتر از آستانه معمولاً به استعلام قیمت نیاز دارد. پاسخ فارسی ذخیره‌شده برای شرکت عملیاتی تهران، تحت سیاست PROC-17.4، با مبلغ تومان و استثنای مشخص تعمیر اضطراری ساخته شده است.

پرسش بعدی می‌گوید: «می‌توانیم این قطعه فوری را بدون سه استعلام بخریم؟» از نظر معنایی نزدیک است. دروازه پیش از بازاستفاده می‌فهمد درخواست‌کننده در شرکت تابعه دیگری با سیاست PROC-19.1 است، مبلغ از آستانه آن شرکت بیشتر است و استثنای اضطراری به تأییدکننده نام‌دار نیاز دارد. کش معنایی باید miss شود.

سامانه همچنان می‌تواند کار ذخیره کند:

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

اگر پرسش فقط «تطبیق سه‌طرفه چیست؟» باشد و تعریف عمومی، نسخه‌دار، غیرشخصی و در همه شرکت‌ها یکسان بماند، نامزد معنایی می‌تواند عبور کند. تفاوت در شباهت زبانی نیست؛ پرسش این است که آیا همه متغیرهای تغییردهنده تصمیم هم‌ارز مانده‌اند.

کش را مانند یک مرز امنیتی دفاع کنید

کش پاسخ هم مخزن محتواست و هم سامانه مسیریابی. هر دو را threat model کنید.

  • افشای میان‌دامنه‌ای: کلید ناقص یا namespace مشترک، اطلاعات مشتق‌شده کاربر دیگر را برمی‌گرداند.
  • آلودگی کش: مهاجم پاسخ مخرب یا غلطی را ذخیره و سپس پرسش‌های محتمل برای بازیابی آن را هدف می‌گیرد.
  • ماندگاری prompt injection: محتوای بازیابی‌شده نامطمئن یک پاسخ را منحرف می‌کند و کش پس از ناپدیدشدن منبع، آن را تکثیر می‌کند.
  • شکست لغو: داده حذف یا محدودشده در خروجی یا شاهد کش‌شده می‌ماند.
  • کانال جانبی و نشت عیب‌یابی: زمان، کلید، embedding، trace یا داشبورد، فعالیت یا ورودی حفاظت‌شده را آشکار می‌کند.

کمترین دسترسی، رمزگذاری، جداسازی namespace، محدودیت نگهداری، انتشار حذف، حفاظت تمامیت و لاگ دسترسی را اجرا کنید. embedding را ناشناس فرض نکنید؛ از محتوا مشتق شده و ممکن است حساس باشد. دستور پرامپت سیستمی برای افشانکردن راز، سازوکار جداسازی کش نیست؛ همان‌طور که OWASP هشدار می‌دهد محدودیت پرامپت قابل دورزدن است.

پیش از نرخ ضربه، بازاستفاده غلط را بسنجید

کش معنایی را ابتدا در حالت سایه اجرا کنید. برای هر نامزد، مسیر عادی پاسخ تازه بسازد و هر دو نتیجه با شاهد جاری مقایسه شود. مجموعه برچسب‌دار باید جفت عادی، تکرار دقیق و near-match خصمانه داشته باشد.

سنجه‌ها:

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

اگر ترافیک ناایمن موفقیت شمرده شود، نرخ ضربه سنجه نمایشی است. نتیجه را بر اساس زبان، مستأجر، گردش‌کار، سیاست و موجودیت نادر برش دهید؛ فارسی، انگلیسی و بازیابی بین‌زبانی را بسنجید و parity را فرض نکنید.

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

دروازه پذیرش

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

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

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

یادداشت منابع — بازبینی ۶ اوت ۲۰۲۶

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

مطالب مرتبط

آماده شروع پروژه هوش مصنوعی خود هستید؟

با تیم ما تماس بگیرید و درباره نحوه کمک به کسب‌وکار خود صحبت کنید.