"Сердцем системы стал локальный класс LCL_PROMPT_EDITOR. Почему локальный? Потому что на этапе прототипирования и тесной интеграции с конкретным циклом инвентаризации (программа редактора промптов) это позволило нам быстро итерировать, не создавая десятки глобальных типов. "
А в чём конкретное преимущество локального класса перед глобальным в данном кейсе? Как по мне - больше мусора в основной программе + соблазн использовать глобальные переменные программы-родителя. Да, не надо глоб.данные в словарь заводить, но если вы в дальнейшем решите развивать этот проект и решите встроить его в другие программы, то всё равно придётся оборачивать в глоб.класс или фм. Двойная трата времени разработчика. Может лучше сразу закладывать нормальную архитектуру даже если это прототип и всё делается ради "попробовать"?
"
Однако локальный класс — это лишь «тонкий клиент» для пользовательского ввода. Всю «тяжелую» работу по коммуникации с внешним миром берет на себя глобальный класс ZCLMM_AI_API. Это наш центральный шлюз для всех звонков к ИИ.
В конструктор класса мы передаем важные параметры контекста: подразделение (IV_DEP) и таблицу параметров (IT_PARAMS), где хранятся пары "Номер материала — Текст материала". Это ключевой момент — ИИ получает не просто вопрос, а структурированные данные для анализа.
abap
METHOD constructor.
mt_params = it_params. mv_dep = iv_dep.
ENDMETHOD.
"
Какой-то не универсальный у вас глобальный класс получился. В конструктор передаются слишком персонализированные данные под эту конкретную задачу. Для реальной МVC класс-api вообще не должен знать про какое-то там подразделение или таблицу с номерами и материалами... На вход в конструктор для класса ZCLMM_AP_API должен быть только один параметр IV_PROMPT и всё. Архитектурно видится вот такая картина. Программа-родитель (где встроен редактор), получает данные из CL_GUI_TEXTEDIТ, вызывает класс-обёртку (например для вашего случая ZCLMM_AI_INVENTORY), который в внутри себя вызывает метод класса ZCLMM_AP_API отправки данных в ИИ, получает ответ, парсит его и возdращает в программу-родителя.
"Следующий шаг — вынести ядро редактора в отдельный глобальный класс (например, ZCL_AI_PROMPT_EDITOR) и повесить на него BADI. "
А что значит повесить на него BADI? Ни разу не слышал такой фразы сколько работаю с SAP =)
Задумка использовать ИИ в конкретном бизнес-кейсе крутая, но хотелось бы больше технических моментов, а не разговоров о высоком как круто применили ИИ. А как технически реализован вызов локальной модели? Где ИИ крутится? На локальном компе у каждого пользователя или в сети компании? Какой ответ возвращает ИИ и как вы его обрабатываете? Как боретесь с тем, что ИИ может галюцинировать при ответе на один и тот же промпт? ИИ ответила вам (например на запрос "Разработай методологию присвоения кодов группам пересорта согласно маске...") и вам ИИ ответила на 100500 страниц текста. Что дальше делаете с этим текстом? Распарсиваете и изменяете состояние системы или пользователь принимает на его основе какие-то бизнес-решения? Как-будто получилась "веб-морда" в виде SAP над ИИ =(
Прочитал статью и не нашёл реальных кейсов (только в комментах)... мол... "один знакомый айтишник, на пике айтишной карьеры, заимел свой маленький свечной заводик.... и раз или два в год выкладывает фоточки в инстаграм из-за бугра..." Вот таких бы историй успешного-успеха =(
Может и читающего навело на какие-то мысли или действия...
Вроде много чего написано, но конкретики мало.
"Сердцем системы стал локальный класс
LCL_PROMPT_EDITOR. Почему локальный? Потому что на этапе прототипирования и тесной интеграции с конкретным циклом инвентаризации (программа редактора промптов) это позволило нам быстро итерировать, не создавая десятки глобальных типов. "А в чём конкретное преимущество локального класса перед глобальным в данном кейсе? Как по мне - больше мусора в основной программе + соблазн использовать глобальные переменные программы-родителя. Да, не надо глоб.данные в словарь заводить, но если вы в дальнейшем решите развивать этот проект и решите встроить его в другие программы, то всё равно придётся оборачивать в глоб.класс или фм. Двойная трата времени разработчика. Может лучше сразу закладывать нормальную архитектуру даже если это прототип и всё делается ради "попробовать"?
"
Однако локальный класс — это лишь «тонкий клиент» для пользовательского ввода. Всю «тяжелую» работу по коммуникации с внешним миром берет на себя глобальный класс
ZCLMM_AI_API. Это наш центральный шлюз для всех звонков к ИИ.В конструктор класса мы передаем важные параметры контекста: подразделение (IV_DEP) и таблицу параметров (IT_PARAMS), где хранятся пары "Номер материала — Текст материала". Это ключевой момент — ИИ получает не просто вопрос, а структурированные данные для анализа.
abap
METHOD constructor.
mt_params = it_params.
mv_dep = iv_dep.
ENDMETHOD.
"
Какой-то не универсальный у вас глобальный класс получился. В конструктор передаются слишком персонализированные данные под эту конкретную задачу. Для реальной МVC класс-api вообще не должен знать про какое-то там подразделение или таблицу с номерами и материалами... На вход в конструктор для класса ZCLMM_AP_API должен быть только один параметр IV_PROMPT и всё.
Архитектурно видится вот такая картина.
Программа-родитель (где встроен редактор), получает данные из CL_GUI_TEXTEDIТ, вызывает класс-обёртку (например для вашего случая ZCLMM_AI_INVENTORY), который в внутри себя вызывает метод класса ZCLMM_AP_API отправки данных в ИИ, получает ответ, парсит его и возdращает в программу-родителя.
Запрос:
Программа-родитель -> ZCLMM_AI_INVENTORY -> ZCLMM_AP_API
Ответ:
ZCLMM_AP_API -> ZCLMM_AI_INVENTORY -> Программа-родитель
"Следующий шаг — вынести ядро редактора в отдельный глобальный класс (например, ZCL_AI_PROMPT_EDITOR) и повесить на него BADI. "
А что значит повесить на него BADI? Ни разу не слышал такой фразы сколько работаю с SAP =)
Задумка использовать ИИ в конкретном бизнес-кейсе крутая, но хотелось бы больше технических моментов, а не разговоров о высоком как круто применили ИИ.
А как технически реализован вызов локальной модели? Где ИИ крутится? На локальном компе у каждого пользователя или в сети компании? Какой ответ возвращает ИИ и как вы его обрабатываете? Как боретесь с тем, что ИИ может галюцинировать при ответе на один и тот же промпт? ИИ ответила вам (например на запрос "Разработай методологию присвоения кодов группам пересорта согласно маске...") и вам ИИ ответила на 100500 страниц текста. Что дальше делаете с этим текстом? Распарсиваете и изменяете состояние системы или пользователь принимает на его основе какие-то бизнес-решения? Как-будто получилась "веб-морда" в виде SAP над ИИ =(
А что за хостер? Забугорный?
Прочитал статью и не нашёл реальных кейсов (только в комментах)... мол... "один знакомый айтишник, на пике айтишной карьеры, заимел свой маленький свечной заводик.... и раз или два в год выкладывает фоточки в инстаграм из-за бугра..."
Вот таких бы историй успешного-успеха =(
Может и читающего навело на какие-то мысли или действия...
Подскажите, а почему не используйте API? Путь выгрузки данных из файлов был выбран для получения опыта? Just for fun... как говорится