Парад релизов: обновление языка — PHP 8.0, а также Xdebug 3, DBAL 3.0, Bref 1.0, Symfony 5.2, Flysystem 2.0. Первый принятый RFC для PHP 8.1, долгосрочная поддержка PHPUnit, порция полезных инструментов, подкасты, стримы, статьи.

Приятного чтения!

• PHP 8.0.0 — Долгожданный релиз языка доставлен строго по расписанию. Спасибо всем контрибьюторам и релиз-менеджерам Gabriel Caruso и Sara Golemon!

  Облако контрибьюторов PHP 8 от php.watch

  

  Наиболее заметные изменения:
  • Именованные аргументы
  • Атрибуты
  • Объединенные типы
  • Объявление свойств в конструкторе
  • Выражение match
  • Оператор nullsafe
  • Улучшенное сравнение строк и чисел
  • Ошибки согласованности типов для встроенных функций
  • JIT

  Максимально полный список изменений есть в документе php-src/UPGRADING

  Документация по большинству изменений еще в процессе. Присоединиться к ее дополнению можно отправляя пул-реквесты в репозиторий php/doc-en.

  А пока можно посмотреть обзоры релиза:

  • php.watch: PHP 8.0: What’s New and Changed
  • stitcher.io: What’s new in PHP 8
  • stitcher.io: PHP 8: before and after
  • PHP 8 — try out all new features — Обзор изменений с интерактивными демо от Marcel Pociot. Перевод.
  • Использование PHP 8 в PhpStorm 2020.3, который выйдет на этой неделе.
  • PHP 8 — Что нового?

  Видео

  • Обзор от Валентина Удальцова.
  • Laracasts: PHP 8 Crash Course — Шикарный курс по PHP 8 от Jeffrey Way.
  • Серия видеороликов по всем новым фичам от Spatie.
  • Видеокурс по новым фичам от Marcel Pociot и BeyondCode.

  С выходом 8.0 закончился период поддержки PHP 7.2, а PHP 7.3 перешел в режим только секьюрити фиксов. Вот инструкция как установить PHP 8.0 на Ubuntu, Debian, CentOS, macOS и в Docker.

Новости и релизы

• Xdebug 3 — Большое обновление популярного отладчика. Теперь он быстрее в работе и значительно проще в конфигурации.

  Для старта достаточно одной опции xdebug.mode, а дефолтный порт сменен на 9003, чтоб не было конфликта с PHP-FPM. Подробнее в руководстве по обновлению.

  Сравнительные бенчмарки Xdebug 2 и Xdebug 3 показывают значительный прирост производительности. Для сбора покрытия он даже быстрее, чем phpdbg, хоть и медленнее PCOV.

• Bref 1.0 — Релиз инструмента, который облегчает создание serverless-приложений на PHP и AWS Lambda. Кстати, теперь с поддержкой WebSocket — удержание соединения берет на себя API Gateway.
• doctrine/dbal 3.0 — После 10 лет с выхода DBAL 2.0 наконец-то мажорное обновление популярной библиотеки для работы с базами данных. Короткий обзор есть в анонсе релиза. Главные изменения касаются отвязки DBAL от PDO. Все fetch-методы перенесены из класса Statement в новый Result.
• thephpleague/flysystem 2.0 — Обновление библиотеки, абстрагирующей работу с файловыми системами. Что нового в версии 2.
• PHP 7.4.13
• PHP 7.3.25
• В твиттере продолжились споры о том, стоит ли поддерживать старые версии PHP в опенсорс инструментах. Никита написал, что инструменты, в которых минимальная версия PHP повышается слишком резко, в действительности приносят больше проблем на пути к обновлению PHP.

  .
  Ранее эта же проблема обсуждалась, когда Марко Ocramius бампнул версию в своем пакете Ocramius/PackageVersions до 7.4 (уже и до 8.0). В результате чего в Composer 2 пакет заменили на форк composer/package-versions-deprecated.

  Так или иначе, а PHPUnit 9 и PHPUnit 8.5 получат Life Support. Это значит, что в них будет гарантирована работа на PHP 7.3 (7.2 соответственно) и всех последующих версиях PHP.

