У нас были похожие ситуации, приводящие к превышению времени ответа. В одном случае нужно было тянуть данные за слишком большой период (решили проблему кешированием и дроблением ответа). В другом случае - обращаться к нескольким мастер-системам (решили добавлением реплики помощника с предложением подтвердить готовность слушать ответ — сам ответ формировался, пока пользователь слушал сообщение).
Если правильно понял, то ваша проблема в том, что мастер-системы слишком долго отвечают. Попробую выдвинуть несколько идей (сразу отмечу, что слабо разбираюсь в этом вопросе, так что мои решения могут показаться абсурдными и нежизнеспособными)
Идеальное состояние здесь — это если система будет отвечать мгновенно или к ней не нужно будет обращаться вовсе. Предположим, что ускорить работу систем в целом нельзя. Значит, попробуем избавиться от медленной системы или создадим иллюзию мгновенного ответа.
Можно ли заранее перенести данные в другие системы, которые будут отвечать быстрее?
Можно ли заранее собирать данные в одну мастер-систему, чтобы не опрашивать системы по отдельности?
Можно ли выдать пользователю меньше информации или выдавать её порционно?
Можно ли выдать информацию порционно? То, что приходит быстро - озвучить сразу, а остальное закешировать и предложить прослушать отдельно.
Можно ли «отвлечь» пользователя, пока формируется ответ? Например, вступительным сообщением.
Можно ли придумать какое-нибудь умное кеширование, которое анализировало бы предыдущие запросы пользователя и предсказывало его вероятные запросы?
Не думаю, что можно с уверенностью сказать о том, какие идеи были придуманы именно с помощью ТРИЗ. Но многие из них связаны с решением противоречий. Например:
Айфон: физической клавиатуры нет, а печатать удобно (приём «Унификация»).
Фоновая загрузка плейлиста в Спотифай: интернет слабый, а музыка не прерывается (приём «Сделай заранее»).
Вращающаяся дверь: человек войти может, а сквозняк - нет (приём «Унификация», т.к. дверь открыта и закрыта одновременно).
Облачное хранилище: устройства с собой нет, а доступ к данным есть (приём «Посредник»).
Я воспринимаю ТРИЗ как метод организации творческого процесса. Никакой волшебной пилюли в нём нет.
Заметил, что новая модель стала лучше понимать контекст разговора (если сравнивать с бета-версией). Это большой плюс.
Из-за запрета на медицинские темы нейросеть отказывается отвечать на такие значимые вопросы, как проведение искусственного дыхания, помощь при отравлении или кровотечении. Предположу, что вы опасаетесь выдать недостоверную информацию, но в этом случае можно было бы перенаправить пользователя в поисковик, тем самым сэкономив ему время в критической ситуации.
Помню искал как-то технического писателя в компанию. Чтобы не отбирать у соискателей много времени, в качестве тестового задания предложил им отредактировать неудачную статью из руководства пользователя. Мне важно было увидеть, как человек умеет структурировать информацию и понимает ли, о чем не стоит писать в мануале.
Один из соискателей отказался бесплатно выполнять задание. Сказал, что на это у него уйдет 2-3 часа, за которые он мог бы заработать пару тысяч на фрилансе. Странный парень.
Спасибо за интересный материал. Я правильно понимаю, что если нужно распознать сложное слово, то вы используете в качестве паттернов не только варианты его написания, но и примеры неправильного распознавания? И именно за счет помещения слова в контекст удается отличить то самое слово от его "брата по произношению"?
Вы правильно заметили по поводу линейности хорошего кода. Однако разговорные интерфейсы (чат-боты, голосовые помощники) редко бывают такими. Например, пользователи могут пропускать шаги, переспрашивать или вовсе уходить от темы.
Проектирование сценариев не ограничивается кодом. Так, на этапе проектирования мы читаем сценарий по ролям, чтобы учесть как можно больше вариантов поведения пользователя. А для этого нужно видеть весь флоу, с чем прекрасно справляется схема.
Кроме того, дизайнер сценариев и программист - это разные роли с разными скиллсетами.
Это не совсем так. Помимо запрета пересечений, ДРАКОН предполагает упорядоченное расположение элементов. По моим наблюдениям, многие дизайнеры пренебрегают этим, за счет чего схема превращается в подобие осьминожки.
Есть и другие принципы, которые остались за рамками статьи. Про один из них вы правильно отметили - выделение «главного пути». Помимо этого, в методологии есть принцип «общей судьбы» (однотипные элементы разных веток располагаются на одном уровне) и рекомендации по проектированию сложных условий.
Кроме того, мы внесли в методологию ряд собственных изменений, чтобы сделать её удобнее для работы с разговорными продуктами. Главное из них - карточки ситуаций.
Когда игра была в топ-10 навыков, было около 500-700 новых пользователей ежедневно. Сейчас показатели спали да 400-500. Но это при том, что я не вкладывался в таргетированную рекламу. Возвращаются в игру по 150-170 человек в день (одни и те же это люди, или нет - не знаю).
Некоторые пользователи запускают игру несколько дней подряд и завершили более 20 успешных сессий (победили Вампуса). Продолжительность сессий сильно варьируется в зависимости от рандома и тактики игрока (проверяет ли он комнаты стрелами или же предпочитает рисковать). Это может быть как 1-2 комнаты, так и 15-20.
Самой большой преградой для новых игроков были длинные правила - четверть игроков их либо пропускала и разочаровывались, либо просто переставала играть дальше. Проблема решилась с помощью интерактивного обучения.
Среди игроков действительно много детей и это отразилось на контенте. Пришлось упростить некоторые реплики, понизить сложность на старте игры и убрать некоторые излишне пугающие звуки.
1. Ведем документацию на движке MediaWiki. Помимо описанных четырех типов топиков используем топики-агрегаторы. В них собираются ссылки по конкретной теме. Такой подход помогает переместиться практически в любое место за пару кликов.
2. По поводу привлечения внимания. «Важно» и «Внимание» объединили в один термин, т. к. они выполняют одну и ту же функцию. Добавили «Совет» — какие-то необязательные детали, которые упрощают работу пользователя.
Для меня флешка оказалась отличной капсулой времени. Помню это был Kingston на 2 Гб. На первом курсе универа записывал туда всякие статейки, музыку для винампа да Java-игры для телефона. Запустил 7 лет спустя, еле живую — прослезился от ностальгии, как всё поменялись за это время.
К одному и тому же решению можно прийти как с помощью ТРИЗ, так и без него. ТРИЗ, на мой взгляд, помогает быстрее перебирать варианты.
У нас были похожие ситуации, приводящие к превышению времени ответа. В одном случае нужно было тянуть данные за слишком большой период (решили проблему кешированием и дроблением ответа). В другом случае - обращаться к нескольким мастер-системам (решили добавлением реплики помощника с предложением подтвердить готовность слушать ответ — сам ответ формировался, пока пользователь слушал сообщение).
Если правильно понял, то ваша проблема в том, что мастер-системы слишком долго отвечают. Попробую выдвинуть несколько идей (сразу отмечу, что слабо разбираюсь в этом вопросе, так что мои решения могут показаться абсурдными и нежизнеспособными)
Идеальное состояние здесь — это если система будет отвечать мгновенно или к ней не нужно будет обращаться вовсе. Предположим, что ускорить работу систем в целом нельзя. Значит, попробуем избавиться от медленной системы или создадим иллюзию мгновенного ответа.
Можно ли заранее перенести данные в другие системы, которые будут отвечать быстрее?
Можно ли заранее собирать данные в одну мастер-систему, чтобы не опрашивать системы по отдельности?
Можно ли выдать пользователю меньше информации или выдавать её порционно?
Можно ли выдать информацию порционно? То, что приходит быстро - озвучить сразу, а остальное закешировать и предложить прослушать отдельно.
Можно ли «отвлечь» пользователя, пока формируется ответ? Например, вступительным сообщением.
Можно ли придумать какое-нибудь умное кеширование, которое анализировало бы предыдущие запросы пользователя и предсказывало его вероятные запросы?
Да, именно так. Это как начальные координаты для поиска.
Тут вы правы. Он хотел создать универсальное устройство, сочетающее в себе плеер, телефон и планшет без стилуса. Для него эта идея была интуитивна.
Какая задача - такое и решение)
Существующие решения сложно оценивать иначе, чем постфактум.
Как я уже писал в статье, ТРИЗ задаёт вектор для поиска «идеального» результата, а не предлагает конкретный алгоритм его получения.
Не думаю, что можно с уверенностью сказать о том, какие идеи были придуманы именно с помощью ТРИЗ. Но многие из них связаны с решением противоречий. Например:
Айфон: физической клавиатуры нет, а печатать удобно (приём «Унификация»).
Фоновая загрузка плейлиста в Спотифай: интернет слабый, а музыка не прерывается (приём «Сделай заранее»).
Вращающаяся дверь: человек войти может, а сквозняк - нет (приём «Унификация», т.к. дверь открыта и закрыта одновременно).
Облачное хранилище: устройства с собой нет, а доступ к данным есть (приём «Посредник»).
Я воспринимаю ТРИЗ как метод организации творческого процесса. Никакой волшебной пилюли в нём нет.
Заметил, что новая модель стала лучше понимать контекст разговора (если сравнивать с бета-версией). Это большой плюс.
Из-за запрета на медицинские темы нейросеть отказывается отвечать на такие значимые вопросы, как проведение искусственного дыхания, помощь при отравлении или кровотечении. Предположу, что вы опасаетесь выдать недостоверную информацию, но в этом случае можно было бы перенаправить пользователя в поисковик, тем самым сэкономив ему время в критической ситуации.
Это точно был вопрос к нейросети, а не к Алисе?
Помню искал как-то технического писателя в компанию. Чтобы не отбирать у соискателей много времени, в качестве тестового задания предложил им отредактировать неудачную статью из руководства пользователя. Мне важно было увидеть, как человек умеет структурировать информацию и понимает ли, о чем не стоит писать в мануале.
Один из соискателей отказался бесплатно выполнять задание. Сказал, что на это у него уйдет 2-3 часа, за которые он мог бы заработать пару тысяч на фрилансе. Странный парень.
Спасибо за интересный материал. Я правильно понимаю, что если нужно распознать сложное слово, то вы используете в качестве паттернов не только варианты его написания, но и примеры неправильного распознавания? И именно за счет помещения слова в контекст удается отличить то самое слово от его "брата по произношению"?
Статья описывает использование ДРАКОН для дизайна нелинейных сценариев чат-ботов. Мы не используем его для программирования/переноса кода.
Вы правильно заметили по поводу линейности хорошего кода. Однако разговорные интерфейсы (чат-боты, голосовые помощники) редко бывают такими. Например, пользователи могут пропускать шаги, переспрашивать или вовсе уходить от темы.
Проектирование сценариев не ограничивается кодом. Так, на этапе проектирования мы читаем сценарий по ролям, чтобы учесть как можно больше вариантов поведения пользователя. А для этого нужно видеть весь флоу, с чем прекрасно справляется схема.
Кроме того, дизайнер сценариев и программист - это разные роли с разными скиллсетами.
Мы рассматривали IDEF3 в качестве одного из вариантов, но ДРАКОН показался нагляднее и легче для восприятия.
Это не совсем так. Помимо запрета пересечений, ДРАКОН предполагает упорядоченное расположение элементов. По моим наблюдениям, многие дизайнеры пренебрегают этим, за счет чего схема превращается в подобие осьминожки.
Есть и другие принципы, которые остались за рамками статьи. Про один из них вы правильно отметили - выделение «главного пути». Помимо этого, в методологии есть принцип «общей судьбы» (однотипные элементы разных веток располагаются на одном уровне) и рекомендации по проектированию сложных условий.
Кроме того, мы внесли в методологию ряд собственных изменений, чтобы сделать её удобнее для работы с разговорными продуктами. Главное из них - карточки ситуаций.
В основе ДРАКОН лежат принципы эргономизации традиционных блок-схем. Соединители - один из элементов для достижения этой цели.
Когда игра была в топ-10 навыков, было около 500-700 новых пользователей ежедневно. Сейчас показатели спали да 400-500. Но это при том, что я не вкладывался в таргетированную рекламу. Возвращаются в игру по 150-170 человек в день (одни и те же это люди, или нет - не знаю).
Некоторые пользователи запускают игру несколько дней подряд и завершили более 20 успешных сессий (победили Вампуса). Продолжительность сессий сильно варьируется в зависимости от рандома и тактики игрока (проверяет ли он комнаты стрелами или же предпочитает рисковать). Это может быть как 1-2 комнаты, так и 15-20.
Самой большой преградой для новых игроков были длинные правила - четверть игроков их либо пропускала и разочаровывались, либо просто переставала играть дальше. Проблема решилась с помощью интерактивного обучения.
Среди игроков действительно много детей и это отразилось на контенте. Пришлось упростить некоторые реплики, понизить сложность на старте игры и убрать некоторые излишне пугающие звуки.
Спасибо за содержательный обзор!
1. Ведем документацию на движке MediaWiki. Помимо описанных четырех типов топиков используем топики-агрегаторы. В них собираются ссылки по конкретной теме. Такой подход помогает переместиться практически в любое место за пару кликов.
2. По поводу привлечения внимания. «Важно» и «Внимание» объединили в один термин, т. к. они выполняют одну и ту же функцию. Добавили «Совет» — какие-то необязательные детали, которые упрощают работу пользователя.