Pull to refresh

Comments 102

Никогда не понимал, чем эти боты лучше формы на сайте. В форме:
-Не надо помнить все варианты и их правильное написание — они есть в каком-то списке или меню
-Есть автокомплит и проверка введенных данных
-Есть богатый набор стандартных элементов UI вроде списков\таблиц\чекбоксов\радиобаттонов, которые заменяют по десятку слов

Здесь надо помнить что заявка на командировку будет коректно распознана в форме «я еду в Х на Y в командировку», но черт его знает будет ли она распознана в форме «планирую поездку на Y в Х по делам». Ну и зачем?
Во-первых, бот хорош в нашем случае тем, что он всегда под рукой. Многие наши корпоративные системы с телефона не доступы, нужны авторизация и VPN.
Во-вторых, совершенно не обязательно использовать точный шаблон запроса, потому что бот умный и обучается, даже если мы делаем опечатки.
Если вы выставили наружу бота — почему бы не вставить наружу нужные системы?
Думаю вопрос должен отпасть после прочтения последнего абзаца, как минимум:
Про авторизацию же история долгая и богатая на приключения, поэтому если интересно — расскажу отдельно.
Да нет, никак это не помогает. Что мешает выставить наружу не бота работающего по апи, а http-сервер?
И пилить для него свою обертку, забирая все тот же API, либо посредствам чего-либо публиковать GUI корпоративного ПО? Что мешает использовать уже реализованный клиент обмена сообщениями с жесткой авторизацией и привязкой + API всех ИС компании, при этом связка бот-API крутится внутри периметра, что не дает информации уйти наружу (не авторизованным пользователям)…
Пилить бота, чтоб пользователям приходилось ставить на свои девайсы дополнительный софт, или всё-таки запилить http-сервер, на который можно зайти через браузер с любой кофеварки?..
1. Сервер — ещё одна точка атаки. Нет гарантии что программисты сделают суперзащищённый софт. Под «любую кофеварку» тестировать вёрстку?
2. У меня на даче такой интернет, что устойчиво работает только Телеграм.

Сделайте нормальный UX для ваших систем и боты не понадобятся. Все упирается в убогий, непонятный, глючный интерфейс корпоративных систем, к которым еще и авторизация с ВПН нужны (нафига????).


Боты в 99% случаев это отмазка чтобы не заниматься UX. Как командная строка у юниксоидов. Только на уровне пользовательских приложений.

Покажите мне 5 сложных GUI, с которыми вы с самого знакомства испытывали положительный UX. Постоянная проблема — GUI может быть быстрым, но его надо понять, на это нужно время и n итераций взаимодействия по разным сценариям. А теперь представьте, что это не единственная система, в которой вы работаете.

При чем тут сложные UI, если мы говорим о приложении, которое выдает сколько дней до зарплаты?

А мы говорим о многофункциональном приложении, которое не только считает дни до зарплаты. Все функции очень простые сами по себе, но их количество заставляет хорошо подумать над GUI при его реализации.
командная строка у юниксоидов.

Вы так говорите, как будто в вашем представлении это что-то плохое :)

Сама командная строка не плоха для некоторых задач. Но выдавать её за хороший универсальный UI — глупость.

Разумеется, для каких-то задач командная строка хороша, для каких-то нет. Например, Хабр читать через командную строку я вряд ли буду (а уж тем более не буду писать сюда через командную строку). Однако, есть множество задач, которые удобнее решать именно в консоли.
Но на мой взгляд утверждение о том, что «в 99% это отмазка, как командная строка», выглядит весьма сомнительным утверждением с цифрами, взятыми с потолка.
Универсальность командной строки — это хороший и универсальный UI.

Она пережила переход от 1200-бодных модемов на гигабитные линки.
Она пережила переход от текстовых дисплеев на графические терминалы с antialias шрифтами и копипастой мышкой.
Она пережила переход с мейнфреймов на десктопы, роутеры кучу других устройств.
Что немаловажно, командную строку очень легко имплементировать с минимальными требованиями к ресурсам.

Поэтому говорить, что она плохая, и есть однозначно лучшие универсальные варианты — неправильно.

Конечно, командная строка неидеальна. Но вы сможете назвать более универсальный UI?

