از نمونه اولیه تا محصول: چرا اکثر POCهای هوش مصنوعی متوقف میشوند
الگویی که در این حوزه بارها تکرار میشود: تیمی در چند هفته نمونهای میسازد که در جلسه خوب کار میکند، همه راضیاند، و بعد پروژه شش ماه در همان نقطه میماند و بیسروصدا کنار گذاشته میشود.
دلیلش معمولاً فنی نیست. دموی خوب و محصول قابل اتکا دو چیز متفاوتند، و فاصلهشان جایی است که کسی برایش برنامه نداشته.
شکاف اول: معیاری برای «بهاندازه کافی خوب» وجود ندارد
این تنها و مهمترین دلیل توقف است.
در دمو، ده پرسش پرسیده میشود و همه جواب خوبی میگیرند. بعد سؤال میشود «آیا میتوانیم به مشتری بدهیم؟» و هیچکس نمیتواند جواب بدهد، چون هیچ عددی وجود ندارد. بدون عدد، تصمیم به تعویق میافتد — و تعویقشدن، همان توقف است.
راهش این است که پیش از ساختن نمونه مجموعه آزمون بسازید: پنجاه تا صد پرسش واقعی با جواب درستشان، از تیکتها و تماسهای واقعی. و سه عددی که سنجیده میشوند:
درصد پاسخ درست. درصد مواردی که درست گفته «نمیدانم». و درصد پاسخهای قاطعِ غلط.
عدد سوم تنها عددی است که تصمیم میسازد. آستانهاش را هم پیش از شروع تعیین کنید، نه بعد از دیدن نتیجه.
شکاف دوم: پرسشهای واقعی شبیه پرسشهای دمو نیستند
در دمو، پرسشها را کسی میپرسد که سامانه را ساخته و میداند چطور بپرسد.
کاربر واقعی جور دیگری مینویسد: کوتاه، محاورهای، با غلط املایی، گاهی چند سؤال در یک جمله، و گاهی چیزی که اصلاً سؤال نیست. در فارسی این فاصله بزرگتر هم هست، که در چالشهای پردازش زبان فارسی توضیحش دادهایم.
تنها راه بستن این شکاف، استفاده از پرسشهای واقعی از همان ابتداست — نه نمونههایی که خودتان نوشتهاید.
شکاف سوم: داده تمیز در برابر داده واقعی
نمونه اولیه معمولاً روی ده سند منتخب ساخته میشود؛ سندهایی که مرتباند و بهروزند.
داده واقعی اینطور نیست: چند نسخه از یک سند، بخشنامههایی که همدیگر را نقض میکنند، فایلهای اسکنشده بدون متن، و دانشی که اصلاً مکتوب نشده.
وقتی دامنه از ده سند به هزار سند میرسد، کیفیت افت میکند و علتش مدل نیست — منبع است. اگر این کار در برآورد دیده نشده باشد، پروژه دقیقاً همینجا متوقف میماند.
شکاف چهارم: چیزی که در دمو لازم نیست
دمو به اینها نیاز ندارد و محصول بدونشان به تولید نمیرود:
احراز هویت و سطح دسترسی — که باید در لایه بازیابی باشد نه در فیلترکردن پاسخ.
ثبت وقایع، برای اینکه وقتی پاسخی اشتباه بود بشود فهمید چرا.
سقف مصرف و رفتار در شکست سرویس.
مسیر ارجاع به انسان.
و سازوکار بهروزنگهداشتن نمایه وقتی سندی عوض میشود. بدون این، سامانه چند ماه بعد با اطمینان از آییننامه منسوخ جواب میدهد.
شکاف پنجم: مالک ندارد
نمونه اولیه معمولاً پروژه تیم فنی است. محصول به مالک کسبوکاری نیاز دارد — کسی که تصمیم بگیرد کدام پرسشها در دامنهاند، پاسخهای اشتباه را بازبینی کند و اسناد را بهروز نگه دارد.
اگر این نقش تعریف نشده باشد، سامانه بعد از راهاندازی بهتدریج بیکیفیت میشود و کسی مسئولش نیست.
مسیری که متوقف نمیماند
ترتیبی که در پروژههای موفق دیدهایم:
مجموعه آزمون، قبل از نمونه اولیه. با آستانه توافقشده.
یک حوزه باریک با اسناد سالم. یک محصول، یک آییننامه، یک واحد. نه «همه دانش سازمان».
نمونه اولیه روی داده واقعی، نه منتخب. حتی اگر داده کثیف است — مخصوصاً اگر کثیف است، چون آنوقت اندازه کار معلوم میشود.
راهاندازی داخلی بهشکل پیشنهاد به کارشناس. دستیار پاسخ را آماده میکند و کارشناس تأیید میکند. ریسکی ندارد و اصلاحهای کارشناس، بهترین داده برای بهبود است.
و بعد در اختیار کاربر نهایی، در همان دامنه باریک.
گسترش دامنه، آخرین قدم است — نه اولین.
سؤالی که در جلسه دمو باید پرسید
اگر دموی یک راهکار هوش مصنوعی را میبینید، این چهار سؤال بیشتر از خود دمو به شما میگویند:
این با چند سند ساخته شده و در دامنه واقعی چند سند خواهد بود؟
پرسشهای این نمایش از کجا آمدهاند؟
وقتی جواب را نمیداند چه میکند — میشود یک نمونه ببینم؟
و کیفیت را با چه معیاری میسنجید؟
جواب سؤال سوم را همانجا امتحان کنید: چیزی بپرسید که مطمئنید در اسناد نیست. سامانهای که برای آن هم جوابی میسازد، همان مشکل اصلی را با مراحل بیشتر بازتولید کرده — و آن، نشانهای است که هیچ برآورد و برنامهای جبرانش نمیکند.