Комментарии 5
получает данные и возвращает пользователю красивый, структурированный отчет
а с чего бы модель вообще могла такое сделать?
Структура конфигурации, которую вы выгрузили, не содержит методы учета: как отражается что-то в реальном мире в этих сущностях. А просто из списка полей это не угадать.
--
Да и к реализации тут будут большие вопросы. Примерно такие же, как к худшим представителям low-code платформ: в конечном итоге, когда вы реализуете таки пункт выше (про трансляцию человеческого языка в запросы к сущностям) - окажется, что вы для построения отчета делаете 300 запросов к базе данных (естественно, я беру аналог реального сложного отчета, который соединяет кучу сущностей, группирует и рассчитывает по ним дополнительные данные), вынуждены прокачать в 10-100 раз больше данных к месту, где работает ваша модель, и обработать эти все переходы кодом. Это прям на порядки менее эффективно, чем работает сейчас внутри 1с:
где запрос будет 1,
где порядок обхода сущностей определит оптимизатор субд,
где не вернется лишнего объема данных,
где максимально все будет обработано еще в субд.
Куда потом пристроить ваше решение, если оно настолько неэффективно? Купить сервер в 10-100 раз мощнее, чтобы покрывал эту неэффективность?
В начале статьи я специально обозначил ожидания как "наивные". Целью исследования было не создать замену СКД (системе компоновки данных), а проверить: может ли ИИ вообще ориентироваться в структуре OData "с чистого листа".
Я действительно ставил перед собой дерзкую цель — проверить, сможет ли ИИ стать альтернативой написанию отчетов и в перспективе заменить часть рутинной работы программиста. Но эта идея провалилась.
Так в "выводах" вы заявляете, что все очень даже получилось:
Работающую связку на Spring AI, готовую к Enterprise-задачам.
Вот я хочу понять, где и что получилось то?
То, что оно может "найди контрагента с инн 123" перевести в url (точнее параметры тула)? Это совсем не enterprise задача. А вот отчет, который я описал в комментах выше - как раз да.
На самом деле получилось собрать рабочую техническую связку, которая стабильно (без галлюцинаций) вытаскивает атомарные данные по запросу на естественном языке.
Под "готовностью к Enterprise" я, пожалуй, поспешно подразумевал лишь инфраструктурную часть: стек Java/Spring AI, работу в закрытом контуре и безопасность данных. С точки зрения бизнеса — это пока лишь умная поисковая строка.
Статья — это в первую очередь история моего пути от наивного "сейчас заменю всех" до понимания, что ИИ — это просто новый, довольно капризный тип интерфейса к данным, у которого очень узкая ниша применения. Спасибо за конструктивную критику, она помогает правильно расставить акценты в итогах исследования.

LLM + 1C: Почему чат-бот для учета — это плохая идея, и как реализовать AI-шлюз через OData