נבדק לאחרונה: יוני 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן C1000-185 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
ארגון זקוק למודל שמקיים הנחיות עם רישוי מתירני ושיפוי.
בחר מודל Granite instruct של IBM מקטלוג watsonx.ai במקום מודל צד שלישי מתארח.
למה: מודלי Granite נבנו על ידי IBM, מנוהלים על ידה ונושאים שיפוי קניין רוחני של IBM - הבחירה הבטוחה המוגדרת כברירת מחדל עבור עומסי עבודה מפוקחים.
בחירה בין גרסה מכווננת לצ'אט לגרסה מכווננת להנחיות עבור משימת חילוץ יחידה.
השתמש בגרסת instruct עם prompt מנחה ברור; שמור מודלי צ'אט לדיאלוג רב-תורות.
למה: מודלי צ'אט מצפים לתורות מובנים לפי תפקידים; עבור משימות חד-פעמיות מודל ה-instruct פשוט וזול יותר.
הפלט חייב להיות דטרמיניסטי וניתן לשחזור עבור דוח ציות.
הגדר את ה-decoding ל-greedy (ללא sampling) כך שאסימון ההסתברות הגבוהה ביותר ייבחר תמיד.
למה: Greedy decoding מסיר אקראיות; sampling עם temperature מציג שונות שאינך רוצה בפלט מבוקר.
יצירת תוכן קריאייטיבי מרגישה חזרתית ותפלה.
עבור ל-sampling decoding והעלה את ה-temperature (לדוגמה 0.7-1.0) כדי להרחיב את התפלגות האסימונים.
למה: temperature גבוה יותר משטח את ההסתברויות כך שאסימונים בעלי דירוג נמוך יותר נבחרים, מה שמגביר את המגוון.
פלט ה-sampling חורג לעיתים מהנושא עם אסימונים נדירים.
הגבל את ה-sampling באמצעות top-k או top-p (nucleus) כדי להגביל את המועמדים לאסימונים הסבירים ביותר.
למה: top-k מגביל את ספירת המועמדים; top-p מגביל מסת הסתברות מצטברת - שניהם מקצצים את הזנב הארוך הגורם לסחף.
המודל נכנס ללולאות, חוזר על אותו ביטוי או משפט.
הגדל את פרמטר ה-repetition penalty כדי למנוע הוצאה חוזרת של אסימונים שנדונו לאחרונה.
למה: העונש מוריד את ההסתברות של אסימונים שכבר נראו; stop sequences לבדם אינם מתקנים לולאות במהלך יצירה.
היצירה עוברת את התשובה ונכנסת לטקסט המשך הזוי.
הגדר stop sequence אחד או יותר (לדוגמה "\n\n", "###") כך שהיצירה תיפסק בגבול ידוע.
למה: Stop sequences מסיימים את הפלט באופן דטרמיניסטי; הסתמכות על max tokens בלבד קוטעת באמצע המשפט.
תגובות נקטעות לפני השלמת ה-JSON המבוקש.
העלה את max new tokens; הגדר min new tokens כדי לאלץ תשובה באורך מינימלי בעת הצורך.
למה: max new tokens מגביל את אורך הפלט; אם נמוך מדי הוא קוטע פלט מובנה לפני הסוגר הסוגר.
סיווג zero-shot מתייג בטעות מקרים חריגים.
הוסף קומץ דוגמאות קלט/פלט מתויגות (few-shot) ישירות ל-prompt.
למה: דוגמאות few-shot קובעות את פורמט הפלט ואת גבול ההחלטה בתוך ההקשר ללא כל כוונון.
הצוות רוצה לבצע איטרציות על prompt לפני כתיבת קוד כלשהו.
השתמש ב-Prompt Lab - עבור בין מצבי freeform, structured ו-chat, כוונן פרמטרים, ואז שמור כתבנית prompt.
למה: Prompt Lab הוא משטח האיטרציה ללא קוד; המצב המובנה מפריד הוראות, דוגמאות וקלט בצורה נקייה.
מסמכים ארוכים חורגים מחלון ההקשר של המודל שנבחר.
חלק ושלף רק קטעים רלוונטיים (RAG) או בחר מודל עם הקשר ארוך יותר מהקטלוג.
למה: אינך יכול לחרוג ממגבלת האסימונים של המודל; דחיסת טקסט נוסף גורמת לשגיאות או השמטה בשקט - אחזור הוא הפתרון המתאים לקנה מידה.
Prompt engineering מגיע למישור במשימת תחום צר הזקוקה לסגנון עקבי.
הפעל prompt tuning ב-Tuning Studio כדי ללמוד soft prompt (וקטור מכוונן) על דוגמאות מתויגות.
למה: Prompt tuning מתאים התנהגות מבלי לשנות משקולות בסיס - זול יותר מ-fine-tuning, אמין יותר מ-prompts ארוכים.
המודל חסר ידע עדכני ועובדתי ברמת הארגון.
השתמש ב-RAG כדי לבסס תשובות במסמכים מאוחזרים במקום לכווונן את המודל על עובדות אלו.
למה: Tuning מלמד סגנון/התנהגות, לא עובדות טריות; RAG מזריק הקשר מבוסס עדכני וקל לעדכון.
החלטה בין prompt tuning לבין fine-tuning מלא עבור פרויקט watsonx ברמת עמית.
העדף prompt tuning: הוא מאמן הרבה פחות פרמטרים, פועל מהר יותר, והוא הנתיב הנתמך ב-Tuning Studio.
למה: Full fine-tuning יקר, דורש מערכי נתונים גדולים, ומסכן שכחה קטסטרופלית; prompt tuning הוא ברירת המחדל של watsonx.
הכנת נתונים לכוונון prompt של מודל סיכום.
ספק זוגות קלט/פלט בפורמט JSON/JSONL הצפוי, מחולקים לערכות אימון ואימות.
למה: זוגות נקיים וייצוגיים מניעים את איכות הכוונון; יש צורך בערכת אימות שמורה כדי לקרוא הכללה.
עקומת אובדן הכוונון משתטחת מוקדם בזמן שאובדן האימות מתחיל לעלות.
עצור או צמצם epochs - המודל מתחיל להתאים יתר על המידה לסט האימון.
למה: אובדן אימון/אימות מתפצל הוא אות ה-overfit הקלאסי; יותר epochs ישננו, לא יכלילו.
תוצאות ה-prompt-tuning אינן יציבות על פני הרצות.
כוונן את learning rate, מספר ה-epochs, batch size, ומספר ה-virtual tokens בתצורת הכוונון.
למה: learning rate גבוה מדי מערער את היציבות של האימון; אלה הם המנופים ש-Tuning Studio חושף לצורך התכנסות.
צריך להשוות שני prompts או נכסים מכווננים באופן אובייקטיבי.
הערך באמצעות מדדי משימות (לדוגמה ROUGE/BLEU עבור סיכום, exact-match/F1 עבור חילוץ) בתוספת סקירה אנושית.
למה: איכות יצירה היא רב-ממדית; מדדים אוטומטיים מזהים רגרסיות אך סקירה אנושית שופטת נאמנות.
מודל מכוונן עדיין ממציא עובדות שאינן קיימות במקור.
בסס באמצעות RAG, הורד את ה-temperature, והנחה את המודל לענות רק מההקשר שסופק או לומר שהוא אינו יודע.
למה: הזיה היא בעיית ביסוס ו-decoding יותר מאשר בעיית משקולות; אחזור בתוספת אילוצים מתקנים את רוב הבעיה.
רק כמה עשרות דוגמאות מתויגות זמינות להתאמה.
הישאר עם few-shot prompting או prompt tuning קל; אל תבצע fine-tuning על נתונים זעירים.
למה: מערכי נתונים קטנים עוברים overfit רע תחת fine-tuning מלא; דוגמאות בתוך ההקשר מכלילות טוב יותר בקנה מידה זה.
בחירה באיזה מודל בסיס לכוונון prompt עבור משימת סיווג.
בחר מודל בסיס Granite הניתן לכוונון ש-Tuning Studio תומך בו עבור prompt tuning, בגודל המתאים למשימה.
למה: לא כל מודל בקטלוג ניתן לכוונון; כוונון מודל קטן יותר נתמך זול יותר ולעתים קרובות מספיק לסיווג.
יש לעקוב אחר איכות הפלט הגנרטיבי באופן רציף בייצור.
הגדר מדדי הערכה של watsonx.governance (איכות, סחף, מדדי generative-AI) מול הפריסה.
למה: Governance הופך הערכה חד-פעמית לספי מדדים מנוטרים עם התראות, ולא בדיקה נקודתית ידנית.
אותו prompt מכוונן חייב לשרת קלטים רבים עם שדות שונים.
הגדר את תבנית ה-prompt עם משתנים בעלי שם וספק ערכים בזמן ההסקה.
למה: משתנים שומרים תבנית אחת ניתנת לשימוש חוזר במקום קידוד קשיח של קלטים, והם ממפים באופן נקי לפרמטרי API.
מודל מתעלם מהוראת המשימה וממשיך את הטקסט.
השתמש במודל מכוונן להוראות ומסגר את ה-prompt כהנחיה מפורשת, לא כקטע להשלמה.
למה: מודלי completion בסיסיים ממשיכים דפוסים; מודלי instruct מאומנים לקיים הנחיות.
צורך בהפעלת SQL אינטראקטיבי על פני נתוני אחסון אובייקטים להכנת תכונות AI.
השתמש במנוע Presto של watsonx.data מעל טבלאות Iceberg באחסון אובייקטים.
למה: Presto מספק SQL מאוחד מהיר בפורמטים של טבלאות פתוחות ללא העתקת נתונים למחסן נתונים.
נתוני אנליטיקה זקוקים לאבולוציית סכמה ו-time-travel על ה-lakehouse.
אחסן אותם כטבלאות Apache Iceberg המנוהלות על ידי watsonx.data.
למה: Iceberg תומך באבולוציית סכמה, snapshots, ופעולות ACID על אחסון אובייקטים - ברירת המחדל של ה-lakehouse.
בחירת מנוע לטרנספורמציה כבדה של ETL מול שאילתת ad-hoc.
השתמש ב-Spark עבור טרנספורמציית ETL/אצווה גדולה; השתמש ב-Presto עבור SQL אינטראקטיבי עם לטנסי נמוכה.
למה: Spark מאפשר חישוב אצווה בקנה מידה; Presto מותאם לשאילתות מאוחדות מהירות - בחר לפי צורת עומס העבודה.
RAG זקוק ל-vector store עבור embeddings הממוקמים יחד עם נתונים מנוהלים.
הקצה Milvus בתוך watsonx.data כבסיס הנתונים הווקטורי לחיפוש דמיון.
למה: Milvus הוא ה-vector store המשולב של watsonx.data; שמירת embeddings ב-lakehouse מפשטת את הממשל.
החלטה בין Milvus לבין watsonx Discovery עבור אחזור.
השתמש ב-Milvus עבור דמיון וקטורי גולמי שאתה שולט בו; השתמש ב-watsonx Discovery (מבוסס Elasticsearch) לחיפוש ארגוני מנוהל עם אחזור היברידי.
למה: Milvus הוא DB וקטורי שאתה מפעיל; Discovery הוא שירות חיפוש ברמה גבוהה יותר עם קליטה ודירוג מובנים.
הכנת מסמכים כך שמודל יסוד יוכל לבסס עליהם תשובות.
פצל מסמכים ל-chunks, צור embeddings עם מודל embedding של watsonx.ai, ובצע אינדוקס שלהם ב-Milvus.
למה: איכות האחזור תלויה ב-chunking הגיוני ובמודל embedding תואם; מימדים לא תואמים שוברים את האינדקס.
תכונת AI זקוקה לנתונים הפרוסים על פני מספר מסדי נתונים ו-buckets.
רשום את המקורות ב-watsonx.data ובצע שאילתות עליהם במקום דרך ה-federation של המנוע.
למה: Federation מונע שכפול נתונים יקר ושומר על נקודת גישה מנוהלת יחידה.
צוות הממשל דורש lineage ובקרת גישה על הנתונים המזינים מודלים.
קטלג מערכי נתונים בקטלוג watsonx.data ויישם גישת IAM/מבוססת מדיניות.
למה: קטלוג מנוהל הוא מה שמקשר lineage של נתונים ל-factsheets של מודלים בהמשך - גישת bucket ad-hoc עוקפת זאת.
פרויקט watsonx.ai חייב לקרוא טבלאות lakehouse מנוהלות עבור RAG.
הוסף חיבור watsonx.data לפרויקט והפנה לטבלאות כנכסי נתונים.
למה: חיבורים חושפים נתוני lakehouse מנוהלים לפרויקט ה-AI ללא ייצוא עותקים.
prompt עובד מ-Prompt Lab חייב להפוך לנכס לשימוש חוזר וניתן לפריסה.
שמור אותו כנכס תבנית prompt בפרויקט, ולאחר מכן קדם אותו למרחב פריסה.
למה: מרחבי פריסה הם הגבול של הייצור; prompts חייבים להיות מקודמים לשם לפני שניתן יהיה לשרת אותם.
יישום זקוק לנקודת קצה של הסקה עם לטנסי נמוכה עבור prompt מכוונן.
צור פריסה מקוונת במרחב הפריסה; היא חושפת נקודת קצה REST לניקוד/יצירה.
למה: פריסות מקוונות מספקות נקודת קצה סינכרונית; פריסות אצווה מיועדות למשימות ניקוד לא מקוונות.
קריאה למודל יסוד מקוד יישום Python.
השתמש במחלקת ModelInference של watsonx.ai Python SDK וקרא ל-generate_text עם הפרמטרים שלך.
למה: ModelInference עוטף אימות, זיהוי מודל, פרויקט/מרחב ופרמטרים בלקוח אחד - נקי יותר מ-REST גולמי.
שירות שאינו Python חייב לקרוא להסקת watsonx.ai.
קרא לנקודת הקצה של watsonx.ai text-generation REST עם זיהוי המודל, קלט ופרמטרים בגוף ה-JSON.
למה: ה-REST API אינו תלוי שפה; ה-SDK הוא רק עטיפה על אותן נקודות קצה.
אימות קריאות SDK או API ל-watsonx.ai.
החלף מפתח API של IBM Cloud IAM באסימון bearer, ואז קרא לנקודת הקצה עם אסימון זה וזיהוי הפרויקט/מרחב שלך.
למה: watsonx משתמש ב-IBM Cloud IAM; הטמעת מפתח ה-API הגולמי בכל קריאה או קידוד קשיח של אסימונים היא שגויה ואינה מאובטחת.
החלטה היכן נכס מודל חי במהלך פיתוח לעומת שירות.
פתח ונסה בפרויקט; קדם את הנכס למרחב פריסה כדי לשרת אותו.
למה: פרויקטים הם סביבות פיתוח שיתופיות; מרחבי פריסה מכילים נכסים מקודמים לייצור, מבוקרי גישה.
חיבור אחזור ויצירה לזרימת יישום אחת.
הטבע את השאילתה, אחזר top-k chunks מ-Milvus/Discovery, הזרק אותם לתבנית ה-prompt, ואז קרא למודל הפרוס.
למה: סדר האחזור ואז היצירה הוא מה שמבסס את התשובה; קריאה למודל תחילה מביסה את ה-RAG.
מיפוי עומס עבודה GenAI למשפחת מוצרי watsonx.
בנה וכונן ב-watsonx.ai, אחסן/שאל נתונים ב-watsonx.data, נהל ונטר ב-watsonx.governance.
למה: שלושת הרכיבים משלימים, לא ניתנים להחלפה - ידיעה איזה מהם עושה מה היא ידע ליבה לבחינה.
ארגון זקוק ל-watsonx מקומי מסיבות של מקום אחסון נתונים.
פרוס את watsonx כתוכנה על Cloud Pak for Data (Red Hat OpenShift) במקום את הצעת ה-SaaS של IBM Cloud.
למה: SaaS רץ ב-IBM Cloud; גורם הצורה של התוכנה רץ באשכול OpenShift שלך לצרכי מקום אחסון/air-gap.
ארגון עבודת GenAI שיתופית והארטיפקטים שלה.
השתמש בפרויקט watsonx כמרחב העבודה המכיל נכסי נתונים, notebooks, prompts ומודלים מכווננים עם גישה משותפת.
למה: פרויקטים הם יחידת שיתוף הפעולה ותחום הנכסים; מרחבי פריסה נפרדים ומיועדים לייצור.
שליטה על מי יכול לגשת לאיזה מופעי ונכסי watsonx.
השתמש בחשבונות IBM Cloud, קבוצות משאבים, ומדיניות/תפקידי גישה של IAM כדי להגביל גישה.
למה: גישה ב-watsonx מונעת על ידי IAM ברמת החשבון/קבוצת משאבים - לא רק שיתוף ad-hoc לכל נכס.
הערכת עלות הפעלת הסקת מודלי יסוד.
קח בחשבון חיוב מבוסס אסימונים על הסקת watsonx.ai בתוספת מנועים/אחסון מוקצים ב-watsonx.data.
למה: עלות GenAI נשלטת על ידי אסימוני קלט/פלט; חישוב lakehouse ו-vector-store הם פריטים נפרדים.
שרטוט ארכיטקטורת RAG בייצור על watsonx.
נתוני Lakehouse ← embeddings ב-Milvus ← אחזור + יצירה של watsonx.ai ← אפליקציה, עם ניטור watsonx.governance לאורך כל הדרך.
למה: זרימה מקצה לקצה זו היא התבנית הרשמית של watsonx שהבחינה מצפה ממך לזהות.
מבקרים מבקשים תיעוד של מחזור חיים ומקור מודל פרוס.
השתמש ב-AI factsheets של watsonx.governance כדי לתעד מטה-נתונים של מודלים, lineage ואישורים לאורך מחזור החיים.
למה: Factsheets הם מערכת הרישום של watsonx למקור מודלים - התשובה המתועדת לשאלה "מאיפה הגיע המודל הזה".
הפלט של מודל ייצור מתדרדר עם הזמן.
הגדר את watsonx.governance drift ו-quality monitors עם ספים והתראות על הפריסה.
למה: ניטור רציף מזהה סחף לפני שהמשתמשים מזהים; אימות חד-פעמי אינו יכול לזהות דעיכה לאחר הפריסה.
יש לבדוק מודל לאי-שוויון בטיפול בקבוצות מוגנות.
הפעל הערכות fairness/bias ב-watsonx.governance ותעד הפחתה ב-factsheet.
למה: חובות AI אחראי דורשות הוגנות נמדדת ומתועדת - לא רק הנחה בלתי נמדדת של הוגנות.
צוות הציות זקוק למערכת ה-GenAI ממופה לתקנות AI.
השתמש ב-watsonx.governance כדי לעקוב אחר סיכונים, לקשר בקרות לתקנות, ולתחזק ראיות מוכנות לביקורת.
למה: Governance קושר סיכון מודל לבקרות רגולטוריות במקום אחד, וזה מה שביקורות ועקרונות ה-AI האחראי של IBM דורשים.