فصل اول- بخش 3- برنامه‌ریزی برای برنامه‌های کاربردی هوش مصنوعی

ترجمه کتاب ساخت برنامه‌های کاربردی با مدل‌های پایه - انتشارات O’Reilly

BOOK: O'Reilly_AI_Engineering_Building_Applications_with_Foundation_Models

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

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

ارزیابی مورد استفاده (Use Case Evaluation)

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

1. تهدید وجودی (Existential Threat): اگر این کار را انجام ندهید، رقبای مجهز به هوش مصنوعی می‌توانند شما را منسوخ کنند. اگر هوش مصنوعی تهدید عمده‌ای برای کسب‌وکار شما محسوب می‌شود، ادغام هوش مصنوعی باید بالاترین اولویت را داشته باشد. این برای کسب‌وکارهای مرتبط با پردازش اسناد و تجمع اطلاعات (مانند تحلیل مالی، بیمه) و کارهای خلاقانه (مانند تبلیغات، طراحی وب) رایج‌تر است.

2. از دست دادن فرصت (Missed Opportunities): اگر این کار را انجام ندهید، فرصت‌های افزایش سود و بهره‌وری را از دست خواهید داد. اکثر شرکت‌ها به دلیل فرصت‌هایی که هوش مصنوعی به ارمغان می‌آورد، آن را می‌پذیرند. هوش مصنوعی می‌تواند در اکثر عملیات کسب‌وکار کمک کند.

3. اکتشاف و تحقیق (Exploration & R&D): شما مطمئن نیستید که هوش مصنوعی در کجای کسب‌وکار شما قرار می‌گیرد، اما نمی‌خواهید عقب بمانید. سرمایه‌گذاری منابع برای درک یک فناوری تحول‌آفرین جدید اگر استطاعت آن را داشته باشید، ایده بدی نیست.

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

نقش هوش مصنوعی و انسان در برنامه

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

1. حیاتی یا مکمل (Critical or Complementary): اگر یک برنامه بدون هوش مصنوعی همچنان کار کند، هوش مصنوعی مکمل برنامه است (مانند Gmail بدون Smart Compose). هرچه هوش مصنوعی برای برنامه حیاتی‌تر باشد، دقت و قابلیت اطمینان بخش هوش مصنوعی باید بیشتر باشد.

2. واکنشی یا پیش‌گیرانه (Reactive or Proactive): یک ویژگی واکنشی در پاسخ به درخواست کاربران عمل می‌کند (مانند چت‌بات)، در حالی که یک ویژگی پیش‌گیرانه در هنگام فرصت، پاسخ خود را نشان می‌دهد (مانند هشدار ترافیک در Google Maps). ویژگی‌های پیش‌گیرانه معمولاً نوار کیفیت بالاتری دارند زیرا کاربران آن‌ها را درخواست نکرده‌اند.

3. پویا یا ایستا (Dynamic or Static): ویژگی‌های پویا با بازخورد کاربر به طور مداوم به‌روز می‌شوند (مانند Face ID)، در حالی که ویژگی‌های ایستا به صورت دوره‌ای به‌روز می‌شوند (مانند تشخیص شیء در Google Photos).

همچنین مهم است که نقش انسان‌ها در برنامه روشن شود. آیا هوش مصنوعی پشتیبانی پس‌زمینه را برای انسان‌ها فراهم می‌کند، مستقیماً تصمیم می‌گیرد، یا هر دو؟ برای مثال، برای یک چت‌بات پشتیبانی مشتری، پاسخ‌های هوش مصنوعی می‌توانند به روش‌های مختلفی استفاده شوند:

• هوش مصنوعی چند پاسخ را نشان می‌دهد که کارشناسان انسانی می‌توانند برای نوشتن پاسخ‌های سریع‌تر به آن مراجعه کنند.

• هوش مصنوعی فقط به درخواست‌های ساده پاسخ می‌دهد و درخواست‌های پیچیده‌تر را به انسان‌ها مسیریابی می‌کند.

• هوش مصنوعی بدون مشارکت انسان، مستقیماً به همه درخواست‌ها پاسخ می‌دهد.

درگیر کردن انسان‌ها در فرآیندهای تصمیم‌گیری هوش مصنوعی انسان در حلقه (human-in-the-loop) نامیده می‌شود. مایکروسافت یک چارچوب برای افزایش تدریجی اتوماسیون هوش مصنوعی در محصولات پیشنهاد کرده است که به آن Crawl-Walk-Run می‌گویند:

