بومی هوش مصنوعی در برابر افزوده هوش مصنوعی: تفاوت معماری که نسل بعدی برنامهها را تعریف میکند
تفاوتی وجود دارد که شایسته توجه است در نحوه ورود هوش مصنوعی به نرمافزارها، و بیشتر بحثهای محصولی از آن عبور میکنند. برخی برنامهها هوش مصنوعی را به خود افزودهاند: یک جعبه جستجو که اکنون زبان طبیعی را میفهمد، یک ابزار نوشتار با لایه تکمیل خودکار، یک داشبورد با ویجت خلاصهسازی مبتنی بر هوش مصنوعی. برخی دیگر از ابتدا به صورت بومی هوش مصنوعی ساخته شدهاند، جایی که مدل یک ویژگی الحاقی نیست، بلکه لایه استدلال اصلی است که برنامه پیرامون آن طراحی شده است. این تفاوت معماری است و محصولاتی اساساً متفاوت ایجاد میکند.
تفاوت ساختاری
در یک برنامه سنتی، منطق قطعی است. اقدام کاربر یک تابع را فعال میکند، تابع ورودیها را بر اساس قواعد از پیش تعریفشده پردازش میکند و خروجی قابل پیشبینی بازمیگرداند. میتوان هوش مصنوعی را به این ساختار افزود – معمولاً به صورت فراخوانی به یک API مدل بیرونی که یک وظیفه خاص و محدود را انجام میدهد – اما معماری کلی مبتنی بر قاعده باقی میماند. هوش مصنوعی ابزاری است که برنامه از آن استفاده میکند، نه مکانیزمی که برنامه با آن استدلال میکند.
در یک برنامه بومی هوش مصنوعی، مدل در مسیر بحرانی قابلیتهای اصلی قرار دارد. برنامه نه تنها برای وظایف خاص هوش مصنوعی را فراخوانی میکند، بلکه استدلال را به مدل واگذار میکند. نیت کاربر به صورت زمینهای تفسیر میشود، نه اینکه در برابر فهرستی از اقدامات از پیش تعریفشده تجزیه شود. گردش کاری که برنامه دنبال میکند ممکن است در زمان اجرا توسط مدل تعیین شود، نه اینکه از پیش توسط توسعهدهنده نوشته شده باشد. این نیازمند یک معماری اساساً متفاوت است: مدیریت زمینه، لایههای بازیابی برای مستندسازی خروجیهای مدل در دادههای جاری، خطوط لوله ارزیابی برای نظارت بر کیفیت خروجی، و تخریب تدریجی برای خروجیهای با اطمینان پایین.
این در عمل چگونه به نظر میرسد
تضاد در گردشهای کاری روبروی مشتری ملموس میشود. یک برنامه پشتیبانی سنتی کاربران را از طریق یک درخت تصمیم هدایت میکند: یک دسته را انتخاب کنید، به یک سری سؤال پاسخ دهید، به یک راهحل برسید. یک سیستم پشتیبانی بومی هوش مصنوعی هیچ درخت تصمیمی ندارد. مدل پیام کاربر را میخواند، زمینه مرتبط را از یک ذخیره برداری (vector store) جستجو میکند، یک پاسخ ترکیب میکند و بر اساس محتوا – نه بر اساس اینکه کاربر به کدام شاخه از درخت رفته است – تصمیم میگیرد که آیا موضوع را ارتقا دهد یا خیر.
یا یک ویرایشگر کد را در نظر بگیرید. GitHub Copilot هوش مصنوعی را به یک پارادایم IDE موجود افزود – تکمیل خودکار، اما هوشمندتر. Cursor و جانشینانش بر پایه این ایده ساخته شدند که مدل باید در سراسر پایگاه کد بخواند و بنویسد، نیت توسعهدهنده را در سطح پروژه درک کند و اقدامات چندمرحلهای انجام دهد. معماری مورد نیاز – پنجرههای زمینه بزرگ، نمایهسازی در سطح فایل، تولید تفاوت (diff) مبتنی بر مدل، مکانیزمهای بازگشت – در نوع خود با افزودن تکمیل خودکار هوشمند به یک ویرایشگر موجود متفاوت است.
مسئله معماری داده
سختترین بخش ساخت برنامه بومی هوش مصنوعی، یکپارچهسازی مدل نیست. مدلها در دسترس هستند، هزینههای API به شدت کاهش یافته و استنتاج سریع است. بخش سخت داده است. برنامههای بومی هوش مصنوعی به زیرساخت بازیابی نیاز دارند که بتواند در زمان پرسش، زمینه مرتبط را نمایان کند، دادههای بدون ساختار را در کنار دادههای ساختاریافته مدیریت کند و این کار را با تأخیری انجام دهد که تجربه کاربری را خراب نکند.
پایگاههای داده برداری به بخش اصلی این پشته تبدیل شدهاند، اما راهحل کاملی نیستند. استراتژیهای تکهتکهسازی (chunking)، انتخاب مدل تعبیه (embedding)، بازبینی (re-ranking) و بازیابی ترکیبی که جستجوی معنایی و کلیدواژهای را ترکیب میکند، همگی به روشهایی بر کیفیت خروجی تأثیر میگذارند که نیازمند تنظیم مداوم هستند. تیمهایی که در زیرساخت بازیابی کمگذاری میکنند، برنامهای به دست میآورند که هوشمند به نظر میرسد اما پاسخهای با اطمینان اشتباه درباره دادههای خود تولید میکند – بدترین نتیجه برای اعتماد کاربر.
شکاف قابلیت اطمینان
افزودن هوش مصنوعی به یک برنامه به معنای پذیرش یک دسته جدید از شکست است: خروجیهای احتمالی که گاهی اشتباه هستند. این زمانی قابل مدیریت است که هوش مصنوعی یک وظیفه حاشیهای را انجام دهد. زمانی که هوش مصنوعی لایه استدلال اصلی باشد، به یک چالش تعریفکننده محصول تبدیل میشود. تیمهای بومی هوش مصنوعی زمان مهندسی قابل توجهی را صرف خطوط لوله ارزیابی میکنند – آزمایش سیستماتیک خروجیهای مدل در برابر نتایج مورد انتظار – و حلقههای بازخورد کاربر که سریعاً خرابیها را نمایان میکنند. نمیتوان یک تست واحد نوشت که تمام ورودیهای ممکن به یک مدل زبانی را پوشش دهد. آنچه میتوان انجام داد، تعریف ویژگیهای خروجی مورد انتظار، اندازهگیری مداوم آنها و ایجاد مسیرهای جایگزین برای موقعیتهای با اطمینان پایین است.
چه زمانی بومی هوش مصنوعی بسازیم و چه زمانی هوش مصنوعی بیفزاییم
همه محصولات نباید بومی هوش مصنوعی باشند. افزودن خلاصه هوش مصنوعی به یک ابزار گزارشدهی اغلب انتخاب درستی است – ارزش واقعی ارائه میدهد بدون اینکه نیاز به بازاندیشی کامل معماری داشته باشد. سوالی که قبل از متعهد شدن به معماری بومی هوش مصنوعی باید پرسید این است که آیا ارزش اصلی محصول به استدلال پویا بر زمینه متغیر وابسته است یا اینکه میتواند توسط یک سیستم قطعی خوب تعریفشده با هوش مصنوعی که نقاط تماس خاصی را تقویت میکند، ارائه شود.
اگر پاسخ اولی است، ساخت بومی هوش مصنوعی از ابتدا به مراتب آسانتر از بازسازی آن است. زیرساخت بازیابی، مدیریت زمینه، سیستمهای ارزیابی – افزودن آنها به یک معماری موجود بسیار سختتر از طراحی آنها از ابتدا است. تیمهایی که در سال ۲۰۲۶ با محصولات بومی هوش مصنوعی برنده میشوند، تقریباً به طور یکسان آنهایی هستند که این شرط معماری را زود انجام دادند.