پنجره زمینه بلند مفید است؛ معماری زمینه مهم‌تر است

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

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

ظرفیت، طراحی را خط نمی‌زند

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

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

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

زمینه لایه‌ای

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

چهار لایه برای بیشتر محصول‌ها کافی است.

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

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

سوم، شواهد همین سؤال: چند قطعه سند، یک قرارداد، یک diff. با شناسه و منبع، نه با خمیر بی‌نام. اگر جواب باید قابل بررسی باشد، مدل و کاربر هر دو باید بدانند شاهد از کجا آمده.

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

اپ چه چیزی را نباید به مدل بدهد

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

داده حساس را به امید پنجره بزرگ داخل درخواست نریز. زمینه بلند مجوز نیست. اگر سند نباید برای این کاربر قابل دیدن باشد، نباید در بسته زمینه باشد، حتی اگر مدل «قول بدهد» نقل نکند. فیلتر را قبل از مدل انجام بده.

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

این در کار روزانه کجا دیده می‌شود

تیم بلیت را جور دیگری می‌نویسد. به‌جای «زمینه را بیشتر کن تا بهتر جواب دهد»، می‌پرسد کدام لایه غایب است. کش را روی لایه پایدار می‌گذارد نه روی کل درخواست. endpoint تعاملی را از بسته زمینه غول جدا می‌کند. راه‌حل موقتی که کل ویکی را به پرامپت می‌چسباند بالاخره حذف می‌شود، چون بودجه تأخیر و هزینه دیگر جا نمی‌دهد.

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

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

این هفته

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

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

زمینه بلند قدرتمند است. زمینه گزیده‌شده است که قابل اعتمادش می‌کند.

پرسش‌های کوتاه

**پس پنجره بزرگ بی‌فایده است؟** نه. برای سندی که واقعاً باید یک‌جا دیده شود مفید است. جایگزین انتخاب شاهد نیست.

**تاریخچه چت را تا کجا نگه دارم؟** تصمیم‌های تمام‌شده را خلاصه کن. متن خام را برای دیباگ کوتاه‌مدت نگه دار، نه به‌عنوان ورودی همیشگی مدل.

**اگر مدل با زمینه کم اشتباه کرد؟** اول ببین شاهد درست غایب بود یا دستور متناقض بود. پر کردن پنجره تشخیص را عقب می‌اندازد.