מפתחים יכולים כעת להבטיח שה-JSON ש-LLM מחזיר תואם למבנה מוגדר מראש על ידי חיבור סכמות Zod ל-Vercel AI SDK או ל-Anthropic’s tool-use API, מה שמונע קריסות בזמן ריצה שמתרחשות כאשר מודל מוסיף שדה לא צפוי.
הצורך במנגנון הגנה קונקרטי הפך ברור בינואר, כאשר מסווג (classifier) שנשלח לסביבת ייצור (production) החל להחזיר מפתח "explanation" שני לאחר שלושה שבועות של פעולה ללא תקלות. הקוד ציפה לשדה בודד, ולכן המפתח הנוסף גרם לחריגה (exception) — מבלי שבוצע פריסה (deploy) חדשה של הקוד. האירוע ממחיש בעיה רחבה יותר: רוב המדריכים עוצרים ב-JSON.parse(response), מתוך הנחה שהמודל יצוית לסכמה של הפרומפט. במציאות, LLMs נוטים לעיתים קרובות לסטות — משנים את ה-casing, מוסיפים שדות, או עוטפים את הפלט ב-markdown fences — מה שמוביל לשיבוש נתונים שקט או לכשלים מוחלטים.
למה ניתוח (parsing) JSON גולמי אינו בטוח
LLMs מאומנים להיות מועילים, לא צייתנים. פרומפט שמבקש
{ "category": "string" }
אינו מחייב את המודל למבנה המדויק הזה. אפילו פרומפט שנכתב היטב יכול להידרס על ידי ההיוריסטיקה הפנימית של המודל, במיוחד כאשר הגדרת ה-temperature מעודדת יצירתיות או כאשר הוראה בהמשך (downstream) דוחפת אותו להרחיב. התוצאה היא זרם של טקסט שנראה כמו JSON אך סוטה מספיק כדי לשבור מנתחים (parsers) שמצפים למבנה קשיח.
כאשר חוסר התאמה כזה מגיע לקוד בייצור, המחיר הוא מיידי: חריגה (exception) שמושלכת, בקשה שנכשלה, ופוטנציאל לשרשרת של שגיאות בהמשך. בשירותים גדולים, דקות של זמן השבתה מתרגמות לאובדן הכנסות ולפגיעה באמון המשתמשים.
Zod + Vercel AI SDK: רשת ביטחון בת שלושה שלבים
Zod הוא מאמת סכמות (schema validator) מבוסס TypeScript שיכול לתאר את מבנה הנתונים המדויק שהמודל אמור להפיק. בשילוב עם ה-helper Output.object של Vercel AI SDK, האימות מתבצע באופן אוטומטי לאחר שהמודל מייצר את תגובתו.
- הגדרת הסכמה – כתיבת אובייקט Zod המשקף את ה-JSON הרצוי. עבור מסווג פשוט זה עשוי להיות
z.object({ category: z.string() }); עבור מחלץ חשבוניות מורכב, הסכמה יכולה לכלול אובייקטים מקוננים, מערכים ו-discriminated unions. - העברה ל-SDK – עטיפת הסכמה באמצעות
Output.object(schema). ה-SDK מזריק פרומפט שאומר למודל להפיק בלוק JSON התואם לסכמה ומנתח את התוצאה באמצעותsafeParseשל Zod. - טיפול בכשלים –
safeParseמחזיר אובייקט תוצאה במקום לזרוק שגיאה. אם הניתוח נכשל, הזינו את השגיאה חזרה למודל ונסו שוב. ניתן להנחות את המודל לתקן את הפלט על בסיס הודעת האימות המדויקת, ובכך להפוך את רוב מקרי הקצה ללולאת תיקון עצמי (self-healing loop).
מכיוון שה-SDK מבצע את הפרומפטינג, הניתוח (parsing) ולוגיקת הניסיון החוזר במקום אחד, מפתחים מחליפים מספר מניפולציות מחרוזת אד-הוק בקריאה אחת שעברה בדיקת טיפוסים (type-checked).
שימוש בכלי (tool use) של Anthropic: כפיית פלט מובנה
בעבודה ישירה עם ה-API של Anthropic, ניתן להשיג את אותה הבטחה באמצעות "שימוש בכלים" (tool use). כלי מוגדר כפונקציה שסכמת הקלט שלה מבוטאת ב-JSON Schema; המודל של Anthropic יקרא לכלי רק אם הוא יכול לספק את הסכמה. על ידי הגדרת tool_choice ל-"any" (או שם של כלי ספציפי), המודל נאלץ להחזיר בלוק מובנה במקום טקסט חופשי.
זרימת העבודה משקפת את הגישה של Vercel:
- כתיבת סכמת Zod.
- המרתה ל-payload של JSON Schema עבור הגדרת הכלי.
- הכללת הכלי בבקשה ודרישה מהמודל להפעיל אותו.
- ניתוח תגובת הכלי באמצעות
zod.safeParse.
אם המודל עדיין מייצר נתונים לא תקינים, אותו דפוס של ניסיון חוזר עם משוב (retry-with-feedback) תקף גם כאן.
כאשר האימות עדיין נכשל
גם עם אכיפת סכמה, מתרחשים לעיתים חוסר התאמות. הסיבות כוללות:
- הזיות מודל (Model hallucination): המודל עשוי לייצר מחרוזת שנראית כמו JSON אך מכילה שגיאות תחביר.
- דליפת פרומפט (Prompt leakage): סבבי שיחה קודמים עלולים לדלוף הוראות פורמט שדורסות את בקשת הסכמה.
- הבדלי גרסאות: גרסאות חדשות יותר של מודלים משנות לעיתים את האופן שבו הן מפרשות קריאות לכלים.
הפתרון המומלץ הוא לולאת ניסיון חוזר (retry loop) קלה. במקרה של כשל בניתוח, הקוד שולח פרומפט המשך כגון: "הפלט האחרון שלך לא היה JSON תקין. הוא הכיל... אנא החזר רק את השדות המוגדרים בסכמה." מכיוון ששגיאת האימות היא מפורשת, המודל יכול לתקן את עצמו ללא התערבות אנושית.
שיקולי ביצועים ועלות
Adding Zod validation introduces negligible CPU overhead—the safeParse operation runs in microseconds for typical payloads. Network latency is unchanged; the extra round-trip for a retry only occurs on the rare failure case. In practice, the cost of a single prevented exception far outweighs the marginal increase in request time.
Counter-argument: is schema enforcement overkill?
Some developers argue that strict schemas limit the model’s flexibility, especially when new fields could provide valuable context. The trade-off is between safety and openness. In mission-critical services—payment processing, identity verification, compliance reporting—predictability wins. In exploratory prototypes, a looser approach may be acceptable, but even there a minimal guard (e.g., z.object({}).passthrough()) can catch catastrophic parsing errors without discarding useful extensions.
What to watch next
- SDK evolution: Vercel’s AI SDK roadmap includes built-in retry policies and richer error reporting, which will streamline the repair loop further.
- Tooling standardization: As more providers adopt tool-use conventions, cross-provider schema validators could emerge, reducing the need for provider-specific adapters.
- Community patterns: Open-source libraries are beginning to bundle Zod schemas with prompt templates, making the “schema-first” workflow a reusable asset.
Takeaway
By treating a Zod schema as a contract that the model cannot break, developers move from fragile JSON.parse hacks to a deterministic pipeline where unexpected fields cause a controlled validation failure, not a production crash. The combination of Vercel’s Output.object helper and Anthropic’s tool-use mechanism turns LLMs from unpredictable text generators into reliable data providers, letting teams focus on business logic instead of endless edge-case debugging.