ਡਿਵੈਲਪਰ ਹੁਣ ਇਹ ਗਾਰੰਟੀ ਦੇ ਸਕਦੇ ਹਨ ਕਿ LLM ਦੁਆਰਾ ਰਿਟਰਨ ਕੀਤਾ ਗਿਆ JSON ਇੱਕ ਪਹਿਲਾਂ ਤੋਂ ਨਿਰਧਾਰਤ ਸ਼ੇਪ (shape) ਦੇ ਅਨੁਕੂਲ ਹੈ। ਇਸ ਲਈ ਉਹ Zod schemas ਨੂੰ Vercel AI SDK ਜਾਂ Anthropic ਦੇ tool-use API ਨਾਲ ਜੋੜ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਉਹ runtime crashes ਖਤਮ ਹੋ ਜਾਂਦੇ ਹਨ ਜੋ ਉਦੋਂ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਕੋਈ ਮਾਡਲ ਕੋਈ ਅਣਚਾਹਿਆ ਫੀਲਡ ਜੋੜ ਦਿੰਦਾ ਹੈ।

ਜਨਵਰੀ ਵਿੱਚ ਇੱਕ ਪੱਕੇ ਗਾਰਡ (guard) ਦੀ ਲੋੜ ਸਾਫ਼ ਹੋ ਗਈ, ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਭੇਜੀ ਗਈ ਇੱਕ ਕਲਾਸੀਫਾਇਰ (classifier) ਤਿੰਨ ਹਫ਼ਤਿਆਂ ਦੇ ਨਿਰਵਿਘਨ ਕੰਮ ਤੋਂ ਬਾਅਦ ਦੂਜੀ “explanation” key ਰਿਟਰਨ ਕਰਨ ਲੱਗੀ। ਕੋਡ ਨੇ ਸਿਰਫ਼ ਇੱਕ ਫੀਲਡ ਦੀ ਉਮੀਦ ਕੀਤੀ ਸੀ, ਇਸ ਲਈ ਵਾਧੂ key ਨੇ ਇੱਕ exception ਨੂੰ ਟ੍ਰਿਗਰ ਕਰ ਦਿੱਤਾ—ਇੱਕ ਵੀ ਕੋਡ ਡਿਪਲਾਈ ਕੀਤੇ ਬਿਨਾਂ। ਇਹ ਘਟਨਾ ਇੱਕ ਵੱਡੀ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ: ਜ਼ਿਆਦਾਤਰ ਟਿਊਟੋਰਿਅਲ JSON.parse(response) 'ਤੇ ਹੀ ਰੁਕ ਜਾਂਦੇ ਹਨ, ਇਹ ਮੰਨ ਕੇ ਕਿ ਮਾਡਲ ਪ੍ਰੋਂਪਟ ਦੇ schema ਦੀ ਪਾਲਣਾ ਕਰੇਗਾ। ਅਸਲ ਵਿੱਚ, LLMs ਅਕਸਰ ਭਟਕ ਜਾਂਦੇ ਹਨ—casing ਬਦਲਣਾ, ਫੀਲਡਾਂ ਜੋੜਨਾ, ਜਾਂ ਆਉਟਪੁੱਟ ਨੂੰ markdown fences ਵਿੱਚ ਲਪੇਟਣਾ—ਜਿਸ ਨਾਲ ਚੁੱਪਚਾਪ ਡਾਟਾ ਕਰੱਪਸ਼ਨ ਜਾਂ ਸਿੱਧੀਆਂ ਅਸਫਲਤਾਵਾਂ ਹੁੰਦੀਆਂ ਹਨ।

ਰਅਅ (raw) JSON ਪਾਰਸਿੰਗ ਕਿਉਂ ਅਸੁਰੱਖਿਅਤ ਹੈ

LLMs ਨੂੰ ਮਦਦਗਾਰ ਬਣਨ ਲਈ ਸਿਖਾਇਆ ਜਾਂਦਾ ਹੈ, ਆਗਿਆਕਾਰੀ ਨਹੀਂ। ਇੱਕ ਪ੍ਰੋਂਪਟ ਜੋ

