אינטגרציה של שימוש בכלים וקריאה לפונקציות של Anthropic באפליקציה

Anthropic Tool Use: היכן נקרעת התקשורת בין המודל לשירותים

המכניקה של Anthropic Tool Use בנויה כך: המודל בוחר כלי ויוצר ארגומנטים לקריאה, ואת הפעולה עצמה מבצע הקוד שלנו. החוליה נשברת לא ביצירת טקסט, אלא בדיוק בממשק הזה — המודל עונה בפסקה קוהרנטית במקום בקריאה ("אבהיר את סטטוס ההזמנה"), וההזמנה נשארת בסטטוס הקודם. מבחוץ זה נראה כמו זהירות, מבפנים — תרחיש לא מטופל ופנייה מהמשתמש.

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

בלי בדיקת ארגומנטים של הקריאה, השירות מחזיר סירוב, והסירוב נבלע ביומן הכללי: למפתח הוא מגיע כסיפור "לפעמים זה לא עובד".

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

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

מה נותנת קריאה מבוקרת לכלים של המודל

קריאה מבוקרת לכלים הופכת את המודל מ"יועץ" ל"מבצע": הוא לא מתאר במילים מה צריך לעשות, אלא בעצמו יוצר קריאה לשירות שלכם — עם ארגומנטים שנבדקו לפי סכימה שהוצהרה מראש. ב-Anthropic המנגנון הזה מתואר כ-Tool Use: לכל כלי יש חוזה, המודל בוחר את המתאים וממלא את השדות.

האפקט מתפרק לכמויות מדידות. שיעור הפעולות שהמודל מסיים ללא אדם עולה: השתתפות ידנית נשארת רק לאישור פעולות בלתי הפיכות — תשלומים, מחיקות, שליחה החוצה. זמן התגובה לבקשה מתקצר, כי נעלם הפער בין "הבין את המשימה" ל"העביר למערכת": הקריאה יוצאת באותו מחזור עיבוד.

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

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

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

מצבי קריאה לכלים: השוואת אפשרויות

מצב הקריאה קובע מי ומתי נותן פקודה לביצוע הכלי — והוא זה שקובע איזה סוג כשל המערכת מאפשרת. כדאי לבחור מצב לפי מחיר הטעות ולפי כמה זמן יכולה לחכות התשובה, ולא לפי נוחות האינטגרציה: לכל אפשרות יש מגבלות משלה שצריך לסגור בקוד.

בפועל אותו כלי עובד במצבים שונים: קריאה — מיידית, שינוי — דרך אישור, פעולה המונית — בתור. במכניקה של Anthropic Tool Use המצב הוא מאפיין של קריאה מסוימת, לא של הכלי, ולכן החלפה אינה מצריכה כתיבה מחדש של האינטגרציה.

סדר ההטמעה: מניתוח תרחישים ועד מסירה

מתחילים בביקורת תרחישים: מתוך כל המקומות שבהם מתבקשת קריאה לפונקציות, לוקחים את אלה שבהם טעות של המודל היא הזולה ביותר, והתוצאה נבדקת אוטומטית. הקונטור בונים על קריאה לכלים של Anthropic — המודל מחזיר ארגומנטים מובנים, לא טקסט, וכל רצף העבודות כפוף לכך.

1. ביקורת תרחישים: 3-5 פעולות שבהן המודל צריך לא להשיב בטקסט אלא לקרוא לפונקציה — סטטוס, יצירת פנייה, שליפה ממדריך. השאר עובר לסיבוב שני.
2. תיאורי כלים: סכימה ב-JSON — שם, פרמטרים, טיפוסים, שדות חובה, התנהגות בעת שגיאה. "חיפוש לקוח" ו"חיפוש הזמנה" לא צריכים לחפוף, אחרת המודל בוחר באקראי.
3. סכימת קריאות: ניתוח כוונה → בחירת כלי → בדיקת ארגומנטים → קריאה לשירות שלכם → תשובת המודל. בנפרד מסמנים שלבים שבהם נדרש אישור משתמש.
4. מגבלות: מכסת קריאות לדיאלוג אחד, זמן המתנה, איסור כתיבה ללא הסכמה, תיעוד כל קריאה עם ארגומנטים ותוצאה.
5. בדיקה בעומס: מריצים זרם דיאלוגים, סופרים שיעור בחירות כלי נכונות וארגומנטים שנדחו, בודקים התנהגות כאשר שירות חיצוני לא זמין וניסיון חוזר לאחר תקלה.
6. קבלה ומסירה לצוות: סכימת קריאות, תיאורי כלים, הגדרות מגבלות, כללי תיעוד והוראה כיצד להוסיף כלי חדש בלי לתקן את הליבה.

תיאורי כלים, הרשאות ותקנות: מה עובר ללקוח

קריאה עובדת לכלים היא רק חצי מהתוצאה. החצי השני — חבילת מסמכים שלפיה הצוות שלכם יוכל להוסיף כלים חדשים, לשנות הרשאות ולנתח תקלות בלעדינו. להלן מה בדיוק מועבר בסיום האינטגרציה עם Anthropic Tool Use.

