فصل نهم: جریان کارهای مدل زبانی بزرگ

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

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

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

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

سومین ایده پیاده‌سازی وظایف مبتنی بر ابزار و قالب‌های پرامپت است. مشکل این است که استخراج اطلاعات آزاد از متن وب‌سایت‌ها ممکن است نامنظم و نامعتبر باشد. گزینه‌های پیش رو شامل استفاده از الگوهای متنی یا تعریف ابزارهای ساختاریافته است. معاوضه این است که ابزارها کار را دقیق‌تر می‌کنند اما طراحی و نگهداری کدهای واسط پیچیده‌تر می‌شود. برای مثال، تعریف کردن یک تابع مشخص برای استخراج نام و آدرس رستوران باعث می‌شود مدل خروجی ساخت‌یافته (Structured Output) تولید کند و اطلاعات دقیقا همان‌طور که می‌خواهیم وارد پایگاه داده شود.

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

پنجمین ایده انتخاب ساختار ارتباطی مناسب بین وظایف است. مشکل این است که نحوهٔ تبادل داده‌ها تعیین می‌کند سیستم چقدر انعطاف‌پذیر یا پیچیده خواهد بود. گزینه‌ها شامل خطوط لوله خطی، گراف جهت‌دار غیرمدور (Directed Acyclic Graph) و شبکه‌های چرخشی هستند. گراف جهت‌دار غیرمدور به مجموعه‌ای از وظایف متصل گفته می‌شود که اطلاعات تنها در یک جهت رو به جلو جریان دارد و هیچ حلقه بسته‌ای تشکیل نمی‌شود. معاوضه این است که افزودن حلقه‌های بازگشتی برای اصلاح خطاها قدرت سیستم را بالا می‌برد اما درک و دیباگ کردن آن را به‌شدت دشوار می‌کند. برای مثال، اگر کیفیت ایمیل تولیدشده پایین باشد، بازگرداندن آن به مراحل اولیه نیازمند مدیریت دقیق تعداد دفعات تلاش مجدد است.

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

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