ذخیرهٔ پاسخ‌های تکراری می‌تواند بخشی از طراحی یک دستیار سازمانی باشد، اما پرسش یکسان همیشه به معنی پاسخ قابل اشتراک نیست. دو کاربر ممکن است همان سؤال را بپرسند و به اسناد متفاوتی دسترسی داشته باشند. همچنین پاسخ دیروز ممکن است پس از تغییر یک دستورالعمل اعتبار نداشته باشد. این مقاله یک معماری پیشنهادی برای کش پاسخ ارائه می‌کند؛ سناریوها فرضی‌اند و هیچ افزایش سرعت یا صرفه‌جویی مشخصی برای محصولی ادعا نمی‌شود.
در راهنمای کش پرامپت OpenAI، موضوع اصلی استفادهٔ دوباره از بخش مناسب ورودی مدل است. این مفهوم با نگهداری پاسخ نهایی در برنامه تفاوت دارد. راهنمای افشای اطلاعات حساس OWASP نیز یادآوری می‌کند که اطلاعات حساس می‌توانند از زمینه و خروجی سامانه آشکار شوند. طرح‌های اجرایی ادامهٔ مقاله پیشنهاد نویسنده برای بررسی در پروژه‌اند.
۱. کش پرامپت و کش پاسخ را جدا طراحی کنید
ابتدا مشخص کنید چه چیزی ذخیره می‌شود. در کش پاسخ برنامه، متن آماده یا نتیجهٔ ساختاریافتهٔ یک درخواست نگهداری می‌شود تا بعداً دوباره مصرف شود. در کش پرامپت ارائه‌دهنده، رفتار استفادهٔ دوباره از ورودی مدل به سازوکار و شرایط همان خدمت وابسته است. اشتراک واژهٔ «کش» نباید باعث شود تیم قواعد اعتبار پاسخ را از قواعد فنی ورودی نتیجه بگیرد.
در پیشنهاد این مقاله، برگهٔ طراحی دو ستون جدا دارد: دادهٔ ذخیره‌شده و شرط استفادهٔ دوباره. برای یک پاسخ دربارهٔ ساعت عمومی خدمت، شرط‌ها با پاسخ دربارهٔ وضعیت پروندهٔ شخصی متفاوت‌اند. دربارهٔ مورد دوم، حتی متن سؤال بسیار عمومی ممکن است نتیجهٔ خصوصی داشته باشد. پیش از انتخاب ابزار ذخیره‌سازی، دامنهٔ مجاز هر نوع نتیجه را بنویسید.
عدم استفاده از کش پاسخ نیز یک انتخاب معتبر است. اگر نتیجه به وضعیت زنده، مجوزهای متغیر یا اطلاعات حساس وابستگی زیادی دارد، هزینهٔ بررسی و بی‌اعتبارسازی ممکن است از فایدهٔ آن بیشتر باشد. این تصمیم را با اندازه‌گیری روی کاربرد واقعی بگیرید. عدد صرفه‌جویی در یک راهنمای ارائه‌دهنده، نتیجهٔ قطعی برای معماری و الگوی درخواست سازمان شما نیست.
۲. کلید کش را به دامنهٔ مجاز و نسخهٔ دانش وابسته کنید
کلید مبتنی بر متن سؤال، برای پاسخ سازمانی اغلب اطلاعات کافی ندارد. در الگوی پیشنهادی ما، شناسهٔ سازمان، محدودهٔ دسترسی مؤثر، نسخهٔ دانش و تنظیمات مؤثر تولید پاسخ در شرط اعتبار لحاظ می‌شوند. این فهرست نسخهٔ آماده برای همهٔ سامانه‌ها نیست؛ تیم باید مشخص کند چه عامل دیگری می‌تواند پاسخ مجاز یا معنی آن را تغییر دهد.
برای نمونهٔ فرضی، پاسخ کارشناس فروش به یک سؤال داخلی نباید فقط به دلیل یکسان بودن متن پرسش برای مراجعه‌کنندهٔ عمومی بازگردانده شود. جداسازی نام سازمان نیز به‌تنهایی همهٔ مرزها را پوشش نمی‌دهد؛ کاربران همان سازمان ممکن است مجوزهای مختلفی داشته باشند. بهتر است کنترل مجوز هنگام دریافت نتیجه دوباره انجام شود و وابستگی پاسخ به منابع اصلی قابل بررسی بماند.
از وارد کردن اطلاعات حساس خام در کلیدهای قابل مشاهده خودداری کنید. کلید ممکن است در ابزار عیب‌یابی یا گزارش زیرساخت دیده شود. در پیشنهاد طراحی، شناسه‌های داخلی محدود و توصیف نسخه به کار می‌روند، اما همان شناسه‌ها نیز به کنترل دسترسی و سیاست نگهداری نیاز دارند. هش کردن مقدار، به‌خودی‌خود مجوز اشتراک نتیجه یا ناشناس بودن کامل داده را تضمین نمی‌کند.
۳. تغییر سند و مجوز را به بی‌اعتبارسازی متصل کنید
زمان انقضا تنها راه کنترل اعتبار نیست. اگر سندی پیش از پایان عمر کش بازنشسته شود، پاسخ وابسته به آن باید طبق قواعد سامانه دوباره بررسی شود. در الگوی پیشنهادی، هر پاسخ شناسهٔ نسخه‌های مورد استفاده را همراه دارد. تغییر وضعیت نسخه می‌تواند نتیجه را نامعتبر کند یا پیش از مصرف، دروازهٔ بررسی نسخه مانع استفادهٔ آن شود.
تغییر مجوز نیز حالت مستقلی است. کاربری که دیروز عضو یک گروه بوده، شاید امروز دیگر اجازهٔ مشاهدهٔ همان اطلاعات را نداشته باشد. باقی ماندن یک نتیجهٔ ذخیره‌شده نباید جای تصمیم فعلی دسترسی را بگیرد. برای آزمون، ابتدا پاسخ مجاز تولید کنید، سپس نقش کاربر آزمایشی را تغییر دهید و درخواست یکسان را تکرار کنید. نتیجهٔ مورد انتظار باید پیشاپیش در قرارداد نوشته شود.
برای رخدادهای مهم، مسیر بی‌اعتبارسازی و مسیر بررسی هنگام خواندن را با هم بسنجید. تکیه بر یک پیام تغییر که ممکن است دیر برسد، تصمیمی است که به رفتار زیرساخت وابسته است. پیشنهاد ما تعریف رفتار در زمان نامعلوم بودن نسخه یا مجوز است: توقف مصرف نتیجه، بازیابی مجدد یا پاسخ محدود. انتخاب مناسب به حساسیت اطلاعات و نیاز خدمت بستگی دارد.
۴. دادهٔ ذخیره‌شده و گزارش‌های آن را محدود کنید
کش پاسخ می‌تواند نسخهٔ دیگری از اطلاعات سازمان باشد. پیش از ذخیره، تعیین کنید کدام فیلدها واقعاً برای استفادهٔ دوباره لازم‌اند. متن کامل مکالمه، اطلاعات هویتی و جزئیات اضافی خطا نباید صرفاً چون در پاسخ اولیه وجود داشته‌اند، وارد همهٔ لایه‌ها شوند. OWASP افشای اطلاعات حساس از زمینه و خروجی را یک دستهٔ خطر معرفی می‌کند؛ کاهش دادهٔ غیرضروری بخشی از بررسی همین مرز است.
در پیشنهاد اجرایی، گزارش رویداد کش شامل نوع نتیجه، شناسهٔ محدود درخواست و دلیل استفاده یا رد می‌شود. ثبت متن کامل سؤال و پاسخ برای شمارش برخورد کش، معمولاً تصمیم جداگانه‌ای است و باید نیازش روشن باشد. اگر بررسی موردی به متن نیاز دارد، دسترسی و مدت نگهداری آن را با سیاست مشخص تنظیم کنید. گزارش فنی نیز می‌تواند محل نگهداری دادهٔ حساس شود.
مسیر حذف را از ابتدا ببینید. پاک کردن یک کلید از حافظه الزاماً همهٔ نسخه‌های متن در گزارش، نسخهٔ پشتیبان یا سامانهٔ نظارت را حذف نمی‌کند. فهرستی از محل‌های نگهداری پاسخ بسازید تا درخواست حذف یا اصلاح، فقط به لایهٔ اصلی محدود نماند. این مقاله دستور حقوقی دربارهٔ نگهداری داده نیست؛ پیشنهاد معماری برای شناخت نسخه‌های اطلاعات است.
۵. سود و شکست کش را با آزمون‌های جدا گزارش کنید
آزمون فنی را به شمارش پاسخ‌های سریع محدود نکنید. برای مجموعهٔ ساختگی، سؤال یکسان با کاربر متفاوت، سند تازه، مجوز لغوشده و نتیجهٔ منقضی اجرا کنید. همچنین حالت قطع سرویس کش را بررسی کنید. برنامه باید طبق طراحی به مسیر جایگزین برود و نباید برای جبران خرابی، نتیجهٔ خارج از دامنه را به کاربر نشان دهد.
سنجش فایده باید شرایط یکسان داشته باشد. زمان پاسخ، هزینهٔ محاسبه و حجم دادهٔ ذخیره‌شده را جدا ثبت کنید و دلیل نامعتبر شدن نتیجه را نیز بشمارید. برخورد زیاد با کش ممکن است ناشی از اعتبار بیش از حد بلند باشد، نه کیفیت معماری. یک امتیاز کلی نمی‌تواند هم‌زمان دربارهٔ سرعت، تازگی و کنترل دسترسی نتیجهٔ روشن بدهد.
پیش از گسترش استفاده، یک گزارش کوتاه شامل دامنهٔ پاسخ‌های قابل کش، شرط اعتبار، مسیر تغییر دانش و آزمون مرز دسترسی آماده کنید. اگر یک دستهٔ اطلاعات هنوز رفتار قابل بررسی ندارد، آن را از دامنهٔ کش خارج نگه دارید تا طراحی تکمیل شود. کش مناسب باید به نیاز پاسخ‌گویی خدمت کند و وابستگی پاسخ به دانش معتبر و مخاطب مجاز را حفظ کند.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
