חלק 1 - תיאוריה כללית

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

מה ההבדל ביניהם:

• כמות ׳משקולות׳, והכיוונון שלהם.
• כמה מידע הם מצליחים ״להכיל״ כאינפוט?
• האם הם מבינים את האינפוט?
• האם הם יודעים להוציא את האאוטפוט הנכון?

דוגמא - מה יקרה כשנבקש ממודלים שונים ״צייר לי פיל״?

• יחידת חישוב עלות הרצה של מודל
• מחושב לפי גודל האינפוט + גודל האאוטפוט + מורכבות ה׳חישוב׳.
• מחיר המודלים נקבע ביחידות של דולר / 1מ׳ טוקנים.

דוגמא לכמות טוקנים ועלות הרצה של ״צייר לי פיל״ ב2 מודלים - האייקו ואופוס.

• שם אחר לאינפוט.
• נהוג להשתמש ב2 מונחים קשורים:
• מגבלת ׳קונטקסט׳ - כמות ה״טוקנים״ המקסימלית שמודל יכול ׳להכיל׳ כאינפוט.
• המונח context engineering - איך אנחנו שולטים במה שנכנס כאינפוט למודל.

2 דוגמאות:

פיסת קוד + cpu שיפעיל אותה.

חבילה של טולים (ולפעמים גם מידע והוראות שימוש), שניתן להתקין בקלות על קלוד / gpt.

בשפת התוכנה - mcp.

דף הוראות / הנחיות / מידע. טקסט בקובץ בפורמט md

מומלץ לייצר לכל פעולה / הנחיה חזרתית שאנחנו משתמשים בקלוד.

בקלוד ובגיפיטי - ניתן ״להתקין״ סקילים רבים.

האייג׳נט יבחר לבד מתי להשתמש בכל סקיל, לפי התיאור שנתנו לו.

חבילה של טולים וסקילים.

• בגיפיטי - אין קונקטור בלי פלאג אין. רק פלאג אינים מאושרים.
• בקלוד - אפשר לייצר קונקטור קסטום מייד ולחבר אותו.

כל תוכנה מבוססת מודל לל״מ עם הגדרה של אחריות משימתית

• אין צורך לקרוא לו בשם.
• הוא לא יודע ליזום.
• הוא צריך בקרה אנושית.
• הוא עושה מה שאומרים לו.
• הוא עובד ממש טוב.

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

הטריגר הוא מה שמפעיל את ה״סשן״.

• ליוזרים סטנדרטיים יש 2 טריגרים - הודעה / לפי זמן מסוים.
• למתכנתים - ניתן ליישם טריגר לפי api ולחבר באמצעות תוכנה למה שרוצים (נכנס מייל / נכנסת הודעה / הטמפ׳ בתל אביב מתחת ל28 מעלות לפי גוגל).

הרצה בודדת של אייג׳נט.

כל ה״קונטקסט״ מתנקה למצב ההתחלתי אחריו.