На то они и боты, что бы автоматизировать либо ускорять какие-то процессы. Имхо.
К примеру, для отправки в командировку нужно только имя, фамилия, дата отлета, дата прилета и страна/город назначения. Все остальное, обычно, является шаблонным текстом и не меняется. Почему бы не автоматизировать процесс подачи заявки на командировку отправкой одного сообщения боту? А по указанному бизнес-процессу эту заявку получат руководители отдела и подтвердят опять же одним сообщением: Ок/окей/хорошо и т.п…
На все это уйдет минимум времени и не нужно за всеми бегать и упрашивать поставить подпись (как такое было у меня).
В компании, где я работаю, многие процессы были автоматизированы именно ботами. Хотя изначально использовались простые скрипты, которые никак не могли управляться администратором удаленно.
А лично у меня таким способом делается 90% работы + примерно по 50% работы делается ботом для менеджеров/продажников/маркетологов. Конечно, для такого результата пришлось потратить кучу свободного времени — но теперь мой отдел справляется выполнить очень высокие планы продаж. А дополнительная премия в конце квартала — это приятно!

UFO just landed and posted this here
Примеры в статье показывают, что бот вполне неплохо разбирается в свободном тексте.
А удобство — в скорости!!!

Вы не представляете, как много может быть разных сайтов хелпдеск, vacationdesk, salarydesk, jira, какой-то еще список, и все это на разных URL, иногда даже с разным видом авторизации. И каждая страничка может открываться по нескольку секунд, потом еще залезть в менюшки, подменюшки, вспомнить что это не тут и лезть в другое…
Если это все можно объединить в бота, с которым ты общаешься в одном и том же мессенджере, в одном и том же окошке, и ты точно знаешь, что бот будет знать самые свежие данные, а не «вот этот сервис у нас уже полгода как заменен другим, а вот этот уже отключен, а вот три новых появилось, но ты про них не знаешь» — это уже круто.
Даже запрос типа «где посмотреть мое расписание отпусков», если будет не ответ а хотя бы точная ссылка — это уже крайне удобно.

Я подозреваю, что работы для создание бота и поддержание его в актуальном виде, который общается так, как в этой статье — огромный труд, но это выглядит действительно круто!
А я подозреваю что если поменять порядок слов, или использовать незнакомые боту синонимы то получится полная ерунда. Если бы это было не так — подозреваю уже громко кричали бы про сильный ИИ. Итого мы имеем, что вместо продирания сквозь тысячи форм мы имеем необходимость помнить о некоторых волшебных словах, которые нужно говорить боту. Не уверен что второе лучше, хотя выглядит конечно забавно.
UFO just landed and posted this here
в таком случае как вы относитеть к Siri и wolframalpha.com? тоже не нужно? по вашей логике ведь есть энциклопедии и справочники, и закладки на нужные сайты.

Я добавлю от себя, чем хорош хорошо сделаный бот — он дает информацию в удобном для вас виде. Например мне чтобы проложить маршрут на общ. транспорте по городу, придется минут пятнадцать возиться с сайтом подгадывая время и выписывая нужные данные. А бот он не просто дает сухую справочную информацию а совмещает ее и оборачивает ее в контекст, и например может ответить «если выйдешь сейчас и сядешь на единицу — будешь на работе без пятнадцати двенадцать» и когда я выйду из единицы, он мне скажет куда пересаживаться и что делать. Не бегать с бумажкой и квадратными глазами, а получать нужную информацию в нужное время. Просто цифровой секретарь. Все прогрессивные технологии в начале высмеивали из-за кажущейся избыточности а потом жить без них не могут. Так что ребята двигаются в правильном направлении, я не сомневаюсь. Когда на рынке появится первый конструктор для корпоративных электронных секретарей мы вспомним этот пост.
В этой «технологии» нет ничего «прогрессивного». Ещё лет 25 назад боты в IRC умели по командам выполнять некоторые действия: скачивать файлы, банить юзеров, отправлять почту. И всё плавно закончилось с распростанением веба.
приципиально нового конечно нет ничего. Но это прогресс, потому что (если обобщить понятие прогрессса) оно изменяет жизнь к лучшему.
При большом количестве вариантов меню будет перегружено и сделать его user friendly так, чтобы люди не тратили ресурсы своего мозга на разбор, очень непросто. В тоже время бот, который хотя бы находит наиболее подходящее слово или синоним, достаточно просто. К тому же все разобранные задачи достаточно типовые, ошибиться в ответе сложно.

