这一直是一个难题，因为LLM具有很大的不确定性，而且如果你用过，你一定会看到类似于以下的输出情况:
- 啰嗦的输出
AI:好的，以下是对问题的json输出:
```json
{"score":"yes"
}
```<eos>
- 形式错误
AI:{'score':'yes'
}显然，一个dict应该用双引号而不是单引号。
有时甚至直接不输出jsonAI:yes
————————————————————————
怎么解决
没什么好办法。说几个弥补的办法。
-
换个prompt
这就纯抽奖了，希望prompt小做改变能输出规范化。 -
二次输出
直接让一次输出兼顾信息抽取和格式规范化，在复杂任务上，7B模型都有点力不从心。所以可以先让LLM用自然语言输出一下分析，第二次再把分析中蕴含的答案变成结构化json。
这不是个好办法。 -
预生成
如果我们规定第一个输出的token是"{"，然后prompt也要求json输出，是否能很好地引导出格式化json？
这是一个很机智的办法，甚至靠这一招还能诱导LLM输出那些它被“教育“不能生成的那些东西。详情看这里。 -
outlines框架
json其实是有很严格的输出结构的，{后面必须是"，第一个"肯定是key的，key之后肯定是 “:”，然后是value。这能写成一个有限状态机。outlines就是靠这个狠狠卡住了输出。不过我不知道如果没卡住要怎么办。我猜是直接在一开始强制生成{"，然后强制不生成"，直到生成一个合法的key，然后再遇到一个"，然后继续强制。如果真是如此，这应该算预生成的进阶了。 -
function call功能
去年openai对此需求的解决办法是function call，智谱也是这样。在langchain里，如果你设定了一个json输出解析器，而且使用了api，你有权选择是用function call生成json还是LLM直接生成。选择不同，具体到openai或者智谱那边形成的prompt也就不同。
function call本质也是一个LLM训练的结构化输出，而且训练得够好，够稳定，比起要求LLM输出json，由function call格式代替然后转变成json更好。本质是使用了LLM功能中完全不同的两个输出规范。
LLM增加的function call功能是在prompt给一个json格式的tools描述，然后告诉llm该调用就调用。llm被训练为在需要call时，先生成一个特殊的function call的前置token，然后生成对应的描述tool调用的json。这个前置token等于一个预填充的引导，但是是由llm自己生成而不是你插手的。如果是你自己本地部署的带function call的模型，你甚至可以预填充一个前置token，两种方法结合，强强联合了属于是。