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