מפת החלטות: prompt, RAG, כלים, סוכן או fine-tune?

החלק הקשה הוא לא איך כל טכניקה עובדת, אלא באיזו לבחור.

המפה עוקבת אחרי העצה שחוזרת במקורות הרשמיים שצוטטו בסדרה, ובעיקר במאמר Building effective agents של Anthropic: למצוא את הפתרון הפשוט ביותר שעובד, ולהוסיף מורכבות רק כשהמדידות מראות שזה עוזר.

המפה

עברו על השאלות לפי הסדר ועצרו בראשונה שמטפלת בבעיה האמיתית שלכם. אז מדדו, והמשיכו הלאה רק אם הבעיה נשארה.

כל צעד למטה עולה יותר לבנות, להריץ ולתחזק מזה שמעליו. צוותים שמתחילים מלמטה (fine-tuning למודל בשביל בעיה ש-prompt ברור או שלב שליפה היו פותרים) משלמים על זה בזמן ובכסף.

מה כל טכניקה משנה

טכניקה	מה היא משנה	מה היא פותרת	עלות בנייה והרצה
Prompt	את ההוראות	משימה לא ברורה, פורמט, טון	הנמוכה ביותר
פלט מובנה	את הצורה של הפלט	JSON לא תקין, שדות חסרים	נמוכה
RAG	את מה שהמודל יכול לקרוא	ידע חסר, עדכני או פרטי	בינונית
כלים	את מה שהמודל יכול לעשות	צורך בנתונים חיים או בפעולות	בינונית
Workflow	את הצעדים, קבועים בקוד	משימות רב-שלביות עם מבנה ידוע	בינונית
סוכן	את הצעדים, שהמודל בוחר	משימות פתוחות	גבוהה, ופחות צפויה
Fine-tuning	את המשקלות של המודל	התנהגות ש-prompting לא מתקן	גבוהה, ועוד תחזוקה
מודל קטן, מזוקק או מקומי	איזה מודל רץ	עלות, זמן תגובה, פרטיות בנפח גבוה	משתנה

הן מתחברות. מערכת production טיפוסית משתמשת ב-prompt טוב, בפלט מובנה, ב-RAG על המסמכים שלה, בכמה כלים וב-workflow סביבם, כש-fine-tuning נדיר וסוכנים שמורים למשימות שבאמת צריכות אותם.

דוגמה מלאה

צוות בונה עוזר תמיכה למוצר שלו:

1. Prompt. system prompt עם הטון והכללים של המוצר עונה טוב על שאלות כלליות, אבל ממציא פרטים על מחירים. זה ידע חסר, אז הצעד הבא הוא RAG, לא prompt ארוך יותר.
2. RAG על מרכז העזרה מתקן את התשובות על מחירים. eval של 50 שאלות אמיתיות מראה שהשליפה מפספסת קודי שגיאה, אז הם מוסיפים חיפוש היברידי עם BM25.
3. כלים. משתמשים שואלים “איפה ההזמנה שלי?”. זה דורש נתונים חיים, אז הם מוסיפים כלי לקריאה בלבד, get_order_status.
4. Workflow. בקשות החזר צריכות תהליך קבוע: לסווג, לבדוק את המדיניות, להכין החזר שאדם יאשר. הם בונים את זה כ-workflow של routing ולא כסוכן, כי הצעדים ידועים.
5. Production. הם מוסיפים guardrails (סינון קלט, השחרת מידע אישי, אישור לפני כל החזר), observability עם traces, ו-prompt caching ל-system prompt הארוך.
6. לא נדרש (עדיין): סוכן ו-fine-tuning. ה-eval לא מראה בעיה שהם היו פותרים.

לפני שעולים לאוויר

רשימת בדיקות שמאגדת את סדרת ה-production:

• סט eval של מקרים אמיתיים, עם בדיקות בקוד איפה שאפשר ושופט LLM שנבדק איפה שלא.
• טיפול ב-stop_reason בכל מקום: max_tokens, refusal, tool_use.
• תוכן לא אמין מופרד מההוראות, וכלים עם הרשאה מינימלית.
• אישור אנושי לפני פעולות בלתי הפיכות או כאלה שיוצאות החוצה.
• מגבלות: מקסימום טוקנים, צעדים, בקשות ותקציב לכל משתמש ולכל משימה.
• Traces לכל בקשה, עם כללי פרטיות למה שנשמר.
• בדיקת עלות: המודל וה-effort הנכונים, caching לקידומות שחוזרות, batches לעבודה שיכולה לחכות.
• תוכנית לשינויים: גרסאות מודלים יוצאות משימוש ומחירים משתנים. הריצו שוב את ה-eval כשאתם מחליפים מודל.

מכאן והלאה

התחום זז מהר, וחלק מהפרטים בסדרה (שמות מודלים, מחירים, תכונות בבטא) ישתנו. המושגים משתנים הרבה יותר לאט: טוקנים והקשר, שליפה, לולאת הכלים, workflows מול סוכנים, evals. כשמשהו חדש יוצא, שאלו את אותן שאלות כמו במפה: מה הוא משנה, איזו בעיה הוא פותר, ואיך תמדדו שהוא עזר?

למונחים שהופיעו לאורך הסדרה, ראו את מילון מונחי AI.

כדי לראות את המפה בפעולה על אפליקציה אחת, צעד אחרי צעד, קראו את מחברים הכול.