نویسنده(های): نیت لیبمن
در ابتدا منتشر شد به سمت هوش مصنوعی.
با نزدیک شدن به دومین سالگرد زلزله ChatGPT، به نظر می رسد عجله برای ساخت برنامه های کاربردی مفید بر اساس مدل های زبان بزرگ (LLM) مشابه آن بسیار زیاد است. اما علیرغم هاله ای از جادویی که در اطراف دموهای نمایندگان LLM یا مکالمات درگیر وجود دارد، مطمئن هستم که بسیاری می توانند با تجربه خودم در توسعه برنامه های کاربردی مبتنی بر LLM ارتباط برقرار کنند: شما با مثالی شروع می کنید که به نظر می رسد عالی کار می کند، اما پشیمانی خریدار به زودی به دنبال خواهد داشت. . آزمودن انواع دیگر این کار به سادگی می‌تواند به‌شدت شکست بخورد، بدون اینکه تمایز مشخصی داشته باشد. و جریان‌های عاملی می‌توانند تمایل خود را به واگرایی در هنگام دور شدن از مسیر شاد اولیه نمونه‌سازی اولیه نشان دهند.
اگر این عنوان نبود، شاید در این مرحله فکر می کردید که من یک هستم هوش مصنوعی مولد luddite، که نمی تواند دور از حقیقت باشد. سفر من و تیم من در Torq در دو سال گذشته، توسعه ویژگی‌های نرم‌افزار مبتنی بر LLM که تجربه ساخت اتوماسیون بدون کد را در پلتفرم ما بهبود می‌بخشد، به من چیزهای زیادی درباره قدرت بزرگ LLM آموخته است – در صورت مدیریت به درستی
از اینجا به بعد، من سه اصل اصلی را مورد بحث قرار می‌دهم که توسعه ما را هدایت می‌کنند و به نمایندگان ما اجازه می‌دهند تا به استقرار موفقیت‌آمیز تولید و سودمندی مشتری برسند. من معتقدم که آنها به همان اندازه با سایر برنامه های کاربردی مبتنی بر LLM مرتبط هستند.
❶ اصل کمترین آزادی
LLM ها از طریق متن آزاد تعامل دارند، اما همیشه این طوری نیست که کاربران ما با برنامه مبتنی بر LLM ما تعامل داشته باشند. در بسیاری از موارد، حتی اگر ورودی در واقع یک توصیف متنی باشد که توسط کاربر ارائه شده است، خروجی بسیار ساختارمندتر است و می‌تواند برای انجام اقدامات خودکار در برنامه مورد استفاده قرار گیرد. در چنین شرایطی، قدرت بزرگ در توانایی LLM برای حل برخی از وظایف که در غیر این صورت نیاز به منطق قطعی عظیم و پیچیده یا مداخله انسانی دارند – می تواند به یک مشکل تبدیل شود. هرچه آزادی عمل بیشتری به LLM بدهیم، درخواست ما بیشتر مستعد است توهمات و جریان های عاملی واگرا. بنابراین، اصل حداقل امتیاز در امنیت، من معتقدم مهم است که LLM را تا حد امکان محدود کنیم.
نماینده ای را در نظر بگیرید که یک عکس فوری از یک لیست دست نوشته خواربار می گیرد، متن را از طریق OCR استخراج می کند، مرتبط ترین اقلام موجود در انبار را پیدا می کند و سفارشی را آماده می کند. ممکن است انتخاب یک جریان عامل چند مرحله ای انعطاف پذیر وسوسه انگیز به نظر برسد که در آن عامل بتواند از روش هایی مانند search_product و add_to_order (شکل 1 را در بالا ببینید). با این حال، این فرآیند می تواند بسیار کند باشد، از مراحل اضافی تشکیل شده است، و حتی ممکن است در یک حلقه گیر کند در صورتی که برخی از تابع ها خطایی را برگرداند که مدل با بازیابی آن مشکل دارد. یک رویکرد جایگزین می‌تواند جریان را به دو مرحله محدود کند، اولی جستجوی دسته‌ای برای دریافت شی درخت محصول فیلتر شده، و دومی ایجاد سفارش بر اساس آن، ارجاع دادن به محصولات مناسب از درخت محصول جزئی که با فراخوانی تابع جستجو بازگردانده شده است. (شکل 2 را در زیر ببینید). جدای از مزیت عملکرد واضح، می‌توانیم بسیار مطمئن‌تر باشیم که نماینده در مسیر باقی می‌ماند و کار را کامل می‌کند.
هنگام برخورد با مشکلات در خروجی تولید شده، من معتقدم که بهتر است تا حد زیادی از اصلاحات به صورت قطعی و بدون دخالت مجدد LLM انجام شود. این به این دلیل است که برخلاف شهود ما، ارسال یک خطا به یک نماینده LLM و درخواست از او برای تصحیح آن، همیشه آن را به مسیر درست باز نمی‌گرداند، و حتی ممکن است احتمال خطاهای بعدی را افزایش دهد. برخی شواهد نشان داده است. با چرخش به نمایندگی خرید مواد غذایی، به احتمال زیاد در برخی موارد مسیرهای JSON نامعتبر برای ارجاع به محصولات تولید می شود (به عنوان مثال، food.cheeses.goats[0] به جای food.dairy.cheeses.goat[0]). از آنجایی که کل سهام را در اختیار داریم، می‌توانیم یک اکتشافی ساده برای رفع خودکار مسیر نادرست به روشی قطعی اعمال کنیم، برای مثال با استفاده از یک الگوریتم فاصله ویرایش برای یافتن نزدیک‌ترین مسیر معتبر به مسیر تولید شده در درخت محصول. حتی در این صورت، برخی از مسیرهای نامعتبر ممکن است بسیار دور از مسیرهای معتبر باشند. در چنین حالتی، ممکن است بخواهیم به جای اضافه کردن خطا به متن و درخواست رفع آن، درخواست LLM را دوباره امتحان کنیم.
❷ ارزیابی تجربی خودکار
برخلاف APIهای شخص ثالث سنتی، فراخوانی یک LLM با ورودی دقیقاً یکسان می‌تواند نتایج متفاوتی در هر بار ایجاد کند. حتی زمانی که هایپر پارامتر دما را روی صفر تنظیم کنید. این در تضاد مستقیم با اصول اساسی مهندسی نرم افزار خوب است، که قرار است تجربه ای مورد انتظار و ثابت را به کاربران بدهد. کلید مقابله با این تضاد، ارزیابی تجربی خودکار است، که من آن را نسخه LLM توسعه آزمایش محور می دانم.
مجموعه ارزیابی را می توان به عنوان یک مجموعه آزمایشی معمولی اجرا کرد که از مزایای یکپارچه سازی طبیعی در چرخه توسعه و خطوط لوله CI/CD برخوردار است. با این حال، بسیار مهم است که LLM ها باید در واقع فراخوانی شوند، و البته مورد تمسخر قرار نگیرند. هر مورد ارزیابی شامل ورودی های کاربر و وضعیت اولیه سیستم و همچنین یک تابع درجه بندی برای خروجی تولید شده یا حالت اصلاح شده است. برخلاف موارد تست سنتی، مفهوم PASS یا FAIL در اینجا ناکافی است، زیرا مجموعه ارزیابی نقش مهمی در هدایت پیشرفت‌ها و پیشرفت‌ها و همچنین گرفتن تخریب‌های ناخواسته دارد. بنابراین، تابع درجه بندی باید برای خروجی یا تغییرات حالتی که نماینده ما ایجاد می کند، یک امتیاز تناسب نشان دهد. چگونه تابع درجه بندی را پیاده سازی کنیم؟ به عنوان مثال، به یک کار ساده LLM برای تولید توابع کاربردی کوچک پایتون فکر کنید. یک مورد ارزیابی می تواند آن را وادار کند که تابعی بنویسد که عنصر n از دنباله فیبوناچی را محاسبه می کند. پیاده سازی مدل ممکن است مسیر تکراری یا بازگشتی را طی کند که هر دو معتبر هستند (اگرچه کمتر از بهینه، زیرا یک عبارت بسته وجود دارد)، بنابراین نمی‌توانیم درباره ویژگی‌های کد تابع اظهارنظر کنیم. با این حال، تابع درجه بندی در این مورد می تواند تعداد انگشت شماری از مقادیر تست را برای آرگومان تابع فیبوناچی بگیرد، یک محیط ایزوله را بچرخاند، تابع تولید شده را روی آن مقادیر اجرا کند و نتایج را تأیید کند. این درجه‌بندی خروجی تولید شده در جعبه سیاه، مفروضات غیرضروری ایجاد نمی‌کند، در حالی که کاملاً آن را به روشی کاملاً قطعی تأیید می‌کند.
در حالی که من معتقدم که باید رویکرد ارجح باشد، برای همه برنامه ها مناسب نیست. مواردی وجود دارد که نمی‌توانیم نتیجه را به طور کامل تأیید کنیم، اما همچنان می‌توانیم درباره برخی از ویژگی‌های آن اظهار نظر کنیم. برای مثال، عاملی را در نظر بگیرید که خلاصه‌های کوتاهی از گزارش‌های سیستم تولید می‌کند. برخی از ویژگی های خروجی آن، مانند طول، به راحتی قابل بررسی است. موارد دیگر، معنایی، نه به اندازه. اگر گزارش‌های تجاری معمولی که به‌عنوان ورودی برای یک مورد ارزیابی استفاده می‌شوند، حاوی یک رکورد واحد در مورد وحشت هسته هستند، می‌خواهیم مطمئن شویم که خلاصه به آن اشاره خواهد کرد. یک رویکرد ساده‌لوحانه برای تابع درجه‌بندی در این مورد شامل یک کار LLM است که مستقیماً یک امتیاز تناسب اندام را برای خلاصه براساس رکوردهای گزارش ایجاد می‌کند. این رویکرد ممکن است ارزیابی ما را در نوعی حلقه رضایت LLM قفل کند، بدون اینکه هیچ یک از تضمین‌هایی که توسط بررسی‌های قطعی ارائه نشده است. با این حال، یک رویکرد ظریف‌تر همچنان می‌تواند از یک LLM برای درجه‌بندی استفاده کند، اما کار را به گونه‌ای متفاوت انجام دهد: با در نظر گرفتن یک خلاصه، می‌توان به مدل دستور داد تا به سؤالات واقعی چند گزینه‌ای پاسخ دهد (مثلاً «آیا یک حادثه بزرگ در دوره تحت پوشش رخ داده است. (الف) خیر (ب) بله، یک وحشت هسته (ج) بله، از دست دادن اتصال به شبکه…”). ما می‌توانیم بسیار مطمئن‌تر باشیم که اگر اطلاعات کلیدی در خلاصه وجود نداشته باشد، LLM به سادگی نمی‌تواند به طور مداوم به چنین سؤالاتی پاسخ دهد، و این باعث می‌شود نمره بسیار قابل اعتمادتر شود.
در نهایت، به دلیل عدم قطعیت، هر مورد ارزیابی باید چندین بار اجرا شود و نتایج جمع آوری شود تا یک گزارش ارزیابی نهایی تشکیل شود. من دریافتم که اجرای زودهنگام مجموعه ارزیابی و استفاده از آن برای هدایت توسعه ما بسیار مفید است. هنگامی که برنامه به بلوغ کامل رسید، اگر امتیاز کلی مجموعه ارزیابی آن به زیر آستانه تعیین شده کاهش یابد، ممکن است شکست خط لوله یکپارچه سازی برای جلوگیری از تخریب فاجعه بار باشد.
❸ نگذارید دم سگ را تکان دهد
نرم افزار خوب مبتنی بر LLM، اول از همه، نرم افزار خوبی است. عامل جادویی که در LLM می بینیم (که بیانگر ماهیت انسان و نقش زبان در درک ما از موجودات هوشمند دیگر است، موضوعی که البته در اینجا به آن نمی پردازم) ممکن است ما را وسوسه کند که در مورد نرم افزار مبتنی بر LLM به عنوان یک کل فکر کنیم. زمینه جدیدی که نیازمند ابزارها، چارچوب ها و فرآیندهای توسعه جدید است. همانطور که در بالا توضیح داده شد، ماهیت غیر قطعی LLMهای تجاری و همچنین API بدون ساختار آنها، در واقع نیاز به مدیریت اختصاصی دارد. اما من استدلال می‌کنم که به‌جای نگاه کردن به برنامه‌های مبتنی بر LLM به‌عنوان یک موجود کاملاً جدید که ممکن است اینجا و آنجا از الگوهای کدنویسی آشنا استفاده کند – باید چنین برنامه‌ای را مانند هر برنامه دیگری در نظر بگیریم، به جز مواردی که نیست. قدرت این رویکرد در این واقعیت نهفته است که با انجام این کار، ما اجازه نمی‌دهیم انتزاعات خارجی، مدیریت سطح پایین LLM را که برای درک واقعی قابلیت‌ها و محدودیت‌های آن در حوزه کاربرد ما ضروری است، پنهان کنند. انتزاع ها را می توان و باید در جایی اتخاذ کرد که باعث صرفه جویی در زمان و کاهش کد دیگ بخار شود، اما هرگز به قیمت از دست دادن کنترل بر مهمترین بخش برنامه شما: نقاط تماس پیچیده بین LLM و کد قطعی شما، که باید متناسب با شرایط خاص شما باشد. مورد استفاده
در پایان، LLM ها را می توان به عنوان اوراکل های قدرتمندی در نظر گرفت که برنامه های کاربردی قبلا غیر قابل اجرا را فعال می کنند. تجربه من در توسعه عوامل مبتنی بر LLM چندین اصل را به من آموخته است که با استقرار موفقیت آمیز تولید و سودمندی مرتبط است. اولاً، باید کمترین آزادی ممکن را به عامل ها داد: جریان ها باید ساختارمند باشند و هر کاری که می توان به طور قطعی انجام داد باید باشد. ثانیاً، ارزیابی تجربی خودکار از وظیفه LLM و منطق پیرامونی باید سنگ بنای فرآیند توسعه باشد و تا حد امکان بر امتیازدهی قطعی تکیه کند. ثالثاً، انتزاعات ارائه شده توسط کتابخانه ها و چارچوب ها نباید در جایی که جزئیات اساسی یکپارچه سازی بین LLM و کد ما، هسته برنامه های کاربردی مبتنی بر LLM را پنهان می کنند، پذیرفته شوند.
برای بحث بیشتر در مورد این موضوع با خیال راحت تماس بگیرید و نظر خود را به من بگویید!
منتشر شده از طریق به سمت هوش مصنوعی