Представим себе, что у нас небольшое кондитерское производство и мы хотели бы вести учет на складе сырья. Учетных позиций у нас будет не очень много, скажем, в пределах 100.
Мы не будем здесь рассматривать десятки позиций. Рассмотрим следующие пять
Мука пшеничная
Сахар песок
Масло растительное
Яйцо куриное
Апельсины
От пяти позиций до пятидесяти или даже до 500 это масштабируется без проблем, к тому же в реальном кондитерском производстве действительно не так уж много позиций для учета.
Сделаем Телеграм-бота, к нему вебхук, к вебхуку скрипт на Python. Это все стандартная история, много раз описанная другими. Не будем на этом останавливаться.
Итак, у нас есть обработчик сообщений, поступающих из Телеграм. Будем отправлять их на обработку большими языковыми моделями (LLM), в просторечье именуемыми искусственным интеллектом (куда уж сегодня без него). State-of-art модели сейчас позволяют организовать вызов функций на основе запроса, сформулированного на обычном человеческом языке. Т.е. пользователь говорит что-то типа: апельсины пришло 100, или апельсины поступило 100 или апельсины приход 100 или пришло 100 апельсинов и т.д. Большая языковая модель в любом случае понимает, что речь идет о поступлении на склад и предлагает вызвать функцию поступления.
В нашем случае будет достаточно всего трех функций: поступление, списание и остаток. При каждом вызове большой языковой модели, будем передавать описание этих трех функций. В скрипте создадим реализацию этих трех функций очевидным образом. Приход будет писать в таблицу приходов, расход в таблицу расходов, а остаток получать остаток из этих двух таблиц. Результат работы такого сервиса выглядит так:
Если вы еще не знакомы с большими языковыми моделями, то у вас может к этому моменту сложиться впечатление, что все это легко ломается, стоит только вместо "мука пшеничная" сказать "пшеничная мука" или просто "мука", как это и происходит в реальной жизни. Но в том-то и фишка больших языковых моделей. Они понимают язык и от разных формулировок одного и того же они не ломаются. Поэтому общение с большой языковой моделью может выглядеть так:
... или так:
... или так:
Что особенно приятно, это то, что сообщения можно не только писать, но и проговаривать. В этом случае потребуется задействовать еще одну модель типа speech-to-text (OpenAI обещают упростить нам жизнь в этом вопросе, но пока только обещают). Потребуется некоторая доработка скрипта, но оно того стоит. Все-таки на диктовку уходит гораздо меньше усилий, чем на письмо. Я сам начал это отчетливо понимать после многих часов тестирования как письма, так и голосового ввода.
Итак. Мы имеем складской учет, который не требует от нас ни установки ПО, ни обучения. Смартфон с Телеграм всегда под рукой у каждого. Взаимодействие происходит максимально комфортным для пользователя способом, на человеческом языке.
Гуд бай, 1С?
Комментарии (30)
qvan
01.09.2024 09:12+1Апельсины ушло 120, ой 130. Отмени последний ввод. Замок или замок? Кто ответственный за операцию? Итд итп.
exwill Автор
01.09.2024 09:12+1Думаете, будут проблемы с отменой последнего ввода? Какие?
anonymous
01.09.2024 09:12НЛО прилетело и опубликовало эту надпись здесь
exwill Автор
01.09.2024 09:12+1Давайте начнем со складского учета
scarab
01.09.2024 09:12+2Техкарты - это базис складского учёта. Или у Вас кондитер будет на каждую булочку будет вручную списывать 30г муки, 5г изюма, 1 яйцо?
А ещё для складского учёта нужно учитывать не только поступления, а поставки в целом. Приехала машина, привезла 50 позиций общим весом полтонны. "Кладовщик" будет это всё руками или голосом в бота заносить?
(открою секрет - сейчас УПД чаще всего ведётся в электронном виде и загружаться в систему будет одной кнопкой).
А с поставками тоже бывает веселье: сегодня купили 100кг муки "Селяночка" по 100 рублей у поставщика А, завтра у поставщика А муки не оказалось и пришлось покупать "Белонежную" у поставщика Б, но уже по 120 рублей: в итоге на складе 200 кг муки - но разной. Какую и в каком порядке Вы будете списывать?
И так далее и так далее.
exwill Автор
01.09.2024 09:12+1А мне вот лично встречалось именно кондитерское производство, у которого была совершенно конкретная "боль". Количественный учет на складе сырья. А то, о чем вы говорите, у них "не болело"
softaria
01.09.2024 09:12+1Тогда это - просто маленький велосипед, для очень узкой ЦА.
Для 1с - вообще не конкурент
mixsture
01.09.2024 09:121) Сложность. Вы показываете 2 элементарных операции на одном виде учета и на одном показателе (только количественный учет). Эта сложность пишется новичками, пришедшими на недельные курсы по 1с. Реальные рабочие конфигурации у 1с, думаю, раз в 1000 сложнее. Как вы собираетесь перейти от одного к другому?
2) Скорость работы. Скорость операций у LLM крайне низкая (по сравнению с оптимизированными для этого структурами хранения в 1с и кодом). Учет часто из себя представляет причинно-следственные связи между операциями по времени (каждая следующая использует предыдущие как исходные данные), поэтому при исправлениях важно актуализировать и все операции, начиная с исправленной до текущего момента. В терминах 1с это перепроведение. Возьмем для примера 1 тысячу операций и необходимость их перепровести. На сколько порядков ваша модель будет медленнее относительного того же на 1с?
exwill Автор
01.09.2024 09:12+11) Типовые конфигурации, да, в 1000 (а может и более) раз сложнее. Только эта сложность в 99% случаев излишня. То, что я вам здесь демонстрирую это реально рабочий сервис. Кому-то потребуется что-то посложнее? Ну напишите еще пару функции, в дополнение к этим трем. А если вы напишите еще 100 функций, то вы обеспечите пользователям практически все, что им нужно. Причем ваша разработка будет все еще неизмеримо проще, чем самая простая типовая конфигурация
2) Так "шустрит" не LLM. "Шустрят" ваши функции. LLM всего лишь "соображает" чего хочет пользователь и выдает сигнатуру функции. Потом эта функция выполняется на сервере. В моем примере это Python + MySQL. Это работает быстрее любой 1С
mixsture
01.09.2024 09:12+1Так вы просто хотите замену экранных форм на текстовый ввод со свободным языком? Тогда это не отменяет 1с (и в целом может совмещаться с движком 1с).
Но в общем случае будет неудобно. Сейчас вы этого не замечаете, опять же, из-за крайне заниженной сложности. У вас по сути в тексте операции лишь 3 реквизита (вид движения, товар, количество). Сделайте аналог формы, где есть поля шапки, есть пару табличных частей, где в каждой строке табличной части несколько полей с текстовыми данными. Я бы посмотрел, как LLM разберется, где какие данные без дополнительной разметки.
Будете делать 1 текст на 1 документ? Тогда потеряете интерактивность ввода - и вы никак не поможете пользователю с заполнением коррелирующих полей (одно поле ограничивает список значений другого, например). Будете делать 1 текст на каждую строку/поле? Тогда ваш документ растянется по вертикали на много-много экранов, потеряется компактность данных, что добавит ошибок у операторов ввода.exwill Автор
01.09.2024 09:12Зачем все это? Пользователь говорит, что ему надо и получает что ему надо. Без всяких табличных частей, коррелированных полей и прочих "чудес". Это все остается в прошлом
mixsture
01.09.2024 09:12Для удобства работы пользователя, которое влияет на число ошибок. Вот чуть ниже в треде вы сами же пришли к необходимости "задавать уточняющий вопрос" - это тоже относится к интерактивному вводу.
Собственно, список проблем - он не о языковых моделях конкретно, он вообще о текстовом вводе. Ровно те же проблемы у меня были при попытке сделать интерфейс к документам 1с в телеграм боте: очень низкая компактность отображения и очень ограниченная интерактивность. Поэтому простые документы (у меня были финансовые доки) - да, возможно. А вот сложные: вроде поступления, реализации, производственных - очень неудобно.exwill Автор
01.09.2024 09:12А теперь представьте, что человек вообще не напрягает глаза, только говорит
tuxi
01.09.2024 09:12+1крахмал картофельный приход 100
крахмал кукурузный приход 75
сколько крахмала сейчас?
какой ответ будет?
второй пример
крахмал картофельный приход 100
крахмал кукурузный приход 75
крахмал расход 70
-
сколько крахмала сейчас?
какой ответ будет?
exwill Автор
01.09.2024 09:12+1Попробуйте сами
https://t.me/awpdemo_bot
webhamster
01.09.2024 09:12Я попробовал, и получилась чушь:
крахмал картофельный приход 100Поступило крахмал картофельный 100
крахмал кукурузный приход 75
Поступило крахмал кукурузный 75
крахмал расход 70
Списано крахмал 70
сколько крахмала сейчас?
Остаток крахмал -70
exwill Автор
01.09.2024 09:12+2LLM посчитала, что у вас три позиции: крахмал картофельный, крахмал кукурузный и просто крахмал. В этом ведь есть логика, не так ли? Не вижу в этом большой проблемы.
Впрочем, быть может вы и правы. Было бы неплохо в таких ситуациях задавать конкретизирующий вопрос
nee77
Осталось совсем чуть-чуть: прикрутить расчет налогов по разным СНО, расчет ЗП, интеграцию с банк-клиентами, формирование документов по различным формам ... и обучить тысячу бухгалтеров
exwill Автор
Обучить бухгалтеров чему? Русскому языку?
anonymous
НЛО прилетело и опубликовало эту надпись здесь
nee77
А Вы когда-нибудь пробовали у бухгалтеров какие-нибудь нововведения внедрить? Это люди со специфическим мышлением (большинство из них). Они как трамваи, хорошо едут там, где проложен путь.