برای پروژه هوش مصنوعی برنامه بریزید؛ نه برای یک نمایش موفق

در جلسه نمایش، دستیار پشتیبانی به چند پرسش جواب می دهد و همه از سرعت ساختش تعجب می کنند. چند ماه بعد، همان تیم با پاسخ های قدیمی، دسترسی های مبهم، هزینه ای بالاتر از انتظار و کاربرانی روبه روست که جواب ها را دوباره از اول بررسی می کنند. چه چیزی عوض شد؟

اغلب، نه یک اتفاق عجیب؛ بلکه چند واقعیت بود که از روز اول در پروژه حضور داشتند، اما کسی برایشان برنامه نریخت. نمونه اولیه جواب می داد، پس همه خیال کردند بقیه کار هم به همین سادگی است. ریسک ها وقتی جدی شدند که سامانه از نمایش محدود به کار روزانه رسید.

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

اول هدف را از ابزار جدا کنید

«یک عامل بسازیم» یا «هوش مصنوعی را وارد پشتیبانی کنیم» هنوز هدف پروژه نیست. هدف باید به کاری اشاره کند که برای کسی بهتر می شود: مثلا کم کردن زمانی که کارشناسان صرف پیدا کردن پاسخ در سند های داخلی می کنند.

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

پیش از انتخاب مدل، جواب این پرسش ها را پیدا کنید: چه کسی از سامانه استفاده می کند؟ کدام گام کارش تغییر می کند؟ امروز چه چیزی مانع اوست؟ از کجا می فهمیم وضع بهتر شده؟ و کدام تصمیم باید همچنان دست انسان بماند؟

فرض های معمول را روی میز بگذارید

بسیاری از ریسک های پروژه عجیب نیستند. پایگاه دانش ممکن است قدیمی باشد؛ کاربر شاید بیرون از محدوده دستیار سوال کند؛ مدل ممکن است با زمینه ناکافی جوابی روان اما بی پشتوانه بسازد؛ دسترسی به بعضی سند ها محدود باشد؛ یا هزینه و تاخیر در استفاده واقعی با پایلوت تفاوت کند.

همین که این موارد آشنا هستند، دلیل بیشتری است که زودتر درباره شان حرف بزنیم. برای هر فرض مهم مشخص کنید چه کسی آن را بررسی می کند، چه نشانه ای خلافش را ثابت می کند و اگر درست از آب درنیامد چه گزینه ای داریم. مثلا اگر کیفیت بازیابی سند کافی نبود، آیا دامنه را محدود می کنیم، محتوا را اصلاح می کنیم یا سامانه را به صف بازبینی می فرستیم؟

در پروژه داده هم همین قاعده برقرار است. اگر داشبورد به تعریف «مشتری فعال» وابسته است، باید معلوم باشد چه کسی تعریف را تایید می کند. اگر مدل برچسب های انسانی می خواهد، تیم باید بداند برچسب ها چگونه تولید شده اند. برنامه ای که فرض ها را پنهان می کند، اطمینان می فروشد؛ برنامه ای که آن ها را روشن می کند، مسیر یادگیری می سازد.

نمونه اولیه جواب همه سوال ها نیست

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

این فاصله در کار عامل ها بیشتر به چشم می آید. گزارش مهندسی عامل های LangChain از استفاده گسترده در محیط عملیاتی می گوید، اما کیفیت را همچنان مانعی مهم می داند و بر نقش ارزیابی و مشاهده پذیری تاکید می کند. گزارش وضعیت مهندسی عامل ها از LangChain یادآور می شود که عامل آماده فقط عاملی نیست که یک بار کار را انجام دهد؛ باید بتوان رفتار آن را دید، آزمود و با تغییر شرایط در محدوده نگه داشت.

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

سرعت را با میزان شناخت تنظیم کنید

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

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

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

برای مشکل های عادی، راه جایگزین داشته باشید

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

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

در مقاله «کار پنهان پشت پروژه های قابل اتکای هوش مصنوعی» به کار های پیرامون مدل پرداخته ام: داده، یکپارچه سازی، آزمون، راهبری و عملیات. همین بخش ها اغلب در برآورد اولیه کم دیده می شوند. اگر تیم برایشان وقت نگذارد، دیر یا زود به شکل اضافه کاری، هزینه یا تاخیر ظاهر می شوند.

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

برنامه باید با یادگیری عوض شود

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

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

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

مهدی لطفی نژاد متخصص داده و هوش مصنوعی، مشاور و مدرس رسمی با نزدیک به ۲۰ سال تجربه صنعتی است. او به صدها متخصص در خاورمیانه و جنوب شرق آسیا آموزش داده و در DATATWEETS می نویسد تا این تجربه عملی را رایگان و خودآموز در اختیار همه بگذارد.