大模型的结构化输出方法初探

——本文是老码农在本公众号的第666篇原创文字。

几乎所有组织都在尝试使用大模型，可以用大模型回答问题、生成故事、编写代码片段，甚至总结报告。但是有一个问题： 大模型的输出通常是非结构化的。如果要求他们提供 JSON 格式的数据，他们会给出文本和 JSON 的混合体ーー有时候是正确的，有时候是一团糟。

现在，由于它们的不可预测性，大模型一般不能直接用于面向消费者的应用程序，所以我们需要一个更可靠、一致的系统，使其能够应用于生产环境。本文梳理了3 个确保大模型结构化输出的策略。

进一步地，还可以将这一整套流程封装为一个独立的MCP Server，形成一个可复用、易维护、具备工程化能力的标准模块，为后续扩展和集成打下坚实基础。

1. 提示工程

最简单有效的方法就是学会如何提问。提示工程的核心在于精心设计提示词，明确要求 LLM 返回特定的结构化输出（如 JSON 格式）。在提示中清晰地说明所需的输出类型，并结合提示工程技术，添加一个具体的示例，将大大提升模型输出的准确性和可用性。例如，就像下面这个例子所做的那样：

    prompt = """
    Please provide the following information in JSON format:
    Question: What is the capital of France?
    Answer: {"capital": "Paris"}

    Question: What is the population of Japan?
    Answer: {"population": "126.3 million"}
    """

    response = model.generate(prompt)
    print(response)

这种方法在大多数情况下是有效的，能够在不需要额外工具的前提下快速实现结构化输出。然而，大模型本身并非完美，因此这样的系统在实际生产环境中仍存在一定的风险和不确定性。

LLM 的输出本质上是基于概率生成的，它根据输入内容预测最可能的下一个词或符号。即使提示中给出了明确的指令，模型仍有可能因为训练数据中的偏差或推理路径的不同而偏离预期格式。此外，LLM 对提示的措辞和上下文非常敏感，即便是细微的改动，也可能导致输出结果发生显著变化。

这使得该方法在一些非关键性的、实验性质的场景中表现良好，但在面向用户的生产环境中却存在一定隐患。例如，当模型本应返回一个结构清晰的 JSON 数据时，却意外输出了类似 "error": "Oops, I don't understand" 这样的非结构化信息，就可能导致后续流程中断甚至系统报错。

虽然这种方式实现起来简单快捷，也无需引入额外组件，但其在生产环境中的稳定性较弱，输出结果仍有可能偏离预期，因此不适合对可靠性要求较高的应用场景。

2.开源库

为了解决 LLM 输出不稳定和格式不可控的问题，社区中逐渐涌现出一些开源工具库，例如 Instructor、Outlines 和 Guidance。这些库的核心目标是帮助开发者更好地解析或约束大型语言模型的输出，使其符合预设的结构或格式。它们通常提供了一种机制，让我们可以为输出定义模板、规则甚至完整的 Schema，从而提升模型响应的可靠性和一致性。

以 Guidance 为例，它允许我们在提示词中直接嵌入结构化约束，通过特定语法控制输出格式。例如，我们可以在提示中明确指定模型应返回一个 JSON 对象，并对其字段类型、取值范围等进行限定。这种方式在一定程度上提高了输出的可控性，减少了因格式错误而导致解析失败的风险。

Guidance使用示例：

    from guidance import Guidance

    g = Guidance()
    model_output = g.prompt("What is the capital of France?", output_format='json')
    print(model_output)

尽管这些开源库在提升 LLM 输出结构化和可控性方面确实带来了一定的帮助，但它们也并非万能，仍然存在一些明显的局限性。在灵活性方面，它们并不能覆盖所有可能的使用场景。例如，对于深度嵌套的 JSON 结构、复杂的业务逻辑或非常规的数据格式支持不够完善，处理起来往往比较困难，甚至需要额外的适配工作。

另外，引入这类库通常意味着系统复杂度的增加，这可能会带来一定的工程开销。特别是在对依赖项敏感或追求轻量架构的项目中，这种额外的复杂性可能会成为负担，影响系统的可维护性和部署效率。

当然，这些工具也有其明显的优势。相比从零构建一套完整的结构化解析方案，使用现成的库无疑更加便捷，能够显著降低开发门槛和实现成本。对于中等复杂度的任务，它们往往能够在较短时间内提供稳定且可接受的结果，具备不错的实用价值。

