پیش از ساخت، مسئله را بزرگ تر از یک ابزار ببینید

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

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

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

درخواست را به کار واقعی وصل کنید

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

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

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

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

یک مسئله می تواند چند جور راه حل داشته باشد

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

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

گزارش مهندسی هوش مصنوعی Datadog از سامانه هایی با بازیابی، فراخوانی ابزار، مهندسی زمینه، تلاش دوباره، مشاهده پذیری و ارزیابی می گوید. بنابراین نیازمندی «مدل پاسخ خوبی بدهد» کافی نیست. باید رفتار در وضعیت های مبهم و شکست را هم تعریف کنیم. گزارش وضعیت مهندسی عامل ها از LangChain در ۲۰۲۶ نیز از اهمیت ارزیابی و مشاهده پذیری در حرکت عامل ها به محیط عملیاتی می گوید.

کشف نیاز را به چهار گام تقسیم کنید

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

کار روزمره را دنبال کنید. مسیر رسمی و کار واقعی همیشه یکی نیستند. از کاربر بخواهید یک مورد عادی، یک مورد دشوار و یک استثنا را توضیح دهد. ببینید داده از کجا می آید، چه کسی آن را تایید می کند و کار کجا از مسیر رسمی بیرون می رود.

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

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

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

ایده را بلندپروازانه بپرسید، وعده را دقیق ببندید

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

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

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

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

گاهی بهترین پاسخ، ساختن نیست

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

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

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

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