העשיר מודל יסוד עם נתוני חברה פרטיים (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.
מקור↗