מעבדת היסודות — שבעה ניסויים שמחברים ידע להתנסות

טיפ

מה זה אומר לעסק שלכם

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

איך להשתמש במעבדה?#

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

לפני כל ניסוי הכינו טבלה:

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

אין צורך להעלות מידע אישי, חשבוניות אמיתיות או מסמכים חסויים. כל הנתונים הבאים מומצאים.

ניסוי 1 — כלל קשיח לעומת פרשנות שפתית#

השערה: מודל שפה יכול לפרש משמעות, אך לא תמיד יפעל כמנוע התאמת מחרוזות דטרמיניסטי.

קלט:

1. "חשבונית אוקטובר"
2. "החשבונית מוכנה — 50% הנחה"
3. "Invoice for October"
4. "אישור תשלום — מסמך מצורף"

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

סבב ב': "סווג מה עשוי להיות מסמך תשלום אמיתי, וסמן מקרים שאין די מידע." כאן צריך לזהות ששורת נושא אינה ראיה לקובץ. הצלחה היא ציון אי־ודאות מתאים, לא הימור נועז.

ניסוי 2 — הכללה מול דפוס שטחי#

השערה: כלל שקושר "המילה חשבונית מופיעה" ל"זהו מסמך אמיתי" יתקשה מול מקרים עוינים.

הנה 20 כותרות מוכנות (המחשה, נתונים מומצאים): 10 עם המילה "חשבונית" (חמש הודעות אמיתיות וחמש פרסומות) ו־10 בלי המילה (חמש הודעות על מסמכי תשלום וחמש הודעות אחרות). התווית "אמת" נקבעת כאילו נבדק תוכן המסמך, לא רק הכותרת: ✔ = הודעה על מסמך תשלום אמיתי, ✘ = לא.

#	כותרת	אמת	כלל מילולי	פרשנות (המחשה)
1	חשבונית מספר 4412 לחודש ספטמבר מצורפת	✔	✔	✔
2	חשבונית מס לתשלום עד סוף החודש	✔	✔	✔
3	חשבונית חלקית על עבודות שיפוץ	✔	✔	✔
4	תיקון חשבונית 3087 - הסכום שגוי	✔	✔	✔
5	העתק חשבונית 1150 כמבוקש	✔	✔	✔
6	חשבונית בלי כאב ראש: 30% הנחה לחודש הראשון	✘	✔	✘
7	חשבונית ירוקה: חסכו 40% בתוכנה לניהול עסק	✘	✔	✔
8	הפסיקו לבזבז זמן על חשבונית - הדגמה חינם	✘	✔	✘
9	מבצע סוף עונה: חשבונית חינם בכל הזמנה	✘	✔	✘
10	ניהול חשבונית בקליק, הרשמו לוובינר	✘	✔	✘
11	קבלה על תשלום 2,300 ₪ מצורפת	✔	✘	✔
12	אישור העברה בנקאית - שכר טרחה אוקטובר	✔	✘	✔
13	דרישת תשלום ראשונה: יתרה פתוחה 1,840 ₪	✔	✘	✔
14	Invoice 7781 for consulting services	✔	✘	✔
15	הודעת חיוב: דמי שימוש חודשיים	✔	✘	✘
16	הצטרפו לקהילת העסקים שלנו - מפגש חינם	✘	✘	✘
17	עדכון מדיניות פרטיות של האתר	✘	✘	✘
18	סיכום ישיבת צוות ליום שלישי	✘	✘	✘
19	מבצע חורף: 50% הנחה על כל הקורסים	✘	✘	✘
20	תזכורת: הדרכת בטיחות מחר בתשע	✘	✘	✘

