返回首页

对比阅读

对比阅读:LLM JSON Output Is Messy: A Fault-Tolerant Layer Beats Switching Models 与 大模型 JSON 输出常不规整,容错层比换模型更实际

AEN
Large Language ModelsJSONAgents·

LLM JSON Output Is Messy: A Fault-Tolerant Layer Beats Switching Models

When large language models call tools, their responses may contain code fences, extra commas, or explanatory text, causing systems to fail immediately. The article recommends first attempting standard parsing, then repairing common formatting problems in a fixed order. This is more economical than switching models after a single failure and is better suited to enterprises integrating AI into existing workflows.

What This Is

The fault-tolerant parser described in the article is a layer of software placed between the LLM's output and the business system. It first attempts strict parsing; if that fails, it strips Markdown fences, extracts the JSON body, converts booleans and null values, and removes extra commas, single quotes, and unquoted keys.

The author groups these problems into six categories: code fences, trailing commas, single quotes, Python literals, unquoted keys, and explanatory text before or after the JSON. Their common feature is that the underlying data may not be wrong—it simply does not fully conform to standard JSON.

Industry View

We have noticed that when enterprises adopt Agents—AI systems that can independently plan and call tools to complete tasks—the bottleneck is often not the model's capabilities, but the lack of an adapter layer between model output and software interfaces. A fixed set of lightweight rules is usually more controllable than immediately switching models, and can also reduce call costs and latency.

But fault tolerance is not a universal fix. Regular expressions cannot reliably handle every nested structure; blindly extracting braces may capture the wrong fragment; and automatically adding quotation marks may alter the original meaning. The article's 60 lines of code cover only common cases. Production systems should still preserve the raw output, log anomalies, and perform secondary validation on high-risk fields.

Impact on Regular People

For enterprise IT: Task failures caused by interface formatting can now be reduced by adding validation, retries, and structured output, without attributing every fluctuation to model instability.

For individual professionals: When working with AI, clearly specifying the output format and preserving the original result is still more effective than repeatedly prompting the model. Understanding this can reduce the frustration of getting “correct content” that nevertheless fails to run.

For the consumer market: As AI products connect more frequently to email, spreadsheets, and business systems, minor formatting errors will interrupt workflows less often. However, automatically repairing incorrect instructions can still amplify errors, so critical actions require confirmation steps.

来源: juejin.cn
BZH
大语言模型JSONAgent·

大模型 JSON 输出常不规整,容错层比换模型更实际

大模型调用工具时,返回内容可能夹带代码围栏、多余逗号或说明文字,导致系统直接报错。文章提出先做标准解析,再按固定顺序修复常见格式问题;这比因一次失败就更换模型更经济,也更适合企业将 AI 接入现有流程。

这是什么

文章所说的容错解析器,是放在大模型输出与业务系统之间的一层程序:先尝试严格解析,失败后再去除 Markdown 围栏、提取 JSON 主体、转换布尔值和空值,并清理多余逗号、单引号及未加引号的键。

作者把问题归为六类,包括代码围栏、尾部逗号、单引号、Python 字面量、未加引号的键,以及 JSON 前后夹带说明文字。它们的共同点是,核心数据未必错,只是没有完全符合标准 JSON 格式。

行业怎么看

我们注意到,企业采用 Agent(能自主规划并调用工具完成任务的 AI 系统)时,瓶颈往往不在模型能力,而在模型输出与软件接口之间缺少适配层。固定一组轻量规则,通常比立即更换模型更可控,也能减少调用成本和延迟。

但容错不是万能修复。正则表达式难以可靠处理所有嵌套结构,贸然提取花括号还可能截取错误片段;自动补引号也可能改变原意。文章中的 60 行代码只能覆盖常见情况,生产系统仍应保留原始输出、记录异常,并对高风险字段做二次校验。

对普通人的影响

对企业 IT:过去由接口格式造成的任务失败,现在可以通过增加校验、重试和结构化输出来降低,不必把每次波动都归咎于模型不稳定。

对个人职场:与 AI 协作时,清晰限定输出格式并保留原始结果,仍比反复追问更有效;理解这一点,有助于减少“内容正确却运行失败”的挫败感。

对消费市场:随着 AI 产品更频繁连接邮件、表格和业务系统,轻微格式错误将更少直接打断流程,但错误指令被自动修复后仍可能放大,因此关键操作需要确认环节。

来源: juejin.cn