Еще я заметил, что чат-бот в какой то степени является гибкой консолью — используются все те же принципы, только на новом уровне и с вкраплениями GUI там, где это действительно улучшает UX.
Чатбот, описанныей в статье, работает именно потому, что он «внутряковый». С ним можно более-менее подружиться и, если букать переговорку или ездить в командировки приходится по 10 раз в месяц, то набрать пару букв команды и правда быстрее, чем лазить по перегруженному интерфейсу. Вы правильно сказали, что это напоминает продвинутую консоль. Тот, кто выучил, условно, grep, и пользуется им по 20 раз в день — существенно выигрывает в скорости по сравнению с пользователем аналогичного инструмента с UI.

Но давайте посмотрим на применение этого для массового рынка. Зашел я, например, на сайт какой-то фирмы, там контакт бота в телеграме, стучу я ему, а он «чем могу помочь?». И вот хрен его знает что ему писать, какие команды он знает. И что дальше — читать документацию? Перебирать варианты? И зачем мне это делать, если моё обращение в эту фирму первое и последнее? Я закрою бота и поищу варианты в меню сайта, или позвоню живому человеку.
если это массовый рынок linux утилит, вас может и отправят читать мануалы :D, но в общем случае это головная боль программистов — сделать так, что бы рандомюзер зашел и сразу нашел то, что нужно без лишних раздумий. Сири, Кортана и прочие очень неплохо решают эту задачу для некоторых сфер деятельности. Пример выше тоже справляется в своей области. Но в целом массовому продукту ни чат-боты ни сложные гуи не нужны. Сейчас наоборот идет тенденция к упрощению всего и вся. Есть отдельные сферы, где это нужно и даже примеры реализации таких чат-ботов, там их и следует применять, условно не пихая вайфай в каждый носок. Такие чат-боты очень пригодились бы в тех.поддержке, существенно разгрузив первую линию ТП или хотя-бы частично автоматизировав поиск решения. Емнип, они уже даже используются в YouDrive (я не пользуюсь, поэтому проверить не могу)
но в общем случае это головная боль программистов — сделать так, что бы рандомюзер зашел и сразу нашел то, что нужно без лишних раздумий

Это работа UX/UI специалистов, не надо на программистов это сваливать может быть тогда будут нормальные интерфейсы в рунете?..
С каких-пор чат-боты пишут UI специалисты? Может от этого вы так и не любите чат-боты?
Вы не путайте пожалуйста «написать бота» и «сделать интерфейс для бота». Программированием бота занимаются конечно же программисты, но интерфесом должны заниматься люди которые разбираются в интерфейсах, люди которые понимают толк в подаче информации, общении с пользователем.
UX/UI специалист нужен ровно наоборот, не чтобы боты понимали людей, а чтобы люди понимали бота.
мне кажется, оба процесса понимания идут параллельно. И тут важно соблюсти баланс между одной понятной пользователю кнопочке «сделать хорошо» и миллиону параметров, понятных и удобных алгоритмам, заложенным в приложение. В любом случае, я не верю, что при решении данной задачи в Крок или при решении аналогичной задачи где-то еще, UX/UI специалист может помочь чем-то.
Если не секрет:
  • на чем написан бот?
  • как реализована функция разбора сообщений пользователя
  • Не секрет. Node.js
  • С божьей помощью. А если серьезно, то все сообщения проходят через модель машинного обучения, где определяется намерение (intent) и сущности (entity)
С божьей помощью

Да ладно вам, все знают как этот бот работает:
ротор поля наподобие дивергенции градуирует себя вдоль спина и там, внутре, обращает материю вопроса в спиритуальные электрические вихри, из коих и возникает синекдоха отвечания

машинное обучение они тут припахали, тоже мне. Народу не нужно машинное обучение — народу нужна работа на свежем воздухе! :)
Неонку забыли. Без неонки работать не будет.
А Вы случайно не L.U.I.S. вместе с Microsoft Bor Framework используете?

Некоторые скриншоты напоминают NODE-RED — используете его для настройки бизнес логики?

Эволюция интерфейсов:
Консоль — GUI — чат бот

А консоль — это и есть чат бот, причем очень даже умный.

основное преимущество чатбота перед консолью в том, что он не требователен к синтаксису запросов. Консоль не помогает пользователю (даже если есть автокомплит — он не очень) а бот может вести и задавать наводящие вопросы, давать пояснения или уточнять информацию. В том числе — сохранять контекст предыдущих диалогов, если надо.
Если писать чатбота без обучения — тогда это просто вебконсоль — упрощенный способ спихнуть разветвленный UI на голову пользователя.

