هوش معماری (Architectural Intelligence) چیست؟

هوش مصنوعی بعدی؟

نکات کلیدی

• معماران باید هایپِ هوش مصنوعی را از نرم‌افزار واقعی جدا کنند. سیستم‌ها را بر اساس مؤلفه‌های ملموس مثل LLMها طراحی کنید، نه بر اساس یک تصویر مبهم از AI.

• تعیین این‌که چگونه، کجا، و چه زمانی از عناصر AI استفاده شود، به تحلیل بده‌بستان‌های سنتی برمی‌گردد.

• اول، مشخص کنید آیا نرم‌افزار AI برای اپلیکیشن شما انتخاب خوبی هست یا نه. مثل هر فناوری دیگری، AI می‌تواند خلاقانه استفاده شود، اما به شکل نامناسب هم می‌تواند استفاده شود.

• دوم، مشخص کنید چگونه از AI به‌طور مؤثر استفاده کنید. بده‌بستان‌های استفاده از یک API «هوش مصنوعی به‌عنوان سرویس» در برابر self-hosting را در نظر بگیرید.

• معماران می‌توانند مهارت‌های تصمیم‌گیری و ارتباطی خود را با AI تقویت کنند، که به طراحی‌های بهتر و درک بهتر میان ذی‌نفعان منجر می‌شود.

Arthur C. Clarke مشهورانه گفت: «هر فناوری به‌اندازه کافی پیشرفته‌ای از جادو قابل تشخیص نیست». همین حالا، آن فناوری «جادویی» با نام AI شناخته می‌شود. هوش مصنوعی یک اصطلاح چتری عالی است و برای مارکتینگ فوق‌العاده است، اما به این معنا نیست که یک چیز مشخص است که بتوانیم خیلی ساده آن را به نرم‌افزارمان اضافه کنیم. و با این حال، صاحبان محصول، مدیرعامل‌ها، و تیم‌های مارکتینگ می‌خواهند آن را به همه‌چیز اضافه کنیم. مشتری‌ها AI نمی‌خواهند، اما شروع خواهند کرد به این‌که آن را به‌عنوان حداقل انتظار (table stakes) برای هر اپلیکیشن در نظر بگیرند.

ما باید از راهنمایی‌های مبهم و دست‌تکان‌دادنی درباره این‌که چگونه و چرا باید از AI استفاده کنیم عبور کنیم. این شبیه این است که از شما بخواهند اسپری را بردارید و یک لایه قشنگِ AI روی همه‌چیز بپاشید. چنین رویکرد شلخته‌ای خروجی‌هایی را که مردم امیدوارند ایجاد نخواهد کرد. ما به یک رویکرد سنجیده نیاز داریم که بفهمد AI چیست و کجا و چه زمانی باید از آن استفاده کنیم. این همان چیزی است که من اسمش را گذاشته‌ام هوش معماری (Architectural Intelligence).

معماران نرم‌افزار حالا باید بفهمند AI چیست و AI چیست نیست. این نیازمند عبور از مارکتینگ و عبارت‌های هایپ و صحبت‌کردن درباره نرم‌افزار واقعی است.

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

AI چیست؟

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

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

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

اما ما به‌عنوان معماران نرم‌افزار جواب آن سؤال را می‌دانیم. بستگی دارد. باید بپرسیم نیازمندی‌ها چیست. چه نوع داده‌ای باید ذخیره کنیم؟ چطور به آن دسترسی خواهد شد؟ کجا به آن دسترسی خواهد شد؟ و از آن نیازمندی‌ها استفاده می‌کنیم تا تحلیل بده‌بستانمان را شکل بدهیم. کلی راهنما درباره همه بده‌بستان‌ها وجود دارد. رابطه‌ای در برابر document store؟ فایل‌محور در برابر in-memory؟ نیازمندی‌های ACID چیست؟ و غیره.

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

AI معمولاً یعنی GenAI

