מודל לאישור הלוואות אסור שיקפח אנשים על בסיס מגדר או מוצא אתני.
החל את עקרון ה-Responsible AI של הוגנות: הערך וצמצם הטיה על פני קבוצות דמוגרפיות.
למה: הוגנות מכוונת ליחס שוויוני; אל תבלבל אותה עם מהימנות (תוצאות עקביות) או פרטיות (הגנת נתונים).
נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן AI-901 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
מודל לאישור הלוואות אסור שיקפח אנשים על בסיס מגדר או מוצא אתני.
החל את עקרון ה-Responsible AI של הוגנות: הערך וצמצם הטיה על פני קבוצות דמוגרפיות.
למה: הוגנות מכוונת ליחס שוויוני; אל תבלבל אותה עם מהימנות (תוצאות עקביות) או פרטיות (הגנת נתונים).
מודל נהיגה אוטונומי חייב להתנהג בעקביות ולהיכשל בבטחה בתנאים בלתי צפויים.
החל מהימנות ובטיחות: בדיקות קפדניות, ניטור ומעקות בטיחות למקרי קצה.
למה: מהימנות ובטיחות עוסקים בהתנהגות עקבית ומונעת נזקים בתנאי אי-ודאות, לא במידע על מי הנתונים.
אפליקציית בריאות מעבדת נתונים אישיים וחייבת להגן עליהם מפני חשיפה או שימוש לרעה.
החל פרטיות ואבטחה: הגן על נתונים אישיים, שלוט בגישה וכבד הסכמה.
למה: עיקרון זה מכסה סודיות והגנה על נתונים; הוגנות והכלה עוסקות במי שהמערכת משרתת.
פתרון צריך להעצים ולערב אנשים ללא קשר ליכולת או רקע.
החל הכלה: תכנן כך שכולם ירוויחו, כולל אנשים עם מוגבלויות.
למה: הכלה עוסקת בנגישות רחבה ובהגעה לקהל רחב; הוגנות עוסקת ספציפית בתוצאות ללא הטיה.
משתמשים חייבים להבין כיצד מערכת AI מגיעה להחלטותיה ומה מגבלותיה.
החל שקיפות: הסבר כיצד המערכת עובדת, את מטרתה, יכולותיה ומגבלותיה.
למה: שקיפות הופכת את המערכת למובנת; אחריות עוסקת במי שאחראי עליה.
נדרשת בעלות ומשילות ברורים כדי שמישהו ייתן דין וחשבון על התנהגותה של מערכת AI.
החל אחריות: אנשים מתכננים, בונים ומפעילים במסגרת משילות ונשארים אחראים.
למה: אחריות מטילה אחריות אנושית; שקיפות רק מסבירה את המערכת, היא אינה מטילה בעלות.
הסבר כיצד מודל generative AI מייצר פסקה קוהרנטית מפרומפט.
מודל שפה גדול מנבא את הטוקן הבא שוב ושוב באמצעות דפוסים שנלמדו מטקסט אימון עצום.
למה: מודלים גנרטיביים מייצרים תוכן חדש באמצעות ניבוי טוקנים הסתברותי; הם אינם מאחזרים תשובות מאוחסנות מילולית.
בחר מודל: אחד זקוק לצ'אט זול בנפח גבוה, אחר זקוק להסקת מסקנות מורכבת מרובת שלבים.
התאם את המודל למשימה – מודל קטן/מהיר יותר לצ'אט שגרתי, מודל הסקה גדול יותר למשימות קשות.
למה: גדול יותר זה לא תמיד טוב יותר; יכולת, עלות וחביון הם שיקולים שיש להתפשר עליהם, אז בחר לפי צורך העבודה.
החלט כיצד לצרוך מודל: נקודת קצה סטנדרטית מנוהלת מול קיבולת ייעודית.
השתמש בפריסה סטנדרטית (תשלום לפי שימוש) לעומס משתנה, או בתפוקה מוקצית לביצועים יציבים, בעלי נפח גבוה וצפויים.
למה: קיבולת מוקצית שומרת חביון עקבי; חיוב סטנדרטי לפי טוקן והוא הפשוט ביותר להתחלה.
הפלט חוזר על עצמו מדי; אתה רוצה תגובות יצירתיות ומגוונות יותר.
העלה את פרמטר ה-temperature; הורד אותו לכיוון 0 עבור פלט דטרמיניסטי וממוקד.
למה: Temperature שולט על אקראיות בחירת הטוקנים; גבוה = יצירתי, נמוך = עקבי.
תגובות נקטעות באמצע משפט, או שאתה צריך להגביל את אורך ועלות הפלט.
כוונן את פרמטר ה-max tokens (אורך השלמה מקסימלי) כדי לקבוע את תקרת התגובה.
למה: max tokens מגביל את אורך הפלט; הוא אינו משנה יצירתיות — זוהי temperature או top-p.
אתה רוצה להגביל את בחירות הטוקנים לקבוצה הסבירה ביותר ללא temperature קשיח.
השתמש ב-top-p (דגימת גרעין) כדי להגביל את הדגימה לקבוצה הקטנה ביותר של טוקנים שהסתברויותיהם מסתכמות ל-p.
למה: top-p מצמצם את מאגר המועמדים לפי מסת הסתברות; כוונן אותו או את ה-temperature, ובדרך כלל לא את שניהם באגרסיביות.
עומס עבודה חייב לנסח תוכן שיווקי וסיכומים מפרומפטים.
זהו עומס עבודה של generative AI — יצירת תוכן מהוראות בשפה טבעית.
למה: עומסי עבודה גנרטיביים מייצרים תוכן חדש; ניתוח טקסט רק מחלץ תובנות מטקסט קיים.
מערכת חייבת לתכנן צעדים, לקרוא ל-tools, ולפעול לעבר יעד עם פיקוח מינימלי.
זהו עומס עבודה של agentic AI — agent המונע על ידי LLM שמסיק מסקנות, משתמש ב-tools ונוקט בפעולות.
למה: Agentic מוסיף אוטונומיה ושימוש ב-tools בנוסף ליצירה; generative AI פשוט מחזיר תוכן.
עומס עבודה כורה ביקורות לקוחות עבור סנטימנט, ביטויים מרכזיים, ויישויות בעלות שם.
זהו עומס עבודה של ניתוח טקסט (NLP).
למה: ניתוח טקסט מפרש טקסט קיים; הוא אינו מייצר פרוזה חדשה כמו עומס עבודה גנרטיבי.
עומס עבודה חייב לתמלל שיחות ולקרוא תגובות בקול רם.
זהו עומס עבודה של speech — זיהוי דיבור לטקסט וסינתזת טקסט לדיבור.
למה: Speech מכסה אודיו פנימה/החוצה; computer vision מטפל בתמונות, לא באודיו.
עומס עבודה חייב לזהות אובייקטים ולקרוא טקסט מתצלומים.
זהו עומס עבודה של computer vision — סיווג תמונות, זיהוי אובייקטים ו-OCR.
למה: Computer vision מפרש תמונות; חילוץ מידע ממסמכים הוא משימה קשורה אך נפרדת.
עומס עבודה חייב לשלוף שדות כמו תאריכים, סכומים וספקים מחשבוניות סרוקות.
זהו עומס עבודה של חילוץ מידע / נתונים (הבנת מסמכים).
למה: חילוץ שולף שדות מובנים ממסמכים; OCR גנרי מחזיר רק טקסט גולמי, לא שדות מתויגים.
אתה צריך את הנושאים העיקריים מבלוק טקסט מבלי לקרוא את כולו.
השתמש בחילוץ ביטויי מפתח (keywords) כדי להציג את המונחים החשובים ביותר.
למה: חילוץ ביטויי מפתח מפרט מונחים בולטים; זיהוי ישויות במקום זאת מסווג דברים בעלי שם כמו אנשים או מקומות.
אתה חייב לזהות אנשים, ארגונים, מיקומים ותאריכים המוזכרים בטקסט.
השתמש בזיהוי ישויות בעלות שם (entity detection) כדי לסווג ישויות אלה.
למה: זיהוי ישויות מתייג דברים בעלי שם; ניתוח סנטימנט במקום זאת מדרג את הטון הרגשי.
אתה רוצה לדעת אם ביקורות הן חיוביות, שליליות או ניטרליות.
השתמש בניתוח סנטימנט כדי לדרג את הדעה המובעת בטקסט.
למה: סנטימנט מודד טון; סיכום מקצר תוכן, הוא אינו שופט קוטביות.
אתה צריך תקציר קצר של דוח ארוך.
השתמש בסיכום טקסט (extractive או abstractive) כדי לדחוס את המסמך.
למה: סיכום מקצר תוך שמירה על משמעות; חילוץ ביטויי מפתח רק מפרט מונחים, לא סיכום קריא.
הבחן בין המרת אודיו לטקסט לבין המרת טקסט לאודיו.
זיהוי דיבור (speech-to-text) מתמלל אודיו; סינתזת דיבור (text-to-speech) מייצרת אודיו מדובר.
למה: זיהוי הוא אודיו קלט→טקסט; סינתזה היא ההפך — אל תחליף בין שני הכיוונים.
אתה צריך מקום יחיד כדי לגלות מודלים, לפרוס אותם ולבנות אפליקציות AI ב-Azure.
השתמש ב-Microsoft Foundry portal — הוא מארח את קטלוג המודלים, הפריסות, ה-playground וכלי ה-agent.
למה: Foundry הוא המרכז המאוחד; שירותי Azure AI בודדים קיימים אך Foundry הוא המקום בו אתה מרכיב ופורס פתרונות.
אתה רוצה שהמודל תמיד יענה כ-support agent מנומס ללא קשר לשאלה שנשאלה.
הגדר התנהגות ופרסונה ב-system prompt; הכנס את השאלה הספציפית ל-user prompt.
למה: ה-system prompt מגדיר התנהגות וכללים כלליים; ה-user prompt הוא הבקשה עבור כל תור.
בחרת מודל בקטלוג ואתה צריך שהוא יהיה ניתן לקריאה מאפליקציה.
צור פריסה עבור המודל ב-Foundry portal, מה שנותן נקודת קצה ומפתח.
למה: מודל בקטלוג אינו שמיש עד שהוא פרוס; הפריסה חושפת את נקודת הקצה הניתנת לקריאה.
אתה רוצה לבדוק פרומפטים ולכוונן את ה-temperature לפני כתיבת קוד כלשהו.
השתמש ב-chat playground ב-Foundry portal כדי לתקשר עם המודל הפרוס ולהתאים פרמטרים.
למה: ה-playground מאפשר לך לבצע איטרציות על פרומפטים והגדרות באופן אינטראקטיבי; אין צורך ב-SDK כדי להתנסות.
אתה צריך לקרוא למודל הצ'אט הפרוס מקוד יישום.
השתמש ב-Foundry (Azure AI) SDK כדי ליצור chat client ששולח הודעות לנקודת הקצה של הפריסה.
למה: ה-SDK עוטף את נקודת הקצה ב-client מטיפוס מוגדר; אתה מעביר הודעות מערכת ומשתמש וקורא את ההשלמה.
האפליקציה שלך חייבת לאמת את עצמה למודל הפרוס.
השתמש בכתובת ה-URL של נקודת הקצה של הפריסה עם מפתח API או פרטי כניסה של Microsoft Entra ID (Azure AD).
למה: אימות מבוסס מפתח הוא הפשוט ביותר; Entra ID מאובטח יותר ונמנע מהטמעת סודות בקוד.
אתה רוצה עוזר AI שמבצע הוראות ומשתמש ב-tools, בנוי ללא הרבה קוד.
צור agent יחיד ב-Foundry portal — הגדר את הוראותיו, המודל וה-tools שלו (ה-Agent Service).
למה: בונה ה-agent בפורטל מגדיר התנהגות ו-tools באופן דקלרטיבי; אינך כותב ידנית את לולאת התזמור.
ה-agent שלך צריך תמיד לצטט מקורות ולסרב לבקשות שאינן קשורות לנושא.
קודד כללים אלה בהוראות ה-agent (ההנחיות ברמת המערכת שלו).
למה: הוראות agent מנחות התנהגות עקבית לאורך תורות, בדומה ל-system prompt עבור מודל צ'אט פשוט.
ה-agent שלך חייב לענות ממסמכי החברה שלך, לא רק מנתוני האימון שלו.
תן ל-agent כלי ידע/grounding (לדוגמה, חיפוש קבצים או Azure AI Search) כדי שיאחזר את הנתונים שלך.
למה: Grounding/RAG מספק הקשר עדכני ופרטי בזמן שאילתה; בלעדיו המודל יכול להזות או להשתמש בידע מיושן.
אתה צריך אפליקציה מותאמת אישית כדי להניע agent של Foundry באופן תכנותי.
בנה agent client app עם ה-Foundry SDK — צור thread, הוסף הודעות, הפעל את ה-agent, קרא תגובות.
למה: ה-SDK חושף threads, runs והודעות כך שהאפליקציה שלך יכולה לשלב את ה-agent בכל זרימת עבודה.
אתה חייב לבנות אפליקציה שמחלצת סנטימנט וישויות מטקסט נכנס.
השתמש ב-Azure AI Language (text analysis) דרך ה-SDK או REST, הנגיש דרך Foundry, וקרא לתכונות sentiment ו-NER.
למה: עבור משימות NLP קלאסיות, שירות ה-Language בנוי למטרה זו וזול יותר מאשר שימוש ב-LLM כללי.
משתמש רוצה לשאול שאלה בקול ושהמודל הפרוס יענה עליה.
שלח את האודיו למודל multimodal שמקבל קלט דיבור, או תמלל תחילה ולאחר מכן הפנה את המודל.
למה: מודלים multimodal יכולים לקבל אודיו ישירות; אחרת השתמש ב-speech-to-text כדי להזין מודל טקסט.
האפליקציה שלך זקוקה לתמלול באיכות גבוהה ולפלט מדובר טבעי.
השתמש ב-Azure AI Speech בתוך Foundry Tools עבור speech-to-text ו-text-to-speech.
למה: שירות ה-Speech מציע זיהוי מכוונן וקולות נוירוניים דמויי חיים, מעבר למה שמודל צ'אט לבדו מספק.
אתה צריך שהאפליקציה תקרא תגובות בקול רם בקול שנשמע טבעי.
השתמש ב-Azure AI Speech text-to-speech עם קול נוירוני; שלוט בפרוזודיה באמצעות SSML אם נדרש.
למה: קולות נוירוניים נשמעים טבעיים; SSML מאפשר לך לכוונן קצב, גובה צליל והגייה.
אפליקציה חייבת לתאר מה קורה בתמונה שסופקה על ידי המשתמש ולענות על שאלות לגביה.
שלח את התמונה למודל multimodal ב-Foundry והפנה אותו עם השאלה.
למה: מודלי LLM multimodal מסיקים מסקנות על תוכן תמונה; שירות ה-Vision הקלאסי מחזיר רק תגים וכותרות קבועים.
אפליקציה חייבת לייצר תמונות מתיאורי טקסט לפי דרישה.
פרוס מודל text-to-image (לדוגמה, מודל DALL-E / image generation) ב-Foundry וקרא לו מהאפליקציה שלך.
למה: מודלי Image generation יוצרים חזותיים מפרומפטים; מודל vision רק מנתח תמונות קיימות.
אתה צריך אפליקציה שמסווגת תמונות וקוראת מהן טקסט מודפס.
בנה אפליקציית vision באמצעות Azure AI Vision (image analysis ו-OCR) הנגישה דרך Foundry.
למה: Azure AI Vision מספק ניתוח תמונות ו-OCR מוכנים; אינך צריך לאמן מודל למשימות נפוצות.
אפליקציה חייבת לחלץ טקסט מודפס ובכתב יד מדפים סרוקים.
השתמש ביכולת ה-OCR (Read) של Azure AI Vision כדי להחזיר את הטקסט המוכר ומיקומו.
למה: OCR מחזיר טקסט גולמי עם קואורדינטות; חילוץ שדות מובנים דורש במקום זאת Content Understanding.
אתה חייב לחלץ שדות מובנים (סכומים, תאריכים, פריטי שורה) מחשבוניות וטפסים.
השתמש ב-Azure AI Content Understanding ב-Foundry Tools כדי לחלץ נתונים מובנים ממסמכים וטפסים.
למה: Content Understanding שולף שדות מתויגים; OCR פשוט מחזיר רק טקסט לא מובנה.
אתה צריך תיאורים מובנים ומטא נתונים שחולצו מקבוצת תמונות.
השתמש ב-Azure AI Content Understanding כדי לנתח תמונות ולהחזיר פלט מובנה.
למה: Content Understanding מייצר תוצאות מובנות עקביות על פני סוגי תוכן, מעבר לכותרת טקסט חופשי.
אתה חייב להפוך הקלטות שיחות לסיכומים מובנים עם נקודות נתונים מרכזיות.
השתמש ב-Azure AI Content Understanding על האודיו כדי לתמלל ולחלץ שדות מובנים.
למה: Content Understanding משלב תמלול עם חילוץ; Speech לבדו מספק רק את התמלול.
אתה צריך סצנות, נושאים ושדות מפתח שנדלו מסרטוני הדרכה.
השתמש ב-Azure AI Content Understanding עבור וידאו כדי לחלץ תובנות מובנות על פני מודאליות.
למה: הוא מנתח זרמי אודיו ווידאו יחד כדי לייצר פלט מובנה, לא רק תמלול.
אתה חייב להוסיף את ידע ה-FAQ הפרטי של החברה שלך לתשובות המודל, במינימום מאמץ.
בסס את המודל באמצעות retrieval (RAG) על המסמכים שלך במקום fine-tuning.
למה: RAG מזריק נתונים עדכניים בזמן שאילתה והוא פשוט/זול יותר; fine-tuning משנה התנהגות, לא רעננות ידע.
אתה חייב לחסום פלטי טקסט ותמונה מזיקים או לא בטוחים ממודל פרוס.
אפשר את מסנני Azure AI Content Safety על הפריסה כדי לזהות ולחסום תוכן מזיק.
למה: Content Safety אוכף מעקות בטיחות של responsible-AI בזמן ריצה; מודל הבסיס לבדו אינו מובטח בטוח.
לאחר הפריסה, אתה צריך למדוד את איכות התגובה ולצפות לסטייה.
השתמש בכלי הערכה וניטור של Foundry כדי לדרג פלטים ולעקוב אחר מדדים לאורך זמן.
למה: הערכה מכמתת איכות (groundedness, רלוונטיות); ניטור תופס רגרסיות בייצור.
אתה צריך לארגן מודלים, agents וחיבורים עבור אפליקציה אחת.
צור Foundry project, המקובץ פריסות, משאבים מחוברים ו-tools עבור פתרון זה.
למה: פרויקט הוא גבול סביבת העבודה; חיבורים מקשרים משאבים חיצוניים כמו Azure AI Search או אחסון.