Консоль тоже может быть нетребовательна к синтаксису запросов. Если вы согласны с 1% шансом сделать rm * -rf

Консоль — GUI — чат бот — GUI карточки в чате.

В описанном в статье примере, последний шаг эволюции вызывает вопросы. Например, диалог о выписке пропуска на 5-10 раз будет раздражать, хорошо сделанный GUI тут был бы предпочтительнее (лично мне). Аналогично и другие кейсы. Почему-то в качестве альтернативы в статье рассматривается только «100 мобильных приложений», а не например одно приложение с понятным меню с удобной группировкой кейсов.

Да любой gui лучше, не обязательно хороший. Чат боты это такая зараза, уже из каждого второго приложения торчат. Надеюсь эти эффективные менеджеры все-таки наиграются или получат свои повышения за умные технологии и свалят в фейсбук или куда сейчас модно… И тогда эту бесполезную заразу можно будет выпилить.

Сорри за негатив, накипело. Потратил пол года чтобы пилить клиента для такой лабуды, вместо тупой странички с формочками, которая по полезности, понятности и скорости была бы лучше в разы.

А можно узнать, как вы сделали разбор фразы??
Добрый день! Спасибо за статью!
В процессе прочтения возник вопрос — Как происходит разбор сообщения ботом?
А если нужно поехать в город Лондон, который находится в Канаде?
Или например сотрудник обрадовавшийся поездке в Рио-де-Жанейро сказал боту, что едет в Бразилью! Но ему Т9 любезно подсказал "Бразилиа", бот купил билеты в столицу Бразилии — город Бразилиа, и привыкший к такому комфорту сотрудник ни о чем не подозревая полетит не туда :)
А еще бывают ведь такие ситуации, когда у сотрудника есть пожелания по пересадке/стыковочному рейсу, но чат-бот ведь этого не учтёт?
а ещё можно в столовой насыпать в общественные солонки пургену… и доверчивый сотрудник, ну вы поняли… :)
Да, неплохо бы научить бот выявлять сотрудников, настолько идиётов и увольнять их в автоматическом режиме :)
Бот пишет тикет в бухгалтерию и письмо специалисту, отвечающему за покупку билетов и бронирование в поездках.

То есть бот сам ничего и не покупает.

И скорее всего есть возможность отмены заявки / её редактирования каким-либо путём (допустим, фразой «Ой, там должно быть...»).

А насчёт Лондона в Канаде — так и нужно писать «Еду в командировку в канадский Лондон», ибо без уточнения и обычный человек скорее всего не поймёт =)
канадский Лондон — написать можно, но поймет ли это бот как надо? автоматически всех нюансов ни машинное обучение ни парсинг регулярками не даст, если изначально такие мелочи не предусматривать.

и бугалтерия скорее всего тоже неичего не заподозрит, ну едет человек в лондон и что такого? про канадский они скорее всего даже не знают.
Ответственный за командировки просто должен увидеть переписку и в случае необходимости связаться лично.
Хотите точности в мелочах — используйте строгие интерфейсы взаимодействия
А какой стек? Что используется для разбора фразы на intent/entity? Что используется для интеграции с чатиками (msbot framework?)
Стек node.js, express и mongo (был MS SQL). С разбором фраз много чего перепробовали, в итоге сейчас используем api.ai. Оказалось оптимально по соотношению гибкость API и скорость работы. Bot Framework не используется, все через коннектор к Tg готовым npm пакетом.
1. Обнаружил, что нельзя удалить сообщения после 48 часов после создания(документация), но не изменения. Плохо…
2. «Нужно найти сотрудника или контрагента» — почему не используете inline-клавиатуру?
3. Контролируете ли «скорость» отправки сообщений пользователям? Ведь есть лимиты (сообщений в минуту)? Действуют ли эти лимиты когда отвечаете на входящее сообщение в webhook?
1. Правило 48 часов — не про нас. Бот – не обычный пользователь, он читает сообщения и реагирует практически мгновенно.
2. В некоторых случаях мы используем инлайн-клавиатуру, но помимо нее также разбираем ответы, написанные текстом. Но лично мне было интереснее обучать бота, чем давать пользователям готовые варианты на выбор. В этом же конкретном случае кмк особо разницы нет – инлайн или обычную клавиатуру использовать.
3. Лимита на отправку сообщений пока не достигали.
3. Лимита на отправку сообщений пока не достигали.
это странно, т.к. Лимит этот ~30 исходящих сообщений в секунду.