پنج سال پیش، تنها زمانی که بیشتر مردم درباره AI صحبت می‌کردند، اشاره به علمی-تخیلی بود. کتاب‌ها، فیلم‌ها، سریال‌ها و رسانه‌های دیگر AI را به‌عنوان شخصیت دارند. آن شخصیت‌ها نمونه‌هایی از چیزی هستند که «هوش عمومی مصنوعی» یا AGI نامیده می‌شود. ما آن را نداریم.

امروز، در ۲۰۲۴، وقتی کسی «AI» را به‌عنوان یک اصطلاح کلی می‌گوید، احتمالاً منظورش «هوش مصنوعی مولد» یا GenAI است. این را در محصولات اختصاصی مثل ChatGPT یا GitHub Copilot می‌بینیم. و این همچنین رایج‌ترین رویکرد «یک ذره AI روش اسپری کن» برای محصولات است. اگر یک مدیر اجرایی بخواهد مطمئن شود محصولش مدرن و نوآورانه به نظر می‌رسد، یک GenAI به آن اضافه می‌کند. این به تعداد زیادی چت‌بات منجر شده است. و هوش مصنوعی مولد فقط درباره زبان نیست. ما می‌توانیم تصویر، ویدئو و صدا را هم با Dall-E، Midjourney و ابزارهای دیگر تولید کنیم.

GenAI از یادگیری ماشین شروع می‌شود

GenAI یک کاربرد مشخص از مفهوم گسترده یادگیری ماشین، ML، است. دقیق‌تر، یک فرایند یادگیری عمیق (deep learning) است. برای هدف ما، فرایند یادگیری ماشین نسبتاً سرراست است. جزئیات پیچیده را می‌گذاریم برای دانشمندان داده.

ساختن یک مدل ML با داده آموزشی شروع می‌شود، داده آموزشی زیاد. می‌تواند هر چیزی باشد: داده فروش تاریخی، عکس حیوانات، نظرهای کاربران. داده ورودی و خروجیِ مورد انتظار را به یک فرایند آموزش ML می‌دهید. این مثل یک تست واحد است. با ورودی A و خروجی مورد انتظار B، چقدر نزدیک شدی؟ فرایند آموزش یک مدل ML می‌سازد و سپس آن را در برابر خروجی مورد انتظار ارزیابی می‌کند. این یک فرایند ساده است که هزاران، میلیون‌ها، یا میلیاردها بار تکرار می‌شود و مدل را پیوسته پالایش می‌کند.

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

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

LLMها مدل‌های ML هستند که داده آموزشی، ورودی و خروجی‌شان کلمات هستند، کلی کلمه، کلی و کلی و کلی کلمه. ورودی برای یک LLM یک سری از کلمات است. خب، در واقع یک سری از توکن‌ها. توکن چیست؟ ممکن است یک کلمه باشد یا بخشی از یک کلمه. جزئیات مهم نیست. یادتان باشد، این همه در نهایت به یک آرایه از floatها تبدیل می‌شود که مدل بتواند با آن کار کند.

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

کجا باید از AI استفاده کنیم؟

حالا که می‌دانیم AI یعنی GenAI، و GenAI واقعاً یعنی LLM، و LLM هم فقط یک نوع مدل ML است، می‌توانیم شروع کنیم فکر کنیم این قابلیت کجا در سیستم‌های ما معنا پیدا می‌کند.

در ۲۰۲۴، ما در نقطه‌ای هستیم که یادگیری ماشین و GenAI دیگر یک فکر بعدی (afterthought) نیستند. این‌ها فناوری‌هایی هستند که به‌سرعت در حال تبدیل‌شدن به عناصر هسته‌ای سیستم‌های نرم‌افزاری مدرن هستند. چطور به اینجا رسیدیم؟

نه چندان دور، وقتی شرکت‌ها شروع به استخدام دانشمند داده و ساخت مدل‌های یادگیری ماشین کردند، همه‌چیز یک راهکار افزونه‌ای (add-on) بود. داده از قبل وجود داشت. برای آموزش مدل‌های ML سفارشی استفاده می‌شد. بعد آن مدل‌ها به‌عنوان یک مؤلفه در یک فرایند تحلیلی استفاده می‌شدند. شرکت‌ها آزمایش می‌کردند، و آزمایش‌ها همیشه جواب نمی‌دهند، پس آن‌ها را جدا از اپلیکیشن‌های حیاتی کسب‌وکار نگه می‌دارید.