• תיאורי כלים: ייעוד, שדות קלט ופלט, חובה, דוגמאות לקריאות תקינות וקריאות שגויות בוודאות. המודל בוחר כלי בדיוק לפי הניסוחים האלה, ולכן תיאור מעורפל הוא מקור ישיר להפעלות שווא.
• סכימת אינטגרציה: איזה שירות קורא לכלי, באיזו נקודה נבדקות הרשאות, כיצד מטופלים חריגה מזמן התגובה וקריאה חוזרת.
• מטריצת הרשאות גישה: איזה כלי זמין לאיזו תפקיד, מה עובד רק לקריאה, ומה דורש אישור אדם לפני ביצוע.
• סט בדיקות: קריאה תקינה, סירוב בהרשאות, שירות לא זמין, תשובה ריקה — מריצים לפני כל עדכון, ולא אחרי תלונת משתמש.
• נוהל ניתוח תקלות: כיצד להבחין בין שגיאה בתיאור הכלי לתקלה בשירות חיצוני, אילו שדות יומן לבדוק, למי להעביר את הניתוח.
• הוראות הפעלה: כיצד להוסיף כלי חדש, כיצד לשנות תיאור ומה לבדוק מחדש לאחר התיקון.
• יומן קריאות: אילו שדות בקשה ותוצאה נשמרים, כמה זמן נשמרים, כיצד למצוא דיאלוג מסוים לפי מזהה סשן.

מקרה בוחן: כיצד הסרנו פעולות ידניות בתמיכה

התמיכה קיבלה פניות בערוץ כללי, וכמעט כל שנייה חייבה פעולות ידניות של מפעיל: לבדוק סטטוס הזמנה במערכת החשבונות, להצליב תשלום, לבצע החזר. המפעיל עבר בין ארבעה חלונות, וזמן התגובה היה תלוי בעומס המשמרת — בשעות שיא התשובות הראשונות יצאו אחרי עשרות דקות.

לפני: תהליך ידני וצווארי הבקבוק שלו

בערך 80% מהפניות טופלו ידנית: סטטוסים טיפוסיים, זמני אספקה, חידוש מנוי. כל פעולה — כניסה נפרדת למערכת, העתקת מזהה, הצלבה ידנית. בעת תקלה בשירות סמוך המפעיל לא ראה שגיאה מפורשת ופשוט חזר על הפעולה, ולכן כפילויות של בקשות החזר הגיעו ללקוח.

אחרי: קריאה אוטומטית לכלים

חיברנו את Anthropic Tool Use: המודל מקבל רשימת כלים עם תיאור פרמטרי קלט ובוחר בעצמו את המתאים — בדיקת סטטוס, תשלום, ביצוע החזר. התשובה נבנית לפי תוצאת הקריאה, ולא לפי ניחוש, ובממשק המפעיל רואים איזו פעולה בוצעה ועם אילו נתונים. שיעור הפניות שנסגרו אוטומטית עלה ל-60–65%.

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

במה Tool Use שונה מעטיפות עצמאיות סביב המודל?

המנגנון המובנה של Anthropic Tool Use עובד אחרת מניתוח תשובת טקסט: המודל מחזיר בקשה מובנית — שם כלי וארגומנטים, האפליקציה מבצעת אותה ומחזירה תוצאה. התיאורים מוגדרים בסכימה עם טיפוסי שדות, ולכן ארגומנטים לא תקינים נחסמים לפני הביצוע.

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

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

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

בחירת הגישה פשוטה: קריאה אחת-שתיים ותשובה לא סטנדרטית — עטיפה מהירה יותר; עשרות כלים, הרשאות וביקורת — המנגנון המובנה, ומדיניות ניסיונות חוזרים ותיעוד משלנו מוציאים לשכבה נפרדת.

ספקות טכניים נפוצים לגבי האינטגרציה

ספקות בסקירה על Anthropic Tool Use — לרוב לא בשאלה אם המודל יודע לקרוא לכלים, אלא בתפעול: גבולות הסמכות, גורל אינטגרציה שכבר עובדת, התנהגות בעת תקלות בשירותים חיצוניים. נפרט ארבעה שצפים כמעט תמיד.

איך להגביל מה המודל יכול לעשות בעצמו?

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

מה קורה אם שירות חיצוני אינו זמין?

את השגיאה מקבל המודל כתוצאת קריאה, ולא המשתמש כחריגה: מחזירים תשובה מובנית עם סוג התקלה, והמודל או מנסה כלי אחר או מודיע שאין נתונים. זמן קצוב לקריאה, ניסיונות חוזרים מוגבלים עם הפוגה ומפסק אחרי סדרת כשלים — חלק מהסכימה כברירת מחדל.

איך למדוד איכות קריאות, ולא רק איכות תשובות?

מתעדים כל שלב: בקשה, כלי נבחר, ארגומנטים, תוצאה, משך. מכאן המדדים — שיעור קריאות עם ארגומנטים תקפים, שיעור תרחישים שנסגרו במעבר ראשון, מספר קריאות מיותרות, שיעור כשלים של כלים. לפיהם רואים את הידרדרות הסכימה לפני שהמשתמש מבחין בה.

נדון במשימה: מה לשלוח ומה תקבלו בתשובה

כדי לא לבזבז שבוע על מכתבי הבהרה, מספיקה שיחה עניינית אחת — 40–60 דקות עם המהנדס שלכם או בעל התרחיש. לאחר מכן אנו חוזרים עם תכנית עבודה והערכת לוחות זמנים, ולא עם הבטחות כלליות. להלן מינימום נתוני פתיחה שמספיק כדי לחשב את היקף האינטגרציה של Anthropic Tool Use במוצר שלכם.

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

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