Спасибо, Матиас за ответ! Вообще говоря, я согласен с вами, pheraps, что не все чат-боты являются «разговорными», и в простых случаях чат-бот может быть реализован непосредственно на предпочитаемом вами языке программирования.
Это особенно верно для командно-ориентированных чат-ботов или того, что я называю транзакционными ботами: давайте рассмотрим на примере бота, который просто садится в такси. Представьте, что есть бот такси с именем @GenovaTaxibot.
Таким образом, этот бот (опционально реализованный как встроенный бот Telegram) мог просто принимать такие запросы, как:
@GenovaTaxy via Bozzano 2/10
ответ бота будет примерно таким:
ciao Giorgio! taxi ALFA66 in 3 minuti.
Все просто! Но обратите внимание, как ни парадоксально,
это пример не разговорного бота!
У службы такси может быть только один (уникальный) запрос :), и в этом случае жесткое кодирование будет идеальным, простым и быстрым.
Проблема возникает с более сложным диалоговым чат-ботом: я имею в виду бота, который управляет сложным / естественным диалогом с пользователем, где, даже если внутри одного вертикального домена, темы (и количество различных диалоговых потоков ) много, и бот должен понимать конкретные / личные запросы и, возможно, бот должен изучать действия пользователя (память… «сознание») :)
В этом сценарии ботов следующего поколения (поколение II / III?) Я думаю, что жестко запрограммированный способ может стать кошмаром программирования, который поддерживает разработчиков в эпоху спагетти-программного обеспечения / камней «goto». Если использовать метафору в веб-программировании, это может быть похоже на времена, когда мы создавали веб-страницы, записывая HTML-код из внутреннего кода… :(
puts "<html><body>This is a spaghetti-nightmare</body></html>"
Итак, в последние дни я стал большим поклонником :
метаязыки сценария потока диалога: языки для описания разговоров, производящие код исходного сценария, который будет оцениваться механизмом диалога времени выполнения.
Я предпочитаю пример ChatScript с открытым исходным кодом от Сью и Брюса Уилкоксов (мое скромное вступление здесь). Вот пример сценария:
Используя что-то вроде C hatScript (или R ivescript, или S uperscript, не возвращаясь к ужасному AIML…), вам придется научиться, Я признаю.
Но долгосрочное преимущество состоит в том, что внутренняя логика отделена от «интерфейсных» диалоговых сценариев, позволяя сосредоточиться на «разработке» диалоговых программистов от внутренней логики программного обеспечения (базы данных, внутренние службы и др.).
Другими словами, создание сценариев диалогов - это вопрос новой «профессии», более ориентированной на проектирование (?!) / Авторинг человеческих взаимоотношений. И возможный простой метаязык сценариев диалогов (как chatScript?) Откроет создание диалоговых приложений для не-разработчиков (в современном здравом смысле).
Кстати, WIT.ai и API.ai (я использовал и немного наслаждался этим последним) прекрасны, но есть большая проблема, immo, с использованием проприетарной диалоговой системы, расположенной в облаке.
Часть прибыли - модель, большая проблема заключается в том, что в коммерческом приложении или связанном с некоторыми данными пользователей конфиденциальности данные клиентов передаются активатору платформы (это может быть WIT.ai, или API.ai, или pandorabots, или любой другой возможно другое); это огромная проблема, и именно по этой причине я ищу общий язык сценариев диалогового потока и диалоговую машину с открытым исходным кодом (сейчас мой любимый кандидат - chatScript, система с таким многолетним опытом).
Извините за отступление, надеюсь, не слишком не по теме
Респект
giorgio