حالا داریم shift-leftِ ML را می‌بینیم، چون می‌خواهیم مدل‌های حاصل، مؤلفه‌های داخلی نرم‌افزار ما باشند، نه افزونه‌های اضافی در سیستم‌های ثانویه. در یکی دو سال گذشته، حتی مؤلفه‌های AI که فقط افزونه بودند، مثل همان چت‌بات‌ها، هم shift-left کرده‌اند و تبدیل به مؤلفه‌های هسته‌ای سیستم شده‌اند که به کاربران قابلیت می‌دهند. این همان جایی است که می‌خواهیم به آن برسیم. ما نمی‌خواهیم AI یک نمایش فرعی باشد. اما این چه شکلی است؟ کجا منطقی است از یک مؤلفه AI استفاده کنیم به‌جای نرم‌افزار «سنتی» که توسعه‌دهندگان می‌نویسند؟

در نظر گرفتن این‌که کجا و چگونه از AI در سیستم خود استفاده کنید مثل واردکردن هر فناوری جدیدی به طراحی سیستم است. باید تحلیل بده‌بستان انجام دهید. مزایا و معایب طراحی‌ای که از AI استفاده می‌کند در برابر طراحی‌ای که از AI استفاده نمی‌کند چیست؟ یا طراحی‌ای که از یک مدل AI متفاوت استفاده می‌کند. سناریویی را در نظر بگیرید که از شما خواسته‌اند AI را به نرم‌افزار اضافه کنید. چطور تحلیل بده‌بستانمان را شروع می‌کنیم؟ عوامل «بستگی دارد» چیست؟

آیا AI برای سناریو مناسب است؟

وقتی برای یک ویژگی جدید طراحی می‌کنیم، معمولاً با گزینه‌های مناسب شروع می‌کنیم و آن‌هایی را که مناسب نیستند کنار می‌گذاریم. چون AI در یک چرخه هایپ است، پیشنهاد استفاده از آن را در جاهایی می‌بینیم که ربطی ندارد. به‌جای AI، یک فناوری دیگر را تصور کنید و این‌که چطور ممکن است از آن سوءاستفاده کنیم: یک دیتابیس رابطه‌ای به‌عنوان موتور کش، یا یک سرویس ایمیل که کامل با Lambda functionها ساخته شده باشد. AI چکش طلایی‌ای که منتظرش بودیم نیست.

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

کاربردهای خوب AI

LLMها می‌توانند یک رابط زبان طبیعی ارائه دهند. این هم برای ورودی کار می‌کند هم برای خروجی. اجازه دهید مردم توضیح دهند چه کاری می‌خواهند انجام دهند، و LLM می‌تواند آن را به دستورالعمل‌های سیستم تبدیل کند. یا LLM می‌تواند پاسخ سیستم را به فرمتی انسان‌پسندتر تبدیل کند.

این منطقی است اگر یک UI قابل‌سفارشی‌سازی اما پیچیده داشته باشید که کسی بتواند چیزی را که می‌خواهد توصیف کند، اما تنظیم‌کردن همه‌چیز زمان می‌برد. یک سازنده گزارش ad-hoc مجهز به AI را در نظر بگیرید. شما درخواست یک گزارش جدید می‌دهید که هر دوشنبه اجرا شود و از طریق یک رابط چت‌مانند مقایسه هفته‌به‌هفته ارائه دهد. این می‌تواند زمان و اعصابِ یادگرفتن تنظیم همه گزینه‌ها از طریق UI را ذخیره کند.

کاربردهای ممکن AI

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

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

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

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

کاربردهای مشکوک AI

دسته سوم جایی است که استفاده از AI ایده‌ای وحشتناک است. بیشتر این سناریوها شامل ممیزی و ردیابی‌پذیری داده هستند، مثل سناریوهای دقیق ریاضی یا وقتی دارید برای نیازهای مقرراتی و انطباق گزارش می‌سازید.

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

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

AI نرم‌افزار غیرقطعی (non-deterministic) است

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

