大模型网摘DeepSeek JSON Structured Output: Field Specs, Examples, and Fallback Rules
Getting a large model to reliably emit JSON is often the first hurdle after wiring up the DeepSeek API: the model clearly understands the task, yet returns prose without code fences, randomizes field names, or tacks on a friendly "Sure, here's the result". The fix isn't mysterious — it comes down to three things: clear field definitions, a concrete example, and explicit fallback rules. DeepSeek's V-series general chat models respond very well to this kind of structured constraint, and even the R-series reasoning models respond better to clear constraints than to elaborate roleplay. Here's how to do it in practice.
Why Field Specs + Examples + Fallbacks Are All Necessary
Just saying "output JSON" is not enough. The model's imagination of fields differs from yours: you ask for price, it gives 金额; you want an array, it gives a string. Field specs remove ambiguity — for each field, state its type, meaning, and whether it's required. Examples align formatting — models are far better at imitating concrete outputs than parsing abstract descriptions. Fallback rules handle exceptions — what to do when information is missing, a field exceeds length limits, or a value falls outside an enum. Together, the three produce a visible jump in parse success rates.
A General-Purpose Template You Can Paste Directly
text
Task: Extract information from the user review below and output JSON.
[Output format requirements]
1. Output exactly one valid JSON object. No explanations, no markdown code fences, no leading or trailing text.
2. Field definitions:
- sentiment: string, required, one of "positive" / "negative" / "neutral"
- keywords: array of string, required, keywords from the review, max 5, in order of appearance
- rating: number, optional, rating mentioned in the review (1-5); omit if not mentioned
- product: string, required, product name; use "unknown" if unclear
3. Fallback rules:
- If required info is missing: keywords = [], product = "unknown". Never fabricate.
- No string field may contain newline characters.
[Output example]
{"sentiment": "positive", "keywords": ["battery life", "screen"], "rating": 5, "product": "X1 Phone"}
[Review to process]
{{user_comment}}
This three-part structure generalizes to most extraction, classification, and tagging tasks — just swap in your own field definitions and example.
Should You Turn On Reasoning Mode?
DeepSeek's R-series deep thinking suits complex reasoning, but simple structured tasks (extraction, classification, format conversion) run faster and more stably on the V-series general model. Rule of thumb: turn on reasoning only when the task requires multi-step inference or multi-condition judgment. For pure format conversion, reasoning mode adds latency and cost, and may even cause the model to "overthink" and append extra content outside the JSON. Also note that R-series responses may include a thinking process — when parsing in code, separate the final answer according to the API's response structure; see official docs for exact fields.
A Complex-Scenario Template with Fallbacks and Batch Processing
text
Task: Parse order texts in batch and output JSON.
[Format constraints]
- The top level must be a single JSON array, one element per order. No text outside the array.
- Element fields:
- order_id: string, required, format like "ORD-2024-001"; null if absent in the text
- items: array of object, required; each element has name(string) and quantity(number)
- total: number, optional, amount as digits only, in yuan; null if undeterminable
- note: string, optional; omit if none
- Fallback rules:
- If one order fails to parse, output {"order_id": null, "items": [], "total": null, "note": "parse_failed"} for that element. Do not abort the whole array.
- If input is empty, output [].
- quantity must be numeric; convert text like "three units" first.
[Output example]
[{"order_id": "ORD-2024-001", "items": [{"name": "keyboard", "quantity": 2}], "total": 598, "note": "rush order"}]
[Text to parse]
{{order_text}}
Pay attention to the rule "a single failed item must not break the whole array" — batch scenarios trip on this constantly. Without it, the model may abandon the entire output or silently change the format over one bad record.
Practical Tips
1. Lower the temperature. Structured output isn't creative writing; lower temperature keeps output converged. See official docs for the parameter range. 2. Defend before parsing: strip possible ``json fences and extract from the first { or [` to the last matching bracket with a lenient routine. 3. Lean on DeepSeek's code strength: pin field names to snake_case in the prompt so downstream consumers don't break. 4. Make fallback values explicit (null, empty array, "unknown"). Never write vague instructions like "decide as appropriate" — the model can't execute those. 5. Make sure your example matches the exact shape of data you want, including field order — the model copies the example's structural habits.
Put these three elements into your system prompt and most JSON output issues get solved at the prompt level — far less painful than patching output with regex afterward. Start from the templates above, run a few dozen real records, then tighten field specs and fallback rules based on failures. Two or three rounds usually get you to production-ready.