PHP Internals

• [RFC] Explicit octal integer literal notation — Не успели выпустить PHP 8.0, а уже принят первый RFC для PHP 8.1! В следующей версии языка восьмеричные числа можно будет записывать с префиксом 0o.

  0o16 === 14; // true 016 === 0o16; // true 

Инструменты

• phpsandbox.io — Аналог codepen/jsfiddle только для PHP. Веб-сайт для быстрого тестирования и демонстрации кода. Кроме голого PHP можно сделать код на Laravel, ReactPHP или импортировать любой проект с Гитхаба.
• beyondcode/httpdump — Приложение на Laravel для отладки водящих HTTP-запросов (отладка веб-хуков и т.п.). Создает случайные URL и дампит в красивом виде все запросы к ним. Демо httpdump.app.
• clue/php-socket-raw — Легковесная ООП-обертка для низкоуровневого расширения сокетов PHP (ext-sockets).
• zenstruck/foundry — Фабрика для создания удобных фикстур с автодополнением в IDE для Symfony и Doctrine.
• spatie/backtrace — Обертка над debug_backtrace() для удобной работы со стеком вызовов.
• nette/tracy — Инструмент для отладки: дебагбар, красивые ексепшены, логирование, профилирование, все в одном.
• JetBrains/phpstorm-attributes — В PhpStorm 2020.3 будут из коробки доступны несколько атрибутов PHP 8. Теперь они вынесены в отдельный пакет.

Symfony

• Symfony 5.2 — Список новых возможностей.
• Бенчмарки Symfony 5.2 на PHP 8.0 и 7.4.
• Неделя Symfony #726 (23-29 ноября 2020)

Laravel

• Защита от спама в Laravel приложениях
• Как отправлять уведомления в Laravel с помощью пакетов beyondcode/laravel-websockets и laravel/echo.
• Laravel Internals #1: 18 Nov, 2020 — Стрим с Nuno Maduro и James Brooks, участниками команды Laravel, о новостях в разработке фреймворка и инструментов экосистемы
• Laravel–Дайджест (9–22 ноября 2020)

Разное

• Front Line PHP — Книга про разработку на современном PHP от Brent Roose и Freek Van der Herten. В канале было как получить дополнительную скидку.
• Памятка по фишкам синтаксиса PHP 7.4 и 8
• Brent Roose пишет о том, как вести блог разработчику — Он стартовал свой stitcher.io s 2017 и сейчас блог посещает больше 1.5 млн пользователей в неделю.
• PHP Tools — назад в 90е — Запускаем и анализируем PHP 1.0.
• Как безопасно реализовать восстановление пароля на PHP.
• PHP 7.4 FFI: Что вам нужно знать
• API для QA: тестируем фичи без доступа к коду
• Ускоряем и стабилизируем автотесты на codeception + selenium
• Финальные классы в PHP, Java и других языках
• Сейчас я буду убеждать вас использовать статический анализ в PHP — Расшифровка подкаста Между Скобок № 11.

Аудио/Видео

• PHP 8: что нового, туда ли двигается, что будет дальше — Стрим с обзором PHP 8 от Валентина Удальцова (Пых), и ответами на вопросы от Никиты Попова и Дмитрия Стогова, двух топовых разработчиков PHP 8.
• Публичное собеседование: PHP-разработчик [Хекслет] — Пока мы с Валентином прокрастинируем готовим открытое собеседование на PHP Point, можно посмотреть альтернативу от Хекслета.
• Подкаст Remote Talk — В гостях Сергей Жук: про PHP, плохо ли на нём писать, книги в IT, подкаст «Между скобок».
• Видеозаписи с прошедших митапов:
  
  • Запись с митапа PHP NN #3 – Опыт перехода с MySQL на Postgres на реальном проекте, советы по написанию кода и жизни после 30.
  • Доклады от краснодарского PHP-сообщества: легаси, автотесты и работа с реляционныи БД.
  • Как устроен деплой в Лайфхакере (Александр Нагорнов, Lifehacker.ru) – Опыт перехода на автодеплой.
  • Вырастили легаси-мамонта и не смогли с ним жить (Андрей Мягков, Simtech Development) — Опыт переписывания внутреннего продукта на PHP.
  • Чем страшны шутки со временем в PHP (Алексей Сундуков, ZeBrains) — Советы по работе с таймзонами в PHP.
  • Как найти общий язык с API в микросервисах (Михаил Самаркин, Skyeng) — Создаем единый формат ответа об ошибках в микросервисах.

