Формат данных важнее модели: как XML‑конфигурации спасают промышленные ИИ‑проекты
В большинстве разговоров про ИИ внимание забирают модели. Какую выбрать, насколько она «умная», сколько параметров, какой контекст. Но в промышленных проектах всё чаще выясняется неприятный факт: ломается не модель, ломается среда, в которой она живёт.
И очень часто корень проблемы не там, где его ищут. Не в «слабой нейросети», а в том, как устроены данные и конфигурации вокруг неё.
Проблема: ИИ в проде упирается в формат, а не в интеллект
На пилотах ИИ может одинаково уверенно «понимать» и XML, и JSON, и полуструктурированный текст. Можно позволить себе эксперименты: ручные правки, нестабильные схемы, неоднозначные поля. Всё, что работает на демо, считается приемлемым.
В проде правила другие.
- Нельзя, чтобы один и тот же маршрут по‑разному отработал на разных средах.
- Нельзя, чтобы модель «догадалась», что автор имел в виду, и тихо поправила конфигурацию «как лучше».
- Нельзя, чтобы изменение одного параметра незаметно поменяло поведение половины интеграций.
В какой‑то момент становится очевидно: если формат данных и конфигураций не задаёт жёсткой структуры, любая сложная ИИ‑система превращается в минное поле. Даже когда модель сильная, инфраструктура масштабируется, а команда опытная.
Есть три типичные симптома:
- Неопределённость. Одно и то же поле трактуется по‑разному в разных сервисах и маршрутах. Документация устаревает, люди полагаются на «контекст», модель — тоже.
- Хрупкость изменений. Любая правка в конфигурации тянет за собой каскад неожиданных эффектов. Нормальный CI/CD превращается в лотерею.
- Невоспроизводимость. Конфиг «чуть поправили руками», часть логики уехала в устную традицию, ИИ‑агенты начинают работать с тем, что видят, а не с тем, что архитекторы задумали.
В таких условиях модель уже не спасает. Нужен другой уровень дисциплины — на уровне формата.
Решение: структурированные форматы как «страховка» для ИИ‑систем
Есть популярное заблуждение: раз современные модели хорошо читают текст, формат данных не так важен. Главное — «объяснить по‑человечески», а дальше ИИ разберётся.
Это верно, пока задача — ответить на вопрос, а не управлять продом.
Как только ИИ начинает:
- создавать и изменять интеграционные маршруты,
- подключать новые источники и приёмники,
- менять правила трансформации и маршрутизации,
формат данных вдруг становится критическим фактором успеха.
У структурированных форматов вроде XML и схем есть несколько качеств, которые в этом контексте оказываются принципиальными.
1. Явная структура.Конфиг — это не «описание намерения», а дерево: маршруты, коннекторы, трансформации, политики, параметры. И человек, и ИИ видят одни и те же узлы и связи. Не нужно угадывать, что «автор имел в виду».
2. Формальная проверка.Схема (XSD, JSON Schema и т.п.) позволяет автоматически ответить на вопрос: «конфигурация вообще корректна?» до того, как она попадёт в прод. Это фундамент для безопасной работы ИИ‑агентов: сначала модель генерирует, потом схема фильтрует.
3. Локализованные изменения.Когда конфигурация — это структура, а не текстовое эссе, любые изменения становятся адресными. Можно изменить один тег, один атрибут, одну ветку — и точно понимать, что остальное осталось неизменным.
4. Совместимость человек ↔ ИИ.Человек читает конфиг глазами, ИИ — токенами и деревьями. Структурированный формат выравнивает их «картину мира»: и архитекторы, и агенты оперируют одинаковыми сущностями.
Важно: речь не о том, что «XML лучше всего для ИИ». Речь о том, что структурированность лучше всего для промышленных ИИ‑систем. XML здесь — просто зрелый, проверенный десятками лет носитель этой структурированности.
Практика Энтакси: XML как язык платформы для людей и ИИ
Теперь к самой интересной части — как это выглядит на уровне реального продукта, а не концепции.
Энтакси — российская low-code платформа для корпоративных интеграций. В её архитектуру изначально заложена идея: конфигурация должна быть не «набором настроек», а формализованным языком описания интеграций, понятным и людям, и машинам.
Это проявляется в трёх ключевых решениях.
1. XML‑конфигурации маршрутов и сервисов
Интеграционные сценарии в Энтакси описываются в виде XML‑конфигураций. Каждый маршрут это дерево из:
- источников и приёмников,
- шагов обработки,
- трансформаций,
- условий,
- политик безопасности и ретраев,
- логирования и трассировки.
На одном и том же артефакте платформа даёт два режима работы:
- визуальный дизайн — когда архитектор собирает маршрут из блоков;
- режим кода (XML) — когда можно работать прямо с исходной структурой.
Это не два разных мира, а две проекции одной и той же формальной модели. Важный побочный эффект: ИИ‑агенту достаточно понимать XML‑структуру, чтобы быть «полноправным участником процесса» наравне с человеком.
2. Хранилище схем и ресурсов
В Энтакси конфиг это не только маршруты. Платформа выделяет отдельный слой ресурсов, где хранятся схемы, описывающие:
- структуру данных,
- форматы сообщений,
- вспомогательные конфигурационные файлы.
По сути, это единый «источник истины» для всего, что связано с формой и типами данных в интеграциях. И когда ИИ‑агент получает задачу «подключить новый сервис» или «добавить трансформацию», он работает не в вакууме, а в окружении чётко определённых схем.
Это сильно отличается от подхода «пусть модель сама догадается по примерам». Здесь модель не гадает, она подстраивается под уже заданный формальный слой.
3. Кастомные теги как уровень доменной семантики
XML в Энтакси используется как язык с собственными доменными конструкциями. Через кастомные теги описываются:
- выбор конкретных коннекторов,
- вызовы маршрутов,
- трансформации (XSLT, маппинг),
- работа с секретами и параметрами,
- логирование, трассировка, технические аспекты интеграции.
Фактически, платформа предлагает не чистый XML, а DSL (domain‑specific language) на его основе. Для человека это значит: читаемый, предсказуемый конфиг, где теги совпадают с привычными интеграционными сущностями. Для ИИ‑агента это значит: чёткий словарь, с которым можно работать программно, а не «угадывать» смысл по свободному тексту.
Как архитектура Энтакси делает продукт готовым для подключения ИИ-агентов
Если говорить прагматично, такая архитектура даёт очень конкретные сценарии:
- ИИ‑помощник архитектора, который умеет разбирать и объяснять существующие маршруты на естественном языке, опираясь на XML‑структуру.
- Автоматизированные изменения: «добавь ещё один потребитель в этот маршрут», «вставь логирование на этапе X», «обнови схему под новую версию сервиса».
- Генерация новых маршрутов из текстового запроса с последующей валидацией по схемам.
Общий знаменатель один: В промышленных ИИ‑проектах формат данных и конфигураций является одним из ключевых архитектурных решений. Заложенный в архитектуру Энтакси структурированный XML‑подход позволит в будущем обеспечить комбинацию предсказуемости, безопасности и управляемости, без которой ИИ сложно вписать в производственном ландшафт.