Speaker A
שלום לכולם. ברוכים הבאים לעוד פרק של קלאוד AI. היום פרק מיוחד, שונה מאחרים, פרק סולו.
פרק סולו על הפקת מערכות GenAI בפרודקשן, עם דגש על אתגרים, מיתוסים וטכניקות מתקדמות.
Key Takeaways
- מערכות AI בפרודקשן דורשות תשתית נתונים חזקה, בקרה וניהול מתמיד.
- רג בסיסי לא מספיק לפרודקשן; יש צורך בטכניקות מתקדמות וגמישות.
- מיתוסים על AI מהיר וקל לשימוש בארגון אינם נכונים במציאות הפרודקשן.
- שיתוף פעולה בין ספקי ענן לארגון קריטי להצלחת הפרויקט.
- אבטחה ורגולציה הן חלק בלתי נפרד מהטמעת AI בארגונים.
What the video covers
- הצגת ניסיון מעשי של קלאודזון בפרויקטים של AI בפרודקשן, לא רק פיילוטים או דמו.
- ההבדל בין חווית GPT לצרכן לבין מערכות ארגוניות בפרודקשן והאתגרים הנלווים.
- מיתוסים נפוצים כמו שהמודל ילמד בקלות מדאטה ארגוני או ש-AI תמיד מהיר.
- חשיבות דאטה מסודר, מדידה, וולידציה, מוניטורינג וניהול עלויות בפרודקשן.
- הסבר על retrieval generation (רג) והבעיות של רג בסיסי במערכות אמיתיות.
- אתגרים ב-knowledge bases: חיתוך מסמכים לא מדויק, דירוג לא מותאם, חוסר הבנת שאילתות מורכבות.
- הצורך במודולריות, גמישות, מנגנוני בקרה ולולאות משוב במערכות AI מתקדמות.
- חשיבות איכות הנתונים, prompt engineering, ושיקולי ארכיטקטורה בפרויקטים אמיתיים.
- התייחסות לנושאי אבטחה, פרטיות, רגולציה ודרישות גיאוגרפיות בפרויקטים בענן.
- המלצות לשיטות עבודה בפרודקשן כמו smart retries, graceful degradation וחשיבות הלמידה מהטעויות.
Chapters
- 00:00הקדמה ומטרת הפרק
- 01:55האתגר של דאטה ומודל GPT ארגוני
- 03:58הצגת ניר שילוני וקלאודזון
- 05:38מיתוסים מול מציאות בפרודקשן AI
- 08:01הבעיות של רג בסיסי בפרודקשן
- 10:02אתגרים ב-knowledge bases ובחיפוש סמנטי
- 14:42שיפור רלוונטיות ודירוג תשובות
- 17:27מודולריות, לולאות משוב וטכניקות מתקדמות
- 22:17איכות נתונים, prompt engineering וארכיטקטורה
- 26:18אבטחה, רגולציה ודרישות גיאוגרפיות
Full Transcript — Download SRT & Markdown
Speaker A
למעשה, הפרק הזה בא לתת מצגת שאני חושב שהייתה מעניינת וטובה, שזכיתי להעביר שבוע שעבר באמזון בג'נרלו. והמטרה של המצגת הזאת, כמו שאתם רואים גם ממותגת קלאודזון, בעצם החברה שאני עובד בה בקלאודזון, זכרו לעשות כבר לא מעט פרויקטים
Speaker A
של AI. חלקם מוצלחים, חלקם פחות, במיוחד בהתחלה, והיום ברוך השם כבר הכל טוב, אבל הייתה תקופת למידה משמעותית. וחשבנו שגם עבורנו וגם כשירות לציבור, באמת כפשוטו, נעלה את זה על הכתף, נכתוב מה עבד, מה לא עבד, מה יכול לעזור לאחרים, באיזה אתגרים
Speaker A
נתקלנו, בעיקר מה פתר אותם. אז בעצם המצגת הזאת היא מצגת מאוד תכליתית שיכולה לתת, לדעתי, הרבה מאוד כלים לכל מי ששוקל להתעסק בזה, להקים מערכות שהם מבוססות רג או אייג'נטים, להיכנס לעולם הפרודקשן. הדגש על פרודקשן, לא על פיילוטים, לא על דמוים, כי
Speaker A
בשביל זה אפשר להסתדר גם בלי המצגת וגם בלי הטיפים. פשוט בפיילוט דברים עובדים נחמד. אוקיי? אז מי שבאמת שוקל להיכנס לעשות את הצעד הזה, אני חושב שיכול להרוויח הרבה מאוד מהניסיון שצברנו. ואם תרצו לכתוב איזה מילה תודה, גם בכיף,
Speaker A
אבל לא בשביל זה אנחנו עושים את זה. המטרה היא באמת ככה להועיל לאנשים. אני מקווה שמזה יהיה שכרנו. אז בואו נצא לדרך.
Speaker A
דמיינו שאתם נכנסים לחדר ישיבות. לפטופים פתוחים, מסכים מאבבים, ואנשים עם עיניים נוצצות. המילה הראשונה שעפה בחדר היא לא שלום אלא AI.
Speaker A
ואז מגיע הרקע, הרגע הקבוע. מי שומר ביטחון? אנחנו רוצים GPT, אבל שלנו. עכשיו פה אני שואל את השאלה שתמיד עוצרת הכל.
Speaker A
מעולה, מאיזה דאטה המודל ילמד? וכאן נכנסת חוכמה יהודית מאוד פשוטה. סוף מעשה במחשבה תחילה. זה לא שיעור מוסר, זה הנחיה ארכיטקטונית.
Speaker A
כי בעולם AI בלי דאטה מסודר, ביצועים מדודים, גדרות הבטחה, גרדריילס, בורים, שום מודל, חכם ככל שיהיה, לא יחזיק מעמד. וזה הלמה של כל מה שאנחנו הולכים לדבר עליו עכשיו. לא רק לבנות משהו שעובד, אלא משהו שמחזיק יציב, בטוח, מדויק, וגם כשמסתיים
Speaker A
ההייפ של החדר, ימשיך לעבוד. שתי המילים על קלאודזון, כי בכל זאת יש הרבה הכרת הטוב לחברה הזאת. קלאודזון קמים כל בוקר אני וקלאודזון עם מטרה פשוטה: לעזור לארגונים להוציא מהענן הרבה יותר עם הרבה פחות מאמץ מצידם. כשותף פרימיר של אמזון, האמת גם שותף השנה של
Speaker A
אמזון וגם של גוגל קלאוד, אנחנו חיים את העולם הזה כבר יותר מעשור. לא ברמת המצגות, ברמת הפרודקשן, ברמת המערכות, הלקוחות, התקציבים והדדליין האמיתיים.
Speaker A
מה שמייחד אותנו זה השילוב של כל העולמות במקום אחד. פינופס, AI, MSP, שירותים מנועים, דופס, דאטה, מיגרציות לענן מול כל המגזרים, מול דיגיטל, מול פאבליק סקיור. כל השרירים שצריך כדי להפוך ענן למנוע צמיחה ולא רק לאוסף של שירותים. והיופי הוא שכשכל זה
Speaker A
קורה במקום אחד, הלקוחות שלנו תמיד יכולים להתמקד במה שהם עושים הכי טוב בזמן שאנחנו דואגים שההערכות יעבדו חלק, יגדלו בקלות וישארו תחת שליטה מבחינתויות. בסוף זה כל הסיפור. אנחנו פה כדי להפוך ענן מאתגר טכנולוגי ליתרון תחרותי, וזה מה
Speaker A
שמניע אותנו כל יום. מי אני בשתי מילים? ניר שילוני. אני מלווה ארגונים בעיסוק ב-GA בפרודקשן אמיתי, לא רק דמוים. ביום יום אני ארכיטקטן וגני אתגרים בקלאודזון. עבדתי עם עשרות חברות בתעשייה הישראלית. אני גם מנחה את הפודקאסט שאתם עכשיו שומעים, קלאודי,
Speaker A
שמטרתו לעשות סדר ולהפוך את העולם הזה להרבה יותר ברור ושמיש. המטרה שלי וגם של המפגש הזה זה לעזור לכם להרגיש מוכנים ולמות צפים מהשינויים, כל הפומו שעף עלינו. מי שמתעסק, מי שלא מתעסק, אנחנו מוצפים במידע חדש באמת לדעת להפריד את העיקר
Speaker A
מהתפל. אז אני חושב שאנחנו נתחיל בקצת מיתוסים מול מציאות, כי יש הרבה דברים שנראים יפים על הנייר ונשמעים טוב ביכול שאנחנו צרכן קצה של GPT לייק לעומת המציאות.
Speaker A
אז בתור התחלה, כבר זה אחד השקפים שאני הכי אוהב, כי הוא חוסם את הפער בין איך AI מרגיש לבין איך שהוא עובד באמת.
Speaker A
אנחנו כולנו מכירים את התחושה. נכנסים לצד GPT, צ'אט GPT, כשם קוד, כן ג'מיני, קלאוד.
Speaker A
שואלים שאלה והוא עונה מהר, יפה, מסודר, ואז ידמה לנו שאם זה עובד פה בטח זה יעבוד בארגון.
Speaker A
זה המיתוס הראשון. מה שעובד בצ'אט GPT עם דאטה אישי יעבוד גם עם דאטה ארגוני. בפועל, מערכות פרודקשן, צחיחות, אימות של דאטה, טיפול בשגיאות, תשתיות ענן, בדרך כלל הבטחה, אנליטיקה, עולם אחר לגמרי. המיתוס עושה שני המודולים מנעולים לגמרי. אני
Speaker A
רק שולח פרומט. המציאות זו אחריות משותפת, responsibility בלשון ספקי הענן. לכן יש את הדאטה, את הפילוח, את הרג שאנחנו מדברים עליו עוד מעט, הוולידציה, את המוניטורינג, את ניהול העלויות, את הסקיוריטי, את התשתיות.
Speaker A
לספק יש את המודל והפלטפורמה. זה שיתוף פעולה, זה לא קסם אוטומטי. אולי המצחיק ביותר, המיתוס הוא ש-AI הוא סופר מהיר. במצגות כן, בפרודקשן לפעמים סופר איטי.
Speaker A
ולייטנסי תור בקשות Q מודלים כבדים, זאת אומרת מציאות שמתכוננים אליה מראש. אז מה אנחנו בעצם אומרים בשקף הזה? שבין החוויה לצ'אט GPT, שוב קלאוד ג'מיני, כל דבר שהוא קונסיומר, לבין מערכת ארגונית יש תהום. ואם לא מזהים את הפערים האלה מוקדם, בונים
Speaker A
מערכת על השליה, לא על אמת. ומכאן נמשיך לדבר איך מגשרים על הפער הזה בצורה אחראית, מאובטחת, בשמשהו שגם נראה כמו מוצר חי ולא כמו דמו. כשהתחלנו לפני קרוב לשנתיים עם עולמות הרג למיניהם, מי שלא מכיר, זה retrieval generation. זה בעצם היכולת שלנו לעבוד מול
Speaker A
מידע ארגוני מפולח ולא לרוץ לאינטרנט ולהוציא שאלות, להגדיר למודל מה הוא מתשאל, למי מותר לגשת, מה קורה עם הדאטה פרייסי שלי, איך אני עושה סקיילינג, לאיזה מחלקות מותר לגשת וכו' וכו' וכו'. אז אנחנו התחלנו עם סשן מאוד מומלץ שעדיין רץ באמזון בימים
Speaker A
האלו שנקרא on data, ובעצם חצי יום, קצת יותר, עד ש כזה, שיושבים ארגונים, חברות שלא מכירות רג ובונות ביחד את הרג הראשון שלהם, לוקחות איזשהו זקיס, סתם תכנאי שטח להנגיש להם את הספרוני תכנאים ולתת להם לענות בזמן אמת לפי תשאול
Speaker A
בצ'אטבוט בשפה חופשית. סתם דוגמה פשוטה, כן? כל אחד עושה מה שהוא רוצה. להביא זה צ'אטבוט שיענה כמו נציג מכירות וכו'. והחוויה הזאת הייתה מאוד מאוד טובה, ואני חושב שגם אנחנו, ואני בטוח שגם הלקוחות חשבו שהדבר הזה הוא חזות הכל.
Speaker A
ובאמת אם זה עובד בכל כך קלות בדמו, זה כנראה יעבוד טוב גם בפרודקשן. אבל כאן אני רוצה להראות לכם למה רג בסיסי, או כמו שאנחנו קוראים לו, נעיב רג פשוט, לא עובד. הפרודקשן על הנייר זה נראה טוב: שאלה, חיפוש, תשובה,
Speaker A
אבל במציאות כמעט תמיד זה מתפרק. נתחיל מהמיתוס. הרבה ארגונים חושבים שברגע שהם עשו וידינג למידע, חיברו אותו לאלם ועשו שאילתא, זהו, יש להם רג. בפועל זה מוביל לבעיות שאנחנו רואים שוב ושוב אצל לקוחות.
Speaker A
הבעיה הראשונה היא מבנה קשיח. הפייפליין כולו תלוי בהקלט מסוים, בפורמט מסוים, בשיטת חיפוש אחת, לרוב סמנטית. אין גמישות, אין הבנה של סוגי מידע שונים, והאינדקס נהיה נקודת הכשל.
Speaker A
הבעיה השנייה, חיפוש לא איכותי. הרגסיסי בעצם מחלץ קטעים שלא בהכרח רלוונטיים, לפעמים קורבים סמנטית, אבל הם לא עונים לשאלה. לקבל תשובה שנשמעת חכמה ולא נכונה זה אחד הדברים הכי מסוכנים.
Speaker A
משם אנחנו מגיעים לבעיה הגדולה ביותר. אין לולאת משוב, פידבק לופ. המערכת לא לומדת מהצלחות או מכישלונות, לא מתקן את עצמה, וכל שינוי דורש נגיעה ידנית בקוד או בפרומפט.
Speaker A
וזה מוביל לתופעה שאנחנו רואים בשטח. דיבאגינג ידני אינסופי. כל פעם שהתשובה לא טובה מתחילים לתקן את ההגדרות, לשנות את הצ'אנקים, לסדר מתדטה. זה פשוט לא נגמר.
Speaker A
סך הכל מה שאנחנו רואים פה בשניורים מסכם את זה היטב: המערכת נעיבית היא מערכת קשיחה, היא לא מודולרית, לא ניתנת לשדרוג ומייצרת תשובות שהם לא עקביות. וזה בדיוק למה צריך לעבור לרג מתקדם כזה שמבין סוגי נתונים שונים, יודע לחפש גם סמנטית
Speaker A
וגם סיקלית, משתמש במתודת החכם ויש בו מנגנוני בקרה עם השוב. בקיצור, רק בסיסי אולי עובד בדמו, בפרודקשן הוא כושל כמעט תמיד, באופן עקרוני תמיד. ולכן אנחנו צריכים טכניקות שהם מתקדמות. כאן אני רוצה לתת לכם רגע מבט מפוכח על האתגרים של שימוש בבדיקות
Speaker A
knowledge bases כמו שהם עד היום. knowledge bases, KBS, מה שבעצם מרכז את המידע, מהנדקס אותו, בדרך כלל דטאבייסים וקטורים, אבל לא רק. הבעיות לא נובעות מהטכנולוגיה אלא מהאופן שבו knowledge base מטפל למסמכים ובשגיאות. נתחיל מהאגרים של processing, התהליך של העיבוד של המסמך
Speaker A
לפני שהוא נכנס למנוע חיפוש. דבר ראשון, generic chunking בדרוק, לדוגמה, חותך את המסמכים לפי גודל קבוע. הדיפולט הוא 300 טוקנים, שהם בערך 220 מילים באנגלית או 140 מילים בעברית, שתיים-שלוש פסקאות קצרות. בקיצור, מעט מאוד תוכן, בערך חצי עמוד ורד,
Speaker A
אולי אפילו פחות. זה אומר שהמערכת לא תמיד, בלשון המטעה, מכבדת גבולות לוגיים, פסקאות, כותרות, משפטים משמעותיים. שהתוצאה בפועל היא חיתוכים באמצע המשפט, רעיונות שמתפצלים וכתאי מידע שמאבדים משמעות.
Speaker A
הבעיה השנייה, limited ranking. גם כשה-edg מוצא תוצאות טובות, הוא לא יודע לדרג אותם על פי לוגיקה עסקית או רלוונטיות. לפעמים התוצאה הראשונה היא פשוט לא הכי טובה. זה פוגע בדיוק של התשובה הסופית.
Speaker A
הבעיה השלישית, no query understanding. המערכת לא מבינה שאלות מורכבות. אין פירוק לשאלות משנה, אין מולטי הופט, ולכן שאלות שחייבות כמה שלבים פשוט נכשלות.
Speaker A
זה היה ה-processing. עכשיו נעבור לחלק של ה-retrieval. זה שלב החיפוש עצמו. הראשון זה search limitations.
Speaker A
חיפוש סמנטי בלבד לפי התאמות וקרבה. אוקיי? ומפספס אתמות מדויקות, מזהים, מראשי תיבות, שמות פנימיים, טבלאות טכניות, מושגים. כל זה לא קיים בחיפוש וקטורי, בחיפוש סמנטי. עכשיו זה מייצר המון false negatives. המידע קיים אבל לא נשלף.
Speaker A
הבעיה השנייה זה קונטקסטוס. כשעובדים...
Speaker A
מסנן לפי סוג מסמך תאריך קטגוריה מחלקה כל מה שיכול להות במט הדטה זה גורם לכך שתוצאות לא רלוונטיות מתערבבות בתוצאות רלוונטיות כששמים את כל זה ביחד זה מסביר למה ארגונים רבים שפשוט חיברו מסמכים לאיזהג מקבלים תשובות לא יציבות.
Speaker A
זו בדיוק הסיבה שאנחנו מדגישים חברים. Advanced rug. כאן אנחנו עוברים 100 בעיות לפתרונות. זה הרגע שב אנחנו לוקחים רג נעיבי כזה שמתקשה פרודקשן ומראים איך להפוך אותו למערכת advance traרג אמיתית שמגיבה טוב, יציבה ומדויקת.
Speaker A
אני מציא כאן חמישה דפוסים שם הגame changנג'רים של bedדroק knowledge basens הדברים שאם מוסיפים אותם איכות התשובה קופצת ברמות דבר ראשון semמנטיק צ'נקing במקום לחתוך מסמך כל x תבים אנחנו חותכים לפי משמעות ישמר על פסקאות על לוגיקה פנימית על מבנה של המסמך תוצאה רלוונטיות
Speaker A
הרבה יותר גבוהה פחות תשובות שמרגישות מבולבלות שתיים מתדata פילטרינ לפני שחושבים בכלל על חיפוש סמנטי מסננים לפי מטדטה תאריך מקור סוג מסמך ישות מחלקה זה מונע הזבל לפני שהוא מגיע לllm והופכת השליפה להרבה יותר מדוייקת ומהירה שלוש hybri retrieval
Speaker A
זה אחד הדברים החשובים באמת צריך גם סמנטי וגם לקסיקלי ככה אנחנו אנחנו תופסים גם מזהים, ראשי תיבות, מספרים וגם שאלות מופשטות יותר. זה הפתרון הכי יציב שיש היום לשאלטות מורכבות. ארבע, רנקינג. אחרי שהבאנו תוצאות, לא חייבים לקבל אותם כמו
Speaker A
שהם. אנחנו מדרגים מחדש לפי רלוונטיות, לפי לוגיקה עסקית או לפי איכות המידע. כך התשובה הראשונה היא באמת התשובה הכי טובה, לא סתם הראשונה שנשלפה.
Speaker A
חמש. Query decosition. שאלטות מורכבות לאכבוד לשאר מורכבות מערכת מתקדמת מפרקת אותן לשאילטות משנה מה שנקרא מולטיופ זה נותן תשובות הרבה יותר מדויקות במיוחד שהשאלה דורשת כמה חלקי ידע היופי הוא שכל אחד מהדפוסים אלה המטפל בקשל אחר של רג נעיבי כשמחברים אותם ביחד
Speaker A
מקבלים מערכת הרבה יותר אמינה הרבה יותר יציבה והרבה יותר שמישהיפרודקשן מתוך החמישיה הזו כשאנחנו עוברים מפרויקט שהוא פי Pcתר אמיתית יש שני פאטרנים שהם לא nice to הם חובה. בלי זה המערכת פשוט לא תעמוד בעומסים ולא תחזיר תשובות יציבות. הראשונה
Speaker A
נקראת נקרא סליחה query decomposition. זה אולי הדבר הכי חשוב שרוב האנשים מפספסים. נתשלים את המערכת. א שאלה מורכבת והמודע צריך להבין בעצמו מה לחפש, איפה לחפש ואיך לפצל את זה. זה לא עובד. בפרודקשן אנחנו שוברים שאלה גדולה לסדרה של תתי שאלות.
Speaker A
מי, מה, איפה, איזה מסמכים, איזה טווח תאריכים. כל תת שאלה מובילה לשאיפה לשליפה מדויקת יותר ואז מחברים הכל בחזרה. התוצאה D הוא גבוה, פחות דמיונות בהרבה יותר שליטה.
Speaker A
השני HBrial. הפטרשני מה שמציא אותכם בעיות שכולנו מכירים קודם מוצר סקיוים מזהים ראשי תיבות שמות שמשתנים החלקים של סמנטיקה לא מצליחה לתפוס לכן אנחנו משלבים שני עולמות הראשון נקראד retrieval מה שנקרא אבדס הוא מבין את המשמעות והשני נקרא leקסical retrieval
Speaker A
יש שם שני מודלים אחד נקרא BM25 והשני RRF אוקיי BM25 זה best match 25 וF זה reciprocal rank fusion אלה החבר'ה מבינים מילים מדויקות זה מה שהם עושים הראשון מבין את המשמעות הם מבינים את המילים והחיבור ביניהם נותן
Speaker A
כיסויים מלא גם משמעות גם מונחים טכניים גם הקשרים וזה מה שהופך רג נעיבי לרג יצור אמיתי למה זה משנה אם נישאן רק על אחד מהם נקבל תשובות חלקיות לפעמים מצחיקות לפעמים מסוכנות אבל כשמשלבים אתר retrieval ואת הquy decomosition, מערכת הרג הופכת להיות
Speaker A
יציבה, מדוייקת ומוכנה לפרודקש. בשקף הזה אני רוצה לעשות סדר באחד הנושאים שהכי מבלבלים היום בעולם הרג. העובדה שיש בעצם שלושה דורות שונים של רג וכל אחד משנה לגמרי את היכולות של המערכת. מתחילים עם רג נעיבי. בוא נתחיל איתו.
Speaker A
זה הדור הראשון, הכי בסיסי, הכי פשוט. שאלה נכנסת, עושים חיפוש המסמכים, מחברים את הטקסט לאלם, מקבלים תשובה בלי שום ניתוח של השאלה, בלי אופטימיזציה, בלי תיקון תוצאות. זה עובד בדמו אבל נשבר מהר מאוד בפרודקשן. אחרי זה מגיע advance
Speaker A
traרג. אתם רואים פה למעלה זה הבחור הזה advance traרג. פה אנחנו רואים כבר שתי שכבות קריטיות שנכנסות לפני ואחרי שלה בחיפוש. פרי רטריבל המלכת מבינה את השאלה משחתבת אותה מרחיבה מושגים מנתבת אותה למסלול הנכון ופה כבר איכות השליפה משתפרת
Speaker A
דרמטית וסטריבל אחרי שהבאנו תוצאות אנחנו מסדרים אותם מחדש עושים רנק עושים סיכום משלבים מקורות שונים זה נותן תשובה הרבה יותר מדויקת ויציבה זה ההבדל בין מחפש מסמך למבין מהמשתמש באמת צריך והדור השלישי תדם טדם מודולר רג מה זה מודול רג פה כבר לא מדובר
Speaker A
בצינור אחד א אלא מערכת של מודולים שאפשר להרכיב ולשלב אה רכיבים כמו search retrive אתם רואים פה reite rank אוקיי fusion mורy כל הדברים האלה מתחברים למודולים שכל מודול כזה הוא יכולת אני יכול לבנות מהם מסלולים שונים לפי הצורך למשל של מסלול שמבוסס על
Speaker A
rרנק אוקיי rite retrive ורנק או מסלול שמבוסס על predict אוקיי שאני יכול לקחת מה שנקרא demonstrate search ופct או מסלול ליטרטיבי פה שואים צד ימין שבעצם מביא מידע שוב ושוב ושוב ולופ מה שנקרא e ran אוקיי הוא כל הזמן מייצר מידע חדש
Speaker A
היופי במודולרי הוא שמכת כבר לא מקובעת והיא הופכת גבישה, ניתנת לשדרוג, מאפשרת לai להתנהג א הרבה יותר כמו מומחה, לפרק בעיות, לשלב כיווני חשיבה, לאבד מידע בכמה שכבות.
Speaker A
אם נעייב רג, מה שאנחנו רואים פה מצד שמאל, אם נעייב רג חד ממדי ואדvenced הוא דו ממדי, אז מודולרar רג כבר פועל בחלל מלא. זה הכיוון שאליו כל התעשייה זזה.
Speaker A
בואו נתמקד בעוד כמה מיטוסים שחוזרים על עצמם שוב ושוב כשארגונים מתחילים לעבוד עם GNI. חשוב לנפץ אותם מוקדם. המידוס הראשון נבחר מודל אחד ונמשיך איתו לנצח. ClודG GPT5 מה שתרצו. במציאות זה מתכון לנדור לוקצאות לא אופטימליות בI אתה חייב נהדות להשוות
Speaker A
לבדוק ביצועים לעבור בין מודלים לפי צורך האג'יליות פה היא יתרון תחרותי לא מותרות המיטוס השני ג'אי עומד בפני עצמו רחוק מאוד מהאמת AI טוב נישען על הבטחה על תשתיות ענן על ניהול הרשאות על מדיניות נתונים כל הדברים הממשעמים שבונים מערכות יציבות.
Speaker A
בלי זה המודל אולי מרשים אבל המערכת לא תעמוד בדרישות פרודקשן. המיטוס השלישי התוצאות יהיו מדויקות אוטומטית זה אולי נכון בדמו אבל לא במערכות אמיתיות צריך שליטה באיכות הנתונים חיפוש טוב פילטרינג לפעמים גם תיקון אנושי המודול לבד א לא יפתור הכל
Speaker A
בצד של הכן מה כן עובדת היכולת לזוז מהר היא כוח כשעושים בנצ'מרק בין מודלים ורואים מי טוב למה מקבלים ערך אמיתי מהיר יותר זול יותר מדויק יותר זה משחק שמתעדקן כל חודש מי שלא זז מפסיד השני זה איכות נתונים וממשל נתונים מה
Speaker A
שנקרא dataגנס אינטגרציה למערכות ארגוניות הרשאה הבטחה טאימות אוקיי בלדם שום מודל לא יתן תשובה שניתן לסמוך עליה ובסוף צריך להגדיר הצלחה למדוד למדוד דיוק למדוד אימפקט ולשפר כל הזמן בלי מדדים קל מאוד להתעב בהשליה היפה של ai במקום מקום במציאות. חמשת המלקודות
Speaker A
הכי נפוצות לפרויקטי GNI. דברים שאנחנו רואים שוב ושוב אצל לקוחות ומה הדרך לצאת מהם? אחד פור data quality איכות נתונים גרועה. זו המלכות מספר אחת.
Speaker A
אם מכניסים למסלול רג מסמכים שבורים טבלאות מרוסקות גרסאות ישנות או PDF שהודפס נסרק ועלה ב-2012 אין הפטרה שהתשובה נראית כמו רעיון גרוע.
Speaker A
Bage in garbage on והפתרון כאן ה הוא לא קסם צריך לנקות את הדטה וכאן חשוב לציין ישם כלים מצוינים שעושים את זה אוטומטית אוקיי יש כלים כמו דוקלינד doקליing הוא מכין בעצם את ה את הפיילים לgeni או unstructed i הוא עושה ETL et ETL על
Speaker A
סטרואידים לכלמות של GN data שמתי לכם לינקים בזוף המצגת אני אצרף אותם אני גם צרף את המצגת להקלטה וגם את הלינקים בנפרד להקלטה כי באמת שווה להכיר את הדברים האלה. גם עושים פסינג המרה נרמול של מסמכים בקיצור הופכים PDF
Speaker A
לידע שהרגע שהרג יודע לעבוד איתו. שתיים inacurate results without feedback. אין feedbaבק אין שיפור.
Speaker A
מערכות רבות מציאות תשובה וזהו. אין מצוב אין מדידה אין למידה. ככה אי אפשר להשתפר.
Speaker A
הפתרון להגדיר מטריקות הצלחה, לאסוף פידבק מהמשתמשים ולשפר באופן רציף את הפרומפטים והצ'אנקינג. שלוש, עלויות יוצאות משליטה. כולנו מכירים את זה. כמה שאלות שאילטות תמימות ואז בם חשבון של אלפי דולרים. מה ההתאוששות? לנתר USAG ולהתחיל למודולים זולים יותר, לאפטם
Speaker A
פרומפטים, לעשות טרינג חכם. פינופס זה לא nice to זה חובה בI בסוגריים לא רק בAI ארבע נתקיים על מודל אחד מודלוק העולם רץ מהר לבחור מודל ולהיתקע עליו זה כמו לקנות אייפון ולהשאר עם iOS 15 זה הכי ישן שהיה
Speaker A
בזמן השיעת המצגת שזה באמצע נובמבר סייר איתו הנצח צר גמישות לכן עובדים עם בדרוק א ברב של אבסטש כלי אורכסטרציה שמאפשרים להחליף מודלים בלי להחליף מערכת בלי בלי להחליף פרומפט, אולי רק להקטם אותו.
Speaker A
וחמש בדרוק qua limמitס מגבלת מכסות. צריכים להגיד את האמת. זו מלכודת שאנשים מגלים רק שזה מאוחר מדי. בדרוק מגבילה בקשות לפי אזור ולפי מודל. דוגמה אנטרפיק clלודס sonונט 3וח דוגמה בפרנקפורט בו סנטרל 1 ההגבלה היא 40 קריאות לדקה. הרבה
Speaker A
מעט. אז תלוי מה אתם עושים לPOC כנראה שזה בסדר אבל מערכות שהם פרודקשן הרבה מקות לדקה כנראה שזה לא מתחיל אפילו לספר את הסיפור אז אם לא מתכננים מראש אסייל יש תקיעות מה ההתאוששות להבין מה הקורות מראש ולתכנן דפלמן בהתם וגם תמיד אפשר לבקש
Speaker A
מאמזון שיגדילו את הקוטות אוקיי לא תמיד זה בלתי מוגבל אבל הם בהחלט יכולים א לעשות טובה ולהגדיל מה המסר פה של השקף הזה. אין כאן שום היסטוריד. רוב אתגרים בגni נפטרים ארכיטקטורה ודטה נכונים בכל מקום שאפשר למקן כמו נקות המידע,
Speaker A
לעשות לו ETL חכם, שווה לעשות את זה ולכן הלינקים בסוף המצגת קיימים. בואו נראה רגע מהbורד ונגע עם משהו שהוא לגמרי פרקטי.
Speaker A
הבחירות הארכיטקטוניות שלנו בWS ובמיוחד בדרוק משפיעות בצורה קיצונית על עלויות ועל ביצועים. הדבר הראשון שאנחנו צריכים לזכור הוא שבai במיוחד בעולם של בדרוק בחירה במודל ספציפי יכולת ההבדל בין מערכת זולה לעיקרה פי 500 כן פי 500 בצד ימין אתם רואים את שלושת היבתי
Speaker A
המרכזיים שיקול ארכיטקטורה איפה להריץ המודלים איזה שירותים משליעים להשתמש די עמוד B knowledge ביסים S3 למדו וכו מה השפעה של latency ודata residency ז להחזיק את המידע קרוב אלינו או באזור גיאוגרפי מסוים כמו בישראל למשל נימבוס זו דרישה קריטית אסור לך מבחינה חוזית להוציא
Speaker A
את המידע החוצה בישראל החלק השני זה אופטימיז אופטימיזציית עלויות להתחיל ממודולים קטנים וזולים כמו nova או מסטרל לפעמים slm אוקיי שמאל language mod לא צריך תמיד lm slm יש לו כמה מיליונים מיליוני פרמטרים יתאים יותר מאשר זה lm ענק
Speaker A
שיש לו מיליארדי פרמטרים ולא תמיד צריך את הגודל הזה לעקוב אחרי טוקן usage לעשות casשינ לכלים כמו רדיס או דין modb זה בעצם של שילטות שחוזרות על עצמם אני יכול פשוט לשלוף מהקש לא' לזרז מאוד הדברים מבחינתc ולשלם הרבה פחות כסף כי מנגנון קש הוא זול
Speaker A
יותר מאשר של הטריט האלה אלים וגם בצ'ינג זאת אומרת במקום לשלוח 50 קריאות למודל שולכים בקשה אחת שמטפלת ב-50 פריטים יחד איפה שאפשר. זאת הדרך לחסוך אלפי דולרים בחודש.
Speaker A
הדבר השלישי זה הטריידופים, פשרות ביצועים. מודולים גדולים נותנים לפעמים איכות מטורפת, אבל הם גם כבדים, איתיים ויקרים יותר. לפעמים מודול קטן עם פרום טוב עובד מהר, מהר יותר ויעיל יותר. ובחלק התחשון. התחתון יש לנו פה טבלה יפה מאוד,
Speaker A
שימו לב, שממחישה כמה זה משמעותי. ברגע שעוברים מנובה, אוקיי, נגיד לקלוד אוopופוס, אנחנו עוברים מx1 לX514 וזה כבר משפיע ישירות על התקציב של הארגון. אתם רואים את נובה מייקרו? נובה מייקרו עולה פה כל כך מעט כסף. שימו לב
Speaker A
איפה נמצאת הנקודה העסרונית. אוקיי ולעומתו כשיכו שאנחנו יורדים למטה במודלים במניים כבדים יותר קלוד 3וח כו פי 27 מסטרל גדול פי 46 קלוד שונט פי 103 וקלוד אופוס פי 514 כאן אני מסביר את שלושתי היסודות שאי אפשר לבנות בלדיהם מערכת היעה ארגונית הפילי
Speaker A
הראשון הוא נושא של clוד ודקיורity זה לא ציסמע בארגון ai מביא גישה למודלים מסמכים רגישים, נתונים משתמשים פה נכנסים עולמות של זרוטראסט, עצפנה בכל אחת מהשכבות מדיניות נתונים ברורה הבסיס הוא להבין מי ניגש למה ומתי הפילר השני freטation
Speaker A
המודול הוא לא רק חכם הוא גם עלול להיות תמים פה אנחנו מגינים עליו מפני prompt inctiontion מפני מידע שגוי או זדוני מפני זליגת מידע זה אומר ולידציות פילטרים וכל מה שמונע מונע ממישהו להשיח את דעת האלה אליהם הפילר השלישי מוניing וגovernance מערכת ה
Speaker A
לא יכולה לרוס על אוטומט היא חייבת בקרה רציפה כדי להישאר מדויקת בטוחה ויציבה זה מתחיל בריטלימיטינ שמונעים עומסי יתר ושימוש לרעה עובר דרך חבר'ה של דבסקופס שמזהים פרצות שאומרים שהמודה לא יקבל לא יפיק מידע לא רצוי הם מסתיים בחלק הכי
Speaker A
חשובן בכל הפעולות הרגישות כשבן אדם עובר על החלטות משמעותיות מאשר מתקן עוצר המרכת הופכת להיות הרבה יותר מינה הרבה יותר אחראית ובעיקר מתאימה לעולם של ארגונים גדולים שקף אחריות ה שקף הזה אומר בואו לא נעשה טעויות יקרות דבר ראשון define clear policies צריך
Speaker A
להחליט מראש איזה החלטות הi מקבל איפה בני אדם עוצרים אותו איפה עובר את הגדר בלי זה מתחילות ההפתעות השני זה מוניטורינג איך יודעים שהמודל שהמודל לא מתחיל להדרדר יכול לשנות דיוק להתות תשובות לפספס צריך דשבורדים ניתור של דריפט ביסעות רצון של
Speaker A
משתמשים השלישי זה handle sensitive data responsibly אי אפשר להפעיל geni על מסמחים רגישים בלי להביא נושא של data residency. מי שרואה מה היכן מאכסן א למי יש גישה בדרוק עוזרת כאן היא לא מאמנת את המודלים על המידה שלנו
Speaker A
והרביעי buildד feedבק loopס בלי לולעת משוב אף מערכת ai לא משתפרת משתמשים צריכים לדווח על טעויות בקלות והמערכת צריכה ללמוד בזה כמעט בזמן אמת ממינימום בואו נדבר על אחד הכלים הכי חזקים אבל גם הכי לא מובנים פרomפ מה שנקרא B expliit and refine אל תגיד
Speaker A
למודל 10 סיכום תגיד לו איזה סוג סיכום למי באיזה טון כמה ארוך דיוק בהנחיות שווה איכות בתשובה ובפעם השנייה וילך לשפר few short examples זה נגזר בעיקרון של few short learning המודל לומד מצוין מדוגמאות תנו לו שתיים שלוש תשובות מעולות פתאום
Speaker A
האיכות קופצת stay agile on models. Prompt עובד מדהים על מודל אחד ופתאום על אחר הוא פשוט גרוע.
Speaker A
לכן לא ננלים, בודקים, משווים, עוברים, מודלים בקלות וdocument what works לכל צוות יש לפנינים שלו, הפרומטים שעובדים פצצה. לכן צריך לטעד אותם, לשתף, לבנות ספריה פנימית. ככה כל הערגול משתפר. בואו נראה פה סיפור לקוח שכל מה שדיברנו עליו מומש פה בצורה יפה.
Speaker A
לקוח שלנו של clודזון שנקרא prodודctט מהולנד החברה שמאוד אהבתי לעבוד איתה הם הגיעו בדיוק מהכאב שכל אחד פה מכיר יש אסטרטגיה אחת על המצגות ויש מציאות אחרת בפיתוח בין שני העולמות האלה יש תהום פרודקטב קמו כדי לגשר על התהום הזאת ולחבר
Speaker A
סוף סוף מה שמנהלים רוצים להשיג לבין מה שהמנדסים בונים בפועל כשנכנסנו פנימה ראינו אתגר מאוד פשוט להסבר וקשה לחיות איתו הידע הארגוני מבוזר מסמכים בכל מקום, סיכומים בזום, טבלאות, החלטות בסלק, אף אחד לא רואה תמונה אחת מסודרת. ואז בנינו להם מנוע ג'אי, שיודע
Speaker A
לקחת את כל הפאזל הזה ולהפוך אותו למאגר יד חי שמתעד בזמן אמת. סמנטיקצ'נקינ כדי לשמור הקשר. מטדת פילטרינ כדי להבין מי הסמה ומתי. בפילדק לופ שמייצר שמדיק את המערכת כל יום. מה התוצאה? אישור קו אמיתי. בין אסטרטגיה לביצוע ההחלטות
Speaker A
מהירות יותר תהיה דוף חכם יותר וצפתי פיתוח שסוף סוף מבינים למה הם עושים מה שהם עושים לא רק מה איך זה קורה מאחורי הקלים לחבר הטכני יותר כל מסמך שנכנס לארגון נוחט ב3 זו נקודת הכניסה משם למדה נכנסת לפעולה היא בודקת מה זה אוזה מצגת
Speaker A
PDF כבד מחליטה איך לפרק אותו בצורה שטובה לai אפשר לחשוב עליו כמו זה אורך תוכן שמכין את המידע לקראת הדיגest לקראת העיכול דינam B שומרת את כל הקונפיגורציות של כל הכוח זאת מערכת שהיא מוליטנ היא מה שנקרא רב לכוחותית כל אחד עם כללים
Speaker A
והגדרות שלו ואז מגיע החלק הכי חשוב bedדroק knowledge bas כאן המידע מקבל עם bדingסוקס והקשרים זה הרגע שבו המידע הופך לידע ש באמת מבין בצד בצד יש לכם למדה וקדוד סליחה clודו ולמדה נוספת שבודקים שהכל תקין תופסים טעויות מזהים מסמכים בעייתיים
Speaker A
מוודאים שהמערכת לא נסמכת על מידע גרוע בסוף im rollולס סוגרים הכל בצורה מובטחת מי שרשאי לראות משהו רואה אותו מי שלא לא וזהו זה לא צנרת זה ההרדבייט של הייי בארגון מנגנון שמכניס מסמכים מפוזרים בצד אחד ומוציא תובנות עסקיות חכמות בצד השני.
Speaker A
זה השקף של צדע לדרך. הדברים שכל מי שבונה מערכות AI חייב לקחת איתו. אחרת הוא ייפול על שטויות שכולנו כבר למדנו בדרך הקשה.
Speaker A
Core patterns אוקיי? יסודות שכל מערכת חייבת. הדבר הכי מפתיע בתעשייה לפעמים לא צריך אלה אליהם בכלל. הרבה בות נפטרות עם חוקים פשוטים.
Speaker A
Regular expression, look up tbles. זה הרבה יותר מהיר. זול. ויציב פי 100. אם כן משתמשים בLM מודדים שני דברים אחד זה כמה זמן לוקח למודל להתחיל לענות מה שנקרא time to first token אוce כמה התנהגות המודל קופצת משאילתא לשאילתא
Speaker A
אלה להם מטבעה מצורים איתיים ולא יציבים ולכן התבונים סביבם א as אוקיי בקשות שהם אסינכרוניות qז שיהיה נוח לעבוד איתם ולא משתפ תפרק כשיש דליי זה ההבדל בין דמו מגניב לבין מוצר שאפשר להישאן עליו השני זה advanced patterns מאיך שעושים דמו
Speaker A
לאיך עושים prodודקש כאן מגיעים המחוקים של מערכות אמיתיות smart retries לא retry עיוור אוטומטי לחזור בלופ על דברים אלא לפי סוג השגיעה השני זה graceful degregation אם או המוס נותנים fallבק הכל מתרסק יכול להיות שאני אעביר למודל אחר. יכול להיות שאני אתן
Speaker A
ליוזר שלי איזשהי הודעה שאומרת שאנחנו בודקים ועושים העיקר לא יתרסק. השלישי זה back pressure. כשיש עומס המערכת מעטה במקום לקרוס. והחלק הנוסף זה מודל routing lmgגי. בעצם שכבה שמחליטה איזה מודל הכי מתאים, מה הכי זול או הכי מהיר או הכי
Speaker A
איכותי. בדרוק למשל נותנת תשתית טובה מאוד להיות lmט מבחינת הבטחה הרשעות ריבועים מודלים אבל אין לה ניתוב חכם זאת הוא לא בלט אין מי שכן עושה את זה יש כלים כמו open routטרפ ke הטק lama אינדקס וכמובן לנציין הרבה
Speaker A
מכירים אתנצן עושים את זה יפה מאוד שם אתם שולטים בפולבקס בניהול עומס וזה מה שהופך מערכת מנחמדה לאי אפשר לעבוד בלדיה כמה מספרים שכל כל ai אנר כדאי מאוד שהוא ידע מה חוקי הפיזיקה של הLM שלושה מספרים פשוטים שמסבירים חצי מהביצועים
Speaker A
time to first token גדל עם גודל הפרomפט פרומפטים ארוכים שווים איתיות הרופט גדל עם אורך התשובה תשובות מפלצתיות עולות כסף מעתות המערכת מודלים גדולים שווה טוב יותר אבל איתי יותר תמיד יש טריידוף אל תנסו לבנות מודל קסים א מודל קסם ה
Speaker A
תבנו מערכת יציבה עם הבנה חזקה לשגיעות ביצועים או מסים וניטוב האלה אליהם יושב בתוך המערכת הוא לא מנהל אותה זו הצידה שלכם לדרך בחיים האמיתיים שלהם ג'ני לפני שאנחנו סוגרים ונפרדים רציתי להשאיר אותכם עם אוסף לינקים שהם באמת שימושיים לא
Speaker A
קישורים למצגת אלא הדברים שאם תעברו עליהם יש סיכוי טוב שתבנו מערכת GNI טובה יותר כבר כבר השבוע בקטגור שלג ורטריriבל ליקדתי את החומרים הכי פרקטיים המדריך של ne 4j לדadvced regג priceless הוא פשוט מדהים והטיעוד של אמזון לגבי metד data
Speaker A
ftering וצקing שני הדברים שהכי משפיעים עליכות תוצ knowledge bases והאחרון בקטגורה זה prompt in gu basicס שמראה לכם איך לקחת את הרג מרמה הבסיסית למתקדמת גם כן אתר שהוא פשוט שווה את משקלו בזהב תראו איזה יופי כמה חומר יש
Speaker A
שם זה לא יאמן תחת מודל valuation שמתי לכם את האתר של ארטל analysis אתר חיצוני third partטי מדהים בחינם הוא עושה בנמרקים עצמאיים על כל המודלים הגדולים זה המקום הכי טוב לראות מי נותן את הול הכי גבוה בעבודה אמיתית מול slms lms להשוות
Speaker A
ביניהם מש יפה ובai enablement הוספתי כמה לינקים הנושא של unstructed IOCLing לנושא של ETL וניקוי והכנה של דataה שני כלים מטריפים קישור למכסוד של בדרוק הקotות שתמיד מפטיע אנשים שזה מה שעוצר להם את הפרודקשן וגם מדריך חשוב על איך צ'אנקינג
Speaker A
באמת עובד מאחורי הקלים ויש גם א משהו קטן שאני שמח לשתף פה ביום שלישי האחרון יהיה לנו פרק חדש בClוד AI והפעם התארח בו גילי נחום מWS זה פרק מיוחד. אנחנו צועלים למוות שעד היום היה קשה לדבר עליהם בכל רם. איך
Speaker A
האמזון רואה את הדור הבא של כל הנשאנטי? איך באמת עובד agent קור מאחורי הקלים, agent sp מתוכנן ל-2025 ו-26 ומה קורה מאחור הכלים של בדרוק. ממש ממש מעניין.
Speaker A
לא, אני לא אגע לכם יותר. זה פרק שאתם באמת רוצים לשמוע. זהו חברים, הגענו לסוף. אם החזקתם מעמד עד כאן מגיע לכם badge של AI Survivors.
Speaker A
ואם למישהו יש עוד שאלות, רעיונות או רצון לראות איך עושים זה מוצר אמיתי, אני פה במייל בטלפון וגם לפעמים בלינקטין בשעות לא אנושיות.
Speaker A
תמשיכו לשחק, לבדוק א לטעות, לנסות שוב. בסוף זה כל הקסם של התחום הזה. תודה רבה לכם, היה כיף גדול. להתראות הפרק הבא
Topics:AIGenAIפרודקשןרגretrieval generationקלאודזוןאבטחת מידעניהול דאטהprompt engineeringשירותי ענן
