נבדק לאחרונה: אפריל 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן AIF-C01 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
בחר פרדיגמת למידה: נתונים מתויגים, נתונים לא מתויגים, או ניסוי וטעייה אינטראקטיבי.
מתויג ← מפוקח. אשכולות/פילוח לא מתויג ← בלתי מפוקח. סוכן לומד לפי תגמול ← חיזוק.
למה: הבחירה מוכתבת על ידי הנתונים הקיימים. RLHF היא למידת חיזוק המונחית על ידי דירוגים אנושיים, המשמשת ליישור LLMs.
התאם מודל שאומן מראש למשימה חדשה קשורה במקום לאמן מאפס.
השתמש ב-transfer learning. כוונן עדין את המודל הקיים על בסיס נתוני התחום החדש.
למה: משתמש מחדש בייצוגים שנלמדו, מקצר את זמן האימון ודרישות הנתונים לעומת בניית מודל מאפס.
בחר מצב SageMaker inference עבור צורת העומס.
עומס יציב עם לייטנסי נמוך ← real-time. תעבורה לא אחידה/לא פעילה ← serverless. מטען גדול (עד 1 GB) או משימה ארוכה (עד שעה) עם קרוב ל-real-time ← asynchronous. בתפזורת לא מקוון ← batch transform.
למה: ל-real-time יש מגבלות מטען/זמן קצוב; async עומד בתור משימות גדולות; batch מיועד לניקוד תקופתי לא מקוון.
מספר צוותי ML צריכים לשתף ולהשתמש מחדש ב-engineered features.
Amazon SageMaker Feature Store כמאגר מרכזי עבור online + offline features.
למה: מונע כפילות של feature engineering ושומר על עקביות train/serve בין צוותים.
בנה מודלי ML ללא קידוד או מומחיות ML (לדוגמה, חיזוי ביקוש לאנליסטים).
Amazon SageMaker Canvas - ממשק no-code ויזואלי לאימון ו-inference.
פרוס מודל יסוד במהירות בתוך VPC.
Amazon SageMaker JumpStart - מודלים מאומנים מראש נפרסים כ-SageMaker endpoints ב-VPC שלך.
למה: JumpStart כולל model artifacts ו-notebooks לפריסה מוגבלת ל-VPC בלחיצה אחת.
אוטומציה של כוונון היפרפרמטרים ובחירת מודל.
Amazon SageMaker Autopilot - בוחן אלגוריתמים ומכוונן היפרפרמטרים באופן אוטומטי.
בחר את מדד ההערכה הנכון עבור מודל סיווג.
נכונות סיווג תמונה/בינארי ← accuracy. פירוט מחלקות ← confusion matrix. מחלקות לא מאוזנות ← F1, precision, recall. בלתי תלוי בסף ← AUC.
למה: Accuracy מטעה בנתונים לא מאוזנים; confusion matrix מראה ספירות TP/FP/TN/FN; F1 מאזן בין precision ל-recall.
עלות פספוס חיובי (false negative) גבוהה בהרבה מ-false positive - לדוגמה, זיהוי הונאה, סריקת מחלות.
בצע אופטימיזציה עבור recall (רגישות). קבל precision נמוך יותר.
למה: Recall = TP / (TP + FN). מקסום שלו ממזער פספוס חיובי במחיר של יותר התראות שווא.
המודל מקבל ציון גבוה על נתוני אימון אך נמוך על נתוני בדיקה/פרודקשן; או שה-accuracy משתפר תחילה ואז יורד ככל שה-epochs גדלים.
Overfitting. הקטן עם יותר נתונים, regularization, early stopping, dropout, או מודל פשוט יותר.
למה: פער גדול בין train ל-test פירושו שהמודל שינן רעש במקום ללמוד דפוסים.
בחר את שירות ה-AI המנוהל עבור משימה חד-תכליתית.
NLP/sentiment/entities ← Comprehend. דיבור לטקסט ← Transcribe. טקסט לדיבור ← Polly. תרגום ← Translate. צ'אטבוט/ממשק קולי ← Lex. תמונה/וידאו ← Rekognition. חילוץ טקסט ממסמך/PDF ← Textract. המלצות ← Personalize. חיזוי ← Forecast.
למה: שירותי AI מנוהלים עולים על מודלים מותאמים אישית כאשר המשימה מוגדרת היטב ונמצאת בקטלוג.
בנה יישום בינה מלאכותית גנרטיבית ב-AWS ללא ניהול תשתית מודל.
Amazon Bedrock - גישה מנוהלת באופן מלא למודלי יסוד (Anthropic Claude, Meta Llama, Amazon Titan, Stability, AI21, Mistral, Cohere) באמצעות API יחיד.
למה: אין הקצאת GPU, אין אירוח מודל; תשלום לפי token. SageMaker JumpStart הוא האלטרנטיבה כאשר אתה זקוק ל-endpoint באירוח עצמי ב-VPC שלך.
הגדר מה הופך מודל ל"מודל יסוד".
מודל גדול שאומן מראש על נתונים מגוונים, לרוב לא מתויגים; ניתן להתאמה למשימות רבות במורד הזרם באמצעות prompting, fine-tuning, או RAG.
הערך כמה קלט נכנס ל-prompt אחד ומה מניע את עלות ה-inference.
Tokens הם יחידות תת-מילה. Context window = מקסימום tokens לבקשה (קלט + פלט). עלות ה-inference פרופורציונלית בקירוב ל-tokens מעובדים.
למה: ספירת tokens, לא ספירת בקשות, מניעה את תמחור Bedrock. אם מסמך ארוך חורג מ-context window, חלק אותו או בחר מודל עם window גדול יותר.
בחר סגנון פלט: דטרמיניסטי לעומת יצירתי.
טמפרטורה נמוכה (כ-0.0-0.3) ← דטרמיניסטי, ניתן לשחזור. טמפרטורה גבוהה (כ-0.7-1.0) ← יצירתי, מגוון. השתמש ב-0 לסיווג או sentiment כדי לקבל תוויות עקביות.
הגבל את מאגר ה-token המועמדים מעבר לטמפרטורה.
Top-K = שקול רק את K ה-tokens הסבירים ביותר. Top-P (nucleus) = שקול tokens עד שההסתברות המצטברת מגיעה ל-P.
למה: Top-P מתאים את גודל קבוצת המועמדים לצורת ההתפלגות; Top-K הוא ברוחב קבוע.
קבל פלט LLM בסגנון, אורך או שפה ספציפיים.
Prompt engineering. הוסף הוראות מפורשות ("הגב בצרפתית, מתחת ל-50 מילים, טון רשמי").
למה: זול ומהיר יותר מ-fine-tuning, אימון מחדש, או שינוי גודל מודל עבור שליטה סגנונית.
שפר את דיוק LLM במשימה ספציפית ללא אימון מחדש.
Few-shot prompting - הטמע 2-5 דוגמאות קלט/פלט מתויגות ב-prompt לפני הקלט החדש.
למה: למידה בתוך ההקשר מאפשרת למודל להתאים דפוסים לדוגמאות ללא עדכוני משקולות.
LLM נותן תשובות שגויות לבעיות הסקה מרובות שלבים.
Chain-of-thought prompting - הנחה את המודל לעבור דרך שלבי הסקה לפני התשובה הסופית ("בואו נחשוב צעד אחר צעד").
LLM מייצר טקסט שנשמע סביר אך שגוי עובדתית או מומצא.
הזיה. הקטן עם RAG (מבוסס על עובדות מאוחזרות), Bedrock Guardrails, טמפרטורה נמוכה יותר, וסקירה אנושית של תפוקות בסיכון גבוה.
הפעל חיפוש סמנטי, אשכולות, או אחזור RAG על פני טקסט או נתונים מולטימודליים.
השתמש במודל embedding (לדוגמה, Titan Embeddings, Cohere Embed) כדי להמיר תוכן לווקטורים צפופים. אחסן ובצע שאילתות ב-vector DB.
למה: Embeddings לוכדים משמעות סמנטית כך שפריטים דומים נוחתים קרוב זה לזה במרחב הווקטורי (cosine / dot-product similarity).
יישום חיפוש מקבל גם טקסט וגם תמונות כקלט.
מודל embedding מולטימודלי (לדוגמה, Titan Multimodal Embeddings) - מקרין טקסט ותמונות לאותו מרחב וקטורי.
בצע אב טיפוס לאפליקציית בינה מלאכותית גנרטיבית במהירות ללא קוד או הגדרת חשבון AWS.
PartyRock (Amazon Bedrock Playground) - בונה אפליקציות no-code מבוסס דפדפן.
בחר מודל תמחור Bedrock.
עומס משתנה / בלתי צפוי ← לפי דרישה (לכל token). נפח גבוה קבוע או תפוקה מובטחת ← Provisioned Throughput. מודלים מותאמים אישית (fine-tuned) ← חייבים להשתמש ב-Provisioned Throughput.
למה: לפי דרישה אין התחייבות; Provisioned Throughput קונה קיבולת ייעודית ביחידות מודל.
בחר את ההתאמה האישית הזולה ביותר שמשיגה את האיכות הדרושה לך.
נסה בסדר זה: (1) prompt engineering, (2) RAG עם בסיס ידע, (3) fine-tuning, (4) continued pre-training.
למה: מאמץ ועלות גדלים בכל שלב. עצור בזה הראשון שעומד ברף.
העשיר מודל יסוד עם נתוני חברה פרטיים (PDFs, מסמכים, תוכן S3) ללא fine-tuning.
צור Amazon Bedrock Knowledge Base. Bedrock מטפל בהכנסה, חלוקה לגושים (chunking), הטמעה (embedding), ואחזור (RAG) בזמן ה-inference.
למה: זול ומהיר יותר לעדכון מ-fine-tuning. שינויים בנתוני מקור ← סנכרן מחדש את ה-KB; אין צורך באימון מחדש.
נתונים משתנים לעיתים קרובות (מלאי, תמחור, חדשות) והמודל חייב לשקף מצב עדכני.
RAG עם בסיס ידע. הימנע מ-fine-tuning - מחזורי אימון מחדש לא יכולים לעמוד בקצב.
למה: RAG מפריד את המודל מהנתונים; ה-KB מתעדכן באופן עצמאי מהמודל.
כוונן עדין מודל יסוד עם דוגמאות מתויגות למשימה ספציפית.
ספק זוגות prompt-completion (הוראה-תגובה). פורמט JSONL הוא סטנדרטי.
למה: Instruction fine-tuning מלמד את המודל למפות כניסות משתמש לתפוקות רצויות במשימת היעד.
למד מודל יסוד אוצר מילים מיוחד (רפואי, משפטי, מדעי) באמצעות הרבה טקסט תחום לא מתויג.
Continued pre-training על קורפוס התחום הלא מתויג.
למה: Continued pre-training מעדכן את הבנת המודל לגבי אוצר מילים ומושגים; instruction fine-tuning מלמד התנהגות משימה. מטרה שונה, צורת נתונים שונה.
תהליך עבודה מרובה שלבים המשלב הסקת LLM עם קריאות ל-APIs חיצוניים, מסדי נתונים, או שירותי AWS.
Amazon Bedrock Agents - מתאם הסקת LLM, הפעלת כלי/API, וסינתזת תוצאות בסביבת ריצה מנוהלת אחת.
למה: Agents מתכננים צעדים, קוראים לכלים, ומחברים תוצאות לתגובה סופית מבלי שתכתוב את לולאת התיאום.
בחר מסד נתונים וקטורי עבור embeddings.
RAG מנוהל ← Bedrock Knowledge Bases (מטפל באחסון וקטורי באופן אוטומטי). DB וקטורי מותאם אישית ← OpenSearch Service (k-NN), Aurora PostgreSQL עם pgvector, Neptune Analytics, או RDS for PostgreSQL עם pgvector.
למה: OpenSearch הוא ברירת המחדל עבור k-NN בקנה מידה גדול; pgvector משתמש מחדש ב-DB יחסי קיים.
פרוס מודל שעבר fine-tuning מ-Bedrock להגשה בפרודקשן.
רכוש Provisioned Throughput עבור מודל Bedrock המותאם אישית. לא ניתן להפעיל מודלים מותאמים אישית באמצעות תמחור לפי דרישה.
למה: קיבולת מודל מותאם אישית ייעודית, מחויבת ביחידות מודל, ונדרשת להפעלה.
הערך או הפחת את עלות ה-inference של Bedrock.
עלות ≈ tokens מעובדים × תעריף לכל token. הפחת על ידי קיצור prompts, קיצוץ דוגמאות few-shot, בחירת מודלים קטנים יותר, או שימוש ב-prompt caching היכן שנתמך.
צור נתונים מתויגים בדיוק גבוה עם סקירת human-in-the-loop (לדוגמה, תמונות מיוחדות, רשומות רפואיות).
Amazon SageMaker Ground Truth Plus - כוח עבודה מנוהל ל-HITL labeling.
למה: עבור ביקורת תקופתית של חיזוי מודל בעל ביטחון נמוך, שלב עם Amazon A2I (Augmented AI).
זיהוי דיבור מפרש לא נכון מונחים ספציפיים לתחום (רפואיים, משפטיים, שמות מותגים).
Amazon Transcribe עם מודל שפה מותאם אישית או אוצר מילים מותאם אישית שאומן על טקסט תחום.
המודל מתפקד היטב באימון אך גרוע בפרודקשן (overfit) - הגדל את הכללה ללא שינוי ארכיטקטורה.
הגדל את הנפח והגיוון של נתוני האימון. אל תצמצם נתונים או רק הוסף היפרפרמטרים.
למה: נתונים מייצגים יותר הם התיקון בעל ההשפעה הגדולה ביותר; regularization ו-early stopping עוזרים, אך הנתונים הם הדומיננטיים.
הערך את איכות הפלט הגנרטיבי.
איכות תרגום ← BLEU. איכות סיכום ← ROUGE. דמיון סמנטי למקור ← BERTScore. העדפה סגנונית ← הערכה אנושית עם ערכות prompt מותאמות אישית.
בחר מודל יסוד של Bedrock עבור מקרה שימוש שבו סגנון הפלט חשוב.
בצע הערכה אנושית על מערך נתוני prompt מותאם אישית בין המודלים המועמדים. אל תסתמך רק על טבלאות מובילים ציבוריות או מדדי לייטנסי.
למה: התאמת סגנון/טון היא סובייקטיבית; benchmark-ים מפספסים זאת.
צור תרשימים ולוחות מחוונים משאלות בשפה טבעית על נתונים עסקיים.
Amazon Q ב-QuickSight - BI בשפה טבעית על גבי מערכי נתונים של QuickSight.
זהה הטיה בנתוני אימון או בחיזוי מודל; הפק דוחות הסברתיות.
Amazon SageMaker Clarify. מריץ מדדי הטיה על פני מאפיינים מוגנים לפני ואחרי אימון, בתוספת ייחוס תכונות מבוסס SHAP.
למה: נדרש בתחומים מפוקחים (הלוואות, גיוס, בריאות) שבהם עליך להדגים הגינות ויכולת הסבר.
המודל מתפקד גרוע יותר עבור דמוגרפיה, קבוצה אתנית, או אזור גאוגרפי מסוים (לדוגמה, מסמן קבוצות מסוימות באופן לא פרופורציונלי).
הטיית דגימה. איזון מחדש של מערך הנתונים: הרחבת נתונים עבור מחלקות לא מיוצגות מספיק; הבטחת מקורות מגוונים ומייצגים.
למה: נתוני אימון שמייצגים באופן חסר קבוצות מייצרים מודלים שמשרתים אותן באופן חסר. תקן בשכבת הנתונים, לא בשכבת המודל.
תעד את ייעודו של מודל, נתוני אימון, ביצועים, מגבלות וסיכונים למטרות ממשל וביקורת.
Amazon SageMaker Model Cards - תיעוד מובנה ובעל גרסאות המקושר למודל.
הגבל נושאי LLM, סנן תוכן מזיק, הסתר PII, או חסום דפוסי prompt injection.
Amazon Bedrock Guardrails. הגדר נושאים אסורים, מסנני תוכן (שנאה, אלימות, מין, עלבונות), מסנני מילים, מסנני מידע רגיש, ובדיקות הטמעה קונטקסטואליות.
למה: מיושם גם על קלטים וגם על פלטים; עובד בכל מודל Bedrock ובמודלים המותאמים אישית שלך.
קבע את חלקה של החברה באחריות האבטחה עבור פריסת בינה מלאכותית גנרטיבית.
מטריצת היקף האבטחה של AWS Generative AI. היקף 1 (אפליקציית צרכן, אחריות נמוכה ביותר) ← היקף 5 (מודל שאומן עצמאית, אחריות גבוהה ביותר).
למה: בנייה ואימון מודל מאפס על נתונים פרטיים מטילים אחריות אבטחה מקסימלית על החברה.
בעלי עניין או רגולטורים דורשים הסבר כיצד המודל מגיע לחיזויים שלו.
השתמש במודלים ניתנים לפענוח כאשר ניתן (עצי החלטה, רגרסיה לינארית/לוגיסטית). עבור מודלים מורכבים, השתמש ב-Partial Dependence Plots, SHAP feature importance באמצעות SageMaker Clarify, או SageMaker Model Cards.
למה: PDPs מראים את ההשפעה השולית של כל feature; SHAP מייחס תרומה לכל חיזוי; model cards לוכדים את הסיפור המלא לביקורת.
פלט בינה מלאכותית גנרטיבית עשוי לשכפל חומר המוגן בזכויות יוצרים או להימסר כעבודה שנכתבה על ידי אדם.
סיכון לגניבת עין / הפרת קניין רוחני. הקטן עם דרישות ציטוט, מעקב אחר מקוריות תוכן, סימן מים (watermarking) היכן שנתמך, סקירה אנושית, ומדיניות גילוי תוכן AI ברורה.
יישום מודל יסוד חייב לשמור prompts ותגובות ברשת AWS - ללא יציאה לאינטרנט הציבורי.
Bedrock עם VPC endpoints (PrivateLink) עבור ה-runtime API. חסום endpoints ציבוריים של Bedrock באמצעות SCPs ברמת הארגון.
למה: PrivateLink שומר על בקשות פרטיות ומונע יציאת נתונים מה-VPC; SCPs אוכפים את הכלל בכל החשבונות.
מספר צוותים קוראים ל-Bedrock מול נתוני S3 משותפים; כל צוות חייב לגשת רק לנתוני הלקוח שלו.
צור IAM service role אחד לכל צוות שמעניק ל-Bedrock גישה רק ל-S3 prefix או מפתח KMS של אותו צוות.
למה: IAM service roles מותאמים אישית אוכפים את עקרון הפחות הרשאות ברמת המשאב. אל תתן ל-Bedrock גישה רחבה ל-S3 ותסתמך על סינון בשכבת האפליקציה.
Bedrock נכשל בקריאת נתוני S3 המוצפנים באמצעות SSE-KMS.
הענק ל-Bedrock service role הרשאת `kms:Decrypt` על ה-CMK הרלוונטי ו-`s3:GetObject` על ה-bucket/prefix.
למה: Bedrock משתמש ב-service role שלו כדי לקרוא את הנתונים; ה-role זקוק להרשאות S3 וגם KMS.
לכוד פעילות Bedrock לניטור, דיבוג, ביקורת, וציות.
שני שירותים משלימים. CloudTrail = מי/מתי/מאין עבור כל קריאת API (זהות, חותמת זמן, IP מקור). Bedrock model invocation logging = מטען ה-prompt/response בפועל, הנכתב ל-CloudWatch Logs או S3. הפעל את שניהם.
למה: CloudTrail לוכד מטא נתונים בלבד; invocation logging לוכד תוכן. ציות לעיתים קרובות דורש את שניהם.
מבקר דורש דוחות ציות של AWS (SOC, ISO, PCI, HIPAA) עבור עומס עבודת ה-AI.
AWS Artifact - פורטל שירות עצמי לדוחות והסכמי ציות של AWS לפי דרישה.
למה: AWS Audit Manager מבקר באופן רציף את השימוש שלך; AWS Artifact מספק את האישורים של AWS עצמה.
גלה וסווג PII או נתונים רגישים אחרים המאוחסנים ב-S3 (מאגרי אימון, יומני מודל).
Amazon Macie - גילוי נתונים רגישים מבוסס ML עבור S3.
למה: השתמש ב-Macie כדי למצוא נתונים הדורשים מיסוך, מחיקה או הצפנת KMS לפני שהם מגיעים למודל או לפלטים שלו.
קלט משתמש זדוני מנסה לעקוף prompt מערכת, להוציא נתונים, או להפעיל פעולות בלתי רצויות.
הגנה מעמיקה: Bedrock Guardrails לסינון תוכן, תבניות prompt המזהות/מתעלמות מדפוסי עקיפה, מגבלות אורך קלט, אימות פלט, והרשאות כלים בפחות הרשאות (least-privilege) עבור agents.
למה: אף אמצעי הקלה בודד אינו מספיק; שלב סינון קלט, סינון פלט, ומגבלות יכולת.
מודל מותאם אישית אומן על נתונים חסויים שאסור שיזלגו לתשובות.
מחק את המודל, נקה את הרשומות החסויות ממערך האימון, ואמן מחדש. סינון פלט אינו מספיק.
למה: ידע מוטמע במשקולות המודל לא ניתן למיסוך אמין בזמן ה-inference; רק אימון מחדש ללא נתונים אלו מסיר אותו.
החלט מה AWS מאבטחת לעומת מה הלקוח מאבטח עבור עומס עבודה של AI.
מודל האחריות המשותפת של AWS: AWS = אבטחת הענן (חומרה, hypervisor, אזורים). לקוח = אבטחה בתוך הענן (נתונים, IAM, מפתחות KMS, רשת, תצורת אפליקציה).