В своей предыдущей статье я намеревался описать цикл машинного обучения чат-ботов в двух частях. В этом посте я расширю свои предыдущие объяснения, поэтому убедитесь, что вы отметили те, что были ранее.

Давайте начнем с краткого обзора: в части 1 мы увидели, как создается поток чат-бота поддержки: либо на основе правил, либо динамически. Во второй части мы рассмотрим, как изменяется поток. Чтобы использовать пример из физики: если часть 1 была о скорости, часть 2 посвящена ускорению (изменению скорости).

Распутывая матрицу замешательства

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

  • Верно положительный (TP): это прогноз чат-бота, который соответствует истинной проблеме пользователя. Другими словами: бот выяснил, что не так, и нашел правильное решение. Если вы хотите знать статус вашего заказа, и бот предоставляет вам именно его, вы видите истинно положительный результат.
  • Ложноположительный (FP): это неправильное решение, предложенное пользователю. Если вы хотите узнать статус своего заказа, и бот показывает вам, как изменить адрес доставки, вы получаете ложное срабатывание.
  • Ложноотрицательный (FN): теперь все становится немного сложнее: этот термин описывает, что происходит, когда бот обучен предлагать решение проблемы, но не предлагает его. Если вы хотите узнать статус своего заказа, а бот останавливает разговор, чтобы передать его человеку, вы видите ложноотрицательный результат.
  • True Negative (TN): это тот случай, если бот не обучен решению пользователя и, следовательно, правильно передает разговор человеку. Если у вас очень сложная проблема с заказом, бот определяет, что требуется помощь человека, и передает разговор, тогда вы видите истинное отрицание.

Я люблю объяснять матрицу путаницы на примере охотника:

  • Истинно-положительный результат случается, когда охотник видит оленя, стреляет в него и попадает в него.
  • Ложно-положительный результат происходит, когда охотник видит дерево, стреляет и попадает в него.
  • Ложноотрицательный результат возникает, когда охотник видит оленя и не стреляет.
  • Истинно-отрицательный результат случается, когда охотник видит, что дерево не стреляет.

Два способа расширения обучающих данных

Посмотрим на нашу модель из первой статьи:

Как видите, обученная модель полагается на обучающие данные, чтобы делать свои прогнозы. (Если вам интересно узнать больше об обучении данных и обучении модели, я настоятельно рекомендую эту серию постов от Адама Гейтгея).

Чем больше у вас обучающих данных, тем лучше должна стать модель. Вот где появляются Истинные Положительные результаты. Они предоставляют образцы из реального мира, которые позволяют нам улучшить обученную модель. Сделать это можно двумя способами: автоматически и вручную.

Элегантность автоматического обучения

(Отказ от ответственности: я не знаю, может ли Эрвин делать то, что я здесь пишу, это просто иллюстрация)

Чтобы машины стали лучше людей, они должны учиться автоматически. В нашем случае это означает, что чат-бот должен добавлять новые точки данных к обучающим данным, чтобы улучшить обучаемую модель.

Давайте посмотрим на это в контексте примера из Части 1. Там я показал вам загадочного бота, который спросил меня: Какой фрукт можно написать, используя только A, N и B несколько раз?. Я правильно решил, угадав Банан.

Если бот посчитал все сыгранные игры, он мог бы сохранить «правильно решено» как точку данных и начать учиться на нем: например, бот мог бы вычислить соотношение «правильно решено» для каждой загадки, а затем оптимизировать свои вопросы, предоставив загадки, которые не являются ни слишком простыми (= 100% правильных), ни слишком сложными (= 0% правильных). Благодаря информации, полученной от таких пользователей, как я, он всегда дает лучшие загадки (например, 90% отгаданных правильно). Это означало бы, что поток со временем будет меняться. И это будет происходить автоматически, то есть без вмешательства человека!

График ниже иллюстрирует вышеупомянутое.

Каждый бот может автоматически изучать разные вещи - с алгоритмическими ограничениями, которые определяют объем изменения потока.

Приведу еще один пример: наши виртуальные агенты в Solvemate узнают популярность решения от True Positives. Чем популярнее решение, тем больше вероятность, что оно будет предложено автоматически.

Я считаю, что автоматическое обучение - это высшая дисциплина для чат-ботов. У него есть потенциал для значительного улучшения этой захватывающей технологии со временем, но это также очень сложно. Что-то может пойти не так, как мы видели на примере Twitter Bot Tay от Microsoft.

Сложность ручного обучения

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

Только представьте, что вы находитесь в совершенно темной комнате и пытаетесь пробить баскетбольный мяч через кольцо. Изучение истинно положительных моментов означает, что вы узнаете, где находится корзина после того, как хотя бы прикоснулись к ней - это дает вам много информации. Если не прикасаться к корзине (= True Negative), вы также получите некоторую информацию. Это означает, что корзина находится не там, где вы достигли, но по-прежнему не сообщает вам, где находится истинное местоположение.

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

Предположим, пользователь хочет проверить статус своего заказа, но у бота нет решения. В этом случае AI Trainer должен вручную добавить «получить статус заказа» в качестве точки данных к обучающим данным и предоставить некоторые формулировки вокруг этого. Тренеры ИИ просматривают разговоры и сообщают боту, что он должен был ответить. Это все равно что учить ребенка вести себя.

Виртуальные агенты Solvemate делают это аналогичным образом: для всех схем, в которых решения были неправильными, инструктор по ИИ должен решить, следует ли им…

  • добавить решение (из-за истинно отрицательного)
  • изменить решение, которое было предложено неправильно (из-за ложного срабатывания)
  • добавить знания, чтобы сделать решение лучше (из-за ложноотрицательного)
  • игнорировать новую точку данных (поскольку запрос не был серьезным)

Все сводится к решению:

  1. Добавление (истинно положительной) точки данных
  2. Не добавление точки данных (= отправить ее на кладбище данных)

На рисунке ниже это показано.

Добавление точек данных к обучающим данным вручную - это нормальный процесс для чат-ботов, который происходит довольно часто. Просто имейте в виду, что ручное обучение может стать значительным драйвером затрат. Подробнее об этом я писал в нашем Калькуляторе ROI чат-бота.

Два цикла улучшения

Таким образом, у нас есть…

  • автоматический цикл улучшения, когда использование бота приводит к новым точкам данных, которые изменяют данные обучения, которые могут изменить обученную модель, что потенциально может изменить ее ответы. Довольно необычно, не правда ли?
  • цикл ручного улучшения, при котором использование бота проверяется людьми, которые решают, хотят ли они добавить новые точки данных к обучающим данным, что изменит обученную модель и потенциально изменит ответы.

Объединение идей

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

Теперь у вас также есть больше предыстории, чтобы понять изменение потока. Спросите поставщика, какие точки данных обрабатываются и как они влияют на цикл автоматического улучшения - если только автоматических улучшений нет.

Последняя мысль

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