قبل از بودجه دادن به پروژه هوش مصنوعی، این شش سوال را بپرسید

یک تیم می تواند در چند روز دمو بسازد و آن را نشانه پیشرفت بداند. اما پیش از خرج کردن بودجه باید پرسید: آیا این ابزار مسئله روزمره ای را حل می کند، کسی برای نتیجه مسئول است و می توانیم بفهمیم کار بهتر شده یا نه؟

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

شش پرسش پیش از تأمین بودجه

برای هر مورد یکی از سه وضعیت را انتخاب کنید:

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

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

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

آزمایش کم دامنه باشد، اما کار واقعی را پوشش دهد

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

آزمایشی کوچک، اما کامل است اگر دست کم بتوانیم این مراحل را ببینیم:

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

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

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

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

دسترسی، کاربران و زمان بازبینی جزو کارند

گاهی دسترسی به داده، آموزش کاربر، مسئولیت فرایند، بازبینی امنیتی و اتصال به سامانه های دیگر را «وابستگی» می نامیم؛ انگار کار هایی بیرون از پروژه اند. اگر می خواهیم بفهمیم راهکار در عمل جواب می دهد یا نه، این ها هم بخشی از پروژه اند.

مثلاً ساخت دستیار پاسخ گویی به تیم پشتیبانی را در نظر بگیرید. پیش نویس های مدل ممکن است خوب باشند، اما این به تنهایی کافی نیست. باید:

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

اگر این شرط ها برقرار نباشند، مسئله فقط یک جزئیات فنیِ حل نشده نیست؛ فرایند کاری هنوز آماده ی استفاده از راهکار نیست.

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

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

سود را بعد از استفاده ی واقعی حساب کنید

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

برای بررسی واقع بینانه تر، این حساب را انجام دهید:

ارزشِ باقی مانده = تعداد کار های قابل انجام × سهم کار های موفق و پذیرفته شده × سود هر کار − زحمت و هزینه ی تازه

هر جزء شواهد خودش را می خواهد.

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

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

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

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

فرض کنید دستیارِ اسناد در هر موردِ پذیرفته شده چهار دقیقه از وقت بازبین را کم می کند؛ امیدوارکننده است. اما شاید فقط ۴۰ درصد سند ها را بتوان به آن سپرد، کاربران نیمی از پیشنهادهایش را بپذیرند و هر مورد هم یک دقیقه بازبینی بیشتر بخواهد. این بار ارزش نهایی خیلی کمتر است. سؤال خوبی برای آزمون بعدی داریم: می توانیم سهم سند های مناسب و پاسخ های پذیرفته شده را بالا ببریم، بدون آن که خطا یا زحمت بازبینی بیشتر شود؟

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

زود سراغ فرضی بروید که می تواند پروژه را منتفی کند

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

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

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

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

پیش از شروع کار، این جمله را کامل کنید:

این زمان و پول را خرج می کنیم تا بفهمیم آیا ______، چون پاسخ آن تعیین می کند که آیا ______.

نمونه ها:

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

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

پیش از شروع، مسئول هر تصمیم را نام ببرید

یک نمایش می تواند با یک ارائه تمام شود. یک تغییر مفید وارد زندگی کاری کسی می شود.

پیش از تأیید، دست کم چهار مسئولیت را نام ببرید، حتی اگر یک نفر بیش از یکی را بر عهده داشته باشد:

• مالک نتیجه: تصمیم می گیرد آیا نتیجه ی عملیاتی، ادامه ی سرمایه گذاری را توجیه می کند.
• مالک گردش کار: رویه ها را تغییر می دهد، کاربران را هماهنگ می کند و به استثنا ها رسیدگی می کند.
• مالک فنی: یکپارچه سازی، ارزیابی، پایش و مسیر جایگزین را نگهداری می کند.
• مالک ریسک: استفاده ی مرتبط از داده، دسترسی، کنترل ها و مسیر ارجاع را تأیید می کند.

مالکیت فهرست کسانی نیست که به جلسه دعوت شده اند. هر مالک به تصمیمی نیاز دارد که هم اجازه ی گرفتنش را دارد و هم از او انتظار می رود بگیردش.

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

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

یک صفحه برای مرز و معیار های آزمایش بنویسید

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

این ها را ثبت کنید:

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

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

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

تصمیم فقط «بله» یا «نه» نیست

محک زدن پروژه رقابتی میان تأیید فوری و رد کردن نیست. هر دروازه می تواند به یکی از چهار خروجی معقول برسد.

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

اول آمادگی را ترمیم کنید، وقتی ایده باورپذیر است اما کاری کوتاه و مالک دار، مثل سنجیدن وضعیت پایه، تأیید یک مجموعه داده یا جذب کاربران، باید پیش از آزمون فنی انجام شود.

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

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

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

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