Давайте посмотрим, на что сейчас способны лучшие языковые модели в плане выполнения работы архитектора 1С. В этом обзоре присутствуют все основные игроки (OpenAI, Anthropic, Google). Также я добавил к ним двух отечественных провайдеров (Yandex и Сбер)
Проектирование конфигураций для 1С, это достаточно сложный процесс. Но концепции, лежащие в основе 1С, довольно просты и не требуют много слов для описания. В качестве препромта или системного промта можно использовать нечто подобное:
В учетной системе таблицы четырех видов. Справочники описывают объекты реального мира. Документы описывают события и в них есть дата. Спецификации описывают состав документов. Документы и спецификации связаны отношением один ко многим. Например, в документе мы указываем покупателя, а в спецификации мы указываем список товаров, которые купил покупатель. Регистры обладают способностью вычислять остаток. Если нам нужен остаток тогда дублируем информацию о событии в регистре.
После препромта описываем словами, что за конфигурацию мы хотим получить, а в конце добавляем «хвостик»:
Создай структуру таблиц базы данных для такого учета с названиями таблиц и полей на русском языке. Также надо указать связи между таблицами. Результат представь в виде JSON
Если представить себе, что мы хотим сделать рабочий инструмент для архитектора 1С, тогда препромт и хвост стоит спрятать внутри приложения, а пользователю предоставить одно единственное поле ввода, куда он внесет свое описание конфигурации человеческими словами, в произвольной форме. Мы же отправим большой языковой модели на обработку это пользовательское описание с препромтом впереди и хвостом сзади. Такая конструкция не единственно возможная. Можно было бы и хвост поставить вперед. Языковым моделям в данном случае более или менее все равно. Но я решил остановиться на таком варианте исключительно для наглядности. В окончательном виде то, что мы отправляем большой языковой модели могло бы выглядеть, например, так:
В учетной системе таблицы четырех видов. Справочники описывают объекты реального мира. Документы описывают события и в них есть дата. Спецификации описывают состав документов. Документы и спецификации связаны отношением один ко многим. Например, в документе мы указываем покупателя, а в спецификации мы указываем список товаров, которые купил покупатель. Регистры обладают способностью вычислять остаток. Если нам нужен остаток тогда дублируем информацию о событии в регистре.
У меня мелкооптовая торговля. Я хочу вести учет закупок товаров у поставщиков и продаж товаров покупателям. Хочу видеть остатки товаров на текущий момент. И сколько и на какую сумму я продал товаров.
Создай структуру таблиц базы данных для такого учета с названиями таблиц и полей на русском языке. Также надо указать связи между таблицами. Результат представь в виде JSON
«Отдадим» это GPT-4 (OpenAI). Результат будет следующим:
{ "Таблицы": [ { "Название": "Справочник_Поставщики", "Поля": [ { "Название": "ID_Поставщика", "Тип": "int" }, { "Название": "Название_Поставщика", "Тип": "string" } ] }, { "Название": "Справочник_Товары", "Поля": [ { "Название": "ID_Товара", "Тип": "int" }, { "Название": "Название_Товара", "Тип": "string" }, { "Название": "Цена_Товара", "Тип": "float" } ] }, { "Название": "Документ_Закупка", "Поля": [ { "Название": "ID_Документа", "Тип": "int" }, { "Название": "Дата_Закупки", "Тип": "date" }, { "Название": "ID_Поставщика", "Тип": "int" } ], "Связи": [ { "Таблица": "Справочник_Поставщики", "Поле": "ID_Поставщика" } ] }, { "Название": "Спецификация_Закупка", "Поля": [ { "Название": "ID_Спецификации", "Тип": "int" }, { "Название": "ID_Документа", "Тип": "int" }, { "Название": "ID_Товара", "Тип": "int" }, { "Название": "Количество", "Тип": "int" } ], "Связи": [ { "Таблица": "Документ_Закупка", "Поле": "ID_Документа" }, { "Таблица": "Справочник_Товары", "Поле": "ID_Товара" } ] }, { "Название": "Регистр_Остатки", "Поля": [ { "Название": "ID_Товара", "Тип": "int" }, { "Название": "Остаток", "Тип": "int" } ], "Связи": [ { "Таблица": "Справочник_Товары", "Поле": "ID_Товара" } ] }, { "Название": "Документ_Продажа", "Поля": [ { "Название": "ID_Документа", "Тип": "int" }, { "Название": "Дата_Продажи", "Тип": "date" } ] }, { "Название": "Спецификация_Продажа", "Поля": [ { "Название": "ID_Спецификации", "Тип": "int" }, { "Название": "ID_Документа", "Тип": "int" }, { "Название": "ID_Товара", "Тип": "int" }, { "Название": "Количество", "Тип": "int" }, { "Название": "Сумма", "Тип": "float" } ], "Связи": [ { "Таблица": "Документ_Продажа", "Поле": "ID_Документа" }, { "Таблица": "Справочник_Товары", "Поле": "ID_Товара" } ] } ] } Конечно же этот JSON (впрочем, как и любой другой) не предназначен для того, чтобы выдавать его пользователю как есть. Если у вас имеется некоторый опыт разработчика 1С, тогда вы можете присмотреться внимательнее к результату и убедиться, что относительно простая утилита может превратить этот JSON в файл .cf, т.е. в конфигурацию 1С. А утилита чуть посложнее может даже сделать два файла выгрузки (.dt), как это принято для типовых конфигураций 1С. Первая выгрузка будет пустой базой, а вторая — демонстрационной базой с некоторым количеством данных, сгенерированных той же языковой моделью.
Это был результат флагманской модели OpenAI GPT-4. Модель 3.5 можете не пробовать. Я вам так скажу, результат будет малопригоден для дальнейшей обработки. Давайте посмотрим, что мы можем получить от ближайшего конкурента OpenAI, компании Anthropic с ее флагманской моделью Claude-3-opus. Не так давно Claude сумел на некоторое время сместить GPT-4 с первого места на арене LMSys. Сейчас, правда, последняя модель GPT-4 вернула себе первое место. Арена LMSys это такая площадка, на которой различные модели соревнуются друг с другом в решении одинаковых задач. Соревнуются всегда две модели. Это как партия в шахматах. В результате получается ELO, как у шахматистов. Я считаю, что это более объективная оценка, чем всевозможные бенчмарки.
Результат Клода такой:
{ "справочники": [ { "название": "Товары", "поля": [ { "название": "Код", "тип": "число" }, { "название": "Наименование", "тип": "строка" } ] }, { "название": "Контрагенты", "поля": [ { "название": "Код", "тип": "число" }, { "название": "Наименование", "тип": "строка" }, { "название": "Тип", "тип": "строка", "значения": [ "Поставщик", "Покупатель" ] } ] } ], "документы": [ { "название": "ПриходнаяНакладная", "поля": [ { "название": "Номер", "тип": "число" }, { "название": "Дата", "тип": "дата" }, { "название": "Поставщик", "тип": "ссылка", "таблица": "Контрагенты" } ] }, { "название": "РасходнаяНакладная", "поля": [ { "название": "Номер", "тип": "число" }, { "название": "Дата", "тип": "дата" }, { "название": "Покупатель", "тип": "ссылка", "таблица": "Контрагенты" } ] } ], "спецификации": [ { "название": "СпецификацияПрихода", "поля": [ { "название": "Документ", "тип": "ссылка", "таблица": "ПриходнаяНакладная" }, { "название": "Товар", "тип": "ссылка", "таблица": "Товары" }, { "название": "Количество", "тип": "число" }, { "название": "Цена", "тип": "число" }, { "название": "Сумма", "тип": "число" } ] }, { "название": "СпецификацияРасхода", "поля": [ { "название": "Документ", "тип": "ссылка", "таблица": "РасходнаяНакладная" }, { "название": "Товар", "тип": "ссылка", "таблица": "Товары" }, { "название": "Количество", "тип": "число" }, { "название": "Цена", "тип": "число" }, { "название": "Сумма", "тип": "число" } ] } ], "регистры": [ { "название": "ОстаткиТоваров", "поля": [ { "название": "Товар", "тип": "ссылка", "таблица": "Товары" }, { "название": "Количество", "тип": "число" } ] }, { "название": "ПродажиТоваров", "поля": [ { "название": "Товар", "тип": "ссылка", "таблица": "Товары" }, { "название": "Количество", "тип": "число" }, { "название": "Сумма", "тип": "число" } ] } ], "связи": [ { "таблица1": "ПриходнаяНакладная", "таблица2": "СпецификацияПрихода", "тип": "один-ко-многим" }, { "таблица1": "РасходнаяНакладная", "таблица2": "СпецификацияРасхода", "тип": "один-ко-многим" } ] }На мой взгляд, даже несколько лучше, чем у GPT4, проще разбирать ссылки. А что нам даст Google со своими Близнецами? Прямо сейчас ELO у модели Gemini-1.5-pro 1249. Это на единицу больше, чем у Claude-3-opus. Результат Близнецов:
{ "таблицы": [ { "название": "Справочник товаров", "поля": [ "Код товара", "Наименование товара", "Цена закупки", "Цена продажи" ] }, { "название": "Справочник поставщиков", "поля": [ "Код поставщика", "Наименование поставщика" ] }, { "название": "Справочник покупателей", "поля": [ "Код покупателя", "Наименование покупателя" ] }, { "название": "Документ закупки", "поля": [ "Номер документа", "Дата документа", "Код поставщика", "Сумма закупки" ] }, { "название": "Спецификация закупки", "поля": [ "Номер документа", "Код товара", "Количество", "Цена закупки" ] }, { "название": "Документ продажи", "поля": [ "Номер документа", "Дата документа", "Код покупателя", "Сумма продажи" ] }, { "название": "Спецификация продажи", "поля": [ "Номер документа", "Код товара", "Количество", "Цена продажи" ] }, { "название": "Регистр остатков товаров", "поля": [ "Код товара", "Количество на начало периода", "Количество поступило", "Количество продано", "Количество на конец периода" ] } ], "связи": [ { "таблица1": "Документ закупки", "поле1": "Номер документа", "таблица2": "Спецификация закупки", "поле2": "Номер документа" }, { "таблица1": "Документ продажи", "поле1": "Номер документа", "таблица2": "Спецификация продажи", "поле2": "Номер документа" }, { "таблица1": "Справочник товаров", "поле1": "Код товара", "таблица2": "Спецификация закупки", "поле2": "Код товара" }, { "таблица1": "Справочник товаров", "поле1": "Код товара", "таблица2": "Спецификация продажи", "поле2": "Код товара" }, { "таблица1": "Справочник поставщиков", "поле1": "Код поставщика", "таблица2": "Документ закупки", "поле2": "Код поставщика" }, { "таблица1": "Справочник покупателей", "поле1": "Код покупателя", "таблица2": "Документ продажи", "поле2": "Код покупателя" }, { "таблица1": "Справочник товаров", "поле1": "Код товара", "таблица2": "Регистр остатков товаров", "поле2": "Код товара" } ] } Ничуть не хуже, чем у предыдущих участников. Из этого тоже можно собрать конфигурацию в автоматическом режиме.
На этом хорошие результаты заканчиваются. Возможно, что следовало бы попробовать еще и Llama-3 с ее 1208 ELO, но я пока так и не смог преодолеть свой скепсис в отношении этой модели. В языковых моделях размер имеет значение. И 70 миллиардов у Llama сильно проигрывают своим ближайшим конкурентам.
Но у нас есть еще модели, которые вообще не участвуют в рейтинге. Речь идет об отечественных моделях от Yandex и Сбер.
Результат Yandex:
{ "Справочник товаров": { "id": "Идентификатор товара", "название": "Название товара", }, "Документ закупки": { "id": "Уникальный идентификатор документа закупки", "дата": "Дата закупки", "поставщик": "Ссылка на справочник поставщиков", "количество": "Количество закупленных товаров", } "Спецификация закупки": { "идентификатор_документа": "Ссылка на документ закупки", "товар": "Ссылка на товары из справочника товаров" } "Регистр остатков": { "идентификатор": "Идентификатор регистра остатков", "товар": "Товар из справочника товаров", "количество": "Количество товара на складе", "сумма": "Стоимость товара на складе" }, "Документ продажи": { "id": "Документ продажи", "дата": "Дата продажи", "покупатель": "Покупатель из справочника покупателей", "количество": "Продаваемое количество товаров", "цена": "Цена продажи товаров" } } Как видите, конфигурацию из этого не собрать. Хотя в целом у Яндекса неплохая модель со 100 миллиардами параметров. И, например, запросы SQL (а значит и запросы для 1С) она генерит достаточно хорошо.
Сберовский GIgaChat с его 39 миллиардами намного слабее. И его результат ожидаемо не лучше, чем у Яндекс:
{ "таблицы": [ { "название": "Поставщики", "поля": [ {"имя": "ID", "тип": "integer", "ключевое_поле": true}, {"имя": "Название", "тип": "text"}, {"имя": "Адрес", "тип": "text"} ] }, { "название": "Товары", "поля": [ {"имя": "ID", "тип": "integer", "ключевое_поле": true}, {"имя": "Название", "тип": "text"}, {"имя": "Цена", "тип": "decimal"} ] }, { "название": "Закупки", "поля": [ {"имя": "ID", "тип": "integer", "ключевое_поле": true}, {"имя": "Дата", "тип": "date"}, {"имя": "Поставщик_ID", "тип": "integer", "связь": "многие_ко_многим", "с_таблицей": "Поставщики"}, {"имя": "Товар_ID", "тип": "integer", "связь": "многие_ко_многим", "с_таблицей": "Товары"} ] }, { "название": "Продажи", "поля": [ {"имя": "ID", "тип": "integer", "ключевое_поле": true}, {"имя": "Дата", "тип": "date"}, {"имя": "Покупатель", "тип": "text"}, {"имя": "Товар_ID", "тип": "integer", "связь": "многие_ко_многим", "с_таблицей": "Товары"} ] } ], "связи": [ {"откуда": "Закупки", "куда": "Поставщики", "связь": "один_ко_многим"}, {"откуда": "Закупки", "куда": "Товары", "связь": "многие_ко_многим"}, {"откуда": "Продажи", "куда": "Товары", "связь": "многие_ко_многим"} ] } Подведем итоги
- Модели из топ-5 арены уже сейчас могут по описанию на человеческом языке создавать работающие конфигурации 1С. Справочники, документы и регистры у вас будут. Отчеты в современных условиях не очень-то и нужны. Пользователь сформулирует, что ему надо на человеческом языке, а модель превратит это в запрос к базе данных.
- Отечественные модели в этом вопросе пока не дотягивают до флагманских моделей. И в целом выдают непригодный для дальнейшего использования результат. Но будем надеяться, что ситуация в будущем исправится.
Если вы хотите развивать свою карьеру в качестве архитектора 1С, следите внимательно за тем, что происходит в области искусственного интеллекта.
Также приходите на открытые уроки, посвящённые архитектуре 1С: 10 июня — «Юнит-тестирование в 1С», 20 июня — «Мониторинг производительности в ЦУП».
ссылка на оригинал статьи https://habr.com/ru/articles/813887/
Добавить комментарий