אוטומציה עשויה להפחית חזרות בלי להבטיח עדכניות, דיוק או רלוונטיות. סיכום שנוצר בבינה מלאכותית הוא עדיין הצעה לבדיקה.
שמירת ראיות לכל מספר
התאימו מספרים למאגר ששימש ושמרו תקופה, יחידה, מסננים וגרסת חישוב. בדקו חישובים חשובים בנפרד. אל תמלאו חוסר בערכים מומצאים ואל תציגו תחזית כתוצאה שנצפתה.
תכנון שגיאות וביקורת
הגדירו מי בודק, מקבל ומתקן. הציגו כשל חלקי; דוח תקין ישן אינו מתחדש בעקבות שליחה חוזרת. בדקו תוכן ונמענים ומדדו חיסכון בפועל במקום הבטחות גורפות.
| נושא | בדיקה לתיעוד |
|---|---|
| מספר | מקור, נוסחה והיקף ניתנים למעקב |
| סיכום אוטומטי | טענות ומגבלות נבדקו |
| הפצה | מצב הדוח ונמענים נבדקו |
מקורות ובדיקה
- NIST — Generative AI Profile, confabulation and evaluation
- Government Analysis Function — Communicating uncertainty
אזורי זמן ואירועים מאוחרים
תקופת דוח תלויה בזמן האירוע ובכללי הסגירה.
- שמרו בנפרד זמן אירוע, זמן קליטה ואזור זמן עסקי. בדוגמה בדיונית, 23:30 UTC הוא 01:30 ביום הבא בהיסט קבוע UTC+02:00. חותמת הזמן עם אזור זמן של PostgreSQL אינה שומרת את שם האזור המקורי.
- כללו את ההתחלה והחריגו את הסיום. חשבו את הגבולות באזור העסקי לפני המרה ל־UTC. בדקו שינוי שעון עונתי, מעבר חודש ותאריך בלי שעה; יום מקומי אינו תמיד 24 שעות.
- הגדירו איחור מותר ומועד סגירת הדוח. חזרו על אותו מזהה כדי להבחין בין אירוע חדש לכפילות. שמרו גרסה שפורסמה ותעדו את השפעת התיקון; סימן מים מעריך הגעה ואינו מבטיח שלמות.
מקרה קבלה שניתן לשחזר
דוגמה בדיונית: הנתונים אינם מתארים לקוח או תוצאה שנצפתה.
הצגת נתוני המקרה
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}החלטה צפויה
באזור הזמן שצוין האירוע שייך ל־9 באוקטובר. שמרו גם את רגע UTC.
נוהל בדיקה
- הגדירו אזור זמן ורגע ייחוס.
- שחזרו אירוע סמוך לחצות.
- שמרו UTC, תאריך מקומי וכלל סגירה. הוסיפו שעה מקומית דו־משמעית בעת שינוי השעון; שמרו היסט ואזור זמן במקום להסיק רגע מסוים.
האם יום הקליטה יכול לשמש כיום האירוע?
רק אם הגדרת הדוח דורשת זאת. שמרו את שני הזמנים והסבירו טיפול באירועים מאוחרים.
מקור ראשוני: PostgreSQL — Date/time types. שיטה קשורה: קריאת המדריך המעשי.