اما باید AI را غیرقطعی در نظر بگیریم. این به معنی تصادفی نیست، اما مقداری غیرقابل‌پیش‌بینی‌بودن در آن ساخته شده است، و این عمداً است. ویژگی، نه باگ، این است که LLM محتمل‌ترین کلمه بعدی را پیش‌بینی می‌کند. «محتمل‌ترین» به معنی «همیشه تضمین‌شده» نیست.

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

وقتی مؤلفه‌های AI را در طراحی سیستم در نظر می‌گیرید، فکر کنید کجا با جواب‌های «به‌اندازه کافی خوب» مشکلی ندارید. می‌دانم دهه‌ها وقت گذاشته‌ایم نرم‌افزاری بسازیم که همان کاری را که انتظار می‌رود انجام دهد، پس این ممکن است ایده سختی باشد.

به‌عنوان یک تمرین ذهنی، یک مؤلفه AI پیشنهادی را با یک انسان جایگزین کنید. سیستم را چطور طراحی می‌کنید تا ورودی اشتباه انسان را مدیریت کند؟ از اعتبارسنجی UI تا الزام بازبینی توسط نفر دوم. اگر User در User Interface یک AI باشد چه؟ احتمالاً باید اعتبارسنجی مشابهی برای چیزی که AI تولید می‌کند وجود داشته باشد.

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

چطور از AI به‌طور مؤثر استفاده کنیم

اگر تعیین کنیم GenAI برای سناریوی ما منطقی است، تصمیم طراحی بعدی این است که چطور از آن به‌طور مؤثر استفاده کنیم. باز هم جواب این است: «بستگی دارد». استفاده مؤثر از AI همیشه وابسته به کانتکست است. با این حال، بعضی ملاحظات سطح بالا معمولاً اعمال می‌شوند.

اول، باید مطمئن شویم نرم‌افزار «به‌اندازه کافی خوب» را قابل‌قبول می‌کنیم. ارزش دارد اشاره کنیم خروجی‌های AI اغلب سطح بسیار بالایی از «خوب» دارند. نگاه کنید LLMها چطور تکامل پیدا کرده‌اند و حالا می‌توانند بیشتر آزمون‌های استانداردشده را پاس کنند.

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

چون استفاده‌های پیشنهادی AI اغلب جایگزین یا مکمل یک انسان هستند، انجام تمرین ذهنیِ «انسان دارد کار را انجام می‌دهد» کمک‌کننده است. آیا آن فرد فقط به دیپلم دبیرستان نیاز دارد، یا به آموزش تخصصی مثل حسابدار یا paralegal؟ اگر دومی است، دنبال مدل‌های تخصصی بگردید که همان زبان را صحبت می‌کنند.

بزرگ‌تر همیشه بهتر نیست

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

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

مدل‌های کوچک‌تر همچنین می‌توانند تخصصی‌تر باشند و برای یک دامنه مشخص آموزش داده شوند. شاید نتوانید درباره Taylor Swift سؤال بپرسید، اما احتمالاً نرم‌افزار شما نیازی ندارد درباره هنرمندان محبوب بداند.

ارزیابی و بهینه‌سازی AI

مگر این‌که محصول شما یک مدل زبانی باشد، آموزش‌دادن مدل زبانی خودتان منطقی نیست. این‌ها حالا محصولات کالایی (commodity) هستند که می‌توانید بخرید و باید یک راهکار «خرید» در برابر «ساختن» باشند. در بعضی موارد، ممکن است fine-tune کردن یک مدل منطقی باشد، که شبیه فرستادن مدل به مقطع تحصیلات تکمیلی است. با این حال، این فقط زمانی منطقی است که آن مدل fine-tune شده یک تمایزدهنده بزرگ برای محصولات نرم‌افزاری شما باشد.

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

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

اجاره‌کردن در برابر مالک‌بودن

