دربارهٔ این فصل
یادداشتِ همراه نوارتا حالا به این فکر کرده‌اید که وقتی با یک دستیار هوش مصنوعی صحبت می‌کنید، چطور درخواست ساده‌ی شما به یک پاسخ دقیق تبدیل می‌شود؟ در پشت صحنه چه اتفاقی می‌افتد که مدل متنی ما می‌تواند بلیت هواپیما رزرو کند یا کدهای برنامه‌نویسی را اصلاح کند؟
در کتاب «مهندسی پرامپت برای مدل‌های زبانی بزرگ» نوشتهٔ «جان بریمن و آلبرت زیگلر»، فصل چهارم به طراحی برنامه‌های کاربردی مبتنی بر این مدل‌ها اختصاص دارد و نشان می‌دهد که چطور باید پل ارتباطی میان دنیای مسائل انسانی و دنیای مستندات مدل ساخت.
اولین ایده کلیدی این است که اپلیکیشن‌های هوش مصنوعی در واقع یک چرخه یا حلقه هستند که مسئله را از کاربر دریافت کرده، به زبان مدل تبدیل می‌کنند و بعد پاسخ را به دنیای واقعی برمی‌گردانند. مسئله اینجاست که مدل‌های زبانی بزرگ کار خاصی نمی‌کنند جز تکمیل سند پرامپت (Prompt)، که به متن‌هایی گفته می‌شود که به مدل زبانی داده می‌شود تا خروجی تولید کند. نویسندگان این روش را اصل شنل‌قرمزی می‌نامند؛ یعنی نباید از مسیری که مدل برای آن آموزش دیده دور شویم و پرامپت ما باید شبیه اسناد موجود در داده‌های آموزشی باشد تا خروجی قابل پیش‌بینی و پایداری به دست آوریم. برای نمونه، در یک برنامه توصیف سفر، ساختار دادن به متن با استفاده از علامت‌های مشخص یا قالب تکالیف درسی کمک می‌کند مدل دقیقا همان الگو را دنبال کند.
ایده دوم به ساختاردهی و آماده‌سازی جریان جلوبر فیدفوروارد مربوط می‌شود که شامل استخراج زمینه، خرد کردن متن به تکه‌های کوچک‌تر و ارزیابی اهمیت آن‌هاست. مشکل اینجاست که اگر اطلاعات زیادی به مدل بدهیم، دچار حواس‌پرتی می‌شود و اگر اطلاعات کم بدهیم، پاسخ درستی نمی‌گیرد. راهکار این است که تکه‌های متن را اولویت‌بندی کنیم و مطمئن شویم که از پنجرهٔ زمینه (Context Window) که به حداکثر حجم متن یا توکنی گفته می‌شود که مدل در یک درخواست می‌بیند، فراتر نمی‌رویم. برای مثال، اگر در یک برنامه پشتیبانی فنی، جستجویی در مستندات انجام می‌شود، باید فقط بخش‌های واقعاً مرتبط را استخراج کنیم و در پرامپت قرار دهیم.
ایده سوم به موضوع بسیار مهم تولید مبتنی بر بازیابی (RAG) مربوط می‌شود که به معنای ترکیب جستجو در منابع با تولید پاسخ است. مدل‌های زبانی به تمام اطلاعات دنیا دسترسی ندارند و اطلاعات پشت دیوارهای امنیتی شرکت‌ها را نمی‌دانند؛ بنابراین اگر پاسخ را حدس بزنند، به توهم‌زایی (Hallucination) دچار می‌شوند، که یعنی اطلاعات نادرست را با لحن کاملاً مطمئن تولید می‌کنند. گزینهٔ پیش رو استفاده از ابزارهای جستجو یا پایگاه‌های داده برداری است تا اطلاعات به‌روز و اختصاصی قبل از ساخت پرامپت از منابع بازیابی شده و به مدل تزریق شود. برای نمونه، در یک دستیار سفر، سیستم باید داده‌های مربوط به پروازها و توصیه‌های دولتی را از طریق ابزارهای خارجی جستجو کرده و در اختیار مدل بگذارد.
ایده چهارم دربارهٔ استفاده از ابزار و استدلال گام‌به‌گام است. مدل‌های زبانی به صورت پیش‌فرض در یک دنیای بسته کار می‌کنند و نمی‌توانند تغییری در دنیای خارج ایجاد کنند. مبادلهٔ مداوم بین برنامه و مدل از طریق زنجیرهٔ فکر (Chain-of-Thought)، که به معنای واداشتن مدل به بیان مراحل استدلال پیش از ارائه پاسخ نهایی است، کیفیت تصمیم‌گیری را به شدت بالا می‌برد. مبادلهٔ ابزار به مدل اجازه می‌دهد که توابع مشخصی را صدا بزند. مثلاً وقتی کاربر درخواست خرید بلیت دارد، مدل یک درخواست ساختاریافته برای اجرای تابع صادر می‌کند و اپلیکیشن پس از تأیید کاربر، عملیات خرید را در دنیای واقعی انجام می‌دهد.
ایده پنجم ارزیابی کیفیت این برنامه‌ها پیش و پس از انتشار است. مشکل اینجاست که مدل‌های زبانی رفتار احتمالی دارند و ممکن است دچار خطا شوند؛ بنابراین طراحان باید هم ارزیابی آفلاین با کمک داوران مصنوعی یا سناریوهای تستی داشته باشند و هم با استفاده از داده‌های تله‌متری و نرخ پذیرش خروجی‌ها در خط تولید، کیفیت کار را زیر نظر بگیرند. برای نمونه، در گیت‌هاب کوپایلوت، نرخ پذیرش کدهای پیشنهادی توسط توسعه‌دهندگان به عنوان یک معیار ضمنی برای سنجش بهره‌وری و رضایت کاربران اندازه گیری می‌شود.
پیشنهاد من به شما این است که وقتی برنامه‌ای بر پایهٔ هوش مصنوعی می‌سازید، هرگز به پاسخ‌های اولیه اتکا نکنید و با تعریف دقیق محدوده‌ها، به مدل اجازه ندهید بدون کنترل صحبت کند. طراحی اصولی پرامپت‌ها و نظارت مداوم بر رفتار مدل، تفاوت اصلی بین یک پروژه موفق و یک ابزار غیرقابل‌اعتماد است.
امیدوارم این مرور کوتاه به شما کمک کرده باشد دید روشن‌تری نسبت به ساخت برنامه‌های مبتنی بر مدل‌های زبانی پیدا کنید. تا برنامه‌ای دیگر و کتابی دیگر، روزگارتان خوش.