1. Crawl (خزیدن): مشارکت انسان اجباری است.

2. Walk (راه رفتن): هوش مصنوعی می‌تواند مستقیماً با کارمندان داخلی تعامل داشته باشد.

3. Run (دویدن): اتوماسیون افزایش یافته، بلقوه شامل تعاملات مستقیم هوش مصنوعی با کاربران خارجی.

نقش انسان‌ها می‌تواند با بهبود کیفیت سیستم هوش مصنوعی در طول زمان تغییر کند. برای مثال، در ابتدا، زمانی که شما هنوز در حال ارزیابی قابلیت‌های هوش مصنوعی هستید، ممکن است از آن برای تولید پیشنهاداتی برای کارشناسان انسانی (human agents) استفاده کنید. اگر نرخ پذیرش توسط کارشناسان انسانی بالا باشد، برای مثال، ۹۵٪ از پاسخ‌های پیشنهادی هوش مصنوعی به درخواست‌های ساده، به صورت کلمه به کلمه (verbatim) توسط کارشناسان انسانی استفاده شود، آنگاه می‌توانید به مشتریان اجازه دهید مستقیماً با هوش مصنوعی برای آن درخواست‌های ساده تعامل داشته باشند.

دفاع‌پذیری محصول هوش مصنوعی (AI Product Defensibility)

اگر شما برنامه‌های هوش مصنوعی را به عنوان محصولات مستقل به فروش می‌رسانید، مهم است که دفاع‌پذیری (defensibility) آنها را در نظر بگیرید. مانع ورود کم(low entry barrier) هم یک نعمت است و هم یک نفرین. اگر ساختن چیزی برای شما آسان باشد، برای رقبای شما نیز آسان است. چه سنگری (moats) برای دفاع از محصول خود دارید؟

به نوعی، ساخت برنامه‌ها بر روی مدل‌های پایه به معنای ارائه یک لایه روی این مدل‌ها است. این همچنین به این معنی است که اگر مدل‌های زیرین در قابلیت‌ها گسترش یابند، لایه‌ای که شما ارائه می‌دهید ممکن است توسط مدل‌ها بلعیده شود و برنامه شما را منسوخ کند. تصور کنید یک برنامه تجزیه و تحلیل (parsing) PDF بر اساس این فرض که چت‌جی‌پی‌تی نمی‌تواند PDFها را به خوبی تجزیه کند یا در مقیاس بزرگ انجام دهد، روی آن بسازید. اگر این فرض دیگر درست نباشد، توانایی رقابت شما تضعیف خواهد شد. با این حال، حتی در این صورت، یک برنامه تجزیه PDF ممکن است اگر بر روی مدل‌های متن باز (open source) ساخته شده باشد، همچنان معنا داشته باشد و راه‌حل شما را به سمت کاربرانی سوق دهد که می‌خواهند مدل‌ها را به صورت داخلی (in-house) میزبانی کنند.

یکی از شرکای عمومی (General Partner) در یک شرکت بزرگ سرمایه‌گذاری خطرپذیر (VC) به من گفت که او بسیاری از استارت‌آپ‌ها را دیده که کل محصولات آنها می‌توانست یک ویژگی برای Google Docs یا Microsoft Office باشد. اگر محصولات آنها موفق شود، چه چیزی می‌تواند مانع از آن شود که Google یا Microsoft سه مهندس را برای تکثیر این محصولات در دو هفته اختصاص دهند؟

در هوش مصنوعی، به طور کلی سه نوع مزیت رقابتی وجود دارد: فناوری (technology)، داده (data)، و توزیع (distribution) — که توانایی عرضه محصول شما به کاربران است. با مدل‌های پایه، فناوری‌های اصلی اکثر شرکت‌ها مشابه خواهد بود. مزیت توزیع احتمالاً متعلق به شرکت‌های بزرگ است.

مزیت داده پیچیده‌تر (nuanced) است. شرکت‌های بزرگ احتمالاً داده‌های موجود بیشتری دارند. با این حال، اگر یک استارت‌آپ بتواند اول به بازار برسد و داده‌های استفاده کافی برای بهبود مستمر محصولات خود جمع‌آوری کند، داده ها سنگر (moat) آنها خواهد بود. حتی برای سناریوهایی که داده‌های کاربر نمی‌تواند مستقیماً برای آموزش مدل‌ها استفاده شود، اطلاعات استفاده می‌تواند بینش‌های ارزشمندی در مورد رفتارهای کاربر و کاستی‌های محصول ارائه دهد، که می‌تواند برای هدایت فرآیند جمع‌آوری داده و آموزش استفاده شود.