چون LLMها محصولات کالایی هستند، یک انتخاب این است که از طریق یک API در رویکرد «LLM به‌عنوان سرویس» به آن‌ها دسترسی داشته باشید یا آن‌ها را روی سخت‌افزاری که خودتان مدیریت می‌کنید نصب کنید. وقتی تازه شروع می‌کنید، رویکرد pay-as-you-go منطقی‌تر است. این اجازه می‌دهد آزمایش انجام دهید، بفهمید چه چیزی بهتر جواب می‌دهد، و مدل‌های مختلف را مقایسه کنید. داده‌های بده‌بستان ضروری را جمع کنید، مثل کیفیت پاسخ، زمان بازگشت پاسخ، و هزینه. حتی ممکن است به نتیجه‌ای برسید که استفاده از LLM برای سناریوی شما منطقی نیست و ممکن است کمک کند use case را در صورت نیاز تطبیق دهید.

وقتی مشخص کردید یک LLM می‌تواند یک مؤلفه مفید در نرم‌افزار شما باشد، رویکرد self-hosting ممکن است منطقی شود. این یک محاسبه ساده هزینه نیست چون عوامل زیادی دخیل‌اند، و ممکن است نتوانید همان مدل‌هایی را که از طریق API می‌گیرید به‌صورت داخلی استفاده کنید. باز هم، ممکن است برای تحلیل بده‌بستان کافی به آزمایش نیاز باشد.

عامل دیگری که باید در نظر بگیرید امنیت است. وقتی سخت‌افزار و شبکه را کنترل می‌کنید، نگرانی‌های کمتری درباره نشت داده وجود دارد. اگر مجبور باشید داده‌ای را که به LLM می‌فرستید sanitize کنید، این روی کیفیت خروجی اثر می‌گذارد. همچنین، اگر بخواهید یک مدل را fine-tune کنید، احتمالاً به self-hosting متعهد می‌شوید.

چه زمانی یک معمار باید از AI استفاده کند؟

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

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

تقویت ارتباطات با AI

LLMها در خلاصه‌کردن حجم زیادی از اطلاعات عالی‌اند. برای یک معمار نرم‌افزار، این به‌ویژه در ارتباط با مخاطبان مختلف مفید است. با شروع از یک سند طراحی طولانی، LLM می‌تواند خلاصه‌های متفاوت برای CTO، صاحب محصول، و تیم توسعه تولید کند.

همچنین می‌توانید از LLM بازخورد بخواهید درباره چیزی که نوشته‌اید. قبل از ارسال یک ایمیل یا ارائه یک پرزنتیشن، از LLM بخواهید با سؤال‌هایی پاسخ دهد که CTO یا صاحب محصول احتمالاً خواهند پرسید.

تقویت تصمیم‌گیری با AI

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

حتی می‌توانید از یک LLM بخواهید کل یک Architecture Decision Record (ADR) را بنویسد. این می‌تواند برای یک پیش‌نویس اولیه مفید باشد، به‌خصوص اگر مجبور کند درباره نیازمندی‌ها آن‌قدر شفاف فکر کنید و آن‌ها را توصیف کنید که بتوانید وارد LLM کنید. با این حال، مثل همه تعامل‌ها، هرگز فرض نکنید درست است. این به‌ویژه برای طراحی مؤلفه‌های نرم‌افزاری جدید درست است، چون LLM ممکن است کلماتی بیرون بریزد که درست به نظر می‌رسند اما قابل پیاده‌سازی نیستند.

خلاصه

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

این مقاله با قانون سوم کلارک شروع شد. قانون دوم او می‌گوید: «تنها راه کشف مرزهای ممکن این است که کمی از آن‌ها فراتر برویم و وارد ناممکن شویم.»

هایپ زیادی بیرون هست. امیدوارم توصیه‌های عملی ارائه کرده باشم درباره این‌که ابزارهای «AI» ملموس چطور می‌توانند به‌صورت عمل‌گرایانه در سیستم‌های نرم‌افزاری استفاده شوند. اما می‌دانم همه جواب‌ها را ندارم، و قطعاً نمی‌دانم چه چیزی ممکن است.

گاهی، کمک می‌کند هایپ را باور کنید و تلاش کنید کارِ ناممکن را انجام دهید. ممکن است از چیزی که می‌توانید به دست بیاورید شگفت‌زده شوید.