Это уже детали конкретной реализации. Человек может подходить к окну выдачи, чтобы забрать заказ. Если же реализация подразумевает доставку заказа к столу, тогда в заказе будет номер стола. И вообще это может быть не общепит, а хлебокомбинат, например, который так будет собирать заказы с магазинов. Не суть
Все более или менее так. Только "пред. промт", как вы его назвали, это всего лишь строка. Читаете структуру базы и пишете в этот самый "пред. промт". А структура базы...
Вот сказали вы ИИ: "выдай мне 10 самых продаваемых товаров в прошлом месяце". И получили SELECT.
А сказали "Теперь нам надо вести учет по размерам". И получили ALTER TABLE.
И то запрос, и то запрос. И то выполняется, и то выполняется. Принципиальной разницы нет
Вы заключаете договор. Получаете бота. Ваш аккаунт в Телеграм будет администратором. Все прочие - клиентами. Вы, как администратор, заводите список товаров. С момента, как вы завели первый товар, клиенты могут начинать делать заказы.
Я вас умоляю. Ну что там может положить сервер? Это же малый бизнес. Мы же начали с чего? Несколько сотен чеков в день. Один чек 100 байт. 100 чеков 10 килобайт. 1000 дней работы 10 мегабайт.
Поскольку сам писал, от первой до последней строчки, могу уверенно сказать: с нулевой вероятностью. Некуда там воткнуть инъекцию.
Кроме того. Ну, помилуйте! Ну даже если случится невероятное. И кто-то узнает, что клиент с номером 983457893475 10 раз купил мороженое. Ну и что? Безопасность важна, но не надо ударяться в паранойю
1) Вопросы "сращивания" решается так же, как и у всех прочих сервисов, через API. Отправили запрос, получили список заказов. Сейчас такого рода интеграции не требуют особенных трудозатрат и высокой квалификации. Даже джуны справляются.
2) ИИ в общем-то все равно: работать с одним свойством, двумя, 10 или 50. Оно все "скушает" и жаловаться не будет. Как я вижу, тут ограничения возникают с другой стороны. Клиент приходит к вам. Он хочет описать в идеале одним, ну максимум двумя словами, что ему нужно и получить, что ему нужно. Если вы предложите клиенту расписать 25 характеристик товара, он просто развернется и уйдет. Обратите внимание, в ресторанах заказывают салат Цезарь или греческий, но не расписывают по ингредиентам желаемое блюдо. Но, повторюсь, со стороны ИИ тут ограничений нет. Если у вас задача несколько иная, чем прием заказа в общепите, то ИИ не будет вас ограничивать в количестве параметров. 10 так 10, хоть 100!
Если вам хочется поэкспериментировать, напишите в личку, я выдам вам бота
Проблема т.н. галлюцинаций LLM связана в первую очередь с тем, что для широких народных масс установлен режим "сказочника". О том, что LLM могут работать в другом режиме они даже не догадываются.
Что касается генерации запросов с помощью LLM, то тут ситуация с возможными галлюцинациями несколько проще, чем в других случаях. Вы задали вопрос. LLM сгенерировала кривой запрос. Ну так он в большинстве случаев просто не выполнится. У вас уже есть естественная система проверки в виде СУБД. Случай, когда запрос все же выполнился, но вместо списка товаров выдал вам список клиентов также не будет для вас проблемой.
Повторюсь, на простых и среднесложных запросах эта технология работает надежно. Надежнее людей. А в сложных случаях надо просто действовать адекватно. Это означает задать один и тот же вопрос несколькими разными способами и разным моделям. Умные люди это и раньше понимали и в ответственных ситуациях привлекали нескольких экспертов параллельно. Ничего не изменилось, только "экспертов" теперь привлечь намного легче, быстрее и дешевле
Вы передергиваете. Я сказал, что есть два варианта реализации. А у вас это каким-то образом превратилось в "каждый конкретный случай"
Что вы пробовали? На какой модели? С какой температурой?
Оплата в боте.
1) Все оно понимает. Уж поверьте. Я это проверял и много раз. Уже год назад это работало достаточно надежно, а современные модели только прибавили
2) Что касается пользователя... Для него это ничем не отличается от взаимодействия с живым программистом, кроме цены и скорости
Это уже детали конкретной реализации. Человек может подходить к окну выдачи, чтобы забрать заказ. Если же реализация подразумевает доставку заказа к столу, тогда в заказе будет номер стола. И вообще это может быть не общепит, а хлебокомбинат, например, который так будет собирать заказы с магазинов. Не суть
Все более или менее так. Только "пред. промт", как вы его назвали, это всего лишь строка. Читаете структуру базы и пишете в этот самый "пред. промт". А структура базы...
Вот сказали вы ИИ: "выдай мне 10 самых продаваемых товаров в прошлом месяце". И получили SELECT.
А сказали "Теперь нам надо вести учет по размерам". И получили ALTER TABLE.
И то запрос, и то запрос. И то выполняется, и то выполняется. Принципиальной разницы нет
Ну и строчи. Кнопку "оплатить" только не забывай нажимать, иначе твой заказ никто не увидит
Вы заключаете договор. Получаете бота. Ваш аккаунт в Телеграм будет администратором. Все прочие - клиентами. Вы, как администратор, заводите список товаров. С момента, как вы завели первый товар, клиенты могут начинать делать заказы.
Не надо ничего устанавливать. В мессенджере общаетесь с ботом
Я вас умоляю. Ну что там может положить сервер? Это же малый бизнес. Мы же начали с чего? Несколько сотен чеков в день. Один чек 100 байт. 100 чеков 10 килобайт. 1000 дней работы 10 мегабайт.
Конечно от id пользователя зависит его роль.
Рассказать, какие у вас товары и сколько они стоят
Какие бэкдоры? О чем вы? Еще раз, я написал все от начала до конца. Кто будет делать бэкдор по вашему? Я?
Поскольку сам писал, от первой до последней строчки, могу уверенно сказать: с нулевой вероятностью. Некуда там воткнуть инъекцию.
Кроме того. Ну, помилуйте! Ну даже если случится невероятное. И кто-то узнает, что клиент с номером 983457893475 10 раз купил мороженое. Ну и что? Безопасность важна, но не надо ударяться в паранойю
Для приема заказов никакое оборудование покупать не нужно. Клиент говорит голосом в свой смартфон.
Вам выдали бота, вы завели список товаров с ценами. Все, можно принимать заказы. Почитайте первую статью. Там все это описано с иллюстрациями
Вы сами себе противоречите. "Не хватает работников, большая текучка..." Так вот же идеальный работник в лице ИИ.
"Нейросеть должна эксплуатироваться специалистом". А зачем он здесь нужен? Что он будет делать по вашему? Объясните, пожалуйста
Добрый день!
1) Вопросы "сращивания" решается так же, как и у всех прочих сервисов, через API. Отправили запрос, получили список заказов. Сейчас такого рода интеграции не требуют особенных трудозатрат и высокой квалификации. Даже джуны справляются.
2) ИИ в общем-то все равно: работать с одним свойством, двумя, 10 или 50. Оно все "скушает" и жаловаться не будет. Как я вижу, тут ограничения возникают с другой стороны. Клиент приходит к вам. Он хочет описать в идеале одним, ну максимум двумя словами, что ему нужно и получить, что ему нужно. Если вы предложите клиенту расписать 25 характеристик товара, он просто развернется и уйдет. Обратите внимание, в ресторанах заказывают салат Цезарь или греческий, но не расписывают по ингредиентам желаемое блюдо. Но, повторюсь, со стороны ИИ тут ограничений нет. Если у вас задача несколько иная, чем прием заказа в общепите, то ИИ не будет вас ограничивать в количестве параметров. 10 так 10, хоть 100!
Если вам хочется поэкспериментировать, напишите в личку, я выдам вам бота
Ну, значит, будем двигать прогресс в ларьках. Будут прогрессивные ларьки и отсталые все остальные )))
Да, и традиционный контрвопрос: а людей, значит, проверять не надо?
Проблема т.н. галлюцинаций LLM связана в первую очередь с тем, что для широких народных масс установлен режим "сказочника". О том, что LLM могут работать в другом режиме они даже не догадываются.
Что касается генерации запросов с помощью LLM, то тут ситуация с возможными галлюцинациями несколько проще, чем в других случаях. Вы задали вопрос. LLM сгенерировала кривой запрос. Ну так он в большинстве случаев просто не выполнится. У вас уже есть естественная система проверки в виде СУБД. Случай, когда запрос все же выполнился, но вместо списка товаров выдал вам список клиентов также не будет для вас проблемой.
Повторюсь, на простых и среднесложных запросах эта технология работает надежно. Надежнее людей. А в сложных случаях надо просто действовать адекватно. Это означает задать один и тот же вопрос несколькими разными способами и разным моделям. Умные люди это и раньше понимали и в ответственных ситуациях привлекали нескольких экспертов параллельно. Ничего не изменилось, только "экспертов" теперь привлечь намного легче, быстрее и дешевле
И вам не хворать