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

یک دستیار پشتیبانی پاسخ میدهد: «کارکنان میتوانند تا سقف ۱۵۰۰ دلار برای لپتاپ هزینه کنند.» چند دقیقه بعد، کارمند دیگری پرسشی شبیه میپرسد و پاسخ ذخیرهشده را در کمتر از صد میلیثانیه میگیرد. سامانه یک فراخوان مدل را حذف کرده است؛ اما همزمان از این واقعیت گذشته که کارمند دوم در شرکت تابعه دیگری کار میکند، ارز متفاوتی دارد و مشمول سیاستی است که همان صبح بازنگری شده است.
دو پرسش در فضای embedding به هم نزدیک بودند، اما به یک تصمیم اشاره نمیکردند.
کش میتواند سرویس هوش مصنوعی را سریعتر، ارزانتر و کمنوسانتر کند. در عین حال میتواند یک ادعای ساختگی را حفظ کند، از مرز مجوز عبور دهد، سیاست لغوشده را برگرداند یا پاسخ مشتقشده از داده یک مشتری را به مشتری دیگر نشان دهد. بنابراین تصمیم عملی فقط این نیست که کش داشته باشیم یا نه؛ باید بدانیم کدام لایه مجاز به بازاستفاده است، چه شروطی باید یکسان بماند و کدام درخواست همیشه باید به شاهد تازه بازگردد.
این راهنما کش پرامپت ارائهدهنده را از کش دقیق و معنایی پاسخ جدا میکند و معماری کنترل را بر هویت، اختیار، انتشار، تازگی و پیامد بنا میگذارد. قاعده اصلی چنین است: ضربه کش پاسخ یک تصمیم سیاستی است، نه صرفاً رویداد کارایی.
گاهی تیم تصور میکند هر ضربه کش، پاسخ قدیمی را تحویل میدهد. در عمل چهار سازوکار با ریسکهای متفاوت وجود دارد:
| لایه | آنچه بازاستفاده میشود | آیا پاسخ نهایی قبلی تکرار میشود؟ | کنترل اصلی |
|---|---|---|---|
| کش پیشوند یا پرامپت ارائهدهنده | محاسبه پیشوند کاملاً یکسان، معمولاً وضعیت key/value توجه | خیر؛ مدل ادامهای تازه میسازد | جداسازی ارائهدهنده، برابری دقیق پیشوند، سیاست نگهداری |
| کش دقیق پاسخ | پاسخ نهایی قبلی برای درخواست و وضعیت سامانه یکسان | بله | کلید کامل و قطعی، تازگی و ابطال |
| کش معنایی پاسخ | پاسخ قبلی برای درخواستی که فقط مشابه است | بله | دروازه همارزی، دامنه مجوز، محدودیت پیامد و سنجش بازاستفاده غلط |
| کش بازیابی یا ابزار | نتیجه جستوجو، سند پردازششده، خروجی ابزار یا ویژگی مشتق | غیرمستقیم؛ شاهد کششده پاسخ تازه را شکل میدهد | نسخه منبع، مجوز، زمان مشاهده و انقضای وابستگی |
لایه نخست اغلب امنترین بهینهسازی است؛ محاسبه را بازاستفاده میکند اما نتیجه قبلی را جای نتیجه تازه نمینشاند. راهنمای فعلی کش پرامپت OpenAI میگوید ضربه به تطابق دقیق پیشوند نیاز دارد و مدل همچنان پاسخ تازه تولید میکند. مستندات کش پرامپت Anthropic نیز برابری کامل بخشهای کششده را لازم میداند و بسته به بستر، جداسازی در سطح workspace یا سازمان را شرح میدهد. اینها واقعیتهای ویژه ارائهدهندهاند که در تاریخ انتشار بازبینی شدهاند، نه تضمین عمومی برای همه سرویسها.
کش معنایی پاسخ ادعای بزرگتری دارد: دو درخواست متفاوت آنقدر هممعنا هستند که پاسخ یکی جای دیگری بنشیند. پژوهش سال ۲۰۲۶ با عنوان از ضربه دقیق تا «بهاندازه کافی نزدیک» صریحاً میگوید بازاستفاده معنایی فرضهای کلاسیک کش را میشکند. شباهت میتواند نامزد پیدا کند؛ ثابت نمیکند کاربر، مجوز، تاریخ، سیاست، منبع یا اقدام موردنیاز یکسان است.
کش بالغ 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 و jurisdiction | fa-IR، en-GB، کشور حاکم | ترجمه، ارز، تقویم و زمینه حقوقی معنا را تغییر میدهد |
release_id | مدل، پرامپت، ابزار و سیاست ایمنی | رفتار قدیمی از یک استقرار ظاهراً کامل جان سالم بهدر میبرد |
knowledge_id | snapshot پیکره، ساخت نمایه و نسخه منابع | پاسخ از منبع اصلاح یا لغوشده بیشتر عمر میکند |
retrieval_policy | فیلتر، top-k، reranker و شرط دسترسی | مسیرهای شاهد متفاوت در یک کلید فرو میریزند |
output_contract | شِما، الزام ارجاع و اقدام مجاز | متن آزاد جایی مصرف میشود که شاهد ساختاریافته لازم است |
time_boundary | زمان مشاهده یا بازه معتبر | واقعیت زنده ناخواسته بیزمان میشود |
sensitivity | عمومی، داخلی، محرمانه و محدود | نگهداری، رمزگذاری، اشتراک و حذف متفاوت است |
release_id را به همان ترکیبی متصل کنید که گذرنامه انتشار هوش مصنوعی ثبت میکند. ویرایش پرامپت، تغییر مجوز ابزار، جابهجایی alias مدل، بازسازی بازیابی یا تغییر سیاست ایمنی باید حتی با جمله ثابت کاربر، هویت تازه بسازد.
مقدار حساس خام را وارد کلید قابل مشاهده نکنید. شناسه canonical یا keyed، نگاشت آن و مخزن کش را محافظت کنید.
پاسخ کششده فقط متن و زمان انقضا نیست. شروط تولید را نیز ذخیره کنید:
این پاکت پاسخ میدهد: «کدام کاربران میتوانند آن را ببینند؟»، «چه شاهدی آن را معتبر کرده؟»، «کدام انتشار آن را ساخته؟» و «چه رویدادی باید آن را لغو کند؟» این نظم مکمل مشاهدهپذیری کیفیت داده است؛ منبع ممکن است بهموقع برسد اما پاسخ کششده هنوز معنای قبلی را حمل کند.
یک TTL دلخواه مسئله واقعی ابطال را پنهان میکند. تازگی پاسخ را از کوتاهعمرترین وابستگی و رویدادهای صریح محاسبه کنید.
اگر پاسخ بر سه منبع، یک نسخه سیاست و کنترل مجوز متکی است، عمر ایمن آن نمیتواند از زودترین انقضای آنها بیشتر باشد. رویدادهای زیر ممکن است این عمر را کوتاهتر کنند:
وابستگی نسخهدار و نمایه معکوس بسازید تا هر رویداد ورودیهای متأثر را پیدا کند. اگر ابطال به جستوجوی متن مبهم پاسخ نیاز دارد، معماری در لحظه ضروری شکست میخورد. «حذف همه» کنترل اضطراری مفیدی است، اما جای lineage را نمیگیرد.
سرو پاسخ کهنه هنگام اعتبارسنجی مجدد شاید برای راهنمای عمومی کمخطر با تاریخ آشکار مناسب باشد. برای مجوز، مانده، تأیید، وضعیت رخداد یا سیاستی که اقدامی را مجاز یا ممنوع میکند معمولاً مناسب نیست.
شباهت embedding باید نامزد پیدا کند، نه مجوز ضربه بدهد. نامزد معنایی فقط زمانی سرو میشود که شروط قطعی منطبق باشند:
آزمون آخر میتواند قاعده، classifier کوچک و verifier را ترکیب کند، اما verifier هم خطاپذیر است. باید روی negative دشوار سنجیده شود: جملههای بسیار شبیهی که نفی، عامل، تاریخ، ارز، آستانه، حوزه قضایی یا اقدام را عوض میکنند. در صورت تردید verifier، کش باید miss شود.
هرگز اعتمادبهنفس تولیدشده را مجوز بازاستفاده ندانید. حذف قطعی و مجموعه آزمون برچسبدار مستقل ارجح است. شباهت زیاد برای جستوجو مفید است؛ مرز تأیید نیست.
دستیار خریدی را در نظر بگیرید که سیاست را به فارسی و انگلیسی توضیح میدهد. قاعدهای عمومی میگوید خرید بالاتر از آستانه معمولاً به استعلام قیمت نیاز دارد. پاسخ فارسی ذخیرهشده برای شرکت عملیاتی تهران، تحت سیاست PROC-17.4، با مبلغ تومان و استثنای مشخص تعمیر اضطراری ساخته شده است.
پرسش بعدی میگوید: «میتوانیم این قطعه فوری را بدون سه استعلام بخریم؟» از نظر معنایی نزدیک است. دروازه پیش از بازاستفاده میفهمد درخواستکننده در شرکت تابعه دیگری با سیاست PROC-19.1 است، مبلغ از آستانه آن شرکت بیشتر است و استثنای اضطراری به تأییدکننده نامدار نیاز دارد. کش معنایی باید miss شود.
سامانه همچنان میتواند کار ذخیره کند:
اگر پرسش فقط «تطبیق سهطرفه چیست؟» باشد و تعریف عمومی، نسخهدار، غیرشخصی و در همه شرکتها یکسان بماند، نامزد معنایی میتواند عبور کند. تفاوت در شباهت زبانی نیست؛ پرسش این است که آیا همه متغیرهای تغییردهنده تصمیم همارز ماندهاند.
کش پاسخ هم مخزن محتواست و هم سامانه مسیریابی. هر دو را threat model کنید.
کمترین دسترسی، رمزگذاری، جداسازی namespace، محدودیت نگهداری، انتشار حذف، حفاظت تمامیت و لاگ دسترسی را اجرا کنید. embedding را ناشناس فرض نکنید؛ از محتوا مشتق شده و ممکن است حساس باشد. دستور پرامپت سیستمی برای افشانکردن راز، سازوکار جداسازی کش نیست؛ همانطور که OWASP هشدار میدهد محدودیت پرامپت قابل دورزدن است.
کش معنایی را ابتدا در حالت سایه اجرا کنید. برای هر نامزد، مسیر عادی پاسخ تازه بسازد و هر دو نتیجه با شاهد جاری مقایسه شود. مجموعه برچسبدار باید جفت عادی، تکرار دقیق و near-match خصمانه داشته باشد.
سنجهها:
اگر ترافیک ناایمن موفقیت شمرده شود، نرخ ضربه سنجه نمایشی است. نتیجه را بر اساس زبان، مستأجر، گردشکار، سیاست و موجودیت نادر برش دهید؛ فارسی، انگلیسی و بازیابی بینزبانی را بسنجید و parity را فرض نکنید.
هر تصمیم بازاستفاده را در ردپای شواهد آماده حسابرسی ثبت کنید: ورودی نامزد، شروط منطبق، نتیجه تازگی، نسخه سیاست، سرو یا رد و تناقض بعدی. برای مشاهدهپذیری کش، محتوای حفاظتشده غیرضروری را لاگ نکنید.
کش پیشوند ارائهدهنده را وقتی فعال کنید که جداسازی، نگهداری و پردازش داده آن سازگار است. کش دقیق پاسخ به کلید کامل تصمیم و ابطال رویدادمحور نیاز دارد. بازاستفاده معنایی را به فهرست کمپیامد و قبولی آزمون سایه، negative دشوار، حریم خصوصی، حذف و rollback محدود کنید.
یک bypass سراسری و purge در سطح namespace نگه دارید. هنگام مهاجرت سیاست یا رخداد، miss پاک از پاسخ سریع و غلط بهتر است. با تغییر معنای کش ارائهدهنده، گذرنامه انتشار، ورود کلاس داده تازه به پرامپت، ریزترشدن مجوز، کوتاهشدن اعتبار منابع یا اقدام مستقیم کاربر بر پایه جواب، دروازه را بازبینی کنید.
سریعترین پاسخ آن نیست که زودتر میرسد؛ پاسخی است که پس از درنظرگرفتن کاربر، سیاست، شاهد و وضعیت سامانه همچنان درست میماند. محاسبه را هرجا مرزش روشن است آزادانه کش کنید. نتیجه را فقط زمانی بازاستفاده کنید که همارزی متناسب با پیامد اثبات شده باشد.

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