Будем с помощью искусственного интеллекта принимать заказы. Это может пригодиться везде, где есть потребность в сжатый промежуток времени принять множество заказов от клиентов. Хлебозавод, молокозавод, точка общественного питания в людном месте, где в обед выстраиваются очереди. Вот далеко не полный перечень мест, где это может быть использовано. Техническое ограничение у нас здесь будет одно: количество товаров в прайсе(меню). Оно не должно быть очень большим. В идеале, не больше 100 позиций. Решения для принципиально большего количества товаров возможны, но требуют немного других подходов и другой экономики.
Для взаимодействия с искусственным интеллектом, он же LLM, он же большая языковая модель, будем использовать мессенджер Телеграм. Таким образом мы экономим на разработке фронт-офиса. Все, что нужно LLM, это ввод сообщений от пользователя (текстом или голосом) и демонстрация ответа. Любой мессенджер является готовым фронт-офисом для LLM.
Сделаем бота Телеграм, который одного пользователя будет воспринимать как администратора, а всех прочих как покупателей(клиентов). Для того, чтобы начать принимать заказы от клиентов, нужно сформировать список товаров с ценами. С этого момента начинается магия ИИ. Кем бы ни был наш администратор, мы можем дать ему задание завести список товаров, а на вопрос "как?" ответить, как принято сейчас выражаться, "словами через рот". И можете быть уверенными, он справится
Искусственному интеллекту на вход можно подавать голосовое сообщение или текст. И то, и другое обрабатывается схожим образом. Просто в первом случае голос сначала превращается в текст. Как видите, предложение создать новый товар может быть выражено в совершенно произвольной форме. Большой плюс такого подхода в том, что никого ничему не надо учить.
Как только товары заведены, можно начинать принимать заказы от клиентов.
Что я тут произнес? Примерно следующее
И здесь тоже не надо никого ничему учить. Что бы и как бы ни говорили ваши клиенты: "ааа...", "ээээ...", "а мне бы... а нет, не надо", оно все поймет и превратит в четко структурированный заказ. Обратите также внимание на то, что я сокращаю названия товаров и это без проблем проходит. Можно просто сказать: "как в прошлый раз" или "мне как всегда" и это тоже превратится в заказ.
Пока клиент не нажал на кнопку "Подтвердить" он может вносить изменения в заказ.
Когда клиент нажимает кнопку "Подтвердить", сообщение о принятом заказе появляется у администратора. В свою очередь, администратор может изменить статус принятого заказа.
Но и это не все, что может администратор. Еще немного магии
На первый взгляд ничего особенного. Ну разобрались что к чему и применили заранее написанный SQL запрос к базе данных. Это почти любое приложение умеет. Но дело в том, здесь нет никаких заранее написанных SQL запросов. Все три запроса:
#1
SELECT SUM(qty)
FROM OrdersRows
INNER JOIN Items
ON OrdersRows.id_item = Items.id
WHERE Items.name = 'Хлеб Бородинский'
#2
SELECT name, SUM(qty) as total_sold
FROM OrdersRows
JOIN Items
ON OrdersRows.id_item = Items.id
WHERE OrdersRows.id_order IN
(SELECT id FROM Orders WHERE date >= CURDATE() - INTERVAL 7 DAY)
GROUP BY name
ORDER BY total_sold DESC
LIMIT 1
#3
SELECT DATE(date) as sale_date, SUM(summ) as total_sales
FROM OrdersRows
INNER JOIN Orders
ON Orders.id = OrdersRows.id_order
WHERE DATE(date) >= CURDATE() - INTERVAL WEEKDAY(CURDATE()) DAY
AND DATE(date) < CURDATE() + INTERVAL (7 - WEEKDAY(CURDATE())) DAY
GROUP BY sale_date
ORDER BY sale_date;
написал искусственный интеллект, а пользователь увидел результат выполнения этих запросов. Вы можете своими словами, на человеческом языке сказать, что вам надо и получить, что вам надо!
Не смотрите на то, что запросы относительно простые. State-of-art модели сейчас запросто напишут вам например такие запросы:
-
Таблица Постоялец, день въезда, день выезда. Нужен запрос выводящий список дней, когда количество постояльцев было максимальным
-
Есть две таблицы Приход (дата, товар, партия, количество) Расход (дата, товар, количество). Нужен текст запроса, который распределит расходы по приходам по методу FIFO
-
Нужен список уникальных покупателей артикула а3465 в 2024 году, из тех, у кого было менее 3 покупок в 2023 году.
Впрочем, опыт показывает, что в большинстве случаев пользователю надо получить простой ответ на относительно простой вопрос.
Эта система приема заказов может работать автономно. Но, если вам надо связать ее с 1С, то для этого есть соответствующий инструмент. В приложении к статье выложен файл расширения. Вы можете использовать его, как заготовку для интеграции с УТ, ERP или КА. Или, чуть переделав, для интеграции с прочими типовыми конфигурациями.
Задаете соответствия между товарами в сервисе и в 1С
И можете грузить заказы
Теперь перейдем к вопросу сколько все это может стоить. В основе затрат лежат аппетиты провайдеров больших языковых моделей. Каждый запрос оценивается во входных и выходных токенах (размер того, что было на входе и размер того, что было получено на выходе). Кроме того, у нас есть еще секунды преобразования голоса в текст. Давайте посмотрим, сколько мы насобирали токенов на нашем простом примере.
Самая первая строка, это две секунды, которые я потратил на то, чтобы сказать: "Новый товар Хлеб Бородинский цена 60". Затем идут 6 строк с входными и выходными токенами. Это все действия администратора по добавлению новых товаров. Обратите внимание, количество входных токенов постепенно растет. Это потому, что растет наш список товаров, а его необходимо передавать с каждым запросом. В среднем один товар это плюс 7 токенов. Легко убедиться, что когда мы доберемся до 100 позиций, у нас каждый запрос будет под тысячу токенов. Сколько у нас будет запросов в день? Если у нас несколько сотен заказов в день, это будет порядка 500 запросов от клиентов с учетом уточнений. Будем считать, что как максимум примерно столько же запросов может быть от администратора (администраторов, 500 запросов это, наверно, будет уже несколько администраторов). Тысяча запросов по тысяче входных токенов, итого миллион. Очень удобно, потому что провайдеры как раз миллионами эти токены и считают. А теперь хорошая новость. У Open AI, для той модели, которую я использовал в данном примере, миллион токенов стоит... от 7.5 рублей до 15 рублей (разброс здесь из за автоматического кеширования запросов). То есть за весь день работы на входных токенах вы "разоритесь" на 15 рублей. Есть еще выходные токены. Они стоят в четыре раза дороже входных. Но их и будет значительно меньше. Обратите внимание на то, что их количество не растет с ростом списка товаров. Их у вас никогда не будет много, даже тогда, когда вы попросите выдать все продажи за все время. Считаться будет текст запроса, а не результат. За день вы потратите на выходных токенах еще рубля 3. Чуть хуже обстоит дело с секундами распознавания. Одна секунда стоит немного, 10 копеек. Запросы от администратора будут скорее короткими 1-2 секунды, зато запросы от клиентов могут растянуться. Если считать в среднем по 10 секунд на тысячу запросов, получиться 100 рублей. Если между вами и провайдером больших языковых моделей будет посредник, то он тоже что-то возьмет себе.
Но как бы там ни было, сумма в 100-200 рублей в день выглядит посильной и для среднего и для малого бизнеса. И, по мнению экспертов, эта сумма имеет тенденцию к сокращению в будущем. Пользоваться этим чудом нашего времени можно (и нужно) уже сейчас.
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.20.75
