تیپ #۳۰

ذخیره‌سازی موقت پرامپت‌ها و نتیجهٔ ابزارها

بخش زیادی از هزینه و تأخیر یک ایجنت از تکرار بی‌فایده می‌آید: هر نوبت همان system prompt، همان تعریف ابزارها و همان اسناد بازیابی‌شده دوباره فرستاده می‌شوند. اگر بخش‌های ثابت را ابتدای پرامپت بگذارید و فقط پیام تازهٔ کاربر یا خروجی ابزار را به انت‌ها اضافه کنید، سرویس‌دهنده می‌تواند آن پیشوند را از کش بخواند و هزینهٔ توکن‌ها را چند برابر کم کند. همین منطق را به ابزارها هم ببرید: کلید کش را از نام ابزار و آرگومان‌هایش بسازید و نتیجهٔ فراخوانی‌های قطعی و فقط‌خواندنی را دوباره استفاده کنید ♻️، اما برای ابزارهایی که عارضهٔ جانبی دارند یا داده‌شان سریع عوض می‌شود کش را کنار بگذارید. کشی که هیچ‌وقت باطل نمی‌شود، در واقع یک باگ است که تأخیرش کم شده.

توضیح کامل‌تر

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