پیش از تأمین بودجه، پروژه‌های کوچک هوش مصنوعی را محک بزنید

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

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

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

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

آزمون شش‌دروازه‌ای

برای هر دروازه از سه برچسب استفاده کنید:

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

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

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

«کوچک» باید یک چرخه‌ی کامل یادگیری را توصیف کند

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

یک پروژه‌ی واقعاً کوچک به‌اندازه‌ی کافی از مسیر را در بر می‌گیرد تا بشود این‌ها را مشاهده کرد:

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

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

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

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

آمادگی جزئی از تعریف پروژه است

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

یک دستیار پاسخ‌گویی پشتیبانی را در نظر بگیرید. مدل شاید پاسخ‌های خوبی پیش‌نویس کند، اما ارزش همچنان به چند شرط بستگی دارد:

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

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

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

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

ارزش را پس از پذیرش و اصطکاک بسنجید

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

یک راه ساده برای به چالش کشیدن برآورد این است:

سود محقق‌شده = حجم واجد شرایط × نرخ استفاده‌ی موفق × سود هر واحد − بار عملیاتی تازه

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

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

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

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

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

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

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

فرضی را بیازمایید که به احتمال زیاد پروژه را تمام می‌کند

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

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

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

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

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

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

نمونه‌ها:

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

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

مالکیت پیش از آزمون شروع می‌شود

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

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

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

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

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

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

به‌جای قولی خوش‌بینانه، از «قرارداد بودجه» استفاده کنید

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

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

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

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

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

تصمیم بیش از دو خروجی دارد

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

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

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

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

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

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

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