{ "category": "string" }

ਦੀ ਮੰਗ ਕਰਦਾ ਹੈ, ਉਹ ਮਾਡਲ ਨੂੰ ਉਸ ਬਿਲਕੁਲ ਸਹੀ ਸਟ੍ਰਕਚਰ ਨਾਲ ਨਹੀਂ ਬੰਨ੍ਹਦਾ। ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਲਿਖਿਆ ਗਿਆ ਪ੍ਰੋਂਪਟ ਵੀ ਮਾਡਲ ਦੇ ਅੰਦਰੂਨੀ heuristics ਦੁਆਰਾ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ temperature setting ਰਚਨਾਤਮਕਤਾ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੀ ਹੈ ਜਾਂ ਜਦੋਂ ਕੋਈ downstream instruction ਇਸਨੂੰ ਵਿਸਥਾਰ ਦੇਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀ ਹੈ। ਨਤੀਜਾ ਟੈਕਸਟ ਦੀ ਇੱਕ ਅਜਿਹੀ ਧਾਰਾ ਹੁੰਦੀ ਹੈ ਜੋ JSON ਵਾਂਗ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਪਰ ਇੰਨੀ ਵੱਖਰੀ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ parsers ਨੂੰ ਤੋੜ ਦਿੰਦੀ ਹੈ ਜੋ ਇੱਕ ਸਖ਼ਤ ਸ਼ੇਪ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਨ।

ਜਦੋਂ ਅਜਿਹਾ ਮਿਸਮੈਚ (mismatch) ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਨੁਕਸਾਨ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ: ਇੱਕ exception ਆਉਣਾ, ਇੱਕ ਫੇਲ ਹੋਈ ਰਿਕਵੈਸਟ, ਅਤੇ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ downstream errors ਦੀ ਲੜੀ। ਵੱਡੀਆਂ ਸਰਵਿਸਾਂ ਵਿੱਚ, ਡਾਊਨਟਾਈਮ ਦੇ ਉਹ ਮਿੰਟ ਘਟਦੇ ਹੋਏ ਮਾਲੀਏ ਅਤੇ ਘਟਦੇ ਹੋਏ ਯੂਜ਼ਰ ਵਿਸ਼ਵਾਸ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।

Zod + Vercel AI SDK: ਤਿੰਨ-ਸਟੈਪ ਸੇਫਟੀ ਨੈੱਟ

Zod ਇੱਕ TypeScript-first schema validator ਹੈ ਜੋ ਉਸ ਸਹੀ ਡਾਟਾ ਸ਼ੇਪ ਦਾ ਵਰਣਨ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਇੱਕ ਮਾਡਲ ਨੂੰ ਜਾਰੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। Vercel AI SDK ਦੇ Output.object helper ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਮਾਡਲ ਦੁਆਰਾ ਆਪਣਾ ਰਿਸਪਾਂਸ ਜਨਰੇਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਵੈਲੀਡੇਸ਼ਨ ਆਪਣੇ ਆਪ ਹੋ ਜਾਂਦੀ ਹੈ।

  1. Schema ਨੂੰ ਡਿਫਾਈਨ ਕਰੋ – ਇੱਕ Zod object ਲਿਖੋ ਜੋ ਲੋੜੀਂਦੇ JSON ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੋਵੇ। ਇੱਕ ਸਧਾਰਨ ਕਲਾਸੀਫਾਇਰ ਲਈ ਇਹ z.object({ category: z.string() }) ਹੋ ਸਕਦਾ ਹੈ; ਇੱਕ ਗੁੰਝਲਦਾਰ ਇਨਵੌਇਸ ਐਕਸਟ੍ਰੈਕਟਰ (invoice extractor) ਲਈ schema ਵਿੱਚ objects, arrays, ਅਤੇ discriminated unions ਨੂੰ ਨੇਸਟ (nest) ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
  2. ਇਸਨੂੰ SDK ਨੂੰ ਪਾਸ ਕਰੋ – schema ਨੂੰ Output.object(schema) ਨਾਲ ਲਪੇਟੋ (wrap)। SDK ਇੱਕ ਪ੍ਰੋਂਪਟ ਇੰਜੈਕਟ ਕਰਦਾ ਹੈ ਜੋ ਮਾਡਲ ਨੂੰ schema ਨਾਲ ਮੇਲ ਖਾਂਦਾ JSON ਬਲਾਕ ਆਉਟਪੁੱਟ ਕਰਨ ਲਈ ਕਹਿੰਦਾ ਹੈ ਅਤੇ Zod ਦੇ safeParse ਨਾਲ ਨਤੀਜੇ ਨੂੰ ਪਾਰਸ ਕਰਦਾ ਹੈ।
  3. ਫੇਲਯਰਾਂ ਨੂੰ ਸੰਭਾਲੋ – safeParse exception throw ਕਰਨ ਦੀ ਬਜਾਏ ਇੱਕ result object ਰਿਟਰਨ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਪਾਰਸਿੰਗ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਗਲਤੀ (error) ਨੂੰ ਮਾਡਲ ਨੂੰ ਵਾਪਸ ਭੇਜੋ ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ (retry) ਕਰੋ। ਮਾਡਲ ਨੂੰ ਸਹੀ ਵੈਲੀਡੇਸ਼ਨ ਮੈਸੇਜ ਦੇ ਅਧਾਰ 'ਤੇ ਆਉਟਪੁੱਟ ਨੂੰ ਸੁਧਾਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਦਿੱਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਜ਼ਿਆਦਾਤਰ edge cases ਇੱਕ self-healing loop ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ।

