Кодиране на платформа за създаване на чатбот, Част 1: Как да направите тъп чатбот

Как се справих с предизвикателството да създам програмно „разговори“.

Миналата седмица реших да създам приложение за създаване на бот. Целта беше (и все още е, тъй като проектът ще бъде готов през следващата седмица) да се направи приложение, което служи като платформа за потребителите от всички нива за изграждане на прости чатботи и да ги домакин на моя сайт. В тази публикация в блога от две части ще разгледам моя процес и някои ценни източници за изграждане на платформа за ботове - първо глупави, а след това, функция по функция, по-интелигентни. (Когато пиша глупаво, нямам предвид куца или лоша. Чатовете ми са готини, но те са далеч от интелигентните)

Какво прави минимален жизнеспособен чатбот?

Най-просто, намирането на правилния отговор на съобщение преминава през възможно най-много проверки, преди в крайна сметка да предложи резервен отговор: „Не разбирам“. Реших да използвам този подход, за да изградя своя чатбот. По този начин мога да продължа да добавя повече слоеве „съответства ли съобщението на това парче от нещата, които ботът ми знае“ към моя минимален адекватен чат. Ето моите първоначални цели:

  1. Потребителите могат да скриптират своите собствени диалози. Потребителят може да добави „тригери“, което означава думи или изречения, на които техният бот ще отговори. Те ще могат да определят масив от различни отговори, колкото искат. Ако ботът е в състояние да съпостави получено съобщение с неговите задействания, той ще избере случаен отговор. Това формира „скриптите“ на всеки бот.
  2. Роботите ще могат да предлагат общи скриптове (като поздрави и отговори на често задавани въпроси) и резервни отговори „Не разбирам“, ако потребителят реши да ги включи.
  3. Ботовете трябва да са прилични да разбират какво им казва потребителят, дори ако това не е точно съвпадение с известни тригери.

Тези характеристики правят моите ботове „базирани на извличане“, както е описана в тази отлична статия. Разговорните модели, базирани на извличане, са по-лесни за изпълнение, тъй като използват хранилище от предварително зададени отговори и някои правила, за да ги изберат. Другата възможност би била създаването на чатботи, които са в състояние да генерират свои собствени отговори, но този подход би бил много по-отнемащ време и склонен към граматически грешки. Нямаше да ми е ясно как да предложа на потребителите възможността да скриптират тези ботове с персонализирано въвеждане.

Изграждане на строителния бот

Простите цели превеждат добре реалните технически характеристики. Скриптовата платформа, която реализирах с React, е основно динамична форма, която расте и се свива по избор на потребителя. Няма ограничение в броя задействания или отговори, които можете да добавите. Във фазата на скриптове потребителите могат да тестват своите ботове и след това да ги запишат, след като са доволни от скриптите си. Те ще могат да редактират бота, да разговарят с него или да споделят връзка с всеки, който да разговаря с бота, както е хостван в моя сайт. Всяко съобщение, което ботът получава, се изпраща на моя Ruby on Rails бекенд, където процес на съвпадение се опитва да намери правилния отговор и го изпраща до лицевия потребител (потребител).

На този етап вече бях въвел някакво просто "чистене" на низове, като премахване на не-азбучни знаци и бяло пространство, но ботовете бяха нещастни при разбирането, различно от много точно съвпадение. Те казаха "Не разбирам" много и това не беше страхотно потребителско изживяване. Той наистина подчерта факта, колко е трудно да се имитира дори и простия човешки диалог програмно.

След като избрах основната логика, която всички мои ботове трябва да приложат, аз се насочих към скриптове на тригери и отговори по подразбиране. На платформата за скриптове на бот на фронтовите потребители потребителите могат да се включат в малки скриптове по подразбиране, като поздрави, сбогувания, лесни въпроси (напр. „Как сте?“) И екзистенциални въпроси (напр. „Какво сте?“). Ботовете станаха малко по-малко глупави след това просто допълнение.

Прости скриптове по подразбиране

Размита струна, съвпадаща за печалбата

Последната стъпка за моя тъп бот производител беше да приложа „размито съвпадение на низ“. Има невероятна скъпоценна скъпоценна камък и библиотека за това. Вместо да сравнявате дали string1 == string2, размитото съвпадение на низ изчислява разстоянието между два низа. Скъпоценният камък използва алгоритъма на разстоянието Jaro-Winkler, за да върне стойност между 0 и 1, за да представи сходство между низовете. 1 означава, че думите са еднакви, 0 означава, че изобщо не са подобни. Поставих прага на съвпадение по подразбиране на моите ботове на 0,8, тъй като изглежда, че минаха печатни грешки или допълнителни думи за пълнене, като същевременно не липсваха напълно значими разлики. Инициализирането на екземпляр за сравнение беше лесно (fuzzy_match = FuzzyStringMatch :: JaroWinkler.create (: native)) и затова го използвах.

Използване на скъпоценния камък

Моят краен метод за намиране на правилния отговор на това съобщение включва всички тези три проверки. Направих някои правила за даване на приоритет на отговорите, в случай че някое потребителско съобщение ще съвпадне с повече от един тригер. На този етап тези правила просто се проявяват в реда на моя метод на съвпадение.

1) съответства на сценариите на потребителя

2) скриптове по подразбиране съвпадения

3) намерете улики от предишен разговор (все още не е приложен)

Трите основни характеристики заедно изведоха ботовете на доста адекватно ниво. Щастлив видях, че моите ботове не се притесняват твърде много от печатни грешки, знаех да дават приоритет на сценариите на потребителя и знаех да предлагам отговори по подразбиране на някои общи съобщения. Експериментирах с основни и начинаещи приятелски реализации за машинно обучение, за да добавя допълнително разбиране към моя строител на ботове, което ще документирам за следващата част от тази публикация в блога.