ماتریسی برای تغییر زاویه و تصمیم‌گیری بهتر درباره‌ی هوش مصنوعی

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

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

این کاوش نیست؛ تکرار یک فکر با اسم‌های تازه است.

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

ماتریس تغییر را جلوی چشم بگذارید

پیش از جلسه‌ی معماری بعدی، بازنویسی دستور مدل، مقایسه‌ی مدل‌ها یا بحث نقشه‌ی راه، از این جدول کمک بگیرید:

ماتریس عمداً کوچک است؛ قرار نیست همه‌ی پاسخ‌های ممکن را تولید کند. کارش این است که تیم را از انتخاب زودهنگامِ آشناترین راه بازدارد.

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

پاسخ دوم لزوماً دیدگاه دومی نیست

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

تحلیلی در سال ۲۰۲۵ در مجله‌ی Nature Human Behaviour به یک موازنه‌ی مهم در آزمایش‌های ایده‌پردازی اشاره کرد: کمک ChatGPT میانگین امتیاز ایده‌های منفرد را بالا برد، اما تنوع مجموعه‌ی ایده‌ها را کم کرد. معنایش این نیست که هوش مصنوعی همیشه خلاقیت را تضعیف می‌کند؛ نشان می‌دهد خروجی‌های خوش‌ساخت هم ممکن است به الگوهای مشابه برسند. این پژوهش درباره‌ی ایده‌پردازی با کمک هوش مصنوعی هشداری مفید است برای تیم‌هایی که ده پیشنهاد تولیدشده را ده دیدگاه مستقل می‌شمارند.

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

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

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

بعد فرض‌ها را مقایسه کنید، نه فقط نثر پاسخ‌ها را. از یک مدل پنج بار خواستنِ «خلاق‌تر باش» تغییر چندانی ایجاد نمی‌کند. عوض کردن کاری که مدل باید انجام دهد، راه قوی‌تری برای ساختن تفاوت است.

پیش از تغییر فناوری، صورت مسئله را عوض کنید

اثرگذارترین تغییر اغلب همان ردیف اول ماتریس است: صورت‌بندی مسئله.

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

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

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

صورت‌بندی بهتر معمولاً میان سه سطح جابه‌جا می‌شود:

• رابط کاربری: فرد چه چیزی باید ببیند یا انجام دهد؟
• گردش‌کار: کدام توالی کار باید آسان‌تر یا ایمن‌تر شود؟
• نتیجه: چه وضعیت قابل‌مشاهده‌ای باید بهتر شود؟

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

محدودیت را ابزار یادگیری بدانید

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

سامانه‌ی بازیابی و تولید متن (RAG) را در نظر بگیرید که پاسخ‌های مرتبط می‌دهد، اما به زمان پاسخ‌گوییِ هدف نمی‌رسد. واکنش معمول، بهینه‌سازی پشته‌ی فعلی است. تغییر سنجیده می‌پرسد اگر چند محدودیت دیگر را در نظر بگیریم چه می‌شود:

• اگر بازیابی فقط ۱۵۰ میلی‌ثانیه فرصت داشته باشد چه؟
• اگر نتوانیم محتوای حساس را برای پردازش به مدل بیرونی بفرستیم چه؟
• اگر هر پاسخِ اثرگذار باید منبع و تأیید انسانی داشته باشد چه؟
• اگر تیم ناچار باشد از دو ارائه‌دهنده‌ی مدل پشتیبانی کند چه؟
• اگر هزینه را به‌ازای هر کار حل‌شده بسنجیم، نه هر فراخوانی مدل، چه؟

هر محدودیت بُعد دیگری از سامانه را روشن می‌کند. مورد اول معماری کارایی را می‌آزماید؛ دومی مرز داده را؛ سومی گردش‌کار را تغییر می‌دهد؛ چهارمی میزان وابستگی را نشان می‌دهد؛ پنجمی هم روش سنجش هزینه را عوض می‌کند.

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

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

شواهد را هم جابه‌جا کنید، نه فقط نظرها را

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

شواهد را هم تغییر دهید.

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

هیچ‌کدام از این دیدگاه‌ها به‌تنهایی تمام واقعیت نیستند؛ کنار هم چیزهایی را آشکار می‌کنند که تیم پیش‌تر نمی‌دید.

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

تغییر مفید در شواهد باید دست‌کم یکی از این‌ها را عوض کند:

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

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

ارزیابی هوش مصنوعی هم به تغییر کنترل‌شده نیاز دارد

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

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

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

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

درس این نیست که هر تیمی باید سکوی ارزیابی پیچیده‌ای بسازد. هر ادعا به تغییری نیاز دارد که مرزش را بیازماید. «عامل می‌تواند کار را انجام دهد» با «عامل در شرایط واقع‌بینانه و به‌شکلی پایدار کار را انجام می‌دهد» یک ادعا نیست.

گسترش گزینه‌ها را از انتخاب نهایی جدا کنید

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

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

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

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

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

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

در ۲۰ دقیقه یک بازبینی تغییر زاویه برگزار کنید

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

• دقیقه‌ی ۰ تا ۴: وضعیت پایه را بنویسید: مسئله، گزینه‌ی ترجیحی، شواهد تعیین‌کننده و دو محدودیت. اگر تیم از پس این کار برنمی‌آید، هنوز چیزی برای تغییر روشن نشده است.
• دقیقه‌ی ۴ تا ۱۰: دو خانه‌ی ماتریس را انتخاب کنید. از دو نفر بخواهید هر کدام یک تغییر در صورت مسئله، محدودیت، شواهد، دیدگاه، سازوکار یا حالت شکست را جداگانه بررسی کنند؛ این استقلال کمک می‌کند پاسخ دوم از اولی جهت نگیرد.
• دقیقه‌ی ۱۰ تا ۱۵: پیامدها را مقایسه کنید. چه نیازی تازه آشکار شد؟ کدام فرض ضعیف‌تر شد؟ آیا راهکار ارزان‌تر یا امن‌تری باورپذیر شد؟
• دقیقه‌ی ۱۵ تا ۱۸: یک آزمون انتخاب کنید. کوچک‌ترین اقدام برگشت‌پذیری را برگزینید که بتواند خط پایه را از بهترین گزینه‌ی دیگر جدا کند: برش تازه‌ای از ارزیابی، پنج گفت‌وگو با کاربر، اجرای سایه، سنجش تأخیر، بازبینی مجوزها یا نمونه‌ی اولیه‌ی بدون هوش مصنوعی.
• دقیقه‌ی ۱۸ تا ۲۰: تصمیم را ثبت کنید: چه بُعدی تغییر کرد، چه نشانه‌ای انتظار داریم، مسئول کیست، چه زمانی بازبینی می‌کنیم و چه چیزی باعث تجدیدنظر می‌شود.

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

تغییر سنجیده را با بی‌ثباتی اشتباه نگیرید

تغییر فقط وقتی مفید است که به شواهد برسد.

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

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

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

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

تصمیم بهتر از تفاوتِ معنادار به دست می‌آید

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

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

سپس همه‌ی گزینه‌ها را با معیارهای تصمیم‌گیری یکسان بسنجید.

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