ਕਿਉਂਕਿ SDK ਪ੍ਰੋਂਪਟਿੰਗ, ਪਾਰਸਿੰਗ, ਅਤੇ retry logic ਨੂੰ ਇੱਕੋ ਥਾਂ 'ਤੇ ਕਰਦਾ ਹੈ, ਡਿਵੈਲਪਰ ਕੁਝ ad-hoc string manipulations ਦੀ ਬਜਾਏ ਇੱਕ ਸਿੰਗਲ, type-checked ਕਾਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

Anthropic tool use: structured output ਲਈ ਮਜਬੂਰ ਕਰਨਾ

ਜਦੋਂ ਸਿੱਧੇ ਤੌਰ 'ਤੇ Anthropic ਦੇ API ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋਵੋ, ਤਾਂ ਉਹੀ ਗਾਰੰਟੀ "tool use" ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਇੱਕ tool ਨੂੰ ਇੱਕ ਫੰਕਸ਼ਨ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸਦਾ input schema JSON Schema ਵਿੱਚ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ; Anthropic ਦਾ ਮਾਡਲ tool ਨੂੰ ਉਦੋਂ ਹੀ ਕਾਲ ਕਰੇਗਾ ਜੇਕਰ ਇਹ schema ਨੂੰ ਪੂਰਾ ਕਰ ਸਕਦਾ ਹੈ। tool_choice ਨੂੰ "any" (ਜਾਂ ਕਿਸੇ ਖਾਸ tool ਦੇ ਨਾਮ) 'ਤੇ ਸੈੱਟ ਕਰਕੇ, ਮਾਡਲ ਨੂੰ free-form text ਦੀ ਬਜਾਏ ਇੱਕ structured ਬਲਾਕ ਰਿਟਰਨ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਵਰਕਫਲੋ (workflow) Vercel ਦੇ ਤਰੀਕੇ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ:

  • ਇੱਕ Zod schema ਲਿਖੋ।
  • tool definition ਲਈ ਇਸਨੂੰ JSON Schema payload ਵਿੱਚ ਬਦਲੋ।
  • ਰਿਕਵੈਸਟ ਵਿੱਚ tool ਨੂੰ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਮਾਡਲ ਨੂੰ ਇਸਨੂੰ ਇਵੋਕ (invoke) ਕਰਨ ਲਈ ਕਹੋ।
  • zod.safeParse ਨਾਲ tool ਦੇ ਰਿਸਪਾਂਸ ਨੂੰ ਪਾਰਸ ਕਰੋ।

