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

نویسنده با یه مثال واقعی شروع می‌کنه: یه تیم یه ایجنت راه انداخته بود که هر صبح یه API متریک رو بخونه، JSON رو شکل بده و توی یه جدول بذاره. کار روز اول جواب داد، ولی بعد صورت‌حساب اومد. هر صبح چند هزار توکن JSON خام می‌رفت توی پنجرهٔ زمینه تا مدل داده‌ای رو دوباره قالب‌بندی کنه که اصلاً نیازی به فکر کردن نداشت، گاهی هم اشتباه می‌کرد، چون یه مدل احتمالاتی داشت کاری رو انجام می‌داد که یه اسکریپت پنج‌خطی هر بار یکسان انجامش می‌ده.

به گفتهٔ نویسنده این تله الان تقریباً همه رو گیر می‌ندازه. تیم‌ها مدل زبانی رو مثل یه رانتایمِ همه‌کاره می‌بینن: هر چیزی که با یه جمله توصیف بشه رو بهش پرامپت می‌دن. ولی مدل یه موتور استدلاله که به‌ازای هر توکن اجاره‌ش می‌کنی؛ اگه بذاریش سرِ یه کرون‌جاب یا مجبورش کنی داده‌تو نگه داره، برای کاری که اصلاً مغز نمی‌خواسته پول اضافه می‌دی. نویسنده به حرف ایوان بورازین از Daytona هم اشاره می‌کنه که همین نکته رو گفته.

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

مدلِ ذهنی‌ای که نویسنده پیشنهاد می‌ده ساده‌ست: هر کار توی یکی از دو سطل می‌افته. کاری که قضاوت و تفسیر می‌خواد — مثل پیش‌نویس، خلاصه‌سازی، دسته‌بندی و تصمیم دربارهٔ اینکه چیزی مهمه یا نه — مالِ ایجنته. کاری که باید دقیق و تکرارپذیر باشه — مثل کارهای زمان‌بندی‌شده، صدا زدن API، تبدیل داده و ذخیره و کوئری — مالِ یه اپلیکیشن قطعیه. ایدهٔ اصلی اینه که اپ رو یه بار با توکن می‌سازی، بعد دیگه بابت هر اجرا توکن نمی‌دی.

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

نویسنده در آخر یه چک‌لیست می‌ده: قبل از پرامپت زدن بپرس این کار قضاوت می‌خواد یا مکانیکیه، آیا زمان‌بندی‌شده تکرار می‌شه، آیا ایجنت داره مستقیم API صدا می‌زنه، و آیا داده توی زمینه هست که روش استدلال بشه یا فقط ذخیره شده. جمع‌بندیش اینه که یه سیستم ایجنتِ خوب هوش رو دقیقاً همون‌جا که ارزششو داره خرج می‌کنه و بقیهٔ کارها رو به کدِ ارزون و قطعی می‌سپره. (این مقاله در بلاگ محصولی به اسم Vybe منتشر شده که همین رویکرد رو محور خودش کرده.)

نکات کلیدی:

• سپردن کار قطعی و تکراری به مدل زبانی سه ضرر داره: بی‌ثباتی، کندی، و هزینهٔ هر اجرا.
• کار رو دو دسته کن: قضاوت و تفسیر برای ایجنت، کار دقیق و تکرارپذیر برای یه اپ قطعی.
• اپ رو یه بار با توکن بساز؛ بعدش مجانی و بی‌خطا می‌چرخه.
• دادهٔ ساختارمند و پرحجم رو توی دیتابیس بذار، نه توی یادداشت‌های حافظهٔ ایجنت.
• شلوغ شدن پنجرهٔ زمینه با دادهٔ خام هم کیفیت استدلال رو پایین میاره هم هزینه رو بالا.