جایگزینی نمونه‌های ایستا با بازیابی پویا هزینه توکن‌ها را کاهش داد

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

بسیاری از توسعه‌دهندگان در حال حاضر چند مثال تکراری را در تمام پرامپت‌ها می‌گنجانند. این رویکرد ایستا زمانی شکست می‌خورد که ورودی کاربر خارج از الگوهای پیش‌بینی‌شده باشد و مدل هیچ راهنمای مرتبطی برای دنبال کردن نداشته باشد. برای هر درخواست خاص، اکثر مثال‌های ایستا به پرکننده‌هایی خارج از موضوع تبدیل می‌شوند که باعث رقیق شدن الگوی مورد نظر مدل می‌گردند. طبق راهنمای فنی منتشر شده در ۹ اوت ۲۰۲۶ توسط dev.to، راهکار این است که با مثال‌های پرامپت به‌جای یک رشته متنی ثابت، مانند یک پایگاه‌داده قابل جست‌وجو برخورد کنیم.

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

سازوکار بازیابی

این سامانه با استفاده از الگوریتم نزدیک‌ترین همسایه (kNN) در فضای بردار معنایی (Embedding) — که شبیه کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه‌ی چه کلمات دیگری است — عمل می‌کند. فرآیند طبق مستندات به ترتیب زیر است:

• بردارسازی: هر نمونه برچسب‌دار در یک استخر داده (Pool)، تنها یک‌بار به یک بردار تبدیل می‌شود.
• امتیازدهی پرسش: پرسش کاربر بردارسازی شده و شباهت کسینوسی (Cosine Similarity) آن با مجموعه نمونه‌ها سنجیده می‌شود. شباهت کسینوسی زاویه بین دو بردار را می‌سنجد و اندازه آن‌ها را نادیده می‌گیرد؛ امتیاز ۱.۰ نشان‌دهنده جهت کاملاً یکسان و امتیاز ۰ به معنای عدم اشتراک هیچ وجهی است.
• انتخاب k-برتر: سامانه نمونه‌ها را بر اساس شباهت به صورت نزولی مرتب کرده و $k$ مورد اول (معمولاً بین ۳ تا ۸ مورد) را انتخاب می‌کند.
• سرهم‌بندی: پرامپت به‌صورت بلادرنگ با یک سرتیتر وظیفه (Task Header)، جفت‌های ورودی-برچسب منتخب و در نهایت پرسش کاربر که برچسب آن خالی گذاشته شده، ساخته می‌شود.

به گزارش dev.to، در دموهای ساده از روش TF-IDF (کیسه کلمات) برای تعیین قطعی بودن در مرورگر استفاده می‌شود (جایی که کلمات نادر وزن بیشتری دارند)، اما در محیط‌های عملیاتی و تولیدی، این روش جای خود را به مدل‌های بردارسازی متراکم (Dense Embedding) می‌دهد تا مترادف‌هایی مثل «لغو» و «انصراف» به‌درستی شناسایی شوند.

جزئیات پیاده‌سازی

برای اجرای این سیستم، از یک تابع cosine برای محاسبه حاصل‌ضرب داخلی دو بردار تقسیم بر ریشه دوم توان magnitudes (بزرگی بردارها) استفاده می‌شود. سپس تابع selectExemplars مجموعه داده را به امتیازات شباهت نگاشت کرده و نتایج برتر (Top-k) را برش می‌دهد.

در یک تسک طبقه‌بندی، تابع assemblePrompt رشته نهایی را می‌سازد. این تابع با یک سرتیتر شروع می‌شود که برچسب‌های مجاز را مشخص می‌کند (مثلاً: صورت‌حساب، ارسال، فنی، حساب کاربری، لغو، بازخورد)، سپس نمونه‌های منتخب را به هم متصل کرده و در نهایت پرسش کاربر را می‌افزاید. برای مثال، در یک پرسش مربوط به لغو اشتراک، یک مجموعه ایستا از مثال‌های «صورت‌حساب» یا «ارسال» هیچ نکته مرتبطی ارائه نمی‌دهد، در حالی که بازیاب پویا دقیقاً نمونه‌های مربوط به «لغو» را بیرون می‌کشد.

بهینه‌سازی انتخاب

انتخاب مقدار $k$ یک موازنه حساس است. مقدار $k=1$ بیش از حد شکننده است، زیرا کل پرامپت به یک مثال واحد وابسته می‌شود. در مقابل، $k$ بسیار بزرگ باعث می‌شود سیستم از نمونه‌های واقعاً مشابه عبور کرده و به نمونه‌های غیرمرتبط برسد؛ این امر دوباره مشکل پرامپت‌های ایستا را بازمی‌گرداند و باعث افزایش تأخیر و مصرف توکن‌ها می‌شود.

برای جلوگیری از انتخاب نمونه‌های تقریباً تکراری، توسعه‌دهندگان می‌توانند از مرتبط‌ترین حاشیه بیشینه (MMR) استفاده کنند. MMR نتایج k-برتر را بازرتبه‌بندی می‌کند تا تعادلی بین مرتبط بودن و تنوع ایجاد شود و با استفاده از یک پارامتر قابل تنظیم $\lambda$، تکرار را جریمه کند: score = lambda * rel - (1 - lambda) * red. در این فرمول، $\lambda=1$ منجر به مرتبط بودن خالص می‌شود، در حالی که مقادیر کمتر، تنوع را افزایش می‌دهند.

این سازوکار در واقع پسرعموی تولید بازیابی‌افزا (RAG) — مثل دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — است. در حالی که RAG برای استخراج حقایق جهت مستند کردن محتوا است، پرامپت‌نویسی پویا برای استخراج مثال‌ها جهت شکل دادن به رفتار مدل به کار می‌رود. در اینجا، استخر داده‌ها به عنوان دانش مدل عمل می‌کند، بنابراین باید برای پوشش کامل و برچسب‌های صحیح، بر اساس ورودی‌های واقعی ثبت‌شده (Logged Inputs) پرورش یابد.

برای کسانی که این سیستم را برای میلیون‌ها نمونه مقیاس‌بندی می‌کنند، پیش‌محاسبه بردارهای استخر و ذخیره آن‌ها در یک شاخص نزدیک‌ترین همسایه تقریبی (ANN) سرعت بازیابی را در سطح $O(\log n)$ نگه می‌دارد تا استنتاج دچار گلوگاه نشود.

گام بعدی شما

• بررسی کنید کدام بخش از پرامپت‌های شما شامل مثال‌های تکراری و ایستا است.
• برای تسک‌های طبقه‌بندی پیچیده، یک مجموعه داده از نمونه‌های واقعی (Logged Inputs) جمع‌آوری کنید.
• منطق بازیابی پویا را در محیط dev48v.infy.uk با بلوک‌های ایستا مقایسه کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.