Сто раз уже всем объясняли, в том числе и на иностранных ресурсах, что у чат-ботов нет будущего: ну не будет человек набивать руками текст — это утомительно и не производительно.

Прикрутить к боту кортану/siri/Alexa и чат-боты внезапно попадут в топ?
А нафига тогда бот-то нужен? Просто подключить «кортану/siri/Alexa» к нужному апи.
Если всё грамотно написать, то проблем привязать готовый back-end к новому front-end не будет
Все популярные мессенджеры (телеграм, вайбер, фейсбуковский — это те с которыми я лично работал) поддерживают кнопки в сообщениях. Поэтому сообщения с выбором из нескольких вариантов делаются кнопками, а вот если пользователь сам толком не знает что хочет (либо список вариантов слишком велик) то ввод произвольного текста и его распознавания неплохо помогает.
Так на штатных клавиатурах (что на android, что на ios) есть кнопка голосового ввода — вводишь «голосом», распознанный текст подставляется в текстовое поле ввода. В результате можно вводить как руками (когда невозможно голосом) и голосом.

чему?


работе до ночи?


см. скрин с маршрутками — крок в своём рэппертуаре

Ой, да ладно вам. Это же не в сталилитейном цеху 3 смены без перерыва. У всех, думаю, бывают периоды чрезвычайной увлеченности тем или иным проектом. Ведь это же супер, когда работа совпадает с твоими интересами. Но рано или поздно возвращаешься в рутину — борьба с тикетами с 9 до 17.
Не могли бы подробнее рассказать про классификацию запросов и выделение именованных сущностей (какие методы и т.д.)?
Если в России все-таки запретят телеграмм (VPN и другие методы обхода уже запретили), как будете выходить из этого положения?
Готов спорить, что они сделают отдельный модуль «авторизация в мессенджерах».
И там — только плати за саппорт: хоть аська, хоть LINE, хоть векторный фидонет, не будь он к ночи помянут.

Читаю, и не понимаю, зачем это всё нужно, или это просто дань моде.
Обычный бизнес-процес со своей статусной моделью, и интерфейс вывода. Только на выходе "веселенькое" уведомление от бота вместо сухого статуса. Ну так лично мне статус удобнее.
На входе "неструктурированный" запрос. Да, именно в кавычках, т.к. структура в нем есть, набор ключей.
Тем не менее, автору большое спасибо за материал, и пару вопросов, если не возражаете:


  1. Есть примеры "неадекватного" поведения бота, или непонимания комманд, нарушения логики.
  2. Какой процент успешных запросов к боту к общему количеству запросов?
  3. Сколько всего реализованно диалогов (задач, бизнес-процессов)?
  4. Как работаете с "отчепятками"?
  5. Проводился ли опрос сотрудников по работе с ботом?
    И вопросы не только к автору, но к остальным участникам. А кто нибудь считал:
  6. Сравнение стоимости обычного бизнес-процесса со статусной моделью, и чатбота
  7. Эффективность пользования вводной частью в обычном бизнес-процессе путем выбора необходимого действия из предложеных, или через чат-бот
  8. Эффективность отслеживания статусной модели в бизнес-процессе, или в чат-боте

Ещё раз спасибо.

1. Конечно, бывают ошибки, особенно на ранних стадиях, пока шло обучение, бот не понимал многих фраз, путал сущности. В этом смысле он как ребенок, чем больше уделяешь внимания его обучению, тем он умнее.

2. Честно сказать, в процентах не считали. Ситуация постоянно меняется – добавили новую функцию, стал чаще ошибаться, подучили – опять все в норме. По нашим ощущениям в 9 из 10 случаев должен понимать правильно.

3. Если ответы по «базе знаний» и smalltalk считать за одну задачу, то 11.

4. В целом машинное обучение справляется с задачей. Но дополнительно используем спеллчекер от Яндекса – почти на каждое сообщение, через API. Но там тоже много интересных моментов – работает не всегда как ожидается, нужно помнить об исключениях (например, названия технологий и имена информационных систем).