ਜੇਕਰ ਮਾਡਲ ਫਿਰ ਵੀ ਗਲਤ (malformed) ਡਾਟਾ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਤਾਂ ਉਹੀ retry-with-feedback ਪੈਟਰਨ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

ਜਦੋਂ ਵੈਲੀਡੇਸ਼ਨ ਫਿਰ ਵੀ ਫੇਲ ਹੋ ਜਾਂਦੀ ਹੈ

Schema enforcement ਦੇ ਬਾਵਜੂਦ, ਕਦੇ-ਕਦੇ ਮਿਸਮੈਚ ਹੁੰਦੇ ਹਨ। ਕਾਰਨਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:

  • Model hallucination: ਮਾਡਲ ਇੱਕ ਅਜਿਹੀ string ਬਣਾ ਸਕਦਾ ਹੈ ਜੋ JSON ਵਾਂਗ ਦਿਖਦੀ ਹੈ ਪਰ ਉਸ ਵਿੱਚ syntax errors ਹੁੰਦੇ ਹਨ।
  • Prompt leakage: ਪਿਛਲੇ ਗੱਲਬਾਤ ਦੇ ਮੋੜ (conversation turns) ਫਾਰਮੈਟਿੰਗ ਹਦਾਇਤਾਂ ਨੂੰ ਲੀਕ ਕਰ ਸਕਦੇ ਹਨ ਜੋ schema ਦੀ ਬੇਨਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦੀਆਂ ਹਨ।
  • Version differences: ਨਵੇਂ ਮਾਡਲ ਰਿਲੀਜ਼ ਕਦੇ-ਕਦੇ ਇਸ ਤਰੀਕੇ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ ਕਿ ਉਹ tool calls ਨੂੰ ਕਿਵੇਂ ਇੰਟਰਪ੍ਰੇਟ ਕਰਦੇ ਹਨ।

ਸਿਫਾਰਸ਼ ਕੀਤੀ ਗਈ ਰੋਕਥਾਮ (mitigation) ਇੱਕ ਹਲਕਾ (lightweight) retry loop ਹੈ। ਪਾਰਸ ਫੇਲ ਹੋਣ 'ਤੇ

Zod validation ਜੋੜਨ ਨਾਲ CPU overhead ਬਹੁਤ ਹੀ ਘੱਟ ਹੁੰਦਾ ਹੈ—ਆਮ payloads ਲਈ safeParse operation ਮਾਈਕ੍ਰੋਸੈਕਿੰਡਾਂ ਵਿੱਚ ਚੱਲਦਾ ਹੈ। Network latency ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਆਉਂਦਾ; retry ਲਈ ਵਾਧੂ round-trip ਸਿਰਫ਼ ਦੁਰਲੱਭ ਅਸਫਲਤਾ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੀ ਹੁੰਦਾ ਹੈ। ਅਸਲ ਵਿੱਚ, ਇੱਕ ਅਸਫਲਤਾ (exception) ਨੂੰ ਰੋਕਣ ਦੀ ਕੀਮਤ, request time ਵਿੱਚ ਹੋਣ ਵਾਲੇ ਮਾਮੂਲੀ ਵਾਧੇ ਨਾਲੋਂ ਕਿਤੇ ਜ਼ਿਆਦਾ ਫਾਇਦੇਮੰਦ ਹੈ।

ਵਿਰੋਧੀ ਦਲੀਲ: ਕੀ schema enforcement ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ?