3. Regex 和后处理

在对输出精度要求极高的场景下，结合正则表达式进行验证并辅以后处理的策略往往最为有效，尤其是在面向消费者的应用中，这种做法能够显著提升模型响应的可靠性和稳定性。该方法的基本思路是：首先通过提示词引导 LLM 生成结构化的输出格式，然后利用正则表达式对输出内容进行格式校验，以确保其符合预期的模式。

如果模型返回的结果未能通过验证，则系统可以自动触发重试机制，再次调用 LLM 生成新的结果，直到满足设定的条件为止。这种方式能够在不牺牲性能的前提下，大幅提升输出的一致性与准确性。

以下是一个简单的代码示例，用于检查输出中是否包含符合特定要求的数字格式，从而演示这一流程的实际应用方式：

import openai
import re
import json

# Simple regex to check if response contains numbers
number_pattern = r'.*"age":\s*(\d+).*'  # Checks for "age": number pattern


# OpenAI setup
client = openai.OpenAI(api_key="your-api-key")
prompt = "Give me a user profile with name and age"
max_retries = 3
valid_response = None  # Track if we got valid response


# Try getting valid response
for attempt in range(max_retries):
    try:
        response = client.chat.completions.create(
            model="gpt-3.5-turbo",
            messages=[{"role": "user", "content": prompt}]
        )
        result = response.choices[0].message.content

        # Check if response matches our pattern
        if re.match(number_pattern, result, re.DOTALL):
            data = json.loads(result)
            valid_response = data
            print(f"Success on attempt {attempt + 1}:", data)
            break
        else:
            print(f"Attempt {attempt + 1} failed: Age format incorrect")
            prompt = "Make sure age is a number in JSON format"

    except json.JSONDecodeError:
        print(f"Attempt {attempt + 1} failed: Invalid JSON")
        prompt = "Return ONLY valid JSON with age as number"
    except Exception as e:
        print(f"Attempt {attempt + 1} failed:", str(e))

if not valid_response:
    print("All attempts failed to get valid response")

你甚至可以根据具体的业务需求，进一步扩展这套机制，例如通过引入条件判断、循环逻辑等编程结构，使其更具灵活性和适应性。这种方式能够根据不同用例动态调整验证流程和处理策略，从而提升整体系统的智能性和鲁棒性。

之所以选择正则表达式，是因为它赋予了开发者对输出格式的高度控制能力——你可以精确地定义输出的每一个细节，包括字段顺序、标点符号，甚至是空格的使用方式。同时，在面对不符合预期的模型输出时，正则表达式也为我们提供了一种明确的错误识别手段，便于及时触发回退或重试机制，确保最终结果的准确性。

当然，尽管正则表达式功能强大，它也并非没有局限。一方面，对于结构复杂、层级嵌套较深的数据格式来说，编写和维护对应的正则规则可能会变得非常困难；另一方面，为了不断修正输出而频繁调用 LLM，也会带来额外的性能开销和成本负担。

这种方案的优势在于其高可靠性，能够确保输出严格符合预设的格式要求，非常适合对数据一致性有强约束的场景。但与此同时，它也增加了开发和调试的复杂度，并可能引入多次模型调用所带来的延迟问题。因此，在实际应用中，需要根据项目目标与资源限制进行综合考量，权衡是否采用这一策略。

4. 小结

关键在于找到合适的平衡点。在某些情况下，最简单的方法可能就足以获得理想的输出；而在更复杂的场景中，可能需要将多种策略结合起来使用。以下是对本文所讨论的三种关键技术的简要总结：

• 提示工程是最直接、最容易实现的方式，适用于结构要求不高的简单用例，但它无法完全避免模型输出的不确定性。
• 开源库为结构化输出提供了更稳定的解决方案，能够在一定程度上提升输出的一致性与可解析性，但其灵活性往往受限于库本身的实现机制和规则设定。
• 正则表达式配合后处理机制，则能在对精度要求极高的场景下提供最强的保障，确保输出严格符合预期格式。然而，这种方式通常伴随着更高的开发复杂度和更多的模型调用成本。

对于构建生产级别的系统而言，通常最优的做法是采用组合策略：从一个清晰、结构良好的提示出发，借助解析库进行初步处理，并通过正则验证等手段对关键输出进行兜底校验，从而兼顾效率与可靠性。