5. Да, в самом начале делали опрос про бота через самого бота. Что касается самих опросов, их делать было сложно с точки зрения контента – все вопросы и ответы нужно адаптировать под экран мобильного. Сейчас пользуемся отдельным сервисом для опросов, а результаты в бот возвращаются через webhook.

6. Чат-бот не исключает существование обычного процесса. Так или иначе они должны где-то существовать. Чат-бот — это, скорее, современный и (в некоторых случаях) более удобный интерфейс, чем многие корпоративные системы.

Спасибо. Вижу принципиально иной подход к работе и результату, относительно нашего :)

Интересная статья, интересное применение бота.

Затем он ищет пользователя по хотспоту Wi-Fi в офисе, чтобы определить ближайший доступный принтер

А можно про этот момент подробнее, как он это определяет?

Бот может обращаться к таблице соответствия хотспотов Wi-Fi в офисе конкретным принтерам или их набору.
Но если подключить ко всему этому follow-me printing, то пользователь сможет получить распечатанный документ на любом офисном принтере, к которому он приложит свой пропуск.
Про авторизацию интересно, напишите пожалуйста
Авторизация реализована через стандартный механизм Tg с запросом номера телефона (в API это request_contact). Бот ищет сотрудника по номеру, и если в HRMS такой есть и не уволен – пускает его на час. Через час проверяет – если пользователь все еще есть в базе, сессия продляется еще на час и так далее.
Чувствуется, сферу техподдержки скоро ждет нашествие чат-ботов.
Не понял, что подразумевается под «шиной». Доступ к какой-то корпоративной БД? Доступ к интерфейсам корпоративных систем?
Можете пояснить?
У вас, кажется, на первом скриншоте ус отклеился время доступности переговорки сообщает не бот, а юзер.

Думаю, время было отправлено через кнопки

Тогда были бы кнопки, на всех остальных скринах они есть

Да, временные интервалы были отправлены через кнопки, вот как тут (в диалоге они потом исчезают):

Для разбора английского есть, к примеру, https://api.ai/


А вот русскоговорящих штук в свободном доступе не встречал. Возможно просто не искал

так они его и используют, с русским он работает

По поводу авторизации я в свое время использовал вариант с добавление в общие чаты. Бот может проверить состоит ли пользователь в том или ином чате и исходя из этого принимать решения.
В чате несколько админов, уполномоченных на прием/удаление пользователей.

Проблемы начинаются, когда боту нужно инициировать чат с пользователем. Нельзя просто взять и написать пользователю по никнейму/телефону

А никогда так и не было. Пользователь всегда пишет боту первый. Это в любой системе с ботами фича такая)
Да да, про аутентификацию напишите поподробней
Здорово, конечно! Только лично мне как-то неприятно, когда незнакомые люди боты ко мне обращаются на «ты».
Клево вышло, мы у себя только для внутренних процессов билда, деплоя и ребута сделали.
Есть куда расти.

Кто нибудь знает статьи/хелпы по работе с api.ai? Из собственный хелп не сказать что бы очень ясный. Если кто готов проконсультировать — отзовитесь пожалуйста.


Мы в Подмосковье с помощью бота ищем попутчиков до метро. Пока все кнопками.

Nika_Voronova спасибо за статью!

1) Почему не использовали конструкторы типа Chatfuel, manychat? Не пробовали или наткнулись на ограничения?
2) Какие NLU движки тестировали? Wit.ai, MS LUIS, Amazon LEX, Recast? Почему выбрали гугл?
3) Почему не использовали русский ЦРТ ChatNavigator? Я знаю в Крок вроде бы любят эту компанию :)
troshchenko спасибо за отзыв!
Отвечаю по пунктам:
1) Конструкторы не использовали т.к. они облачные, а персональные данные россиян должны храниться и обрабатываться на территории РФ. Плюс сама идея интеграции бота, размещенного «где-то там», с корпсервисами вызывают большие вопросы у ИБ.
2) Выше отвечала на этот вопрос. Если вдаваться в детали, то Wit начинал тормозить, как только база интентов разрасталась, а у кого-то из перечисленных Вами не было русского на момент старта. API.ai оказался самым удобным и быстрым для нас. Хотя могу точно сказать, что «идеального» AI мы пока не нашли.
3) В КРОКе решениями ЦРТ плотно занимается другой департамент. Я с ними пока не работала, поэтому тут пошли по другому пути.
Главный вопрос: зачем это? У вас же есть вроде достаточно вменяемый портал с заказом переговорок?
Sign up to leave a comment.