API + ИИ = Х ?

В лаборатории никогда не скучно

Инновации рождаются там, где не боятся пробовать, ошибаться и снова пробовать. В лаборатории «Байта» это ежедневная рутина: мы склеиваем непривычные технологии, устраиваем «краш‑тесты» гипотез и смотрим, как идеи ведут себя в полевых условиях. И даже «заскорузлые» (по мнению, которое автор не разделяет) на первый взгляд платформы разработки отлично раскрываются в новых сценариях. 1С — не исключение: при правильной подаче она становится удобным и эффективным источником данных для современных ИИ‑систем.

А что, если использовать ИИ как API?

Идея проста: оставить вашей системе привычный HTTP‑вход, а взаимодействие — поручить большой языковой модели. В качестве шины данных мы выбрали универсальный стандарт OData — он одновременно предоставляет и метаданные (через $metadata), и данные (CRUD‑операции, фильтры, $expand, пагинация и т. д.). Главное преимущество в том, что модели не нужно детально объяснять, откуда какие поля брать и как их связывать: OData уже содержит декларативное описание сущностей и навигаций.

Мы придумали учебную предметную область — техническое обслуживание автомобилей — и начали прикручивать к ней ИИ‑ассистента. В роли клиентского интерфейса — Telegram‑бот, а под капотом — 1С с OData и модели OpenAI.

Наши наблюдения:

• GPT‑4o в нашем сценарии часто путалась в метаданных, периодически «забывала» перед запросом посмотреть структуру, игнорировала часть инструкций по поведению.
• GPT‑4.1 справилась заметно лучше: уверенно ориентировалась в $metadata, корректно строила запросы и формировала полезные ответы пользователю.

Мы не писали отдельных контроллеров под метаданные: модели достаточно указать, что перед ней стандартная OData, и (в редких случаях) показать пример JSON‑payload для записи.

Кейс: ассистент получает от пользователя фразы вроде «Покажи все машины с проблемными аккумуляторами» и самостоятельно:

1) анализирует метаданные и связи, 2) строит корректные OData‑запросы, 3) собирает ответ в удобочитаемом виде.

Пример типового payload, который потребовался один раз для «калибровки» записи (далее модель справлялась сама):

{
  "Дата": "2025-08-10T12:30:00",
  "Машина_Key": "b169c50d-62d4-11f0-95a3-000c294aa8f8",
  "ВидЖидкости": "Топливо",
  "Объем": 35.5,
  "ЕдиницаИзмерения_Key": "9a6a3a2b-1c4e-4d91-8a2e-3a8b1bd01001"
}

Важно: мы не хардкодили отдельные методы под каждую сущность — вся логика строится на универсальности OData.

Почти само… И да, и нет…

Опыты показали: модель хорошо «чувствует» данные и связи (включая ссылочные типы и зависимые выборки), однако для более «прикладного» участия ей нужно объяснить контекст работы:

• Кто такой сотрудник сервиса? Чем он занимается в системе и какой результат ожидает получить.
• Какие сущности считаются «основными»? Машины, проблемы (отдельный справочник), измерения жидкостей, работы/задачи.
• Какие ограничения по бизнес‑процессу? Например, что запись в регистр сведений должна быть атомарной и валидационной по ключам.

В одном случае нам действительно пригодился пример JSON для корректной записи в регистр сведений — после этого модель начала уверенно подставлять нужные реквизиты самостоятельно. Дальше — лучше: ассистент научился цеплять зависимые сущности, «помнить» контекст запроса и собирать многошаговые выборки без явного программирования промежуточных слоёв.

ИИтоги

Когда вышла линейка GPT‑5, мы протестировали gpt‑5‑mini — и она отлично вписалась в задачу:

• Инструкции выполняются заметно чётче, за счёт чего удалось сократить системный промт до ~50 строк (раньше он был больше).
• При наличии данных в базе примеров JSON больше не требуется: модель корректно «достраивает» поля по семантике и именам реквизитов.
• Культура наименования в 1С сыграла нам на руку: 100% реквизитов модель распознавала именно так, как мы ожидали.

Итоговая конфигурация:

• ~500 строк Python‑кода (интеграция Telegram + OpenAI, прокси к OData, минимальная пост‑обработка ответов).
• 50 строк системного промта — и никаких специальных «слоёв» для метаданных.
• Модель «из коробки» умеет:
  • показать список машин;
  • вывести связанные проблемы (справочник);
  • отобразить измерения жидкостей;
  • добавить задачу на ремонт и записать новое измерение;
  • собрать всевозможные сводки, например:
    • «Покажи все машины с проблемными аккумуляторами»,
    • «В какой машине дольше всего не записывали показания топлива?»

Что нам это дало:

• Лёгкое решение: без нагромождения промежуточных API‑слоёв.
• Гибкость диалога: модель понимает разные формулировки бизнес‑проблем и отвечает «по делу».
• Снижение издержек на интеграцию: OData + ИИ выступают как универсальный интерфейс к данным.

Вывод: связка API (OData) + ИИ превращает метаданные в «живой» интерфейс. Если система уже говорит на стандартизованном языке, модели достаточно минимального онбординга, чтобы начать приносить практическую пользу.

Несколько практических заметок

• Дайте модели право смотреть $metadata и выносите это в явную инструкцию.
• Добавьте 1–2 эталонных примера JSON для сложных записей — после «калибровки» они больше не потребуются.
• Уточните роли и цели: кто пользователь, какой результат «правильный» и что считать ошибкой.
• Поддерживайте понятные имена реквизитов в 1С — это сильно повышает точность «догадок» модели.

Что дальше?

Мы планируем обобщить подход на другие предметные области, добавить контроль качества ответов (включая проверку бизнес‑правил до записи) и расширить формат ответов (таблицы, вложения, графики). Так-же планируем попробовать доступные в РФ облачные и локальные модели. Но главный инсайт мы уже получили: когда данные описаны стандартом, ИИ‑ассистент становится естественным «API‑клиентом» — почти без кода.

Автор: Игорь Медведев