Как избавиться от «кривого» JSON, генерируемого LLM, без регексов

Проблема: LLM‑модели почти никогда не отдают корректный JSON

Большинство проектов, работающих с языковыми моделями (обёртки AI, RAG‑конвейеры, агентные системы), сталкиваются с одной и той же ошибкой – полученный от модели текст не проходит парсинг. Даже если использовать режим JSON от OpenAI или формулировать строгие системные подсказки, в продакшене модель часто добавляет лишние запятые, использует одинарные кавычки вместо двойных, забывает закрывающие скобки или полностью опускает обязательные поля. При попытке выполнить JSON.parse(llmOutput) в Node‑приложении такой «мусор» приводит к падению потока Express‑сервера и, как следствие, к потере данных.

Почему «регекс‑патч» не спасает

Первой реакцией разработчика обычно становится написание функции‑фильтра:

1. Удалить блоки маркдауна json
2. С помощью регулярных выражений убрать конечные запятые
3. Попробовать распарсить строку в try / catch

Эта схема работает лишь в простейших случаях. Как только модель генерирует вложенный объект внутри массива, пропускает обязательный ключ, меняет порядок элементов или добавляет несколько синтаксических ошибок, обычный регекс уже не способен восстановить структуру. В итоге либо происходит исключение, либо данные отбрасываются и требуется повторный запрос к модели, что удорожает процесс токенами.

Архитектурный подход: слой надёжности для JSON

Для решения проблемы был создан отдельный сервис‑прокси, который принимает «сломанный» JSON, автоматически исправляет его и проверяет соответствие заданной схеме. Основные элементы решения:

• llm-json-guard – небольшая библиотека, доступная в npm и PyPI, предназначенная для интеграции в любой бекенд.
• RapidAPI‑бэкенд – высокопроизводительный эндпоинт LLM JSON Sanitizer & Schema Guard, развёрнутый в облаке, где происходит фактическая обработка строки.
• Схема валидации – JSON‑Schema, описывающая ожидаемую структуру данных (типы полей, обязательные свойства, ограничения).

В результате поток данных выглядит так:

LLM → llm-json-guard → RapidAPI‑sanitizer → проверка схемы → бизнес‑логика

Таким образом, парсинг и валидация происходят до того, как строка попадёт в основной серверный процесс, и любые ошибки фиксируются в отдельном, изолированном контексте.

Интеграция в Express: минимум кода, максимум надёжности

Библиотека спроектирована как middleware для Express, что позволяет подключить её одной строкой. Примерный код выглядит так:

import express from "express";
import { LLMJsonGuard } from "llm-json-guard";

const app = express();
app.use(express.json());

// Middleware, который «чистит» ответ модели
app.post("/ai/endpoint", LLMJsonGuard({
  // JSON‑Schema, с которой будет сверяться результат
  schema: {
    type: "object",
    properties: {
      id: { type: "string" },
      title: { type: "string" },
      price: { type: "number" }
    },
    required: ["id", "title", "price"]
  },
  // опционально: таймаут и количество повторных попыток
  timeout: 2000,
  retries: 2
}), (req, res) => {
  // На этом этапе req.body уже гарантированно корректный JSON
  const data = req.body;
  // Дальнейшая бизнес‑логика (запись в PostgreSQL, кэш и т.д.)
  res.json({ status: "ok", payload: data });
});

app.listen(3000, () => console.log("Server started on :3000"));

Как видно, после подключения LLMJsonGuard в req.body уже находится полностью исправленный и валидированный объект. При возникновении необратимых ошибок (например, отсутствует обязательный ключ, который нельзя добавить автоматически) middleware генерирует ответ с кодом 400 и подробным описанием проблемы, позволяя клиенту решить её без повторных запросов к модели.

Преимущества подхода

Как расширять решение

1. Поддержка разных языков – библиотека уже публикуется в PyPI, что упрощает её использование в Python‑стеке (FastAPI, Django).
2. Кастомные стратегии исправления – API позволяет задать собственные функции‑постпроцессоры, если требуется специфическая логика (например, преобразование дат в ISO‑формат).
3. Мониторинг и метрики – интеграция с Prometheus или Grafana через middleware‑обёртку даёт видимость количества исправленных сообщений и частоты сбоев схемы.
4. Кеширование – часто повторяющиеся запросы к LLM JSON Sanitizer могут кэшироваться на уровне CDN, что уменьшит нагрузку и стоимость.

Итоги

Проблема «неправильного JSON от LLM» решается не цепочкой хрупких регулярных выражений, а отдельным уровнем, который изолирует парсинг и валидацию от основной бизнес‑логики. Использование готового SDK llm-json-guard и облачного сервиса RapidAPI позволяет быстро добавить надёжный слой защиты в любой проект, работающий с генеративным ИИ, и сосредоточиться на бизнес‑ценности, а не на постоянных исправлениях синтаксиса.