大模型的JSON之殇：从脆弱的API调用到稳健的未来
💡
原文中文，约6000字，阅读约需15分钟。
📝
内容提要
大模型在调用外部工具时，生成JSON格式常遇到引号和特殊字符转义问题，影响调用成功。业界发展了提示工程和框架抽象等多层防御策略以提高可靠性，同时探索XML和Multipart协议等替代方案，以解决JSON的缺陷，未来可能实现更稳健的工具调用。
🎯
关键要点
- 大模型在调用外部工具时，生成JSON格式常遇到引号和特殊字符转义问题，影响调用成功。
- LLM与JSON之间的矛盾是概率模型与确定性语法的冲突，LLM难以严格遵守JSON的句法规则。
- 在实践中，LLM生成的JSON常出现格式错误，导致调用失败，开发者需构建复杂的防御机制。
- 业界发展了多层次缓解策略，包括提示工程、框架抽象和生成层面强制执行。
- 提示工程通过明确指令和示例提高模型生成正确格式的概率，但缺乏强制性约束。
- 框架抽象如Semantic Kernel利用C#特性自动生成JSON Schema，简化开发者工作。
- 生成层面强制执行通过约束生成技术确保输出的句法正确性，但可能影响生成内容的自然性。
- 探索替代方案如XML和Multipart协议，XML的CDATA块解决了转义问题，但支持度不如JSON。
- 未来的理想协议可能是混合格式，支持结构化调用和原始文本的分离。
- 模型上下文协议（MCP）旨在标准化LLM与外部工具的交互，促进工具的互操作性。
- 建议.NET开发者使用成熟库简化JSON处理，隔离高风险载荷，实施验证环节，设计简单的原子工具，保持架构灵活性。
❓
延伸问答
大模型在调用外部工具时遇到什么问题？
大模型在生成JSON格式时常遇到引号和特殊字符转义问题，导致调用失败。
如何提高大模型生成JSON的可靠性？
业界发展了多层次缓解策略，包括提示工程、框架抽象和生成层面强制执行。
提示工程在大模型生成JSON中有什么作用？
提示工程通过明确指令和示例提高模型生成正确格式的概率，但缺乏强制性约束。
框架抽象如何帮助.NET开发者处理JSON？
框架抽象如Semantic Kernel利用C#特性自动生成JSON Schema，简化开发者工作。
有哪些替代JSON的方案？
替代方案包括XML和Multipart协议，XML的CDATA块解决了转义问题，但支持度不如JSON。
未来的工具调用协议可能是什么样的？
未来可能实现混合格式的协议，支持结构化调用和原始文本的分离。
➡️
