اگر در گوگل فارسی «معماری هوش مصنوعی» را جستجو کنید، صفحهٔ اول تقریباً تماماً دربارهٔ ساختمان است: ابزارهایی که اسکیس را به رندر تبدیل میکنند، هوش مصنوعی برای طراحی پلان، هوش مصنوعی در BIM. این نتیجه اشتباه نیست؛ معماری در فارسی پیش از هر چیز یعنی همان حرفهای که ساختمان میسازد، و ابزارهای هوش مصنوعی در آن رشته واقعاً پرکاربرد شدهاند.
اما همین عبارت معنای دیگری هم دارد که در فارسی تقریباً بیصاحب مانده. معمار هوش مصنوعی در نرمافزار کسی است که پیش از نوشتن کد تصمیم میگیرد سیستم چطور ساخته شود. این نوشته دربارهٔ همان معنای دوم است.
من این عنوان را برای کاری که انجام میدهم به کار میبرم، و دیدهام که در فارسی معمولاً بد فهمیده میشود — یا با برنامهنویس یکی گرفته میشود، یا با فروشندهٔ ابزار. پس بگذارید بهجای تعریف، از تصمیمها شروع کنم.
چهار تصمیمی که کار را میسازند
وقتی کسبوکاری میخواهد هوش مصنوعی وارد کارش شود، معمولاً پرسشش این است: «کدام ابزار؟» این پرسش، هر جوابی که بگیرد، مهمترین پرسش نیست. چهار تصمیم دیگر هست که پیش از انتخاب ابزار باید گرفته شود و اگر گرفته نشود، ابزار هرچه باشد نتیجه یکی است.
یک: سیستم چه کاری را خودش انجام دهد
این ساده به نظر میرسد و نیست. فرض کنید یک ایجنت پاسخگوی مشتری دارید. آیا اجازه دارد به مشتری بگوید کالا موجود است؟ آیا اجازه دارد سفارش را ثبت کند؟ آیا اجازه دارد بگوید سفارش قبلی کجاست؟
هر «بله» یک قدم راحتی برای مشتری است و یک قدم ریسک برای شما. سیستمی که فقط حرف میزند تقریباً بیخطر و تقریباً بیفایده است. سیستمی که هر کاری میکند، روزی کاری میکند که نباید. جای درست جایی میان این دو است و پیدا کردنش کار معمار است.
نکتهٔ مهم این است که این حد باید در سازوکار نوشته شود، نه در متن دستوری که به مدل میدهیم. اگر تنها چیزی که جلوی ایجنت را میگیرد جملهای است مثل «هرگز تخفیف نده»، شما حدی ندارید؛ یک درخواست دارید. مدل زبانی درخواست را معمولاً رعایت میکند و گاهی نه، و آن «گاهی» را نمیشود پیشبینی کرد. حد واقعی جایی است که ایجنت اصلاً به ابزار تخفیف دسترسی ندارد.
دو: کجا باید از آدم بپرسد
اگر پاسخ به تصمیم اول کاملاً «خودش انجام دهد» یا کاملاً «هیچوقت» نباشد — که معمولاً نیست — آنگاه نقطههایی هست که سیستم باید بایستد و بپرسد.
اینجا یک اشتباه رایج هست: فکر میکنیم هرچه تعداد این نقطهها بیشتر باشد امنتر است. در عمل برعکس میشود. سیستمی که برای هر چیزی میپرسد، آدم را خسته میکند و آدم خسته بدون خواندن تأیید میزند. یعنی نقطهٔ تأیید هست ولی کار نمیکند.
پس پرسش درست این نیست که «کجا بپرسد» بلکه این است که «کدام چند مورد آنقدر مهم است که آدم واقعاً بخواندش». معمولاً فهرست کوتاهی است: چیزی که پول را جابهجا میکند، چیزی که به بیرون سازمان میرود و پس گرفته نمیشود، و چیزی که دربارهٔ آن قانون یا تعهد قراردادی هست.
سه: چه چیزی بین گفتگوها میماند
بیشتر ابزارهایی که امروز هست، هر گفتگو را از صفر شروع میکنند. مشتری هفتهٔ پیش سه پیام داده، امروز پیام چهارم را میدهد، و سیستم او را نمیشناسد.
برای فروش، این تفاوت میان یک ابزار و یک سیستم است. کسی که دیروز پرسیده و امروز دوباره پرسیده، نشانهای داده که در همان یک گفتگو دیده نمیشود. کسی که سه بار قیمت خواسته و هر بار رفته، پروندهٔ متفاوتی دارد با کسی که بار اول است.
تصمیم معمار اینجا این نیست که «حافظه باشد یا نباشد» — تقریباً همیشه باید باشد. تصمیم این است که چه چیزی بماند و چقدر. نگه داشتن همهچیز هم گران است و هم مسئولیتآور؛ نگه داشتن هیچچیز یعنی هر بار از نو شروع کردن. میانهٔ کار معمولاً این است: نه متن کامل گفتگوها، بلکه چند واقعیت دربارهٔ آن شخص — چه پرسیده، در چه مرحلهای است، چه چیزی برایش مهم بوده.
چهار: وقتی مدل اشتباه کرد چه میشود
این تصمیمی است که بیشتر از همه از قلم میافتد، چون در نمایش هیچوقت پیش نمیآید.
مدل زبانی گاهی چیزی میگوید که درست نیست و با اطمینان کامل میگوید. این نه خرابی است و نه چیزی که با ابزار بهتر حل شود؛ خاصیت این فناوری است. طراحی درست یعنی سیستم طوری ساخته شود که این اتفاق، وقتی افتاد، خسارت کم بزند.
راههایش مشخص است: کارهایی که برگشتناپذیرند از دسترس ایجنت خارج شوند؛ هر پاسخی که به عدد یا موجودی یا وضعیت سفارش اشاره میکند از یک منبع واقعی خوانده شود نه از حافظهٔ مدل؛ و جایی که سیستم مطمئن نیست، گفتنِ «نمیدانم، میپرسم» بهعنوان یک پاسخ مجاز تعریف شود، نه شکست.
همان چهار تصمیم روی یک مثال
انتزاعی گفتنش کم فایده دارد. فرض کنید یک فروشگاه اینترنتی پوشاک است که در اینستاگرام و واتساپ هم سفارش میگیرد، و میخواهد ایجنتی داشته باشد که به پیامها جواب بدهد.
تصمیم اول — چه کاری خودش بکند. جواب دادن به پرسش دربارهٔ سایز، جنس پارچه و نحوهٔ شستوشو: بله، چون اطلاعاتش ثابت است و از یک جدول خوانده میشود. گفتن اینکه یک کد رنگ خاص موجود هست یا نه: بله، ولی فقط اگر از انبار خوانده شود؛ نه از چیزی که مدل «به یاد دارد». ثبت سفارش: نه در قدم اول. تخفیف دادن: نه، و نه با دستور بلکه با اینکه ابزارش را ندارد.
تصمیم دوم — کجا بپرسد. یک نقطه کافی است: مرجوعی. هر پیامی که دربارهٔ پس دادن کالاست به آدم میرسد، چون هم پول در آن هست و هم معمولاً مشتری ناراضی. بقیهٔ موارد نیازی به تأیید ندارند و اگر داشته باشند، تأییدکننده در هفتهٔ دوم دیگر نمیخواندشان.
تصمیم سوم — چه چیزی بماند. نه متن کامل گفتگوها. سه چیز: این شخص چه سایزی خریده، چه چیزی مرجوع کرده، و آخرین بار دربارهٔ چه محصولی پرسیده. همین سه قلم، دفعهٔ بعد فرق میان «سلام، چه کمکی میتوانم بکنم» و «سایز ۳۸ آن مدل موجود شد» را میسازد.
تصمیم چهارم — وقتی اشتباه کرد. پرخطرترین اشتباه در این کسبوکار این است که ایجنت بگوید چیزی موجود است و نباشد. پس هر جملهای که به موجودی اشاره میکند باید از انبار خوانده شود، و اگر انبار جواب نداد، پاسخ مجاز این باشد که «الان مطمئن نیستم، بررسی میکنم و میگویم» — نه حدس زدن.
این چهار پاسخ ده دقیقه وقت میبرد و تفاوت میان دو سیستم کاملاً متفاوت را میسازد، بدون اینکه در انتخاب ابزار چیزی عوض شود.
همان چهار تصمیم، در سه سیستمی که ساختهایم
مثال بالا فرضی بود. این بخش نیست.
این نوشته را هادی بختزاده نوشته است، معمار سیستمهای هوش مصنوعی و بنیانگذار وندیداد گروپ در ازمیر. سه سامانهای که پایین میآید ساختهٔ ماست و همان چهار تصمیم، در هرکدام، جواب متفاوتی گرفته — که خودش نشان میدهد این تصمیمها را نمیشود یک بار گرفت و همهجا تکرار کرد.
در سیستمعامل املاک (VANTA، از اردیبهشت ۱۴۰۵). تصمیم اول: پاسخ به پرسش دربارهٔ یک فایل بله، قیمتگذاری نه. تصمیم دوم: هر چیزی که به شرط یا تعهد نزدیک شود به مشاور میرسد. تصمیم سوم: خواستهٔ متقاضی با جملهٔ خودش میماند، تا وقتی فایل تازهای رسید که با آن بخواند. تصمیم چهارم — و مهمترینشان: دانش بازار بهصورت داده در سیستم است و قاعدهای نوشته شده که سیستم را از ساختنِ جواب برای محدودهای که دادهاش را ندارد منع میکند.
در همزاد دیجیتال (AIOS Twin). تفاوت اصلی در تصمیم سوم بود: یک پرونده برای یک آدم، در چهار کانال. کسی که در دایرکت پرسیده و در واتساپ ادامه داده، همان یک نفر است. این یک قابلیت نیست که بعداً اضافه شود؛ لایهای است که بقیهٔ سیستم روی آن سوار میشود.
در سامانهٔ محتوایی (همزاد سوشیال). اینجا تصمیم دوم شکل عجیبی گرفت: سیستم اجازه دارد خودش محتوا بسازد و منتشر کند، ولی هر پیامی که به بیرون میرود از یک نگهبان رد میشود. و یک قاعدهٔ اخلاقی در سند معماریاش قفل شده — ساختن نظر یا درخواستِ جعلی ممنوع، چون برندی که با صداقت ساخته شده با یک اسمِ جعلی از بین میرود.
اگر میخواهید ببینید این سه سیستم چه اندازهای دارند و چه میکنند، صفحهٔ محصولات عددها را دارد، و پروندهٔ سازنده شمارهٔ ثبت و راه استعلامش را.
چرا اینها را «معماری» مینامیم
کارِ معمار هوش مصنوعی در همین چهار تصمیم خلاصه میشود، و دلیل نامش هم همین است: خصوصیت مشترکشان همان چیزی است که معماری ساختمان را از ساختوساز جدا میکند — هر چهار تصمیم پیش از شروع گرفته میشوند و بعداً تغییرشان گران است.
جای پنجره را میشود روی نقشه با یک خط عوض کرد و روی دیوار ساختهشده نه. حد اختیار یک ایجنت هم همینطور است: اگر از ابتدا تعریف شده باشد، یک شرط در پیکربندی است؛ اگر شش ماه بعد بخواهیم اضافهاش کنیم، باید سراغ همهٔ جاهایی برویم که فرض کردهاند این حد وجود ندارد.
پس شباهت آن دو معنا اتفاقی نیست. فقط جستجوی فارسی فعلاً یکیشان را میبیند.
این برای کسبوکار ایرانی یعنی چه
سه چیز، مشخص.
اول، این نقش معمولاً وجود ندارد و کارش هم انجام نمیشود. در بیشتر پروژههایی که دیدهام، کسی هست که ابزار را میشناسد و کسی هست که کسبوکار را میشناسد، و آن چهار تصمیم در فاصلهٔ میان این دو گم میشود. نتیجه سیستمی است که در جلسهٔ نمایش خوب کار میکند و در هفتهٔ سوم رها میشود. اگر این را در کارتان دیدهاید، مشکل معمولاً ابزار نبوده.
دوم، برای کسبوکار کوچک این یک استخدام نیست، یک ساعت فکر کردن است. لازم نیست کسی را با این عنوان بیاورید. لازم است پیش از راهاندازی هر ایجنتی، همان چهار پرسش را روی کاغذ بنویسید و جواب بدهید. حتی جواب بد و نوشتهشده بهتر از جواب نانوشته است، چون نوشتهشده را میشود بعداً دید و عوض کرد.
سوم، محدودیتهای زیرساختی اینجا بخشی از معماریاند، نه حاشیه. دسترسی مستقیم به بعضی سرویسهای خارجی از ایران باز نیست و پرداخت به آنها هم ساده نیست. این یعنی تصمیم دربارهٔ اینکه کدام بخش از سیستم کجا اجرا شود، در ایران بخشی از طراحی است — نه چیزی که بعد از طراحی حل شود. طرحی که این را در نظر نگرفته باشد، روی کاغذ درست است و در عمل اجرا نمیشود.
اگر میخواهید این عبارت را در فارسی جستجو کنید
چون «معماری هوش مصنوعی» به معنای ساختمانیاش تعلق دارد، برای پیدا کردن مطلب فنی عبارت را دقیقتر کنید: «معماری سیستم هوش مصنوعی»، «طراحی سیستم ایجنت»، یا مستقیم به انگلیسی AI systems architecture. این یکی از جاهایی است که فارسی هنوز واژهٔ جداکننده ندارد و ناچار باید با کلمهٔ اضافه جدا کرد.
همین کمبود، برای کسی که فارسی مینویسد، فرصت هم هست. مطلب فنی دربارهٔ این معنا به فارسی تقریباً نیست، و کسی که دنبالش میگردد امروز چیزی پیدا نمیکند.
جمعبندی
معمار هوش مصنوعی کسی نیست که مدل میسازد یا ابزار میفروشد. کسی است که پیش از هر کدی چهار چیز را تعیین میکند: سیستم چه کاری را خودش بکند، کجا بپرسد، چه چیزی را به یاد بسپارد، و وقتی اشتباه کرد چه بشود.
این چهار تصمیم در نمایش دیده نمیشوند و در ماه سوم همهچیز را تعیین میکنند. اگر پروژهای دارید که خوب شروع شد و خوب ادامه پیدا نکرد، احتمالش هست که مشکل در انتخاب ابزار نبوده باشد.
اگر خواستید ببینید این تصمیمها در یک نمونهٔ مشخص چطور گرفته میشوند، فرق ایجنت با چتبات و اینکه هرکدام کجا به کار میآید همین چهار پرسش را روی یک مثال واقعی میبرد، و جایی که به ایجنت نباید اختیار داد دربارهٔ تصمیم اول است.