چگونه از شوراهای هوش مصنوعی برای حل مسائل مهندسی مبهم استفاده میکنم
داشتن یک دستیار هوش مصنوعی مفید است، اما برای معماری نرمافزار پیچیده کافی نیست.
اگر از هوش مصنوعی فراتر از قابلیت تکمیل خودکار (autocomplete) استفاده کنید، متوجه یک الگو میشوید. یک مدل واحد راهکاری را پیشنهاد میدهد. خوب به نظر میرسد. آن را پیادهسازی میکنید. سپس، سه روز بعد، متوجه یک نقص معماری بزرگ میشوید.
این شکستِ مدل نیست، بلکه شکستِ فرآیند شماست. یک مدل واحد بهندرت فرضیات خود را به چالش میکشد.
برای حل مسائل مبهم، به یک «شورای هوش مصنوعی» (AI Council) نیاز دارید. این یک پلتفرم جدید نیست؛ بلکه یک گردش کار (workflow) است که در آن چندین بافتار (context) هوش مصنوعی، یک پیشنهاد را از نقشهای مختلف بررسی میکنند.
هدف این است که استفاده از هوش مصنوعی را به یک گردش کار مهندسیِ تحت مدیریت تبدیل کنید.
در اینجا گردش کار آورده شده است:
• بیان مسئله: شما مسئله را تبیین میکنید. • عامل معمار (Architect Agent): یک عامل مبتنی بر منبع (source-grounded)، پیشنهادی را همراه با موازنه (trade-offs) ایجاد میکند. • نقد شورای هوش مصنوعی: نقشهای مختلف هوش مصنوعی پیشنهاد را بررسی میکنند. • ترکیب بازخوردها: یک عامل تمام بازخوردها را ارزیابی کرده و تضادها را شناسایی میکند. • دفتر ثبت اعتراضات (Objection Ledger): شما تمام اعتراضات، شدت آنها و نحوه رفع آنها را پیگیری میکنید. • مدیریت انسانی: شما تصمیم میگیرید که آیا طرح آماده است یا به دور دیگری نیاز دارید. • عامل اجراکننده (Executor Agent): یک بافتار مجزا طرح را پیادهسازی میکند. • عامل حسابرس (Auditor Agent): بافتار سومی کد را بر اساس مشخصات (spec) اصلی بازرسی میکند.
قدرت این روش از تفکیک نقشها نشأت میگیرد. فقط نپرسید «نظر تو چیست؟»؛ بلکه به نشستهای مختلف هوش مصنوعی، نقشهای مشخصی اختصاص دهید:
- متفکر سیستمی (System Thinker): ریسکها و مرزهای سیستمی را ارزیابی میکند.
- بازبین منتقد (Critical Reviewer): فرضیات را به چالش میکشد و شکافهای منطقی را پیدا میکند.
- سادهساز (Simplifier): پیچیدگیهای غیرضروری را شناسایی میکند.
- بازبین جایگزینها (Alternatives Reviewer): رویکردهای مختلف را پیشنهاد میدهد.
مهمترین بخش، «دفتر ثبت اعتراضات» (Objection Ledger) است. بدون آن، بازخوردها به نظرات مبهم تبدیل میشوند. یک دفتر ثبت، شما را مجبور میکند هر نگرانی را برطرف کنید. شما اعتراضات را در وضعیتهای Open (باز)، Accepted (پذیرفتهشده)، Rejected (ردشده) یا Resolved (رفعشده) علامتگذاری میکنید. این کار یک سابقه تصمیمگیری قابل بازرسی ایجاد میکند.
شما به یک گلوگاهِ کپی-پیست تبدیل نمیشوید. عامل مبتنی بر منبع، فرآیند ترکیب را انجام میدهد. شما در نقش «حاکم» (Governor) عمل میکنید. شما کارهای دستی را انجام نمیدهید، بلکه مسئول کنترل نقاط تصمیمگیری (gates) هستید.
تصمیمات با شماست:
- چه زمانی تکرار (iteration) را متوقف کنید.
- چه زمانی مشخصات (spec) را تأیید کنید.
- چه زمانی ریسک نهایی را بپذیرید.
از این روش برای بازسازیهای (refactors) پرخطر یا معماریهای نامشخص استفاده کنید. آن را برای رفع باگهای جزئی به کار نبرید. هزینهی اضافی (overhead) این روش تنها زمانی توجیهپذیر است که هزینه یک طراحی اشتباه بالا باشد.
از کوچک شروع کنید. از یک منتقد و یک سادهساز استفاده کنید. بلافاصله ارزش آن را خواهید دید.
Source: https://dev.to/j3nnning/how-i-use-ai-councils-to-solve-ambiguous-engineering-problems-4dii