Давайте посмотрим, на что сейчас способны лучшие языковые модели в плане выполнения работы архитектора 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 июня — «Мониторинг производительности в ЦУП».
Комментарии (2)
mlnw
10.06.2024 13:49+1Модели из топ-5 арены уже сейчас могут по описанию на человеческом языке создавать работающие конфигурации 1С
Ммм. А теперь давайте с этим подходом создадим
ERPхотя бы простейшую тупейшую конфигурацию из ассортимента 1С, уровня 1С:БизнесСтарт или что-то типа. Сколько человеколет на это понадобится?
ainu
Если бы работа по составлению таких вот конфигураций было бы единственным занятием человека на должности "Архитектор 1С", то ещё возможно (но очень очень спорно, особенно если учесть, сколько именно в современных организациях таблиц, столбцов, и как часто появляются новые).
Имело бы смысл, если бы условный "архитектор" составлял бы новую "архитектуру" каждые 15 минут за 10$ штука, без дальнейшей поддержки, с 9 утра до 18 вечера.