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

אם יצא לך פעם לבקש ממודל “תחזיר לי JSON” ולקבל בתגובה משהו שנראה כמו JSON, מריח כמו JSON, אבל בפועל זה… פרוזה עם סוגריים מסולסלים – אתה לא לבד. זה אחד המקומות הכי מצחיקים-מתסכלים בעולם ה-LLM: אתה מבקש אובייקט, והוא מחזיר שיר. אתה מבקש מערך, והוא מחזיר “בטח! הנה:”.

החדשות הטובות מפי אילון אוריאל: אפשר להגיע ל-100% JSON תקין בפועל, גם בסביבות פרודקשן, גם בעומסים, גם כשמשתמשים כותבים דברים יצירתיים במיוחד. זה לא קסם, זו הנדסה: שילוב של חוזה ברור (schema), כלי אכיפה, ולולאת תיקון אוטומטית שלא מתביישת להגיד למודל “חמוד, תנסה שוב”.

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

למה בכלל המודל “שובר” JSON? 3 סיבות שמפתיעות אנשים

המודל לא “מייצר JSON”. הוא מייצר טקסט שנראה סביר לפי ההקשר. ואם ההקשר מאפשר שפה חופשית—הוא ינצל את זה בכיף.

הסיבות הקלאסיות:

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

המטרה שלנו היא לא “לבקש יפה”. המטרה היא להפסיק להשאיר מקום לפרשנות.

היעד האמיתי: לא JSON יפה – JSON שאי אפשר לשבור

במערכת רצינית, JSON תקין זה מינימום. מה שבאמת חשוב:

• Valid JSON: עובר parser ללא שגיאות
• Valid Schema: עומד ב-JSON Schema/Pydantic/Zod
• Deterministic-ish: אותו קלט → אותה צורה של פלט (גם אם הערכים משתנים)
• No extras: בלי טקסט לפני/אחרי
• Safe defaults: אם מידע חסר, מחזירים null/ברירות מחדל מוסכמות, לא “ניחושים פרועים”

וכדי להגיע לשם, עובדים בשכבות. כמו בצל. רק בלי הדמעות.

שכבה 1: מגדירים חוזה. לא “תביא לי JSON”, אלא “זה המבנה ואין ויכוח”

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

מה עושים במקום? מגדירים Schema רשמי, עם טיפוסים, שדות חובה, ערכי enum, והגבלות. לדוגמה (במילים, לא בקוד):

• object בשם result
• שדות חובה: status, items
• status חייב להיות אחד מ: "ok", "needs_more_info"
• items הוא מערך של אובייקטים; בכל item יש id (string), title (string), confidence (number 0-1)
• אסור שדות נוספים

נקודות קריטיות שחוסכות כאב:

• קבע האם מותר additionalProperties. ברירת מחדל מומלצת: לא.
• תחליט מראש מה עושים כשאין מידע: null? מחרוזת ריקה? שדה חסר? עדיף אחיד וברור.
• תגדיר טווחים: confidence בין 0 ל-1, מספרים חיוביים וכו’.
• תגדיר maxLength כדי למנוע “נאומים” בתוך שדה שאמור להיות קצר.

שכבה 2: “מצב מובנה” של הספק – כשהפלט כבר לא טקסט חופשי

כאן נכנסים הכלים שנותנים 80% מהקסם: Structured Output / JSON mode / response_format / tool calling (השמות משתנים בין ספקים).

הרעיון פשוט: במקום לבקש “תחזיר JSON”, אתה אומר למנוע: הפלט חייב להיות JSON לפי סכמה X. ואז המנוע עצמו אוכף את זה.

בפרקטיקה יש שתי גישות נפוצות:

1) Response format שמחייב JSON

• אתה שולח schema
• המערכת מחזירה אובייקט JSON בלבד
• אין טקסט מסביב

2) Tool calling / function calling

• אתה מגדיר פונקציה עם פרמטרים לפי schema
• המודל “קורא לפונקציה”
• אתה מקבל arguments מובנים

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

שכבה 3: עדיין לא 100%? מוסיפים “שומר סף” שלא מתרגש

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

לכן מוסיפים ולידציה בצד שלך:

• JSON.parse: חובה
• Schema validation: חובה יותר
• אם נכשל → תיקון אוטומטי

וזה הסוד הגדול של 100%: לא לסמוך על פעם אחת. לבנות מנגנון תיקון.

שכבה 4: לולאת תיקון שמחזירה “תנסה שוב” בצורה חכמה (בלי טון עצבני)

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

• הנה ה-JSON שהחזרת (כמו שהוא)
• הנה השגיאה מהוולידטור (בפירוט)
• הנה הסכמה
• תחזיר רק JSON תקין, ללא טקסט נוסף

וכאן טיפ קטן אך חשוב מאוד של אילון אוריאל עדיף להחזיר למודל את הודעת השגיאה המדויקת של ה-validator. זה עושה פלאים.

כללים ללולאת Retry שעובדת:

• 2 נסיונות מספיקים ברוב המקרים (1 תיקון + גיבוי)
• אם עדיין נכשל: תחזיר פלט “safe” (ברירת מחדל) ותסמן status שמבקש השלמה
• לא לשנות את הסכמה באמצע. יציבות = פחות כאוס.