شرکت‌های موفق زیادی وجود داشته‌اند که محصولات اولیه آنها می‌توانست یک ویژگی از محصولات بزرگتر باشد. Calendly می‌توانست یک ویژگی از Google Calendar باشد. Mailchimp می‌توانست یک ویژگی از Gmail باشد. Photoroom می‌توانست یک ویژگی از Google Photos باشد. بسیاری از استارت‌آپ‌ها در نهایت از رقبای بزرگتر پیشی می‌گیرند، که با ساخت ویژگی‌ای شروع می‌کنند که این رقبای بزرگتر نادیده گرفته‌اند. شاید شرکت شما بتواند بعدی باشد.

تعیین انتظارات (Setting Expectations)

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

• چند درصد از پیام‌های مشتری را می‌خواهید چت‌بات خودکار کند؟

• چت‌بات باید چند پیام بیشتر را پردازش کند؟

• با استفاده از چت‌بات چقدر سریع‌تر می‌توانید پاسخ دهید؟

• چت‌بات چقدر می‌تواند در نیروی کار انسانی صرفه‌جویی کند؟

یک چت‌بات می‌تواند به پیام‌های بیشتری پاسخ دهد، اما این به معنای خوشحال کردن کاربران نیست، بنابراین ردیابی رضایت مشتری (customer satisfaction) و به طور کلی بازخورد مشتری مهم است. بخش “بازخورد کاربر” در صفحه ۴۷۴ در مورد نحوه طراحی یک سیستم بازخورد بحث می‌کند.

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

• معیارهای کیفیت: برای اندازه‌گیری کیفیت پاسخ‌های چت‌بات.

• معیارهای تاخیر (Latency): شامل TTFT (زمان تا اولین توکن)، TPOT (زمان به ازای هر توکن خروجی) و تاخیر کل. آنچه تاخیر قابل قبول در نظر گرفته می‌شود به مورد استفاده شما بستگی دارد. اگر تمام درخواست‌های مشتریان شما در حال حاضر توسط انسان‌ها با زمان پاسخ میانه یک ساعت پردازش می‌شوند، هر چیزی سریع‌تر از این ممکن است به اندازه کافی خوب باشد.

• معیارهای هزینه: هر درخواست استنتاج (inference) چقدر هزینه دارد.

• معیارهای دیگر مانند تفسیرپذیری (interpretability) و انصاف (fairness).

اگر هنوز مطمئن نیستید که از چه معیارهایی می‌خواهید استفاده کنید، نگران نباشید. بقیه کتاب بسیاری از این معیارها را پوشش خواهد داد.

برنامه‌ریزی نقطه عطف (Milestone Planning)

هنگامی که اهداف قابل اندازه‌گیری تعیین کردید، به یک برنامه برای دستیابی به این اهداف نیاز دارید. چگونگی رسیدن به اهداف بستگی به جایی دارد که شروع می‌کنید. مدل‌های موجود را ارزیابی کنید تا قابلیت‌های آن‌ها را درک کنید. هرچه مدل‌های آماده (off-the-shelf) قوی‌تر باشند، کار کمتری باید انجام دهید. برای مثال، اگر هدف شما خودکار کردن ۶۰٪ از تیکت‌های پشتیبانی مشتری است و مدل آماده‌ای که می‌خواهید استفاده کنید از قبل می‌تواند ۳۰٪ از تیکت‌ها را خودکار کند، تلاشی که باید انجام دهید ممکن است کمتر از زمانی باشد که اصلاً نتواند تیکتی را خودکار کند.

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

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

