עקרון ה-AI המינימלי

לארכיטקטורת תוכנה יש כלל הנקרא "עקרון הכוח המינימלי" (principle of least power). הוא קובע שעליך להשתמש בכלי הפשוט ביותר כדי לפתור בעיה. השתמש בסקריפט במקום בפריימוורק ענק. השתמש בקובץ שטוח במקום במסד נתונים מורכב. הכלי חייב להתאים למשימה.

עקרון ה-AI המינימלי פועל לפי אותו היגיון.

AI מייצר שגיאות. הוא יוצר הטיות וחוסר עקביות. הוא יקר. והחשוב מכל, ה-AI עושה אופטימיזציה כדי להיראות מיומן במקום להיות צודק. שימוש ב-AI מוקדם מדי הופך אותך לתלוי בכלי שחסר לו ההקשר שלך.

הפסיקו להתייחס ל-AI כאל התשובה. התייחסו אליו כאל טיוטה ראשונית מהירה.

נסו את החלופות הבאות במקום:

  • Rubber duck debugging: הסבירו את הבעיה שלכם בקול רם כדי למצוא את הפתרון בעצמכם.
  • תיעוד (Documentation): חפשו בתיעוד קיים במקום לבקש הסבר גנרטיבי.
  • סקירת עמיתים (Peer review): שאלו קולגה במקום מודל שרק רוצה לרצות אתכם.

אני מרבה לפנות ל-AI מהר מדי. אני עושה זאת כי הוא זמין. הוא יוצר משהו שנראה כמו התקדמות תוך שניות. אבל עבודה אמיתית היא איטית. עבודה אמיתית כוללת אימות, הטלת ספק והחלטה אם הפלט מתאים לצרכים שלכם.

AI טוב בלגרום לדברים להיראות נכונים. הוא משתמש בשפה בטוחה ובמשפטים ארוכים כדי להיראות יסודי. הוא מרבה לומר לכם בדיוק את מה שאתם רוצים לשמוע. זה מסוכן כאשר הגישה שלכם שגויה.

כשאתם משתמשים ב-AI לכתיבת קוד, שאלו את השאלות הבאות:

  • מה חייב להיות נכון כדי שזה יעבוד?
  • אילו הנחות מוקדמות נעשות כאן?
  • אילו מקרי קצה (edge cases) קיימים בהקשר הספציפי שלי?

עקרון ה-AI המינימלי אינו עוסק בהימנעות מ-AI. הוא עוסק בהימנעות מאוטומציה יתר. אל תפנו לטנק כשאופניים יכולים לעשות את העבודה. אל תשתמשו ב-AI כשכלי פשוט יותר עולה פחות ועובד טוב יותר.

האנשים שמנצחים הם אלו שיודעים מה העבודה שלהם עושה, גם כשה-AI נעלם.

מקור: https://dev.to/amrree/the-principle-of-least-ai-5c68

קהילת למידה אופציונלית: https://t.me/GyaanSetuAi