Давайте посмотрим, на что сейчас способны лучшие языковые модели в плане выполнения работы архитектора 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", "связь": "многие_ко_многим", "с_таблицей": "Товары"}
]
}
],
"связи": [
{"откуда": "Закупки", "куда": "Поставщики", "связь": "один_ко_многим"},
{"откуда": "Закупки", "куда": "Товары", "связь": "многие_ко_многим"},
{"откуда": "Продажи", "куда": "Товары", "связь": "многие_ко_многим"}
]
}
Подведем итоги
Если вы хотите развивать свою карьеру в качестве архитектора 1С, следите внимательно за тем, что происходит в области искусственного интеллекта.
habr.com
Проектирование конфигураций для 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С
Давайте посмотрим, на что сейчас способны лучшие языковые модели в плане выполнения работы архитектора 1С. В этом обзоре присутствуют все основные игроки (OpenAI, Anthropic, Google). Также я добавил к...
habr.com