در مقاله UltraChat، Ding و همکاران (۲۰۲۳) به اشتراک گذاشتند که “سفر از ۰ به ۶۰ آسان است، در حالی که پیشرفت از ۶۰ به ۱۰۰ به طور فزاینده‌ای چالش‌برانگیز می‌شود.” لینکدین (۲۰۲۴) همین احساس را به اشتراک گذاشت. یک ماه طول کشید تا ۸۰٪ از تجربه مورد نظر خود را به دست آورند. این موفقیت اولیه باعث شد که آنها به شدت دست کم بگیرند که چقدر زمان برای بهبود محصول نیاز دارند. آنها دریافتند که چهار ماه دیگر طول کشید تا در نهایت از ۹۵٪ فراتر بروند. زمان زیادی صرف کار بر روی مشکلات محصول (product kinks) و مقابله با توهمات (hallucinations) شد. سرعت پایین دستیابی به هر ۱٪ سودِ بعدی دلسردکننده بود.

نگهداری (Maintenance)

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

بسیاری از تغییرات خوب هستند. برای مثال، محدودیت‌های بسیاری از مدل‌ها در حال برطرف شدن هستند. طول زمینه (context lengths) در حال طولانی‌تر شدن است. خروجی‌های مدل در حال بهتر شدن هستند. استنتاج مدل (model inference)، فرآیند محاسبه یک خروجی با توجه به یک ورودی، در حال سریع‌تر و ارزان‌تر شدن است. شکل ۱-۱۱ تکامل هزینه استنتاج و عملکرد مدل در benchmark محبوب مدل‌های پایه به نام MMLU را بین سال‌های ۲۰۲۲ تا ۲۰۲۴ نشان می‌دهد.

با این حال، حتی این تغییرات خوب نیز می‌توانند باعث اصطکاک (friction) در گردش کارهای شما شوند. شما باید دائماً مراقب باشید و یک تحلیل هزینه-فایده (cost-benefit) برای هر سرمایه‌گذاری تکنولوژی انجام دهید. بهترین گزینه امروز ممکن است فردا به بدترین گزینه تبدیل شود.

ممکن است تصمیم بگیرید یک مدل را به صورت داخلی (in-house) بسازید زیرا به نظر می‌رسد ارزان‌تر از پرداخت به ارائه‌دهندگان مدل است، فقط برای اینکه پس از سه ماه متوجه شوید ارائه‌دهندگان مدل قیمت‌های خود را به نصف کاهش داده‌اند و گزینه داخلی را به گزینه‌ای گران تبدیل کرده‌اند. ممکن است در یک راه‌حل شخص ثالث (third-party solution) سرمایه‌گذاری کنید و زیرساخت خود را حول آن سفارشی کنید، فقط برای اینکه ارائه‌دهنده پس از عدم تامین مالی، از کسب‌وکار خارج شود (go out of business).

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

برخی تغییرات برای انطباق سخت‌تر هستند، به ویژه تغییرات حول مقررات (regulations). تکنولوژی‌های هوش مصنوعی برای بسیاری از کشورها مسائل امنیت ملی در نظر گرفته می‌شوند، به این معنی که منابع برای هوش مصنوعی، شامل محاسبات (compute)، استعداد (talent) و داده (data)، به شدت تنظیم شده هستند. برای مثال، تصویب قانون حفاظت از داده عمومی اروپا (GDPR) تخمین زده شد که ۹ میلیارد دلار برای سازگار شدن کسب‌وکارها هزینه داشته است. در دسترس بودن محاسبات می‌تواند یک‌ شبه تغییر کند زیرا قوانین جدید محدودیت‌های بیشتری بر روی اینکه چه کسی می‌تواند منابع محاسباتی را بخرد و بفروشد اعمال می‌کند. اگر فروشنده GPU شما ناگهان از فروش GPU به کشور شما منع شود، شما در مشکل هستید بود.

برخی تغییرات حتی می‌توانند کشنده (fatal) باشند. برای مثال، مقررات حول مالکیت فکری (Intellectual Property - IP) و استفاده از هوش مصنوعی هنوز در حال تکامل هستند. اگر محصول خود را بر روی مدلی بسازید که با استفاده از داده‌های دیگران آموزش داده شده است، آیا می‌توانید مطمئن باشید که IP محصول شما همیشه متعلق به شما خواهد بود؟ بسیاری از شرکت‌های سنگین‌وزن در حوزه IP که با آنها صحبت کرده‌ام، مانند استودیوهای بازی، به دلیل ترس از دست دادن IPهای خود در آینده، در استفاده از هوش مصنوعی تردید دارند.

هنگامی که متعهد به ساخت یک محصول هوش مصنوعی شدید، بیایید به stack مهندسی مورد نیاز برای ساخت این برنامه‌ها نگاه کنیم.