ਕੁਝ ਡਿਵੈਲਪਰਾਂ ਦਾ ਤਰਕ ਹੈ ਕਿ ਸਖ਼ਤ schemas ਮਾਡਲ ਦੀ ਲਚਕਤਾ (flexibility) ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਨਵੇਂ fields ਕੀਮਤੀ ਸੰਦਰਭ (context) ਪ੍ਰਦਾਨ ਕਰ ਸਕਦੇ ਹਨ। ਇਹ ਸੁਰੱਖਿਆ ਅਤੇ ਖੁੱਲ੍ਹੇਪਣ (openness) ਵਿਚਕਾਰ ਇੱਕ ਸਮਝੌਤਾ ਹੈ। ਮਿਸ਼ਨ-ਕ੍ਰਿਟੀਕਲ ਸੇਵਾਵਾਂ—ਜਿਵੇਂ ਕਿ payment processing, identity verification, compliance reporting—ਵਿੱਚ ਭਵਿੱਖਬਾਣੀਯੋਗਤਾ (predictability) ਜਿੱਤਦੀ ਹੈ। ਖੋਜਾਤਮਕ ਪ੍ਰੋਟੋਟਾਈਪਸ (exploratory prototypes) ਵਿੱਚ, ਇੱਕ ਢਿੱਲੀ ਪਹੁੰਚ ਸਵੀਕਾਰਯੋਗ ਹੋ ਸਕਦੀ ਹੈ, ਪਰ ਉੱਥੇ ਵੀ ਇੱਕ ਨਿਗਰਾਨੀ (e.g., z.object({}).passthrough()) ਮਹੱਤਵਪੂਰਨ extensions ਨੂੰ ਖਤਮ ਕੀਤੇ ਬਿਨਾਂ ਭਿਆਨਕ parsing errors ਨੂੰ ਫੜ ਸਕਦੀ ਹੈ।

ਅੱਗੇ ਕੀ ਦੇਖਣਾ ਹੈ

  • SDK evolution: Vercel ਦੇ AI SDK roadmap ਵਿੱਚ built-in retry policies ਅਤੇ ਬਿਹਤਰ error reporting ਸ਼ਾਮਲ ਹੈ, ਜੋ repair loop ਨੂੰ ਹੋਰ ਸੁਚਾਰੂ ਬਣਾਏਗੀ।
  • Tooling standardization: ਜਿਵੇਂ-ਜਿਵੇਂ ਵਧੇਰੇ providers tool-use conventions ਨੂੰ ਅਪਣਾਉਂਦੇ ਹਨ, cross-provider schema validators ਸਾਹਮਣੇ ਆ ਸਕਦੇ ਹਨ, ਜਿਸ ਨਾਲ provider-specific adapters ਦੀ ਲੋੜ ਘਟ ਜਾਵੇਗੀ।
  • Community patterns: Open-source libraries ਹੁਣ prompt templates ਦੇ ਨਾਲ Zod schemas ਨੂੰ ਬੰਡਲ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੀਆਂ ਹਨ, ਜਿਸ ਨਾਲ “schema-first” workflow ਇੱਕ ਮੁੜ ਵਰਤੋਂਯੋਗ (reusable) ਸੰਪਤੀ ਬਣ ਰਹੀ ਹੈ।

ਮੁੱਖ ਨੁਕਤਾ

Zod schema ਨੂੰ ਇੱਕ ਅਜਿਹੇ ਇਕਰਾਰਨਾਮੇ (contract) ਵਜੋਂ ਮੰਨ ਕੇ ਜਿਸ ਨੂੰ ਮਾਡਲ ਤੋੜ ਨਹੀਂ ਸਕਦਾ, ਡਿਵੈਲਪਰ ਕਮਜ਼ੋਰ JSON.parse hacks ਤੋਂ ਇੱਕ ਨਿਸ਼ਚਿਤ (deterministic) pipeline ਵੱਲ ਵਧਦੇ ਹਨ ਜਿੱਥੇ ਅਣਪਛਾਤੇ fields ਕਾਰਨ ਇੱਕ ਨਿਯੰਤਰਿਤ validation failure ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ production crash। Vercel ਦੇ Output.object helper ਅਤੇ Anthropic ਦੇ tool-use mechanism ਦਾ ਸੁਮੇਲ LLMs ਨੂੰ ਅਨਿਸ਼ਚਿਤ text generators ਤੋਂ ਭਰੋਸੇਯੋਗ data providers ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਟੀਮਾਂ ਅੰਤਹੀਣ edge-case debugging ਦੀ ਬਜਾਏ business logic 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰ ਸਕਦੀਆਂ ਹਨ।