• PHP Release Radar — Episode 1: Composer 2.0 — Новый (видео-)подкаст про релизы в PHP-мире. В первом выпуске один из главных разработчиков композера Nils Adermann.
• PHP Internals News #72 :: PHP 8.0 Celebrations! — Каждый автор RFC в PHP 8 говорит по паре слов о своей фиче.
• PHP Internals News #71 — О том, что не попало в итоге в PHP 8:
  • __toArray();
  • перегрузка операторов;
  • readonly свойства;
  • компактное присвоение для объектов;
  • return if ($condition);
  • модификаторы доступа на чтение и запись для свойств.

Спасибо за внимание!

Если вы заметили ошибку или неточность — сообщите, пожалуйста, в личку хабра или телеграм.

Больше новостей и комментариев в Telegram-канале PHP Digest.

Прислать ссылку
Поиск ссылок по всем дайджестам
← Предыдущий выпуск: PHP-Дайджест № 192

Рассказываем, как развивались способы создания презентаций до появления привычных нам сервисов.

Мы привыкли делать презентации в специальных программах или онлайн-редакторах: у нас есть Powerpoint, Google Slides, Keynote или Prezi. Среди них самым популярным изобретением стал именно Powerpoint: этот сервис верой и правдой служит нам уже более 30 лет. Но что было до его появления? Презентации тоже были. Давайте посмотрим, с помощью каких технологий их создавали.

Какими были первые презентации?

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

Alt: Витражи представляли собой серию последовательных изображений

Еще одна важная веха развития презентаций – это школьные доски. Первые из них появились в XIX веке и предназначались для надписей мелом. В XX веке наряду с ними стали использоваться маркерные доски. Впрочем, мел и маркер не имеют между собой существенных различий. Главный минус этого способа презентации – выступающий должен писать на доске в режиме реального времени. Это неизбежно прерывает речь, а также не позволяет создавать аккуратные схемы или рисунки.

Alt: В научных кругах доски активно использовали для презентации и обсуждения новых идей – на них показывали расчеты и схемы

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

Что изменилось с появлением проекторов?

Ко второй половине XX века популярность обрели сразу две технологии, качественно отличающиеся от меловой доски – они позволяли проецировать изображения на экран. Это делали с помощью кодоскопов или диапроекторов. Давайте подробнее остановимся на каждом устройстве.

Как работал кодоскоп?

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

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

Alt: Вот так выглядит кодоскоп. Это устройство увеличивало оригинал изображений в 10-20 раз

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

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

Как работал диапроектор?

Диапроектор или слайд-проектор – это устройство, в которое вставляли несколько цветных изображений размером 24х35 мм. Их изготавливали на фотопленке или на специальных стеклянных пластинах. Принцип действия устройства также строится на освещении – сначала использовали лампы накаливания, а с 1980-х годов – галогенные лампы.

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

Alt: Так выглядит диапроектор. Картинки для отображения вставляются в ячейки и поочередно сменяются

С помощью диапроектора появилась возможность показывать фотографии и цветные слайды. Эти слайды готовили художники, они были красиво оформлены, содержали иллюстрации и инфографику. В целом, возможности оформления таких презентаций были достаточными для полноценных выступлений. Кроме того, появилась возможность одновременно загружать в проектор до 80 слайдов – для этого были созданы карусельные диапроекторы.

Alt: В карусели можно было компактно разместить множество слайдов – с такими диапроекторами можно было делать длинные подробные презентации

Эта технология даже позволяла воссоздать простенькую анимацию – правда, это было редким явлением. В подавляющем большинстве случаев презентовали статичные слайды. Если же нужно было впечатлить аудиторию чудесами техники, на один экран направляли сразу несколько диапроекторов – а иногда и несколько десятков. У этих проекторов были внешние диафрагмы, которые реагировали на незаметные для человека звуковые сигналы. С помощью такой технологии слайды не просто перещелкивались, а исчезали и возникали с визуальными спецэффектами.