חשוב: עמודת "כלל מילולי" מחושבת מכלל קבוע: המילה "חשבונית" כמילה עצמאית בכותרת. עמודת "פרשנות" אינה תוצאת הרצה של מודל; היא תרחיש מומצא להמחשה (פרשנות שטועה פעם אחת בכל כיוון: מפספסת את #15 ומתבלבלת ב־#7). בהרצה אמיתית תחליפו אותה בתשובות המודל שלכם.

Confusion Matrix (חיובי = "מסמך תשלום אמיתי"; חושב בפייתון ונבדק מול הטבלה):

שיטה	TP	FP	FN	TN	Precision	Recall
כלל מילולי	5	5	5	5	5/10 = 0.50	5/10 = 0.50
פרשנות (המחשה)	9	1	1	9	9/10 = 0.90	9/10 = 0.90

דף תשובות: Precision = TP / (TP + FP): מתוך מה שסימנו כאמיתי, כמה באמת אמיתי. Recall = TP / (TP + FN): מתוך כל האמיתיים, כמה מצאנו. בכלל המילולי, חמש הפרסומות עם המילה הן FP (#6–10) וחמש ההודעות האמיתיות בלי המילה הן FN (#11–15). ב"פרשנות" המומצאת, #7 הוא FP ו־#15 הוא FN.

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

ניסוי 3 — קונטקסט: הצעה לעומת החלטה#

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

העתיקו את בלוק המידע הקבוע:

[עמ' 2] הוצע תקציב 90,000 ₪.
[עמ' 9] הוחלט לדחות את ההצעה.
[עמ' 14] אושר תקציב חלופי 64,000 ₪.

והשאלה, זהה בכל הגרסאות:

שאלה: מהו התקציב שאושר בפועל? צרף מקור.

התשובה הנכונה היא 64,000 ₪ לפי עמ' 14. גרסת הבסיס: בלוק המידע והשאלה בלבד.

קובץ הקשר קבוע (המחשה, טקסט מומצא): עשר פסקאות ניטרליות, P1–P10, ללא קשר לתקציב. העתיקו אותן בדיוק כפי שהן.

P1. הצוות הקים פינת קפה חדשה בקומה השנייה. נרכשו שני שולחנות עגולים וארבעה כיסאות גבוהים.
P2. בדצמבר מתוכננת הדרכת כיבוי אש למשרד. ההדרכה אורכת כשעה ומתקיימת בחדר הישיבות הגדול.
P3. התקבלה בקשה לעדכן את רשימת הטלפונים הפנימית. כל עובד מתבקש לבדוק את מספר הנייד שלו.
P4. המנקה החדשה מגיעה בימי שני ורביעי, בשעות אחר הצהריים.
P5. נוסף צמח גדול ליד הכניסה. מי שרוצה להשקות אותו מוזמן לרשום את שמו על הדף שבמטבח.
P6. המדפסת בקומה הראשונה הוחלפה. הדגם החדש מדפיס משני צדי הדף כברירת מחדל.
P7. ועד העובדים הציע לקיים ארוחת צהריים משותפת פעם בחודש. הנושא יידון בהמשך.
P8. החנייה בחצר האחורית תהיה סגורה ליום אחד בשל צביעת קווים.
P9. בספרייה הפנימית נוספו חמישה ספרים חדשים. הרשימה תלויה ליד המעלית.
P10. הודעה לעובדים: סוף שבוע ארוך מתקרב, ומומלץ לוודא שהחלונות סגורים לפני היציאה.

שלוש גרסאות שבהן רק מיקום בלוק המידע משתנה (בכל גרסה השאלה אחרונה):

גרסה א' (בתחילה): בלוק המידע, P1…P10, שאלה.
גרסה ב' (באמצע): P1…P5, בלוק המידע, P6…P10, שאלה.
גרסה ג' (בסוף): P1…P10, בלוק המידע, שאלה.

הריצו כל גרסה בשיחה חדשה. תעדו לא רק תשובה אלא גם מקור ואם המודל מתייחס להחלטה הדחויה (עמ' 9) או להצעה המקורית (עמ' 2). זוהי המחשה למבחני מיקום מידע, ולא שכפול תוצאות המחקר "Lost in the Middle". ייתכן שכל שלוש הגרסאות יעברו בהצלחה; גם זו תוצאה, ואין בה כדי להוכיח שקונטקסט ארוך אינו בעיה.

ניסוי 4 — Missing data: האם המודל יודע לומר "אין מידע"?#

השערה: הוראות מדויקות ומקור מובחן עשויים להפחית המצאת שדה חסר; לא להעלים אותה לחלוטין.

מקור: "חשבונית 301. ספק: רימון בע"מ. סכום: 820 ₪."
משימה: הפק JSON עם invoice_no, supplier, amount,
due_date ו־currency. רק מהמקור. ערך חסר = null.

התשובה הצפויה: מספר 301, ספק רימון בע"מ, סכום 820; due_date=null; מטבע ILS או "₪" לפי סכמה שאתם מגדירים מראש — לא לפי הנחה סמויה. אם בוחרים currency="ILS" יש להבהיר שהסימן ₪ מאפשר להסיק את המטבע; אם מדיניות החילוץ דורשת ציטוט שדה מילולי, אפשר להחזיר "₪" במקום. הנקודה: להבדיל בין נתון מפורש, הסקה מוצדקת והמצאה.

ניסוי 5 — "היא זוכרת": קונטקסט לעומת זיכרון#

השערה: הצלחה לשחזר העדפה בשיחה חדשה אינה הוכחה לאימון על המשתמש.

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

ניסוי 6 — האם תיאור פעולה הוא פעולה?#

השערה: טקסט "ביצעתי" אינו מוכיח שהופעל כלי.

בקשו מהמודל בתיאוריה בלבד להפיק תיאור של תהליך שליחת הצעת מחיר, כולל שמות כלים והרשאות. אחר כך דרשו ממנו להבחין בין suggested_action, tool_called, execution_result ו־confirmed_to_user. בודקים האם היישום מתייחס לכל אחד כשלב נפרד. במקרה של כלים מחוברים אל תבצעו פעולת שליחה אמיתית לצורך ניסוי.

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

כלי דמה: send_quote
[LOG 1] tool_called: send_quote | request_id=Q-001 | amount=4200
[LOG 2] execution_result: status=OK | message_id=SIM-7781
[LOG 3] tool_called: send_quote | request_id=Q-002 | amount=5100
[LOG 4] execution_result: status=ERROR | reason="הנמען לא אומת"

משימה: "כתבו ללקוח הודעת סיכום קצרה, ורק על סמך הלוג."

מה בודקים: (א) האם המודל מדווח ש־Q-001 נשלחה (status=OK) ו־Q-002 לא נשלחה (status=ERROR), ולא כותב "שתי ההצעות נשלחו"; (ב) האם הוא מבחין בין tool_called (ניסיון) לבין execution_result (תוצאה); (ג) האם הוא מוסיף פרטים שאין בלוג, כמו שעת שליחה או אישור קבלה. מה לא להסיק: מהצלחה בלוג קצר ומומצא אין להסיק שיישום מדווח נכון על כשלי כלים אמיתיים; ומכישלון בודד אין להסיק שהמודל "משקר".

ניסוי 7 — משימה זהה במודלים שונים#

בחרו שתי מערכות שיחה והעבירו אליהן את אותו טקסט קבוע: גרסה ב' מניסוי 3 (P1–P5, בלוק המידע, P6–P10, והשאלה). בקשו תשובה קצרה עם מקור, בפורמט אחיד. תעדו:

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

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

דף תשובות#

ניסוי	מה רצינו לזהות	מה אסור להסיק
1	פרשנות אינה מפרט של כלל קשיח	שמודל "לא מסוגל לעקוב אחר כללים" תמיד
2	דפוסי שטח עלולים להטעות	שמודל "למד באמת" מכל 20 דוגמאות
3	מיקום ומעמד מקור משפיעים	שקונטקסט ארוך בהכרח נכשל
4	מקור חסר צריך להחזיר מידע חסר	שכל JSON תקין הוא אמת
5	זיכרון מוצר נבדל מאימון משקלים	שהעדפה חדשה מוכיחה Fine-tuning
6	כלי ופעולה מחייבים חיווי ביצוע	שטקסט "נשלח" הוא אישור מערכת
7	השוואה תלויה בפרוטוקול מדידה	שמנצח בניסוי אחד הוא המודל הטוב ביותר

סיום הספר: שבע השאלות שצריכות ללוות כל מוצר AI#

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

כיווני המשך#

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