Почему в Энтакси конфигурация хранится в XML как в оптимальном структурированном формате для ИИ - Entaxy

Зачем вообще думать о формате данных для ИИ

При промышленных внедрениях ИИ главная проблема не «научить модель», а обеспечить стабильный поток качественных, однозначно трактуемых данных. Формат определяет, насколько легко данные валидировать, версионировать, объяснять и адаптировать под разные модели.

Для корпоративного ИИ это критично:

• Нужны строгие схемы и валидация.

• Нужна прозрачность для аудита и безопасности.

• Нужна стабильность интеграций между системами и контурами (DEV/TEST/PROD).

• Нужна возможность, чтобы как люди, так и ИИ‑агенты могли одинаково однозначно читать конфигурацию.

Отсюда вытекает выбор структурированных, формально описываемых форматов.

Лучшие форматы данных для ИИ в промышленной среде

1. XML — строгий структурированный стандарт

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

Ключевые преимущества XML для ИИ‑сценариев:

• Схемы XSD: позволяют задать жёсткую структуру данных, типы, обязательность полей, ограничения; это идеально для проверки входных данных и конфигураций перед запуском пайплайнов ИИ.

• Богатая иерархия и пространства имён: облегчают описания сложных доменных моделей (интеграционные маршруты, политики безопасности, форматы сообщений).

• Отличная совместимость с корпоративным стеком: ESB/ESG, BPM‑системы, брокеры сообщений и многие отечественные решения по‑прежнему нативно поддерживают XML.

Для производственного ИИ это означает меньше неожиданных падений пайплайнов и более предсказуемое поведение моделей.

2. JSON / JSON Schema — для веб‑сервисов и быстрой интеграции

JSON почти стандарт де‑факто для REST‑сервисов и фронтенда, поэтому он широко используется для передачи данных в ИИ‑сервисы и микросервисы.

• Компактен и удобен для логов и телеметрии ИИ‑систем.

• JSON Schema даёт валидацию, но в промышленной практике строгие схемы применяются реже, чем в XML‑мире.

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

Оптимальный сценарий: JSON на границе REST‑API, XML и другие структурированные форматы — внутри платформы.

3. Табличные форматы (CSV/Parquet) для данных обучения

Для данных обучения и аналитики важны не только структура, но и объём:

• CSV — минимально достаточный формат для выгрузок и простых датасетов.

• Паркет/ORC — колоночные форматы для больших объёмов, где работает Spark, ClickHouse, «тяжёлый» ML.

Это хорошие форматы для «сырых» и агрегированных данных, но не для конфигурации или описания сложных интеграционных маршрутов.

4. Domain‑specific XML/JSON форматы

Во многих отраслях в России до сих пор доминируют отраслевые XML‑стандарты: форматы ФНС, ФСС, кадровые и финансовые XML‑структуры. Корпоративный ИИ неизбежно должен уметь:

• Принимать и валидировать данные в этих форматах.

• Трансформировать их во внутренние структуры (например, через XSLT или визуальные мапперы).

• Возвращать результат в тех же регламентированных схемах.

Поэтому «идеальный» набор форматов для промышленного ИИ в России — это комбинация XML‑схем, JSON для REST, табличных форматов для аналитики и специализированных отраслевых XML.

Как структурированные форматы помогают ИИ решать сложные задачи

Почему «структурированность» критична для ИИ в проде

Мощные языковые модели легко работают с неструктурированным текстом, но в промышленной среде это недостаточно:

• Нужны гарантии, что модель не «придумала» поле или не потеряла параметр.

• Нужна возможность автоматически собирать и проверять большие конфигурации.

• Нужна воспроизводимость: из одного и того же XML‑описания система и ИИ‑агент всегда должны получать одинаковое поведение.

Структурированный формат даёт:

• Явную иерархию: ИИ‑агенту проще ориентироваться в дереве элементов и атрибутов, чем в произвольном тексте.

• Однозначные имена и типы полей: это снижает риск ошибок при генерации и модификации конфигураций.

• Проверяемость схемами: любой сгенерированный ИИ конфиг можно автоматически проверить XSD/JSON Schema до развёртывания.

Пример: ИИ‑агент как «конфигуратор маршрута»

Представим сценарий: ИИ‑агент получает запрос «настрой интеграционный маршрут, который раз в час собирает данные из ERP, агрегирует и отправляет в DWH и CRM». Если конфигурация маршрута описана в структуре вида:

• Корневой элемент маршрута (route).

• Вложенные элементы коннекторов, трансформаций, политик.

• Явные ссылки на ресурсы, схемы, параметры безопасности.

ИИ‑агенту достаточно:

• Прочитать XML/JSON‑конфигурацию как дерево.

• Добавить или изменить конкретные элементы (например, новый выходной коннектор, XSLT‑преобразование, политику ретраев).

• Отдать результат обратно в том же формате, который тут же валидируется и разворачивается на платформе.

Такой подход гораздо надёжнее, чем генерация «полутекстовых» инструкций.

Архитектурная ставка Энтакси на XML‑DSL и схемы

В Энтакси конфигурация маршрутов, сервисов и многих системных объектов хранится в XML, что вытекает из архитектуры платформы как корпоративной шины и интеграционной low‑code‑системы.

Ключевые аргументы этого выбора:

• XML‑DSL для интеграционных маршрутов. Маршруты описываются в виде XML‑конфигураций, которые удобно визуализировать (Design) и редактировать как исходный код (Source). Такой подход устоялся в корпоративной интеграции и хорошо знаком архитекторам и разработчикам.
• Пространства имён и кастомные теги. Через собственные XML‑пространства имён и кастомные теги описываются коннекторы, трансформации, политики безопасности, настройки маршрутизации и т.п. Это даёт выразительный язык, понятный и людям, и ИИ‑моделям.
• Хранилище схем и конфигураций. Внутри платформы предусмотрено файловое хранилище схем и конфигурационных ресурсов, где XML‑схемы определяют структуру данных и сообщений, с которыми работают сервисы. Это делает конфигурационное пространство платформы формально описанным и машиночитаемым.

В результате все критичные сущности — от маршрутов до схем сообщений — представлены в одном классе структурированных форматов, которые легко анализировать, генерировать и валидировать.

Архитектура Энтакси уже готова для реализации различных ИИ-сценариев, таких как:

• Модели могут анализировать XML‑маршруты и конфигурации как структурированные деревья, а не как «кусок текста».
• Генерация изменений становится безопаснее: ИИ‑агент оперирует тегами и атрибутами, а не свободной формой.
• Валидация через схемы позволяет автоматически отсеивать некорректные конфигурации, сгенерированные ИИ, ещё до деплоя.

Таким образом архитектура Энтакси изначально спроектированная под хранение конфигурации в XML позволяет и реализовать конфигурационное пространство максимально понятным для людей, и обеспечить отличное восприятие ИИ‑системам, и при этом оставалось строго формализованным.