Как проходили выступления?

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

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

Alt: Изображения, полученные с помощью кодоскопа, не отличаются красочностью

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

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

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

Если задействовали анимацию, выступление и вовсе превращалось в спектакль с четко прописанным сценарием. Скоординировать множество диапроекторов – непростое дело. В такой презентации не предусматривались вопросы от слушателей, а содержание было второстепенным. Все подчинялось главной цели – впечатлить людей спецэффектами.

Как выглядели слайды?

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

Оформление слайдов было во многом похоже на то, что мы знаем сейчас: широко применялись иллюстрации и подписи:

Alt: Перед вами презентация General Electric, показанная в 1958

Конечно, дизайн середины прошлого века в чем-то уступал современным возможностям. О трехмерной инфографике или сложных фотоколлажах говорить не приходится: только цветные заливки, простые изображения и текст:

Alt: Это слайд с презентации IBM’s Premiere of Products (1959)

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

Alt: Такими были слайды в презентации Packing, a Recurring, Recursive Problem (1976)

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

Alt: Презентация IBM (1979)

Выводы

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

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

В других сферах чат-боты также хорошо себя зарекомендовали: в медицине они могут провести опрос пациента, передать специалисту симптомы и записать на прием к врачу для установления диагноза. В логистических компаниях чат-боты помогут согласовать дату доставки, сменить адрес и выбрать удобный пункт выдачи. В крупных интернет-магазинах чат-боты частично взяли на себя сопровождение заказов, а в сфере сервисов каршеринга чат-бот выполняют до 90% задач оператора. Однако, претензионную работу чат-боты решать пока не умеют. Негативный фидбек и спорные ситуации по-прежнему ложатся на плечи операторов и специалистов.

Таким образом, большинство растущих бизнесов уже активно используют чат-боты для работы с клиентами. Однако, польза от внедрения чат-бота часто варьируется: в одних компаниях уровень автоматизации достигает 90%, в других компаниях он составляет лишь 30-40%. От чего это зависит? Насколько хорош этот показатель для бизнеса? Есть ли способы повысить уровень автоматизации чат-бота? В данной статье будут рассмотрены вопросы, которые помогут разобраться в этом.

Бенчмаркинг

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

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

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

Необходимо сформировать список вопросов для проверки (не менее 50 вопросов, разделённых на несколько тематик):

• Вопросы по банковским услугам, например: «Какие у вас ставки по вкладам?», «Как перевыпустить карту?» и пр.
• Справочная информация, например: «Какой сейчас курс валют?», «Как получить кредитные каникулы?» и пр.
• Уровень понимания клиента. (Устойчивость бота к опечаткам, ошибкам восприятие разговорной речи), например: «Я поетря карту, чтро мне делаьь?», «Пополнить мобилу» и пр.
• Разговор на отвлечённые темы, например: «Расскажи анекдот», «Чем заняться во время самоизоляции?» и пр.

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

Эти вопросы следует задать своему чат-боту, а также чат-ботам конкурентов. После написания вопроса возможны 3 варианта результата (в зависимости от результата проставляется соответствующий балл):

• бот не распознал вопрос клиента (0 баллов);
• бот распознал вопрос клиента, но только после уточняющих вопросов (0,5 балла);
• бот распознал вопрос с первой попытки (1 балл).

Если чат-бот перевел клиента на оператора, то вопрос также считается не распознанным (0 баллов).

Далее суммируется количество баллов, набранных каждым чат-ботом, после чего рассчитывается доля корректно распознанных вопросов по каждой тематике (низкая – менее 40%, средняя – от 40 до 80%, высокая – более 80%), и составляется финальный рейтинг. Результаты можно представить в виде таблицы:

Предположим, по результатам бенчмаркинга чат-бот банка занял второе место. Какие выводы можно сделать? Результат не самый лучший, но и не худший. Опираясь на таблицу, можно сказать о его не самых сильных сторонах: во-первых, требуется доработка алгоритмов для корректного распознания вопросов клиента (чат-бот не всегда понимает вопросы клиента, содержащие ошибки и опечатки), а также не всегда поддерживает диалог на отвлеченные темы. Более детальную разницу можно увидеть при сравнении с чат-ботом, занявший первое место.

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

Таким образом, по результатам проведения бенчмаркинга были выявлены сильные и слабые стороны в работе чат-ботов, а также проведено сравнение конкурирующих чат-ботов между собой. Следующим шагом является выявление этих проблемных мест. Как этого достичь? Рассмотрим некоторые подходы, основанные на анализе данных: AutoML, Process-mining, DE-подход.

AutoML

В настоящее время искусственный интеллект уже проник и продолжает проникать по многие сферы бизнеса, что неминуемо влечет за собой повышенный спрос на компетенции в области DataScience. Однако, спрос на таких специалистов растет быстрее, чем уровень их квалификации. Дело в том, что разработка моделей машинного обучения занимает много ресурсов и требует не только большого объема знаний от специалиста, но и значительных временных затрат на построение моделей и их сравнение. Чтобы сократить давление, создаваемое дефицитом, а также сократить время на разработку моделей, многие компании начали создавать алгоритмы, способные автоматизировать процесс работы DataScientist’ов. Такие алгоритмы получили название AutoML.

AutoML, который также имеет название «автоматизированное машинное обучение», помогает DataScientist’у автоматизировать трудоемкие и многократно повторяющиеся задачи разработки моделей машинного обучения, при этом сохраняя их качество. Несмотря на то, что модели AutoML позволяют сэкономить время, они будут эффективны только тогда, когда проблема, которую они решают, является постоянной и повторяющейся. В этих условиях модели AutoML работают хорошо и показывают приемлемые результаты.

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

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

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

Разметка сообщений от клиентов

Далее объявляем модель AutoML, обучаем её на размеченных данных и сохраняем (все необходимые параметры модели также передаются, но в примере ниже они не приводятся).

automl = saa.AutoML res_df, feat_imp = automl.train('test.csv', 'test_preds.csv', 'classification', cache_dir = 'tmp_dir', use_ids = False) automl.save('prec')

Загружаем полученную модель, после чего производим предсказание целевой переменной для тестового файла:

automl = saa.AutoML automl.load('text_model.pkl') preds_df, score, res_df = automl.predict('test.csv', 'test_preds.csv', cache_dir = 'tmp_dir') preds_df.to_csv('preds.csv', sep=',', index=False)

Далее производим оценку полученной модели:

test_df = pd.read_csv('test.csv') threshold = 0.5 am_test = preds_df['prediction'].copy() am_test.loc[am_test>=threshold] = 1 am_test.loc[am_test<threshold] = 0 clear_output() print_result(test_df[target_col], am_test.apply(int))

Полученная матрица ошибок:

В процессе создания модели мы стремились минимизировать ошибку 1-го рода (отнесение хорошего диалога к плохому), поэтому для полученного классификатора остановились на f1-мере, равной 0,66. С помощью обученной модели удалось выявить 65 тыс. «плохих» сессий, что, в свою очередь, позволило выявить на 7 недостаточно эффективных сценариев.

Process Mining

Для выявления проблемных сценариев также применим инструменты, основанные на Process Mining — общее название ряда методов и подходов, предназначенных для анализа и усовершенствования процессов в информационных системах или бизнес-процессов на основании изучения журналов событий.

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

18% диалогов имеют более 4-х сообщений от чат-бота

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

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

Выявленные сценарии фигурируют примерно в 15% всех диалогов

DE (Data Engineering) подход

Также был применен несложный аналитический подход для поиска проблемных сценариев: были выявлены диалоги, оценка обратной связи в которых (со стороны клиентов) составляла от 1 до 7 баллов, затем отобраны наиболее часто встречающиеся сценарии в этой выборке.

Так, комплексно применяя подходы, основанные на AutoML, Process Mining и DE были выявлены проблемные места в работе чат-бота компании, требующие доработки.

Теперь чат-бот станет лучше!