הבלוג של ינון פרק

הפוסט היום מסיים את החלק הראשון של סידרת הפוסטים על פיתוח משולב AI. בסידרה עד עכשיו למדנו איך להתקין את ספריית OpenAI Agents SDK, למדנו על שני סוגי מערכות משולבות AI (סקריפט שרץ ברקע וסוכן אינטרקטיבי) ואנחנו אפילו כבר יודעים איך לכתוב תוכניות פשוטות משני הסוגים.

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

זוכרים את השורה-

result = await Runner.run(agent, user_message)

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

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

דוגמאות למערכות כאלה יכולות להיות:

1. ממשק צ'ט עם סוכן חכם כמו באתר ChatGPT.

2. סוכן תמיכה חכם שעונה לפניות של משתמשים במקום נציג אנושי.

3. סוכן מכירות חכם שמתקשר למשתמש ומנהל שיחה כדי למכור מוצר.

4. מורה לאנגלית שמנהל עם משתמש שיעור אנגלית מובנה תוך כדי שיחה.

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

הבסיס של כל מערכת אג'נטית היא היכולת לפנות למודל שפה גדול ולקבל תשובה או יותר נכון "השלמה". בפוסט זה נראה איך לפנות למודל שפה גדול דרך הספריה openai-agents-sdk.

הי חברים,

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

כשבדיקה אחת נכשלת אפשר להסתכל ולתקן.

כש 5 בדיקות נכשלות אפשר להסתכל ולתקן אבל זה יכול לקחת זמן, אז דוחים את זה לאחרי הגירסה.

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

כש 50 בדיקות נכשלות הדרך היחידה להתקדם היא למחוק את כל הבדיקות ולהתחיל מחדש.

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

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

הפונקציה itertools.pairwise בפייתון לוקחת רשימה ומחזירה רשימה של זוגות חופפים מתוך הקלט המקורי, לדוגמה:

>>> import itertools
>>> list(itertools.pairwise(range(100)))
[(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9), (9, 10), (10, 11), (11, 12), (12, 13), (13, 14), (14, 15), (15, 16), (16, 17), (17, 18), (18, 19), (19, 20), (20, 21), (21, 22), (22, 23), (23, 24), (24, 25), (25, 26), (26, 27), (27, 28), (28, 29), (29, 30), (30, 31), (31, 32), (32, 33), (33, 34), (34, 35), (35, 36), (36, 37), (37, 38), (38, 39), (39, 40), (40, 41), (41, 42), (42, 43), (43, 44), (44, 45), (45, 46), (46, 47), (47, 48), (48, 49), (49, 50), (50, 51), (51, 52), (52, 53), (53, 54), (54, 55), (55, 56), (56, 57), (57, 58), (58, 59), (59, 60), (60, 61), (61, 62), (62, 63), (63, 64), (64, 65), (65, 66), (66, 67), (67, 68), (68, 69), (69, 70), (70, 71), (71, 72), (72, 73), (73, 74), (74, 75), (75, 76), (76, 77), (77, 78), (78, 79), (79, 80), (80, 81), (81, 82), (82, 83), (83, 84), (84, 85), (85, 86), (86, 87), (87, 88), (88, 89), (89, 90), (90, 91), (91, 92), (92, 93), (93, 94), (94, 95), (95, 96), (96, 97), (97, 98), (98, 99)]

בואו נרחיב אותה באמצעות שני פרמטרים:

1. פרמטר size קובע את גודל ה״זוג״ (וכן כל מספר גדול מ-2 כבר לא יהיה זוג).

2. פרמטר stride קובע את גודל הצעד כלומר החפיפה בין הזוגות.

לדוגמה ארצה להיות מסוגל להפעיל את הפונקציה כדי לקבל את כל השלשות החופפות בטווח המספרים עד 100, או לקבל קבוצות של 5 מספרים בהפרש של 3 אחת מהשנייה.

רוב הספריות הפופולריות לפיתוח צד לקוח לא תומכות בהרחבה של קומפוננטות מבחוץ וזה חבל. נדמיין שקיבלתי קומפוננטת ריאקט של מונה לחיצות:

export default function Counter() {
    const [count, setCount] = useState(0);

    return (
        <div>
            <p>Count = {count}</p>
            <button onClick={() => setCount(c => c + 1)}>+1</button>
        </div>
    );
}

אני רוצה להוסיף לו כפתור איפוס, אבל בלי לשנות את הקובץ המקורי של Counter. אפילו אם אני מוכן לשנות את הקריאות ל Counter מבחוץ כלומר לעטוף אותו באיזה CounterWithReset אין לי איך לעטוף את הקומפוננטה ולשנות את ה Virtual DOM שהיא מחזירה. זה פשוט לא בכללים.

בואו נראה שתי דוגמאות לספריות שכן מאפשרות מנגנון כזה ומה הופך אותו לאפשרי.

"זה עובד?"

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

וזה בכלל לא משנה.

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

1. כמה קל יהיה לשנות את הפרויקט כשהדרישות ישתנו?

2. כמה משאבים זה צריך?

3. כשזה יישבר, האם אדע לתקן?

4. כשימציאו חומרה חדשה, מערכת הפעלה חדשה או גירסאות חדשות לספריות, כמה קל יהיה להתאים את המערכת לתשתית החדשה?

5. אפשר לשבור את זה בטעות?

6. אפשר לשבור את זה בכוונה?

7. מה עדיין לא עובד?

8. איזה דרישות חדשות עשויות להיות לי שלא יתאימו לארכיטקטורה שנבחרה ויכריחו אותי לבנות מערכת חדשה?

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