שכבה 5: תכנון הסכמה כך שהמודל יצליח… ולא יתחיל לאלתר

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

• העדף enums קטנים: במקום status חופשי, תן 2–5 אופציות.
• אל תבקש “תאריך במילים”: תן format: "YYYY-MM-DD".
• אל תבקש טקסט ארוך בתוך הסכמה אם לא חייב: טקסט ארוך מעלה סיכוי לשבירה.
• תן דוגמאות של 1–2 מופעים תקינים (אבל לא להעמיס).
• תפריד בין “תשובה למשתמש” לבין “אובייקט לוגי”: אם צריך טקסט למשתמש, שיהיה בשדה ייעודי.

רוצה שהמודל יצליח? תפסיק לתת לו חופש יצירתי במקומות שלא צריכים יצירתיות.

5 טעויות נפוצות שבאמת קל ליפול אליהן (ולצאת מזה בסטייל)

1. “אני אוציא את ה-JSON עם regex”: כמו לנסות לתפוס דג עם מזלג. לפעמים עובד, תמיד מביך. עדיף: לא לקבל טקסט חופשי בכלל.
2. סכמה עם שדות “description” ארוכים מדי: המודל מתחיל לנאום. לשמור קצר.
3. לא לסגור פינות של nullability: אם שדה לא תמיד קיים, להגדיר אם הוא חובה אבל יכול להיות null, או אופציונלי.
4. מפתחות לא עקביים: פעם “userId” פעם “user_id”. המודל יתבלבל. תבחר סגנון אחד.
5. לנסות לתקן JSON “בכוח” בצד הלקוח: יש טריקים של “להוסיף גרש” או “למחוק פסיק”. הם עובדים עד שהם לא. עדיף לתקן דרך המודל עם שגיאת validator, או להשתמש במצב structured מלכתחילה.

קטע פרקטי: מתכון “100%” שעובד בפרודקשן

רוצה מתכון תכל’ס?

• שלב 1: מגדירים JSON Schema קשוח
  • additionalProperties: false
  • required מוגדר
  • enums מוגדרים
  • טווחים מוגדרים
• שלב 2: משתמשים ב-structured output / tool calling
  • מבקשים אובייקט לפי schema
  • מונעים טקסט חופשי
• שלב 3: ולידציה בצד שרת
  • parse + schema validate
• שלב 4: Retry אוטומטי אם נכשל
  • שולחים למודל את השגיאה והפלט הקודם
  • מבקשים “החזר רק JSON תקין”
• שלב 5: Fail-safe
  • אם אחרי 2 ניסיונות עדיין לא תקין (נדיר)
  • מחזירים אובייקט תקין מינימלי עם status שמבקש השלמה/בדיקה

כך אתה מבטיח: תמיד יוצא JSON תקין, גם אם התוכן חלקי.

7 שאלות ותשובות שאנשים שואלים בדיוק בזמן הלא נכון (ואז שמחים שקראו)

• ש: אם אני משתמש ב-JSON mode, אני מסודר ב-100%?
• ת: אתה קרוב מאוד, אבל עדיין חובה לעשות ולידציה בסוף. 100% מגיע משילוב של אכיפה + ולידציה + Retry.
• ש: מה עדיף, tool calling או JSON response format?
• ת: לשימושים “פונקציונליים” (הפעלת פעולה) tool calling מרגיש טבעי. לדאטה טהור, response format עם schema לרוב נקי יותר. שניהם מצוינים אם יש ולידציה.
• ש: למה לא פשוט לבקש “תחזיר רק JSON בלי טקסט”?
• ת: כי “לבקש” זה נחמד. “לאכוף” זה עובד.
• ש: מה לגבי שדות טקסט חופשי ארוכים? זה מגדיל סיכוי לשבירה?
• ת: כן. אם חייבים טקסט ארוך, תן לו שדה ייעודי עם מגבלות, ואל תערבב אותו עם שדות לוגיים שצריכים להיות מדויקים.
• ש: איך מתמודדים עם משתמש שנותן קלט לא ברור?
• ת: תכנן status מסוג "needs_more_info" ושדה questionsToAsk כמערך. ככה הפלט תמיד תקין, והמערכת יודעת לבקש הבהרה.
• ש: אפשר להחזיר מספרים כמחרוזת ואז להמיר?
• ת: אפשר, אבל זה בזבוז. עדיף להגדיר טיפוסים נכון ולתת למודל לעמוד בהם. המרה צריכה להיות חריגה, לא אסטרטגיה.
• ש: כמה שדות מקסימום כדאי לשים בסכמה?
• ת: כמה שצריך, אבל לא “אולימפיאדה”. אם הסכמה נהיית מפלצת, פצלו לאובייקטים מקוננים או לשני שלבים של פלט.

סיכום

כדי להוציא JSON תקין ב-100% מהמקרים צריך להפסיק לקוות שהמודל “יבין למה התכוונת”, ולהתחיל לעבוד עם חוזה קשוח שמאפס את מרחב הפרשנות. סכמה טובה, מצב פלט מובנה, ולידציה עם לולאת תיקון קצרה—וזהו. יש לך מערכת שמחזירה תמיד אובייקט תקין, שנוח לעבד, לשמור, לחפש, ולבנות עליו אוטומציות בלי להתפלל לאלי הפסיקים.