Abstract
This study introduces Conversation Routines (CR), a structured prompt engineering framework for developing task-oriented dialog systems using Large Language Models (LLMs). While LLMs demonstrate remarkable natural language understanding capabilities, engineering them to reliably execute complex business workflows remains challenging.

The proposed CR framework enables the development of Conversation Agentic Systems (CAS) through natural language specifications, embedding task-oriented logic within LLM prompts. This approach provides a systematic methodology for designing and implementing complex conversational workflows while maintaining behavioral consistency. We demonstrate the framework’s effectiveness through two proof-of-concept implementations: a Train Ticket Booking System and an Interactive Troubleshooting Copilot. These case studies validate CR’s capability to encode sophisticated behavioral patterns and decision logic while preserving natural conversational flexibility.

Results show that CR enables domain experts to design conversational workflows in natural language while leveraging custom functions (tools) developed by software engineers, creating an efficient division of responsibilities where developers focus on core API implementation and domain experts handle conversation design.

While the framework shows promise in accessibility and adaptability, we identify key challenges including computational overhead, non-deterministic behavior, and domain-specific logic optimization. Future research directions include CR evaluation methods based on prompt engineering framework driven by goal-oriented grading criteria, improving scalability for complex multi-agent interactions, enhancing system robustness addressing the identified limitations across diverse business applications.

UPDATE (18/02/2025)

The article has been published on arXiv! Compared to the original version, the updated version submitted to arXiv includes som experimental results, refinements and formatting adjustments: https://arxiv.org/abs/2501.11613

A few days ago, the just released SWARM open-source project [1] from OpenAI sparked quite a bit of discussion within the agent-based Generative AI community, particularly among those focused on conversational AI. It’s a small, simple project (so far) that the company defines as:

An educational framework for exploring ergonomic, lightweight multi-agent orchestration. It is managed by the OpenAI Solutions team.

When comparing SWARM to well-known multi-agent frameworks such as LangGraph, CrewAI, AutoGen, and others, many argue that there is nothing groundbreaking about this small framework, which appears more like a demo than a production-ready platform. Indeed, OpenAI itself tends to characterize its project as a simple cookbook [2].

In a certain sense, I strongly agree; however, several key concepts in SWARM’s proof-of-concept align with my perspective on constructing LLM-based conversational agents. It is important to clarify that the term (conversational) agent, as I use it, has a very specific meaning, which only partially overlaps with the concept of AI agents as understood in the LLM-based community recently. For a more detailed discussion, please refer to my previous article: Conversational Agent with a Single Prompt [3].

Agents = Routines + Handoffs

The accompanying insightful OpenAI github cookbook [4] highlights several key points. The framework introduces the concept of routines that embed conversational workflow logic in a no-code manner (as I previously referred to in my article, referring to this as Directive Instructions on Conducting the Dialog).

The fundamental premise of SWARM is to decompose a complex conversational workflow (macro-task) into multiple smaller tasks managed by agents, which can be viewed as LLM-based experts in specific domains and policies. These agents collaborate through straightforward yet effective handoff mechanisms based on function-calling design patterns. So far, nothing new — I agree [5][6].

Instructions (on Conducting the Dialog)

With SWARM, it is possible to define complex workflows where conversational designers (prompt engineers) articulate the business logic of the workflow in natural language. The related backend business logic components, referred to as tools within the context of LLM programming, remain separate and can reside in custom Python code (or any programming language of choice).

This allows applications — whether conversational or otherwise — to be constructed from distinct components: LLM-based workflows, developed by prompt engineers (or coders), and hard-coded programs, handled by traditional software developers.

To me, this is the most crucial aspect when building an AI team in practice: bringing together developers (sw coders) and conversational designers (~no-coders) to work collaboratively!

Let us now examine a simple explanatory code snippet extracted from the blog example:

Notably, in the example provided in the blog, the LLM-based routine may include fixed (deterministic) steps, such as mandatory dichotomous questions (yes/no), implemented as Python functions. In the snippet here above, two routines (agents), are defined: triage_agent and sales_agent, each possessing its own workflow as specified in the instructions prompt, along with a set of associated functions, commonly known as tools, which implement the relevant business logic on the backend.

No-code Instructions

The instructions consist of simple sequences of conversational step directives, written in natural language or pseudo-code (such as bullet points or any structure expressible in natural language), which may include conditionals and/or loops.

This is significant as it demonstrates a method for conceptualizing chatbot interactions that are not reliant on hard-coded scripts (in a specific programming language or dedicated conversation workflow tool) but instead are based on high-level directives for conducting dialogue, articulated in natural language within system prompts.

Deterministic Workflow Checkpoints

In revisiting the snippet analysis, the most significant feature is the execute_order() function outlined earlier within the sales_agent tool. The notable aspect of this function is that when the sales agent determines an order should be executed, it invokes the execute_order() function, which can prompt a yes/no confirmation request from the user.

SWARM thus enables a synthesis of no-code programming (implemented as instructions in prompts) with workflows that include hard-coded dialog turns (implemented as programming code in invoked functions). I refer to these functions as workflow checkpoints.

This approach is particularly noteworthy as it allows for the design of complex conversational applications where hard-coded workflows are seamlessly integrated with LLM-based workflows.

Context Variables and Task-Oriented State Machines

The framework introduces context variables — a simple yet effective mechanism for retrieving and storing contextual data shared across routines. While the implementation may appear basic, its straightforwardness is part of its strength.

Interestingly, opinions differ on how SWARM handles state management: some consider context variables as part of a potential state-machine-based approach, while others argue that the framework remains fundamentally stateless, given its dependence on stateless calls to the LLM models driving the agents.

From my perspective, particularly in conversational design, SWARM effectively implements a task-oriented state machine, albeit at a high level of abstraction. In this framework, conversational states are naturally encoded within the logic of routines, enabling both input and output data to be stored in shared context variables. This allows conversation designers to focus on agent-driven tasks without the need to explicitly conceptualize a full state network, as in the Langraph approach.

Additionally, the framework adopts a minimal yet effective testing method through evals. Once again, I appreciate this clear and practical methodology for validating routine behaviors.

Conclusion

While SWARM may not yet rival more established multi-agent platforms like LangGraph, CrewAI, and AutoGen (to mention the most prominent) in terms of sophistication, it introduces a promising approach to orchestrating LLM-based conversational agents. Its ability to decompose workflows into smaller, specialized tasks managed by individual agents demonstrates a practical framework for agent-based orchestration.

What may differentiate this approach from other frameworks is its emphasis on workflow development through the seamless integration of no-code and hard-coded processes. This allows conversational designers to define overarching logic using natural language prompts, while developers handle more complex backend functions through traditional coding methods.

This hybrid design creates a fluid workflow where the roles of both no-code and coded components are clearly delineated, allowing for flexible, collaborative development of conversational applications.

Moreover, SWARM’s minimalistic reliance on context variables and simple testing methodologies strikes a balance between simplicity and functionality, making it a pragmatic choice for developing medium-complexity agentic systems. Whether SWARM will evolve into a robust, production-ready framework remains to be seen. However, its approach represents an important step toward bridging the gap between conversational designers and software developers, fostering a more collaborative environment for building next-generation conversational AI systems.

As the community further explores its potential, SWARM may prove to be more than just an educational tool, but rather a viable option in the growing landscape of LLM-based multi-agent frameworks.

Update (2024–11–03): Insights from Initial Experiments

Following several hands-on tests with SWARM, I would like to provide further insights into my experience with this framework. The key advantage of adopting an agentic approach (exemplified by SWARM, along with other LLM-based agentic frameworks) lies in a principle reminiscent of the structured programming paradigm of the 1960s: break down the main problem (or workflow in this context) into smaller, manageable sub-problems.

Each sub-problem is assigned to a specialized agent, which operates based on instructions crafted by a conversation designer and utilizes tools or backend functions implemented in Python by a developer.

This approach represents a substantial advancement over the monolithic, LLM-based methods that were our primary focus just a year ago. For example, consider a Retrieval-Augmented Generation (RAG) application. In tests, I implemented a search workflow using cooperating agents aligned with SWARM’s design. In this setup, a master orchestrator agent delegates tasks to specialized agents, each tasked with retrieval from sources such as relational databases or vector stores. The results demonstrated minimal hallucinations and an effective response strategy for unmet requests. Overall, this multi-agent approach outperformed the single-LLM model.

Beyond the design pattern best practices mentioned above, I have reassessed my previously favorable view of what I termed “Deterministic Workflow Checkpoints.” Specifically, the example OpenAI Python function execute_order(), which directly reads user input (via input()) and writes output (using print()), illustrates a suboptimal design pattern. The hard-coded backend logic in this function bypasses both instructional flows and user interface design, leading to several limitations.

For example, in scenarios where user confirmation is required (such as verifying a purchase or payment), it is valid to include a checkpoint function that prompts a yes/no confirmation. However, it is not ideal for such functions to embed workflow interaction logic directly. Instead, it would be more effective to delegate interaction logic to a specialized user interface agent — this could be the main orchestrator agent or, even better, a dedicated agent attuned to specific user interface modalities (whether chat, voice interface, or email), the bot-persona design and so on.

While the principle of using functions as checkpoints is sound, the original OpenAI example relying on direct input() and print() calls could be considered an anti-pattern, as it does not conform to the separation of concerns in agent-based design.

Regarding LLM models, some have argued that SWARM is specific to OpenAI’s models, but this is not accurate. OpenAI API calls have become a de facto standard, and many non-OpenAI vendors provide compatible interfaces. In my tests, I used Azure OpenAI deployments, and the framework operated effectively with only few lines of additional initialization code I wrote, as shown below:

Lastly, you can utilize SWARM as-is on-premises (either locally on your hardware or in a private cloud) with the outstanding ollama engine, which supports lightweight open models, as demonstrated by Cole Medin in his YouTube video [7].

Last but not least, It is unfortunate that OpenAI appears reluctant to further develop the SWARM project on GitHub. Specifically, they have disabled the ability for users to open issues, which is an unusual practice for a prominent organization that incorporates the term “Open” in its branding.

Nonetheless, I remain appreciative of OpenAI’s contributions. I would like to express my gratitude for underscoring a principle in which I firmly believe: that LLMs serve as effective conversationalists and that the multi-agent approach supports the no-code aspirations of many chatbot conversation designers, enabling machines to facilitate dialogues on their behalf.

What do you think?

References

[1] OpenAI SWARM GitHub Repository: https://github.com/openai/swarm

[2] OpenAI SWARM GitHub Cookbook Blog Article: Orchestrating Agents: Routines and Handoffs https://cookbook.openai.com/examples/orchestrating_agents

[3] Concept of Conversational Agents: Conversational Agent with a Single Prompt? https://www.linkedin.com/pulse/conversational-agent-single-prompt-giorgio-robino-vrppf/

[4] OpenAI SWARM Cookbook Jupyter Notebook: https://github.com/openai/openai-cookbook/blob/main/examples/Orchestrating_agents.ipynb

[5] Microsoft Autogen Handoffs: https://microsoft.github.io/autogen/dev/user-guide/core-user-guide/design-patterns/handoffs.html

[6] Old OpenAI Prompt Engineering Tutorial: https://platform.openai.com/docs/guides/prompt-engineering/strategy-split-complex-tasks-into-simpler-subtasks

[7] Ollama + OpenAI’s Swarm — EASILY Run AI Agents Locally, by Cole medin: 
https://www.youtube.com/watch?v=8jpVeUTNExI

Last weekend, just for personal fun, I conducted a non-scientific experiment to test how well the Large Language Models (LLMs) available on the market “know” a specific natural language (Italian, in my case) according to CEFR guidelines.

I’ll briefly recap what the CEFR classification standard is, detail the experiment, and finally share some thoughts about it.

What’s CEFR?

CEFR (Common European Framework of Reference for Languages), also known in Italy as QCER (Quadro Comune Europeo di Riferimento per le Lingue), is a standard for classifying language proficiency.

The CEFR is a guideline used to describe the achievements of language learners across Europe and increasingly worldwide. In November 2001, a European Union Council Resolution recommended using the CEFR to establish systems for validating language ability.

The six reference levels (A1, A2, B1, B2, C1, C2) are widely accepted as the European standard for grading an individual’s language proficiency. These levels cover several competencies: written and oral comprehension, and written and oral production.

• A1 and A2: Basic users who can understand and use simple phrases and sentences in familiar contexts. A1 indicates very basic comprehension and production, while A2 shows slightly more advanced skills.
• B1 and B2: Independent users who can handle more complex language. B1 users understand the main points of clear standard input on familiar matters and can produce simple connected text. B2 users comprehend and interact on a wider range of topics, producing detailed and coherent text.
• C1 and C2: Proficient users with advanced skills. C1 users understand a wide range of demanding texts, recognize implicit meaning, and express themselves fluently. C2 users easily understand virtually everything heard or read, summarizing information from various sources coherently.

The LLM Self-Evaluation Experiment

I collected the responses of each of the nearly 50 models available on the Chatbot Arena website to this question (prompt) in Italian:

“Qual è il tuo livello di conoscenza della lingua italiana, rispetto alla classificazione QCER? Rispondi solo con una parola indicante il tuo livello di competenza:”

Meaning in English: “What is your level of Italian language proficiency, according to the CEFR classification? Respond with only one word indicating your level of competence”.

For each model, I collected the response and had to elaborate a bit because, in some cases, the models replied with synonyms, long sentences, or nonsensical answers. I compiled all the results in a table. See the attached screenshots:

The table shows three columns: MODEL-NAME, QCER_LEVEL (the resulting CEFR level as a single word), and RANK (where 1.0 means the LLM replied exactly with the expected level; between 0.0 and 1.0 means the LLM replied with a synonym or a long sentence).

Almost half of the models, including small and open-parameter models, self-evaluate with good or very good proficiency.

Hmm… Maybe there is a bit of overestimation in these LLM self-assessments?!

Automating Language Proficiency Assessments?

My experiment was clearly just a curiosity! I’m not a linguist, so a more thorough investigation should be conducted by domain experts (linguist researchers).

The quick test I conducted was done via the chat (textual) web interface, so the models can’t estimate listening and speaking! I admit my simple prompt biased the LLMs to reply with a single word that we assumed valid just for reading/writing abilities. A complete evaluation would require interfacing these LLMs with a voice interface (to test listening and speaking) and the production of content with varying levels of difficulty.

With a more scientific evaluation, a human language expert, typically a language teacher from a certifying body, could examine an LLM to classify proficiency using the same CEFR metrics we use for humans (reading comprehension, writing production, listening comprehension, speaking production, interaction, mediation).

A further step could be to develop a comprehensive LLM-based testing application to fully automate the proficiency examination, using a top-level LLM as the examiner to test other LLMs (acting as examinees). So, perhaps, by using high-proficiency LLMs as CEFR experts, we could automate some of the real teachers’ work on CEFR examinations, evaluating the language proficiency of human students… or other LLMs.

More generally, many e-learning activities (language-learning related and beyond) usually done by human teachers could be partially implemented by LLM-based conversational agents.

For example, teachers could be assisted by conversational assistant applications to manage the “heavy work” of exercising students and examining them, reporting relevant milestones and events to the teacher. There is a vast range of automation in the edutech sector that is now enhanced by generative AI.

What do you think?

#GenerativeAI #LLMs #LargeLanguegeModels #LanguageLearning #eLearning #EduTech #CEFR #QCER

Using Large Language Models for Chatbot Development: Specializing in Prompt Design

In this article, I share my experience in constructing Generative AI prompts to develop Conversational Agents.

First, I will clarify the relevant terms. Then, I will provide a brief overview of how we can utilize Large Language Models (LLMs) as intelligent conversationalists. Finally, I will present some compelling use cases where I have refined prompt engineering best practices to implement chatbots solely from no-code requirement specifications (system prompts).

Conversational Agents

Years ago, during my previous academic career (specifically as an assistant researcher at ITD-CNR), my research leader and other researchers always referred to chatbots as conversational agents. This perplexed me, as I’m particular about terminology in computer science. I always understood an agent to be any kind of software that intermediates among humans to perform some task (usually delivered by a human).

My point was that not every chatbot is truly an agent in functional terms.

For example, consider a voice system that acts as an assistant (nowadays we might call it a voice copilot) for a worker, assisting them in accomplishing specific real-life working tasks. Is it correct to define this system as a conversational agent? Maybe not, because it lacks agentive functionality. The term assistant may be more appropriate for augmented-reality scenarios like this (read also my previous article, Voice-cobots in industry. A case study). However, I admit that historically, in the scientific and academic community, conversational agent and chatbot have been used as synonyms.

Nevertheless, things have become more confusing with recent advancements in LLM-based autonomous agents. In this research area, which is broader than conversational applications, agents can autonomously define and execute micro-tasks based on a human-provided description in natural language (the system prompt) of a specific high-level duty or activity. This is a fascinating area of research with potentially disruptive practical applications, and there are many software frameworks available, but that’s a slightly different topic. Let’s now focus instead on the conversational application verticals.

Overall, I use the term Conversational Agent to refer to a specific type of agent that performs conversational tasks on behalf of a human.

Progress with LLM-based conversational agents allows us to build chat systems with a single prompt based on cognitive architectures. By utilizing advanced state-of-the-art LLMs, developers can describe what the chatbot should do without having to program the conversation as a series of fixed dialog states. From the development perspective, this could be a definitive cost-saving alternative to solutions based on intents, slots, states, and hard-coded flow management.

LLMs as Core Layers for Agent Engines

Long story short, GPT-based Large Language Models have revolutionized the field of conversational AI since the release of GPT-3 by OpenAI. These recent LLMs, trained on vast amounts of text data, can generate human-like responses and engage in meaningful dialogues. Their ability to understand and generate language makes them ideal for building chatbots.

Instruction-based Chat Completion Models

A basic foundation model (a large language model trained with sufficient data to ‘know’ a specific human language) is not sufficient to be a valid engine, capable of making conversations and reasoning.

Simply put, the disruptive improvement in GPT-3 models occurred with GPT-3.5-turbo (the model behind the famous ChatGPT, see my previous article: Reflecting on ChatGPT’s Anniversary). GPT-3.5-turbo is based on the foundation of GPT-3 but enhanced by a supervised training algorithm (HFRL and similar supervised training mechanisms) that enables it to converse with people in a fluid natural language, using polite and ‘controlled’ manner.

More importantly, the models from GPT-3.5 onwards are also instruction-based models because they are trained with programming code (OpenAI coined the term instruct). This last feature enabled some sort of ‘reasoning’ abilities. The LLMs are now able to perform themself some programmatic ‘logic’ understanding, such as concepts of programming languages including sequences, conditionals, and iterations.

Function Calling Feature

Another disruptive feature that nearly all state-of-the-art generative models now possess is the ability to call external functions/APIs (sometime called tools in LLM agents jargon). This is achieved through special fine-tuning of the aforementioned models, enabling LLMs to ‘call’ external functionalities, such as programs made in any programming language, to solve specific requests or actions and retrieving real-time data. This is a fundamental need in a cognitive architecture, where the LLM is the core ‘reasoning’ component that autonomously retrieves information from external systems or invokes actuators.

The function-calling feature is crucial for autonomous agents but not essential for building basic conversational agents. However, function-calling becomes a must-have when the conversational system needs to invoke external APIs. For example, a customer care assistant might need to open a ticket in an internal ticketing system or query the system to monitor the ticket status and inform the customer during the conversation.

The recent generative language models (instruction-based LLMs fine-tuned for chat completions, also enabled by function calling) can understand logic and instructions (through directive written in natural language in the prompt) and have an improved capacity to conduct human-like conversations in nearly any natural language. Additionally, these models can interact with external (proprietary) APIs. All in all, today’s models like GPT-4 or equivalents are viable engines for building autonomous agents capable of performing task-oriented conversations typically handled by humans.

In the next paragraphs, I will delve into this with some examples, but first, I will introduce the prompt engineering approach I used.

Prompt Design for Task-oriented Conversations

Prompt engineering is the practice of designing and refining input prompts to effectively guide the behavior and output of language models. By carefully crafting these prompts, users can enhance the model’s ability to understand and respond to complex instructions, ensuring more accurate and contextually appropriate outputs. This technique is crucial for optimizing the performance of state-of-the-art generative models, enabling them to perform specific tasks, generate creative content, and simulate ‘human-like’ conversations with precision.

The techniques I experimented with are about writing system prompts to instruct the LLM to conduct conversations in specific application domains to achieve particular tasks.

In-Context Learning

In all use cases I’ll introduce, I used a similar approach: the system prompt is composed of an introductory context section where I defined 1: the goal of the conversation (or task), 2: the bot-persona (the description of the agent’s characteristics/character, using the usual conversation design metrics), 3: the user persona (a description of the user profile), 4: The core part of the context is contextual data useful for the current conversation session. For example, if the conversation is an interview for a job applicant, this data includes the job description file and the candidate’s curriculum. More generally, the technique is akin to the one made famous with Retrieval Augmented Generation (RAG) applications, where you ‘stuff’ inside the prompt data retrieved (maybe with some embeddings database or any specific vertical data retrieval system).

When considering the data needed to accomplish a task-oriented conversation, it could be anything that fits into the prompt context window size (4K tokens, 8K tokens, 16K tokens, and so on). In all practical use cases I have experimented with and mentioned below, a context window of 4–7K tokens has been entirely sufficient for the purpose.

Directive Instructions on Conducting the Dialog

After the context part of the prompt, in the following instruction section, I detailed the required steps (actions to be accomplished in a specific order). This is the tricky part where you instruct the model not just on how to conduct the conversation in terms of social practices and human conventions, but also provide guidelines regarding the topics to cover, possibly including explicit questions or general behaviors to adopt.

Here, you instruct the LLM on what topics must be covered in the chat, how to conduct the dialogue with more or fewer guidelines, and how to guide the conversation from point A to the desired point B. Finally, the instructions must include criteria for deciding when to end the conversation session, which depends on the specific application and can be a bit tricky to implement.

Some Application Use cases

I introduce three dialogue systems I prototyped for entirely different verticals. All these applications have in common the fact that I wrote the conversation program as a single system prompt for an LLM. In chronological order of my developments:

Case 1: A Virtual Caregiver for Patient Telemedicine Visits

I have been involved in some prototypes related to the healthcare vertical, specifically in transcribing and extracting data from practitioner-patient visits for Conversational Analysis (CA) using LLMs. As a side project, I developed an emulation of a remote monitoring visit where a virtual assistant (acting as a practitioner or caregiver) contacts a patient every day via an instant messaging app to monitor their health status, particularly considering the patient is potentially affected by COVID-19. The virtual caregiver asks the patient about their health status, chats with them in a very natural way, delves into symptoms, and engages in small talk if the patient initiates it, while keeping the conversation focused on retrieving certain parameters: health status, temperature, blood oxygenation, and a few other variables.

Once all the requested information is retrieved, the virtual caregiver says goodbye to the patient and closes the conversation, internally returning a data structure (a JSON) containing all the information obtained from the patient. Interestingly, in this case, the end of the conversation is not strictly necessary. After the initial session, the user can re-engage with updates on their symptoms. The virtual caregiver replies to any patient questions or statements about their symptoms and internally emits any data updates via a function call. This example is also interesting for its psychological support aspects, but that’s another story.

You could argue that the described conversation is just an old-fashioned form-filling that one could implement with a simple hard-coded chatbot. However, the novelty of the LLM-based conversation is the naturalness of the interaction. This variance in how the system conducts any new conversation session, allowing user digressions while returning to the programmed goal of gathering information, is invaluable!

Case 2: A Customer Care Assistant

This is a classic chatbot application that I already mentioned in the article. Imagine a virtual assistant helping an employee of a very large company submit requests or report issues that can be tracked by opening tickets on a specific backend system. The user must also be able to ask about the status of previously submitted tickets. This is a very common chatbot application that I delivered in production as a standard state-machine flow tool seamlessly integrated with external REST APIs.

Subsequently, I tried to re-implement the same application using an LLM-based approach. The initial application involved highly constrained workflows, so what’s the advantage of using an LLM as a dialog conductor? I also struggled with implementing these programmatic steps that are simple to implement with a hard-coded flow. So, what are the advantages of implementing all this logic with a ‘declarative’ approach instead of using a standard software program?

There are two interesting pros: the conversation built by the LLM seems more ‘natural’, emulating the behavior of a human being (e.g. a help desk operator), allowing the user to describe an issue in various ways and guiding them to explain the problem concisely to gather all the necessary data.

The second advantage is the reduction in development time: with the single-prompt approach, the chatbot developer is no longer a software programmer using a chatbot development tool, but rather a prompt engineer with conversational design skills, who writes the chatbot specification as a special text in a natural language (English, Italian, etc.).

Besides the prompt engineer, we still need a backend developer who knows how to integrate external APIs, but what’s nice is that these two roles are quite distinct, and the software responsibility boundaries are clear.

Case 3: A Virtual Job Position Interviewer

The most fun and intriguing application I’m experimenting with is in the Human Resources vertical. Using the usual in-context learning prompt-writing approach, I built an emulator of a recruiter conducting an interview with a person who applied for a certain job position.

In the prompt context, I included the job post description and the candidate’s curriculum vitae. In the instruction section, I taught the LLM to act as a perfect recruiter, asking questions to verify all matches and mismatches between the role description and the candidate’s experience. The results are very impressive, and the virtual interviewer’s behavior is smart enough to detect weaknesses and strengths of the candidate by comparing the CV with the required skills. As a test candidate myself, I have been unable to lie in response to such precise investigative questions.

Since I’m not an expert recruiter myself, my approach could surely be improved with input from a domain expert in human resource recruiting. Nevertheless, my current experiments are astonishing. The system conducts a natural (similar to a human-to-human dialog) yet very rational interview, exploring points of weakness and verifying the truth of user statements in a polite and positive manner (as I instructed the bot-persona to do).

Besides the above application, I also created collateral LLM-based tools, such as a ‘pre-interview’ prompt to decide if a candidate deserves to be interviewed and some ‘post-interview’ tools that analyze the interview dialog and produce a structured report with a final ranking, but these are collateral (one-shot) LLM-based applications.

Prompt Development Challenges

LLMs are not deterministic. This has certain advantages, such as enabling smooth, fluent, always slightly different conversation variations, but it also presents some drawbacks. When considering the applications covered here, this randomness can potentially create issues. The main challenge I encountered was not the outcomes of the first prompt I designed, but the subsequent editing required to refine it to adjust some incorrect or unexpected runtime behavior.

Related to this, LLMs suffer from what I call fragility syndrome: you may have an initially well-functioning prompt, but even a minor, seemingly insignificant modification of a statement or a typo (by the way, typos are absolutely forbidden when writing prompts; please use a spell checker!) can cause different and unexpected runtime behaviors. Fixing this usually requires a lot of time spent on trial and error, where I rethink the prompt and often have to rewrite or reorganize it following a new, more logical approach.

For the prototypes I created, I admit I did not use any automated testing tools to validate the LLM outputs. This automatic evaluation is not a trivial task, although there are some emerging tools that can help prompt engineers validate prompts (this is a topic for a future article).

Tentative Conclusions

There is a lot of hype around optimal use cases for LLMs. Since 2023, I have seen hundreds of papers, articles and videos concerning RAG/LLM applications. While LLM-enabled data retrieval-based chatbots are certainly an important use case, for me, as a conversation designer also, the perfect use case for state-of-the-art LLMs is to exploit the conversational capabilities embedded in LLMs trained and fine-tuned on human conversations.

The no-code dream of developing chatbots has now become a reality with just prompt engineering skills?

What are your thoughts?

#promptEngineering #LLMs #generativeAI #GenAI #nocode #conversationalAgents #AutonomousAgents #chatbots #ConversationDesign #AI #MachineLearning #NaturalLanguageProcessing #AIChatbots #AIApplications

ChatGPT celebrates its first birthday on November 30, 2023. Exactly one year ago, OpenAI announced the birth of ChatGPT in a blog post, which you can find here.

In December 2022, the ChatGPT craze took off immediately, with hundreds of thousands of users and developers (like myself) eagerly engaging with this innovative technology.

I must confess that before ChatGPT was born, I was skeptical of large language models (LLMs) and statistic-based AI technologies in general. I followed the debates surrounding GPT-3 in 2022 with keen interest, and I must admit I was quite perplexed about the potential successful evolution of what some referred to as ‘statistic parrots’.

However, everything changed with the release of GPT-3.5 by OpenAI and subsequent models. These new models were extensively trained not only with human texts, including narratives and conversations, but also with programming code (InstructGPT). This has been a game-changer, in my opinion. These LLMs have been ‘filtered’ (with RLHF techniques, etc.) and fine-tuned for a chat experience interface (ChatGPT), not only demonstrating a nearly perfect natural language syntax but also exhibiting remarkable semantics, as acknowledged even by Walid Saba.

Inspired by amazing David Shapiro’s live coding videos, I delved into prompt engineering techniques in December 2022. Throughout 2023, I focused on exploring the applications of large language models, specifically in the realms of natural language processing and conversational interfaces, especially chatbots.

In my free time, I also studied a lot and participated a little bit in the growth of some excellent open-source Python development frameworks like LangChain, LlamaIndex, LiteLLM, just to name a few. I have been overwhelmed by the sheer number of academic papers published at an insane rate throughout the year.

Now, a crucial development is that the latest GPT-based models have demonstrated the capability to perform some reasoning-based tasks.

Many researchers are currently grappling with the challenge of constructing ‘autonomous’ agents, or more accurately, copilot assistants — systems designed to interact in real-time with users and collaboratively execute workflows alongside humans. This is a topic that has interested me for quite some time, as I developed in 2020 a research project concerning a voice cobot in logistics industrial real-time workflows.

I am currently intrigued by the prospect of utilizing LLMs as foundational layers in cognitive architecture frameworks to develop a new era of goal-oriented conversational agents. These systems engage in real-time conversations with users, perhaps in voice-first augmented-reality applications, incorporating voice, chat, vision, physical sensors, actuators, to achieve user goals without depending on hard-coded logic (an ‘imperative-driven’ software written in some programming language).

Perhaps we have reached a juncture where we can design these systems, setting ‘business requirements’ almost entirely in natural language, maybe by the final user directly (or probably helped by a prompts design expert). Are we witnessing the realization of the ‘no-code’ dream that some of us fantasized about just a few years ago?

Surely, 2024 will be an exciting year for the conversational AI community!

What are your thoughts?

English stands as the most widely utilized language on the internet, particularly in Western countries. It unquestionably serves as the lingua franca within the fields of computer science and scientific communities across the globe. The detailed breakdown of languages and their respective proportions in the training data for models like GPT-3.5 remains undisclosed by OpenAI and other providers.

Most contemporary large language models, including GPT-3.5, are likely trained on an extensive and diverse corpus of internet text, encompassing content from a multitude of languages. It is a rough assumption that the percentage of training data follows the language prominence on the internet. Please refer to the table below for approximate reference.

If we limit the languages to Western countries, we would probably see a higher percentage of English, possibly exceeding 50%. Do you concur?

What astonishes me, however, is the near flawless proficiency of state-of-the-art LLMs (Large Language Models) in minor languages, including my own: Italian. Rarely do I encounter syntax and “semantic understanding” errors, even in conversations conducted in highly proficient Italian.

This is undeniably remarkable!

So, when it comes to constructing complex LLM-based applications in a non-English language, one might assume that employing prompts exclusively in the non-English language is the straightforward and convenient approach. Nonetheless, I’m not entirely certain that it consistently produces the best results.

At first glance, there doesn’t appear to be a significant qualitative difference when comparing applications generated using prompts in Italian versus English.

However, let’s take a moment to consider some important factors in the equation: token usage, cost, latency, procedural understanding, language subtleties, and proficiency.

Tokens usage

Several months ago, I participated in a small Twitter thread where Hassan Hayat (@TheSeaMouse) shared a small experiment demonstrating that, when given the same text (an abstract of a famous paper in that case), GPT consumes fewer tokens when processing English compared to other languages:

Twitter https://twitter.com/solyarisoftware/status/1610979278870532107?s=20

Well, token usage significantly increases for languages with non-Latin character sets. That’s partially expected, but what surprised me was that the original text, when translated into Italian and tokenized, required almost double the number of tokens compared to English.

In other words, a prompt written in Italian costs twice as many tokens as one written in English. Quite interesting!

Money Cost and Latency

These variables are closely tied to token length. If you’re using a cloud-based LLM with a pay-per-usage pricing model (say Azure Openai deployment), the more tokens you employ, the more you pay. However, even if you’re running an on-prem model at home, such as a LLAMA 70B or similar, the number of tokens you process represents an indirect cost.

More tokens processed translate to increased computation, which, in simplified terms, results in longer latency. This latter point is crucial, particularly when your application involves a conversational interactive system like a chatbot or, even more, a voice-interfaced assistant, where the latency is a crucial factor.

By the way, I don’t have any benchmarks or comparisons regarding the relationship between context window token size and latency. Please do let me know if you come across any relevant research or discussions on this topic.

Efficiency in ‘Procedural Understanding’

I’ve been experimenting with LLM prompts that implement conversational agent goal-oriented workflows, such as the common customer care use case where a chatbot guides the user to open a ticket, among other tasks.

In such scenarios, your goal is to instruct an LLM to follow a procedural workflow. This workflow may involve conditional statements, a sequence of actions such as slot filling, API requests, and even the generation of events in structured formats like JSON. For an academic example, refer to:

TOPIC: Opening a Support Ticket
STEP-BY-STEP WORFLOW:
1. Begin the process of opening a support ticket for the user's issue.
2. Initiate a conversation to gather all the necessary details.
3. Collect the following attributes one at a time:
   a. Issue Description: Ask the user to provide a detailed description of the problem they are encountering.
   b. Product or System: Inquire about the name or model of the product or system they are using.
   c. Contact Information:
      i. Choose a preferred method of contact:
         - If "email" is selected:
           - Request the user's email address.
           - Confirm the provided email address.
         - If "phone" is selected:
           - Request the user's phone number.
           - Confirm the provided phone number.
4. Display a summary of the gathered information and request confirmation from the user before proceeding.
5. Finally, submit the support ticket with the provided information. Generate the following JSON code without comments:
   {"api": "open_ticket", "email": email, "phone": phone, "description": description, "product": product}

It has come to my attention that these pseudo-code prompts are better understood when written in English. This may be because recent LLMs are also trained in programming languages, where the most commonly used programming terms are in English.

I’m not entirely certain about this observation, and I lack quantitative data for a definitive comparison. It’s more of a personal impression, and I would appreciate it if you could share any research studies on this topic.

Temporary Conclusions

My current approach is to write prompts in English, even for Italian language LLM-based applications, whether they are conversational systems or involve more complex tasks in the Italian natural language application verticals (such as meeting transcript summarizations or spoken dialogue conversational analysis).

By the way, to prompt the LLM to reply in Italian, I simply use a straightforward instruction like this:

LANGUAGE: Conduct the conversation in informal, fluent Italian.

This approach apparently offers several advantages:

• It minimizes token length, thereby reducing costs and latency.
• It maximizes procedural comprehension when it comes to workflow instruction prompts. Debatable.
• It allows for the creation of multilingual applications by design; you write your prompts once in English and can deploy your system in any language with a single word substitution!

However, I acknowledge that all of my considerations thus far have been quite qualitative and are based on my empirical experiments. I invite you to share your experiences and any relevant scientific evidence on the discussed topics.

Thank you for taking the time to read this article. Your feedback is highly valuable to me, so please feel free to leave a like and a comment below to share your thoughts and insights.

Giorgio

I started writing this article almost two years ago, and from time to time the topic comes in my mind, so maybe the question in the title is still valid.
In the first part of the article I analyze what is happening in the smartspeaker-based voice-enabled assistants market, and in the second part I introduce some change requests that could allow Telegram to become a winner competitor in this restless vertical.

Let‘s recap the current smartspeaker market landscape

For a few years, Amazon Alexa and Google Assistant have been competitors in the consumer smartspeaker market, with a similar market share. To be precise, Amazon Echo devices are a bit more spread all around the word, anyway the gap between the two competitor is not so huge.

Bixby has been a possible emergent third competitor, but Samsung seems have given up with the release of a branded smartspeaker device and the company has reserved the technology just for its branded smartphones. 
End of the game of a splendid conversational technology conceived by Viv Labs’s Adam Cheyer and others.

After more than a year of stagnation, things are now changing because recently Google announced to sunset conversational actions. This means that:

In almost one year, Google Assistant will no more support actions designed only for smartspeakers.

Google focus on Android actions is announced and foreseen since a while. But now the company seems to have suspended his investments in voice technologies through smartspeakers.

Recently Sonos announced a new “service”, its own voice assistant that could be a competitor of Alexa (de facto, the current monopolist). But it’s not clear to me if the Sonos service will be implemented as an hardware device (an HI-FI smartspeaker / home multi-hub, aka the “soundbar”?). 
The company, after having acquired in 2019 great snips.ai opensource-based company, will certainly focus on data privacy, proposing some local device processing of user voice data (on the smartspeaker, not on the cloud!).

Apple has his Siri voice assistant, running on their HomePod devices, right! But so far these Apple smartspeakers haven’t achieved an important market share. The first release of HomePods was too expensive and the Siri third party applications integration has never gained huge success.

Microsoft smartspeaker for Cortana was never born and the entire Cortana project seems to be died. Game never started.

Last but not list, also Facebook, pardon, Meta, is apparently at stake:

who remember Facebook Portal devices?

And what happened with the Facebook-Amazon agreement that established the coexistence of Facebook Portal and Amazon Alexa on the same devices produced and sold by Facebook? Hasn’t been heard from since! Also,

Whatsapp for business has not shined in the spaces of enterprise chatbot solutions.

Facebook, sorry Whatsapp, selected a short list of system integrator companies (2nd party) to “filter” 3rd party enterprise companies. In my opinion this has been an unsuccessful path that duplicated data privacy concerns and over-complicated accounting requests, creating a lot of frustration. By example, so far it’s impossible to set-up a chatbot on Whatsapp even for academic or no-profit purposes (e.g. my accounting access request to Whatsapp for CPIAbot, coming from myself as a public national research institute researcher, has never received a reply). Unclear business strategy.

Is the unique voice assistant a failed model?

So why the smartspeaker-based voice integration assistants are in this stagnation? In this second quarter of 2022, we are in a situation were

Amazon Alexa seems to be the only competitor left in the market of voice assistants based on smartspeakers.

But the question now is:

Has a unique smartspeaker-based central voice assistant a future (as a main hub at home or in the office)?

I remember discussions of experts few years ago, when pretty all agreed with the fact people need (at home) a unique voice assistant, not many assitants! 
Is it still so?

Alexa now seems the winner of this prediction, the unique “1st party” assistant, the only one that leads the market. But this winning is maybe more related to the fact that Amazon competitors are “loosing out”. In fact also Alexa devices and investments didn’t grow as we expected. I have the feeling of a general stagnation also inside Alexa departments, by example the developers communities are no longer supported as they were years ago and many smart guys moved from Alexa to AWS. Weird, but significant signal.

So the winner-take-all desire of all above mentioned companies is probably failing and there are many reasons. All these big companies pretended to be the exclusive winner, proposing “walled gardens” and cloud-based ecosystems initially perceived by the market as disruptive, but these models are failing:

• Regarding final users, because the privacy data concerns haven’t yet solved (also because the cloud-based architecture proposed).
• Regarding 3rd party developers companies, because not proposing to them a complete technical advantage and a clear and profitable business model

My personal vision is that we do need a completely different approach, that exits from big player proprietary walled gardens, with two fundamental requirements:

• Hardware: we preferably do need a open-hardware smartspeaker device and some embedded open-software (and common protocols) on top.
• Software: we do need an open-architecture based on the coexistence of “peer-to-peer” multiple (voicefirst) assistants, operating on a common open architecture.

In other words,

• As a final user you wish a smartspeaker where you can use one or more voice assistants (made by “3rd parties”)
• As an application developer (service supplier/enterprise company), you wish a common protocol to plug-in your service into the above open-hardware smartspeaker ecosystem.

What does all this have to do with Telegram?

Even if the famous instant messaging (mobile) app is still a cloud-based closed-source system, an important and well engineered feature is the “by-design” possibility to enable 3rd party bots, in part following the multi-assistant architecture I mentioned above. Let’s deep dive!

What’s Telegram and what Telegram Bot APIs are?

Telegram is, for many reasons and above all user experience and proven security, probably the best instant messaging app available on common smartphones and personal computers operating systems!

This is not only because of the usual reasons Telegram fans mention when comparing this app with unloved Whatsapp, but, for developers, Telegram is great mainly because they can easily build chatbot applications, the so called Telegram Bots.

As all you programmers know, Telegram supplies a totally free, easy and performance-based way to build chatbots, using well done Bot APIs (just updated to version 6.1 in June 2022). You can set-up your chatbot in a few minutes using some high-level APIs on your preferred programming language. Last but not least, Telegram generously allows you to store for free a really huge amount of gigabyte of file storage. So far so good.

My experience as researcher and developer of CPIAbot

When I was researcher at ITD-CNR, from 2018 to 2020, I conceived and implemented CPIAbot, a Telegram voice-chatbot to help foreigners (emigrants) students of CPIA (Italian public adult schools) to learn Italian language as a second language at a basic level (L2/pre-A1).
 
As you can imagine, for a person that has to learn a foreign language, the verbal/spoken language understanding is a fundamental goal. So I allowed my chatbot to get inbound voice messages and to reply with outbound (synthetic) voice messages, back to the user. BTW, following research statistics we elaborated in the experimentation phase, the voice channel has been the preferred way for learners to interact with the bot!

From the UX perspective, using CPIAbot, students send text and/or voice messages to the bot. A custom server produces a text transcript with an ASR engine (at times I used pretty good Facebook wit.ai free service). Afterward the user transcript is elaborated by a dialog manager engine (my own opensourced naifjs) and the response is returned to the user as a text and/or voice message again, using a Google TTS voice, or a human-spoken audio recording. More info about CPIAbot on my old article here and on the academic project home page.

What’s missing in the almost apparent Telegram Bot API perfection?

So far you can develop a Telegram voicebot following the message-based paradigm. That’s not totally natural, I have to admit (from the natural language spoken interactions), even if nowadays people is used to communicate exchanging (also spoken) messages through instant messaging apps. Let’s consider audio messages ok for now.

Now I claim some change requests that could bring Telegram to be a competitor of big-players voice-assistants masterbots (someone says metabots) I mentioned above. Simply speaking:

Imagine your Telegram app as a smart-speaker embedded on your phone, able to connect you to any 3rd party bot without being an all-around “masterbot” assistant.

Sound good! Isn’t it? But how would it work in practice? To enable a great voice interface user experience, some features are now missing.

Change request #1: 🔊 Voice/Audio Messages Auto-Play

You need that when a bot is answering user (spoken) request, the bot voice message (response) is auto-played by the device (just when you are currently interacting with). Now, instead, user must click on the voice message icon to play it.

Of course, also for trivial privacy reasons, I would like to configure (opting-in/opting-out) the auto-play feature, with a general mute-all flag, and/or a bot-dependent flag (I probably want to un-mute just the more frequently used bots).

Related to the voice auto-play experience (and in general about any audio or music content play), of course a smart-phone has not the loudspeaker audio power of a smart-speaker (as the Amazon Echo or Google Nest devices, all great devices, no doubt). 
And even if enhanced with a desired audio auto-play software feature, the coupling with an external (bluetooth-connected?) loudspeaker is something highly recommended, but optional.

Change request #2: 🎙️ Voice Wake-Word Detection

This feature is a bit more complex to implement, and controversial. You would replicate the user experience of the invocation sentence on a smart-speaker, when you say “Hey Google…”, sorry, I mean:

Hey Telegram open MyAppName…

You want the named bot starts waiting your spoken command utterance, recording your voice until a silence is detected, and afterward the audio message is forwarded to the Telegram server as usual (at the end of the day to the MyAppName bot). 
There are also alternative solutions where we come to invocate a specific bot (by example you could want to invocate bot with his specific name, etc.), but you get the idea. Last but not least, the current Telegram client app push-to-talk chatbot selection mode is not so bad, eliminating many privacy-related concerns.

Change request #3: 🖧 A Decentralized Architecture Support for Voice-based Bots

Decentralized, headless or no-brokerage, are possible keywords that could differentiate Telegram bots from the centralized (1st party master-bot + 3rd party skill-bots) approach big-players so far imposed on us. 
In these well-known scenarios the master company supplies a proprietary first-party master-bot (e.g. Google Assistant or Alexa) that commands all the games. In facts in this model, your bot (the action in Google Assistant parlance, or the skill in Amazon Alexa parlance, or the capsule in Samsung Bixby jargon) must follow a rigid contractual and technological framework and all data “passes through” central master-bot cloud servers. That’s bad, or at least, that’s controversial in terms of data privacy, vendor lock-in, etc.

So forget the first party approach of a (big-player owned) cloud system that monopolizes/centralizes traffic of all external (third-party) skill-bots. Instead, imagine Telegram just as a light middleware that supply two things:

• The common client (the TG app) updated with the above proposed change requests to integrate an enhanced voice integration
• Some server-side services on the Telegram cloud server that finally redirect to your (private person or enterprise) bot.

In other words, as final user:

Imagine you could access on your smartphone Telegram app a short-list of voicebot services provided by independent suppliers you (and only you) selected!

In this scenario Telegram would be not the unique (voice) assistant, but just a vehicle to enable you to “talk” with a set of independent assistants of your choice. It’s a complete different business model (with respect of big-players), requiring just minor architectural and software updates on the current Telegram client (and some optional enablers on Telegram servers).

Is this bot-independent model sustainable for Telegram company?

That’s a critical open point. I guess Telegram could set-up the overall architecture:

• Giving for free some basic features (by example the audio auto-play and the wake-word detection on the client, etc.)
• Supplying as paid services some server-side enablers, as a multilingual speech-to-text and text-to-speech platforms, and why not some smart “conversational AI” services to simplify/automatize chatbot developments (as a speech-to-text engine, a text-to-speech engine, an intent/entities classifier, a dialog manager, a semantic search engine, etc. etc.).

Maybe Telegram Premium, extended for a developers program (“Telegram Premium for Enterprises”), could be a possible solution to cover all costs of the upgrade and a possible economical gain?

I imagine by example that TG Premium for Entrprises contract could be set up, in such a way that a chatbot developer company could pay for premium services like a networking traffic enhancement, the use above mentioned server-side enablers, etc. etc.

Please comment!

What do you developers or final users think about all this? 
Please leave your feedback on the comments!

Giorgio

Update: I participated at the www.lingofest2021.com event, 2021, March 26th, presenting my talk: Enterprise Voice Cobots, where this case study is deepened. Slides and video links available at the end of the article.

Voice assistants, for consumers at home, are nowadays taken for granted, but there is a huge space of applications of voice virtual assistants also in enterprise verticals.

I want to introduce my current R&D project, involving an innovative voice assistant application in the logistics shipping container operations.

In a sentence, the voice-cobot I conceived helps forklift vehicle drivers to load and unload shipping containers from/to yard spots from/to container trailers.

Let me share, before all, the general concept of a voice-cobot, as a possible application of a conversational assistive-reality computing. Afterward I will show the solution I found for the specific industrial scenario.

What’s a cobot?

On Wikipedia you get this definition:

“Cobots, or collaborative robots, are robots intended for direct human robot interaction within a shared space, or where humans and robots are in close proximity.”

Well, the above definition refers to industrial robots, hardware machines — capable of carrying out a complex series of actions automatically — guided by a human being, using an external control device or whit a control embedded within. Robots may be constructed on the lines of human form, but most robots are machines designed to perform a task with no regard to their aesthetics.

So in general we refer to cobots meaning industrial robots (the common case is an articulated electro-mechanical robots) that helps automate unergonomic tasks such as helping people moving heavy parts, or machine feeding or assembly operations. But that’s not what I want to talk to you about!

So what’s a Voice-Cobot?

For voice-cobot I mean a voice-interfaced digital assistant that, through a real-time spoken conversation, helps a human operator to accomplish a specific working task.

Now forget the usual virtual assistant scenario that, as end-users, we experiencing with Amazon Alexa or Google Assistant at home, through smartspeakers or smartdisplay devices. Instead I want to talk here about the special case of private virtual assistants for industry enterprises.

The disruption of a voice assistant in enterprise spaces refers to the concept of an assistive-reality computing automation made by a private, company-owned virtual assistant that collaborates with human operators (employees, skilled workers, professional technicians) to accomplish working tasks, literally having real-time conversational interactions (by voice, text, other UI).

Voice is an essential requirement, but the voice interface itself is not the game-changer, instead the collaborative enterprise-assistant computing is!

There is a common misconception where the novelty is just about the fact that you “talk to machine”, using speech (instead of chatting or using a graphical user interface), but that misses the most important point.

A voicefirst interface and maybe a voiceonly interface are — in many cases — the best way to interact with computer, in situations where the human is working “hands-on” as in the case of a vehicle driver, a machine operator, a doctor, etc.
 
Nevertheless, the best human-machine interface must be evaluated case-by-case and it can be made with different strategies, by example in input it could be voice, text, a camera scene, any IoT sensors, where in output it could be voice, earcons, text, graphics, light-signal devices, etc. All this could also work in parallel in a multimodal strategy.

The real innovation is not just the voice interface, but the virtual assistant collaborative logics, meaning that

enterprise processes are controlled by a single conversational-AI assisted-reality computing that interacts with human operators,

collaborating with them to accomplish workflows, and leading to time and costs savings and possibly to a better (and fun) user experience.

The case study: empty shipping containers handling

As a software engineer, consultant and researcher, I was initially asked by DITEN — Università di Genova- Dipartimento di Ingegneria Navale, Elettrica, Elettronica e delle Telecomunicazioni — to solve an apparently standard computer vision text detection/recognition problem.

The topic was to automatically recognize the shipping container marking codes, during the containers loading/unloading tasks made by an operator driving an empty container handler machine.

After some fun (I’m ironic) with text recognition from images algorithms I implemented, I soon realized how difficult is to detect texts in real-life motion scenes. It’s hard to achieve a detection system with an accuracy near to 100%. And what to do in case of the no detection/erroneous cases?

That’s why I got a trivial idea:

What if the operator dictated the code to a voice assistant? Just talking!.

My friend and account manager at DITEN University replied:

Let’s deepen, Giorgio, maybe it’s not crazy as it seems.

So Forklift-cobot born! 
The concept was to supply to forklift vehicle operator, specifically empty container handler and reach stacker, a simple voice assistant command-and-control software, running on common tablet/mobile device fixed on the vehicle cabin.

The foreseen operator’s user experience concept is really simple: he gives voice commands (pull mode) to insert data, as the task name, the handled container code, the container-truck vehicle plate, yard spot name, etc.

The voice assistant checks dictated/spelled data, does search in the company backend database and stores transactions on task completion. Avoiding any stop of the operator just to insert data on a web GUI app (as currently happens).

I made two short video demonstrations of the proof-of-concept desktop-prototype I implemented, where I show the functionalities and the voice interaction activation on a mobile device.

I’m Italian and the the video are realized in Italian language, but you can enable Youtube subtitles in English.

Video Container Handler Operator Cobot Demo — Part 1 (voice assistant general functionalities)

Video Container Handler Operator Cobot Demo — Part 2 (usage on a mobile device)

Research & Development open points

The implemented prototype is now in the on-field test phase, where the proposed system has to be evaluated by expert senior machine operators.

Besides, there are many technical open points, mainly related to the voice recognition/audio subsystems and the on-cabin user interface ergonomics. Let me introduce some.

Speech recognition issues
Noise is a common industrial environment problem and an urgent related topic is the availability of a on-premise noise-proof ASR avoiding any cloud-enabled service. For security reasons, a key requirement is data-privacy: all business processes data transactions must not exit outside the enterprise intranet.

You need local and private (on-premise), multi-lingual, noise-proof robust speech recognition engine (ASR).

Voice activation UI, human-machine HW interfaces
A not-trivial aspect is related to find the suitable hardware interfaces with the cobot, case-by-case.

The current speech activation solution is done with multiple concurrent (working in parallel) push-to-talk solutions, as touchscreen, foot-switch activation, or physical push-button on the vehicle dashboard (see figure here below).

Also the mic/headphones subsystem has challenges solvable with many audio options: headset, open-air mic/loudspeakers, etc.

The webapp-based architecture
As shown in the videos, the prototype has been implemented with a client-server web architecture. Having implemented the client as an application running on a standard web browser on top of any mobile device, has many pros.

All the audio message exchange is realized with the Web Audio API and currently any web app (on a mobile device) can access also any internal devices (even the video camera streaming), the GPS geolocation coordinates and accelerometers (helping to localize the vehicle movement), even USB interfaced external devices (e.g. a RFID long-range reader), last but not least some Bluetooth interfaced peripherals (audio I/O, custom buttons), etc.

To wearable or not to wearable?
Another advantage of having the client running on a (web app) mobile device, is just the fact the “terminal” of the cobot run on a very cheap portable handset. You can use pretty any mobile phone or tablet, to be mounted inside a cabin and/or to be used outside the cabin, by an operator walking with the handset, for different tasks, as container positions control in the yard area, etc.

That said, the mobile device web client is just an option among many others. A “fixed” client could run on a more powerful edge-computer, or even a micro-controller.

Another alternative to mobile tablet/phones is a smartglasses wearable. Apparently that’s the definitive solution, but with a lot of issues like high costs, lack of standard API interfaces, unergonomic for an operator inside a cabin.

Conversational design
On the (software) user interface side there are interesting conversational design research topics. The current UI implementation uses a tablet/mobile device. The client-side software runs on a web browser and exploit some multimodal paradigms using voice, texts and, last but not least, usual graphical interface capabilities of a browser.

By example, in the prototype, the screen background color has been used to visually explicit the status of conversation turns between the user and the machine. Synthetic voice (TTS) short answers and prompts are accompanied by longer explanations written on the display, added by suggestions of the next steps the user could have to do, etc.

The command-and-control approach is less simple than what appears, especially if the conversation between user and the machine has to be at the same time short but nice and even engaging.

Maybe there is a challenge if you want to integrate the task-completion essential features (minimal requirements), with a domain-specific or open-domain question-answering query system, or you want to manage any user-defined alerts and reminds, an inter-operators intercom subsystem, etc.

Conversational AI backend computing
Here’s where it gets tricky. Consider the voice-cobot not just as yet another vertical application to solve a specific enterprise task.

Instead the cobot become the “enterprise’s computer” able to talk with the single user with possibly a user-defined botpersona, adapted to that user needs and preferences, and at the same time serving users for many requirements, as a single “company voice”.

The company cobot bot-persona appears to users as different (user-defined) bot-persona while being a single business logic intelligence.

Last but not least, the kernel component is the dialog manager / conversational AI intelligence.

For the prototype, because of the pretty “simple” scenario, I used my own dialog engine NaifJs — that I opensourced in 2020 — where dialog tracking is based on a state-machine approach.

For more complex scenarios, with many concurrent tasks and push mode/mixed-initiative where the assistant start a conversation, maybe to assign tasks, etc. the current implementation could be enhanced with an high-level rule-based language. This is an open research topic.

Another applied research/engineering topic is about how to “standardize” the company knowledge-base/database integration.

The problem could be solved trivially with APIs and database queries but the real challenge is to define a standard common ground company private knowledge base, to be queried and used for inferences made by the conversational AI.

Temporary conclusion

The described case study describe a very specific shipping industry scenario where a voice-cobot helps the working tasks of a container handler vehicle operator, reducing times and costs.

The described assistive-reality system is applied to a specific industrial operation, but it could be applied to many other factory tasks and different operator roles. By example, in the shipping container depots/repairs industry, the voice cobot could assists many other kind of human operator activities: truck gates automation, container inspection reporting, safety/emergency alerting, truck drivers “help desk”, operators tutoring, etc. etc.

Is all not just about another voice-interface application in industry. It’s instead about the rethinking of all business processes, where an assistive enterprise computing could collaborates with many/all humans. 
Isn’t this just Industry 5.0?

2021, March 26th I participated at the www.lingofest2021.com event, presenting my talk: Enterprise Voice Cobots, where this case study is deepened.

Slides @ #lingofest2021:
https://docs.google.com/presentation/d/1ieZnAdREzEGXkcO4C_XPIbS9YAnE76mB0wpP2k-yOlQ/edit#slide=id.g4412d4946c_0_0

Video @ #lingofest2021:

Video My “Enterprise Voice Cobots” presentation at www.lingofest2021.com event, 2021, March 26th

Contact

If you are an enterprise company, maybe in the shipping / supply-chain/ smart-factory automation, or in any vertical where you think a voice-bot could solve a real workflow, or you are in R&D ICT company, or if you are an academic organization and you are interested on deepening this applied research contexts, I’m available to collaborate, as researcher and as a consultant.

You can contact me on linkedin or just send me an email at giorgio.robino@gmail.com.

I learned of Almond, the Stanford University open virtual assistant, for the first time one year ago reading an article on voicebot.ai. 
I have been immediately enthusiastic about the core concepts on which the project is based: the user’s data privacy, the need of a web based on linguistic user interfaces, the distributed computers architecture, the natural language programming approach and many others topics related to a possible next generation of the web, populated by a federation of humans and theirs personal assistants.

Soon I discovered that one of the principal developers of Almond software is Giovanni Campagna, a PhD student in the Computer Science Department at Stanford University and member of the Stanford Open Virtual Assistant Lab (OVAL) who works with prof. Monica Lam. Hence the idea of my interview with him, about the past and the future of Almond and personal virtual assistants.

Introduction to Almond

Giorgio: Ciao Giovanni! In order to sketch out what it is and what it will be Almond, may you briefly summarize the project history? The oldest public presentation I remember was by Monica Lam in fall 2018. May you give us the basic concepts of the project and explain what is the role of Almond within OVAL laboratory research?

Giovanni: The Almond project started in Spring of 2015 as a class project to explore a new, distributed approach to the popular IFTTT service. At the time, it was called Sabrina. Soon after, we realized the need for both a formal language to specify the capability of the assistants, and a natural language parser to go along with it, so end users could access those capabilities. The first publication for Almond, and the first reference under its current name, came in April 2017 at the WWW conference, where we described the architecture: the Almond assistant, the Thingpedia repository of knowledge, and the ThingTalk programming language connecting everything together.

Since then, we have been working on natural language understanding, focusing in particular with the problem of cost. State of the art NLU, used by Alexa and Google Assistant, requires a lot of annotated data, and is very expensive. We made two recent advancements: first, in PLDI 2019 we showed that using synthesized data can greatly reduce the cost of building the assistant for event-driven, IFTTT-style commands. Later, in CIKM this year my colleague showed how to build a Q&A agent that can understand complex questions over common domains (restaurants, hotels, people, music, movies, and books) with high accuracy at low cost.

In ACL this year, I presented how the same synthesized data approach can be used to build a multi-turn conversational interface, achieving state of the art zero-shot (no human-annotated training data) accuracy on the challenging MultiWOZ benchmark.

Most recently, we have received a grant from the Alfred P. Sloan Foundation to build a truly usable virtual assistant (not just a research prototype), and we hope to release it in 2021.

About Giovanni Campagna as researcher and developer

Giorgio: I’m curious about your personal history, Giovanni. I know you are Italian and probably you moved to Stanford as a PhD student. What made you start developing Almond? Did you initially work on Almond as part of your PhD thesis? Are you the leader of the software project development? And how is the team composed? Besides the Almond project, What is your current role in the OVAL team and what are your long-term research interests?

Giovanni: I moved to the US and to Stanford as a Master’s student, and I started Almond in class. I was interested in programming languages and pursuing the software theory concentration, which includes PL, compilers, and formal methods. I met Prof. Lam in her Advanced Compilers class. At the time, she was mainly focusing on messaging and social networks, with the goal of disrupting the Facebook monopoly (this was part of the Programmable Open Mobile Internet initiative, aka the Mobisocial Lab). But even then, she had the vision of what would come next, and while Alexa was not popular yet, it was clear that virtual assistants would be the next potential monopoly.

Personally, I started developing Almond as research on the ThingTalk programming language: designing a programming language that can enrich the power of the assistant beyond simple commands, and give the power of programming to everyone. Parallel to ThingTalk, I worked on converting natural language to code, because natural language is the medium of choice to make programming accessible. Our research found that neural networks are extremely effective for natural language programming tasks, as long as training data is available. ThingTalk is still the core of my PhD thesis, but over time we moved our focus to reducing the cost of training data acquisition.

I built the original version of the Almond assistant, and a large chunk of the current code, so in a way I am still the maintainer of it, but Almond would not have been possible without the help of my colleagues. These include Silei, Michael, Jackie, Mehrad, and Sina (all current PhD students). Silei was the first to join after me and he’s the second-most active dev on Almond. His research is mainly on Q&A over structured data. Michael recently defended his thesis; he was working on multi-modality: bridging GUIs and natural language. Jackie also worked on multi-modality, with a paper in UIST on mobile app interactions using natural language. Mehrad is working on multilinguality leveraging machine translation technology, as well as named entity recognition. Sina is working on Q&A over free text, paraphrasing, and error correction. Additionally, we have a number of MS and undergraduate students who have helped on various projects.

What is your view on data privacy and how this is related to personal assistants?

Giorgio: Data privacy is probably a foundation concept that gave birth to the Almond project. May you deepen why privacy is so important for all of us, citizens and companies? How is all this related to democracy and people’s freedom on the web?

One problem I see in current big player personal assistants is the fact that people’s data (voice conversations, also containing background ambient audio, e.g. at home) are processed by cloud systems proprietary platforms. In the best scenario, all this data is used to improve “AI-blackbox” cloud-based proprietary services, feeding machine learning algorithms. In the worst case, conspiracy theorists do suppose a malicious use by such companies that would steal personal end-user data populating people’s knowledge bases for any further commercial usage. Do you consider this last scenario an actual concern?
To protect privacy, in opposition to cloud-based “walled gardens”, Almond provides a tech architecture based on virtual assistants that can run on users’ devices. Do you think that the issue can be fully solved at the architectural level or do we need in any case government regulations?

Giovanni: This is not an easy question, and let me preface by saying this is my personal opinion, not the project’s. I think privacy is inextricable from freedom: I am not truly free if everything I do is tracked, logged, and stored forever by a company or government. I am not truly free if I can be judged in the future for anything I’ve done at any point in my life. One closes the blinds to be free to do whatever in the privacy of their home. And because so much of our lives is now conducted over the Internet, it’s clear that Internet privacy overlaps significantly with real life privacy.

Now, as you point out, virtual assistants and conversational AIs in general pose unique challenges to the privacy problem. First, state of the art natural language requires a lot of user data for training, which means the virtual assistant providers are continuously collecting all the conversations performed on the assistant, and have contractors continuously listening and annotating the data. To have somebody listen to my conversations, that’s not very private. Reducing the need for annotated real data has been a strong focus of our research, and we believe we’re finally getting there.

Second, and most importantly, virtual assistants inherently have access to all our data, through our accounts: banking, health, IoT, etc.. We want the virtual assistant to get access to our accounts because we want help, and we want the convenience of natural language. But what guarantee do we have that a proprietary service won’t suck all the data and use it for marketing purposes? Why wouldn’t a proprietary assistant provider look at our banking information to promote a credit card or mortgage product? Why wouldn’t a proprietary assistant look at the configured IoT devices to promote similar or compatible products? And with Amazon and Google dominating the online retail and ad markets respectively, it would be surprising if they did not eventually start doing that.

Tell me about your general vision on open-source software

Giorgio: I see that many Almond software components are made in Node.js and I know you have been a member of the Linux/GNOME community. Could you share your point of view about the importance of open-source software in general, such as the Linux operating system (I know you are a Linux desktop user, like me). How open source and open data are related to data privacy?

Giovanni: I have been an advocate of free software for a long time, and I am a strong believer of the four fundamental software freedoms as purely ethical principles. The freedom to study software is what allowed me to learn how to build software before I started college, and the freedom to modify and distribute software allows people to collaborate and build something bigger than any single individual could build.

I also believe that, unlike proprietary software, free software cannot abuse the trust of users. It is trivial to detect a free software app collecting more data that claims, or doing anything shady with the data. It is trivial to fork the app and remove any privacy-invasive functionality. Hence, free software communities are very careful to gain the trust of users and protect their privacy. You can see it for example with Firefox: while Firefox collects data for telemetry, they’re very careful to allow people to disable the telemetry, and do not collect more than they claim.

Giorgio: Why did you decide to develop Almond in Node.js? As nodejs developer myself, I’m specifically curious about the engineering reasons that drove you to use the Javascript environment. Is it an opportunistic matter, maybe because it is easy with nodejs to develop in multi-platform environments? Or are there other software engineering reasons?

Giovanni: I chose to build Almond in nodejs because it is the most portable platform. At the beginning, we had this idea that the full Almond assistant could run on web, phone (Android and iOS), desktop, embedded. Nodejs is the only platform that supports that. Over time, we found that running the assistant on Android or iOS is quite challenging, and we moved to an architecture where a user keeps the assistant running on a home server or a smart speaker. Yet, I still find nodejs more programmer friendly and just nicer to work with than the obvious alternative, Python. I should also note, using a type-safe compiled language would have been challenging, given the ever changing nature of a research prototype.

What do you mean by Linguistic Web?

Giorgio: Regarding Almond’s core concepts, I have been impressed by the statement “We are witnessing the start of proprietary linguistic webs” that I found in these Almond presentation slides. May you clarify what you mean by Linguistic Web? Are proprietary linguistic webs an implicit reference to Google Assistant and Amazon Alexa voice-based / smartspeaker-based virtual assistants? If so, what are your concerns in the “walled gardens” proprietary (virtual assistants) ecosystems and how Almond could be an alternative for private citizens and/or companies? What are strengths of open and non-proprietary platforms to improve (linguistic) democracy (and freedom) on the web?

Giovanni: That is exactly right: what we’re referring to is the third-party skill platforms being walled gardens controlled top-down by the assistant providers. Any company who wishes to have a voice interface must submit to Alexa and Google Assistant. As proprietary systems, these can shutdown competing services, or impose untenable fees.

We believe instead that every company should be able to build their own natural language interface, without depending on Amazon or Google. These natural language interfaces should be accessible to any assistant. One example of work in this direction is Schema2QA (to appear in CIKM 2020), a tool to build Q&A agents using the standard Schema.org markup. Any website can include the appropriate markup to build a custom Q&A skill for themselves, and furthermore the data is available to be aggregated across websites by the assistant.

Could you explain what Natural Language Programming is?

Giorgio: Could you define what LUI (Linguistic User Interfaces) and Natural Language Programming mean for you? With the popularity of smart speakers and current voice-first interfaces we are moving from the GUI (Graphical user Interface) to CUI/VUI (Conversational / Voice User Interfaces). One of Almond’s disruptive milestones is the idea that the final user must program himself his personal virtual assistant, just speaking with a computer in natural language. That’s currently an unachieved goal, in human-machine interfaces.

What do you think it will be, say in the next ten years, the way users will program their private virtual assistants? More in general, do you foresee that common people will interact with computers (and professional software developers will develop applications) in some sort of natural language programming?

Giovanni: To me, there is no distinction between LUI, CUI and VUI. Of course, language is conversational, and we expect the assistant to sustain multi-turn conversations, with follow-ups and error correction. This is by the way something that Alexa and Google do very well for their first party skills, but don’t really offer to their third-party skills, which get basic single-shot intent classification and perhaps simple slot filling. (In contrast, Bixby is another assistant that is built conversational from the start, and in many ways has a similar design to Almond). Note also that voice tech is mature and standard STT works really well.

Where things change is natural language programming. Ultimately, the goal of a virtual assistant is to use natural language to do things, and because the assistant is a machine, all it can do is execute code. So the idea is that every natural language command issued to the assistant can be mapped to an executable statement in a programming language (a domain-specific language, in our case ThingTalk). The job of the assistant then is just to execute the generated code and present the results to the user. Once you frame the assistant this way, the capability of the assistant is only limited by what the DSL can represent. For example, we experimented with a DSL of access control policies, and found it could be used to grant fine-grain access to shared devices and accounts (in Ubicomp 2018).

Which is the personal assistant end user experience, according to Almond vision?

Giorgio: Which kind of personal assistant user experience Almond provides to end users? It seems to me that Almond is built upon the task-oriented approach to automate everyday user actions/tasks (especially browsing/querying the web), following the IFTTT-like way (“alert me when the price of BitCoin is below $3600”). This approach reminds me of the Google Assistant mantra “To get things done” and that’s smart! This kind of personal-programmed micro-tasks completion feature is in fact pretty absent (or just hinted) in big players platforms such as Google Assistant and Amazon Alexa.

On the other hand, Google and Amazon provide some sort of general-purpose / not-personal basic question-answering and (news/ music) streaming services, referring to third party developers (Action in Google parlance / skills in Amazon parlance) for any other specific service.

May you deepen the key values and UX features that differentiate Almond from big players?

Giovanni: First of all, I want to stress, Almond is still a research prototype. It is an experimental platform to test our ideas, both in NLP and in HCI. We have received a grant from Sloan to turn the prototype into a truly usable product. As we do that, we imagine we will also focus on the most important skills: music, news, Q&A, weather, timers, etc. Yet, the technical foundation to support end-user programming will remain there, and we will try to support it going forward.

In terms of differentiating features, I imagine the key differentiator is really privacy, rather than UX. I imagine Almond will be supported on a traditional smart speaker interface, because that’s the most common use case for a voice interface. I also personally like using Almond on the PC, where we have an opportunity on the free software OSes. I’ve given a talk at GUADEC (the GNOME conference) recently about potential opportunities there.

Giorgio: What do you think about the big player server-centric (1st + 3rd party) information architecture, especially in terms of quality of service to end users?

Giovanni: Finally, because we’re fully open source, I think the distinction between first party and third party will be blurred in our assistant. We give the same technology to everyone, unlike Alexa for example which keeps AMRL (the Alexa Meaning Representation Language) only for first party skills. We imagine that even long tail skills will be developed in an open repository, and everyone will collaborate to build those skills. 
The model should be similar to Home Assistant, a leader in the open-source IoT space, which is all built by the community.

About the NLP chain: LUINet, ThingTalk and Thinkpedia

Giorgio: Could you introduce the Almond natural language processing chain you conceived?

Giovanni: The key idea of our approach to NLU is to factor the domain-independent aspects of natural language from the specific domains. Our goal is to raise the level of abstraction, so that developers don’t have to build the same thing over and over again. Instead, we want developers to specify their APIs and database schemas, with a few bits of natural language on every field. We then use a general state machine of dialogues and a general grammar of English to synthesize millions of dialogues that talk about the domain of interest, which we train on. The tools to build these synthesized datasets for training are part of Genie, which is the core NLP technology backing Almond. In diagram form:

At inference time, this is what the agent does:

Our pipeline uses a neural semantic parser (the LUINet model, based on the BERT-LSTM architecture) to understand the input sentence, and maps it to an executable form in the ThingTalk programming language. The ThingTalk code makes use of primitive APIs defined in Thingpedia, such as the Yelp skill in this example. The code is JIT compiled and executed, and returns the results. The results are then passed to a general dialogue state machine, that, given the AST of the executed code, the results, and annotations on the APIs, is able to generate both the new formal representation of the dialogue, and the agent’s utterance.

Here is the state machine at a glance:

The interesting aspects of this state machine is that it does not depend on the particular domain of interest. So the same state machine can be used for restaurants, movies, music, etc. The state machine is built once and for all, and new domains can be plugged with very little cost. Additionally, when the state machine is refined to add new features, the refinements are shared across all skills. This is also a way in which all skills are “first-party skills”: all skills benefit from the work done to improve other skills, when that work is not domain-specific.

About the technology behind the Almond NLP chain

Giorgio: The work you made with LUINet, Genie, and all other components is impressive! It seems to me that you followed the “classic” semantic parsing approach where natural language statements are translated to a formal language (ThingTalk). The semantic parsing approach makes absolute sense for me, maybe differentiating itself from currently very popular intent-based probabilistic classifiers approach, used by Google (Dialogflow), Amazon (Lex) and many other NLU (Natural Language “Understanding”) platforms available on the market.

Could you deepen how the Almond approach differs from the intent-based classifiers? What are pros and cons of these different approaches? 
Don’t you think that in the long term the intent-based machine learning could be a simpler way to let the assistant learn (”retrain”) new user intents/requests? On the other hand, in the long term, the Almond NLP formal language production would win in terms of AI explainability in a possible “machine reasoning”. What do you think about it?

Giovanni: First, let me clarify that when we say semantic parsing, we mean neural semantic parsing, rather than classic semantic parsing. Classic semantic parsing is template or grammar based, and tries to match spans of the sentence to specific primitives in the knowledge base. 
Neural semantic parsing instead has a lot more in common with machine translation: a sentence is fed to a neural network, and the neural network outputs a program, token by token. 
That makes neural semantic parsing a super set of intent-and-slot systems: intent-and-slot are similar to semantic parsing, where the target language has a single function call with parameters. 
The neural semantic parsing approach is more general, because the target language can be any formal language, and need not match the sentence exactly, nor it needs to be limited to only one API call. For example, semantic parsing allows us to translate questions to SQL-like statements with joins, projections and filters, instead of hard-coded API calls, which allows us to better understand complex questions.

The downside is that neural semantic parsing requires more data to train, which, if annotated by hand, must be annotated by an expert. Building a semantic parsing training set by hand is practically infeasible: the closest that has been built are dialogue state tracking datasets such as MultiWOZ (which are known to have annotation problems) or paraphrase-based datasets such as Overnight, WikiSQL and Schema-Guided Dialogues (but performance on paraphrase is known to overestimate performance on real data). On the other hand, Genie allows us to use synthesis for the training set, and only annotate a small amount of data for evaluation, which makes semantic parsing practical again.

I imagine long-term all assistants will move to semantic parsing. Note for example that Alexa is also using some form of semantic parsing (through AMRL) for first-party skills. Intent classification is too limited in what kind of sentences are understood.

Genie also differs from other assistants in how it approaches state tracking (carrying over state across multiple turns). While commonly used tech separates NLU and state tracking, Genie combines both problems into a single neural network. This reduces the problem of “unhappy paths” typical of rule-based state tracking, where all the different ways the user might continue the conversation or change the subject have to be modeled explicitly. 
The rule-based state machine is still imbued into the neural model using the state-machine based synthesis, but the neural network can generalize beyond it. In our experiments on the MultiWOZ dataset, we found the state machine could cover 83% of turns, but the neural network could still interpret correctly 47% of the remaining 17%, hence generalizing in what state transitions are supported by the agent. 
See paper: State-Machine-Based Dialogue Agents with Few-Shot Contextual Semantic Parsers.

Will ThingTalk evolve from a smart commands interpreter to a full “conversational companion”?

Giorgio: I see ThingTalk, the Almond natural language programming language inspired by IFTTT, as the first attempt to implement a general natural language programming. Using ThingTalk you can set-up in natural language some “actions’’ triggered by external (web APIs/local) events (e.g. “When I use my inhaler, get my GPS location, if it is not home, write it to a log file in Box.”). 
Does ThingTalk also include any personal-facts continuous learning and a personal knowledge base memory? 
Do you have any news about how Almond could eventually evolve into a general-purpose personal “conversational AI”, able to sustain multi-turn conversations, not only in event-based task-completion contexts, but maybe also in companion-like open-domains / chit-chat dialogs?

Giovanni: This is absolutely on our radar. First of all, we’re partnering with Chirpy Cardinal, another Stanford project who won second place in the Alexa Social Bot Challenge. In the near future, we will integrate Chirpy Cardinal into Almond for companionship and chit-chat capabilities.

We also imagine that the assistant will learn the profile of the user, their preferences, and will have memory of all transactions, inside and outside the agent. We do not have any released work on this yet.

About stateful and contextual dialog management

Giorgio: In general, one topic I’m personally obsessed with is how to program multi-turn chatbot dialogues, in contextual (closed/open) domains. That’s a goal not yet achieved by Google and Amazon cloud-based assistants. To date, in fact, both the famous systems surprisingly do not maintain dialog context in multi-turn conversations even on a simple domain as weather forecasts. The lack of context is not just related to conversational domain, but also to the “time”. Namely, the above mentioned voice assistants are not able to remember pretty anything about a previous interaction with a specific user. No memory (“stateless”, if we think about a conversation as a state-machine workflow). Worst, there isn’t any incremental learning by conversations.

Now, in what directions do you think conversational technology will evolve? Personally, I foresee a next generation of personal assistants that will be able to sustain task-based / closed-domains dialogs (say in the ThingTalk way) and to chat about general open-domain knowledge. The basic personal assistants feature I do not see yet in any state of the art chatbot is the ability to understand and reason about personal user facts. Do you agree with this view?

Giovanni: I think state of the art assistants will grow conversational capabilities for task-oriented skills very quickly. Some, like Almond and Bixby, are built to support multi-turn from the start. Others, like Alexa, will require re-engineering for multi-turn, but they will get there very soon. See also Alexa Conversations as an emerging technology for multi-turn, multi-skill experiences.

Incremental learning is a much more open-ended area. There is a large body of work in this space, starting with LIA, the “teachable” assistant from CMU. I also imagine the assistant will grow a profile of the user, both by data mining on the conversation history and by explicitly tracking a KB of the user’s information. In a sense, this is already available: the assistant knows my contacts and family relations, it knows my location, it knows my preferred music provider, etc. It will only grow over time as more features are added.

Giorgio: BTW, what is your opinion about any practical usage of “statistical web-crowd-sourcing” (my definition) in systems like Generative Pre-trained Transformer 3 (GPT-3), the auto-regressive language model that uses deep learning to produce human-like text?

Giovanni: Pretraining is at the core of the modern NLP pipeline, whether it’s masked-language-model “fill in the blanks” pretraining (BERT and subsequent works), generative pretraining (GPT 1, 2 and 3) or sequence-to-sequence (T5, BART). It is key to understand language, because it can be trained unsupervised, so it has significantly less cost than supervised training. I can only imagine the use of pretraining will grow over time. As for GPT3 specifically, the few-shot results are honestly impressive on a range of tasks. At the same time, the model is so large that it cannot be easily fine-tuned, so it’s quite difficult to apply it to a downstream task.

Giorgio: About closed domain vs open domain chatbot building, what do you think about RASA (the open-source opensource engine to build contextual assistants) approach?

Giovanni: What RASA is doing is quite interesting in that they’re also trying to push the envelope of conversationality, and they also recognize the limit of intent-based systems. At the same time, I see their current NLU product is still using a classic intent-based dialogue tree. Their dialogue manager requires fully annotated examples of conversations, which are incredibly hard to acquire and annotate well. But I’m looking forward to new stuff, when it becomes available!

The Distributed ThingTalk Protocol and the Federated Virtual Assistants Architecture

Giorgio: One of the things I love more of Almond is the vision of a next generation web made by a network of federated (Almond based) virtual assistants. As far as I understood, in this model each person would have a virtual assistant acting as a virtual secretary and talking with other people-clones assistants or people directly. The virtual assistant would act as a “programmable interface”, managing “access control” and sharing personal info based on dynamic programming made by users themselves. That is, in my opinion, very powerful and disruptive! May you explain this concept and could you give us some technical implementation architectural details?

Giovanni: I think your question summarizes it very well. The idea is that every person would have their personal virtual assistant running on their own trusted device. The virtual assistant executes requests on behalf of the owner, and on behalf of others, with access control. The requests are represented in ThingTalk and exchanged over a messaging protocol; in our prototype, we used the Matrix messaging protocol. The access control policies are also represented in ThingTalk. Access control is enforced using Satisfiability Modulo Theory, so the access control is formally verified. I recommend looking at our Ubicomp 18 paper for further technical details. 
The interesting thing of this work though was noting how useful fine-grained access control would be: in our user study, we found that across 20 scenarios, the willingness to share data and accounts would double with fine-grained control. We also found that our access control language covered 90% of the enforceable use cases suggested by crowdworkers.

On which devices Almond will run: smartphones, smart-speakers, personal computers?

Giorgio: I know you spent a lot of energy trying to run Almond on a vast range of personal computer platforms, focusing on the Android app as a common “personal computer”, maybe because smartphones are the personal computers in this era, for common people. Beside, one of the possible weaknesses I see in Almond is the absence of a (home-based) voice-based interface, maybe through an open-hardware smart-speaker? Do you have any plan to allow private citizens to interface Almond through smart-speaker or any voice-based platform? What are pros and cons of voice-first interfaces?

Giovanni: We absolutely see Almond on the smart speaker as a first class citizen. Since fall of 2019 we have partnered with Home Assistant to bundle Almond as an official add-on, so you can use Almond to control a Home Assistant-based smart speaker. That means one can build a fully open-source voice assistant stack using a Raspberry Pi, Home Assistant OS, and Almond. There are a couple challenges in using Almond with a pure voice interface, mainly around the wake word, for which there is no easy to use open-source solution. (Recently, we discovered Howl from UWaterloo, which is also used by Firefox Voice, and we’re investigating that). Also, building a conversational interface that is friendly to pure speech output is not easy. Even commercial assistants work better on a phone when they can display links, cards, and interactive interfaces.

Could the Almond federated architecture be also a solution for business companies?

Giorgio: A distributed architecture of virtual assistants (where each end-user has his local assistant) that allows people to tune a fine-grained access control, selecting what info is public and what actions external assistants (aka people) can access to, seems to me a breakthrough in the current debate on personal data sharing.
BTW, You may know that Tim Berners-Lee in 2018 announced to be working on a personal assistant (code-name: Charlie). “Unlike with Alexa, on Charlie people would own all their data”. Are you in touch with him or any people at Inrupt?

Giovanni: I know that Monica has spoken with Tim Berners-Lee in the past. In any case, I believe this space is quite young, and there is certainly an opportunity for multiple open-source projects who focus on different aspects of the stack. Our focus is really in the NLP and dialogue management, while their focus seems to be the distributed architecture.

Giorgio: Almond seems now focused on providing an assistant to private citizens (end private users). The distributed architecture and the access control management you propose for end private users couldn’t be applicable also to business companies that want to provide their services to people? I imagine a scenario where an end user’s assistant talks to a company-assistant. May this Almond possible extension in the future be coupled with Thingpedia APIs?

Giovanni: Of course! The goal of our research prototype of a distributed virtual assistant was to show how useful access control can be in natural language. The use cases need not be limited to consumer access control: it could be applied in corporate settings, and it could be applied to sharing data between consumers and businesses. For an example of the latter, see this paper from HTC & NTU which uses ThingTalk technology to audit sharing of medical data.

First European Open Virtual Assistant Workshop

Giorgio: In June 2020, the First European Open Virtual Assistant Workshop scheduled by OVAL was cancelled due to the COVID-19 outbreak. The goal of the workshop was to introduce OVAL lab’s open, federated and privacy-preserving virtual assistant to the European research and business communities. There is any plan to reschedule the workshop?

Giovanni: Unfortunately, as you can imagine all in-person events have been canceled for the foreseeable future due to COVID-19. I don’t know at this time when the workshop will be rescheduled.

Giorgio: In general, what do you think about the recent European citizens’ privacy-preserving initiatives and related supporting laws (see GDPR regulations, the recent GAIA-X project and, specifically regarding personal assistants, the Fraunhofer SPEAKER platform)? Do you see common points between current European policy on “data sovereignty” and the Almond goals?

Giovanni: I think European efforts in this space are very important in terms of raising awareness of the importance of privacy. Building effective alternatives to the Amazon / Google duopoly is one way to restore privacy, like we’re doing with Almond.

At Almond, we’re also collaborating with the AI4EU initiative, which aims to build an European cloud of AI infrastructure.

At the same time, on a purely personal basis, as an European citizen with an opinion, I often disagree with the choices of our Commission, which seems to be animated more by economic strategy (and fear of American competition) than by sincere values. The goal should be privacy for all, not just making sure the next Google pays European taxes.

Often, it is also difficult to assess certain projects, because there is no open-source code, no released product, not even a development version. We see a lot of press releases and reports, but there is no sense of a coherent software artifact, accessible to developers. Even for the two projects you linked, development has reportedly started, but there is no code accessible anywhere. To me, and I stress this is a purely personal opinion, this is not the way to run a successful open source initiative.

How do you see the future of Almond?

Giorgio: Recently Almond received Sloan Support. As far as I understand, the new funds will support the engineering of Almond solutions, with the goal to convert the developed prototypes into real products usable by consumers.

May you give more details and describe the next steps of the project, in the short term and in long-term (say next 5 years)?

Giovanni: The short term goal, in the next year, is to use the funds from Sloan and other foundations to build an initial product. We aim for a small initial user base of enthusiasts who care about privacy.

The long term goal is then to use this initial product to further fund raise, and then use the established product to build both a successful open-source community, and an ecosystem of companies using Almond technology in their products. This should allow Almond to thrive and become self-sustainable.

Recent Talks (2020)

Almond: An Open, Programmable Virtual Assistant 
Giovanni Campagna, GUADEC, the GNOME Conference, ORBIS 2020, 
July 24, 2020.

Building the Smartest and Open Virtual Assistant to Protect Privacy
Monica Lam, Stanford Online Seminar, April 9, 2020.

Links

Giovanni Campagna home
Almond project home
Stanford Open Virtual Assistant Lab
Open Virtual Assistant Initiative Wiki
Almond Community Forum
Almond open-source repositories

How to contribute to Almond

Updates: 
september 22th 2020: in paragraph “About the technology behind the Almond NLP chain” the answer has been integrated, inserting the link of a new paper.

This article is a remake of my original answer to Julie Daniel Davis article Google Assistant versus Amazon Alexa: Which Could be Queen of the Classroom?
 I mitigated the original title “Are Alexa and Google Assistant both looser in edutech space?”, too extreme and generic, I admit. 
The reviewed article is above all a way of reflecting about my experience with CPIAbot, a chatbot I’m developing to assist no-native italian language L2/PreA1 (almost illiterate) students of some Italian public schools, as part of a ITD-CNR research project. 
More broadly, my thoughts are about some limits of today Amazon and Google voice assistant and smartspeakers technology.

Almost one year ago I started to develop CPIAbot, a language-first, voice-first multimodal chatbot, running on Telegram, to assist foreigners, students of CPIA, Italian public adult schools courses, to learn Italian language basics.

Let me tell the story. In fall 2018, our initial research goal, at ITD-CNR, was to realize a smartspeaker application (on Alexa or on GoogleAssistant) but we faced many issues. I detailed a long list of points in an academic paper I’ve just submitted (soon available), entitled “Un assistente conversazionale a supporto dell’apprendimento dell’italiano L2 per migranti: CPIAbot” (more details at the end of this article).

Long story, short, about using smartspeakers in our ongoing experiment:

From the linguistics/educational perspective, a voiceonly application is too demanding in term of learner’s cognitive effort, especially in the case of no native/illiterate learner (QCER level L2/Pre A1) .

Unique User identification

There are also many related tech issues, but for me, in educational realms (in classroom or outside the classroom),

the big issue that both systems have is the lack of a real Unique User Identification.

That means a way to identify uniquely the user (any student, any teacher) of the (conversational/voice) application. Having an user ID requirement is for me essential for any chat or voice application made with the goal of follow the student learning.

The related big point is related to the impossibility to process voice recordings of students. In short:

an Alexa Skill or a Google Assistant Conversational Action can not access user voices. Full stop.

Here below I deepen the voice/text flow that happens when a user interact with a third party app on Alexa or Google Assistant (through a smartspeaker).

Personal Voice Identification

Voice signature identification is just a subtopic of users (students) identification need. Probably we could renounce to identify a student by his/her voice, but at the end of the day we need to identify the student (especially for personalized exercises, part of our application/research goal). If we want to track and improve the specific student learning progress, we need to identify him/her.

So far, both Alexa and Google Assistant do not provide a convincing/final solution to identify speaking user in front of a smartspeaker (a far-field device).

Twitter https://twitter.com/solyarisoftware/status/1197248086390784000?s=20

Both big players allow to identify a small set of voiceprints (Google call these voice matches, whereas Amazon call these voice profiles). Google Assitant recognize a max of six different voices, whereas is not clear if there is a limit of recognized voices in Amazon Alexa. The good news is that both systems pass info to third party skills. See here and here.

But the proposed solutions are unpractical or even impossible in classroom scenarios, where there could be a lot of students in front to a single smartspeaker. All in all, the present voice recognition is not a suitable solution to identify a student.

Users Speech (voice recordings)

Voice recognition a part, there are other basic limits about voice recordings in general. The biggest issue involves privacy topics, but let take a part that thin ice for now; just let’s talk about some flat technical points:

both Alexa and Google Assistant “by design” do not forward the users (students in our case) voice recordings to third party skills/actions.

Generally speaking, this is quite understandable because big players do not want any possible malicious use of people voices by third party applications. But this inhibit a lot of smart elaborations the application could do with voice analysis. I already point out the need to use voice print recognition to identify speakers, and…

without the student audio/voice recordings, the application can’t do correct pronunciation analysis, sentence intonation recognition, emotional detection (“sentiment analysis”), etc. etc.

On Alexa, user utterances are not forwarded to the third party skills

In case of Alexa, user utterances (transcripted from voice to text) are not forwarded to third party skills, “as is”. In facts it happens that:

An Alexa skill do not even receive the full sentence (as voice-to-text transcript) of the user speech!

Instead, the skill gets just a label (an intent, in “conversational AI” jargon) that the developer has initially planned (during the “Alexa Skill nteraction model” design phase) that matches with the current user sentence. Strange, but this is the way!

Why Alexa do this “censorship”?

As far as I know, it has never been officially explained by Amazon, but I do believe it was a deliberate strategic decision. My suggestion is that the Alexa “interaction model” mitigates possible malicious uses/abuses by third party skills, giving Amazon an automatable way to control 3rd Party apps, avoiding privacy issues, etc. That’s a possible “customer first” right dogma.

On the other hand, the intent-based interaction inhibit third party skills to elaborate the user full utterance, limiting the NLU (natural language understanding).

Twitter https://twitter.com/solyarisoftware/status/1190651101621768192?s=20

Google Assistant, with Actions SDK, gives developers more freedom allowing them to use a classic intent-based classifier (the Dialogflow platform) as Alexa does, but Google also gives the option to use an alternative “low level” pass-trough (Actions SDK API), where the user utterances are passed to application, without any filtering. Thanks Google for that!

Why this “pass-through” is so important for an e-learning app or any (language) assistant bot?

Having the complete student text and voice input is paramount to analyse utterances on a human-machine conversation, e.g. a linguistic exercise.

Let’s imagine a simple conversation where an assistant chatbot asks the student to describe a scene displayed on a image or a video. In the example below, the CPIAbot exercise “guess the word” asks the student to guess the word (part of a glossary) describing the people that work in the scene.

Regarding the specific image, the students could answer: sales girls, women, cashiers, shop girls, clerks and many other definitions, that would be interesting to catch and analyze by the bot. This is feasible but pretty hard to implement with the Alexa interaction model.

Devices costs

The other point the original article mentioned are smartspeakers devices end-user costs. The author is absolutely right when she says that an Amazon Alexa Dot is cheaper than a Google Nest Home. The same is for Echobuds (Amazon offers the cheapest earables devices in the market). BTW, earbuds (personal, near-field earbuds) solve the user identification problem previous mentioned.

In a language learning context (and in any discipline), we want students use the (voice bot) application also outside the classroom, and

the “cheapest” and “easiest to own” device for people, especially refugees is a smartphone.

So back to our comparison, again both Google Assistant And Alexa lose in facts, because it’s true that both assistants are available as mobile app, but there are limits on voice/text interactions, by example in case of Amazon Assistant the students can’t text to Alexa. Google Assistant is a bit better, allowing users to write (or speak), but (if I well remember) there is no the way, action application side, to distinguish if user has wrote or has spoken (I could be wrong, I have to double check).

Minor notes about the devices audio quality

Amazon Echo has a jack audio output and Google Nest has not. That’s true. But both the devices could be coupled via bluetooth. Problem solved.

For me, as an “audiophile”, in terms of audio quality, comparing my Google Home Mini with an Amazon Echo Dot (v3), I much prefer the Google’s device because the more natural sound, or vice-versa, I literally dislike the over-compressed audio quality of Amazon Echo devices. Well, that’s subjective and on the other hand, in a classroom, the Echo’s bigger audio is a plus, I admit.

Authoring tools for teachers

Alexa Skills Blueprint? Maybe they are a nice tool for an initial engagement and gaming, but you can’t develop interesting/serious educational applications with them.

The most important point for me, is that both Google and Amazon do not provide so far a real simple convincing tools for non-developer and application developers in education realms, as teachers.

The visual design (GUI) vs language-based (CUI) tools is an old fashioned but highly discussed debate among conversational designers/developers. My side, regarding skill/actions development, and more in general about conversational application design and development, I’m supporter, since few years ago, of not-visual, but high-level authoring tools (possibly using very simple, declarative, ~natural language) programming languages. So far, I do believe that

both Amazon and Google do not provide authoring tools that allow teachers, contents creators and any no-developer, to easily create serious/complex custom applications.

Maybe Amazon is in the right direction with the www.litexa.com approach (I’ll deepen that topic on a future article). On the other hand, I have to say, as developer, that Google Actions programming paradigm is better than the Amazon skills programming proposal. There are many reasons, a bit tech/off topic here, that I often pointed out with my tweets.

Concluding, I confess I’m not too happy about how the two biggest players now support application development (in educational realms). We need much more! :-)

CPIAbot academic papers:

1. F. Ravicchio, G. Robino, G. Trentin.
CPIAbot: un chatbot nell’insegnamento dell’Italiano L2 per stranieri. 2019.
Published in Didamatica 2019 acts, Best Paper Award in section: BYOD. Mobile e Mixed Learning (ISBN 978–88–98091–50–8 https://www.aicanet.it/didamatica2019/atti-2019 p. 77–86).

2. F. Ravicchio, G. Robino, S. Torsani, G. Trentin.
Un assistente conversazionale a supporto dell’apprendimento dell’italiano L2 per migranti: CPIAbot. Nov 2019. 
Submitted to the Italian Journal of Educational Technology (IJET).

Related article: Stateful Alexa Skills?

I’m happy to read your opinion. Please let me know your experience!

In this article I want to deepen a typical problem when developing a not trivial Alexa skill, as a complex task-completion workflow or a well-structured voicefirst game: the need of a state management framework supporting developers to manage multi-turn conversations contexts.

The need of a dialog “state management” is a topic very well explained in the Chas Sweeting’s beautiful article “Lessons learned moving from web to voice development”:

Lessons learned moving from web to voice development.NLU (natural language understanding) isn’t necessarily the main challenge in moving from web to voice development —…hackernoon.com

My article now is a follow-up and it introduces some change request proposals for Alexa Skill Kit team about how to integrate skill state management in the Alexa Developer Portal.

The Chas article shows the problems faced in building an Alexa Skill with the goal to collect some info (getting the weight of a person and others user data). In general the author perfectly hits the spot when he says:

Bottom-line, if you’re developing for Alexa, it’s totally up to you to manage all context and the routing which comes with it.

Enter the state management!

…this also represents how conversational engines like Dialogflow work: by mapping utterances to intents whilst considering input contexts (ie. incoming states) based on the data already known.

I like the graphical diagrams that the author used to proof the concept, blending visualization of internal states with the corresponding utterances/prompts flow. See his beautiful example:

Such state machine represents a conversation unit (in my parlance) and shows at the same time user interface and logic: Internal conversational states graph (contexts, in the Dialogflow parlance), Utterances & Prompts (answers to user), Logic Functions (fulfillment), Utterance State Transitions (user-triggered), Logic State Transitions (an initial state calls a final state).

Love it! 
The concept I want to deepen now is that:

A complex conversational workflow can be designed as a graph of inner states transitions, where each state represents a dialog step and each unit is as stand-alone state machine.

By example, see the diagram here below, again from Chas’s article, where a conversation workflow is made by two state machines (two dialog units) to get weight and age data from user. On the diagram you can see the getWeight dialog unit (on the left), connected to the getAge unit (on the right):

Please note that each dialog unit is composed by multiple states. By example the getWeight unit contains four different states: LOG _EIGHT, RECEIVED QNTY_NEED_UNITS, ASK_TO_CONFIRM.

Sounds a cool design! But how is all that related to Alexa skill practical coding?🤔

Be patient and please let me recap in broad terms what is so far the skill programming process with the Alexa developer console.

The Alexa Skill Programming Model

Alexa Skill programming is based on two phases: 1. definition of the Interaction Model and upload to Alexa server to build the model. 2 the run-time intents classification and logic fulfillment. Let see them in more detail:

• Phase 1. Design-time. One-off Interaction Model definition.
  Above all, the designer defines all intents and slots; he defines all sentences examples to achieve a short number of labeled intents. The designer can define the Skill Interaction Model through the web Alexa Developer Console, producing at the end a static JSON data structure.

• Instead of using the web portal wizard (also called Alexa Console), an expert Alexa developer can create the Interaction Model editing the JSON file from scratch and uploading the file via the ASK CLI (I usually prefer this approach) to let Alexa machine learning servers to process one-off the intents classification model (to be used afterward in run-time).
• The intents/slots classification learning is an Alexa server cloud one-off batch processing getting in input your JSON Interaction Model and producing some internal model that Alexa server will use in run time to classify user utterances in intents/slots. See below an Interaction Model JSON file chunk:

{
  "interactionModel": {
    "languageModel": {
      "intents": [
        {
          "name": "MyIntent",
          "slots": [
          ...
          ],
          samples: [                                                                                                                                                
            {words},                   
            {words} {voice},                                                                                                                                      
            {voice} {words},                                                                                                                                      
                                                                                                                                                                              
            {intro} {voice} {words},                                                                                                                              
            {intro} {words} {voice}                                                                                                                               
          ]
        },
        ...
      ]
    }
  }
}

• Phase 2. Run-time: Developer Logic Fulfillment 
  Developer have to code all the conversational flow (and the logic behind) with a standard programming language; I’m a javascript developer and from now on I’ll refer to the Alexa Skill Kit SDK for NodeJs.

At run-time, for each user utterance, Alexa cloud server choose the most likely intent and send a Request JSON payload to the skill run-time server (an HTTPS web server or an AWS Lambda function).

{
  "session": {
    ...
  },
  "context": {
    
  "request": {
    "type": "IntentRequest",
    "requestId": "amzn1.echo-api.request...",
    "timestamp": "2019-02-07T09:09:47Z",
    "locale": "it-IT",
    "intent": {
      "name": "MyIntent",
      "confirmationStatus": "NONE",
      "slots": {
        "voice": {
          "name": "voice",
          "confirmationStatus": "NONE"
        },
        "words": {
          "name": "words",
          "value": "la vita è bella",
          ...

The user skill program elaborates the request and reply a response JSON format. Using the NodeJS SDK, the developer has to fulfill handlers objects for each intent to be handled. That means writing two functions for each intent: canHandle() and handle(), as sketched in the pseudo code here below:

const Alexa = require("ask-sdk")
...

//
// intent handlers
//

const MyIntentHandler = { 

 canHandle(input) {
   // specify conditions that trigger an intent handler 
   return input.requestEnvelope.request.type === 'IntentRequest'&& 
   input.requestEnvelope.request.intent.name === 'MyIntentName' 
  },

 handle(input) { 
   // intent handler logic processing    
   ...
   ...
 }
}

Nothing new so far!

The problem I see is that developer has to create for each skill just a flat list of intents (and slots). This list is unaware of any specific application state, as described in previous paragraphs. In other words, we can see the list as the big sum of all the intents involved in all states the skill must handle. That’s confusing and error-prone if the skill become more and more complex.

Finally, I think that it should be a simple state management support in the Alexa Console!

Change Request 1 — Add (session data) proprieties to support state management in the Interaction model

Let’s assign a state name propriety (and a unit name propriety too) to the intents model. In this way the model is no more a flat list of intents, but instead:

the skill is now conceived explicitly as a state machine where each dialog unit is made by a finite number of intents related to that specific dialog unit/state.

How to do that in the Alexa Console Intent page? 
We need to add state and unit attribute for each intent. That’s it! 
The example here below shows how the interaction model would become:

{
  "interactionModel": {
    "languageModel": {
      "intents": [
        {
          "name": "LogWeight",  // dialog intent name
          "state": "LOGWEIGHT", // dialog state name
          "unit": "getweigth",  // dialog unit name

          "slots": [
          ...
          ],
          samples: [                                                                                                                                                
            "I weigh {WeightNumber} kilos",                                                                                                                                                                                                                                                                                                    
            ...                                                                                                                   
          ]
        },
        ...
      ]
    }
  }
}

At run time the skill will receive the new unit/state info in the session data proprieties to be processed like in the example here below:

canHandle(input) {
   // specify conditions that trigger an intent handler 
   return input.requestEnvelope.request.type === 'IntentRequest'&& 
   input.requestEnvelope.request.intent.name === 'LogWeight' &&
   input.requestEnvelope.request.unit.state === 'LOGWEIGHT' &&   
   input.requestEnvelope.request.state.unit === 'getweigth' 
  },

Note: the proposed change request of new proprieties point out just the developer experience (client-side). On the Alexa server backend the CR imply a modified intents machine learning algorithm; in the proposed approach, Alexa server must split the previous flat list of intents in a multiple sub-list of intents (one sub-list per unit/state). All in all the previous task is just splitted in sub-tasks. This also would produce a better classification at run-time, isn’t it?

Change Request 2 — A Skill Boilerplate Code Generator

With a complex Interaction Model (due a complex state machine) it could be difficult for a developer to manage a large number of canHandle() and handle() functions.

So it could be very useful to integrate the Alexa Portal with a wizard tool to generate a template/boilerplate code. I mean something that could extend what Alexa evangelist robmccauley did with the The Alexa Code Generator!

The state-management code generator would be available for all ASK foreseen programming languages: nodejs, python, java, etc. BTW. The code generation could be perfect sub command for ask CLI.

Last but not least, the proposed 1-click code generator could be a web (or CLI) wizard to guide skill developer to start with the state management design phase and it could auto magically generate code to map situations in states, following the situational design approach, see the nice webinar:

Twitter https://twitter.com/solyarisoftware/status/1124341787177439232

Recap

The lack of an Alexa-native state management support is one of big minus when developing an Alexa skill. In the article I suggest how to re-think the Alexa skill programming (and in general any conversational application development) with a state management approach.

I proposed two possible change requests for the Alexa Developer Console in order to support state management and integrate a code generator wizard to speed-up skill coding with an initial skeleton.

Some developers claim with me the lack of an Alexa state management support, as by example the expert Mark Tucker did in the article: Alexa Needs Intent Context in 2019 (he talked specifically about “intent context” lack).

Besides Alexa, conversational context management is a debated and controversial topic among conversational AI researcher. But that’s a long story.

In a future article I’ll show you some third-party solutions (for Alexa) and I’ll present my own simple deterministic stateful dialog manager NaifJS, that I used to develop CPIABot, a telegram bot for language learning:

Twitter https://twitter.com/solyarisoftware/status/1128300142828847105

Stay tuned! 😃

Related articles

• Tips on State Management at Three Different Levels
• Building Conversational Alexa Skills: How to Dynamically Elicit Slots Based on a Previous Answer Using Dialog Management
• How to Use Session Attributes in Your Alexa Skill to Enhance the Voice Experience
• Allow skill to anticipate/disallow specific intents during conversation (see also: Alexa Needs Intent Context in 2019 ).
• Alexa Code Generator
• Create Engaging Alexa Skills Using Situational Design

I’m very happy to read your comments!

7.10.2018 — added a note about X.ai

Recently I started my new job as researcher at ITD-CNR, the Institute of Educational Technology, part of the Italian National Research Council. The goal of research team to which I belong is to realize chatbots/voice assistant applications in order to support Italian language teachers that teach Italian to immigrants (both children and adults). Challenging!

We are mainly focused on voicefirst multimodal conversational apps usingsmartspeakers and smartphones and we are now experimenting the possibilities of Google Assistant (nowadays Actions On Google is the only framework that support Italian language on a smartspeaker). As soon as possible we’ll probably use other voice metabots (Amazon Alexa and Microsoft Cortana).

But I have naming issues.

At CNR the other researchers call me and my colleagues “ chatbottisti”. Ugly term I think, that could be translated from Italian to English as chatbotters. Terrible, isn’t it?

Seriously, in general I dislike the term chatbot to generally refer to a conversational application. Let me explain why here below.

From my point of view, and basing on my knowledge, a chatbot is technically something very specific: it’s a conversational app running through an instant messaging platform, as Facebook Messenger, Telegram Messenger, Whatsapp, Slack, Facebook workplace, etc.

A chatbot get written user utterances and reply text-based sentences (and GUI widgets) through chat messages.

Again, the term chatbot sounds to me wrong for a conversational app conceived for a voice assistant hub as Google Assistant or Amazon Alexa. Maybe voicebot is a better name here? A proper definition could be:

A voicebot is a conversational app conceived to run on a smartspeaker: getting spoken language user sentences and replying spoken language (and sounds).

To be honest I’m not yet satisfied with the above definition. I feel that voicebot is a too partial and temporary way to define by example an Amazon Alexa skill or a Google Assistant Action.

Digression: 
Google, Amazon and Microsoft all implement their assistants in “centralized” web architecture. Google call action an application made by a third party developer that implement any specific functionality “called by” Google Assistant.

Interesting, the name action imply the Google vision of an ecosystem of Assistant apps that fulfill any kind of tasks (following the “get things done” mantra).

Whereas Amazon call skill third party applications that integrate and extend Alexa core features. Is not by chance that Alexa skills inherit the Alexa voice. It’s always Alexa that chat with users, even if the application is made by third parties.

Anyway, for me is clear that an application built for Alexa or Google Assistant is mainly voicefirst (based on a voice as primary media) but also multimodal by design. Both systems let developers to conceive an application to use multiple device media capabilities: beside the voice, for example, the screen and the touch.

In the long term we’ll certainly see the integration of other sources in human-computer interaction: gesture/gaze detection, emotion detection, etc., as Cheryl Platz stated in her beautiful talk at #designmatters17 conference:

Paul Cutsinger, Alexa US Chief Evangelist, has recently introduced the Alexa Presentation Language. Is obvious now that Alexa skills will not be just voice-bots, but “universal” conversational application embracing a vast variety of input and output modes and a vast variety of devices.

An Alexa skill run now on a voice-only smartspeaker (Amazon Echo device), a voice+screen smartspeaker (as the Amazon Echo Show), a smart TV, inside a car with a dedicated device, etc. Amazon call all these things ambient computing.

Google Assistant’s minds follow a very similar path, maybe more focused on the analysis of the day-to-day human user experience cross devices.

If I’m not wrong, Google call ubiquitous computing the Google Assistant experience where a person interact with the Assistant (and the Actions on Google third party apps) with a frictionless cross device experience:

Video slides of my talk at GDG Genova #ioextended

So, can we still name chatbot a cross-surface, multimodal conversational application?

By example let’s imagine a Google Assistant audiobook/popdcast listening experience, started at home in the morning with a Google Home smart speaker, continued later when driving with some in-car smartspeaker and continued in the evening when walking, through a mobile phone.

A Chatbot UX? I don’t think so.

Conversational agents is a better name?

Another misleading term, often used in academic contexts as alias of chatbot, is conversational agent. Maybe referring to any conversational “AI” software that mangle natural language understanding.

I don’t know exactly why there is a lot of dated scientific papers regarding conversational AI (another vague definition), always referring to the term conversational agent. For me it’s totally confusing.

Recently I really enjoyed the karen kaushansky’s recent talk “Design the Future, with Voice”:

Video https://player.vimeo.com/video/288109032?app_id=122963

Especially I like when she says that we’re going from centralized voice assistants (Amazon Alexa, Google Assistant) to inter-connected assistants (by example Amazon Alexa talking with Microsoft Cortana) and afterward toward agentive technologies (she mentions Chris Noessel’s studies) and says:

“the assistant became the agent doing a task for me, acting on my behalf”

The perfect example of a conversational agent, Karen affirms (and I fully agree), is Google Duplex. Now can we name chatbot a Google Duplex agent that soon negotiate (with a phone call) an appointment with the doctor in behalf of ourselves? Chatbot sound again really misplaced.

An interesting case of “singularity”(just about naming) is Dennis R. Mortensen X.ai, an AI assistant that schedule meetings, via e-mail. 
For me this an example of a real conversational agent! Now can we still define chatbot an application that converse though e-mails messages? Yes maybe, in a very broad sense and curiously Mortensen define his creature an “AI assistant”.

Last but not least, similar topics in an interview with IBM Watson CTO Rob High:

Who's talking? Conversational agent vs. chatbot vs. virtual assistantWe've all seen instances where terms like "chatbot," "virtual assistant" and "conversational agent" have been used…searchcio.techtarget.com

Final naming survey

In conclusion, a bit for joke, a bit serious, I please ask you to help me finding a general name for a conversational application. In other terms how you name your application running on a (voice) assistant ecosystem?

• bot
• chatbot
• voicebot
• conversational app
• voice app
• conversational agent
• convo (CONVersational Object)
• other

Thank you for giving me your definition, and for any comment here or on twitter, replying to:

Twitter https://twitter.com/solyarisoftware/status/1048687713845690374

Feedbacks

Twitter https://twitter.com/HandNF/status/1048702684906151936

Twitter https://twitter.com/FlorianHollandt/status/1048692232847597569

Twitter https://twitter.com/rogerkmoore/status/1048854922459058177

Twitter https://twitter.com/BrianRoemmele/status/1048691542578221056

Twitter https://twitter.com/dcoates/status/1048694586401595392

Twitter https://twitter.com/CBF_Studio/status/1049005219001061376

Twitter https://twitter.com/virtualgill/status/1049333096955432961

Twitter https://twitter.com/cpearl42/status/1049342699747205122

Twitter https://twitter.com/PullStringInc/status/1049886534382604288

Twitter https://twitter.com/solyarisoftware/status/1035437623739932674

In my article here below (in Italian, maybe Silvano Luciani could translate for you), I detailed different API approaches (ActionsOnGoogle vs AlexaSkill), to manage audio contents: short length (SSML)/long-running podcast/streaming):

Echo Dot ed Home Mini: Audio confrontoUn’introduzione allo sviluppo di applicazioni audio su Amazon Alexa e Google Assistantconvcomp.it

Last but not least, I’d suggest to populate Actions SDK sample page:

Samples on GitHub | Actions on Google | Google DevelopersThe following table lists our sample Actions projects that use the Actions SDK. You can filter this table by the…developers.google.com

with minimal examples showing how to develop audio-contents based actions, with typical use cases; by example it could be nice to see how to manage an actions that play a musical album (containing many tracks) with long-running audio media responses mentioned in this article!

Thanks again 
giorgio

L’anno scorso, qualche mattacchione mise su youtube un video in cui veniva presentato Amazon Echo Silver, fantomatica versione e parodia del vero prodotto Amazon Echo, specificamente studiato per le persone anziane.

Il video, fatto così bene tecnicamente da sembrare, a prima vista, una vera pubblicità di un nuovo dispositivo Amazon, diventò famoso per una doppia ironia: da un lato venivano attribuite allo smartspeaker impossibili funzionalità di intelligenza (addirittura visiva), ma sopratutto venivano presi in giro disturbi e comportamenti stereotipati delle persone anziane: la sordità, lo storpiare la wake-word Alexa in mille modi diversi, la perdita di memoria, la presunzione del “lo sapevo”, etc. etc.

Tra le scenette della pantomima, la più simpatica è forse la funzionalità “Uh Huh” grazie alla quale Alexa sembra seguire un discorso, rispondendo con l’intercalare non-verbale al racconto sconclusionato di un anziano che narra ad Alexa una qualche vicenda senza capo né coda del passato. Tornerò dopo su questo.

Per i pochi che non lo conoscono, ecco il video:

Video video -parodia di Amazon Silver: https://www.youtube.com/watch?v=YvT_gqs5ETk

Smart-speaker Skill (in Italiano)?

Scherzi a parte, negli ultimi mesi si è parlato con grande attenzione delle possibilità degli smart-speaker nell’ambito health-care, in particolare per l’assistenza alle persone anziane.

Per quanto riguarda la definizione di smart-speaker rimando all’articolo dell’anno scorso, ma ancora valido: Smart speaker: cosa sono, quali sono, come funzionano e quanto costano.

Il mercato degli assistenti vocali e degli smartspeaker è in grande fermento ma le tecnologie contendenti nel 2018 rivelano un duopolio: da un lato Amazon Alexa, con i dispositivi per la famiglia Amazon Echo, dall’altro il competitor “emergente” Google, con gli analoghi dispositivi Google Home, versione vocale della più vasta tecnologia “multimodale” Google Assistant.

Al momento è Google l’unico dei due che ha già commercializzato in Italia i dispositivi in lingua italiana (a partire dal 15 Marzo se non erro),

ma anche Amazon ha appena rilasciato (22 Maggio) una versione di test ad un numero ristretto di utenti di Alexa in lingua italiana. Probabile che il lancio ufficiale avvenga tra qualche mese massimo:

Sia Alexa sia Google Home sono metabot, ovvero assistenti virtuali su cloud connessi a milioni di dispositivi utente e dotati di una “intelligenza artificiale” centralizzata e proprietaria.

Sebbene i metabot assolvano a molteplici compiti di base, come fornire informazioni di vario tipo (previsioni del tempo, news, accesso a wikipedia, ascolto di musica, radio in streaming, audiolibri, etc.), si prevede un grande sviluppo di un ecosistema di applicazioni terze parti (chiamate skill nella terminologia Amazon Alexa, o chiamate action nel mondo Google Assitant), che svolgeranno i compiti più vari.

Gli “skill” degli assistenti virtuali sono l’equivalente delle “app” nel mondo mobile.

Fatta questa introduzione all'ambito tecnologico degli assistenti vocali, torniamo alle applicazioni specifiche per le persone anziane.

Alexa, Telefono — Casa

Una delle funzionalità possibili con gli smartspeaker è l’evoluzione del “telefono di casa” in un telefono attivato da comandi vocali.

Video https://www.amazon.com/b?ie=UTF8&node=16713667011

Alexa rende possibili molte interessanti possibilità di comunicazione telefonica, di video-chiamata e messaggistica:

Drop in: è possibile fare delle chiamate “telefoniche” tipo “interfono” tra diversi dispositivi all'interno della stessa abitazione o tra dispositivi remoti, appartenenti a utenti abilitati. L’esempio classico all'interno della famiglia è quello di comunicare direttamente con un proprio familiare (la persona anziana nel nostro caso) attraverso due dispositivi Amazon Echo, uno presso la camera da letto della persona anziana, e l’altro presso la figlia che abita in altra abitazione. Per chiamarsi basterà dire:

Alexa, passami mamma

Annunci: altra funzionalità di Alexa è quella degli annunci “broadcast” che possono essere ricevuti da tutti i dispositivi all'interno di una abitazione:

Alexa, dì a tutti che sto arrivando a casa. Sarò lì alle 17:30!

Chiamate: è possibile fare chiamate telefoniche o video-chiamate, attraverso sincronizzazione con la rubrica dei contatti sulla Alexa app.

Alexa, chiama papà

Messaggi: è possibile mandare messaggi SMS oppure audio/video messaggi. Per esempio la persona anziana può semplicemente lasciare un messaggio vocale a suo figlia Federica, dicendo:

Alexa, manda messaggio a Federica

e dettando il messaggio, che verrà recapitato a suo figlio via Alexa app o dispositivo Echo di Federica. Altri dettagli qui — vedi anche questo articolo.

Verso i badanti virtuali?

In aggiunta a tutte le funzionalità di interazione vocale già disponibili con i metabot, stanno nascendo parecchie applicazioni terze parti (sopratutto skill per Alexa) per l’assistenza a persone disabili, con problemi di mobilità e la cura remota degli anziani.

Un settore in fermento è sicuramente quello delle applicazioni software ed hardware nella smarthome integrata dagli assistenti vocali, con una grande diffusione di dispositivi “smart” integrabili su Alexa e Google Home. In Italia è molto partecipato il gruppo Facebook Google Home Mini, in cui si parla ad oggi soprattutto di integrazione con dispositivi domotici.

La validità delle interfacce vocali per le persone anziane e con problemi di mobilità è indubbio, si pensi ad esempio al controllo dell’illuminazione, della temperatura e della postura con un letto reclinabile elettricamente con comandi vocali.

Un altro ambito interessante è quello dell’osservazione delle activities of daily living, che danno la misura del livello di indipendenza e quindi del benessere della persona.

La startup TESEO di Genova, fornisce un sistema in grado di imparare abitudini significative e questo consente di discriminare tra situazioni normali, eventi anomali (ad es. cadute e svenimenti) e variazione nel tempo di abitudini connesse alle ADL, specchio di un cambiamento del livello di indipendenza della persona. Il sistema funziona attraverso sensori wearable ed interfaccia vocale con la persona seguita. Vedi video demo:

Video http://www.teseotech.com

E ancora, nell’ambito delle applicazioni robotiche con funzioni di assistenza medica, la startup in parte genovese PilloHealth, che sta rilasciando sul mercato un robot che dispensa pillole, con riconoscimento facciale della persona.

Il dispositivo comprende un’interfaccia vocale e API per Pillo-skill terze parti. Pillo agisce in una certa misura anche come assistente virtuale “general purpose”, alternativo a quelli dei big player dell’assistenza virtuale domestica.

Video https://www.pillohealth.com/

Di applicazioni hardware robotiche per la domotica parleremo sicuramente in successivi articoli in ConvComp, ma torniamo ora al tema dell’assistenza agli anziani, soprattutto alle possibili skill software che si possono realizzare nell’ambito dell’assistenza e dell’entertainment per la terza età.

Marvee, chat di gruppo vocale per l’assistenza all’anziano

Uno skill che merita di essere citato è Marvee, di Heidi Culbertson. Heidi, un’esperta di applicazioni vocali, ha creato uno skill Alexa per sua mamma Marvee, anziana con problemi di mobilità e progressiva cecità.

L’idea di Heidi è quella di avere un sistema di comunicazione remota tra i componenti della famiglia e la mamma che vive da sola.

Attraverso l’applicazione, gli utenti possono per esempio inviare un “Morning Beacon”, ovvero un messaggio di gruppo per fare sapere ai propri cari cosa si sta facendo. Inoltre gli utenti possono, con semplici comandi vocali, inviare messaggi di testo o email con richieste specifiche del tipo “vienimi a trovare”, “chiamami”, etc. Tutti i dettagli qui.

Si potrebbe pensare che in fondo quest’applicazione non sia niente o poco di più dell’equivalente di un gruppo Whatsapp, ma quello che fa la differenza, secondo me, è proprio l’interfaccia vocale come mezzo di interazione, più adatto alla persona anziana rispetto all’iterazione con una app su telefono mobile; perfino meglio di un telefono fisso.

Il piacere del raccontare di sé (anche parlando ad una macchina)?

Torno alla fantomatica funzionalità di pseudo ascolto “uh huh” del video parodia iniziale, perché ci sono implicazioni meno banali di quello che potrebbe sembrare.

Cathy Pearl, esperta senior di applicazioni vocali e conversational designer, ora in Google, ha recentemente scritto il bell’articolo “The Societal Benefits of Smart Speakers”, nel quale accenna tra i vari punti trattati al problema della companionship.

La solitudine è un problema che riguarda tante persone, soprattutto quelle anziane. Molti anziani vivono da soli e possono sentirsi isolati. Idealmente potrebbero essere circondati da amici, dalla famiglia e da persone che si prendono cura di loro andando a visitarli di persona. Ma sfortunatamente questo non avviene sempre.

E’ possibile allora che un giorno una nuova generazione di smartspeaker intelligenti aiuti a risolvere il problema?

Una ricerca di Scientific American di qualche anno fa, ha analizzato le conversazioni delle persone per determinare qual’è l’argomento di cui le persone parlano maggiormente. Sorprendentemente, lo studio ha evidenziato che le persone parlano perlopiù di se stesse! La ricerca ha dimostrato cioè che:

Le persone hanno piacere quando parlano di loro stesse, anche se nessun altro li sta ascoltando!

Mi viene allora in mente il chatbot, citato alla nausea, ELIZA, sviluppato nel 1966 da Joseph Weizenbaum, che faceva la parodia di un terapeuta Rogersiano, in buona parte rispondendo al paziente con domande ottenute dalla riformulazione delle affermazioni del paziente stesso.

Così, per esempio, alla frase:

Mi fa male la testa 

il programma potrebbe ribattere con:

Perché dici che ti fa male la testa?

oppure la risposta a:

Mia madre mi odia

potrebbe essere:

Chi altro nella tua famiglia ti odia?

Un ascoltatore virtuale potrebbe essere realizzato come skill di un assistente vocale, al fine, non dico di fare una analisi psicologica del parlante, ma forse sarebbe già bello avere una applicazione dialogica in grado di reggere una “conversazione di ascolto”, di tutto quello che ha da dire il nostro anziano narratore!

Un sistema di registrazione dei ricordi personali, se volete. 
Un diario dettato a voce.

Infine un sistema di memorizzazione di informazioni personali potrebbe creare un grafo di conoscenza semantica. Da usarsi per condivisione ai propri cari. I posteri forse. Affascinante, no?

Smart speaker nelle case di cura?

Nel 2017 alcuni ricercatori hanno realizzato uno studio pilota su 50 residenti ottuagenari di una casa di riposo vicino a San Diego (USA). L’esperimento fu condotto da Davis Park, direttore del Front Porch Center for Innovation, il quale crede fermamente che la tecnologia vocale possa aiutare le persone anziane nel comfort della propria abitazione, evitando che queste si sentano isolate.

Lo studio fu diviso in due parti: le funzioni base di Alexa, e l’integrazione smart home. Durante una fase iniziale, gli ospiti della casa di riposo si abituarono ad usare Alexa nella quotidianità, per la lettura di audio-libri, le informazioni sull'agenda giornaliera delle cose da fare, il promemoria delle medicine da prendere, l’ascolto delle ultime notizie e la comunicazione con i propri cari.

Dopo sei mesi di sperimentazione, i risultati furono che il 75% dei residenti aveva interagito con Alexa giornalmente, e la stessa percentuale di persone sostenne che l’assistente virtuale li aveva aiutati a sentirsi più connessi con la famiglia e gli amici. La totalità (100%) degli intervistati ha affermato che Alexa ha reso nel complesso la loro vita migliore.

Nella seconda parte dello studio, Alexa è stata integrata con tecnologia smart home al fine di aiutare i residenti a controllare l’ambiente circostante, chiedendo ad Alexa di accendere il riscaldamento, chiudere le luci, o chiamare qualcuno per aiuto.

Eric Topol, medico ed autore di “The Creative Destruction of Medicine: How the Digital Revolution Will Create Better Health Care”, riassume il perché la tecnologia vocale stia cambiando la vita degli anziani in America, nell'articolo New Technologies Help Seniors Age In Place — And Not Feel Alone.

“Le persone vogliono essere autonome, a prescindere dall'età anagrafica.” - Eric Topol

Ecco il documento completo (51 pagine) sullo studio della casa di cura Front Porch: Amazon Alexa Pilot Analysis Report.

Un’altra esperienza interessante, dove Alexa è usata come strumento complementare a degli incontri di musicoterapia in una altra casa di riposo:

Moments of joy: See what happens when a retirement community adopts Amazon's Alexa.Two things bring joy to every day of Len Marten's life: his framed 1944 photo of the woman who was his wife for 72…blog.aboutamazon.com

Ulteriori spunti / Aggiornamenti:

• How Voice-First Technology Can Drastically Change Aging
• New Technologies Help Seniors Age In Place — And Not Feel Alone
• The Octogenarians Who Love Amazon’s Alexa
• Amazon Alexa — Voice-activated model for engagement
• Alexa…Just what the doctor ordered?
• Voice Assistant and Older Adults Lifestyle
• Could Amazon Echo help cut the cost of dementia?
• INTRODUCING LISA BY CUIDA HEALTH
• 9–11–2018: Amazon Alexa in lingua italiana è ora disponibile (data di lancio Italia: 24 Ottobre 2018). I dispositivi smartspeaker che attualmente sono disponibili in lingua italiana sono quindi Google Home ed Amazon Alexa.
• 7–01–2019: articolo di Max Amordeluso: Alexa for the Elderly — How Voice User Interfaces Can Improve the Lives of Older Adults Living Alone
• Alexa for Business, permette la realizzazione di skill intra-aziendali che potrebbero avere applicazioni non solo nelle case di cura ma anche in ambito ospedaliero. Ne parleremo in un successivo approfondimento.
• 10–09–2019: articolo Why Alexa is Perfect for Seniors. I lettori più nerd possono apprezzare la presentazione di Alexa For Business del CTO di Amazon Werner Vogels.
• 7–11–2019: articolo The impact of voice technology on loneliness and isolation
• 23–01–2020: articolo The disconnected become attached to voice

Socialità, indipendenza, dignità

In “The Societal Benefits of Smart Speakers”, articolo già menzionato, Cathy Pearl riflette sull’esperimento fatto con i residenti del Front Poch. Mi piace molto la sua riflessione, di cui riporto qui un estratto in chiusura:

Creators of a home assistant robot were surprised when their first real user, a quadriplegic man, immediately asked the robot to fetch a towel to wipe his mouth. It was certainly not the top capability the creators of the helper robot had designed it for, but sometimes these automated devices give us something we don’t always think enough about: our dignity.

For those with other types of physical disabilities, the Echo can foster independence. A man with cerebral palsy had difficulty regulating his body temperature in the middle of the night. Now, with the Echo, he can adjust the thermostat himself, without having to wake his mom.

Facendo mie le parole di Cathy:

I dispositivi automatici (non solo gli assistenti vocali) potrebbero restituirci una cosa a cui non diamo abbastanza valore: la nostra dignità.

01–11–2018 — Warning: questo articolo compara alcune caratteristiche audio di Google Home mini e Amazon Echo Dot di seconda generazione (vedi fotografia). Dal 30 ottobre 2018 è in vendita in Italia l’Echo Dot di terza generazione, che ha caratteristiche audio completamente rinnovate rispetto al modello di precedente generazione.

24–10-2018 — Update: interessante articolo di comparazione tra Google Home mini e Amazon Echo Dot di terza generazione: Amazon’s new Echo Dot vs. the Google Home Mini: Which sounds better?

Non vi propongo il solito articolo di comparazione all'americana di un Amazon Dot e un Google Home Mini. Su Youtube trovate centinaia di video-confronti sulle feature base e sui vari tricks di domotica.

Qui vorrei invece fare alcune considerazioni sui diversi approcci di Amazon e Google nello sviluppo di applicazioni vocali su smart-speakers. Accenno solo alle caratteristiche hardware/audio dei due dispositivi, spendendo qualche riflessione in più sulle diverse possibilità di sviluppo applicativo con il suono.

Le due aziende che ora detengono il duopolio degli assistenti vocali hanno forse una differente concezione di cosa sarà l’esperienza utente con un’applicazione vocale, anzi, per meglio dire, “sonica”. Ne accennerò.

Sound User Experience

Con questa dizione intendo un’esperienza utente (di un’applicazione conversazionale su smartspeaker) che non sia un’applicazione VUI (Vocal User Interface) derivante dal semplice porting di un’applicazione testuale chatbot o di un odiatissimo risponditore vocale automatico IVR (Interactive Voice Responder).

No. In una UX sonica i contenuti verbali (“voce” come trasposizione di una informazione testuale) sono arricchiti da informazioni di suono di svariato tipo: la voce umana nei suoni non verbali, la musica, soundtracks, i rumori di ambiente, le earcon (icone audio), jingle, audio-clips, podcasts, registrazioni audio e suoni di ogni tipo.

Gli smart-speaker hi-fi permettono esperienze soniche immersive, oltre il concetto archetipico di interfacce vocali.

Audio-confrontiamo i dispositivi hardware

Ma ripartiamo da un hardware-confronto tra i due piccoli smartspeaker “combo”.

Google Home Mini
Sul dispositivo ho già scritto in mio precedente articolo: L’umorismo del sasso parlante di Google. La qualità audio del “sasso parlante” è a mio avviso più che eccellente.

Potenza sonora abbondante e completamente soddisfacente in una stanza di dimensioni standard. Ma quello che mi piace particolarmente è l’equilibrio di equalizzazione in frequenza, con bassi generosi, insomma definirei Google Home Mini un oggetto di ascolto Hi-Fi!

Lo uso per esempio per ascoltare musica in camera da letto:

Hei Google, suona la playlist spotify: Jazz for Sleep 

Quella della “ninna nanna musicale” in audio-diffusione, è un’esperienza che non conoscevo prima, e devo dire che è molto piacevole! 
E se si desidera una potenza di suono maggiore, è possibile bluetooth-accoppiare il sasso con bluetooth speaker esterno.

Amazon Echo Dot
A confronto con il Mini, Il Dot risulta perdente rispetto alle capacità audio, sia in termini di potenza sonora, sia in termini di equalizzazione audio, di “pasta del suono”. L’esperienza qui è paragonabile a quella dell’ascolto di una radiolina da tavolo.

Per contro è disponibile un mini-jack audio (stereo) per cui è possibile ridirigere l’audio via cavo su delle casse amplificate. Ottima opzione oltre a quella via bluetooth.

Video https://www.youtube.com/watch?v=TW37zykX-Oo

Evito qui un confronto sulla “pasta” della voce sintetica (in lingua italiana) di default di Alexa e Google Assistant, perché il Google Home Mini, acquistato su Google Store, è quello in lingua italiana, mentre L’Amazon Echo Dot , regalatomi da Amazon, è configurato sulla lingua Inglese. Non è possibile quindi fare un confronto alla pari. Per impressioni sul tono di voce di Google Home, ho già scritto qui e Giuditta Del Buono ha scritto qui.

Come possiamo indovinare facilmente dalle comunicazioni ufficiali e voci di corridoio, Amazon Alexa verrà probabilmente rilasciato in lingua italiana, tra non molti mesi. Questa è la mia personale previsione e non c’è una specifica comunicazione ufficiale da parte di Amazon, ma … credetemi!

Smartspeaker non é solo Voice User Interface

Uno dei probabili successi delle applicazioni vocali per smartspeaker è relativo alle possibilità soniche a completamento di un’interfaccia bot vocale (speech-to-text e text-to-speech).

Un settore innovativo è quello delle applicazioni soniche che integrano software vocali dialoganti con contenuti audio pre-registrati.

Ma proviamo subito ad elencare qualche tipologia di nuove applicazioni possibili con gli smartspeaker.

Giochi ed intrattenimento

Certamente un settore in rapidissima espansione sugli Alexa skills è quello dell‘entertainment, in particolare i giochi sociali, per i bambini e la famiglia.

Ci sono esempi di giochi per bambini davvero fantastici come Kids Court, di Adva Levin. In questo gioco i bambini sottopongono un “reato” ad un giudice virtuale che ascoltati i pareri del bimbo accusato ed il suo accusatore, assolve o condanna, infliggendo pene giocose ed insegnando alcuni principi legislativi ai bambini.

Giustamente Kids Court ha guadagnato il primo premio della Amazon’s kids competition!

Non è quindi un caso che Amazon abbia lanciato parecchie iniziative nell’ambito dell’intrattenimento per bambini, come Echo Dot Kids Edition e l’iniziativa FreeTime Unlimited.

Musica, podcast, news, la radio, l’audio streaming

Attualmente, l’attività più frequente per gli utilizzatori di Amazon Alexa, sembra essere quella dell’ascolto della musica.

Sia in Alexa che Google Home, l’ascolto di un brano musicale specifico è possibile se l’utente ha attivato una sottoscrizione a pagamento con un aggregatore di contenuti terzo come Spotify, TuneIn, e rispettivamente Amazon Music su Alexa e Google Play Music su Google Home.

Quindi se per esempio ho configurato Google Home associandolo al mio account a pagamento su Spotify, posso richiedere la riproduzione di “Amarsi un po” di Lucio Battisti, su Spotify.

Hei Google, riproduci su Spotify “Amarsi un po” di Lucio Battisti

Inoltre sia in Alexa che Google Home, è possibile ascoltare il live streaming di una radio FM, attraverso collegamento a TuneIn.

La cosa che mi ha lasciato perplesso però, è che attraverso la funzionalità di ascolto di musica o radio, attraverso i colossi aggregatori di contenuti (terze parti) sopracitati, non è possibile avere un’esperienza interattiva / conversazionale sui contenuti (musicali) che si stanno ascoltando.

Verso la radio interattiva?

Immaginate questo scenario: mentre sto ascoltando “Amarsi un po” di Lucio Battisti (attraverso una radio via TuneIn, per esempio), vorrei potere interrompere l’ascolto chiedendo per esempio:

Hei Google, in che anno è stato fatto l'album?
 
Ok Google, chi c’è alla batteria?

Ok Google, alle chitarre c’è Ivan Graziani?

No, al momento tutto questo, che io chiamo “radio interattiva” (ne ho parlato in mio talk, a partire da pagina 44 delle slides) non è possibile su Alexa e GoogleHome.

Audio-Skills ed Audio-Actions

Se i metabot non realizzano (ancora) la radio interattiva come funzionalità integrata, è però possibile per gli sviluppatori creare esperienze soniche con uno skill (Alexa) o action (GoogleHome), applicazioni software terze parti.

E’ possibile per esempio realizzare applicazione che riproduca contenuti pre-registrati (audio on-demand ovvero file) e live streaming audio, potendo contemporaneamente gestire delle conversazioni sui contenuti audio in riproduzione in quell’istante. Questo è un nuovo paradigma nella fruizione interattiva di informazioni, contenuti di ogni tipo, ora sì davvero “conversazionale”!

Radio Interattiva? E’ interrompere l’ascolto di un notiziario ins streaming e chiedere ulteriori info ad un “listening assistant” su argomenti/persone citate nel notiziario.

Per realizzare la radio interattiva è necessario poter riprodurre dei file audio, ed anche uno streaming audio. Servono dei metadati associati, un sistema di sincronizzazione e un’intelligenza conversazionale vocale (che io chiamo listening assistant) per la gestione delle queries dell’utente.

La realizzazione di un bot conversazionale che permetta dialoghi sui contenuti dei metadati associati ad uno streaming audio … è fuori dallo scope di questo articolo!

Google si sta muovendo proprio in questa direzione, con una nuova strategia sui podcast, di cui vi parlo nel prossimo paragrafo, ma proviamo prima ad elencare quali sono le armi in possesso ai programmatori che vogliano creare contenuti complessi comprensivi di audio sulle due piattaforme in esame.

Riproduzione di brevi audio clips via SSML

SSML è lo standard usato da Amazon e Google per il controllo della prosodia dello speech sintetico. Ma il linguaggio è anche usato per la riproduzione di brevi contenuti audio (appunto con il tag <audio>).

Nell’esempio qui sotto è visualizzato un messaggio di testo preceduto da un breve earcon, ovvero una clip audio di breve durata:

// This is the initial welcome message
var welcomeMessage = "<audio src=’https://s3.amazonaws.com/ask-soundlibrary/musical/amzn_sfx_trumpet_bugle_03.mp3'/>Welcome to the Easter Bunny Egg Hiding Game. I will ask you multiple questions that you should answer yes or no. Based on your choices, I will make a recommendation on where to hide an egg. Are you ready to begin?";

this.emit(':ask', welcomeMessage, repeatWelcomeMessage);

L’SSML va bene per la riproduzione di segmenti audio brevi.
Nel caso di Alexa c’è infatti una limitazione della lunghezza della clip a 90 secondi, mentre nel caso di Google Home la limitazione è di 120 secondi.

Qui sotto alcuni articoli su SSML, secondo Google ed Amazon.

GoogleHome
Invito alla lettura dei due articolo introduttivi: SSML for Actions on Google e Advanced SSML for Actions on Google di Leon Nicholls e More SSML for Actions on Google! dell’italiano Silvano Luciani.

Il “dialetto” SSML di Google permette alcune feature molto interessanti come il “Sound Layering” di segmenti audio che possono essere in parallelo od in sequenza come nell’esempio della figura qui sotto, dove la traccia Distant Thunder viene eseguita in parallelo (tag: <par>) con la traccia Ringing Ambient Background:

Alexa
Le direttive SSML sono molto simili a quelle Google (in verità un sottoinsieme). Rimando al documento Speech Synthesis Markup Language (SSML) Reference per i dettagli. Vedi anche l’articolo introduttivo:

Amazon has made it easier to add sounds to custom Alexa SkillsI’m recognized as an Amazon Alexa Champion and have published more than twenty custom skills on the platform. I…medium.freecodecamp.org

Librerie di effetti sonori

Entrambe le piattaforme mettono a disposizione librerie di “sound effect” adatti a giochi:

• GoogleHome: Sound Library.
• Alexa: Alexa Skills Kit Sound Library.

Le librerie sopra sono solo la punta di un iceberg di un mercato che potrebbe essere molto promettente: la produzione di clip audio, musica per giochi e l’audio produzione!

Play di file audio e live-streaming

Su Alexa: L’ASK permette una discreta libertà di programmazione con l’audio, attraverso le funzionalità AudioPlayer. Si veda l’articolo introduttivo di Dave Isbitski: New Alexa Skills Kit (ASK) Feature: Audio Streaming in Alexa Skills.

Con l’AudioPlayer è possibile fare il play, in uno skill, sia di file audio MP3, sia di streaming HTTP. Su github sono disponibili due progetti che dimostrano l’uso di Alexa Audio Player per la realizzazione degli skills:

• Il folder Multiple-streams contiene un esempio di skill per riprodurre un insieme di streams audio preregistrati (podcasts).
• Il folder Single-stream contiene un esempio di skill per la riproduzione di un singolo stream, come per esempio una live radio.

Per maggiori info: AudioPlayer interface e PlaybackController interface.

Quello che mi piace dell’approccio Alexa è che vengono gestiti allo stesso modo file audio e lo streaming audio.

Su GoogleHome: Claudio Cherubino (un altro Googler Italiano!) mi fa notare che il play di contenuti audio di lunghezza superiore ai 120 secondi (con l’SSML) è possibile attraverso le Media Responses!

Al momento non mi risulta che sia possibile fare, all’interno di una action,il play di audio streaming su GoogleHome. Cosa invece possibile su Alexa.

Google Search per i contenuti podcast

Google definisce podcast un programma audio consistente in uno o più episodi.

Affinché un podcast appaia nei risultati di una query Google Search, con una descrizione di ogni episodio ed un player embedded, è necessario esporre un feed RSS valido con almeno un episodio, una home page dedicata al podcast, contenente un link al feed RSS. Tutti i dettagli qui.

Google può creare Action automatiche per l’interazione con i contenuti di un podcast publisher, con una corrispondente pagina auto-generata nella directory di Assistant. Dettagli qui.

Interoperabilità tra dispositivi (nello spettro multimodale) ?

E’ ora possibile ascoltare podcasts con Google Assistant. Dicendo:

OK Google, play the Modern Love podcast. 

Questo funziona sia con Google Home che con i dispositivi Android.

Ricerca di informazioni all’interno di un podcast!

Zack Reneau-Wedeen, Google Podcasts Product Manager, afferma che in futuro i podcast metadata permetteranno a singoli episodi podcast di apparire nei risultai di una ricerca con Google search. Un podcast si attiverà non solo quando una persona lo cerca in modo specifico (funzionalità già disponibile su Android), ma anche quando una persona cerca argomenti o persone inclusi nel podcast stesso.

La strategia di Google sul podcasting e l’integrazione con Google Search è spiegata in dettaglio negli articoli:

Inside The New Google Podcasts Strategy

Conclusioni

Il confronto sull'hardware, perlomeno rispetto ai due dispositivi utilizzati vede vincitore Google Home Mini; come speaker, questo “suona” meglio dell’Amazon Echo Dot. Non ce n’è. Con scherzosa equazione “trad” direi che:

Echo (Dot) : PC = Google Home (Mini) : Apple Macintosh

Ma sulle possibilità di sviluppo applicativo, vedo al momento l’approccio Alexa come più aperto, per il fatto che, malgrado alcuni limiti degli strumenti di sviluppo software che Amazon propone (di cui magari parlerò in successivo articolo), le funzionalità dell’Amazon Skill Kit permettono di realizzare applicazioni audio che possono comprendere sia live-streaming audio sia audio on-demand (segmenti audio di lunghezza qualsivoglia), ovvero podcast.

Alexa Skill Kit vince nel supporto alla sperimentazione!

Le primitive di programmazione audio di ASK sono relativamente semplici e danno allo sviluppatore potenzialità creative senza vincolare a paradigmi predeterminati. Questo spiega il recente emergere delle applicazioni vocali nell’ambito dei giochi e dell’intrattenimento.

Tante superfici per una stessa applicazione?

Estendendo il discorso non solo all’audio, dal punto di vista della strategia e della visione di cosa sarà nei prossimi anni un’applicazione conversazionale, ci sono due approcci forse differenti tra Amazon e Google. E non è facile fare previsioni.

La visione di Google mi appare piuttosto chiara dopo aver ascoltato un po’ di talk all’evento #io18 appena concluso. Tale visione è forse riassunta nel diagrammino della slide qui sotto riportata.

Un’applicazione Google Assistant deve funzionare nell’intero “spettro multimodale” dei dispositivi possibili, le “superfici” (così Google chiama la UI su una determinata tipologia di dispositivo):

• Voice only, ovvero su un dispositivo smartspeaker Google Home.
• Voice forward, ovvero quello che Brian Roemmele chiamerebbe voicefirst (sembra che quest’estate Google rilascerà un dispositivo smartspeaker con interfaccia visuale/forse touchscreen, qualcosa di paragonabile ad un Amazon Echo Show).
• Intermodal — immagino che si intenda la app mobile Google Assistant, in cui l’interazione può avvenire con controllo vocale oppure attraverso interfaccia visuale/touch, standard di una app Android.
• Visual only — si intende la app Google Assistant (e le App Actions per qualsiasi altra mobile app compliant al nuovo standard), dove non c’è interfaccia vocale, ma solo quella visuale di una app mobile consueta.

In tutto questo, in relazione alle applicazioni audio, un ruolo importante lo gioca il progetto di Zack Reneau-Wedeen sui podcast, esempio perfetto di ambito applicativo (sonico) cross-superficie.

E Amazon?

Alexa al momento sta puntando tutto sul cosiddetto voicefirst (o voice only in riferimento al diagramma sopra): l’esperienza utente avviene anzitutto attraverso un’interazione vocale, con i dispositivi smartspeaker Amazon Echo ed Echo Dot, che possono, secondariamente, avere un’interfaccia visuale opzionale con i dispositivi Echo Show ed Echo Spot (ed altri che sicuramente ci verranno presto proposti).

Amazon non ha Android, cioè il sistema operativo di Google contenuto nel ~70% dei telefoni mobili della popolazione mondiale. Amazon non ha nemmeno su smartphone una app equivalente a Google Assistant, anche se Alexa sarà presto disponibile come app con un funzionamento analogo a Google Assistant.

Last but not least, a qualche giorno di distanza dal mega evento #io18, c’è stato il non trascurabile evento #MSBuild di Microsoft, dove è stata annunciata tra tante altre news, l’integrazione di Cortana e Alexa.

Questo annuncio è importante perché introduce un settore applicativo nuovo per le applicazioni conversazionali ed audio, cioè quello delle applicazioni interaziendali voicefirst. Un settore importantissimo è quello dell’office automation (si pensi alle funzionalità di Alexa for Business, arricchite dalla integrazione con Office365). Ne parlerò prossimamente.

Video All’evento #MSBuild, Megan Saunders (Microsoft) e Tom Taylor (Amazon) dimostrano integrazione tra Cortana ed Alexa.

Insomma nel Duopolio Google/Amazon, Microsoft si allea con il secondo e la sfida diventa più bilanciata forse. Ne vedremo delle belle! Stay tuned.

Posseggo da una settimana un Google Home Mini (che in casa chiamiamo confidenzialmente “il sasso parlante”), nella versione commercializzata in Italia, ovvero in lingua italiana.

Riporto qui qualche considerazione sulle prime prove di utilizzo, un poco deludenti ma al contempo anche sorprendentemente emozionanti, ammetto, anticipando una temporanea conclusione.

Update 15 Aprile: aggiunto paragrafo su impossibilità di “ascoltare” youtube.
Update 17 Aprile: aggiunta nota su “Media responses” con le actions.

Non so come aiutarti

La percentuale di volte in cui Google Home “non capisce” è davvero molto alta ed i messaggi di errore sono piuttosto prolissi, ecco una lista di frasi tipiche:

Scusami, non ho capito.

Non so come aiutarti, ma ogni giorno imparo qualcosa in più.

Mi dispiace, non so come esserti d’aiuto, ma sto cercando di imparare.

Mi dispiace, non so come aiutarti, ma il mio team mi insegna cose nuove ogni giorno.

Fateci caso: si tratta quasi sempre di frasi che durano non meno di due o tre secondi. Frasi troppo lunghe! E la cosa incomprensibile è che non vengono usati i quattro bellissimi led multicolore e multi-intensità di cui è dotato Google Home Mini:

Invece i 4 led sono usati (a parte il boot) solo e sempre con colore bianco e con una codifica che non è a me di chiara interpretazione, ma se non ho capito male: scorrimento lampeggiante significa “sto elaborando”, mentre 4 led accesi con massima luminosità vogliono dire “ti ascolto, parla”. 
Ho perplessità però su cosa significhino i 4 led che si spengono (senza che venga emesso alcun output vocale tra l’altro); immagino vogliano dire: “non mi stai dicendo nulla”. Non chiaro.

Piccoli miglioramenti auspicati 
Nel caso di un errore del tipo “non ho capito un bel niente” potrebbero essere visualizzati per esempio 4 led in colore rosso. Nel caso di “funzione non disponibile” i led potrebbero lampeggiare in colore giallo e così via.

Di certo l’ascolto di lunghi messaggi di “non capito” innescano in me un po’ di nervosismo quando, rendendomi conto del fallimento, devo ripetere o riformulare la domanda interrompendo l’output con:

Ok Google, … 

Non ho capito

e poi ancora probabile catena di:

Ok Google, blablabla

Non ho capito…

In effetti il followup-mode di Alexa è un passo avanti:

Video demo di Ahmed Bouzid

Ora non ho ancora capito se è il mio dispositivo ad avere un difetto hardware con il microfono, ma rimane il fatto che il natural language understanding appare davvero scarso, perlomeno non sembrano implementate risposte a domande apparentemente semplici e molto prevedibili statisticamente.

E non mi pare sia un problema generale di speech recognition di Google Assistant, perché ho verificato che la omonima app su smartphone riconosce in modo eccellente quasi tutto il mio parlato (tra l’altro mi ha colpito il fatto che lo speech recognition viene effettuato localmente sul telefono).

Mi pare strano non sia stato previsto un banale test del sistema audio che potrebbe essere attivato con il semplice comando:

Ehi Google, mi senti bene?

Ok Google, prova microfono!

Uffa, vogliamo le robe che c’hanno gli anglofoni!

Un’ulteriore frustrazione è data dal fatto che non vengono comprese in lingua italiana richieste che ho visto essere soddisfatte con successo nella versione di lingua inglese. 
Morale: dal punto di vista delle funzionalità, il livello di comprensione di Google Home in lingua Italiana è per il momento davvero basso. Ma sono sicuro che migliorerà progressivamente nei prossimi mesi.

Prosodia e poesia

Una cosa che mi ha colpito subito positivamente è il tono della voce sintetizzata di Google Home in versione italiana, che mi pare eccellente.

Seduzione di una poesia recitata ad arte!

La perfezione della prosodia si evidenzia per esempio nella richiesta di una poesia:

Ok Google, recita una poesia

“Alla Musa” di Ugo Foscolo
 Pur tu copia versavi alma di canto…

In questo caso, io sono rimasto stupefatto dalla qualità della prosodia del testo! Ma… la voce narrante è un raffinato Text-To-Speech o quella di un attore umano? 
Provo ancora:

Ok Google, dimmi una poesia

“Tanto gentile e tanto onesta pare” di Dante Alighieri
tanto gentile e tanto onesta pare la donna mia …

Ok Google, recita un'altra poesia

Incipit dei promessi sposi di Alessandro Manzoni: 
quel ramo del ramo di como che …

Nei casi sopra, la recitazione è esemplare ed i casi sono due: o la recitazione è una registrazione di un attore umano (ma l’impronta vocale sembra proprio quella sintetica dell’Assistant), oppure la qualità del text to speech è davvero formidabile. Ora la mia curiosità è alta: come è stata realizzato un così sofisticato controllo della prosodia? Immagino che ci sia stato un lavoro di codifica ad hoc, ma come? Attraverso il linguaggio SSML? Attraverso il famigerato tacotron2?

Sono davvero confuso e mi ci vuole l’aiutino di Silvano Luciani e James Giangola, a cui chiederò di chiarirci il dilemma! :)

La controprova con un text to speech non elaborato? Ecco qui:

Ok Google, dimmi una poesia

“San Martino” di Giosué Carducci
La nebbia agli irti colli piovigginando sale, …

In questo caso il TTS è terribile. Non c’è pressoché nessun controllo di tono e stress. Nemmeno le pause. Una differenza che cambia tutta l’esperienza!

Giochini per bambini ed ilarità per tutti!

Ma ecco dove Google Assistant riesce a convincere, facendo ridere un po’ tutti in famiglia, specie le bimbe, per esempio con il gioco quiz davvero ben fatto per miscela di suoni, musichette e battute scherzose:

Ok Google, Ti senti fortunato?

Senz’altro mettono di buon umore semplici giochini, raccontini e barzellettario vario di buffo gusto umoristico:

Ok Google, sorprendimi

Ok Google, raccontaci una favola

Ok Google, cantami una canzone!

Ehi Google, lancia due dadi

Ehi Google tira una moneta

Ok Google, sfera magica

Ehi Google, conta da ... uno a.. un milione

Ok Google, sei buffo!

E ci sono sorpese di ironia e doppi sensi simpatici:

Ok Google, vado in bagno!

il bagno è sempre in fondo a destra. Ti aspetto qui!

Ok Google, come la va?

non posso lamentarmi!

Multi-turn, Contesto, Personalizzazione

L’esperienza che attualmente si può avere con Google Assistant in versione italiana è davvero poco “conversazionale”. Sono rarissimi i casi di multi-turn proposti dall’Assistant, in cui c’è una esperienza di dialogo che vada al di là del singola volley (una-domanda-una-risposta).

Ancora, la gestione del contesto è assai rara. Ecco però un esempio in cui c’è un poco di mantenimento del contesto: quando chiedo le informazioni del meteo per la giornata di oggi, mercoledì, con la richiesta:

Ok Google, che tempo fa oggi?

Oggi il tempo a Genova è …

e poi chiedo

Ok Google, e sabato?

Sabato a Genova non pioverà! …

Però manca totalmente una benché minima personalizzazione, che vada al di là delle quattro impostazioni che si possono fare in fase di configurazione via app (nome dell’utente, indirizzo di casa e del lavoro, e poco altro).

E’ vero, c’è una funzionalità di voice match (attivabile solo da app… ed al momento credo possibile per una singola persona in questa versione italiana…) che permette di identificare il propria impronta vocale e dargli un nome per cui dopo se io dico:

Ok Google, ciao!

lui risponde

Ciao, Giorgio!

ma se la stessa frase viene detta da un’altra persona in casa, lui risponde solo:

Ciao!

Ma Assistant sembra non imparare assolutamente nulla dall'interazione di un dialogo esplicito in cui l’utente fa delle affermazioni su di sé. Se non erro non viene capita nemmeno la frase:

Mi chiamo Giorgio Robino

Eppure basterebbe configurare una conversazione del tipo “conosciamoci” in cui l’Assistant possa imparare “qualcosa” su di noi (raccogliere qualche dato su di noi), per avere successivamente l’illusione di una conoscenza di noi stessi… anche solo riutilizzando i dati memorizzati. Quella che negli anni ’90 avremmo chiamato “profilazione”, potrebbe rendere più usabile il nostro assistente. No?

Radio , Musica , Audiolibri

La qualità audio di Google Home mini? HI-FI: potenza di suono ed equalizzazione eccellente!

La buona vecchia Radio FM

L’ascolto di una Radio FM è possibile attraverso la fonte tunein. Ecco l’elenco dellle stazioni disponibili: https://tunein.com/radio/local/ 👍🏽

Ok Google, metti RAI Radio 3 

Ok, Radio RAI 3 da tunein: 🎶🎶🎶

Passare da una stazione radio ad un’altra con un comando vocale mi ha dato un’inattesa soddisfazione istantanea!

Peccato solo che che le uniche conversazioni possibili durante l’ascolto dello streaming audio siano la richiesta del nome della stazione radio. Nient’altro.

E la Radio Interattiva?

Manca un’assistenza all’ascolto di contenuti in streaming (o file registrati) attraverso un bot che fornisca su richiesta, informazioni sui contenuti. Durante l’ascolto di un programma radiofonico sarebbe stupendo potere chiedere informazioni (“metadati”) sul programma stesso, come ad esempio i nomi degli autori del programma, l’argomento del programma, informazioni sugli argomenti trattati, etc. etc. Personalmente sto lavorando in questa direzione, con il concept: Fairy Tales, a storytelling bot.

Musica Google-Maestro!

L’ascolto della musica è possibile attraverso un numero limitato di fonti alternative: al momento Google Play (solo a pagamento) oppure Spotify (che opportunamente configurato permette di di accedere alle free playlist: https://open.spotify.com/ ). Chi ha provato Spotify con account premium pare soddisfatto. Google Home è consapevole delle canzoni che suona:

Ok Google, che canzone è questa?

risponde con titolo e cantante e se si apre l’app Spotify sul telefono si può pilotare la musica di Home e si vedono gli eventuali lyrics disponibili. Anche qui i problemi sono nel far comprendere il comando:

Ok Google, suona "le più popolari" di Lucio Battisti

(sono i brani che Spotify mette in evidenza per ogni artista) ma Google Home non capisce, se gli si chiede però solo:

Ok Google, suona "Si, viaggiare"

allora mette proprio la canzone scelta. Chiedendo “suona l’ultimo di Lucio Battisti” reagisce in maniera diversa, mettendo a volte un album a volte un altro, senza seguire un ordine logico (non cronologico di ultima pubblicazione, non di ultimo album suonato).

Audio Streaming Queue — Nice to have feature
Una cosa che mi piacerebbe è che l’Assistant potesse gestire una coda delle sorgenti di streaming, per esempio mi piacerebbe ascoltare una playlist di musica jazz su Spotify, poi chiedere l’ascolto di Radio 24, poi ancora delle news e quindi chiedere di tornare alla musica (la playlist appena ascoltata). 
Al momento tutto questo non è solo fantasia.

Nessun contenuto audio da Youtube?

Una nota di perplessità anche sul fatto che non è disponibile lo streaming audio di contenuti già disponibili su Youtube! In verità c’è la possibilità di comandare la visualizzazione di video youtube attraverso Chromecast.

Ma non è quello che vorrei! Mi piacerebbe invece poter ascoltare, ripeto: ascoltare, non vedere su uno schermo, tutti i contenuti di youtube attraverso i dispositivi Google Home.

Vorrei ASCOLTARE su Google Home tutti i video Youtube!

Per Google sarebbe davvero un enorme vantaggio competitivo, perché su youtube ci sono contenuti gratuiti di ogni tipo, già validati e controllati.
Prendiamo ad esempio me stesso, sono anche musicista ed ho pubblicato su youtube la mia stessa musica su youtube.

Sarebbe fantastico se potessi dire invocare lo streaming di una traccia del mio album “Wanderer” ( edito da SOLYARIS MUSIC, ovvero Giorgio Robino, il sottoscritto) e pubblicata su youtube anni fa!

Anzi mi piacerebbe ascoltare su Google Home qualsiasi contenuto di youtube! Ma qual’è il problema per cui Google non ha abilitato questa connessione tra Youtube e Google Home? La conversione dei formati video in audio? Non credo. Forse il motivo è quello di favorire/rispettare accordi commerciali con Spotify ed altre “major” o spingere ad usare Google Play a pagamento?

E lo streaming audio nelle Actions?

Attualmente non è possibile realizzare actions, ovvero applicazioni terze parti, che fanno streaming audio. La funzionalità invece è possibile su Amazon Alexa.

Per la precisione è possibile riprodurre “spezzoni” audio via SSML, ma fino ad un massimo di 120 secondi.

Ma va detto che l’implementazione SSML di Google permette funzionalità innovative come la riproduzione “in parallelo” di testo e soundtrack! 
Si veda il bell’articolo di Silvano Luciani: More SSML for Actions on Google!

E’ possibile la gestione dei podcasts, anche se in modo a mio avviso un poco rigido, qui descritto: https://developers.google.com/actions/content-actions/podcasts

Da due mesi a questa parte, Action on Google permette infine di effettuare il play di una traccia audio (file, no streaming) attraverso le Media Responses API.

Come sviluppatore, devo dire però che la gestione semplice ed intuitiva dell’ Alexa Audio Player, di file e streaming audio, mi è parsa molto più easy.

Audio libri

Ahimè. Non pervenuti. Non mi pare sia ora possibile ascoltare degli audio libri. Per certo so che Google Home in lingua inglese permette di ascoltare degli audio-libri. Vedi: https://www.youtube.com/watch?v=eCyucYW2bDQ

Google Play ha attualmente a catalogo degli audio-libri anche in lingua italiana:

Audiobooks — Books on Google PlayRead the latest books including Audiobooks on your phone, tablet, or computer. Millions of books at your fingertips on…play.google.com

Il fatto è che pare non esserci comunque la possibilità di ascolto di audio libri con Google Home in versione Italiana.

Ma dove sono le app (“actions”) italiane?

Le applicazioni terze parti (ovvero le actions realizzate da sviluppatori / aziende esterne a Google), in lingua italiana, si possono contare sulle dita di una mano. Eccole: https://assistant.google.com/explore.

Il fatto che al momento siano così poche non mi sorprende. Il lancio commerciale di Google Home Italia è di poche settimane fa e chi in Italia avrebbe potuto sviluppare e rendere disponibile subito applicazioni vocali interessanti … non si è (ancora) mosso.

La mancanza di una “discoverability” conversazionale è però ancora un elemento di debolezza di Google Assistant. Per esempio io non vorrei avere scoperto che esiste un’applicazione del Corriere Della Sera perché sono andato via web alla pagina ed ho successivamente provato il comando:

Ok Google, Chiedi a Corriere della Sera notizie su Milano

La user experience che invece avrei voluto sarebbe stata quella di arrivare alla action parlando semplicemente con l’Assistant … ma invece se chiedo:

Ok Google, Cosa dicono le notizie?

Vengo rediretto allo streaming audio del fornitore di news nelle impostazioni predefinite via app mobile (per esempio quelle del Corriere Della Sera).

Le news! Ma quanti bugs!

Proviamo con una richiesta scontata (oggi, domenica 15 Aprile alle 9 del mattino):

Ok Google, le ultime notizie!

Vediamo quali sono le ultime notizie. Riprendo a riprodurre da Corriere della Sera, ieri alle 7 e 12 del mattino.

Qui il metabot passa il controllo alla action del Corriere della Sera che inizia con la lettura delle notizie:

Ecco l’editoriale del Corriere della Sera di Sabato 14 Aprile, …

Il malfunzionamento fastidioso è che le “ultime notizie” sono quelle di ieri! Mi aspetterei che un fornitore di news debba fornire informazioni almeno aggiornate almeno quotidianamente! Ovviamente l’aspettativa ottimale è che le informazioni siano fornite in tempo reale.

Una nota positiva sul servizio del Corriere Della Sera però la vorrei spendere: 
alcuni articoli (immagino in forma originale scritta) vengono letti da una voce sintetica con buona qualità della prosodia! Anche qui mi chiedo se si tratti davvero di un Text-To-Speech (la voce sembra generata con un sistema con sintesi concatenativa, dato che si riconoscono inflessioni dialettali italiane “umane”), il risultato è comunque buono.

Il servizio di flash briefing di Amazon Alexa, testato con un Echo Dot, funziona bene invece. E’ questo il modello da imitare.

Conclusioni temporanee

Il giudizio dell’esperienza, a parte tutte le limitazioni ed i bug, è comunque buono per l’emozione positiva della “relazione” che il metabot instaura con noi. Non importa se una volta su tre, al momento, l’Assistant non c’azzecca.

L’importante è che mette tutta la famiglia di buon umore. Ora diamoci da fare noi, sviluppatori e sviluppatrici, a realizzare applicazioni vocali che servano e ci migliorino!

P.S. prossimamente su questi “schermi”, alcune mie considerazioni sui tool di sviluppo Google Actions SDK e confronto con gli Alexa ASK SDK. Stay tuned!

Ringrazio Elisabetta Schiatti e Giuditta Del Buono per lo scambio di impressioni e prove di interazione! 💐🎶💐🎶

Qualche informazione

Sito ufficiale Google Home.
Data di lancio di Google Assistant in lingua Italiana: 1 Novembre 2017.
Data commercializzazione di Google Home in Italia: 23 Marzo2017.
Elenco delle app (actions): Che cosa può fare il tuo assistente.
Google Home Help Forum: productforums.google.com 
Centro di assistenza di Google Home: support.google.com/googlehome
Pagina Facebook: Google Home Italia
Gruppo Facebook: Google Home Mini

Articoli collegati:

“Oggi piove?” — “Senza pioggia non ci saranno arcobaleni”Le prime parole tra noi e Google Home Miniconvcomp.it

Il 2018 è l’anno delle interfacce vocali?Riflessioni sull’articolo di Toni Fontana: Progettazione Chatbot 2018convcomp.it

Dialoghi uomo-macchina che emozionano le orecchie?Il mio talk al XI Summit IA 2017 — Architettura delle Conversazioniconvcomp.it

Perché la Silicon Valley sbaglia riguardo ad Amazon EchoPensate che Amazon sia un’azienda tecnologica? Se sì siete in errore, non lo è.convcomp.it

Tutti casa, famiglia e bot-badanti?L’ambient-computing secondo Amazon e Googleconvcomp.it

Da questo mese avviamo una newsletter mensile

Il blog www.convcomp.it è senz’altro legato al Milano Chatbot Meetup, ed il perché è spiegato qui: http://www.milanoallnews.it/milano-chatbots-meetup/.

Abbiamo per questo motivo creato una sezione del blog dedicata ai meetup di Milano e ad altri eventi in Italia: https://convcomp.it/milano-chatbot-meetup/home

In questa sezione sono collezionati tutti gli articoli pubblicati sul blog con tag #Milanochatbotmeetup.

Qualche news sui prossimi eventi a Milano, fonte la newsletter di Paolo Montrasio/Milano Chatbot Meetup home page:

I video e le slide dei video del meetup di giovedì 22 febbraio sono linkati in questa pagina.

Il canale You Tube è https://www.youtube.com/c/MilanoChatbots 
Se non siete iscritti fatelo adesso così sarete avvisati del caricamento dei video prima ancora che vi arrivino queste mail tramite Meetup.

E’ attivo inoltre un gruppo Telegram: https://t.me/milanochatbots

Ci sono molti eventi in programma nei prossimi 10 giorni:

1. Chatbot con Node-RED e RedBot, giovedì 15 marzo

dettagli: https://www.eventbrite.it/e/biglietti-milano-js-chatbot-con-node-red-e-redbot-43847094841

2. Evento Milano Digital Week, venerdì 16 marzo

Iscrivetevi ai due talk separatamente con i link che seguono. Il programma è:

• Privacy: come il GDPR influirà su innovazione e digitalizzazione (iscrizione), di Alessandro Basile. Utile a sviluppatori e a clienti, non solo per i chatbot. Alle ore 19 nella solita location di via Venini 42.
• Appuntamento con il bot — Semplifichiamo la nuova ospitalità (iscrizione), di Giorgio Sidari. Alle ore 19 nella solita location di via Venini 42.

3. Milano Chatbot Meetup, giovedì 22 marzo — Bot impossibili

Alle ore 19 nella solita location di via Venini 42. Il programma è (Iscrivetevi qui):

• I bot di WhatsApp di Michel Morelli. Sappiamo tutti che non si possono scrivere bot per WhatsApp. E invece no, il modo c’è. Vedremo qual è l’infrastruttura necessaria ed una dimostrazione dal vivo.
• CoT — Chatbots of Things, di Michele Feliciani. Ci presenterà i chatbots al servizio dell’Internet of Things, ossia come unire due nuove tecnologie in rampa di lancio nei prossimi anni.

Informazioni, Idee, richieste, etc.

Fino ad ora il blog ha avuto un taglio sia tecnico sia business sulle applicazioni finali. A fianco della sezione dedicata alle news sugli eventi, prevediamo di creare nuove sezioni specifiche su tecnologia, mercato, ma anche settori di carattere “umanistico” come la linguistica e la psicologia. Cosa ne pensate? Ogni suggerimento è benvenuto.

Per informazioni sul blog convcomp.it, consigli/desiderata/etc. e soprattutto per pubblicare i vostri articoli, potete contattare la redazione all’e-mail: info@convcomp.it. Scriveteci!

https://convcomp.it/chi-siamo-effb1849ad32

Il blog, ideato e curato da Giorgio Robino e Giuditta Del Buono, organizzatori dell’evento #convcomp2016 , ha l’obiettivo di approfondire, sul piano tecnologico, sociale e di business, le tematiche correlate ad engine cognitivi ed applicazioni conversazionali multimodali.

La volontà è quella di stimolare attraverso il blog il confronto tra esperti ed appassionati provenienti da diversi settori e attivi sia nell’ambito della ricerca sia in quello dell’impresa, allo scopo di porre l’accento sulla necessità di un approccio multidimensionale nell’ambito della progettazione delle applicazioni conversazionali.

Giorgio Robino, ingegnere del software, si interessa dal 2015 di applicazioni conversazionali, seguendo costantemente l’evoluzione globale sia delle tecnologie sia del mercato. Attualmente svolge attività di ricerca presso il CNR — Istituto per le Tecnologie Didattiche, dove sta collaborando alla realizzazione di un progetto finalizzato all’impiego delle applicazioni conversazionali per l’insegnamento della lingua italiana agli stranieri. Twitta quotidianamente su queste tematiche, con particolare attenzione alle applicazioni vocali, dal suo account solyarisoftware.

Giuditta Del Buono, ingegnere, ha esperienza nelle aree del trasferimento tecnologico, del supporto alle start-up e dell’open innovation. Attualmente lavora presso Netalia, cloud provider italiano. Mette in ConvComp la curiosità verso lo sviluppo di nuove forme di interazione tra uomo e macchina e la passione per la creazione di nuove collaborazioni che coinvolgano ricerca, impresa e in generale soggetti eterogenei sotto il profilo settoriale e dimensionale.

Editors e writers: https://convcomp.it/about
E-mail: giorgio.robino@gmail.com

Vuoi ricevere aggiornamenti su nuovi articoli ?

Vuoi ricevere aggiornamenti su nuovi articoli ?Clicca il bottone “Follow” nel menu in alto a destra, a fianco di “ConvComp”!convcomp.it

Apprezzo sempre gli articoli di Toni Fontana sul suo blog Architettura dell’Informazione Sonora, ed invito il lettore a leggere il recente articolo:

Progettazione Chatbot 2018 -La progettazione chatbot 2018 è al centro della discussione di progettisti che sono impegnati nella costruzione di…www.tonifontana.it

Quoto qui qualche passaggio e mi permetto qualche riflessione e domanda. Propongo infine un mio punto di vista su come stanno andando le cose nel mondo delle interfacce conversazionali (vocali).

La progettazione chatbot 2018 è al centro della discussione di progettisti che sono impegnati nella costruzione di Vocal User Interface. Il tema è talmente nuovo, che al momento possiamo solo parlare di sperimentazione

Probabilmente in questo passo è stato usato il termine chatbot intendendo in generale un’applicazione conversazionale. Va benissimo! Ultimamente si tende a distinguere i chatbot (applicazioni conversazionali la cui user interface è lo scambio di testi, tipicamente in applicazioni di messaggistica istantanea su smartphone) dai voicebot (applicazioni conversazionali la cui interfaccia si attua attraverso la voce); esempi di successo in USA nel 2017 sono i voice assistant di Amazon (Alexa, attraverso i dispositivi smartspeaker della serie Amazon Echo ed app su telefono mobile) e Google (Google Assistant attraverso il dispositivo Google Home).

Amazon Echo (il primo “smartspeaker” di grande successo commerciale) fu lanciato a fine 2014; sono passati più di 3 anni e se non erro Amazon Echo Dot è stato l’oggetto più venduto in assoluto da parte di Amazon durante le vacanze di Natale 2017. Google Home è stato lanciato nel novembre 2016.

A mio avviso siamo quindi ormai fuori da una fase sperimentale, sebbene in Italia i sistemi vocali siano ancora oscuri a molti. Uno dei motivi per cui in Italia le interfacce vocali ed i voice assistants sono ancora misconosciuti, è il fatto che Amazon Alexa non parla ancora la lingua italiana (Google Assistant si, ma solo da dicembre 2017). Sopratutto, sia i dispositivi Amazon che quelli Google non sono ancora in vendita in Italia.

Nonostante questo (temporaneo) stallo, a mio avviso:

Nel 2018 gli assistenti vocali ad interfaccia vocale avranno grande diffusione!

sebbene già di chatbot sulla rete ce ne siano a migliaia. Più o meno funzionanti; più o meno progettati.

Colgo l’ironia. E’ senz’altro vero che la prima ondata di chatbot (diffusi nelle piattaforme di messaggistica istantanea) sono (stati) di imbarazzante mancanza di intelligenza conversazionale (malgrado la dicitura “AI” spesso sbandierata da molte aziende).

Fatto sta che quello che possiamo dire oggi, potrebbe essere smentito già la prossima settimana. Per cui se già avevamo dei dubbi sulle predizioni sull’user experience 2018. Figurarsi sul tema chatbot.

Invero io sono certo che il trend è quello di una sempre maggiore diffusione dei sistemi conversazioni ad interfaccia vocale (voicebot).

I dati di vendita degli smartspeakers in USA sono impressionanti e non lasciano più dubbi, neanche ai più scettici. Riporto qui due analisi di mercato (2017) significative:

Smart Speakers Sales Grow 300% in 2017, 24 Million Globally Says Strategy Analytics - VoicebotStrategy Analytics has a new report out that forecasting that 24 million smart speakers will be shipped globally in…www.voicebot.ai

Amazon Alexa Smart Speaker Market Share Dips Below 70% In U.S., Google Rises to 25% - VoicebotA new study from Edison Research and NPR reports that Amazon Echo maintains almost a three-to-one consumer market share…www.voicebot.ai

Se parliamo dell’Italia, verosimilmente qui tutto partirà quando Google Assistant ed Amazon Alexa saranno localizzati in lingua italiana ed i dispositivi Google Home e Amazon Echo (e parenti multimodali come Amazon Echo Show) saranno in vendita nel nostro paese. Un azzardo di previsione di data? Dalla seconda metà del 2018.

In particolar modo il mondo del marketing sta spingendo per la realizzazione di queste interfacce. L’attenzione delle persone è sempre più bassa, il rumore di sottofondo sempre più alto. Molte domande degli utenti sono basiche e ripetute. Per questo motivo le interfacce conversazionali possono essere la soluzione. Risposte semplici e ripetute all’infinito per lasciare spazio ad operatori umani specializzati. Risultato è la costruzione di una esperienza iper personalizzata per il cliente.I vincitori di questa battaglia? Le interfacce ibride.

INTERFACCE IBRIDE, nel senso di human-in-the-loop ?

Mi pare di capire che tu intenda, nell’esempio sopra riportato, quello che in gergo si chiama “humans in the loop”; è classico il caso dell’automazione del customer care: il chatbot agisce come un helpdesk di primo livello, risolvendo problemi generali e redirezionando la conversazione ad un operatore umano, quando il sistema automatico “non capisce”. 
Sebbene questo approccio possa funzionare bene e sia perfetto in molti casi, ricordo che il più famoso di questi sistemi, “M” di Facebook, è stata una delle epic failure del 2017, vedi:

Facebook cancella M, l'assistente virtuale di MessengerDopo un paio d'anni senza successo, il social network rinuncia al suo chatbotwww.lastampa.it

Facebook is shutting down M, its personal assistant service that combined humans and AIFacebook M, the text-based virtual assistant that used human workers to train an artificial intelligence system, is…www.theverge.com

INTERFACCE IBRIDE, nel senso di multimodali ?

D’altro canto nel link https://www.tonifontana.it/interfacce-ibride/ dici:

Le interfacce ibride saranno il futuro, cioè avranno componenti visive, di messaggistica e altre ancora vocali.

Sì! A riguardo dei sistemi di interfaccia utente, negli ultimi tempi si usa il termine “multimodale” per quello che tu chiami “ibrido”. Perlomeno questa è la dicitura usata da Google ed Amazon (sempre loro) per indicare interfacce prevalentemente vocali (“voicefirst”) che possono essere estese con interfacce di output visuali (vedi Amazon Echo Show), ed interfacce di input gesturali o basate su computer vision (il virtual assistant effettua un’analisi dello sguardo dell’umano e di una intera scena, attraverso telecamera, come nel prodotto sperimentale Amazon Echo Look).

Per certo la tecnologia della speech recognition sta affrontando il problema della emotional detection (analisi dell’emozione contenuta in una frase detta da un umano, del significato del tono (delle informazioni non verbali), dei suoni di sottofondo. E per certo nei prossimi mesi vedremo un progresso nella tecnologia del text to speech con generazione di voci sintetiche indistinguibili dalle voci umane:

Audio samples from "Natural TTS Synthesis by Conditioning WaveNet on Mel Spectrogram Predictions"Abstract: This paper describes Tacotron 2, a neural network architecture for speech synthesis directly from text. The…google.github.io

Ancora, potremmo definire “ibrida” anche la user experience di progettazione CAD (Computer Aided Design), dove l’interazione con un oggetto “grafico” è realizzata con comandi vocali invece che con linguaggi di comandi scritti. Ecco un esempio:

Microsoft researchers build a bot that draws what you tell it to - The AI BlogIf you're handed a note that asks you to draw a picture of a bird with a yellow body, black wings and a short beak…blogs.microsoft.com

INTERFACCE IBRIDE, nel senso di “radio interattive” ?

Last but non least, nell’ambito delle applicazioni conversazionali vocali, io uso il termine “ibrido” per indicare un’applicazione che integra podcast (contenuti audio preregistrati, realizzati da attori umani, per esempio un radio drama o della musica…) con contenuti forniti su richiesta dell’utente da un voicebot, che funziona come un “listening assistant” di contenuti preregistrati. Per fare un esempio concreto: nel mio ultimo talk al summit italiano di architettura dell’informazione, ho presentato il concept del progetto “Fairy Tales”, un’applicazione ibrida dove un voicebot fa da assistente all’ascolto di favole della buonanotte per bambini, preregistrate da attori (“doppiatori”) umani; l’ascoltatore può interrompere l’ascolto della favola di Cappuccetto Rosso chiedendo informazioni sui personaggi, sulla storia, sui suoni ascoltati, riprendere l’ascolto, etc.

Vedi anche mio vecchio commento:

Hybrid convo voice applications?Hi Leor,medium.com

Per citare un caso più autorevole del mio proof-of-concept, la BBC (la società concessionaria in esclusiva del servizio pubblico radiotelevisivo nel Regno Unito) si sta muovendo in questa direzione:

BBC releases its first Alexa-powered interactive audio dramaThe BBC has a rich history in radio, after having been founded as a wireless broadcaster back in the 1920s. But now…www.techradar.com

Perché tanto ottimismo? Perché aziende come Amazon e Google stanno spingendo nella ricerca. Il loro obiettivo non è salvare il mondo, ma portare avanti e vendere Smart Speakers in tutto il mondo.[…] Google, dal canto suo, vende Google Home che si interfaccia e comunica con tutti i dispositivi Android come smartphone, Androidwear, Smart TV, altoparlanti intelligenti, e tanto altro ancora.

La strategia? Il dominio del mondo!

La mia opinione è che questi giganti non vogliano semplicemente “vendere” smartspeakers; quello che vogliono è convogliare tutto l’accesso all’informazione, ad internet, attraverso i dispositivi ad interfaccia vocale. Mesi fa definii “cavalli di troia ”gli smarspeakers (in particolare mi riferivo al prodotto sperimentale Amazon Echo Connect):

Video https://www.youtube.com/watch?v=mhVZvLybavs

About Amazon Echo ConnectHi Brian! Forwarding your article, today I wrote tweet:medium.com

permettendo alle aziende produttrici di entrare nelle nostre case con dispositivi che sostituiranno non solo il telefono fisso (questa è cosa facile da indovinare), ma le modalità di accesso ad Internet. 
Ipotizzo che tali dispositivi in questione verranno presto “regalati” e ci verrà chiesto di pagare un canone mensile per accedere ad Internet ed ai “servizi” forniti dagli assistenti vocali; credo che gli operatori Telco avranno nuovi concorrenti: Google, Amazon, ed altri colossi quali Samsung.

Twitter https://twitter.com/solyarisoftware/status/955800290904756224

Blockchain e Chatbot
Questa premessa è stata necessaria perché per coloro che stanno investendo nella creazioni di queste reti, la blockchain è il nuovo internet. E chi sviluppa chatbot ha iniziato a sperimentare con la nuova internet. […] Insomma entrano nel mercato delle criptovalute per rafforzare la loro posizione.

Su questo sono un poco scettico. E’ vero che la possibilità di avere un registro distribuito di transazioni può essere molto interessante nel caso di chatbot intercomunicanti, ma all'orizzonte non vedo traccia di una tecnologia di collloqui tra bot distribuiti; siamo ahimè nell’epoca dei metabot server-centrici (AmazonAlexa/GoogleAssitant).

Conclusioni
Questa è semplicemente una fotografia di quello che è accaduto nel solo mese di dicembre 2017. E sapere cosa accadrà nel mese di febbraio 2018 è pura fantasia.[…] Difficile che sia una bolla. Nel senso che è difficile che prodotti come gli smart speaker scompaiano dal nostro quotidiano.

Forse per quanto riguarda lo sviluppo, l’assistenza vocale o i migliori chatbot saranno appannaggio delle Big Company. Forse la tecnologia dell’intelligenza artificiale resterà nel tempo sempre molto costosa e inarrivabile per la grande massa degli sviluppatori. Ma è certo che nei prossimi 5 anni avremo familiarità con assistenti vocali e chatbot.

Per questo motivo sviluppatori e progettisti si dovrebbero alleare nella progettazione di chatbot, per risolvere i problemi fin qui incontrati e portare alla grande massa le interfacce vocali.

Progettazione, questa sconosciuta (attività umana)

Questo ultimo punto è molto importante e credo sia un elemento di criticità per una possibile rivalsa innovativa del “sistema Italia”.

Nel 2017 abbiamo visto avanzare un’offerta tecnologica “proprietaria” proposta dalle startup, il che va benissimo, ma quello che io sento assolutamente mancare in Italia è la formazione scientifica, accademica (e di sistema industriale infine) nell’ambito delle applicazioni conversazionali “intelligenti”, ovvero di quello che Amazon ed altri chiamano “Conversational AI”.

L’Università italiana deve velocemente iniziare a fare formazione di alto livello sul Conversational AI!

Malgrado il tanto parlare attorno al “machine learning” io credo che non ci sia un’adeguata ricerca (del pubblico e del privato) su tecnologie che io credo debbano essere aperte (“Open AI”). 
Ma ritengo i grandi player “colpevoli” (si fa per dire) di chiusura, mi riferisco sopratutto i leader tecnologici Google, Amazon, Apple, IBM, Microsoft. Con modesti investimenti e progetti collaborativi questa aziende potrebbero sponsorizzare l’evoluzione e la diffusione di “linguaggi di programmazione” adatti alla progettazione conversazionale (è un discorso un po’ tecnico di cui continuerò a parlare nei prossimi mesi). Un’opportunità del “not be evil” tutt’ora mancata con la Open AI, tanto declamata (a parole).

Timide previsioni per il 2018

Distinguerei due ambiti differenti: quello dei chatbots, ovvero applicazioni “text-first” che girano sui telefoni mobili (applicazioni di messagistica istantanea), e quello dei voicebot (bot con interfaccia vocale).

1) CHATBOT

• Facebook Whatsapp: In Italia abbiamo un problema: l’applicazione di messaggistica che usa la maggior parte degli Italiani è Whatsapp: una piattaforma su cui non è possibile sviluppare chatbot. Nemmeno nella appena uscita Whatsapp for Business è possibile (che io sappia). No mercato (consumer). Fine dei giochi.
• Facebook Messenger è la piattaforma su cui sono stati lanciati molti chatbot business, vero. Ma Messenger non è una app che usa la gente. E nemmeno ha aiutato finora la strategia tecnologica di Facebook, più orientata al modello di micro app alla WeChat che al paradigma conversazionale “puro”. Ma i giochi potrebbero cambiare se è vero che Facebook sta progettando uno smartspeaker hardware!
• Stesso discorso per Telegram: stupenda piattaforma amata dagli sviluppatori, ma a mio modesto avviso Pavel Durov sembra non avere colto l’importanza della voce. Si sta occupando di una sua possibile moneta elettronica, un po’ come Kik. Sono perplesso. Vedremo.

2) VOICEBOT

Non solo gli assistenti vocali (di cui gli smartspeaker sono solo “terminali”), ma in generale

tutte le interfacce vocali/conversazionali sono un trend in continua crescita esponenziale.

Non ho dubbi sul fatto che ci sarà una diffusione sempre maggiore per esempio nell’ambio IoT ed automotive oltre che in quello della smarthome.

Vedremo nel 2018 nuovi settori applicativi: l’utilizzo di sistemi vocali in ambito aziendale. Esempi? L’office automation, il settore alberghiero, per citare due ambiti già di per sé enormi. Anche qui, è Amazon a guidare i giochi.

Ma quello che a me non è chiaro è se Amazon continuerà ad essere leader (in una posizione di quasi monopolio), o se nuovi player al momento dormienti (penso a Samsung, per esempio) proporranno alternative competitive. 
Google è in una fase, secondo me, di rincorsa silente ad Amazon. Una situazione di stallo che spero Google presto superi (ma qui entriamo nel campo della fantaeconomia).

In Italia, la mia previsione è che non succederà niente di rivelante nei prossimi mesi, almeno fino a quando Google non deciderà di mettere in vendita in Italia Google Home (e derivati multimodali) parlante in italiano. E direi che si, l’Italia potrebbe fare da Google-cavia nel Sud Europa; credo che Google scoprirà presto le carte della superiorità “linguistica”.

P.S. Applicazioni vocali non significa solo assistenti virtuali intelligenti e generalisti, ma anche dialogo con oggetti qualsivoglia. Una dritta? sentiremo presto parlare di Samsung.

Invito il lettore a rispondere nei commenti! Vorrei davvero che convcomp.it fosse uno spazio di condivisione e scambio!

Il 24–25 Novembre 2017 a Bologna si è tenuto l’undicesimo Summit italiano di architettura dell’informazione , a cui ho avuto piacere di partecipare con il talk dal titolo:

L’informazione è nella sceneggiatura? 
Progettazione di dialoghi uomo-macchina.

Nella preparazione del focus del talk, il mio intento inizialmente era quello di esporre alcuni design pattern conversazionali e la loro implementazione in linguaggio ChatScript, ma alla fine, supponendo che il pubblico in gran parte non fosse composto da addetti ai lavori (rispetto la progettazione conversazionale uomo-macchina) ho optato per una trattazione più ampia su tre sezioni:

Ho parlato dello stato dell’arte dei chatbots ed i voicebots, accennando ai metabots che oggi paiono dominare la scena degli assistenti vocali: Google Assistant ed Amazon Alexa.

Ho poi accennato agli strumenti di sviluppo tipici, dall'hard-coding, all'utilizzo dei linguaggi di scripting, introducendo per sommi capi il più longevo di questi ultimi: ChatScript.

Infine, non potevo non fare un piccolo approfondimento sulle nuove possibilità delle Voice User Interfaces; i problemi progettuali sono molto più ampi rispetto ai dialoghi testuali. Progettare sistemi conversazionali vocali significa infatti abbracciare nuove dimensioni: per esempio, quelle soniche relative alla produzione di voci sintetiche “human-like”.

Sebbene i sistemi di speech recognition (ASR) e text to speech (TTS) siano in continua evoluzione e incredibile miglioramento, uno dei problemi che attualmente hanno un po tutti i bot parlanti è la monotonia emozionale della voce (sintetica). Per esempio Alexa e Google Assistant permettono un numero ristretto di differenti varianti di impronta vocale. Il tono di voce e la prosodia sono modulabili in modo molto limitato.

Come dare emozione ad un parlato sintetico?

Uno degli strumenti in mano agli sviluppatori è l’SSML, un linguaggio che permette di “taggare” singole parole e frasi, permettendo di instillare un poco di prosodia in un sistema di sintesi vocale. L’SSML permette di introdurre pause e corretta pronuncia di numeri e di termini particolari in lingua straniera. 
L’Expressive SSML è un dialetto SSML proposto da IBM, che permette di definire un’emozione contestuale ad un prompt (una intera frase, recitata dal voicebot). Per esempio è possibile dare ad una frase un tono “buona notizia” oppure di “scuse”:

<express-as type=”GoodNews”> I am pleased to inform you that your mortgage loan application was approved. </express-as>

<express-as type=”Apology”> Is there any way I can make this up to you? </express-as>

Questo è un passo avanti interessante rispetto alle funzionalità di normalizzazione del testo da recitare, ma siamo ancora a livelli elementari di un parlato automatico che ha poca emozione. La mia previsione è quindi quella di una nuova tecnologia che, con una programmazione non procedurale ma dichiarativa,

• in input: permetta agli sviluppatori di catturare il “sentiment”, a partire dal parlato umano, anche dalle sue componenti non-verbali.
• in output: permetta di dare emozione ad una frase che il bot recita, in funzione sia di un’impronta vocale base del bot-persona (ad esempio una brand-voice) e sulla base di un sistema di modulazione “emozionale” funzione del contesto. Come ho schematizzato:

In conclusione del mio talk, ho presentato il mio progetto personale Fairy Tales (inventato con Giuditta Del Buono), dove i bot possono anche trasmettere poca emozione perché questa “è da lasciare” agli umani, in una specie di “radio interattiva” reinventata, che miscela podcasts realizzati da attori umani a bot che funzionano come listener assistants, completando i contenuti pre-registrati.

Fairy Tales nasce dall'idea di un voicebot per l’ascolto di favole della buonanotte per bambini, ma l’idea è valida anche per ambiti differenti, per esempio l’e-learning, le news, etc.

Le mie slides sono disponibili qui: http://bit.ly/iasummit

James Giangola e le massime conversazionali di Paul Grice

Alla conferenza ci sono stati interventi tutti interessanti, e tra tutti ha spiccato quello del linguista nr. 1 di Google James Giangola (Creative Lead, Conversation Design & Persona)!

L’intervento di James è stato incentrato sull'introduzione al principio di cooperazione, un argomento specifico della pragmatica linguistica. La sua relazione è stata densa ma allo stesso tempo semplice, come solo i più grandi sanno fare!
Consiglio la lettura del bell'articolo di Toni Fontana:

Architettura delle conversazioni. Principio di cooperazione di Grice -La scorsa settimana ho accennato al principio di cooperazione di Grice parlando della architettura delle conversazioni…www.tonifontana.it

I video della conferenza:

Video https://www.youtube.com/watch?v=FlLWakqK2xo

Video https://www.youtube.com/watch?v=b1Yd52XfGpo

Last but not list, ringrazio marco tagliavacche per avermi invitato e gli organizzatori e i volontari che hanno contribuito alla realizzazione dell’evento di Architecta: un grandissimo lavoro!

☞ Please tap or click “︎❤” to help to let Giorgio and others know that you appreciated this piece.

Hi Leor,

Absolutely a good point!

A technology that reads the text for tone and can then automatically generate SSML code for the TTS.

yes, the reading software could understand context and “sentiment”. it doesn’t seems a so difficult goal and I foresee next generation TTS APIs will cover the “expression” lack in today tech.

Waiting for this evolution (coming very soon immo), in the meantime a possible way is having what I call “hybrid” (made by humans and by bots) convo apps:

Twitter https://twitter.com/solyarisoftware/status/920624077760614400

Imagine a sort of interactive audiobook, where content is prerecorded (let say a podcast), made by humans (voice actors).

Spoken editions + Soundscapes + metabot voiceover

On top of this podcast, a metabot act as voiceover/listener assistant (completing linear prerecorded narrative with extra metadata info).

What do you think about it?
I’m experimenting such realms…

A bit kidding, I see things in an almost opposite way: it’ Google (Assistant) that is surrounding Amazon (Alexa) but not (just) in the technological space.

Both titans are now pretty “equal” in tech architecture framework and structure of voicefirst platforms offered to third party apps authors; to be fully honest, Amazon Alexa own a small advantage, by example supplying streaming APIs (for long prerecorded audio contents…) right now, whereas Google Assistant still lacks this core feature … but it’s coming soon.

The big diversity I see, is in the space of what Google conversational design team call “conversation” (in broad meaning: cultural, psychological, socio-linguistic, philosophical and not just as set of chatbots design interaction guidelines); it’s a matter of human-centric (design) rethinking of human-machine interactions.

That appears to me as a huge cultural (not just design-related) move (for Google), facing a paradigm-shift from visual to conversational, where “conversation” is collective shared (human) intelligence communication, in respect of multiple traits of humans’ diversity… I’d say with my words:

“Conversation evolves (human) intelligence”

Amazon instead, “simplistically” pursue his usual commercial strategy I call “centralizing into the marketplace”. I feel that Alexa skills fundamental concept is:

“to minimize, for a consumer, the elapsed time between the mental stimulus to purchase something and the instant when stuff is owned”.

Here voice-based conversational appliances (for the family, at home) are just a more convenient UI for consumers. And BTW, now Amazon Echo devices are enhancing even more the e-commerce space to human-to-human telecommunications sectors (voice, video, multimodal); the company just want to bring all humans’ activities in his marketplace. Scary.

About the metabots’ ubiquitous computing challenge, I wrote more thoughts months ago:

Tutti casa, famiglia e bot-badanti?L’ambient-computing secondo Amazon e Googleconvcomp.it

Last but not least I invite you to participate and wrote also for the Italian community blog www.convcomp.it !

Premessa, motivazione, metodo

Domenica 11 giugno andremo a votare il sindaco della nostra Genova.

Non avendo le idee chiare sulle diverse proposte, io e Giuditta Del Buono abbiamo deciso di leggere tutti i programmi dei candidati e di analizzarli relativamente al tema del digitale, riportando qui estratti dei documenti disponibili e inserendo nostre riflessioni personali.

Intendiamo per “digitale” l’impatto sociale, economico e lavorativo delle nuove tecnologie informatiche, in relazione alle competenze umane e ad un auspicabile rinascimento nel e per il nostro territorio.

L’argomento potrebbe apparire secondario rispetto ad altre criticità evidenti a livello locale, ma in realtà lo sviluppo e l’utilizzo di nuove tecnologie sono fattori che condizioneranno fortemente il lavoro del futuro e dunque le capacità di sopravvivenza e di crescita della nostra città. Abbiamo poi deciso di concentrare la nostra attenzione in modo specifico su questo ambito perché riguarda il nostro personale settore di lavoro (informatica ed innovazione digitale).

L’approccio che abbiamo adottato per realizzare l’analisi è questo:

• ci siamo attenuti strettamente alla lettura dei programmi scritti ufficiali e volutamente non abbiamo considerato (pur avendoli in parte seguite) le video interviste, i talk-show e panel vari.
• per ognuno dei candidati abbiamo cercato sul web il documento del programma, abbiamo estratto le parti che riguardano il digitale e le abbiamo riportate e commentate esprimendo un nostro parere.
• abbiamo connotato i nostri personali commenti con le sigle [GR] per le note di Giorgio Robino e [GDB] per le note di Giuditta Del Buono.

Osservazioni generali

I 9 candidati sindaco sono qui elencati in ordine alfabetico:

1. Stefano Arrighi
2. Marco Bucci
3. Marika Cassimatis
4. Gianni Crivello
5. Arcangelo Merella
6. Marco Mori
7. Luca Pirondini
8. Paolo Putti
9. Cinzia Ronzitti

I programmi presi in considerazione sono i documenti pubblicati sul web, in data 5 giugno 2017, ore 14:00. Articolo aggiornato in data 8 giugno, ore 15:30.

Dei 9 candidati, solo 4 hanno pubblicato sul web un documento vero e proprio che approfondisce e dettaglia il programma proposto; 4 di loro hanno pubblicato una singola pagina web, piuttosto scarna di contenuti, uno di loro non ha reso disponibile il proprio programma nemmeno attraverso una pagina web (lavoro che avrebbe richiesto non più di qualche ora di impegno). Casualmente, e ad alleviare il nostro senso di colpa per questa scelta non del tutto politically correct, nell’immagine di apertura dell’articolo mancano proprio i due candidati il cui programma è stato divulgato in misura minore.
Ci siamo stupiti quindi prima di tutto della perlomeno apparente (attendiamo di essere contraddetti nel caso ci fossero sfuggite le corrette fonti) scarsità di informazioni scritte che caratterizza buona parte delle candidature.

Riteniamo che questa mancanza di approfondimento debba essere di per sé criticata, anche se il nostro obiettivo qui non è quello di fare un’analisi politica generale (proprio per questo motivo abbiamo volutamente omesso simboli/riferimenti di partito o movimento o ideologia).

I programmi talvolta contengono inoltre errori di forma sui quali non siamo intervenuti. Anche le nostre riflessioni sono riferite ai contenuti del programma e non all’uso (talvolta curioso) della terminologia tecnica.

Ecco di seguito il nostro report candidato per candidato.

1. Stefano Arrighi

Programma

Non abbiamo individuato un documento di programma per le comunali.
Abbiamo richiesto chiarimenti e approfondimenti, non ancora pervenuti. Spulciando l’”alfabeto programmatico” del Popolo della Famiglia al link:

Il programma del Popolo della Famiglia: 26 punti di orientamentoARTICOLO TRATTO DALLA VERSIONE PER ABBONATI, SOSTIENI LA CROCE www.lacrocequotidiano.it/abbonarsi-ora L'ambiente è il…www.lacrocequotidiano.it

Alla lettera “d” troviamo la “Destinazione universale dei beni”. Nessuna traccia del digitale nemmeno tra le altre lettere.

[GDB][GR] Ci sembra incredibile che un candidato sindaco non abbia trovato modo di pubblicare per iscritto il proprio programma personale. Sul digitale (come su ogni altro tema) per quanto ci riguarda almeno per ora Arrighi è escluso dal confronto.

2. Marco Bucci

Programma

documento (55 pagine)

Sul digitale

pagina 7:

L’ambizione di Genova è di diventare Smart, una città intelligente che promuove modelli di sharing economy (economia della collaborazione) per la totalità dei suoi cittadini. Un «Comune in tasca» accessibile nei suoi servizi a tutti i soggetti interessati perché tutto sarà online e fruibile da ogni dispositivo digitale (e- Government).

pagina 9:

3. Avvieremo un pacchetto di esenzioni fiscali relative alle tasse locali che assieme alla esenzione dell’IRAP regionale renderà competitivo il Comune per i nuovi insediamenti,prevedendo una riduzione delle imposte locali (IRAP e TARI) per le imprese che si insedieranno sul territorio e per le nuove start up innovative, ma anche per le aziende che assumeranno nuovo personale.

[GR] Good news, si tenga però presente che la dicitura “startup innovative” non significa tout-court aziende che operano nel digitale e di fatto ad oggi non identifica pienamente aziende connotate da un forte contenuto di innovazione.

[GDB] Interessanti le esenzioni fiscali.

4. Focalizzeremo il Parco Scientifico e Tecnologico-Great Campus come rimodulatore dell’assetto della Città. L’amministrazione riconosce il ruolo del Great Campus quale fattore abilitante per la crescita del territorio. Metterà quindi in atto azioni che ne supporteranno e favoriranno lo sviluppo al fine di creare ricadute positive in ambito tecnologico e in tutti gli altri settori economici, creando nuovi posti di lavoro.

[GR] Non è specificato come il Great Campus porterà nuovi posti di lavoro. Purtroppo la città ha già visto perdere un numero elevato di posti di lavoro in Ericsson, una delle aziende insediatesi agli Erzelli.

5. La Liguria, in collaborazione con IIT, avrà uno dei sistemi più avanzati in termini di tecnologia e scienza a servizio della vita (Human Technology Hub). Il Comune sarà il principale partner per la sperimentazione delle innovazioni tecnologiche, soprattutto a servizio dei suoi cittadini più fragili.

[GR] Andrebbero forse descritti più in profondità i punti di forza e gli obiettivi del sistema “Human Technology Hub”.

7. Promuoveremo il lancio di un programma «Silver Technology» che promuova l’alfabetizzazione tecnologica di tutti coloro che non hanno dimestichezza con le tecnologie digitali, ormai indispensabili per una cittadinanza attiva e qualificata (vedi tessera “Silver” capitolo 8.4). In collaborazione con l’Università e le scuole sarà lanciato un progetto di condivisione delle conoscenze per cui studenti «digitali» aiuteranno le persone meno abituate alle nuove tecnologie, traendone in cambio sgravi sulle tasse universitarie, riduzioni sull’abbonamento dei mezzi pubblici.

11. Utilizzeremo le nuove tecnologie e le specifiche soluzioni già sviluppate da start-up genovesi per coinvolgere la cittadinanza nella segnalazione, tramite foto e altro, di danni ai beni artistici e all’arredo urbano.

[GR] A quali nuove tecnologie ci si riferisce?

12. Sperimenteremo logiche di crowd-funding (raccolta di fondi attraverso piccoli contributi di gruppo molto numerosi che condividono un medesimo interesse) in progetti di interesse generale della cittadinanza (dall’arredo urbano ad eventi di quartiere).

[GR] Manca approfondimento sul preciso ruolo che il Comune avrebbe nei processi di crowd-funding.

13. Innovation Network : Genova può candidarsi ad essere il fulcro di un network variegato ed esteso di partner per l’innovazione, un ponte tra esperienza e visione del futuro, grazie ad un’offerta di servizi e partnership (Università, incubatori, acceleratori, fondi d’investimento, aziende sul territorio, grandi partner nazionali, attività culturali e commerciali) che vanno aggregati, potenziati e comunicati con una pianificazione lungimirante. Per realizzare questa visione serve una camera di regia istituzionale che metta a disposizione spazi di aggregazione, di lavoro e di contaminazione, fruibili da studenti, liberi professionisti, startup e PMI innovative, assieme a risorse aziendali tramite smart working.

Non un’unica sede, ma una struttura distribuita strategicamente sul territorio, per sfruttare al meglio le peculiarità della città, rendendo piacevole fare networking, lavorare e ispirarsi.

Parliamo di spazi per il co-working per studenti, talenti e aziende, cosi locati sul territorio:
a) Una sede in una zona centrale di Genova per favorire l’aggregazione (es.: tramite la riqualificazione della struttura Hennebique).
b) Una sede presso gli Erzelli per favorire il trasferimento tecnologico tra IIT, Università e aziende.
c) Spazi per studenti e aziende, nei pressi o all’interno delle facoltà dell’Ateneo genovese, per creare continuità e contatto tra formazione, ricerca e mondo del lavoro. Questi spazi, ospitando eventi e fiere nuove di grande attrazione, con potenziale di mostrare il futuro realizzato da startup, ricerca applicata d’alto livello e creatività, potranno fare da volano anche per il business tradizionale e il turismo, come avviene in molte capitali europee della tecnologia e dell’innovazione.

[GDB] Da diverso tempo si parla di aggregazione degli attori di innovazione attivi a livello locale e della necessità di un loro coordinamento. Credo sia necessario a questo punto fare un passo ulteriore e proporre delle logiche di coordinamento. L’esistenza di una rete realmente funzionante avrebbe probabilmente un impatto positivo superiore alla creazione di nuovi coworking in diverse aree della città.

pagina 13:

1.4 L’impatto occupazionale

Alta Tecnologia e Industria
1. Crescita e sviluppo di Startup e Spin Off universitari
2. Grandi Aziende e Medie Imprese esistenti: protezione e rilancio
3. Grandi Aziende e Medie Imprese di nuova collocazione: marketing territoriale e sviluppo
4. Polo IIT (Istituto Italiano delle tecnologie) — Human Technology Hub
5. Ribaltamento a mare per supportare l’espansione di Fincantieri
6. Sviluppo tecnologie avanzate per la Sicurezza Nazionale (Cyber Security) e Monitoraggio del Territorio
7. Sviluppo comparto Energia — Progetto «Energy Valley» (**)
8. Sviluppo comparto manifattura: Enterprise 4.0

pagina 47:

8.4 Servizi per categorie speciali

1. Card della Cultura Comune di Genova- Genova City Pass

Ideata per sostenere le attività ed i progetti delle Istituzioni Culturali, promuovere lo sviluppo e la competitività del territorio, la Carta della Cultura è in grado di portare vantaggi ai cittadini, ai turisti in visita, al territorio e alle amministrazioni comunali.

La card della Cultura è uno strumento dedicato ai cittadini e ai turisti per l’accesso in modo unificato a servizi acquistabili dal portale web e fruibili dalla Carta Multiservizio della Cultura che integra accessi facilitati a musei, spettacoli, concerti, visite guidate, titoli di viaggio per i trasporti pubblici, circuito di promozioni dedicate alla ristorazione, al pernottamento e allo shopping.

[GR] “Genova City Pass”, in pratica una specie di marketplace info-commerce/ecommerce. E’ una buona cosa, basta che i costi non ricadano sui piccoli esercenti per i quali il servizio dovrebbe a mio avviso essere gratuito, al fine di invogliare a progressiva digitalizzazione delle micro attività.

La soluzione è accessibile anche in mobilità utilizzando smartphone e tablet grazie alle app dedicate che permettono agli attori aderenti (Amministrazioni , Enti , Esercizi) di dialogare con facilità e velocità con turisti e cittadini. Vantaggi immediato per amministrazione e territorio, con aumento della visibilità dell’offerta, del legame con il territorio e con il continuo monitoraggio dei consumatori e dei servizi correlati.

2. Green Card dedicata ai giovani (15–29 anni)

Il progetto intende far evolvere la Green card giovani attualmente in uso ( tessera gratuita con sconti a vista) in una carta finanziaria prepagata che mantenendo l’accesso alla rete di agevolazioni e sconti di carattere culturale, ricreativo, sportivo, turistico e commerciale presso Enti, associazioni, strutture, servizi ed esercizi commerciali che hanno aderito all’iniziativa nel corso degli anni, offra in aggiunta a tutti i giovani uno strumento di carattere bancario (conto corrente online con Home Banking e Circuito di Credito) un circuito di fidelizzazione in Cash Back e altre opportunità di sconti ed agevolazioni dedicate al progetto rese possibili dalle caratteristiche bancarie della smart card.

[GR] Personalmente mi interesso di sistemi di pagamento elettronici e ritengo che un circuito di pagamento con cashback sarebbe di grande impatto, ma la proposta non spiega come si intende realizzare il progetto che ovviamente implica il coinvolgimento di una o più banche.

Non è spiegato se il progetto debba essere inteso in un’ottica di business privato o di open-business (in quest’ultimo caso le banche non trarrebbero profitto dall’operazione o quantomeno il profitto sarebbe concordato con l’amministrazione).

3. Carta Silver dedicata agli anziani

Oltre ai vantaggi succitati della card giovani (sconti, prepagata, buoni acquisto a voucher per progetti mirati es: per i servizi di volontariato nei musei) e’ integrabile in accordo con la Regione con i servizi sanitari e sociali.

[GR] Manca approfondimento. In generale, quella delle card è una proposta fatta anche dal candidato Pirondini.

pagina 48:

9.1 Il Comune al servizio dei Cittadini

d. Una nuova Amministrazione: semplificazione e digitalizzazione

Con l’amministrazione uscente ancora oggi, dopo anni di annunci e di attese semplificazioni, le pratiche burocratiche e i rapporti con l’amministrazione costituiscono un onere per cittadini e imprese.

Oggi non è possibile pensare alla modernizzazione dell’amministrazione e a nuovi servizi prescindendo dalle nuove tecnologie dell’informazione e delle comunicazioni.

La rivoluzione digitale in atto è inesorabile e noi dobbiamo recuperare il tempo perduto dall’amministrazione uscente e procedere con decisione per colmare il digital divide e attuare l’ammodernamento dell’ente.

e. Il coinvolgimento attivo dei cittadini è importante

Il Comune realizzerà un Portale Segnalazioni del Comune di Genova (dissesti strade, marciapiedi, atti vandalici, igiene pubblica, etc) per garantire migliori condizioni di sicurezza a cittadini ed imprese. La soluzione, resa disponibile attraverso le infrastrutture in Cloud di operatori liguri ed italiani, prevederà un sistema di ricezione e gestione delle segnalazioni relative sia ad eventi programmati sia imprevisti, che potranno essere effettuate sia dal personale in forza in tempo reale che dai cittadini, attraverso il collegamento dati tramite smartphone o tablet, consentendo al Centro di Comando e Controllo di procedere tempestivamente alla verifica della segnalazione e al dispacciamento delle attività necessarie ai team di competenza, tracciando l’intervento fino alla risoluzione.

pagina 49:

f. Un’amministrazione moderna e efficiente

Un’amministrazione moderna e efficiente è lo strumento per la realizzazione della nostra visione e del nostro progetto.La nostra amministrazione comunale deve diventare nei prossimi anni un esempio per qualità e accessibilità dei servizi e innovatività delle soluzioni proposte.

Un obiettivo importante è che tutti i servizi devono essere online e devono essere accessibili in modo semplice (anche da smartphone) da cittadini e imprese.

Per perseguire questo obiettivo dobbiamo realizzare una completa riorganizzazione dell’amministrazione e attuare il passaggio al digitale.

Dobbiamo adottare anche un nuovo modo di lavorare e ritrovare le giuste motivazioni. Il messaggio importante è che sul lavoro contano i risultati non la presenza fisica. Lavorare nell’ente deve essere anche gratificante. Sfruttando i benefici che offre la digitalizzazione possiamo sperimentare e adottare nuove forme di organizzazione del lavoro che vanno in direzione di maggiore autonomia e responsabilità. Forme di lavoro agile contribuiscono a valorizzare il personale e consentono di conciliare meglio i tempi del lavoro con i tempi della vita familiare.

Bisogna reingegnerizzare i processi per renderli più semplici e funzionali a compiere la piena transizione al digitale. Il cambiamento, oltre a migliorare la qualità dei servizi offerti, consentirà di razionalizzare carichi di lavoro, superare compiti obsoleti e conseguire maggiore efficienza nella ripartizione del personale.

In questa logica verrà effettuato una precisa analisi delle modalità di funzionamento dei Municipi per meglio definire il legame con le struttura centrali, valutarne la possibile semplificazione (numero e consiglieri) finalizzata a favorire migliori servizi e migliore integrazione con le altre strutture presenti sul territorio (es. ASL).

Occorre adottare sistemi informativi adeguati a supporto delle funzioni di programmazione e controllo e di gestione dei servizi.

Dopo anni di gestione disastrosa anche dal punto di vista della comunicazione, la ricostruzione del rapporto di fiducia con i cittadini è di fondamentale importanza. I cittadini devono essere messi nelle condizioni di conoscere e valutare i risultati delle politiche intraprese.

A tal fine bisogna che tutto quello che produce l’amministrazione (documenti, dati, informazioni) sia assolutamente trasparente. Il valore fondamentale dell’amministrazione deve essere l’accountability verso i cittadini — contribuenti, che sono i veri azionisti dell’amministrazione. Bisogna quindi adottare moderni strumenti di rendicontazione sociale e web reporting e potenziare le funzioni di comunicazione con la cittadinanza. L’ente deve essere promotore di pratiche di open government anche come strumento per incentivare il controllo civico sulle politiche.

pagina 50:

9.2 Valorizzazione del personale del Comune

La Scuola di amministrazione pubblica deve diventare un punto di riferimento sul territorio per la formazione manageriale e l’innovazione nella pubblica amministrazione per qualità dei servizi offerti e per capacità progettuale. Essa deve inserirsi nei network nazionali ed europei e deve stabilire relazioni di collaborazione e scambio con altri soggetti — centri, fondazioni e scuole — che perseguono missioni analoghe in materia di innovazione nella pubblica amministrazione.

Il Comune, con l’istituzione della Scuola di amministrazione pubblica, potrà assumere un ruolo di leadership nei processi di innovazione e modernizzazione della società promuovendo la diffusione delle competenze digitali e collaborando con Università, associazioni di categoria, enti pubblici e privati.

[GDB] Forse troppo brusco il passaggio ipotizzato dall’arretratezza alla leadership.

3. Marika Cassimatis

Programma

pagina web (una pagina, o documento)

Sul digitale

1-Sviluppo Sostenibile- wi-fi libero
Wifi libero in tutta la città come opportunità per sviluppare servizi innovativi e supporto del business, dello studio, del turismo, della mobilità e dello svago.

[GDB] Stesso slogan di Merella ma senza rancore, forse a causa della vantata inesperienza nella politica.

4. Gianni Crivello

Programma

pagina web (1 pagina + aggiornamento 8/6: lavoro + amministrazione)

Sul digitale

Punto 2 “Il Comune regista di sviluppo”
Il Comune ha bisogno di più risorse. Anche per poter usare la Grazie ai nuovi investimenti possiamo superare l’isolamento logistico e consolidare Genova come città attrattiva. Il Blueprint, il completamento del waterfront, lo sviluppo della cittadella tecnologica di Erzelli e dell’Istituto Italiano di Tecnologia, un forte marketing territoriale e un sistema di agevolazioni fiscali e di opportunità per chi porta lavoro e competenze, rendono il Comune soggetto centrale contro il declino.
Lo sviluppo di una grande città ha bisogno di un ateneo ed una ricerca sempre più capaci di competere e dialogare con il mondo: un Patto con l’Università dovrà connettere formazione e lavoro nell’area metropolitana genovese, favorendo servizi diffusi dedicati, agevolazioni abitative e la qualificazione del centro storico come vera e propria cittadella universitaria. L’ IIT, deve restare a Genova non solo fisicamente: è ora che il suo talent garden produca effetti diretti sulla città che può beneficiare per prima dei suoi tanti spin off produttivi. politiche finanziarie nazionali.

Punto 9. “Il Comune amico” 
Una burocrazia più snella, che risponda ai cittadini in modo veloce, anche online; la nascita di una “CartaGenova” che permetta di accedere ai servizi sociali e d‘informazione collettiva; la possibilità di avere tramite il Comune libri scolastici e tablet per la scuola in comodato d’uso, per agevolare le famiglie in difficoltà.

[GDB] Se questo è il programma, sul digitale vediamo tanti slogan, molte poche idee e forse confuse (è solo una metafora il riferimento al “talent garden” di IIT? Ci auguriamo di sì). Una sola “CartaGenova” che appare perdente contro le tre carte (Cultura, Giovani, Silver) che gioca Bucci.

[GR] I punti d’intervento sembrano una lista di titoli, a cui non segue nessun chiarimento d’intenti, nessuna visione. L’idea della “carta” è presente anche nelle proposte dei candidati Bucci e Pirondini.

Aggiornamento: 
In data 8 giugno (successiva a quella di pubblicazione di questo articolo, il 5 giugno, ore 14), il sito del candidato è stato aggiornato con una sezione “programma”, consistente di alcune pagine che dettagliano meglio i punti; tra questi, quelli che riguardano il digitale sono Genova 4.0: Sviluppo e integrazione digitale, ricerca e Università e Competenze e servizi digitali

[GDB] La conoscenza dello scenario attuale non sembra elevata, nel momento in cui si fa riferimento al Talent Garden come ad una delle ricadute della presenza a Genova dell’IIT, e non sembra chiaro il percorso per fare di Genova un polo di innovazione, nel momento in in cui si parla di “costituzione di ecosistemi” di connessione tra università, ricerca e imprese.

[GR] Il dettaglio delle pagine ora inserite sul sito web evidenzia non pochi punti in comune con i programmi dei candidati Pirondini (e-governement) e Bucci (mondo del lavoro ed enti di ricerca). Molti buoni intenti, poco dettaglio su come realizzarli.

5. Arcangelo Merella

Programma

sito web (1 pagina)

Sul digitale

7. Economia del mare, hi-tech e turismo per uscire dalla crisi
Inoltre basta ritardi e false promesse per il rafforzamento e l’ampliamento della banda larga e del wi-fi in tutta la città.

[GDB] Lo stesso slogan della Cassimatis, ma più “rancoroso”.

[GR] Parlare genericamente di hi-tech e wi-fi, senza dettagliare, indica la mancanza di una precisa visione del futuro (nei termini di utilità “applicativa” della digitalizzazione).

6. Marco Mori

Programma

documento (43 pagine)

Sul digitale

Il programma non tratta il tema del digitale.

La spiegazione implicita è contenuta nelle ultime righe del documento:

Completamente inutile affrontare altri temi nel programma. Genova, come gli altri comuni italiani, è sotto occupazione di un nemico invisibile ai più, costituito dai grandi gruppi del capitale internazionale. Pensare a dove posizionare la nuova panchina del parco mentre la città viene bombardata suona addirittura ridicolo.

[GDB] E’ una scelta. Per Mori la strategia di sviluppo digitale non è una leva prioritaria per la crescita locale. Nel programma spiega con quali strumenti e politiche recuperare risorse che potrebbero essere poi impiegate in ambiti strategici per la città, e ci auguriamo che a quel punto il digitale sarebbe preso in considerazione.

[GR] Devo dire che in alcune interviste, il candidato ha risposto in modo positivo su varie proposte di digitalizzazione fattegli, ma effettivamente il programma omette la questione in toto.

[GDB][GR] Per motivi diversi rispetto ai candidati che si sono astenuti dalla pubblicazione del programma, siamo dunque costretti ad escludere anche Mori dal nostro confronto.

7. Luca Pirondini

Programma

documento (162 pagine)

Sul digitale

pagina 111:

4. LA DIGITALIZZAZIONE DEL SISTEMA DI GOVERNO COMUNALE,
MUNICIPALE E METROPOLITANO

1. Il piano digitale del Comune

L’idea di città digitale in 5 punti
1. Servizi comunali online accessibili per ridurre o eliminare le code agli sportelli
2. Piano di Alfabetizzazione digitale per non lasciare indietro nessuno
3. I dati per la trasparenza e la buona amministrazione per rendere disponibili e riutilizzabili i dati aperti per costruire scenari in supporto ai processi decisionali pubblici (es. interventi su zone ad alto tasso di incidenti stradali, gestione ottimale dei flussi turistici o altro) nel pieno rispetto della privacy di tutti gli attori coinvolti
4. Iniziative di Partecipazione civica con piattaforme online per mettere a sistema le buone energie in campo e operare scelte condivise cittadini/PA
5. La città in rete per turisti e cittadini per accedere all’offerta culturale e turistica del territorio , luoghi ed itinerari cittadini di particolare interesse ed altri servizi annessi

pagina 111:

1 — Servizi comunali online

Studio, lavoro, questioni famigliari, imprevisti: al giorno d’oggi la necessità di ridurre i tempi della burocrazia per aumentare l’efficienza e migliorare la qualità della vita risulta essenziale, in questo senso ICT può offrire grosse opportunità di applicazione. La nostra amministrazione sarà contraddistinta dalla individuazione e dallo sviluppo di tutti quei servizi che possono essere fruiti attraverso internet (in alcuni casi si tratta di riprendere il lavoro già
iniziato dalla precedente amministrazione) allo scopo di velocizzare e soprattutto di ridurre il più possibile le occasioni in cui al cittadino ed al turista viene chiesto di fare code agli sportelli.

Nell’ottica di una semplificazione dei servizi occorre pianificare una riorganizzazione del sito istituzionale Comunale in modo che sia ben chiaro e ben visibile in un unico passaggio quali servizi possono essere utilizzabili anche online.

[GR] Effettivamente la user experience dell’attuale sito web del comune di Genova è poco “user friendly”, per usare un eufemismo.

1. Riorganizzazione del personale finalizzata a strutturare un livello organizzativo che agevoli la transizione al digitale. Si punta ad intervenire in particolare su: efficacia ed efficienza delle procedure; trasparenza dell’azione amministrativa; processi di spesa; sistemi interni di gestione; pubblicazione di dati e documenti in formati aperti; procedure di controllo; processi di approvvigionamento; atti e modulistica; semplificazione bandi.

2. Riqualificazione del personale con l’avvio di un piano di formazione interna che favorisca il miglioramento dei processi organizzativi e il cambiamento sensibilizzando a tal merito tutte le figure dirigenziali coinvolte . L’obiettivo sarà anche quello di valorizzare il capitale umano pronto a mettersi in gioco. La prossima amministrazione si impegna a fare tutto il possibile per colmare il gap tecnologico e culturale dei dipendenti preparandoli ad affrontare lo switch-off con una struttura pubblica culturalmente pronta a muoversi in una organizzazione nativamente digitale. Questi obiettivi saranno parte integrante della quotidiana azione amministrativa.

3. Inserimento là dove possibile di forze fresche attraverso un piano di assunzioni non superiori al 25% forza lavoro andata in pensione come da direttive nazionali.

4. Razionalizzazione dei servizi ridondanti come per esempio le app delle partecipate Amiu e Aster costate rispettivamente 8.000 euro e 4.900. In questo caso il cittadino per effettuare la stessa azione, vale a dire una segnalazione, deve scaricarsi sul proprio Tablet/Smartphone due diverse applicazioni. La proposta è quella di un sistema che amministrativamente integra più uffici, ma verso il cittadino presenta un’unica interfaccia web fruibile su tutti i dispositivi sul modello di SensorTrento .

5. Adozione di strumenti Open Source allo scopo di ridurre, la dove possibile, i costi di licenza dei prodotti e liberando la Pubblica Amministrazione da un’eccessiva dipendenza dal software proprietario. Occorre avere il pieno controllo sul software che controlla i dati dei nostri cittadini. ( cit. Flavia Marzano )

[GR] Non conosco quali siano i costi di licenza del software proprietario usato dalla PA, ma il punto sostanziale non è soltanto il controllo del software, ma il controllo dei dati dei nostri cittadini.

6. Affrontare il problema della mancanza di Interoperabilità dei sistemi informativi attraverso un’ adeguata progettazione che preveda tra l’altro l’introduzione di software open source accanto ad applicativi proprietari esistenti e l’adozione di formati standard fruibili dagli utenti su tutti i computer.

[GR] Sono inorridito dalla mancanza attuale di interoperabilità (che però ricordiamoci ha radici politiche e di convenienza solo per ultime vere ragioni tecniche).

7. Sistema pubblico d’identità digitale ( SPID ) è il sistema unico di login per l’accesso ai servizi online della pubblica amministrazione e dei privati aderenti. Tutte le amministrazioni locali sono chiamate ad adeguare i propri servizi al piano nazionale nazionale. Oltre a continuare su questa strada pensiamo all’accesso unificato di servizi come: anagrafe e stato civile, modulistica IMU e Tasi, SUAP Sportello unico Attività produttive, accesso gratuito alla rete wifi cittadina per residenti e city users registrati ed una pagina web di facile consultazione in cui siano elencati con trasparenza i servizi erogati con la possibilità per il cittadino di accedere alle informazioni su come usarli e segnalare eventuali malfunzionamenti.

[GR] Sì. Il sistema SPID è assolutamente necessario.

pagina 113:

Alfabetizzazione e cittadinanza digitale

Per partecipare alla vita pubblica e fruire dei servizi messi a disposizione occorre che i cittadini siano connessi ed alfabetizzati. Occorre un piano di digitalizzazione dei cittadini.

[GR] Il punto è estremamente importante, perché l’alfabetizzazione è premessa culturale, di integrazione e di prospettiva di lavoro.

1. Apertura di “sportelli per la semplificazione” in tutta Genova, sul modello di Roma, che fungano da supporto alla cittadinanza in particolare anziana ma non solo nell’uso dei servizi pubblici online e sui propri diritti digitali. (es. accesso civico)

2. Coinvolgimento delle realtà associative che già svolgono attività simili attraverso un ruolo di “regia” pubblica sul modello di progetti pilota già sperimentati a Genova.

[GR] Cosa si intende per regia pubblica? 
Quali sono questi progetti pilota già sperimentati? 
Non chiaro.

3. Integrazione di quanto già proposto con l’illustrazione di strumenti e processi innovativi che prevedano la progettazione partecipata online su specifiche tematiche da individuare di volta in volta e il cui utilizzo sarà opportunamente spiegato partendo dagli “sportelli per la semplificazione” presenti sul territorio

pagina 113:

I dati per la trasparenza e la buona amministrazione

E’ importante individuare tipologie di “dati aperti” da inserire sul portale ufficiale del comune di Genova rilevanti per una eventuale utilità pubblica come per esempio:

1. incidenti stradali sull’esempio del Comune di Bergamo che grazie ad un’analisi avviata a seguito della pubblicazione di questi dati, ha scelto di attuare degli
interventi per migliorare la viabilità che hanno ridotto il numero di incidenti stradali.

2. parcheggi a strisce bianche presenti in città o ancora su Blu Area, Isole azzurre, ZTL, ecc. che potrebbero essere utili come informazione per i turisti e per dare la
possibilità di sviluppare servizi o applicazioni finalizzate ad informare gli utenti sui posteggi disponibili in strade urbane e centri d’interesse.

3. Immobili dismessi e abbandonati: il Comune di Genova detiene una ingente quantità di immobili dismessi o da riqualificare il cui inserimento anche parziale “a sistema” nel tessuto produttivo e associativo funzionerebbe da volano per nuove attività economiche, sociali e culturali. Mappare adeguatamente queste
informazioni e renderle fruibili in formati aperti e contestualmente su un portale di facile consultazione consentirà di uniformare gli elenchi già in possesso ai
Municipi, creare app e servizi, favorire nuove proposte di utilizzo per associazioni, enti interessati, persone creative. La stessa azione potrebbe essere fatta per gli immobili privati inutilizzati o peggio in stato di abbandono . Rendere pubblico un elenco di questo tipo coinvolgendo associazioni ed enti che hanno a cuore il riuso, ma anche i comitati e i singoli cittadini che segnalano le situazioni diventate fonte di degrado (vedi punto 4 del programma) favorirà la partecipazione ad un processo di riqualificazione urbana. Si parte da buone intese regionali per la valorizzazione del patrimonio pubblico derivate dal piano nazionale del demanio a progetti concreti e realizzabili dalla prossima amministrazione.

4. Open Demanio attraverso la sezione rigenerazione e riuso del progetto nazionale vogliamo avviare processi partecipativi aperti e trasparenti che coinvolgano cittadini, associazioni, imprenditori ed altri enti. (vedi punto 4 del programma) Produrre, usare e sintetizzare i dati attraverso valutazioni e strumenti adeguati è quindi il valore aggiunto che vogliamo fornire alla macchina comunale.

pagina 114:

Partecipazione civica con piattaforme online

Per creare le condizioni che portano alla progettazione partecipata, avere una visione il più possibile dettagliata del territorio e facilitare la comunicazione con l’ente comunale l’idea è quella di partire avviando una mappatura della cittadinanza attiva su scala cittadina (associazioni, comitati del territorio, ecc.) da realizzarsi coinvolgendo i Municipi e tutti gli attori interessati. I dati raccolti saranno pubblicati in formato Open Data ed inseriti all’interno
di un portale istituzionale categorizzato e di semplice consultazione.

pagina 115:

La città in rete per turisti e cittadini

1. Il comune in tasca per cittadini e turisti con un’app integrata contenente informazioni divise per categorie su:
○ Introduzione : storia, geografia, dati statistici
○ Il Comune — guida agli uffici: elenco degli uffici dell’Amministrazione
Comunale con l’indicazione dei contatti e degli orari di apertura;
○ Eventi : informazioni su tutti i principali eventi aggiornati in tempo reale;
○ Da vedere : descrizione e informazioni utili su musei, siti di particolare interesse storico-artistico (gli edifici storici, le chiese, le aree archeologiche, le
piazze, ecc.) e su quelli di particolare interesse naturalistico;
○ Itinerari : Per ogni percorso turistico di ogni zona d’interesse nella città sono
presenti indicazioni sulla percorribilità per le persone diversamente abili;
○ Dormire : informazioni sui servizi di ricettività;
○ Mangiare : informazioni sui servizi di ristorazione;
○ Multimedia : galleria fotografica;
○ Servizi Info e numeri utili : contatti e riferimenti dei servizi dedicati ai turisti e ai cittadini.
2. City Card: un portale/app che consenta ai turisti di acquistare la propria City Card personalizzata da computer sul modello del Comune di Venezia e che permetta di centralizzare alcune operazioni/informazioni come per esempio l’ acquisto di servizi turistici tra cui l’accesso wifi agli hotspot pubblici ed integrata con “Comune in tasca”
3. Hotspot wifi : l’introduzione di un servizio di City Card sul modello del Comune di Venezia e di SPID ( Sistema pubblico d’identità digitale) consentirà a regime di introdurre il pagamento del wifi comunale per i turisti che ne fanno richiesta, gratuito per residenti e city user (lavoratori, studenti, professionisti che svolgono la propria attività nel comune di Genova)

[GDB] Eviterei il pagamento del wi-fi comunale per i turisti.

[GR] Tale proposta è molto simile a quella del candidato Bucci.

pagina 116:

2. La prossima Genova Smart City

Ancora è importante lavorare per la costruzione di scenari comparativi e previsionali , da parte dei soggetti tecnici che sono chiamati a dare supporto ai decisori politici con il supporto per esempio di Open Data e Big Data e per la riduzione delle diseguaglianze fisiche, economici o culturali. Al raggiungimento di questi obiettivi, complessi e decisivi, vanno dedicate risorse specifiche (e ingenti), finalizzate in primo luogo alla corretta infrastrutturazione delle città e all’alfabetizzazione digitale almeno di base . Il dibattito sulla dimensione e l’urgenza dei grandi investimenti per la costruzione delle infrastrutture di rete rischia di nascondere un elemento che pare poco dibattuto (salvo preziose eccezioni): senza adeguati standard di interoperabilità e apparati di riconoscimento che consentano il flusso continuo e sicuro dei dati tra tutti i soggetti che li detengono e utilizzano, anche le reti più potenti rischiano di essere sottoutilizzate. Si pensi per esempio alla connettività wifi in città in cui nelle diverse zone o locali l’accesso non unificato può generare scoramento nei turisti stranieri .

pagina 118

Conclusioni

La nostra idea di Città Digitale è l’idea di una Genova in cui non esista mai più una separazione netta tra due mondi (digitale ed analogico), ma dove uno va a supporto ed integrazione dell’altro per migliorare la vita quotidiana ed il lavoro di tutti i cittadini.

[GDB] Le proposte ci sono, molte di buon senso, molte quasi coincidenti con quanto proposto da Bucci, con una nota di stile che riporta dove possibile ai temi cari al Movimento (trasparenza, partecipazione).

[GR] Proposta ampia e ben dettagliata. In molti punti simile a quella del candidato Bucci. Il programma contiene una vasta lista di punti di azione, ma mancano esempi concreti relativi allo specifico territorio comunale della città di Genova.

Il digitale viene considerato come facility del cittadino e sistema di e-governance (il che va benissimo) ma pare che manchi una visione del digitale come strumento per il rilancio del lavoro e dell’economia locale.

8. Paolo Putti

Programma

documento (39 pagine)

Punti salienti inerenti il digitale

pagina 17:

Lavoro
La riduzione del tempo e del numero di lavoratori e delle lavoratrici necessari a produrre beni e servizi è drasticamente calato con l’automazione meccanica, con la rivoluzione informatica digitale e sta ancora più rapidamente calando con lo sviluppo di intelligenze artificiali. A Genova più che in altre città questo processo ineluttabile ha prodotto una perdita dei posti di lavoro e ha quindi generato malessere, a causa sia della difficoltà economica, sia della perdita del riconoscimento sociale attribuito a chi lavora.

[GR] Dire che il lavoro sta calando anche con lo sviluppo di “intelligenze artificiali” ritengo sia un’affermazione non corrispondente alla realtà delle cose.

Attualmente, a Genova, il numero di persone ed aziende che si occupano di AI anche “solo” in termini di ricerca e sviluppo è talmente esiguo che il problema, purtroppo, nemmeno si pone. In poche parole, attualmente non ci sono posti di lavoro nell’AI, né lavoro scomparso dalla città “a causa” dell’AI.

La mia personale opinione è che invece le nuove tecnologie informatiche permetteranno nuove tipologie di lavoro, e certamente si tratta di lavoro molto qualificato intellettualmente, che necessita di una cultura e di una preparazione professionale ad oggi rara nel nostro territorio.

La ricchezza generata da macchine-computer-robot appartiene alla collettività intera, dal momento che si basa sull’applicazione di conoscenze universali, acquisite nelle università, nelle scuole, nei luoghi pubblici del sapere, il cui fluire e scambio è amplificato dall’iperconessione di rete.

[GR] Questo è un punto estremamente importante, su cui sono personalmente d’accordo. Aggiungo che, in riferimento all’intelligenza artificiale in particolare, è auspicabile che si esca dall’attuale atteggiamento di frammentazione e visione proprietaria (startups, brevetti, etc.).

Per chi fosse interessato, ho trattato questi temi negli articoli: Istituzioni e intelligenza artificiale privata, From AI-blackboxes to open standards ed altri.

Il riconoscimento di questa ricchezza collettiva dovrebbe consentire di ridurre le ore di lavoro a parità di retribuzione, aumentare i posti di lavoro e permettere la creazione di un reddito di esistenza e di servizi pubblici comunali. Chi, come il Comune, gestisce i beni pubblici può, per la sua parte adoperarsi per elaborare strategie per affrontare il cambiamento epocale rappresentato dal decremento del fabbisogno di ore/lavoro, la necessità di svincolare il reddito di sussistenza dall’attività lavorativa cogliendo l’opportunità di sfruttare competenze tecniche che spesso non sono espresse nell’ambito lavorativo (ragazzi e ragazze giovani sottomansionati).

pagina 18:

Banche del sapere/Tavoli di pensiero

Spazi e momenti di aggregazione e confronto dei cittadini e delle cittadine esperti nel campo di servizi pubblici, urbanistica, creazione di imprese, di pratiche partecipative, di gestione delle risorse, di intelligenze artificiali, informatica etc.

[GR] Buon punto, peccato che non venga dettagliato. E’ curioso il fatto che vengano utilizzati i termini “intelligenze artificiali”. Questo è l’unico programma che menziona esplicitamente una delle tecnologie del lavoro del futuro.

Si tratta di incubatori delle conoscenza presenti in città che possono essere utilizzati per:
1)animare il contributo partecipativo della cittadinanza a varie istanze (tavoli tematici);
2) fornire all’amministrazione, in collaborazione con gli uffici contributi tecnici specialistici;
3) contribuire attivamente alla formazione del personale comunale su temi specifici;
4) elaborazione di proposte innovative sul problema del reddito/lavoro/benessere.

[GDB] Una nota di partecipazione più sfumata e probabilmente meno organizzata rispetto al M5S. Un’espressione di intento di partecipazione della collettività (“esperta”, però).

pagina 28:

Contrasto al gioco d’azzardo e ad altri esercizi commerciali non di qualità

Il proliferare di sale giochi e videolottery ha portato all’espandersi di una piaga sociale come la ludopatia, con tragiche conseguenze sociali sulle famiglie e sui livelli di criminalità.

[GR] E’ un punto solo apparentemente scorrelato dal “digitale” perché il gioco d’azzardo prolifera in modo devastante sia nelle sale gioco (off-line) sia nei video “games” on-line (fenomeno in continua crescita); in entrambi casi si tratta di una digitalizzazione perversa e questo programma pone l’accento sul contrasto di questo tipo di “digitalizzazione”. Ritengo giusto addirittura combattere una forma di digitalizzazione, quando questa è “anti-etica”.

Anche il fenomeno di diffusione di distributori automatici
di cibo e bevande ha portato spesso ad un aumento del degrado ed una concorrenza sleale verso gli esercizi commerciali tradizionali.

[GR] Sì. La logistica automatizzata per il mercato “consumer” (per esempio con i distributori automatici di cibo) è senza dubbio “digitalizzazione” ma anche in questo caso si tratta di una direzione sbagliata e che va a svantaggio degli esercizi commerciali tradizionali.

P.S. A riguardo della digitalizzazione delle piccole attività commerciali e dell’home delivery in passato ho lavorato ad alcune soluzioni tecniche e di possibile impatto sociale non riscontrando successo anche in un modello open-business.

Per contrastare questi fenomeni proponiamo:
● Limitazione oraria dell’offerta di gioco tramite provvedimento del Sindaco;
● Azioni e di elaborazione di proposte all’Amministrazione tramite attraverso la Consulta per i giochi a premi in denaro) e di sensibilizzazione in particolare presso le scuole;
● Limitazione dei distributori automatici di bevande che costituiscono concorrenza sleale per le realtà commerciali di prossimità;
● Incentivi, in collaborazione con la Regione, alla qualità commerciale degli esercizi;
● Sostegno tramite ANCI ad iniziative legislative che tutelino la facoltà dei Coomuni di esercitare forme di controllo sulla diffusione delle occasioni di gioco, la tracciabilità dei flussi di denaro impiegati nelle giocate, il divieto di pubblicità alle varie forme d’azzardo

[GR] L’attività di monitoraggio e di controllo dei flussi di denaro è di per sé un’attività informatica doverosa. Spiace che non venga menzionata, tra le azioni a contrasto, quella a mio parere più importante e cioè l’azione di informazione ed cultura, che andrebbe fatta a partire dall’educazione scolastica e diretta alle fasce di popolazione più deboli.

pagina 38:

LA CITTÀ INTELLIGENTE
L’utilizzo delle più avanzate tecnologie informatiche può favorire migliori condizioni di lavoro e risparmi gestionali, attraverso la cultura del “lavoro agile”, da svolgersi anche all’esterno dell’azienda, con incremento di produttività e conciliazione dei tempi di vita e di lavoro e riduzione della congestione dei trasporti nelle ore di punta.

Banda larga e hotspot

Vogliamo promuovere e coordinare gli interventi di tutti gli operatori pubblici e privati al fine di consentire a tutti i cittadini, le cittadine e le imprese un accesso alla rete a banda larga. Vogliamo dotare la città di hotspot wifi ad accesso libero in tutti i luoghi pubblici, garantendo disponibilità e qualità del servizio.

[GR] Generalmente trovo qualunquista la proposta che ancora molti fanno di “hotspot wifi per tutti”, ma qui viene sottolineata la prospettiva di dare l’accesso alle imprese (forse si vuole intendere soprattutto alle piccole imprese). Per esempio se i negozi avessero tutti accesso alla rete, sarebbero possibili servizi di on-line shopping e home-delivery, a supporto dei piccoli negozi.

Sensori intelligenti per il traffico veicolare

Vogliamo installare sensori intelligenti in tutti gli snodi viari e semaforici e in tutti i parcheggi per rendere disponibili informazioni in tempo reale sui percorsi ottimali o sui parcheggi disponibili, per sviluppare strategie intelligenti di gestione della mobilità e dell’interscambio trasporto privato/pubblico, riducendo transiti inutili e congestioni localizzate, riducendo disagi e inquinamento.

[GR] Una operazione di grande impatto ma anche grandi costi (si vedano quali sono stati i costi dei pannelli AMT installati nelle strade di Genova negli anni scorsi). 
Sensori intelligenti potrebbero essere anche utilizzati per il controllo della velocità dei mezzi in circolazione, i cui limiti sono continuamente superati. L’utilizzo di un tracciamento pervasivo di persone e mezzi ha da un lato effetti benevoli per tutta la comunità (gestione automatica di flussi) ma anche aspetti di privacy e “over-control” (video sorveglianza, multe automatiche, etc.). 
Al solito, a mio parere, a monte di una azione di controllo retroattivo e coercitivo, c’è anzitutto la strada principale della formazione e della cultura ai cittadini (l’educazione “stradale” in questo caso).

Intelligenza Artificiale per la creazione e la diffusione di nuovi servizi pubblici

Genova possiede un ricchissimo patrimonio di competenze nei settori più avanzati della tecnologia: Università, CNR, IIT, ecc. Chiamami Genova vuole essere promotrice del coinvolgendo tutti gli esperti ed esperte del territorio per puntare a fare di Genova la città leader dell’IA, con miglioramento della qualità della vita e creazione di un indotto in grado di generare lavoro e ricchezza per le nuove generazioni.

[GR] [GDB] Siamo d’accordo sul principio, resta da chiarire la strategia operativa proposta per il rafforzamento delle sinergie tra enti di ricerca.

Accessibilità Digitale Smart Working

Diffusione della cultura e degli strumenti del “lavoro agile”, svolto cioè in parte all’interno dei locali aziendali e in parte all’esterno, per incrementare la produttività e agevolare la conciliazione dei tempi di vita e di lavoro
specialmente delle lavoratrici e dei lavoratori con figli piccoli o genitori anziani e per ridurre la congestione dei trasporti nelle ore di punta. Allestimento di un congruo numero di spazi di co-working mettendo a disposizione spazi ad uso
pubblico, ampliando la sperimentazione del telelavoro negli uffici comunali.

9. Cinzia Ronzitti

Programma

pagine web: [1], [2].

[GDB][GR] Non abbiamo trovato alcun riferimento al mondo del digitale e come per Arrighi abbiamo chiesto chiarimenti e ulteriori riferimenti sul documento di programma. Al momento anche la Ronzitti è esclusa dalla nostra analisi.

CONCLUSIONI

Considerato quasi inesistente o molto superficiale il programma presentato da molti candidati, riteniamo che solo 3 candidati abbiano approfondito in modo sufficiente il tema del digitale:

2. Marco Bucci
7. Luca Pirondini
8. Paolo Putti

[GDB] Tra Bucci e Pirondini ci sono molti punti in comune e gli slogan comuni a tutti i candidati (che hanno espresso quantomeno slogan) vengono articolati dai due candidati con un certo grado di dettaglio.

Il digitale nel programma di Pirondini è uno strumento importante per la politica ed il tipo di Governo che vuole realizzare il Movimento, con un impatto prima di tutto sul cittadino, mentre per Bucci il digitale è uno strumento per migliorare la qualità della vita del cittadino e per supportare lo sviluppo del territorio grazie ad una maggiore innovazione e competitività delle imprese.

Il programma sul digitale di Putti si differenzia dagli altri, oltre che genericamente per un minore livello di approfondimento, da un lato per le (più) marcate riflessioni di tipo etico e dall’altro per una più spinta (e forse eccessiva) visionarietà.

In tutti e tre i programmi quello che forse manca con più evidenza è l’indicazione degli strumenti e delle strategie operative che si vogliono adottare per attuare i diversi obiettivi programmatici.

[GR] Sono d’accordo con Giuditta sul fatto che i programmi di Bucci e di Pirondini sono simili in molti punti: c’è una visione della digitalizzazione come semplificazione dei processi per i cittadini. Ci sono anche idee pratiche molto simili (il sistema delle cards). 
Nel programma di Bucci c’è una attenzione anche al sistema aziendale privato, con aperti accreditamenti verso specifiche aziende/enti del territorio. 
Il programma di Pirondini non fa riferimento alla digitalizzazione rispetto al mondo del lavoro, facendone invece una questione di e-governance; una visione parziale secondo me.
Il programma di Putti, sebbene sia sul digitale molto meno approfondito di quello dei precedenti candidati, contiene qualche interessante volata positivista ed al contempo critica, facendo riferimento esplicito ai problemi etici e lavorativi delle nuove tecnologie (le “intelligenze artificiali”). Passando dalle stelle alle stalle, ho apprezzato anche il punto contro la digitalizzazione dei sistemi di gioco d’azzardo e i sistemi di automazione della distribuzione di cose e cibo, che stanno portando alla morte dei piccoli negozi ed aumentano il disagio sociale.

[GR] [GDB] In generale, al di là di un maggiore livello di approfondimento che avremmo apprezzato in tutte le proposte, un tema che abbiamo stentato a intercettare nelle proposte dei candidati relative al digitale e che ci sembra invece prioritario, è quello delle politiche per il supporto alla crescita e ad una maggiore qualificazione dell’impiego nel comparto.

In definitiva, la lettura dei programmi non scioglie appieno le nostre indecisioni nella scelta di voto. Ma almeno ora sappiamo (di non sapere).

Questo articolo è stato scritto a 4 mani da Giorgio Robino e Giuditta Del Buono.

Invitiamo i lettori a commentare ed eventualmente fornirci informazioni addizionali sui programmi.

Nelle settimane scorse sono emerse eclatanti novità sui nuovi prodotti e servizi di Amazon e Google (e ultima ma non ultima Microsoft), che riguardano direttamente il mondo dei chatbots.

Si parla sempre di più di ubiquitous computing (termine usato dai paladini Google) ovvero di ambient computing (termine usato dagli evangelisti Amazon). Molti esperti sono d’accordo sul fatto che, udite udite, non solo i personal computers andranno a sparire, ma nel prossimo decennio ci sembrerà progressivamente ridicolo parlare di mobile first, dato che anche i telefoni cellulari non saranno più così fondamentali. Che succederà allora?
 
Ci sarà un progressivo utilizzo pervasivo di servizi vocali e multimodali (termine usato da Google) di tipo conversazionale, che agiranno sui dispositivi di interfaccia più disparati: i telefoni mobili ancora, ma anche terminali vocali e TV interattive.

La gente userà sempre di più interfacce vocali per accedere ai servizi, per strada, in automobile e soprattutto, guarda un pò, a casa.

Il mercato nuovo è quello vecchio! La famiglia, la casa!

Questa sembra la strategia commerciale di Amazon, senza dubbio, ma anche quella di Google. D’accordo, ammettiamo che sia così, ma cosa sono queste annunciate conversational user experiences?

Stiamo parlando di chatbots, ma in un contesto ben più vasto di quello di software per la messaggistica chat.

“Assistant is a conversational interface to Google” — Brad Abrams

Anzi, più che semplice interfaccia, la conversazione è il nuovo paradigma computazionale per Google ed Amazon prime tra tutte (vedi dopo).

Beyond the verbal. Conversational UXsHi Eddmedium.com

Il dialogo diventerà il modo con cui rapportarci con i computers, anzi tutte le “cose”: un numero e tipo innumerevole di dispositivi attorno a noi.

Conversazione, nell'accezione della teoria della conversazione di Gordon Pask (quindi nei termini della cibernetica classica)

ma anche

Conversazione, nei presupposti del principio collaborativo delle massime conversazionali di Paul Grice; ovvero per la progettazione di chatbots “funzionali”, che seguano linee guide di etica ed estetica linguistica, infine di pragmatica.

Tutti ambiti di studio per il team di Google Design che si occupa specificamente di Conversational Voice User Interfaces (non posso non ricordare tra gli altri: Brad Adams, Nandini Stocker, Daniel Padgett, James Giangola, Ilya Gelfenbeyn).

Ogni settimana vengono lanciati sul mercato nuovi dispositivi hardware voicefirst ed il termine “conversazionale” è ormai una keyword tra chi si interessa di design ed UX/UI.

BTW, atteso annuncio questa notte, da parte della startup di Andy Rubin (Android):

Twitter https://twitter.com/BotsbyVB/status/869539416804425728

Proprio oggi Jess Thoms (Xandra Labs) nel suo bell’articolo “A guide to developing bot personalities”, conferma il nuovo trend di un approccio psicologico e di scrittura creativa, necessari alla costruzione di interactive screen writing (per dirla alla Oren Jacob), per chatbots che devono avere una personalità (bot-persona):

A guide to developing bot personalities.Personality is the new UX.blog.prototypr.io

Ma al di là dei propositi e dei facili slogan (“Intelligenza Artificiale” citata a sproposito dappertutto), la maggior parte dei chatbots attualmente in produzione hanno dialoghi troppo elementari.

Mi trovo dunque d’accordo con la critica sollevata qualche giorno fa da Cheryl Platz (Microsoft) il quale ha sostenuto che attualmente anche i chatbots vocali su Amazon Alexa e Google Assistant sono ben poco conversazionali (Voice User Interface Design: New Solutions to Old Problems); ecco un esempio pratico che lei fa nel suo articolo:

By way of example, the “natural language” way to turn off a light isn’t deeply conversational. You wouldn’t turn to your spouse and say, “Isn’t it a chilly night? I’m feeling a bit cold. Turn the thermostat up, won’t you?” (Unless you’re in an Oscar Wilde play, perhaps.) You’d probably just blurt out “Turn the thermostat down.” Less of a conversation, more of a request.
 —Cheryl Platz Voice User Interface Design: New Solutions to Old Problems

Tornando al titolo di questo articolo, penso che la casa e la famiglia siano nuovi mercati di conquista dei big players della comunicazione (e dei media). Due recenti novità di Amazon e Google mi hanno portato a questa conclusione. Andiamo con ordine:

1. Amazon Echo Show ed Alexa

Il dispositivo smart speaker di Amazon Echo nasce nel novembre 2014. Ma è senz'altro all'inizio del 2017 che Echo e il pargoletto Echo Dot raggiungono in USA un successo notevole. Stiamo parlando di un dispositivo connesso ad internet con dei microfoni ed altoparlanti, che permette di “parlare” ad Alexa, una sorta di metabot centralizzato in Amazon.

Qualche settimana fa Amazon lancia due nuovi dispositivi che estendono Echo aggiungendo una telecamera (Echo Look) ed uno screen (Echo Show). Consiglio la lettura della bellissima analisi di Chris Messina:

Why Silicon Valley is all wrong about Amazon’s Echo ShowSo you think Amazon is a tech company? No, you’re wrongmedium.com

Nell’articolo Messina fa una analisi socio-economica (prima che tecnica) del perché questo apparentemente “stupido” visore touch-screen è una soluzione dirompente e sottovalutata (se non addirittura derisa da molti). Io mi trovo invece d’accordo con lui su tutti i punti, e vedo ulteriori impatti:

Why TVbots Are The Next Big ThingHi Dharmesh! Eventually, I agree with you, especially when you close your article saying:chatbotsmagazine.com

Penso che Amazon Echo Show sia, seppur sicuramente un prototipo forse non duraturo, un definitivo punto di ingresso di Amazon su settori prima poco esplorati dal colosso dell’ecommerce: la famiglia, la casa, la comunicazione interpersonale con voce e video (in concorrenza diretta con le mobile Telco!). Il dispositivo si pone infatti come abilitatore di video-chiamate tra familiari (servizio drop-in).

Video Recensione Amazon Echo Show (generazione 1)

Penso che la cara vecchia TV non sia affatto morta (ovviamente lo è morta nei termini di fruizione di canali broadcast, ma non lo è nei termini di centro di intrattenimento interattivo per la famiglia).

Echo Show e la Amazon Fire TV (sono appena usciti nuovi televisori Amazon con screen giganti, Alexa-enabled, ovvero che integrano una interfaccia vocale con un televisore) permetteranno presto lo sviluppo di quelli che chiamo TVbots, ovvero chatbots che estendono gli Alexa skills per applicazioni “multimodali”, non solo vocali, ma dove l’informazione di output all’utente potrà essere non solo audio ma anche visiva: per esempio un utente potrà chiedere ad alta voce le previsioni del tempo e in aggiunta ad una risposta vocale, sarà anche visualizzata una infografica nella TV di casa nel salotto, od in un piccolo Echo Show in camera da letto, ed eventualmente su una app sul telefono mobile o su su un dispositivo embedded dentro l’automobile, etc. etc.

2. L’evento Google I/O 17: Google Assistant per tutto

Settimana scorsa è terminato lo spettacolare evento #IO17.

In Italia se ne è parlato poco, ma Google ha presentato (in alcuni casi in verità solo annunciato) forse il numero di nuovi prodotti e servizi più ampio in tutta la sua storia, con uno spettacolo multisala durato tre giorni e che ha coinvolto quasi 300 persone sul palco, tra responsabili di area e molti “semplici” sviluppatori.

Lasciamo un attimo da parte l’approccio “democratico” e multiculturale che Google vuole comunicare (e che merita un articolo separato) e concentriamoci sugli aspetti strategici relativi ad Assistant (metabot paragonabile ad Alexa) ed il dispositivo Home (diretto antagonista di Amazon Echo).

La strategia di Google è dichiaratamente “conversazionale” e non riguarda solo il dispositivo Google Home; l’azienda propone un SDK per poter “far parlare” ogni elettrodomestico con Google Assistant:

Personalmente sono impressionato della (nuova) visione di Google e per una volta mi devo rimangiare la mia ironia sul “don’t be evil” della corporation. Stanno facendo un lavoro culturale notevole. Chapeau.

Ho raccolto tutti i talk dell’evento relativi a Google Assistant, Actions on Google e Conversational Design. Vedi anche:

Twitter https://twitter.com/ActionsOnGoogle/status/865718714653704193

Ma cosa c’entrano i Bot-Badanti?

Diamo per scontato il fatto che parleremo sempre più con TV, elettrodomestici aggeggi vari ad interfaccia vocale, telefoni, automobili, etc.

In verità chi risponderà saranno probabilmente metabots, o assistenti virtuali che dir si voglia (Google Assistant o Amazon Alexa), probabilmente con funzionalità estese realizzate da applicazioni sviluppate da terze parti (Actions On Google o Amazon Skills).

Davvero non useremo più i computers e addirittura non leggeremo quasi più?
Il rischio è quello di una progressiva riduzione delle nostre capacità analitiche e critiche?
Io temo che questo rischia esista, a meno che metabots e bot specialistici non siano bot-badanti di una umanità in progressiva demenza ma diventino al più presto sistemi di vera intelligenza aumentata.

Hi Edd

I partially agree with you when you say (I think ironically) that “Alexa is a great kitchen computer”. I seriously believe instead that Amazon is experimenting new prototypical devices (see Amazon Look and Amazon Echo Show) for an incoming “massive attack” in the area of market surprisingly “uncovered”:

Family, at Home

As you may know, Google is pretty in the same way; see news shared at #IO17 event just finished; please note Brad Adams literally stated:

Assistant is a conversational interface to Google

Twitter https://twitter.com/solyarisoftware/status/865904098817826817

So I eventually agree with your statement: “The future isn’t voice, but integration”, with few clarifications: that “integration” is probably what Amazon call ambient computing (and Google call ubiquitous computing), and for me voice (the verbal paradigm) is just a glue of that integration. Now:

is not voice for the verbal, but is voice for conversational (intelligent&interconnected) user experiences.

Google even propose conversational UI as central&pervasive approach in all his new products (see what presented at #IO17).

So what does “conversational” mean?

Conversational is not just a voice interface commodity (in kitchen or in car or wherever you like at home or on the road), but is the ability of new appliances to “talk”, having intelligent conversations, both in man-machines interactions, and also among machines (here conversational imply also a possible chatbot-to-chatbot API open-standards).

So for me conversational UX (not just UI!) means an experience where a human dialog with a machine (a chatbot behind Amazon Echo/GooglHome, or an incoming TVbot behind Amazon Echo Show or Google Assistant for TV), exchanges intents and trans-actions in the cybernetics meaning.

Related articles:

Why TVbots Are The Next Big ThingHi Dharmesh! Eventually, I agree with you, especially when you close your article saying:chatbotsmagazine.com

1. Hardware: the TVhubPremise/recap: in terms of hardware, I see the Amazon Echo Show as a proof of concept of a next-generation of…medium.com

Video https://upscri.be/3e59ef?as_embed=true

• You have a screen (maybe in an incoming new Amazon product a big screen exactly as an usual nowadays TV).
• You have an audio input/output.
• You have an home actuators/sensors hub controller.

2. Software: Services & use cases ( with TVbots)

Audio / video calls
The Amazon Echo Show promotional video just anticipate some new use cases of Alexa skills, for the family,

As the drop-in, the intercom video-calls feature. 
I fully agree when you state in another comment:

“…[a product] for everyone in your family and extended family to make easier, hands-free calls.”

BTW, I feel next step will be the video/audio call to everyone. Here Amazon is disrupting not only the personal computing paradigm, but just the (not-mobile) audio/video call messaging realms.

The corporation also want probably to become a Telco supplier … see Alexa calling & messaging services.

Video-On-Demand
I foresee Amazon Show will evolve soon in an interactive TV: your Alexa assistant will select video on demand streaming channels, just with an audio command:

Alexa, news about Genova, Italia

And you will get a video program with related news.

or

Alexa, any horror movie to watch?
…

And you will watch your preferred Matsumoto’s Tatsuo I stracult movie (joking).

TVbots (anything on demand)
I mean third party bots (Alexa skills with video output), realizing any kind of chat + video application.

Video https://www.youtube.com/watch?v=sVyRkl5qNb8

What, is this too much? :)

Hi Dharmesh!
Eventually, I agree with you, especially when you close your article saying:

“This kind of audio+visual interface is going to be really popular” — Dharmesh Shah

Yes, for quite some time, I called (with a quasi-provocation) the TVbot this “new” kind of audio+visual interface (see my tweets). And by the way, these kind of devices will become soon mainstream, because the chatbot-inside integration:

TVBots = chatbots for voice-first interactive “television.”

TVbots for TVhubs?

TVbots are chatbots for next generation of interactive “television” (let’s call TVhub): a computer connected on internet, sort of smart-home hub enabled by a vocal interface (INPUT) along with a screen/monitor for human-machine graphical info interaction (OUTPUT), and last but not least an IoT central hub to control connected home devices (sensors/actuators).
 
I hazard that TVhubs will also substitute home-phones, and is not by chance that Amazon is launching Alexa Calling (voice over IP service through the Amazon Show device).

Conversational computing (chatbot) still matter (with TVbot)?

Short answer: absolutely yes! 
I’m a CHATbot developer, and I’m specifically enthusiast on natural language-understanding conversational computing realms, but please note this do not contradict the TVbot way: I feel that next generation of chatbots applications will be highly conversational and chatbot intelligent applications will really matters (BTW, of course let’s do not more claim any “artificial intelligence”), instead of the the hardware interface device (Amazon Show or similar incoming competitors TVhubs).

14 May Update:

I better defined TVbots & TVhubs. See also:
https://medium.com/@solyarisoftware/premise-recap-in-terms-of-hardware-i-see-the-amazon-show-as-a-proof-of-concept-of-a-next-1b641a897b17

What do you think about it?

Qui sotto qualche riflessione a caldo sulle “novità” introdotte all’evento.

• riporto mia risposta all’articolo Facebook is killing off WhatsApp
• riporto video di talk su nuovo prodotto Workplace e bot-integrazioni

Hi Andrew Maher, good points in your story!

Here my thoughts about #F82017, specifically trying to answer your questions. BTW, I'm focused on chatbot development (and conversational UX design) and I confess in advance: for me #F82017 news&updates have been a disappointment.

Let’s face it: one of more awaited announce was:

WhatsApp Chatbots! But none of this has happened.

I don’t really know the reasons WhatsApp have been put aside from the Messenger new “games”, nevertheless it seems to me that you are right when you say:

Facebook has stopped innovating with WhatsApp

Reason why are almost mystery for me:

• From the tech side: 
  To integrate/extend the Messenger Bot Platform to WhatsApp does not seem a gigantic work… so I’d conclude that the separation is just a company strategy, but which one?
• From the business perspective: 
  WhatsApp have an established user base of half the world!, especially in chatty/conversational countries and regions, as South-America, East-South Europe (In Italy for 70% population, internet == WA…), but also in East-Europe part of Asia, in India!, also in part of Africa, etc.

So my naif question, about the no-integration of the Messenger chatbots platform into WhatsApp, is:

why giving up with enormous markets all around the world?

In facts I have no answers to my questions and concerns… and yes, I say “concerns”, because I feel that in my country (generally speaking in Europe and above mentioned regions alla round the world)

#boteconomy business (in Europe) will really start and growth up when bots will be available in WhatsApp!

By the way, my delusion on #F82017 is also related to a collateral (but more important) point: 
I have the feeling that Facebook is (paradoxically) “cautious” on chatbots tech innovation, without a clear (or transparent?) strategy regarding instant messaging conversational UX. E.g. Messenger new updates seems to me “minor stuff”, mainly GUI-oriented updates, without a clear vision on new conversational paradigms. But that’s another story for another article…

#F82017 videos to watch!

Here some interesting talks regarding Bot Platform 2.0 updates and chatbots integration in Workplace, the new “Facebook for corporate”, possible competitor of Slack, Microsoft Teams, etc.

Twitter https://twitter.com/solyarisoftware/status/856421361765560320

Twitter https://twitter.com/solyarisoftware/status/856523673997647876

Twitter https://twitter.com/solyarisoftware/status/856420353656094721

Con grande piacere inoltro anche qui sul nostro blog, l’invito di AgID, Agenzia per l’Italia Digitale — Presidenza del Consiglio dei Ministri, e rimando il lettore alla lettura del comunicato odierno:

Chiamata all’Intelligenza (artificiale)!Una task force per studiare gli effetti dell’Intelligenza Artificiale per la creazione e la diffusione di nuovi servizi…medium.com

La task force è stata promossa da AgID allo scopo di comprendere come le possibilità offerte dall’intelligenza artificiale possano incidere nella costruzione di un nuovo rapporto tra Stato Italiano e cittadini, analizzando le implicazioni sociali relative alla creazione di ulteriori possibilità di semplificazione, informazione, interazione.

Io non amo il termine “intelligenza artificiale”, usato troppo a sproposito negli ultimi tempi, sopratutto in ambito chatbots. Tanto meno adoro sentire parlare in modo generico ed esoterico di “cognitive *”, ma non è il caso di andare per il sottile ora.

Bisognerà approfondire quali sono le relazioni tra prodotti e servizi privati e progetti per la cosa pubblica, che spero si attuino con progetti collaborativi, con opensource ed open-data (dal punto di vista dei contenuti), con modelli di profitto auspicabilmente open-business.

Invito il lettore a leggere una mia breve riflessione (ottobre 2016):

Istituzioni e intelligenza artificiale privataIn risposta a all’articolo di Monica Cainarca: https://medium.com/italia/intelligenza-artificiale-rischi-e17ea8eebe5f…convcomp.it

Ma è cosa straordinaria questa odierna “chiamata alle armi”: è il primo segnale, da parte del governo italiano, della volontà di attuare una “governance” sui reami dell’intelligenza artificiale (o presunta tale, approfondiremo e chiariremo bene).

Ci sono enormi applicazioni possibili a vantaggio dei cittadini. Nuove prospettive nell’economia del lavoro.

Anzitutto è necessario fare un lavoro culturale facendo grande chiarezza su qual’è lo spettro delle applicazioni AI. 
Troppo spesso si associa a questo termine tutto quello che ha a che vedere con la robotica meccatronica (per esempio i robot antropomorfi). Ultimamente sembra che ci sia una associazione uno a uno tra AI e veicoli autonomi. Oppure, fino all’anno scorso parlava di intelligenza artificiale solo in riferimento all’analisi di grandi quantità di dati. Intendiamoci, tutto ciò va bene, benissimo! Il data mining su big data (con machine learning) è solo una delle possibili applicazione di algoritmi (complessi) ma, come vecchio ingegnere (del software), ho difficoltà a chiamare tutto questo “intelligenza artificiale”. Poco importa.

Qui, in questo blog, ci interessano sopratutto le applicazioni conversazionali, ovvero sistemi software che comunicano con gli esseri umani (o altre macchine) in linguaggio naturale. Chiamiamo chatbots queste applicazioni, semplificando ma intendendoci.

Personalmente sono impegnato da tempo nello studio di conversational user experience design. Uno degli ambiti che necessita urgente ricerca (ed applicazione operativa) è quello della didattica, l’education e l’e-learning (penso a strumenti per i bambini e gli adolescenti, per esempio, o all’educazione o acculturamento di persone adulte).

E’ necessaria una task forse davvero, che metta insieme insegnati (ed esperti del “contenuto”), esperti di chatbots design, esperti linguaggio (non solo in termini di linguistica computazionale ma proprio in termini di educazione all’uso raffinato della lingua italiana). Ultimi ma non ultimi servono esperti di comunicazione, esperti di psicologia, scrittura creativa, umanisti, etc.

In questi ambiti applicativi, come ingegnere del software e sperimentatore di dialog flows design, spero di poter dar un mio modesto contributo a questa nascente iniziativa.

Partecipiamo numerosi ed affrettiamoci! Scadrà infatti il 21 aprile la possibilità di inviare la propria candidatura per partecipare alla task force.

As “serious” developers, marketers, startuppers, scientists or whatever, 
I think that

we should avoid to use the term “Artificial Intelligence” in chatbot develop realms!

At least nowadays, in 2017, and I explain why in few moments.

The funny statement by @Imdevloper goof about the ridiculous of many companies and people yapping about AI, maybe just because they use a machine-learning-based crowd-sourcing associative map algorithm.

No, please stop to claim your product is AI-based just because you are using intents/entities hash! Come on!

Do not misunderstand me, I have nothing against GREAT API.ai, WIT.ai platforms!❤️

Maybe I’m more perplex with similar followers/copy-catted engines that many startups are using for their chatbots products&services, some time even claiming to have self-made fantastic (and private). That’s often ridiculous!

🤔🤔😲🤐🤐🤐😒😒😒😲🤔😲🤐😒😲

Again, please note I fully respect above mentioned platforms, but please, we can not call all these kind of services or products: ARTIFICIAL INTELLIGENCE!

And yes, I admit, I naively associate in my mind the term AI with a view of a possible machine intelligence, and at least some sort of machine inference and reasoning ability, but that’s so hard to realize with nowadays software “technology” and eventually I become nervous when so much people out talk out of turn about AI.

There is no Artificial Intelligence in our today software, in planet Earth.

To rule or not to rule? A minor digression

Secondly that’s a sub-subject of the funny mentioned tweet: in #botdev realms rule-based engines seem evil or old-fashioned tech, at least among some gurus of esoteric (and often closed-source) “cognitive” technologies (never mind business strategies…).

In any case, there is also a lot of confusion of what rule-based means.

On one side some people use this term referring to chatbots where logic is hard-coded on a software application realized in traditional programming languages:

if (user say *) then
 ...
 if (user say *) then
  ...
  if (user say *) then
   ...
   if (user say *) then
    ...
    if (user say *) then
     ...
    end
   end
  end
 end 
end

Someone call “Pyramid of Doom” the nefarious effects of this approach.

See my inside about Alex Bunardzic speech at last #CBC16 event in 2016 https://convcomp.it/sullevento-chatbotconf-2016-di-vienna-23cde4b1b320 (sorry for Italian, but please read Alex slides/video).

And yes, as a long term dev-strategy, hard-coding dialog flow logic with standard code (Javascript, Ruby or any “trad” programming language you prefer) is not a suitable way to develop complex chatbots, for many reasons out of scope here, but just to mention few: difficult maintenance, no separation between dialog flow editing and back-end subsystems (but that’s could be also a pro, in case of super-high performance dumb-bots, as a payment system).

Even if I admit, nowday successful chatbots are realized with traditional code approach (as far as I know, one of my preferred and successful, Matty Mariansky’s Meekan, is a Python-based software).❤️

That said, in my mind when I think about a rule-based system I instead thing about an inference engine (maybe I’m old and come in my mind seventies expert systems), or more pragmatically I think about chatbot scripting languages&engines that allow to

design dialog flow with a script metalanguage❤️❤️❤️

BTW, My preferred example of such a system is grandfather ChatScript.

All in all, I invite all you, AI-experts, to review a bit all these big AI-statements, maybe trying to go back, with modesty, to “old-fashioned” decades of studies of natural language understanding (#NLProc).

You can not easily automatize semantics of a human-to-human (or human-to-bot or bot-to-bot) complex conversation with your start of the art ML-blackboxes.

But now,

let me go back reading my “Italian grammar for dummies” elementary school book…❤️

📚📚📚🤓🤓🤓📚📚📚🤓🤓🤓📚📚📚🤓

Yes, #bot2bot is an hot topic. There are here both business (monetization) and technical (API) open topics.

What is now prevalent is what I call server-centric model (with again both business/tech implications). Goshup pubsub proposal is in that way.

immo, the challenging / innovative realm is pure #p2p (w negotiation) #bot2bot paradigm and I’m especially interested in #NLAPI (Natural Language interchange bot communication)…
Incoming #bot2bot features are: automatic negotiation and introspection (a bot must report reasons why he delegated to a third party bots, and the bot to bot communication would be in pseudo-natural langauge)…

respect
giorgio

ciao Alex,
many good points here, thanks for your notes.

But I admit I’m perplex on the modern era of “serverless”, that I feel a bit as an hypocrisy.

For me serverless, in terms or an inter-computing architectural paradigm, really means “without a servers”, all in all serverless is in my mind, just a synonymous of “distributed computing” in a P2P desirable world :-)

Indeed we use now the term “serverless” just to point out the opposite model that I call instead “mainframe/ server-centric” ;-)

Again about big data and Saas for machine learning… I wrote my concerns many times, see here about crowdsourcing for NLProc ML (in chatbots Saas realms):

From AI-blackboxes to open standardsAnswering Marc Canter’s Facebook postchatbotsjournal.com

respect
giorgio

Il bell’aggiornamento appena pubblicato su questo stesso blog www.convcomp.it :

Messenger: un marzo ricco di novità per i bot developersIl 2 Marzo è stata una giornata piena di cambiamenti e novità per i chatbot developers: Facebook Messenger ha…medium.com

mi porta ad una riflessione generale (che prescinde da Facebook)🤔

Non è una novità il fatto che l’approccio di Facebook Messenger per lo sviluppo di chatbots sia il paradigma GUI (Graphical User Interface) piuttosto che quello CUI (Conversational User Interface).

Messenger Bots: Decision Trees vs WebviewsSince now we’re mostly past this obsession with natural language in bots, time to talk about another developer dilemma…medium.com

Messenger sta ricalcando sempre più il modello di successo di WeChat, dove i bots sono miniprograms, applicazioni web embedded dentro la chat. Si tratta di applicazioni visuali piuttosto semplici nel flusso di navigazione, spesso semplicemente menu-driven.

Non c’è niente di male nei menu-driven dumb bots!

Anzi, sono io stesso detrattore di paventata intelligenza artificiale conversazionale (spesso solo un discutibile machine learning di frasi d’intento), mentre sono uno fermo sostenitore dei bots transazionali, ovvero applicazioni (dumb workflow bots) che guidano l’utente a realizzare uno specifico business goal (una transazione di e-commerce, un qualsiasi pagamento, una rapida info, etc.).

Quindi ben venga la via frictionless di Facebook (frictionless rispetto una UX per utenti ora abituati a smanettare su una mobile app)!

Però…

questo modello di applicazione chatbot alla WeChat è secondo me debole nel lungo termine; mi pare essere piuttosto un modello di users retention, che forse un poco nasconde l’aspettativa disattesa (da parte di Facebook) di un esplosivo successo dei propri bots. Non è mica andata come sperato, però.

Ci sono alcuni punti che pongo all’attenzione del lettore: 
Perché i FB bots in verità non hanno “spaccato” fin da subito?

Perché FB ha deciso un low-profile nella proposta di bots che sono quasi apps e riportano l’utente ad una UX vecchia, con i menu ed il “push advertising”?

Perché M, il progetto di “intelligenza artificiale” conversazionale di FB, è tenuto piuttosto in stand-by? Pare che la super arma segreta, se non erro tenuta in beta test e disponibile solo in alcuni stati USA, non abbia mica entusiasmato (vedi polemiche di uso di humans-in-the-loop, ovvero operatori umani che rispondono alle conversazioni con gli utenti in vece della “AI-balckbox”).

Ora, in Italia, c’è da dire una cosa: l’applicazione chat che usa il 90% della popolazione è una ed una sola:

la grande massa di noi consumer italici, usa WhatsApp.

D’altro canto sappiamo tutti bene che WA non permette assolutamente la realizzazione di qualsiasi bot! E tutti i tentativi di fare applicazioni automatizzate sono state bannate da WhatsApp, vedi famoso caso brasiliano. Vedi:

Whatsapp and the NO-chatbots regulationHi Alfred! Interesting experience; thank for your report!medium.com

Chatbots o non chatbots, la grande maggioranza degli italiani usa WhatsApp per messaggiare su gruppi (più o meno assurdi, come quelli delle mamme e dei babbi dei bambini all’asilo, o più o meno futili come i gruppi dark-channels intra-aziendali)…che orrore!🤢

Noi nerd-fighetti no, noi usiamo Telegram! ma anche no; infatti i più snob come me hanno tolto WA dal telefono ed usano a malapena TG con un pò di malcelato fastidio nell’accendere il telefono all’uopo di leggere questo o quel channel o command based bot di gioco d’azzardo e/o porno… un agire zombie decerebrato… che miseria!🤢

Eppoi ha ragione Pavel Durov: le telefonate disturbano la concentrazione! 
E stare sempre attaccati al telefonino è da sfigati!

Ma infine, chi lo usa Messenger in Italia per chattare nel day by day? 
Ma lasciamo perdere un attimo i reami Facebook.🤷

Da tempo, e cioè da quando organizzai il primo evento italiano sul conversational computing, il 24 giugno 2016:

IL CONVERSATIONAL COMPUTING E LA RIVOLUZIONE DEI CHATBOT!Primo chatbots-day italiano sui sistemi di dialogo in linguaggio naturale ed il conversational commercemedium.com

penso che:

La rivoluzione dei chatbots è quella conversazionale!

Ne sono ancora convinto, forse ora ancora di più, in questo inizio 2017, privo di innovazione davvero eccitante. Ma è questione di medio termine (pochi anni); i segnali sono inequivocabili: stiamo andando verso sistemi ad interfaccia vocale sempre più pervasivi (per la massa, noi “consumatori”).

Ormai l’hashtag #voicefirst spopola, perché certamente i dispositivi di Amazon (vedi Echo/Alexa), Google (vedi Home/Actions), e asap LINE (vedi Clova), e chissà quali altri mainframe metabots vocali prenderanno campo. Il passo successivo saranno poi le TV interattive (streaming + videobots). Mi ci gioco le …🔮

Ma il punto non è l’interfaccia vocale.

Senz’altro ce la meneremo nei prossimi mesi con le tecnologie di riconoscimento dell’impronta vocale, one-to-one sentiment analysis, problemi etici di privacy e beffarde nuove rogne cyber-security, maledizioni ai padri padroni orwelliani e spioni ascoltatori di ogni risma che ci conosceranno meglio di nostra mamma! 😧

No, il punto non è tanto che la voce velocizza la comunicazione, che evita anche la “perdita di tempo” di scrivere sul telefonino i nostri bei testi (insulsi o pieni di contenuti che siano), il punto interessante è l’evoluzione del linguaggio di comunicazione tra uomo e macchina, e la comprensione del linguaggio (da parte di entrambi, la macchina e l’uomo).

Vincerà il Natural Language Understanding?

Facile a dirsi, NLU, ma difficile a farsi. Intuizione intelligente un corno! E’ da qualche decennio che la ricerca della linguistica computazionale ci si arrabatta con i migliori cervelli, ma i risultati mainstream non ci sono. Ce la meniamo ancora con il data mining sui corpora testuali. Contenti loro; io non ne sono troppo entusiasta di questa ricerca, vecchia e decrepita.🏰

I sistemi neurali, ora declinati in deep learning, tanto declamati dalle AI-startups (e da me così tanto amati che ci feci la mia tesi di laurea nel lontano 1999), non risolvono, ora nel 2017, nemmeno lontanamente un qualche problema di machine intelligence. Sbaglio? Dimostratemi il contrario, Ve ne prego!

Che ci fai ora con i sistemi generativi? Ci fai forse crowdsourcing machine learning, con big data di conversazioni e ci apprendi intenti ed entità, d’accordo! Ma poi?

Hai risolto il problema della comprensione semantica? Manco per niente. E le applicazioni pratiche? Sì, qualcosina, d’accordo, ma, ve ne prego, togliete la dicitura “intelligenza artificiale”!🙏🙏🙏🙏🙏

BTW, interessante lettura:

The Two Paths from Natural Language Processing to Artificial IntelligenceWhy isn’t Siri smarter? AI has accelerated in recent years, especially with deep learning, but current chatbots are an…medium.com

Lasciamo allora perdere il nuovo sub-simbolico che avanza. Che dire della buona vecchia via simbolica allora? Quella tanto disprezzata dagli odierni scienziati evangelisti della religione del “cognitive computing”?

A parte che ci andrei giù molto piano a parlare a destra e manca di scienze cognitive … ed andrebbero un pò più conosciuti (almeno per essere criticati a ragion veduta) i sistemi chatbots di natural language processing “tradizionale”, come per esempio il buon “vecchio” ChatScript, che anche se con un “semplici” approcci rule-based, se lo sono però posto il problema del fundamental meaning. Un qualche risultato di understanding e pragmatico forse lo ottengono, o no? 🙄

P.S. Qui dove sono i linguisti computazionali (italiani)?
Dormicchiano sogni di ricerca mai sovvenzionata? Tutti a casa?

Aiutatemi a capire, Vi prego!🙏🙏🤔🤔

Altri pensierini:

To web or not to web (in chatbots realms)?Hi Matt,medium.com

About VUI vs CUI (again)…Hi Shane,medium.com

About Decisione trees, VUI, CUI…Hi Mikhail and thanks for sharing your works, also with dissemination,events,etc. :-).medium.com

Except instead of dozens or hundreds of generals contractors to choose from in a locality you’re stuck with three (Amazon, Google, Apple) that do 98% of the business and a very long tail of the rest.

what will be the future of mentioned big players metabots, is not clear to me; for final users and bot-service makers there pros and cons (both business and tech side) of these star-centric architectures, where any third party vertical chatbots will pass through them.

metabots could not be mandatory the above model, where any chatbot will be to be integrated with a (short?) list of hubs.

An interesting alternative is a peer-to peer (= chatbot-to-chatbot) NL-API (Natural-Language APIs) integration/negotiation.

I think automatized machine-to.machine among chatbots is an incoming area of research (again, both business and tech) and please note, again, I don’t call this artificial intelligence; that’s just a possible new way of application programming interface (open standard) for chatbots integration.

Slack fitting in that category? Do you see them creating a preferential program for bot partners like they’ve somewhat done with giphy and SalesForce?

Yes, in a way. I’m not too up to date on recent Slack business developments (If I’m not wrong they recently agreed some sort of partnership/relationship with IBM too).

For sure Slack have the big merit to have been probably the first company, in tempore non suspecto, that proposed a great and complete third party chatbots integration ecosystem. Slack is an amazing example of chatbots in/for (team-work) groups! And I feel that chatbots in group-chats is again a still unexplored interesting application area (but that’s another story).

Yes, I agree with your points, especially I with your final statement (your Quora Q/A):

Do you need AI to be an “intelligent” virtual assistant? No. As before the AI craze very useful things can be done with plain old analysis and algorithms and many of those have been rebranded as AI.

I’ll never end to remark this possible hypocrisy of pseudo-artificial intelligence engines, often proposed here an there.

Great chatbot applications, now in 2017, are result of creative conversational design of exiting user experiences (made by human authors). 
I close parenthesis :)

Back to your article on Quora, I do not see a profound dichotomy between chatbots and assistants.

For me:

chatbot means a vast a category of software communicating with humans with an “agreed” talkative, spoken, natural language.

Broad definition, I admit. So, there is a thin boundary between a chatbot (as a vertical conversational application of some sort) and an assistant.

Maybe a possible (architectural & business) diversification is between (centralized) chatbot-hubs, inter-mediation frameworks (someone call these metabots); I’m referring to Amazon Alexa, Google Actions, Slack maybe, and new incoming players (see brand new LINE Clova devices);

Twitter https://twitter.com/johmaldes/status/836977861210877958

In all these cases, metabots act as a user all-in-one front-end assistants that dispatch requests, redirecting user to third party chatbots services/applications. Finally, in this possible incoming scenario, the chatbot, in my (tech/business) view, is any specific final application.

I don’t know if I added something useful here.
regards/giorgo

As far as I understand, convos, maybe acronym for Conversational Objects :-), are chatbots applications (made by Octane AI) to be embedded inside a web site.

That’s interesting, and by the way, that’s the exact opposite of WeChat mini-programs paradigm (to embed a web application inside a chat messaging app).

Both approaches have in common the idea that the web paradigm (GUI web UX) will survive, coexisting with full conversational man-machine interactions (text-based and voice-based). I feel that’s true now in 2017, but things will probably change very soon.

The big question, in my modest opinion, is now:

Does the web way(HTML/CSS and mobile apps = GUI), and the chatbot technology on top, are the medium for some years now ? 
Or we are going very fast with a pervasive full conversational user interfaces (CUI/VUI) ?

I feel we are going, faster than we think in these days, towards #voicefirst chatbots.

This is not a bad news for us, bot-makers or conversational computing engineers, because all in all, the real point is not the interface but the substance (let me say, once a time) the intelligence, usefulness and creativity of a smart bot application. 
Machine learning is not the point, 
interface media is not the point; 
amazing conversational user experiences for great services, that’s the point.

my two cents
giorgio

I believe that distinguishing rule-based engines from serious artificial intelligence systems is a wrong/misleading opposition, and I disagree too with the answers on the “tidy summary” link you mention.

So it depends on what you define with rule-based and serious artificial intelligence.

For me rule-based doesn’t means keywords matching (and so command-based bots), but it means an algorithm that process user utterance through a prededined set of rules, doing a intent guessing and meaning matching.

An example of a rule-based engine in this way is great opensource ChatScript, but following your statement:

serious artificial intelligence software, which analyzes your words in a more complex way to deduce what you really want — or better yet, what you really need.

ChatScript (that’s a famous rule-based chatbots engine), with his powerful natural language processing (NLP) pipeline, fit exactly the above mentioned description.

What I want to state here is that there is a too frequent but misleading antithesis between rule-based and mythical AI systems. In facts it appears to me that too often, people talk about AI, just referring to some sort of machine learning (for NLP) algorithms, but, in my opinion, in general, not all machine learning is artificial intelligence.

In facts, I admit:

I do not know what Artificial Intelligence means in 2017! And I suspect no one really knows…

With respect
giorgio

Ciao Giuseppe,

mi è piaciuto il tuo articolo! Hai riportato i fatti in modo veritiero ed equilibrato, ed hai avuto i coglioni di dire quello che non sento mai dire in Italia da quasi tutti quelli che dicono essere esperti di tecnologia e comunicazione. Sono sostanzialmente d’accordo con la tua analisi; ne accennai anch'io in un commento l’anno scorso:

Il teorema filosofico di anarchia e libertà dei fratelli DurovCiao Andrea e grazie del commento, che mi stuzzica due considerazioni ancora:medium.com

e prima qui:

La “diversità” di TelegramAggiorno qui mio articolo già pubblicato il 5 Dicembre 2015 con titolo Telegram vs Whatsapp ?, che ripropongo…medium.com

Solo il titolo del tuo articolo mi porta iniziale fraintendimento, perché riporta ad una contrapposizione geopolitica tra “Ovest” contro “Est”,

mentre la contrapposizione dei due modelli oggi è, come dici, tra neoliberismo dell’establishment e neoliberismo anarchico-individualista.

Ed in alternativa, dal “basso”, non c’è molto che vien su, purtroppo.

Venendo al pragmatico/tecnologico; ci sarebbe da approfondire (ti invito a farlo) a riguardo della psicologia di massa prevalente nell’utilizzatore di Facebook/WhatsApp e sdei ocial networks “gratuiti”.

Ora, tra i “detrattori” di whatsapp ci sono anch’io, insieme alla maggior parte dei nerd informatici, ca va sans dire, ma il fatto che Telegram sia “meglio “ è l’ultimo dei problemi!

Il problema è nella mancanza (in Italia) in una cultura su modelli collaborativi a cui solo accenni in fondo al tuo articolo. Io nel mio piccolo faccio per esempi questa “lotta”:

From AI-blackboxes to open standardsAnswering Marc Canter’s Facebook postchatbotsjournal.com

Grazie ancora per il tuo articolo.

Ti invito a seguire/scrivere sul blog della comunità italiana chatbots: www.convcomp2016.it

you provocatively :) ask:

There are a dozen ways to order a coffee. Why do dumb bots only allow one?

The short answer to your question is simple: 
it’s because these “dumb bots” are probably bad designed, probably hard-coded by software programmers (traditional computer language developers that realize bots with NodeJS/Python/etc.). 
SW Developers (and I’m a developer me too) don’t have the correct mindset to realize smart conversational experiences and probably they still practice wrong tools to build-up innovative, or simply smart conversational flows (see my old notes, e.g. [1], [2], [3], etc.). I explain better in a moment, but beforehand let me point out the your article contains great graphics and insights. Thanks.

Hi already commented Mikail’s (great) article, me too, and … I’m in the middle.

On one hand, I’m pretty sure that in near future chatbots will be done through a fully conversational UX (maybe without a Graphical User Interface but instead #voicefirst, with a prevalent voice-devices based interface, and, as chatbot developers,

we need to study & deepen the humans-to-humans usual language interaction behavioral patterns of common natural language understanding

BTW, that’s the reason of my comment above mentioned and my frustration with widgets, webviews and, in general, with what I call the click&point paradigma.

On the other hand, I do not like too much the RAN (Random Access Navigation) definition, because I associate it in my mind with stateless intent/entities extractors (with machine learning) , now excessively popular :-)

Viceversa, RAN is a real requirement if you mean a way to back the user to a (business application) contextual (work)flow, and, paradoxically, but please note, there is no so much AI on that,

RAN is simply a smart processing & memory of user conversational acts (within the business application)

respect
giorgio

Now, premising that I’m not an UI designer expert and I almost agree with your thoughts in this article, let me note just a specific point:
 
it seems to me (maybe i’m wrong) that your examples you oppose two different approaches:

• on one hand: “decision trees” (with a natural language processing UX) approach
• on the other hand: A old good standard GUI (“all at once”) web approach where user can edit many fields on a single graphical “widget”

So, we do not love decision trees maybe, but not any NLP chatbot (I mean just text processing, without graphics) necessarily behave with a decision tree UX; back to your booking example, let say the user want to change the departure date after, without restart the “flow”, as you said.
Here a smart NLP bot, just let the user to change an input field allowing to ask it in any moment with a request like :

change departure date

isn’t it ?

Anyway I admit the usual mantra: with a full conversational approach there are minus: sometimes input fields require sequential steps and info are more “implicits”; but that’s also a possible pro: by example a smart bot could remember data previously submitted by user, guess, etc.

The final pro of a conversational based, app flow design, is of course where chatbots will be also voicebots.

Thanks again
giorgio

Che questo sia in relazione con investimenti sin ambito AI, ho perplessità. Non mi trovo molto d’accordo con la definizione di intelligenza artificiale qui data:

Intelligenza Artificiale (IA), vale a dire le capacità di calcolo algoritmico e di risoluzione dei problemi da parte dei sistemi informatici utilizzati.

In generale non penso che siano i “big data” a essere la chiave (di svolta economica) e nutro dubbi sul fatto che Facebook e Google stiano davvero investendo risorse in ambito AI, come invece vuole la leggenda metropolitana :-)

Ricordo che Facebook “M” pare un progetto in stand-by (rumors, ammetto) e che Google stenta nella vision, con il progetto “Actions”, partorito solo da un mese, è vero, ma forse come mossa antagonista verso Amazon Alexa più che altro… Non ci vedo AI in nessuna di queste cose, ma una guerra commerciale all’acquisizione di dati e futuri clienti…

Invito ad ascoltare l’intervista a Ted Livingston in occasione dell’evento #talkabot qualche mese fà:

Il punto non è l’intelligenza artificialeOrmai, da qualche settimana, gli eventi dedicati ai chatbot e alle piattaforme di intelligenza artificiale a supporto…medium.com

Saluto
giorgio

I share here Marc’s comment:

I’ll leave it to Lauren Kunze to respond — vis a vis — AIML 2.x.
But what I CAN comment on is the tradeoffs between scripting languages and GUI/drag&drop GUI authoring approaches we’re seeing in the ChatBot marketplace.
On one side — clearly there is a great need for easily accessible Bot scripting environments — so that has led to the spread of these drag-and-drop interfaces. Clearly most people are not coders — but when was it written that ALL tasks need to be done by non-programmers?
Aren’t there situations where having programmatic control — is imperative and truly necessary?

Absolutely yes!

I hate to say this — but creating Bots — falls into that category!
On the other hand — one could debate the quality and flexibility of any given scripting language — and AIML and ChatScript seem to BOTH have plenty of the functionality required to create compelling Bot experiences. 
Evidence — Mitsuku’s continued success and life-like experience.

Yes, you are referring to Mitsuku, Steve Warswick’s chatbot creature.

True nature of Open Source aside — it seems to me that PandoraBots is the world’s leading ChatBot tool company and that Lauren Kunze is doing a kickass job with PandoraBots — and taking it to the next level!
Kudos to Lauren.
What I think is missing from this discussion — is the data.
Your AI is only as good as its data. Does it really make sense to build a ChatBot — in a matter of hours?

I agree. Nonsense, for me.

Cause that says to me — “it probably doesn’t have much data behind it…..”
ChatBots are NOT something you want to build — quickly.
Or said conversely — ChatBots built in a hurry — display the quality of — a ChatBot built in a hurry.

Naturally.

There IS a place for a scripting language in this equation.
There is EVEN a place for drag-and-drop interfaces.
But without quality and deep data — I just don’t see how any one ChatBot can deliver — a decent experience.

I can’t agree more with you Marc,

BTW, please note I have nothing against Pandorabots a part the fact I do not like AIML (and I state AIML 2.x is proprietary; but that’s a minor question); that said, I often read with pleasure Lauren’s blog articles I re-tweeted sometime via my twitter account :-)

Now, I am a developer, and I probably share with you the perplexity with no-coding tools.

Decoupling back-end from front-end

Talking about botdev, in terms of software engineering, it’s better to decouple competences (and tools):

• Front-end: 
  Beforehand there is the dialog flow design, realms of possible new profession: conversational designer: I imagine this role covered by a “writer”, a novelist, a screenwriter, an expert in interactive-fiction, any creative with natural language narrative, etc. He/she design by example the personality of the bot (#botpersona), with specific language for specific customer/user context, etc.
• Back-end: 
  On the other side there is the application business logic, realms of backend developers, that probably manage database interfaces, API with third party services, product/service components, etc. 
  It’s the usual standard way.

The reason I’m for chatbots scripting languages, is in order to decouple “frontend” from “backend” skills.

Now, I confess, I’m a console-based guy and I do not love drag-n-drop graphical tools, nowadays trendy, for a bunch of reasons:

• Whit these drug&drop stuff, as application developer, you become strictly-coupled with specific third party tools, and you do not own your conversational flow texts. So, I admit, I do not like Chatfuel-like and ALL OTHER SIMILAR webapps, last but not least IBM Watson Conversation, that I call (GUI-RAD) “AI-Blackboxes”.
• Viceversa, having your dialog flow as flat source files is an enormous value in the long term: you can edit/maintain easily your dialog flows, reusing all standard programming tools&paradigma (sharing code among authors, using git, etc. etc.). Even building your (machine) learning supervisor to update scripts ;-), etc. etc. etc.

A Common Chatbot Scripting Language

There is a third important plus, sharing need, among #botdev developers/makers. We need a COMMON high level language for chatbot programming/authoring, that have to be an open standard (and possibly an open source implementation).

It’s about to gain usual advantages of open source languages, that allowed pretty all modern step forward in computer science; let’s think about what have been last decades software engineering with programming languages like C/C++, or more recently with beloved Ruby, and all in all with all widespread programming languages.

That’s the reason why I try to support and share:

• ChatScript by Bruce Wilcox (v. 7.1 released few days ago)

See also similar sons/subsets/inspired-by, like great opensource works:

• RiveScript by Noah Petherbridge
• SuperScript by Rob Ellis (v. 1.0 released yesterday)

We need, in conversational engineering, a common metalanguage to develop next generation complex #botapps!

My articles about the topic:
this article is related to the previous one:

From AI-blackboxes to open standardsAnswering Marc Canter’s Facebook postmedium.com

About scripting, graphical drug&drop, development tools:

Decoupling business logic with dialog flow scriptingHi Matthias!medium.com

Conversational vs Transactional ChatbotsThanks Matthias for your answer! Generally speaking, I agree with you pheraps that not all chatbots are “conversational…medium.com

Bots builders: drag&drop, NLP or scripting?Hi Eva,medium.com

#botdev: GUI tools vs scripting languages ?Hi TY Wang! Thanks, you touched some good points!medium.com

Beside that, maybe surprisingly, even if I’m great fan of scripting (in the development of complex #botapps), I’m myself developing a framework in Ruby, to build chatbots to implement strict (“dumb”) workflow-based / transactional applications (payment gateways, simple e-commerce, booking, etc.), see:

Naif — Ruby micro framework to build dumb chat machinestalk, 15 December 2016 @ #MilanoChatbot Meetupmedium.com

Follow Giorgio Robino on Twitter: www.twitter.com/solyarisoftware

Hi Marc, I share some thoughts about your questions/doubts in your Facebook post. I wish to say that’s a pretext to point out my general criticism about what I call AI-blackboxes (in general and not referring specifically to API.ai).

I copied here your points:

Is anybody here using API.ai?
Somebody just told me that Google changed the price to Zero?
But my friend is concerned they’ll eventually shut it down?
Thoughts? Beliefs? Experience?
…
I always felt that API.ai was a Google hedge — to get them into the market quickly.
But hearing that API.ai is free — is encouraging. They apparently have interfaces to Alexa, Slack, Facebook et al

Beforehand, let me state that:

I really like Ilya Gelfenbeyn’s API.ai NLP approach

API.ai have been one of first platforms (few years ago) working in that approach: machine learning actions/entities extractions from (croudsourced) intents.

Afterward a plenty of startups followed very similar NLP (Natural Language Processing) approach to build “machine learning” chatbots engines. 
Just to mentions big players products/services very similar: many “AI” startups and big players as: Microsoft (with LUIS), Facebook (with acquired WIT.ai, very very similar to API.ai), Amazon (with Alexa/Lex), IBM (with Watson Conversation), etc. etc. etc.

Last but not least Google few months ago acquired API.ai that’s now a part of Google in Actions work in progress platform. BTW API.ai acquisition seems to me a workaround because probably Google actions/assistant strategy is still not fully defined (or simply technology is not ready to be published worldwide?), also in terms of commercial vision, whereas Alexa (by concurrent always growing Amazon) seems now winning with his #voicefirst device…

Now, what all above mentioned and similar platforms have in common?

1. Closed-source

These are proprietary products by (a short list of) big players: the source code is non published and even internal algorithms/behaviors are almost always fully obscure (Watson is a archetypal example of this closure, see my previous article: About IBM Watson-like systems).

I call these products(& services): “AI-blackboxes”

2. SaaS

SaaS (Software As As Service), the nowadays widespread cloud computing model, where your specific application client software call some external provider API (here for Application Programming Interface) to get some remote internet service from a server platform (in our case a NLP engine).

3. Pay per call

Pricing model is often something like: first N calls for free, with a successive “Let’s call” custom pricing or a old fashioned pay per usage (you pay X amount (thousandth of dollar) for each API call).

4. “Serverless”

Pretty all above mentioned players in new chatbots development realms, are beforehand cloud services providers companies, always looking for new customers. Serverless is a paradoxical buzzword here: cloud companies state to provide serverless services for mobile app (Android, iOS) developers and now for bots developers). That’s an Orwellian definition:

Serverless stands now for “mainframe paradigma”. Serverless instead would mean literally “distributed computing”!

I’m perplex regarding this trendy computing (and BUSINESS) model. I just mention two main points, without even mentioning to the huge ethics implications and concerns about privacy of data and people personal data collection & exploitation; forget it… let focus now in engineering aspects:

Server-centric or server-less?

The cloud server-centric model is not at all the definitive solution of all (chatbots) applications needs. 
There are plenty of incoming possible chatbots applications related to internet of things (let’s think to automotive, smart-home, HW embedded devices, etc.), where probably

distributed computing model will “be back”

All devices will talk to us, they talk each others (#bots2bots machine-to-machine is probably a real AI frontiers, more than the machine intelligence in the General-AI meaning) and maybe data will be eventually collected in could-based servers, but

I’m hoping for a man-machine peer-to-peer networking and not for pervasive server-centric client-server businesses.

The need of opensource and open standards (in AI)

Seriously, I can’t imagine any modern scientific, technical and even humanistic evolution without open-source, let’s think about what linux has become in operating systems realms, or open standards and open source programming languages has become in software engineering last decades!

BTW, I have been for long time a C language (open standard and open source) developer and I am a Ruby language developer and, talking about chatbots… I’m now also modest supporter of ChatScript, one of few open source established (but underrated) projects to build NLP/conversational applications).

Earlier this 2017, we are in a ridiculous infancy of NLP platforms, where each one want to sell at the highest price his magic blackbox.

Business is business, ok, and I also think brand new lambda functions will probably gain great success in the near years. 
Nevertheless, I feel that future (of human and machine intelligence) is in huge open source collaborations projects, where I would like to see big players (Google, Amazon, Apple, Facebook, etc.) to collaborate with a (new) open business models,

defining open standards and sharing (AI) algorithms.

To be specific (to chatbots development realms), I imagine a huge open standard (& open-source!) project to define a shared chatbot scripting language, possibly coupling human authoring and machine learning. Support of above mentioned (among others) companies in the direction of an open standard, will really change the games. In 2017 I will spend my little energy for that purpose.

Per diventare scrittrice o scrittore su questa pubblicazione medium, ti invitiamo a compilare questa form
Vedi anche qui.

Buon anno nuovo!

I was unaware of https://www.w3.org/TR/payment-request/ and I’ll read this w3c proposal; thanks again.

1. Payment Workflow: User — Merchant — Bank

What’s the reason behind having the merchant forwarding the request instead?

I know, this three actors handshake seems unusual, but in my opinion is fast and secure:

• User, during an online shopping checkout with the merchant chatbot, do not care about successive payments transaction details, but simply say:

pay smartbank

BTW, smartbank is a bank where user own an account (user@smartbank) and user associated one ore more chat apps account in the home banking settings.

• Merchant does the payment request , asking to the user bank with a backend protocol (https instant-payments API or in a future … a chatbot to chatbot transaction),
• Bank, after some verification (the user is really a customer of the bank, etc.) forward a confirmation back to the user and the user eventually confirm the payment.

This opens up to possibilities of a merchant showing a payment request to the customer and then submitting a different one to the payment provider imho

I see. I designed PayChat also for micro-payments (let say under 5$… and this is a possible killer application use case), and with an optional absence of confirmation (steps 4 and 5 in PayChat dotted lines in sequence diagram). 
In this scenario (no confirmation) a merchant fraud is possible, I admit, but with the explicit confirmation instead, the fraud is a long shot, because is the user that accept the incoming request (from the bank)
 
In my opinion is very important to reduce the friction in the online chat payment flow. Some backend strategies have to be set-up to limit possible frauds (e.g. user could define thresholds values in the home banking, or maybe a list of trusted merchants, or user could claim an error in payment with an end-of -the day procedure, etc. etc., TBD).

2. User identifier

IBAN. Most of the world does not have IBAN. The proposal should be reworked to work with a generic set of payment credentials…

Yes, mentioning IBAN in sequence diagram is measliding, because that’s the bank account ID used in Italy (Europe), and of course any other unique user bank account ID fit well, but please note this ID is not really involved in sketched flow: in my view, merchant payment transaction refer to the user identifier inside the chat app, by example, in my case, my username in Telegram Messenger is @solyarisoftware, the identifier that user, as bank customer, stored in his home banking profile.

3. final price

There must be a mechanism for the user to feedback on the first PaymentRequest so that — if necessary — the total amount can be recalculated (e.g. import taxes, shipment fees, conversion rates if the customer decides to pay in a different currency, …). You can look at the PaymentRequest proposal for inspiration.

You are right. I assumed that the payment flow start when the final price is defined. 
BTW, I think paypal is perfect for both

• standard physical goods online shopping from a remote merchant (involving shipment, taxes, currency calculations)
• but is perfect for “local trades” / proximity commerce, where, by example, users buy products and services from retailers / offline / in-stores.

See also a PayChat simplified sequence diagram at slide 36 here:

Naif — Ruby micro framework to build dumb chat machinestalk, 15 December 2016 @ #MilanoChatbot Meetupmedium.com

Please feel free to contact me also via email: giorgio.robino@gmail.com

Happy new year to you!
regards
Giorgio

Hi Eva,

About ChatFuel, is an example of what I call GUI-RAD #botdev tool. It seems to me like 90's graphical tools to make websites without coding. In true, nowadays, best websites are hand-crafted by front developers with (deep) knowledge of HTML5/CSS3 languages, isn’t it?
So ChatFuel-like tools are maybe perfect to build very simple “static” chatbots, like static websites instead of complex dynamic web apps, if you allow the comparison.

ChatFuel is free at the moment but probably will become with a fremium buisiness model, maybe.

BTW, personally, I’m not too much for chatbots As A Service (CAAS <-> SAAS) hosted in a cloud by a third party central cloud provider; last but not least there are behind, important data ( = conversations) privacy issues (let’s think about a commerce, banking, healthcare chatbots app).

About WIT.ai and similar NLP-intents extractors (as WIT.ai, API.ai, IBM Watson Conversation); here the problem is that these platform solve (very well sometime) the entities and actions from user intents, that’s perfect, but this is just a “minor” part of the chatbot build: the biggest part of develop, immo, is the conversational (work)flow, that i call the (conversational context) state management. As far as I see, all these tools are pretty stateless, forwarding the problem of statefullness to the application side (made by a developer that code the workflow and data management in a standard programming language, let say nodeJS or similar).

Personally I’m fan of scripting languages as Bruce Wilcox’s open-source: ChatScript, see my article:

How to build your first chatbot using ChatScriptChatbots can help you get things done right inside chat tools like Whatsapp and Slack. Just say the word and your…medium.freecodecamp.com

What is great with scripting language (for bot dev) is that the authoring develop is a “script” in a “simple” language for novelists, screeplayers, exactly in the way you pointed out in your previous article:

They are the story tellers, people who can convey a meaning with fewer words, the right words.
(source: https://chatbotsmagazine.com/bots-are-just-a-facade-here-is-the-real-problem-e69f80116d7c#.c5g3fbnud)

See also:

#botdev: GUI tools vs scripting languages ?Hi TY Wang! Thanks, you touched some good points!medium.com

Do you experienced ChatScript or similar? 
What do you think about?

regards
giorgio

Hi Mimi 
Yes, but I’m concerned about the usage of private AI-blackbox as IBM Watson, in medicine, healthcare and any analytics and decisions regarding people-privacy/private citizens life.

Generally speaking, there is a huge concern, nowadays maybe underrated, about incoming pervasive presence of artificial intelligence systems in our societies (IBM is along with Google, Amazon and few others big players).

Specifically, the problem I see with IBM Watson is that it is a closed product of a private company. There is nothing bad in a pure commercial product approach, but problems arise if this product become spread in public domains research, public services (universities, hospitals, etc.), when AI platforms/engines are private commercial products. That’s the point.

And secondly, technically speaking, is not clear to me (and some scientists I interviewed) Watson internals algorithms/functioning, because it’s fully closed; I call this AI-blackbox. That closure is bad, in my modest opinion. 
I admit, I’m also critic about big-data machine learning data mining and analytics algos, where there is not a clear way to introspect the “why” when the system made a decision regarding single cases that broke statistical approaches...

Nevertheless, I’m a huge fan of Big Blue, that have all the capacity and power to reverse this business model approach and I please ask IBM to open the doors to scientists community, possibly in the open-source direction.

BTW, I already wrote minor notes and trivial criticisms to IBM Conversation here: (sorry in Italian):

Whatsapp bots presto e… tante altre news!Nella mia veste qui di pseudo-giornalista, provo ad elencare alcuni recenti annunci ed accadimenti nel magico #botmondo…medium.com

Looking forward your feedback on that and of course I’d happy to share thioughts with Watson developers

Respect
giorgio

Maybe myself I prefer to use the term chatbot when a complex natural language interaction is a prevalent feature (the software interact just in natural language, via text or voice), whereas I use the concise term bot, meaning a software application running on a instant messenger chat app like Messenger, by example, where a textual dialog flow is not the predominant media (let’s think a “well done” Messenger bots, with webpage-like UI with photos/carousels/widgets/etc.)

Many people still use the ridiculous terms virtual/conversational agent meaning what you name chatbot.

Myself I call botpersona all these chatbots like Mitsuku, or all Wilcoxs’ characters (e.g. Rose, Susette, etc. and btw I’m a huge fan of ChatScript) or Pullstring characters (Humani, HelloBarbie, etc.). And of course Microsoft stuff like Tay (…), but for sure Xiaoice; I mean complex authoring chatbots (incidentally, often hand-crafted by human authors/screen players/novelists) able to entertain users in long conversations, fooling users to interact with a person (remember the “I,robot” movie holograma scenes?)

Video https://www.youtube.com/watch?v=RCj-gkbtvrw

BTW incidentally all mentioned bots are historically in entertainment realms;, but in my modest opinion great botpersona could be killer applications in business realms too.

On the other side, i distinguish botpersona from more simple business-bots for what you call business processes automation (Indeed I call these workflow-based or transactional bots). Maybe Ted Livengston (KIk CEO) could call them #noAI bots ;-). In this case, the bot are just the messaging way (chat app alternative alternative to the web paradigma) to achieve a business goal, following a maybe quickest interaction with poor NLP. BTW, I’m working on a tool to build this kind of dumb bots:

Naif — Ruby micro framework to build dumb chat machinestalk, 15 December 2016 @ #MilanoChatbot Meetupmedium.com

Last but not least, another fully abused term is Artificial Intelligence. Arghhh :-) but this is another big misunderstanding and another story

respect
giorgio

Hi Hamza!

I agree with your analysis regarding privacy and myself too, as chatbots researcher and developer, I’m concerned on “artificial intelligence” centralized black-boxes that big players push now (btw, IBM Watson is another monolith to add to the “black” list). Joking ;-)

The good news, in my modest opinion, is that cloud-based chatbots services idiom that now seem prevalent, is NOT the only one possible.

I’m unhappy with this idea that any “machine intelligence” (specifically in this case of chatbots: natural language understanding engines or any other machine learning facility) must owned by proprietary “pay-per-service”.

By example, I immagine in a future, a net of distributed chatbots (sometime interconnected in a collaborative mesh network, sometime isolated in a one-to-one relationship among users and a single chatbot services), without passing through any “central engine” (that possibly could collect any conversation, so any users data).

In that way I’m interested on AI “democratization” that pass through open-source (dev/data) projects. And specifically that’s the reason I do my small contribute helping Bruce Wilcox’s ChatScript project :)

But also in this scenario privacy concerns on the “channel” (instant messaging app or a smart-home voice-device), still remain.

Wire is promising regarding this requirement, but also Telegram Messenger appears to me to already respect the same user privacy “ideology”.

What do you think about it ?

respect
giorgio

Nel mondo del marketing ideale niente sarebbe più desiderabile che poter inviare il messaggio giusto, al momento giusto, all’utente che è in cerca di qualcosa su una specifica pagina internet: questo è quello che però, nel mondo reale, è in grado di fare un trigger.
Questo tipo di obiettivo richiede una profonda conoscenza del comportamento degli utenti e la capacità di costruire campagne marketing che si adattino perfettamente alle loro esigenze.

In realtà esiste già un modo per fare questo, ed è l’utilizzo dei triggers.

Ma che cos’è un trigger e come funziona?

Un trigger è, tecnicamente, un evento che si scatena al verificarsi di una determinata condizione che tenga conto di tre fattori principali: tempo, luogo e sequenza.

Dato che si tratta di uno strumento informatico, per tempo intenderemo il tempo di permanenza dell’utente, per luogo la pagina specifica su cui l’utente si trova, per sequenza, invece, il susseguirsi di azioni specifiche che l’utente compie in una determinata pagina ed in un determinato arco di tempo.

In realtà, il fattore tempo può essere soggetto ad infinite variabili: è infatti possibile che un trigger specifico scatti non soltanto perché un utente è rimasto su una pagina, ad esempio, per un arco di tempo superiore ai 20 secondi, ma anche perché oltre ad aver superato il tempo minimo richiesto per la sua attivazione, l’utente ha visitato quella pagina specifica in un determinato arco temporale all’interno di una giornata oppure proprio in una giornata specifica, come ad esempio il giorno di Natale, il giorno del ringraziamento, il Black Friday o l’Epifania.

Che cosa può fare un trigger nello specifico?

Un trigger può aprire una finestra di dialogo in cui è possibile inserire un vasto numero di contenuti: dal testo alle immagini, dai link esterni ai video, è possibile davvero sbizzarrirsi con la fantasia per scegliere cosa mostrare agli utenti in modo da convertirli in clienti aumentando il livello di engagement.
– mostrare offerte relative agli articoli
– suggerire approfondimenti sul post di un blog
– redirect a pagine correlate
– approfondire argomenti trattati nella pagina
– chiedere l’iscrizione alla newsletter agli utenti
– chiedere la compilazione di un contact form
– attivarsi durante una conversazione a seguito di una specifica domanda

In che modo è possibile sfruttare al meglio un trigger?

1. Come saluto iniziale agli utenti.

Iniziamo dall’uso più comune che si può fare del trigger, ovvero il saluto automatico.
Questo tipo di trigger è il più semplice da implementare ma è comunque una formula testata e comprovata per aumentare le conversioni.
Adattare i messaggi alle esigenze dei potenziali clienti è uno dei modi migliori per far si che aumenti il livello di curiosità sul prodotto.

2. Come strumento di coinvolgimento dei clienti durante la fase di processo decisionale.

I saluti iniziali sono un buon inizio, ma ci sono modi più efficaci di coinvolgere i clienti.
La chiave per creare i trigger più efficaci è conoscere e comprendere il comportamento dei proprio clienti: ad esempio, se un utente spende molto tempo su una sola pagina del sito, c’è la possibilità che qualcosa non sia chiaro o che, invece, l’argomento lo interessi molto e sia propenso alla conversione.

Siamo in grado di utilizzare queste informazioni per configurare dei triggers contenenti messaggi su misura che coinvolgano i clienti a seconda della pagina di permanenza, per chiarire dubbi o aiutare la conversione.

Controllando, ad esempio, che il visitatore sia sulla pagina di un prodotto specifico per più di 30 secondi e interpretando questo dato come la ricerca di ulteriori informazioni e una dimostrazione di interesse, potrebbe aprirsi la chat con un trigger che fornisca le informazioni necessarie per indurre all’acquisto.

3. Come equivalente digitale del volantino.

Immaginate qualcuno che arrivi nel vostro negozio con in mano un volantino delle promozioni e offerte: il trigger può essere proprio l’equivalente digitale del volantino.

I trigger possono essere utilizzati anche per tracciare i clienti che arrivano su un sito specifico tramite la ricerca a pagamento o anche organica, ad esempio utilizzando uno strumento come Piwik.
Questo richiederebbe una impostazione particolare ma che vale sicuramente la pena avere.
Sapere, infatti, cosa gli utenti hanno visto prima di scegliere di arrivare su un sito aiuta a personalizzare l’approccio verso il cliente stesso.

Per implementare questo trigger è necessario identificare gli utenti in arrivo tramite degli URL con UTM, quindi con alta tracciabilità, che permettano di verificare la sorgente del traffico. Un esempio di questo tipo di tracciamento può essere quello messo in atto da Google Adwords: tutte le visite provenienti da Adwords hanno infatti una sorgente di provenienza definita.

4. Soddisfare le richieste degli utenti.

Se avete già molto traffico sul vostro sito e consequenzialmente un alto numero di richieste e di chat attive, il miglior metodo di copertura sarebbe quello di associare alla live chat una chatbot in grado di gestire autonomamente le richieste più semplici e comuni, ovvero le cosiddette FAQ, degli utenti.
Proprio nella chatbot è infatti possibile impostare un set di trigger che rispondano ad alcune delle domande basilari che gli utenti solitamente pongono. In questo modo il il trigger verrebbe percepito dall’utente come un alto livello di personalizzazione dell’interazione che sta avendo con l’azienda, e quindi come uno strumento valido di Customer Acquisition.
Qualunque sia l’uso pratico che si sceglie di fare del trigger, lo scopo finale rimarrà sempre colpire l’utente e convertirlo in cliente. E, se di cliente già si tratta, aumentare la sua fidelizzazione al brand nel tempo.
Sono effettivamente infiniti gli usi che è possibile impostare dei trigger, limitati solo dalla creatività del singolo e dalla sua voglia di sperimentare.
La chatbot di Awhy include i trigger tra le sue funzionalità principali: come strumento di marketing è infatti in grado di coinvolgere l’utente in una esperienza a 360 gradi all’interno del sito.

Vuoi provare i triggers e le loro molteplici funzioni? Prova Awhy.

Roberta Gallo

15 agosto — IBM Watson Conversation

Sorprendentemente, IBM in agosto dichiara “discontinued” il prodotto: Dialog, il modulo di IBM Watson dedicato alle applicazioni conversazionali

Script conversations any way you like to answer questions, walk through processes, or just to chat! Note: The Dialog service is deprecated as of August 15, 2016. See its documentation for more information.

annunciando subito il prodotto sostitutivo: Conversation, il servizio che ora IBM propone per lo sviluppo di bots. Nella pagina Dialog overview vengono introdotti i concetti del nuovo sistema.

mie note:
Dialog, per chi non lo sapesse, funzionava come un linguaggio di scripting, del tipo che io chiamo XML-like, ovvero con una sintassi simile all’AIML. Lo confesso: non mi piaceva la sintassi, inadatta ad un non-programmatore, cioè alla persona “autrice” di una applicazione di dialogo, cioè chi costruisce il dialog flow, ovvero una scrittrice, uno sceneggiatore, una psicologa, una persona esperta di narrative fiction, etc.

Conversation, invece, non è programmabile attraverso un linguaggio di scripting (per quel che mi è dato di sapere leggendo la documentazione sopra), ma presenta un GUI dialog builder del tipo che io chiamo “lego-bricks”, dove cioè lo sviluppatore disegna il flusso conversazionale attraverso un’interfaccia grafica click-and-point, congiungendo blocchi (bricks). Per dettagli, vedi documentazione.

La mia prima impressione è che Conversation (così come in precedenza è stato Dialog), sia una tecnologia ancora non ben consolidata…che assembla senz'altro buone idee (la gestione di regole, un linguaggio di query, etc.), ma perde, secondo me, l’occasione mancata di sviluppare un linguaggio di scripting innovativo ed universale, che io immaginerei essere una evoluzione/semplificazione di ChatScript, il sistema opensource inventato da Bruce Wilcox (che un pochino io supporto nel rework documentale su github).

Invece Conversation sembra conformarsi ad un modello di programmazione GUI simile ad API.ai, WIT.ai e molti simili RAD che nascono come funghi negli ultimi mesi.

Ora, capisco da un lato l’idea di “semplificare” il disegno di un dialogo attraverso l’uso di un’interfaccia web adatta a non programmatori, ma questo goal non è raggiunto perché in realtà lo sviluppo software con Conversation richiede una integrazione stretta con gli strumenti di programmazione trad (un linguaggio di programmazione, per esempio NodeJS o Python, etc., JSON per il passaggio dei dati, etc.). Personalmente non mi piace molto questo approccio “ibrido”, che divide la glue-programmazione in vari paradigmi, da un lato la logica conversazionale stateless, disegnata con uno strumento ad interfaccia grafica ad hoc, dall’altro la gestione del contesto, la logica di back-end e la gestione dello stato, da scrivere con un usuale linguaggio di programmazione. 
JSON come se piovesse. No comment sul modello di pricing.

La mia speranza è che IBM torni ad essere leader tecnologico nell'ambito dell’apertura all’open-source e non nella proposta di AI-blackboxes. 
In quel caso, mi piacerebbe collaborare alla costituzione di un tavolo di lavoro comune ad aziende e dipartimenti di ricerca per la definizione di un linguaggio di dialog scripting condiviso, e mi rivolgo senz'altro ad IBM come uno degli interlocutori che mi piacerebbe vedere tra i protagonisti e co-proponenti!

P.S. domani e dopodomani ci sarà a San Francisco l’evento Watson Developer Conference.

4 ottobre — Actions on Google

Con mia sorpresa, non ha avuto troppo seguito l’evento #madebygoogle del 4 novembre. A me ha colpito l’intervento di Scott Hufman, che ha presentato la tecnologia Actions. Tutto l’ecosistema API SDK probabilmente sarà reso pubblico entro dicembre 2016, insieme al lancio del dispositivo Google Home (il dispositivo ad interfaccia vocale, “rivale” di Amazon Echo).

mie note:
Il possibile successo di Google Allo è ancora un enorme punto interrogativo.

Il software Assistant, perfetta spia delle conversazioni chat di ogni utente, potrebbe diventare di default indispensabile per tutti, così come oggi lo è per quasi tutti noi “googlare” per cercare ogni info sul web,

ma potrebbe anche essere un grande flop, se nella percezione psicologica delle persone venisse mal tollerato il fatto che tutte le conversazioni saranno supervisionate da un suggeritore virtuale che tutto sa di noi…

E notino, lor signori, che una cosa è chattare con molteplici butler-chatbots che ci forniscono servizi one-to-one,altra cosa è avere un unico master bot (mi riferisco a Google Assistant dentro Allo, così come ad Amazon Alexa…) che re-interpreta ogni nostra azione, suggerendoci cosa dire, cosa fare… magari ridirigendoci secondo logiche non trasparenti (#noIntrospection)…

E’ un punto aperto questo, molto delicato negli impatti sociali, in termini di democrazia, a cui ho giò accennato riflettendo sulle esternazioni di Ted Livingston all'evento #talkabot.

Dunque, anche se l’annuncio di Huffman appare, ad un orecchio distratto, solo un elenco di annunci di cose meravigliose che saranno in futuro, in realtà delinea “pacatamente” una strategia tecnologica che potrà essere molto pervasiva nelle conseguenze dell’economia. Le “actions”, forse in qualche modo paragonabili agli Alexa skills (la tecnologia software sottostante Amazon Echo, per l’integrazione di applicazioni conversazionali business terze parti), sono lo strumento con cui Google probabilmente farà profitto con il local business… e la “foundation” è ovviamente il motore di ricerca, il knowledge graph, ovvero il tutto, tutti noi. 
Stay tuned! Ma anche: stay con mutande di ghisa!

1 novembre 2016 — Whatsapp bots?

La notizia forte, per noi italiani tutti, bot-developers, startuppari, aziende piccine o multinazionali, è l’annuncio esplicito della integrazione di una piattaforma bots anche su Whatsapp. Le parole sono quelle del creatore di Facebook, durante il report meeting dell’ultimo trimestre 2016,

Ed ecco quanto ha affermato Mark Zuckerberg ed una deduzione sulle tempistiche, del giornalista Alex Heath, e cioè di un possibile rilascio di API per Whatsapp in occasione dell’evento #FBF8, in primavera 2017:

mie note:
L’annuncio di Zuckerberg è solo un accenno alla integrazione (rispetto alla piattaforma bots) di FB con WA, nel 2017, ma è avvalorata anche da un annuncio comparso in agosto nel blog di WA:

https://blog.whatsapp.com/10000627/WhatsApp-guarda-avanti

Azzardo quindi addirittura un mio personale pronostico: l’Italia sarà possibile beta test country per la zona EMEA, e forse il Brasile per il Sud America.
Magari mi sbaglio ma se tanto mi dà tanto…

Ora, sebbene io sia un sostenitore della “ideologia” e della tecnologia di Telegram Messenger, che, attraverso una piattaforma molto aperta, permette di sviluppare applicazioni conversazionali non-solo-business e quindi perfetta per esempio per applicazioni sociali, etc. etc. Diciamocela tutta: 
In Italia il 90% (o poco meno?) della popolazione chattante usa Whatsapp e quindi, a mio avviso l’esplosione di una #boteconomy, che credo darà linfa ad una economia del nostro territorio (in particolare penso ad un ecosistema #convcomm, per la vendita di prodotti e servizi di “prossimità”), esploderà solo quando sarà possible sviluppare bots sulla piattaforma che la maggior parte degli italiani (non io), hanno installato sul proprio cellulare ed usano per gli usi più deprecabili. Quindi? Benvengano asap i chatbots su Whatsapp. Mi voglio sbilanciare con lo slogan: W Whatsapp e la #boteconomy italiana!

Twitter —Welcome Messages and Quick Replies

1 novembre. Twitter lancia in beta il nuovo servizio, che, decidete voi come chiamarlo, per me è “la nuova bot platform di Twitter”.
In sostanza Twitter propone un sistema di bots dedicato alle aziende, in particolare al customer care. Sono ad oggi attivi prototipi online per un pò di grandi aziende e… per esempio il bot @gov che fornisce informazioni sulle odierne votazioni in USA:

Twitter https://twitter.com/solyarisoftware/status/795398703439867904

Voilà un esempio di conversazione di tipo customer care:

8 novembre 2016 — Messenger Platform v1.3

Ma torniamo a Facebook con una notizia fresca di giornata: Messenger ha rilasciato oggi, anticipando di 1 mese quanto annunciato Mikhail Larionov all’evento #cbc16. 
L’aggiornamento prevede utili UI widget e una tecnologia pagamento (chiamata tokenization) per integrazione payment provider terze parti (cioè Paypal e Stripe a parte), per dettagli, vi invito a vedere il talk di Mikhail Larionov all’evento #cbc16:

Twitter https://twitter.com/solyarisoftware/status/794514796729303041

Notizia di poche ore fa, annunciata prima da David Markus e poi da Mikail:

Introducing Messenger Platform 1.3For the first time ever, businesses can drive targeted audiences to Messenger and keep them engaged with new tools…messengerblog.com

Introducing Messenger Platform v1.3 and New Ways to Drive the Conversation - Facebook for…Today, we're announcing new features and improvements to the Messenger Platform that developers have been asking for…developers.facebook.com

E Microsoft? E Telegram? E Slack?

Ci sono alcune cose che bollono in pentola, in Microsoft (che ha appena rilasciato Teams, il “concorrente” di Slack), Telegram, tra gli altri, ed ecco qui… ma no!Invece che parlarvi di rumors, aspettiamo qualche conferma!

Last but not least, se posso permettermi una piccola pubblicità personale: sto preparando, nel tempo libero, codice e le slides di un mio giochino #botdev #opensource:

Ci vediamo il 15 dicembre a Milano? 😊
Stay tuned!
giorgio

Le chatbots determineranno un forte cambiamento anche nella gestione delle comunicazioni interne degli enti sia pubblici che privati.
Nel corso dei prossimi decenni la maggior parte delle comunicazioni interne cartacee utilizzate nelle scuole, negli uffici e in qualunque altra struttura pubblica o privata, verranno sostituite da quelle elettroniche.
In alcuni casi si prediligerà l’invio delle email, in altri l’utilizzo della rete intranet ma, in entrambi i casi, c’è il rischio che questi messaggi non ricevano la stessa attenzione dei loro antenati cartacei.

Secondo la ricerca fatta dal Radicati Group , un dipendente riceve in media 88 email al giorno e per alcune aziende questa cifra aumenta addirittura del 20%.

Il problema del ricevere un così alto numero di email è relativo alla possibilità che ha il ricevente di stabilire quanto sia effettivamente importante la singola mail in un flusso così nutrito: è infatti probabile che, in questa situazione, una email venga smarrita tra le altre, non arrivando nemmeno ad essere aperta dal destinatario.

Nel tentativo di ridurre le email, molte aziende si sono attrezzate per spostare i flussi di comunicazione sulla rete intranet. Tuttavia la maggior parte delle reti intranet non sono abbastanza efficienti per la risoluzione delle situazioni critiche che possono presentarsi ai dipendenti quotidianamente.
Ciò avviene perché, a meno che non si tratti di situazioni di emergenza, è possibile che i dipendenti non accedano a questa rete per giorni, fino al punto in cui non gli è necessario farlo ma non rendendosi disponibili per eventuali risposte da fornire ai loro colleghi.

I social network aziendali sono spesso utilizzati per ovviare al problema delle email: tenere il passo con gli aggiornamenti di Slack o Yammer è possibile se si ha un team di lavoro molto ristretto, di 15 o 20 membri al massimo, ma questi strumenti non possono funzionare come mezzo di comunicazione con un’azienda da centinaia di dipendenti perché diverrebbe impossibile essere costantemente aggiornati sulle comunicazioni scritte da tutti gli utenti.

Perché le chatbots possono fare la differenza?

Partiamo dal principio: la chatbot è un software che comunica con gli utenti tramite servizi di messaggistica istantanea, quali quelle presenti su Facebook, Skype o altre piattaforme di comunicazione.
La caratteristica delle chat dotate di bot di assistenza è quella di definirsi sia come strumento di comunicazione tra di individui che, allo stesso tempo, come strumento di promemoria.

Ma quali sono i motivi principali per cui le chat dovrebbero subentrare all’utilizzo delle email e della rete intranet nelle comunicazioni aziendali?

1.Tutti i dipendenti sanno come utilizzare le applicazioni di messaggistica.

Le prime 4 applicazioni di messaggistica più utilizzate hanno più di 3 miliardi di utenti mensili attivi. Avete letto bene, 3 miliardi, il che vuol dire più degli utenti di Facebook, YouTube, Twitter e Linkedin combinati. È persino più del numero di utenti che utilizzano la posta elettronica a livello mondiale.

2. Le chatbots possono raggiungere anche i dipendenti che non hanno accesso alle email o al compuer.

Vi è stata una lotta portata avanti per anni per far si che la comunicazione si digitalizzasse in cinque settori specifici: sanitario, alberghiero, industriale, logistico e di vendita al dettaglio. La maggior parte dei lavoratori di questi settori, infatti, non ha tempo né modo di sedersi al computer e leggere le mail.

Il cambiamento epocale si è verificato quasi interamente negli ultimi tre anni: è infatti in quest’arco di tempo che gli smartphone si sono diffusi in proporzioni incredibili.

3. Le chatbots sono strumenti di comunicazione sia interna che esterna.

Le chatbots possono fare da veicolo per comunicazioni sia esterne che interne. Ad esempio, i dipendenti possono richiedere dei messaggi predefiniti su richiesta inserendo semplici comandi come “attività del giorno” o “appuntamenti della settimana” e la chatbot sarà in grado di fornire l’elenco di attività di riferimento.
Questa flessibilità permette di rispondere all’esigenza di ottenere comunicazioni che siano indipendenti dall’intervento di terzi, veloci e altamente funzionali.

4. Velocità di lettura.

I messaggi inviati tramite chatbot sono facili da leggere, brevi e concisi. Questo tipo di comunicazione, semplicemente, non supporta la prolissità e costringe ad esprimersi in modo sintetico.

5.Velocità di scrittura.

I messaggi brevi non sono solo più facili da leggere, ma ovviamente anche da scrivere. Ogni qual volta si deve scrivere un articolo per un blog, ciò richiede tempo e un notevole sforzo mentale. Una chat non richiede nulla di simile: si tratta spesso di una singola frase o di poche parole che comunichino solo quanto è strettamente necessario.

Da questo punto di vista è molto interessante il funzionamento della chatbot della CNN: questa è, infatti, in grado di condensare articoli lunghissimi in un massimo di 50 battute.

6. Non sono necessari procedimenti d’accesso.

Per accedere alla rete Intranet di un’azienda, il dipendente deve inizialmente installare un software VPN, richiedere l’accesso a quel software, ottenere un ID, registrare il proprio telefono cellulare, digitare un codice di autorizzazione e, una volta avviato il browser, inserire l’indirizzo web di riferimento.

Riuscite ad immaginare quanto tempo un dipendente possa perdere nel compiere tutti questi passaggi semplicemente per controllare se ci sono nuovi messaggi di comunicazione interna?

A differenza di una rete intranet non vi è alcuna necessità di effettuare un login per usare una chatbot. I servizi di messaggistica sanno chi sei e con chi condividi le tue informazione. Non serve fare nulla di aggiuntivo al lanciare l’app stessa per leggere i messaggi ricevuti ed inviarne di nuovi.

Queste sono le semplici ragioni per le quali il modo con cui avverranno le comunicazioni nel mondo del lavoro potranno finalmente cambiare.
E voi siete al passo con il cambiamento?

Roberta Gallo

In the context of CodeMOOC, a massive open online course offered by the University of Urbino about computational thinking and coding, a large-scale coding quiz was planned for 20 October. Using only a Telegram client and a QR Code scanner, the participants were able to take part in the game and compete with over 900 groups in Italy.

Participants did register to a Telegram channel where they would receive instructions before the start of the game. At the start of the game, we handed out the link to a live Youtube stream, where further instructions and quiz questions were given out.

For each coding quiz, the Telegram bot coordinating the event wrote a special link to the channel conversation, that would redirect users to the voting conversation using Telegram’s deep link feature. Since each quiz had a unique identifier, the deep link would not only transfer the user to the bot, but also send out a hidden command.

/start IY4

(Where IY4 is the hidden code for the 4th quiz question.)

Participants could also access the voting process by scanning a QR Code, containing the same deep link.

Once invoked, the bot did ask for an answer from the user.
As soon as the question was closed from our side (by simply providing the correct answer to the bot through a private chat), the bot did rank all correct answers by their timestamp and signal the results on the channel. The first 3 correct answers were publicly acknowledged with various, priceless, emoji medals. 🥇

Message processing

A total of 974 participants (in terms of Telegram users) took part in the event. Since each person could register for a group of people (acting like a team leader), a total number of 9689 people were involved with the game.
14 questions were asked, collecting a total of 7004 responses by participants, over approximately one hour and a half.

In other words: a lot of messages were sent to our bot over a short amount of time.

Telegram supports two modes of fetching incoming messages: pull and push.

Pull mode

In pull mode, your bot server periodically connects to a Telegram end-point and downloads part of the messages queued up for delivery. The delivery mechanism can be customized, for instance downloading a batch of messages in a single call and using long-polling to stall the request until some data can be returned.

In theory, the pull method ensures higher efficiency: requests are sent out by your server, they can be controlled easily, and large batches of messages can be returned in a single HTTP data transfer.

However, pull operations are synchronized by nature. The Telegram API disallows multiple parallel requests (since, of course, the pull request operates sequentially on the delivery queue).
While transferring one single large payload and performing one single JSON decode step may be more efficient, in pull mode you are indeed increasing the average response time of each message.
Moreover, after the download phase, data parallelism is entirely up to the developer. Handing off message handling to different threads can be more or less easy, depending on your development framework: in Go a goroutine can be dispatched for each message, while the same can be done for async tasks on any .NET language.

Pull mode synchronizes data transfer and makes parallel message processing harder for the developer.

Push mode

This mode — which incidentally is the only mode of operation of many other messaging platforms — trades off the single, efficient data transfer step for multiple parallel message handling operations.

Instead of waiting for your server to fetch messages, updates are pushed to your bot’s web server to an URL of your choice (Telegram requires HTTPS, a domain name, and a certificate). Instead of having to deal with parallelism, this mode exploits the inherent strong points of a web server: dealing with multiple incoming connections and handling them off efficiently to your code.

Your web server was born for this.

Results

Based on our logs, 7.414.458 messages where sent to the bot through Telegram, in little over 80 minutes of operation.

Initially, the bot was configured to operate via pull mode and synchronous message handling, since this mode allows for far easier debugging and development. However, as soon as the event did start, we quickly discovered that the queue of messages was growing uncontrollably and the bot simply could not keep up.
We quickly switched over to push mode. Over the course of a couple of minutes the bot was able to catch up and performed very responsively for the rest of the event.

The bot was running on a quad-core machine clocked at 2.6 GHz, with 2 GBs of RAM.

In conclusion, pull mode is perfectly suited for bot development, since it allows developers to control the flow of messages and to carefully debug the code. Implementing an efficient message handling method via pull mode, however, probably isn’t worth the development effort. As suggested by others, it is far easier to entrust the web server with handling parallel requests on your behalf.

More generally — and this is very important in the context of the recent focus on bots as a replacement of apps — using a bot instead of a web site (for instance) gave us a very important advantage. The messaging platform, Telegram in this case, acts as an extremely scalable load balancer in front of your service. It handles message queuing, retrying, delivery, and push notifications — essentially Telegram offers an incredible amount of complex infrastructure for free. This allows you to focus on actual service development instead of having to worry about the plumbing.

The messaging platform is a large part of your service’s infrastructure and it does a lot of work on your behalf.

So, thank you, Telegram. 🙏

This Europe Code Week event has been a good opportunity to appreciate the effects of an unusual load (for our scale of development) on our bot. Further similar events will be planned in the near future and we look forward to evaluating performance and scaling issues in deeper detail.

The code used during the event is available on Github.

This post was first published on the blog of the Applied Computer Science course at the University of Urbino.

between the lines of a Whatsapp official blog post published in Italian Whatsapp blog web page last 25 Aug 2016:

Looking ahead for WhatsAppToday, we're updating WhatsApp's terms and privacy policy for the first time in four years, as part of our plans to…blog.whatsapp.com

It seems to me that they will offer some business chatbots APIs by the end of the year… so just a rumor right now; any spoilers ? ;-)

BTW, maybe your article could be updated because this yesterday news:

Twitter https://twitter.com/solyarisoftware/status/793831819019825152

Thanks & regards
giorgio

Ormai, da qualche settimana, gli eventi dedicati ai chatbot e alle piattaforme di intelligenza artificiale a supporto, sono un susseguirsi tumultuoso. Quello degli eventi su queste tematiche (chatbot soprattutto, ma anche machine learning e in genere AI), è ormai diventato un business redditizio per gli organizzatori!

BTW, il primo evento italiano su questi temi è stato #convcomp2016, che inventai e realizzai assieme a Giuditta Del Buono. La conferenza del 24 Giugno a Milano, fu gratuita e aperta a tutti :-)

Talkabot, la conferenza di Austin

Oggi vorrei parlarvi dell’evento #talkabot, conferenza di 3 giorni avvenuta ad Austin (TX) dal 27 al 29 Settembre. Alcuni giornalisti ed esperti hanno scritto molto e vi invito in particolare a leggere questi splendidi report:

• 2 days of global chatbot experts at Talkabot in 12 minutes
• Part 1: Talkabot conference liveblog
• Part 2: Talkabot conference liveblog
• Part 3: Talkabot conference liveblog

L’intervento di Ted Livingston

Al #talkabot ha partecipato anche Ted Livingston, fondatore della piattaforma di messaggistica istantanea Kik. Ieri è uscito l’articolo Talkabot: Conversation with Ted Livingston, CEO Kik di Peter Swimm che riporta il video integrale dell’intervista di Kurt Wagner:

Video report integrale dell’intervista (su youtube)

Conoscevo ovviamente già Ted e la piattaforma di instant messaging canadese Kik, che ha attualmente 300 MAU soprattutto giovani e giovanissimi. Kik da molti anni integra una piattaforma di sviluppo bots, con modello “alla WeChat”.

e che realizza molte features che noi, in Italia, crediamo siano state inventate da Telegram (per esempio le mentions che in Telegram sono gli inline bots) ma che invece sono state sviluppate prima in Kik (sul chi è venuto prima potrei sbagliarmi, ma poco importa).

Conoscevo già (e personalmente condivido) le idee di Ted Livingston a riguardo delle applicazioni chatbot orientate al commercio (di beni digitali ma sopratutto fisici), la proposta di Kik rivolta al commercio offline e il proximity commerce.

Va precisato che la visione del CEO di Kik non è quella di un commercio conversazionale (#convcomm) basato su raffinate tecniche di natural language understanding, ma piuttosto quella di bots “alla WeChat”, molto semplici ed addirittura “menu-driven”, che realizzano, all’interno della chat, una user experience simile a quella della navigazione su web. Poco più di pochi click and point, UX di intermediazione tra persone, in ambito business o enterntainment. Vedi: How Our Dumb Chat Bot Got A Million Users Without Even Trying

Conoscevo già l’ironia di Ted Livingston rispetto alla associazione tra chatbot e intelligenza artificiale, ma nell’intervista sul palco del #talkabot è stato sorprendentemente esplicito! Molto tagliente nella sua visione e nel suo giudizio sulle grandi aziende che sostengono di avere superlative piattaforme di intelligenza artificiale.

L’AI è davvero il nuovo grande business delle grandi aziende?

IL CEO di Kik ha menzionato i maggiori big players e non ha lasciato niente di non-detto con lapidaria sentenza:

If AI is required to win (big companies), they have already won. If AI is not required, then they have already lost.

Ora, va detto che Ted non è contrario all’AI tout-court; tutt’altro! Lui sostiene che ci saranno in futuro, nelle applicazioni chatbot, grandi benefici dall’utilizzo del machine learning, ma afferma che:

AI is not the point.

La bot-economia come frictionless middleware tra domanda ed offerta

L’intelligenza artificiale non è il fattore principale del possibile devastante impatto dei bot nell’economia digitale. 
Il fattore principale è semmai l’eliminazione di quella che chiama “friction”: i bot sono semplicemente un mezzo nuovo, più rapido ed efficace per arrivare alle persone e facilitare le conversazioni interpersonali. 
E’ questo il punto molto pragmatico: la convenienza (da parte di chi sviluppa una qualsiasi applicazione) nell’utilizzo dei bot, che saranno (ovvero sostituiranno) i nuovi “siti web” (e le mobile app così come le intendiamo oggi: programmi di cui fare download su nostro telefonino o tablet). 
Su questo ha insistito parecchio ripetendo alcune volte lo slogan:

Le risposte di Ted sono sempre riflessive ed equilibrate; per esempio accennando positivamente a quanto detto recentemente da David Markus, Facebook leader, a riguardo di un velato possibile cambio di direzione strategica dell’azienda (in riferimento ad un possibile isolamento del dipartimento AI che lavora alla discussa — perché con non dichiarato approccio “human in the loop” — piattaforma “M”). 
Si è sbilanciato invece in una critica più aperta rispetto a Google Allo, esprimendo la sua perplessità nei confronti di un sistema di intelligenza artificiale pervasivo, che interviene in ogni conversazione tra persone suggerendo risposte/comportamenti.

Google ha annunciato di rilasciare entro Dicembre 2016 Assistant, la piattaforma di sviluppo per sviluppatori di bot. Vedremo!

L’intelligenza artificiale è l’abdicazione della riservatezza dei dati?

Questo è un tema molto delicato a mio avviso: la privatezza dei dati personali o meglio la percezione della privacy che gli utenti hanno nell’utilizzo di una qualsiasi piattaforma di instant messaging (o dispositivi ad interfaccia vocale com Amazon Echo e Google Home).

Ted Livingston sostiene che, psicologicamente, alle persone non piace il fatto che quando chattiamo, per esempio su Allo, tutte le conversazioni sono analizzate da un AI-assistant che, oltre a fornire forse un vero aiuto o supporto, “legge” (…) anche tutte le conversazioni tra te e le persone (ed i bot)!

Riflessione mia: 
è una sottile linea rossa quella che sottende tra possibile successo dell’utilizzo di intelligenza artificiale pervasiva e big data raccolti dalle corporations e il possibile opposto trend di rifiuto totale delle persone ad utilizzare tali tecnologie (l’esempio concreto, in fase di sperimentazione, è Google Allo).

Ted Livingston ha insistito sul fatto che in Kik i messaggi degli utenti non vengono assolutamente letti per nessun motivo. Per inciso, questo punto è “IL” cavallo di battaglia principale del fondatore di Telegram, Pavel Durov!

Altra cosa è, psicologicamente, avere una conversazione one-to-one con un bot (senza intermediazioni di assistant AI “terza parte”, nella accezione Google Allo o Amazon Alexa. 
Se sappiamo “per certo” che la conversazione è “criptata” dalla piattaforma e che i nostri messaggi e quindi le nostre conversazioni, infine tutti i nostri dati personali, non verranno utilizzati dall'azienda, allora può andarci bene condividere informazioni confidenziali con un chatbot applicativo che risolve un problema in un dominio specifico, come per esempio un bot bancario o di assistenza medica.

Futuro prossimo: chat-payments e colloqui inter-bots

Tra gli altri punti molto importanti che ha toccato Ted Livingston e che mi interessano molto:
1. l’insistere sul fatto che la chiave di volta sarà un sistema di pagamento all’interno della piattaforma ospitante i bot, a supporto degli sviluppatori di applicazioni (personalmente lavoro anche in questo ambito con un piccolo progetto coming soon).

2. Ted Livingston ha accennato ad un eco sistema prossimo venturo di applicazioni realizzate con cooperazione di molteplici bot che parleranno tra loro (anche questo è un tema che mi affascina e su cui sto lavorando).

Concludendo, condivido tutto quello che dice quest’uomo!

Il rapporto dell’Abi Lab in collaborazione con la School of Management del Politecnico di Milano, mette in luce nel 2014 i clienti che si sono serviti dell’accesso alla banca in “mobilità” con l’uso di smartphone e tablet sono aumentati di oltre l’80%.

Che cosa ha favorito questo? Semplicemente la diffusione delle App! In media, solo durante il 2014 ne sono state scaricate circa 8.800 al giorno, con un incremento del 17% sul 2013. Tutte le banche prese come campione stavano offrendo ai loro clienti servizi e funzionalità studiati appositamente per smartphone e il 77% anche un’offerta specifica per il tablet.

Ma è stato scoperto anche qualcosa in più: emerge infatti che il 36% delle banche offre, in aggiunta alla classica applicazione di mobile banking, un’App dedicata ai pagamenti elettronici presso i punti vendita, mentre il 27% ne ha una che funge da borsellino elettronico. Sono presenti anche App per operare sui mercati (23% delle banche), per la comunicazione (18%), per i servizi di assistenza ai clienti (14%) e per la gestione della finanza personale (9 per cento).

Tra i servizi più utilizzati all’interno delle App troviamo che il 65% è la consultazione del saldo e i movimenti di conto, il 54% è la localizzazione della filiale o dello sportello automatico situati in prossimità. Lo smartphone viene utilizzato anche per l’accesso ai servizi dispositivi, dato che il 37% effettua bonifici e giroconti.

COSTA STA CAMBIANDO IN CONCRETO NEL MONDO BANCARIO?

La tendenza che si sta delineando da parte delle banche riguarda l’impiego di sistemi di assistenza tramite chat o collegamento telefonico e servizi di gestione della finanza personale nell’arco dei prossimi 3 anni; è interessante notare che le comunicazioni effettuate via chat rispetto al 2014 sono aumentate del 66%.

Emerge quindi anche una mutata sensibilità nei confronti dei servizi di caring da proporre al cliente, ottimizzati e customizzati in un quadro sempre più omnichannel. La diversificazione dei canali utilizzati ha portato anche ad un posizionamento delle banche all’interno dei canali social: l’86% delle banche è presente sui maggiori social network.

PERSONAL DIGITAL BANKER: IL SUPERAMENTO DEL TRADIZIONALE CONTACT CENTER

I clienti delle banche si stanno abituando sempre di più a concepire i servizi offerti dalle banche all’interno di esperienze digitali; un esempio molto riguarda un recente studio che ha evidenziato come, negli Stati Uniti 4 cittadini americani su 10 non hanno fatto visita ad una filiale nell’arco degli ultimi 6 mesi. Il consulente che prima era abituato ad operare come personal banker incontrando i clienti faccia a faccia, si sta trasformando in un personal banker digitale, in grado di proporre a ciascun cliente soluzioni su misura studiate per le specifiche esigenze.

Se guardiamo al tema dell’assistenza ai clienti, l’Osservatorio sui Contact Center bancari promosso da ABI Lab e dall’Ufficio Analisi Gestionali dell’Associazione Bancaria Italiana ha certificato una notevole crescita dell’assistenza telematica al cliente nel settore bancario. Infatti a differenza di altri settori, per quanto riguarda le banche i canali di contact sono stati istituiti di recente; in passato si doveva raggiungere la filiale più vicina per ottenere anche informazioni banali e l’introduzione di questo nuovo tipo di servizio ha fatto sì che gli utenti hanno cominciato a preferire le chiamate ai call center piuttosto che doversi recare in banca. Ma l’avvento del personal digital banker è solo una questione di tempo: infatti le novità tecnologiche nel settore del caring, come i chatbot, permettono di ottenere informazioni e supporto in maniera ancora più veloce e comoda, perciò poco a poco verranno impiegati in maniera sempre più consistente.

Basti pensare che le comunicazioni via chat rispetto al 2014 sono aumentate del 66%, i contatti via e-mail ben del 10%. Inoltre continua a rafforzarsi infine l’interesse del settore bancario nei confronti dei social: l’86% delle banche con Contact Center è presente sui maggiori social network, e quasi la metà impegna operatori nel dialogo con il cliente social (il 43% su Facebook e il 33% Twitter).

Peter Morville dedica un post all’Architettura dell’informazione conversazionale e ritiene che con l’aiuto dell’architettura dell’informazione gli assistenti vocali miglioreranno e, aggiungo io, riceveranno la giusta diffusione. Questo non significa che le interfacce vocali sostituiranno o addirittura cancelleranno le interfacce grafiche. Morville è scettico a riguardo. Io sono convinto che per alcuni contesti l’interazione vocale sarà utile e migliorerà la produttività.

Architettura dell’informazione conversazionale

Peter Morville, il padre dell’architettura dell’informazione, racconta di come l’assistenza vocale sia al centro dell’attenzione di un gran numero di persone e di quanto le aziende stiano investendo in questa tecnologia.

Morville lo dice. E’ scettico e proprio perché scettico ha comprato, secondo me, l’assistente vocale più interessante, Amazon Echo. Certo adesso dovrebbe provare Google Home e Google potrebbe ascoltare quanto dice Morville. Ma andiamo con ordine.

Sia la luce

Morville, nell’utilizzare Echo, ha apprezzato le funzioni musicali, che sono le più immediate, Spotify e Music Prime. In aggiunta ad una sveglia se dovesse addormetarsi.

Tuttavia, troppo spesso, la nostra conversazione va in questo modo:

Peter (al buio): “Alexa, accendi la lampada.”
Alexa (accende la lampada): “Va bene.”
Susan (urla dalla cucina): “Cosa?”
Peter (urla di nuovo): “Niente, stavo solo parlando con Alexa.”
Alexa: “Non sono del tutto sicuro su come aiutarti in questo.”
Susan (urla dalla cucina): “Non dimenticare di ringraziare Alexa.”
Alexa: “Mi spiace, non so la risposta.”

In questo dialogo a tre, a me pare importante sottolineare due cose.

• L’assistente vocale entra in un contesto di cui non fa (ancora) parte.
• Un assistente vocale ti ascolta alla lettera.

Poi scrive

Il problema più grande di Alexa è che lei mi fa sentire stupido. Alexa mi costringe ad ammettere che non riesco a ricordare il nome di una delle mie canzoni preferite di Vienna Teng.

Su Spotify, posso cercare Vienna Teng, selezionare Warm Strangers, e avviare Harbor senza interruzione. Questa è la magia del Recognition over recall. Ed è difficile da fare con un interfaccia vocale.

Esperienza sonora? Quale esperienza?

Quale esperienza ti fa vivere l’assistente vocale? Evidentemente questa esperienza non è ancora stata progettata. Gli ingegneri non sono tenuti a pensare all’esperienza dell’utente se non per le funzioni proprie di funzionamento, spinti alla soluzione di numerosi problemi. Nessuno al momento si è (ancora) chiesto quale esperienza vive l’utente. O quanto meno nessuno se lo è chiesto in termini di ricerca antropologica e culturale.

Ancora, Morville

Che cosa posso chiedere? Qual è la sintassi corretta?

In teoria la macchina, l’assistente vocale, dovrebbe apprendere dal nostro linguaggio. Ma ad oggi l’assistenza vocale non comprende il contesto di quello che dice l’uomo.

Un assistente vocale non può impegnarsi in una conversazione reale. Sono tante le varianti e le regole (non rispettate) che coinvolgono una conversazione. Lo vedremo, nello specifico, la prossima settimana.

Così l’onere cognitivo ricade su di noi. Lei ci fa sentire stupidi.

L’onere cognitivo ricade su di noi, sull’essere umano. L’uomo, infatti, si adatta più velocemente della macchina. La capacità di calcolo dei nostri telefonini o di dispositivi come Google Home non sono equiparabili al nostro cervello. E quindi… finisce che siamo noi a studiare lo strumento. Siamo noi che vogliamo capire come funziona, come può funzionare al meglio. Cerchiamo e ricerchiamo l’affordance dell’assistenza vocale.

Progettare un assistente vocale

Peter Morville lancia degli spunti da approfondire. Alcune linee guida che l’architettura dell’informazione sonora e questo blog dovremo seguire e approfondire nel tempo.

Potrebbe essere utile se Alexa avesse una architettura dell’informazione distinguibile. Se potessimo selezionare una categoria come la musica, le notizie, o lo shopping. Potrebbe essere più facile navigare in ogni sottoinsieme di casi d’uso e comandi.

Alexa dovrebbe aiutare a capire e ricordare. Per fare questo Peter Morville invita Alexa a interfacciarsi con Siri (cosa che non è possibile perché nessuno delle due aziende, al momento, lo prevede) o imitarla per una interazione multimodale (acustico/visivo).

Quando si chiede una canzone a Siri, infatti, l’assistente vocale di Apple risponde proponendo visivamente, sullo schermo dell’iPhone, la canzone presente nell’app iTunes.

Immaginate che cosa potrebbe fare Alexa con un ampio display sulla parete del soggiorno. Mentre ha solo i vantaggi dell’audio (ad esempio, l’utilizzo multi-room, l’accessibilità per i non vedenti), Alexa, senza lo schermo, non può renderci utenti forti. Chiedere non è sufficiente. Deve anche mescolare input e output audiovisivi per consentire una migliore visualizzazione e una migliore ricerca.

Alexa ha bisogno di una architettura delle informazioni multi-canale (cross-channel) che abbracci l’interazione multi-modale.

Cross channel e Multi-Channel e la luce fu!

Per spiegare la differenza tra Cross channel e multi-channel è necessario riprendere un articolo di Luca Rosati e Andrea Resmini autori del libro ancora attualissimo, Architettura dell’informazione pervasiva. Rosati e Resmini lavorano su questi temi dal 2007.

A me pare che Morville inviti ad una pervasività dell’architettura dell’informazione sempre più spinta. Dove il sonoro e la voce sono e devono essere solo una parte del sistema.

Peter Morville e la sua compagna dopo un mese hanno rinunciato ad Alexa, perché hanno ritenuto difficile l’uso e pensano che Echo debba essere ancora migliorato.

Per ora, i nostri telefoni, tablet e computer portatili offrono una migliore esperienza. Ma io credo che Alexa vedrà presto la luce con un piccolo aiuto da parte dei suoi amici dell’architettura dell’informazione.

Ecosistemi di conversazione

E’ tutto l’anno che scrivo riguardo interfacce e nuove frontiere. E senza nessun assurdo tecno-entusiasmo mi pare che i segnali siano molto forti.

• Perché nel futuro avremo INTERFACCE IBRIDE
• LE INTERFACCE DEL FUTURO e il Design dell’Esperienza
• LA NUOVA INTERFACCIA UTENTE non è l’interfaccia
• Le nuove frontiere dell’UX sono LE NUOVE SFIDE DELL’UX

www.tonifontana.it

ChatBot

Peter Morville conferma che non si può parlare dell’interazione vocale tra uomo e macchina senza parlare dei servizi di messaggistica, già esistenti e che fanno uso di Intelligenza artificiale (chatbot).

In Italia ancora non sono molto diffusi, ma esistono già assistenti intelligenti che aiutano l’utente che ha delle specifiche necessità. Operator è un chatbot che ti connette con gli esperti per scoprire e comprare ciò che ami. Magic è un numero di telefono a cui inviare SMS per ricevere tutto quello che vuoi, su richiesta e senza problemi.

Oppure ci sono le intelligenza artificiali con supporto umano come Facebook M.

Morville ricorda anche i chatbot usati dai media, ma questi, già alla loro uscita, hanno creato più fastidio che consenso tra gli utenti. Aumentando, secondo me, lo scetticismo nei confronti di questa tecnologia.

La questione mi pare sempre la stessa. Ossia che in tanti, anzi, in troppi, pensano, o vogliono pensare, che un chatbot, o un assistente vocale, o l’intelligenza artificiale, possano fare qualsiasi cosa. Così non è.

la chat occuperà una nicchia specializzata nell’ecosistema conversazionale più ampio.

Le buone pratiche di bot e AI: il servizio

Morville porta ad esempio il chatbot CourtBot. Si tratta di un progetto creato dalla Code for America che invia SMS alle persone che devono avere a che fare con il tribunale o la polizia. Il bot ricorda le date del processo, la scadenza per il pagamento delle multe e così via. Il ChatBot rende un servizio.

Ma il bot non fa tutto e non si organizza da solo. Il bot è solo una delle tante parti dell’ecosistema. L’ecosistema è molto più ampio, in un percorso cross e multi channel che coinvolge agenti di polizia, citazioni di carta, il bot stesso, un call center, un sito web e il palazzo di giustizia.

La soddisfazione degli utenti è raggiunto quando le parti si incastrano per creare un intero ecosistema.

Deus ex machina

E’ inevitabile che le forze della tecnologia ci spingano ad usare nuovi strumenti e a vivere diversamente. Ma non vivremo mai in un film. Non dobbiamo affrontare la tecnologia con la Tecnologia ma con la Cultura.

Mentre io credo che la consapevolezza sia tra le forze più dirompenti per plasmare il nostro futuro, non sto trattenendo il fiato per il deus ex machina della super-intelligenza. Consapevolezza e conversazione sono tra le cose più complesse, contestuali, disordinati e incorporati che possiamo conoscere.

L’intelligenza artificiale ha bisogno dell’Architettura dell’informazione

Lo sa Morville, ma lo sa bene ciascun architetto dell’informazione, che l’Uomo crea confusione. Ma se già sappiamo che il Design è una conversazione sappiamo pure che

Per trovare quello che ci serve o per fare le cose, un sito web è un conversatore megliore di qualsiasi bot.

Un linguaggio naturale debole ci farà andare solo lontano. Alexa non capisce il significato o il contesto, così le nostre “conversazioni” richiedono organizzazione, progettazione dello spazio e interazione multimodale.

Un po’ di chiarezza e di realismo

Spesso chi pone dubbi sull’assistenza vocale ne parla in relazione agli assistenti vocali che ha visto al cinema o in televisione, o peggio ancora, nei fumetti.

La colonizzazione dello spazio è sempre stato un mito della cinematografia fantascientifica. Ma chi paragona le spedizioni spaziali della NASA a quei film?

Paragonare Siri, Cortana, Alexa e tutti gli altri assistenti vocali a Jarvis di Iron Man (un fumetto), a Her o a Deus Ex Machina (film di fantascienza), sarebbe come paragonare la NASA alla flotta stellare di Star Wars, lo Space Shuttle all’ USS Enterprise (NCC-1701) del capitano Kirk di Star Trek.

Allora se vogliamo parlare e capire l’assistenza vocale, i risultati raggiunti, le opportunità e le potenzialità dello strumento, dobbiamo proprio toglierci dalla testa la letteratura, i film e i cartoni animati di fantascienza che fanno riferimento a questa tecnologia.

La realtà è che uno smartphone riesce a fare operazioni straordinarie. La realtà è che, come dice Peter Morville, i nostri telefonini, al momento, fanno quello che pensiamo ci basti. I telefonini soddisfano, oggi, i bisogni della maggior parte delle persone. Ma la realtà è anche che un dispositivo elettronico alto un palmo di mano non riuscirà a sostituire il nostro cervello. Almeno, non nel breve e medio periodo.

Pensiamo che l’assistente vocale non sia utile perché la maggior parte delle persone ha imparato a chattare, inviare messaggi e telefonare anche mentre guida, (quasi) senza guardare. Il pollice di alcuni ragazzi e ragazze ha una velocità che sfida le leggi dell’ergonomia. Per chi guida sarebbe più logico guidare e basta, oppure usare un vivavoce. Sarebbe più sicuro e produttivo usare un assistente vocale, che seppur lontano dalla Supercar KITT, potrebbe rendere la guida sicura e aiutare comunque in molte attività. Eppure così (ancora) non avviene.

La realtà è che l’esperienza dell’assistenza vocale non è ancora soddisfacente. La realtà è che gli assistenti vocali devono essere migliorati e testati ulteriormente.

E ad Oriente? WeChat

Mentre l’occidente vive questo scetticismo diffuso, in Cina l’uso dei bot è cosa abbastanza comune. Ed è guardando a questo mercato che si investe in questo campo. Gli Stati Uniti e l’Occidente sviluppano assistenza vocale, ma non ne fanno uso.

I chatbot stanno influenzando le aziende.

Certo, a differenza dell’internet occidentale, l’Internet cinese è regolamentato e WeChat, in buona sostanza, è una piattaforma di messaggistica. I chatbots che funzionano su WeChat sono più simili ad applicazioni leggere dove è possibile prenotare un dentista o svolgere attività più complesse. Ma gli usi insoliti sono tanti.

Michael Yuan, autore del libro Chatbots: Building Intelligent Bots, spiega come i bot sono percepiti in Cina:

Se si avvia un business in Cina oggi, si creerà un wechat pubblico bot ben prima di avere un sito web.

Sorprendentemente, vi è una nuova generazione di società di contenuti finanziati VC che operano esclusivamente in wechat — non hanno nemmeno i siti web pur essendo valutati decine di milioni di dollari.

Questo non significa che i bot avranno lo stesso successo nel nostro caos occidentale. I fallimenti di Kinect della Xbox o del bot Tay della Microsoft sono notevoli e da tenere ben presenti. Quello che possiamo dire è che

I chatbots sono ancora in grado di fare un’enorme quantità di cose, da semplici conversazioni alla pianificazione e analisi dei contenuti. Il futuro è sulla buona strada!

Ma stiamo andando troppo lontano ed è bene concludere tornando a noi e all’architettura dell’informazione conversazionale.

La singolarità

Peter Morville conclude ricordando che invece della catastrofica estinzione dell’uomo sostituita dall’intelligenza artificiale si potrebbe vivere una nuova era tecnologia grazie all’architettura dell’informazione sonora. Studio del contesto, progettazione dell’esperienza, progettazione cross canale e multisensoriale.

La singolarità potrebbe essere vicina. Che ne pensi Alexa?

Insomma, il nostro futuro sta tutto nella nostra umanità, nella nostra capacità singolare di mettere l’Uomo al centro, nella nostra unicità, nella nostro essere singolare, addirittura singolare-plurale.

Essere consapevoli di questo, certamente, aiuterà ad usare meglio gli strumenti che la tecnologia ci offrirà.

www.tonifontana.it

Originally published at www.tonifontana.it on October 24, 2016.

Ho seguito tutto (…) il live tweet del #botday, la megaconferenza del 19 ottobre a San Francisco, organizzata da O’Reilly:http://conferences.oreilly.com/artificial-intelligence/bot-ca/public/schedule/proceedings

Ho chattato al volo con qualche relatore e persona presente in sala. Raccolgo qui qualche foto agli speakers che mi hanno più colpito maggiormente.

Cathy Pearl (sulla user experience ed il linguaggio)

Una delle slides più più re-twittate/commentate all’evento, è quella che ho inserito come foto di copertina, di Cathy Pearl, Director of User Experience in Sense_ly. Dice Cathy:

Progetta [un chtabot] in base a come la gente parla davvero, e non per come vorresti parlasse!

Questa frase è piaciuta molto al pubblico e pare essere, per uno sviluppatore di applicazioni conversazionali, un proposito totalmente condivisibile, ma mi ha fatto fare qualche riflessione, lasciandomi perplesso:

Qual è la lingua che la gente parla davvero ?

O non sono invece molteplici le lingue parlate dai cittadini di uno stesso rione? E’ opportuno omologare un chatbots ad un singolo paradigma di comunicazione linguistica mainstream (quindi per esempio, nell’ambito di una applicazione customer care, l’usare un linguaggio formale e serio in lingua naturale italiana? Oppure per una applicazione di online-shopping destinata ad un pubblico molto giovane, è opportuno l’utilizzo di uno specifico linguaggio gergale, slang, dialettale, o con emoji, nel caso di chatbot che gira su applicazione di messaggistica istantanea)?

O invece può essere migliore un approccio #botpersona ? Cioè potrebbe essere interessante far adeguare l’utente ad un linguaggio specifico di un chatbot?

Penso che i bots di prossima generazione avranno una propria #boteness e forse sarà meglio che il bot-linguaggio sia riconoscibile come non-naturale e peculiare alla “personalità” artificiale del bot.
Comunque il talk di Cathy mi è piaciuto ed il libro in anteprima “Designing Voice User Interface”, l’ho già comprato, essendomi convinto da tempo che il futuro sarà nell’interfaccia vocale (CUI -> VUI).

Lili Cheng (sugli aspetti sociali, su Xiaoice)

Molto interessante anche l’intervento di Lili Cheng, responsabile del progetto Microsoft FUSELabs. Lili ha parlato delle applicazioni chabot “social”, cercando di spiegare, tra l’altro, il successo di Xiaoice tra i giovani Cinesi (ma anche Giapponesi), dimostrando le abilità del chatbot non solo nel chit-chat, ma anche in ambiti di ausilio alla didattica, etc.

BTW, Consiglio di ascoltare l’intervista di Jon Bruner: 
Lili Cheng on bot personalities

La ricercatrice ha poi illustrato alcune strategie del Microsoft bot Framework, tra cui il “disaccoppiamento” e l’indipendenza dai canali: a tal proposito, mi ha fatto piacere che tra i canali possibili (per i chatbots), Lili abbia menzionato le mail! e la CLI (command line interface):

Peter Skomoroch (piattaforme AI e prossimi scenari)

Il cofondatore di skipflag ha fatto un intervento su alcuni strumenti di machine learning utili allo sviluppo di bots. 
E’ la slide finale del suo talk, quella che per me è più affascinante in assoluto, quando parla di fuzzy APIs e di interazioni tra bots! 
Vedi anche podcast.

Andy Mauro (sulle piattaforme di messaggistica)

Il fondatore di automat.ai, ha fatto una comparazione tra i diversi approcci di UI/UX delle più diffuse piattaforme di messaggistica istantanea.

Mi ha fatto piacere che abbia citato la piattaforma Kik e l’approccio #NoAI di Ted Livingston. Interessante anche l’insistere su interazioni tra bots ed il problema della discovery.

Amir Shevat (sui tools e le best practices)

L’onnipresente (agli eventi sui chatbots) evangelista Slack, ha fatto una overview generale sugli strumenti di sviluppo di bots, su tutto il ciclo di vita, dal prototyping agli strumenti di analytics. Tutto interessante e molto piaciuto dal pubblico.

Ho apprezzato che Amir non abbia parlato solo di botkit ma invece abbia fatto una overview sugli strumenti di terze parti. Ma mi è spiaciuto però che non sia stato menzionato ChatScript tra gli strumenti di scripting authoring, e nemmeno ha citato SuperScript, di Rob Ellis, che lavora in Slack anche lui. Poi forse non mi trovo d’accordo su alcuni statements fatti (per esempio la citazione dell’utilizzo di molteplici piattaforme di AI per fare un crowd-decision), comunque tutto interessante!

Infine, nella definizione delle best practices, Amir, dopo aver dato un colpo alla botte (il parlare del valore delle piattaforme di AI proprietarie), da un colpo al cerchio (il contro valore del “contesto” umano, ovvero la business logic peculiare di ogni applicazione, dominio del singolo sviluppatore/creatore del bot!).

E dice, in riferimento all’utilizzo di piattaforme di AI:

Fake it until you need it

Intendendo forse che è possibile “emulare” un comportamento smart, che la gente crede essere quello di sistemi di machine learning, finché davvero non c’è necessità di usare una piattaforma di intelligenza artificiale “esterna” (e spesso a pagamento), e che la cosa più importante è infine curare tutto il ciclo di vita convenzionale del software, con particolare attenzione ai sistemi di analytics e supervisione umana!

Last but not least, Amir ha annunciato il libro “Designing Bots” che pubblicherà nel 2017.

Joshua Browder (utilità sociale di bots per i cittadini)

Lasciate che spenda due parole di introduzione a questo ragazzo: fondatore di DoNotPay, il primo avvocato-robot in UK, Joshua Browder è chiamato il ‘Robin hood di internet’, secondo la BBC. Un combattente per i diritti dei consumatori. Ecco come la definizione del servizio sul sito DoNotPay:

DoNotPay has launched the UK’s first robot lawyer as an experiment. It can talk to you, generate documents and answer questions. It is just like a real lawyer, but is completely free and doesn’t charge any commission.

Joshua Browder, mosso in generale dall’intento di fare servizi utili ai cittadini, ha spiegato nel dettaglio il funzionamento di DoNotPay e la necessità di chatbots che non servano per l’home delivery della pizza, ma per risolvere problemi ai cittadini.

L’intervento di Joshua è senz'altro quello più “politico”, considerando tra l’altro che l’evento #botday era a pagamento (con biglietto a caro prezzo, quindi destinato ad un pubblico “azienda”) e l’evento è stato organizzato da una casa editrice che ha quindi cavalcato l’onda della chatbot fashion, insomma non si può certo dire che che fossimo nella culla del no-profit, eppure è significativo l’intervento del creatore di DoNotPay, anche perché pone giustamente il punto davvero critico ed interessante della applicazioni chatbots, ovvero l’impatto dell’intelligenza artificiale sul mondo del lavoro, un dibattito già iniziato con le polemiche su X.ai e che deve proseguire anche con una presa di coscienza delle istituzioni.

E’ curioso il fatto che Joshua abbia illustrato l’architettura software usata per DoNotPay, dichiarando di usare IBM Watson (una piattaforma di intelligenza artificiale, closed-source e di big player profit). 
Gli chiederò asap conto di questa decisione :), perché di sistemi di natural language classification / understanding ce ne sono anche di opensource. Mistero o azione politica? Interessante… Stay tuned.

Altri articoli sull’evento:

7 Takeaways from O'Reilly Bot Day | botnerdsI was lucky enough to attend O'Reilly Bot Day in San Francisco. Bot Day was the first "proper" bot conference I've…botnerds.com

Tutte le slides:

Speaker slides - Bot DaySpeaker slides- Bot Day Speaker slidesconferences.oreilly.com

Ringrazio le persone che hanno fatto il live report, facendo tante foto e commentando, tra cui: Mariya Yao, botnerds, Sara Winge, Mary Parks, Jon Bruner, Kelly Manthey, Paolo Perazzo, Botanalytics, @OReillyAI, Cecily Robyn Lough, @ruchagokhale, @strataconf. etc. etc. :-)

Update 4 Novembre: tutte le registrazioni video dell’evento #cbc16: qui!

Non c’è dubbio: #cbc16, l’evento sui chatbots ChatbotConf2016 organizzato ieri dagli amici di orat_io di Vienna è stato davvero eccellente!
Organizzazione alla stra-grande, speaker d’eccezione, molti dei quali provenienti da oltreoceano, copertura a tutto spettro delle aziende protagoniste internazionali (direi che tutte le aziende significative erano presenti: Slack, Facebook, Microsoft, IBM, Google, prima presenza della giapponese LINE in Europa… forse mancava WeChat, ma per il resto c’erano proprio tutti) e c’erano molte teste pensanti e qualche startup austriaca.
Wow!

Disclaimer: non ho partecipato personalmente all'evento, ma l’ho seguito su twitter quasi tutto il giorno… scrivo quindi qui qualche breve pensiero in base alle foto, ai commenti ed ai brevi botta-e-risposta su Twitter. Aspetto le slides e qualche insight di chi era all'evento e ha potuto forse parlare de visu con gli attori sul palco!

P.S. ringrazio Luca Dell’Ora ed il team di @wearesocialit che hanno twittato foto e video per tutta la durata dell’evento e che invito nuovamente qui a pubblicare/ripubblicare su www.convcomp2016.it il loro articolo/report ! :)

Cito qui di seguito solo alcuni tra gli speaker, sicuramente mi sono perso qualche altro intervento notevole, ma queste sono le persone che mi hanno subito impressionato:

Mikhail Larionov

Technical leader in Facebook, Mikhail ha fatto alcune anticipazioni su prossima release update della UI di Facebook Messenger Bot Platform, le cui API saranno probabilmente rilasciate entro la fine dell’anno. 
E’ simpatico il fatto (una provocazione?:) ) che siano stati fatti riferimenti, in qualche slide, a Goggle Home ed Apple… hmm, prevedo che gennaio 2017 sarà un mese caldo per il #botdev :)

BTW, una domanda che avrei voluto fare a Mikhail è quella a riguardo dei rumors dell’entrata in campo di Whatsapp con i bots, con un’apertura dunque alle applicazione automatiche, mentre fino ad oggi sono stati banditi e perseguiti legalmente gli autori dei chatbot “non ufficiali” (sul fatto che Whatsapp ci stia ripensando, ci sono peraltro affermazioni ufficiali dico/non-dico di Whatsapp stessa , che ricordo essere azienda acquisita da Facebook).
Poco male; glielo chiederò personalmente presto. Ovviamente questo punto per noi in Italia è fondamentale: da tempo sostengo che la #boteconomy italiana decollerà quando sarà possibile sviluppare bot sulla piattaforma tanto odiata da noi nerd, ma che usa il 95% della popolazione italica…

video: https://www.youtube.com/watch?v=8GfNmPF7o2U

Alexander Weidauer

Alex, già creatore ed organizzatore dei ben fatti chatbots meetups di Berlino

Apro parentesi: i berlinesi e i viennesi sono stati primi in Europa ad organizzare meetup sulle tematiche dei chatbot, va detto! Proprio ai meetup di Berlino mi sono ispirato, con Giuditta Del Buono i primi giorni dell’anno per creare il primo evento italiano: #convcomp2016 che abbiamo poi realizzato il 24 giugno scorso (anche se il nostro intento era quello di estendere la partecipazione, oltre agli sviluppatori di bot, a tutte le persone che lavorano attorno al conversational computing nella ricerca scientifica, nel business, negli aspetti umanistici e ludici, di servizi ai cittadini, etc. etc. ma insomma questo già lo sapete se state leggendo questo articoletto)!

Alex, dicevo, ha presentato una slide che secondo me fotografa esattamente la situazione tecnologica attuale dei business chatbot.

• Da un lato infatti oggi è possibile creare chatbot di buon valore (secondo me) con tecniche “tradizionali”, che nella slide vengono dette hand-crafted e che corrispondono in pratica o sistemi wired/hard-coded, o a sistemi basati rule-based (vedi l’amato/dibattuto ChatScript dell’amico Bruce Wilcox);
• D’altro canto ci sono i sistemi che Alex chiama data-driven ed ovvero i modelli generativi di machine-learning; tecnologia, quest’ultima, di cui tutte le startup alla moda parlano ma che è, secondo me, ancora un terreno di ricerca pieno di trappole, quindi ci andrei molto cauto con una facile apologia del crowd-sourcing learning…

Comunque per me, quella riportata sotto è la slide più interessante dal punto di vista della tecnologia: a quando sistemi generativi di utilizzo pratico nel business? Già nel 2017?

Blog: Lastmile conversations

Matty Mariansky

Adoro quest’uomo. Ebbi qualche breve conversazione con lui l’anno scorso commentando suoi articoli sulla user experience conversazionale CUI/GUI, che riportavano la sua esperienza con la startup: www.meekan.com

Mi piace l’approccio di Matty, molto pragmatico e sincero, quando dice, con le slide, quello che io traduco scherzosamente così:

Caro sviluppatore startupparo, non sei Google né Facebook, giusto? ed allora lascia perdere la General Artificial Intelligence, ma focalizzati invece sul dominio applicativo su cui vuoi fare business o servizi utili alle persone, e fai un chatbot che risolva bene un problema applicativo specifico, con qualsiasi strumento informatico tu abbia a disposizione.

Matty riporta cioè l’attenzione alla UX/UI di un design (conversazionale) applicativo ben fatto. E lasciamo agli scienziati (di Facebook e Google e OpenAI, etc. etc. ) il compito di arrovellarsi sulla progettazione di macchine intelligenti di autoapprendimento del natural language understanding. Cognitivo a chi ? :-)

Slides: Memories of a bot trainer 
Blog: Building the robot assistant
Video: https://www.youtube.com/watch?v=uHYQvb5wMOo

Alex Bunardzic

Conoscevo Alex per aver letto qualche suo interessante articolo di #botdev, come “How to Design a Bot Protocol”, e mi ha fatto piacere che lui sia stato relatore al #cbc16!

Alex Bunardzic mi ha cortesemente fornito le sue slides: “How To Avoid Pyramid Of Doom When Designing Bot Workflows” e mi è piaciuto tutto il suo taglio “personale”, ho trovato stimolante ogni punto e sono d’accordo su ogni tradeoff che presenta: concierge vs butler, stateless vs statefull, GAI vs workflow bots e…:

Bot workflow is an uncharted territory

Ma è nella parte meno filosofica (che peraltro condivido) e più pratica dello sviluppo software di workflow bots, che mi sono trovato particolarmente in sintonia, e in effetti lui raggiunge conclusioni simili a quelle su cui sto lavorando io stesso, con un mio piccolo progetto work in progress, che pubblicherò presto probabilmente come opensource, sviluppato in Ruby, dove le conversazioni (che io chiamo “contesti”) tra entità dialoganti (man-machine, ma anche machine to machine) vengono codificate come macchine a stati (nome in codice del mio micoframewrok è naif, stay tuned).

Slides: How To Avoid Pyramid Of Doom When Designing Bot Workflows
Blog: Bots for Business
Video: https://www.youtube.com/watch?v=IzNT1NPlVJU

Note: 
l’info-grafica che ho messo nella copertina di questo articolo, mi vede presente :) in vicinanza con IBM, Facebook, altri super-big players e tanta altra bella gente! Chiudo allora con Luca Hammer che mi spiega come ha realizzato l’info-grafica in questo stupendo articolo:

Guide: Analyzing Twitter Networks with Gephi 0.9.1This is by no means a complete guide, but a starting point for people who want to analyze Twitter networks with Gephi.medium.com

Commentate numerosi!
giorgio

Il primo meetup del gruppo milanese dei Chatbot è stato un successo. Il 29 settembre al Venini42 eravamo in 45, nonostante lo sciopero dei treni ci abbia privato di un po’ di partecipanti. Gli interventi sono piaciuti e dopo un’ora e mezza di talk abbiamo fatto un paio d’ore di chiacchiere, birre, focacce e patatine. Gli ultimi tiratardi hanno spento le luci alle 23.

Quel che mi ha dato molta soddisfazione come organizzatore è stata soprattutto la fase di networking dopo i talk. Testimonia che l’argomento tira e che le persone hanno davvero voglia di creare qualcosa. Ho girato per un po’ tutte le conversazioni ma ovviamente ho perso più della metà di quel che è successo. Eppure ho visto nascere molti contatti. C’erano aziende che volevano presentare i loro prodotti e le loro esperienze, sviluppatori che volevano imparare o spiegare quel che hanno fatto, designer, responsabili di progetto, innovation manager, ecc.

Video Keynote di Paolo Montrasio (PDF con note a https://connettiva.eu/milano-chatbots/Paolo_Montrasio_Keynote_2016-09-29.pdf)

Dopo il mio keynote hanno presentato due sviluppatori. Guido Bellomo ha mostrato come creare bot cross platform usando il suo tool RedBot.

Video RedBot di Guido Bellomo

e Salvatore Cordiano ha mostrato come scriverne uno in PHP per Telegram, con walkthrough e demo interattiva apprezzata dal pubblico che mandava messaggi al bot. Le sue slide ed il suo codice sono qui.

Creare un bot Telegram passo passoÈ un bot Telegram che ripete ciò che gli scriviamosalvatorecordiano.github.iosalvatorecordiano.github.io

Ha chiuso la serie dei talk una presentazione molto apprezzata di Alessandro Vitale che ha mostrato le sue esperienze nell’uso del linguaggio naturale per comunicare con i bot e i vantaggi rispetto a interfacce più tradizionali.

Video NLP e bot design di Alessandro Vitale

Data la dimensione del gruppo (180 iscritti al 29/9 e 236 oggi) ci sono arrivati sconti per conferenze ed offerte di lavoro, che abbiamo trasmesso in mailing list. Tra le offerte ricordo quella di The Oak, che era presente in sala e ha spiegato chi sta cercando e perché. Ci è arrivato anche l’invito a partecipare al Codemotion di fine novembre a Milano con uno spazio tutto per noi il venerdì sera. Lo spazio per i talk del Codemotion è andato via in un attimo ed attendo la pubblicazione ufficiale del programma per presentarveli.

Il prossimo meetup sarà giovedì 20 ottobre sempre alle 19 al Venini42. Il programma dei talk è già definito. Inizio io con una rapida visione di una Chat of Things e a seguire presenteranno le loro esperienze e i loro prodotti Vittorio Banfi di botsociety.io e Federico Nitidi, che ha sviluppato il bot di calciomercato.com. Interverrano anche Codemotion, che ci regalerà un biglietto omaggio e delle magliette (estratti tra i presenti) ed offrirà il buffet, e da remoto Thomas Schulz di botscamp.io

C’è così interesse che in pratica è già fatto anche il programma del meetup del 17 novembre, ma lo annuncerò durante il meetup di ottobre. Per ora vi dico che si tratta di altre aziende italiane che presentano i loro prodotti e le loro esperienze.

Intanto iscrivetevi al meetup di ottobre!

In risposta a all’articolo di Monica Cainarca: https://medium.com/italia/intelligenza-artificiale-rischi-e17ea8eebe5f#.mg94aw6qr

Ciao Monica!

Riporto il testo:

La preoccupazione principale è che i sistemi di IA sono sempre più integrati in istituzioni sociali fondamentali nonostante la mancanza di rigorosi studi e conferme sul loro grado di accuratezza e sui loro effetti sociali ed economici.

Questo è un punto molto delicato ed importante, che in Italia non stiamo ancora affrontando, nel 2016.

La mia preoccupazione è che sistemi di machine learning proprietari (ovvero appartenenti ad aziende private con obiettivi di profitto) diventino, come dici: integrati nelle istituzioni sociali fondamentali, senza che ci siano delle metriche di valutazione super partes, ovvero di organismi esterni di controllo (che immaginerei essere di competenza R&D dell’istruzione pubblica, università, CNR…, etc.). Non mi pare accada niente di tutto questo ora, ma niente proprio :-D, e questo è un grosso problema!

Sono certamente d’accordo con la conclusione:

Se gli impatti sociali dell’intelligenza artificiale sono difficili da vedere, è di fondamentale importanza individuare approcci rigorosi per renderli più visibili e trasparenti.

Sì, al momento manca in Italia, per quel che ne so, la ricerca di un qualche sistema di controllo “etico” (e democratico…) sulle soluzioni tecnologiche e metodologiche e strategiche, previste dai tanto acclamati sistemi di intelligenza artificiale “privata”.

BTW, ti invito a partecipare (scrivendoci se vuoi e diffondendo) il blog: www.convcomp.it che abbiamo creato per creare una comunità italiana attorno ai temi legati all'intelligenza artificiale, il machine learning ed i chatbots (sopratutto).

Cordiali saluti
giorgio

Qualche giorno fa, precisamente il 29 settembre, si è tenuto a Milano il primo meetup sul tema dei chatbot.

Durante la serata sono intervenuti: Paolo Montrasio con il keynote introduttivo; Guido Bellomo con la presentazione del progetto open-source “RedBot”; Alessandro Vitale con il talk intitolato “NLP e bot design”.

Al meetup c’è stato anche il mio intervento nel quale ho raccontato come è possibile “Creare un bot Telegram passo passo”.

Le slide sono disponibili qui, mentre il tutorial completo per la creazione di un bot Telegram è disponibile a questo link.

Dopo la pausa estiva è opportuno ricominciare a pensare alla gestione del proprio proprio Customer Service con un argomento leggero ma valido: 10 letture fondamentali per il miglioramento del Customer Service.

Quando si tratta di migliorare e arricchire noi stessi e le nostre vite, non c’è investimento migliore che comprare un libro.
Quale altro investimento offre un accesso diretto alle conoscenze di qualcuno che è diventato esperto in un campo specifico dedicandogli anni della sua vita, studi e ricerche?
Per diventare esperti in un campo nel quale ci si è appena immersi, trovare il miglior libro relativo a quell’argomento stesso è la cosa migliore che si possa fare.

Nella lista seguente la cosa che più salta all’occhio è che nessuno di questi ha Customer service nel titolo. Di fatto molti dei libri dal titolo simile non hanno dei validi contenuti, né relativamente al campo specifico né per l’acquisizione di conoscenze generiche aggiuntive.

Ci sono invece tanti libri che, apparentemente, non hanno nulla a che vedere con il Customer Service ma che possono rivoluzionare il modo in cui ci si approccia ai clienti.

Ecco la lista dei 20 libri da leggere per migliorare il proprio Customer service

1) Come trattare gli altri e farseli amici di Dale Carnegie

Questo è il libro che più di ogni altro aiuta ad andare d’accordo con gli altri nel lavoro e nella vita privata, e che dovrebbe essere letto da chiunque abbia un ruolo attivo nel campo del Customer Service.
Le rivelazioni di Carnegie su ciò che è in grado di muovere le persone nel profondo e su come questo qualcosa possa effettivamente essere utilizzato per renderle felici ed ottenere ciò che si vuole da loro, sono tanto importanti oggi quanto lo erano quando vennero pubblicate, nel 1937.

“Quando trattiamo con la gente, ricordiamo che non stiamo trattando con persone dotate di sola logica. Noi stiamo trattando con creature dotate di emozioni, creature agitate da pregiudizi e motivate dalla superbia e dalla vanità.”

2) La spinta gentile. La nuova strategia per migliorare le nostre decisioni su denaro, salute, felicità di Richard Thaler e Cass Sunstein.

Se vuoi imparare come influenzare le scelte dei tuoi clienti e come indurli a dare un maggior valore ai tuoi prodotti, questo è il libro che fa per te.
Tramite la teoria dei Nudge (ovvero delle spinte gentili) i due autori spiegano come tramite questa si possano indurre comportamenti specifici in ciascun individuo.

“Per far perdere peso alla gente una strategia efficace sarebbe mettere degli specchi nelle caffetterie.”

3) Detto, fatto! Di David Allen

La gestione del Customer Service richiede una notevole capacità di coordinazione delle tempistiche, del personale e di tutti quei fattori che entrano in gioco nel rapporto tra l’azienda e il cliente. È facile che, dato il compito complesso, ci si lasci prendere da stress e comportamenti emotivi. I software di Help Desk possono senza dubbio aiutare, ma in questo libro è possibile trovare la chiave della produttività libera da stress.

“La maggior parte delle persone è più produttiva nel proprio lavoro la settimana prima di andare in vacanza, ma non è certo per la vacanza in sé. Cos’è che si fa l’ultima settimana prima di partire per un lungo viaggio? Si mette ordine, si chiudono delle scadenze, si fa chiarezza sui propri obiettivi e si rivedono i termini degli accordi presi con se stessi e con gli altri. Suggerisco che ciò venga fatto settimanalmente, invece che annualmente.”

4) Delivering Happiness di Tony Hsieh

Non c’è nessun caso di studi che rispecchi maggiormente l’idea di come il Customer Service possa portare un’azienda ad un successo inaspettato più di quanto non abbia fatto con Zappos.
Pare addirittura che tutti i clienti di Zappos abbiano un aneddoto su quanto il personale del Customer Service dell’azienda possano averli positivamente stupiti.
Questo libro, scritto dal CEO dell’azienda, racconta come e perché il Customer Service ha avuto tanta importanza per questa azienda e fornisce innumerevoli spunti su come possa essere ripensato il rapporto tra azienda e cliente.

“Nel corso degli anni, il primo punto di forza della nostra crescita a Zappos sono stato i clienti fedeli e il passaparola. La nostra filosofia è stata quella di prendere la maggior parte del denaro che avremmo investito per la pubblicità a pagamento e di investirlo, invece, nel Customer Service e nella Customer Experience, lasciando che fossero i nostri clienti a fare marketing per noi attraverso il passaparola.”

5) Il vantaggio della felicità di Shawn Achor

Essere positivi è una delle caratteristiche più importanti per la gestione del Customer Service e può determinare una effettiva rivalutazione dell’azienda da parte dei clienti. Questo libro vi insegnerà dei metodi studiati da un punto di vista scientifico dal team di Achor che promettono di rendere il lettore più felice e più ottimista nel tempo, cosa che avrà una notevole ricaduta in positivo sulla produttività, la performance lavorativa, e migliori relazioni con i clienti.

“Gli studenti ai quali è stato detto di pensare al giorno più bello della loro vita proprio prima di fare un test di matematica hanno avuto risultati migliori dei loro colleghi. E quelle persone che hanno espresso emozioni positive mentre negoziavano un affare hanno avuto risultati più efficienti di quelli che dimostravano emozioni neutrali o negative.”

6) Checklist, come fare andare meglio le cose di Atul Gawande

Quando tanti clienti inviano e-mail dai vari livelli di priorità la cui gestione spetta a più di un team, il funzionamento del Customer Service può diventare piuttosto caotico.
Quando le cose diventano confuse e caotiche le possibilità che dei dettagli fondamentali vengano smarriti aumentano a dismisura. In questo libro Gawande, rinomato chirurgo, ci racconta alcune storie incredibili su come le checklist, un concetto dalla semplicissima applicazione, salvino ogni anno milioni di vite negli ospedali. In realtà le checklist possono essere utilizzate per rendere a prova di rischio qualunque tipo di processo o sistema, e grazie a questo libro è facile imparare come.

“A molti non piacciono le checklist. Devono essere scrupolose, non sono molto divertenti. Ma il problema non è relativo alla semplice pigrizia…è come se fossimo costretti ad usare una forma di controllo su noi stessi che ci provoca imbarazzo. Si va infatti contro la convinzione profondamente radicata che chi è veramente ingamba tra di noi — o aspira ad esserlo- può gestire persino le situazioni di maggiori complessità. Ma le persone così definite ingamba sono audaci, improvvisano. Non hanno protocolli o liste di controllo. Forse la nostra idea di eroismo deve essere aggiornata.”

7) La mucca viola. Farsi notare (e fare fortuna) in un mondo tutto marrone di Seth Godin

Quasi tutte le aziende all’inizio cercano di farsi notare, ma già dopo pochi anni si conformano alle aziende più anziane presenti sul mercato.
Cosa determina questo fallimento nel volersi distinguere?

Questo libro cerca di risolvere questo mistero e da un’importanza fondamentale al pensarla in modo diverso e volersi differenziare dagli altri. E nella scelta di essere riconoscibili, il Customer Service dovrebbe riflettere sempre questa intenzione.

“In un mercato affollato, uniformarsi è fallire. In un mercato affollato non emergere è uguale ad essere invisibili”

8) Drive. La sorprendente verità su ciò che ci motiva nel lavoro e nella vita di Daniel H. Pink

Questo è uno dei libri più efficaci nel motivare che siano mai stati pubblicati negli ultimi dieci anni.
Se vuoi motivare il tuo team perché offra un validissimo servizio di assistenza clienti (e la cosa non ha a che fare con il budget a disposizione), o hai bisogno di motivare i tuoi clienti a scriverti per chiedere aiuto (e la cosa non ha a che fare con il referral né con il gamification), Daniel Pink ti insegnerà ciò che serve sapere sul capire cos’è che fa si che le persone compiano azioni specifiche.

“Il problema del fare del premio l’unica obiettivo che conta è che alcune persone sceglieranno il percorso più veloce per raggiungerlo, anche se ciò significa prendere una scorciatoia. In effetti, la maggior parte degli scandali e comportamenti scorretti che sono radicati nei comportamenti della vita moderna coinvolgono le scorciatoie.”

9) I quarantanove racconti di Ernest Hemingway

Saper scrivere è molto importante nel Customer Service: scrivere con chiarezza rende più facile comunicare con i clienti, che sono più soddisfatti e inclini all’interazione con l’azienda. Mentre esistono moltissimi libri ricchi di consigli su come fare a scrivere bene, è consigliabile leggere quei libri che sonodavvero scritti bene.
Una scrittura chiara e scorrevole è indubbiamente quella che troviamo in tutte le opere di Hemingway. Lui sapeva come rendere ogni singola frase piena di brio utilizzando un linguaggio positivo, variegato e deciso.

“Tu potresti parlare. Io potrei ascoltare. Ed un miracolo potrebbe accadere.”

10) Ottieni tutto quello che puoi con quello che hai già di Jay Abraham

Probabilmente non c’è esperto più rinomato di Jay Abraham per quanto riguarda lo sviluppo delle aziende, il quale ha lavorato con alcune delle compagnie di più grande successo al mondo per la modestissima cifra di 50,000$ al giorno. Abraham sa meglio di chiunque altro come portare un’azienda da una fase di crisi ad una di sviluppo fiorente, e in questo libro ha inserito dei consigli molto validi per la gestione del Customer Care. Lo scopo del libro è quello di modificare la percezione che gli operatori del Customer Service, i manager del marketing o chiunque altro abbia come compito quello di ascoltare i clienti ed entrare in contatto con loro, hanno di se stessi, iniziando a percepirsi come fidati consiglieri dei loro clienti.
La peculiarità di tutte queste letture non è solo quella di essere determinanti per l’arricchimento del Customer Service aziendale, ma anche per quello del singolo nel proprio vivere quotidiano.
E voi avete delle letture particolarmente coinvolgenti che potrebbero rientrare in questa lista?
Segnalatele tra i commenti, saremo lieti di arricchire la nostra lista.

Roberta Gallo

Viviamo sicuramente un momento estremamente interessante per il campo del customer service: le modalità con cui vengono erogati i servizi di assistenza clienti ridefiniscono sempre più il rapporto cliente-azienda, cambia il modo in cui viene concepito il Customer Care che integra sempre più e sempre meglio nuovi e moderni strumenti.Ormai, si sa, l’assistenza clienti è multicanale: vi è più di un modo per interagire con un’azienda e un brand e si passa dai classici mezzi quali email e telefono, ai social network, sino ad arrivare alle app come Whatsapp. Gli sviluppi più interessanti riguardano, però, le chatbot. Come definirle?

In un articolo, The Guardian ha descritto le chatbot come “programmi che imitano le conversazioni con persone reali utilizzando l’intelligenza artificiale. Le chatbot trasformano il modo in cui si interagisce con il web”

Nell’ambito del customer service, le chatbot utilizzano il potere crescente dell’intelligenza artificiale per permettere agli utenti di interagire con un’azienda esattamente come farebbero con un addetto all’assistenza clienti.

Ma quali sono i benefici che si possono ottenere dalle chatbot? Vediamone alcuni.

Le chatbot sono il nuovo trending topic

Chris Messina, developer che ha inventato l’usatissimo hashtag per le conversazioni in Twitter e poi passato a Uber, famoso servizio di car pooling di San Francisco in qualità di Developer Experience Lead nel gennaio 2016 — ha scritto un articolo, proprio nello stesso mese, nel quale preannunciava l’ascesa di qualcosa che lui definiva conversational commerce, descrivendolo come “l’utilizzo di chat, servizi di messaging o altre interfacce di linguaggio naturale per interagire con le persone, brand, o servizi e bot che fino a questo momento non hanno avuto un vero posto nel contesto bidirezionale e asincrono del messaging”.

Secondo Messina il risultato è il conversare con le aziende tramite Facebook Messenger, Whatsapp, Telegram, Slack e trovarlo assolutamente normale.

La sua visione di conversational commerce ben si inserisce quest’anno con l’esplosione prevedibile delle chatbot. Piattaforme di messaggistica come Facebook Messenger hanno investito recentemente in maniera imponente sulle chatbot, introducendo anche negozi virtuali di bot (bot stores) ai quali gli sviluppatori possono accedere, codificare e costruire da soli una chatbot a loro gusto.

La reazione iniziale alle chatbot è stata per certi versi abbastanza tiepida — la loro abilità nel gestire il linguaggio naturale a volte lascia a desiderare — ma è bene ricordare che siamo solo agli inizi di una appassionante evoluzione delle comunicazioni B2C.

In effetti, Gartner multinazionale nella consulenza strategica, ricerca e analisi nel campo dell’Information Technology, fece una predizione alcuni anni fa asserendo che nel 2020, l’85% delle interazioni con i clienti sarà gestita senza l’apporto umano.

L’ascesa delle chatbot si incastra perfettamente in questa predizione.

I clienti si dimostrano aperti all’idea delle chatbot

Spesso, il punto su cui si dibatte di più, quando si parla di automatizzazione dei servizi di customer care è incentrato sul “tocco umano”, ovvero quel contatto che solo un operatore in carne e ossa può stabilire e che un bot non sarebbe in grado di dare; tuttavia una ricerca ha dimostrato che ben il 40% dei clientipreferisce soluzioni self-service, soluzioni in cui in poche parola se la sbrigano da soli.

In più, Zendesk ha trovato che più del 50% dei clienti ritiene importante il fatto stesso che loro possano risolvere i propri problemi da soli senza dover aver a che fare con addetti all’assistenza clienti.

I clienti sono inoltre molto interessati nell’interagire con le aziende tramite messaggi (e già lo stanno facendo). Addirittura uno studio commissionato da OneReach (piattaforma di comunicazioni in cloud) rivela che il 64% dei clienti preferirebbe scrivere un messaggio piuttosto che chiamare un’azienda e alcuni dati rilasciati durante la F8 Conference, Facebook Developer Conference, hanno dimostrato che più di un bilione di messaggi sono stati inviati alle aziende ogni mese.

Combinando i due approcci, self-service e messaggistica/sms, ecco che si arriva alle chatbot.

La cosa interessante e che queste fanno leva, alla fine, su un canale che i clienti già stanno utilizzando (messaggistica istantanea, sms) integrandolo con il loro desiderio di esperienza self service.

Le chatbot sono più veloci di un operatore. E insieme?

Le chatbot sono sicuramente più veloci di un operatore a parità di tempo; questo è abbastanza ovvio poiché la capacità di processare le chiamate in entrata dagli operatori è comunque più limitata per motivi legati al tempo dedicato alla singola interazione, che è molto variabile.

È chiaro che poi il fattore che fa la differenza sull’utente finale è la qualità della risposta. Spesso si parla delle “freddezza” delle interazioni che avvengono con un sistema automatizzato, rispetto al “contatto caldo” che si può venire a creare con un operatore.

Ma se si parla di efficienza e velocità, le chatbot, tuttavia, si dimostrano ottime nell’erogare una buon servizio di customer care: i clienti possono digitare la loro domanda e ricevere una risposta praticamente immediatamente, il tutto è basato su una logica pre-programmata.

Sul fronte del costo, poi, le chatbot sono più economiche.

Tuttavia la parte interessante di tutto questo è che prendendo l’aspetto migliore di entrambi, ossia la velocità garantita dalla chatbot e il contatto caldo dell’operatore, e combinandoli si può arrivare praticamente ad una perfetta customer care.

Qui sotto propongo un esempio che riporta una esperienza di customer care attraverso Facebook Messenger con il negozio Spring.

La chatbot di Spring chiede ad esempio se l’utente stia cercando articoli maschili o femminili; in seguito chiede quale tipo di abito si vuole cercare, tutto in rapida successione. In poco tempo ci si trova a guardare tutti i risultati in maniera veloce e facile.

Esattamente come nell’esempio, la maggior parte delle persone utilizzerà e già utilizza le chatbot per richieste molto semplici, ma alcune volte i clienti potrebbero avere richieste più complesse di quanto un bot possa capire. Nell’esempio di prima, con Spring, l’utente ha trovato un cardigan che gli è piaciuto ma voleva anche sapere se fosse disponibile in un colore differente. Quando ha fatto la richiesta alla chatbot per verificare se vi fosse il colore bianco, il bot in maniera molto gentile ha risposto che sarebbe tornato presto con una risposta.

Partendo da una conversazione con un bot per arrivare poi a scrivere ad un operatore per le richieste più specifiche è un buon modo per garantire un’ottima customer experience ad ogni cliente.

Le chatbot possono incorporare media di ogni tipo

Tutto ciò che concerne i contenuti visuali — quindi immagini, foto, disegni — hanno un altissimo impatto nell’essere umano; infatti processiamo le immagini 60mila volte più velocemente di quanto facciamo con i testi.

Le immagini sono una veloce e facile via per comunicare informazioni, per cui è interessante il fatto che le chatbot possono incorporare media come immagini e GIF nella conversazione.

Anche se le chatbot principalmente comunicano tramite testo scritto, le immagini però aiutano le chatbot a farle sembrare più umane; inoltre mostrano un prodotto che è più facile da far vedere che descrivere.

Tornando all’esempio dell’e-shop di Spring, una volta che si scrive che tipo di prodotti si desidera cercare, il bot risponde con varie opzioni con immagini sulle quali è possibile cliccare ed espandere per avere più informazioni.

È quasi indistinguibile da un essere umano (quando il tutto è scritto correttamente)

Il timore più grande sulle chatbot riguarda il fatto di avere con loro una user experience fredda, a tratti goffa (con risposte non troppo pertinenti) e robotica. In ogni caso i bot possono restituire una user experience senza troppi intoppi, umana quando scritta correttamente.

Dipende concretamente dal tipo di comunicazione del proprio brand/azienda, se formale o informale.

Se il brand usa solitamente un tono informale, il linguaggio quotidiano e il fatto di utilizzare nelle chatbot il “noi” o “io” funziona sicuramente.

Al contrario, se l’azienda ama i toni formali, è preferibile la terza persona e un linguaggio non troppo quotidiano.

Tornando al caso di Spring, il tono utilizzato era chiaramente sull’informale: per cui quando il bot risponde con “Hey ciao” e parla di sé con il “noi”, si percepisce ad esempio più umanità. È probabile che quasi la differenza non si noti tra la risposta del bot (a sinistra) e la risposta dell’operatore (destra) quando entra nella conversazione.

I brand si dimostrano sempre più recettivi nell’utilizzare le chatbot nelle loro comunicazioni verso il cliente.

I mesi a venire sono sicuramente determinanti per capire quanto queste possano realmente giocare un ruolo chiave nell’erogazione del customer service; i benefici appena elencati chiariscono intanto sicuramente due punti: l’ascesa indiscutibile delle chatbot e il loro grande potenziale.

Valentina Mangia

On August 26th, during the course of the “Coding in your Classroom, Now!” summer school, a large treasure hunt game took place in the historical center of Urbino: 26 teams, composed of 139 participants overall, challenged each other by chasing clues through the narrow and steep streets of the city, following the orders of a… bot.

The game had been developed during the week just before the event and the whole team behind the treasure hunt spent the last minutes before the start feverishly fixing the last bugs.

(Well, most of them.)

The summer school, aimed at school teachers of all grades, had the main focus of bringing coding to the classroom, in a way that could be engaging for both teachers and young students. Thus, it made more than sense that the treasure hunt itself, “Urbino Code Hunting” as it was called, would be based on coding puzzles as well.

What made the treasure hunt interesting is that the whole registration process, the actual hunting, puzzling, and other game mechanics were directly handled by a Telegram bot. Anyone with a Telegram account could very easily register during the 4 days before the game just by entering a conversation with it.

Registrations to the game were handled by a run of the mill conversation with the bot.

The bot asked registrants to solve a “preliminary” puzzle (to prepare players for what would have come later and to work as some kind of captcha), how many other participants would have taken part to the game together with the team leader, and the team’s name.

Gameplay

Usually a treasure hunt game requires players to find hidden objects or reach secret locations based on some — more or less vague — clues. In our case, the actual puzzling was centered around coding questions delivered by the bot, not around recognizing locations from clues, both because coding was the theme of the game and because many participants weren’t familiar with the city. Therefore, locations to reach were given out explicitly by the bot.

The actual gameplay was structured as follows:

1. Each group gets a random location to reach (sent as a precise geographical location and rendered as a point on a map).
2. On reaching its assigned location, the group snaps a selfie and sends it to the bot.
3. The bot picks one of the coding puzzles and waits for the group’s answer. A minimum delay of 1 minute between attempts is required.
4. If the solution is correct, the bot gives out a new clue for the final puzzle.
5. Go to 1.

Location, location, location

We identified 30 well-distributed locations around the town, which we marked with a description, a precise GPS location, a numeric ID, and a secret code (16 random alphanumeric characters).

Each location had its own secret 16-character code.

How did the bot ensure that a group has reached its destination? Easy. We printed 30 paper signs (on A4 sheets), one for each location, with a special QR Code linking to an URL following this scheme:
https://telegram.me/treasurehuntbot?start=0123456789ABCDEF

This link makes use of the deep linking feature of Telegram: after opening the URL through a QR Code scanner, the user’s phone automatically starts the Telegram client and sends the “/start 0123456789ABCDEF” string to our bot, without actually displaying it inside the conversation screen. Since each QR Code contained the location’s secret 16-character code inside the URL, the bot would know with certainty which code the group had scanned and thus which location was reached.

The bot tracked each group making its way through a sequence of 12 locations. To ensure that groups of players do not follow each other and that they don’t cluster in the same area, the sequence of locations to reach for each group was chosen at random.

In order to ensure fairness, sequences of locations were generated beforehand with a bounded maximum (and minimum) length.

Puzzling

Puzzles — which were given out as soon as a group reached a location and sent a confirmation selfie of the group — were based on the CodyRoby quizzes . These simple logical puzzles make use of shared conventions, like the colored pseudo-code blocks from Blockly used in Code.org and the CodyRoby coding cards.

All puzzles required at most a couple of minutes to be solved and the answer could be provided as a simple text message, usually with a single character or a single number. Answers would be accepted quite liberally, with whitespace, in upper or lower case, and with any formatting. Wrong answers caused a forced delay of 60 seconds before the next attempt.

Correct answers not only let the group move forward, but they also rewarded the group with an important clue that would then be used to solve the last riddle: as soon as a group reached the last location (which we made sure was the same for all groups), they were given a map (like, a real, tangible, honest to goodness map made out of paper) that could be used to find out the exact place where the coveted prize was hidden.

The first group that reached it would get to keep the prize and receive another wonderful QR Code. Who doesn’t love QR Codes anyway? This last code signaled that the game was over for everyone.

A Telegram channel was used to broadcast information, to share selfies, and to make the game more engaging.

The Urbino Code Hunting Telegram channel was created on the day of the game and all participants were invited to subscribe to it. Major advancements of the groups were broadcast on the channel, along with all selfies taken by the groups as soon as they were sent in from the various locations. The channel gave the participants and us a way to monitor the state of the game, thus making it more engaging as the groups got closer to their final destination.

The bot was powered by a PHP application and a MySQL database, patched together in less than a week.

The source code has been published on Github under the MIT license if you want to take a look. At the moment, deploying the bot for your own backyard treasure hunt might not be the easiest of tasks, but we are already planning to make it reusable at will.

(And we have other significant — and scary? — plans for the future…)

This post was first published on the blog of the Applied Computer Science course at the University of Urbino.

Il primo incontro inizia con una rapida overview dello stato dell’arte della tecnologia, dei problemi da risolvere e delle opportunità che ci offrono, e si finisce con un ampio spazio per fare networking. In mezzo c’è la possibilità di presentare un proprio talk: chi ha qualcosa da mostrare, progetti in corso o sogni nel cassetto, può mandarmi un messaggio (sono l’organizzatore). Sono sufficienti cinque minuti e non sono necessarie slide. Edit 12/09: abbiamo tre talk, vedete il programma a fine post. C’è ancora spazio per proporsi. Edit 19/09: i talk sono diventati quattro e il programma della serata è chiuso. Però è aperta la call for speakers per la serata successiva!

Però c’è qualcosa di più importante. Se state leggendo questo blog è perché i chat bot vi interessano e credete nel loro futuro. Se siete della zona di Milano verrete a questo meetup (iscrivetevi!), ma se vivete o lavorate altrove vi invito ad organizzarne uno vostro con cui attirare altre persone come voi e fare squadra per dare forza a questo interesse. Createne uno subito e scoprirete chi altro c’è nella vostra zona. E se non vi va di usare meetup troverete mille altri modi per organizzarvi. Siete pronti? Via!

Programma della serata

Inizio alle 19:00, via Venini 42 Milano.

• Keynote, di Paolo Montrasio
• RedBot, di Guido Bellomo
• Creazione di un bot Telegram passo passo, di Salvatore Cordiano, Full stack Web Developer @parallelit
• NLP e bot design, di Alessandro Vitale @alevitale https://medium.com/@alevitale https://medium.com/@Conversate

Se volete tenere un talk in una delle prossime serate mandami un messaggio.

1. Prossimo Chatbots Meetup a Milano, il 29 Settembre

L’amico Paolo Montrasio, già speaker-manager all’evento #convcomp2016 dello scorso 24 giugno, organizza il prossimo meetup a Milano; partecipate numerosi! ISCRIVETEVI!

Mentre il chatbot-day #convcomp2016 del 24 giugno è stato un primo momento di incontro globale, il prossimo meetup di Settembre è il primo meetup “standard”, cioè in orario serale “post lavoro”.

L’idea è di creare dei meetup simili in differenti città italiane (Roma, Palermo, Genova, Trento, etc.) e continuare a sviluppare il networking!

2. Presto bots su Whatsapp ?

Sì certo, i Telegram-esaltati hanno un rispettabile snobbismo rispetto a Whatsapp (io lo disinstallai dal mio telefono un anno fà), ma ammettiamolo: l’economia dei bots partirà in Italia quando Facebook permetterà di sviluppare i bots sulla chat che in Italia usa il 95% (o forse più) della popolazione.

Ed ecco una comunicazione ufficale del 25 Agosto, passata forse inosservata: WhatsApp guarda avanti

Si tratta solo di media marketing (ancora :( ) o davvero entro la fine dell’anno anche su Whatsapp sarà disponibile una piattaforma di sviluppo bots (come o uguale a quella di Facebook Messenger) ?

Piaccia o no, penso che la bots-economy partirà in Italia quando sarà possibile sviluppare applicazioni su Whatsapp. Che ne pensate ?

3. Il blog www.convcomp.it

Usate questo blog! Postate i vostri articoli/news e commentate gli articoli! Tutte le istruzioni qui. Per ogni ulteriore info/proposte/etc. non esitate a contattare via mail la redazione: mailto:info@convcomp.it

Giorgio, 8 Settembre

Lo scenario che si presenta per quelle aziende che scelgono di rimpiazzare il lavoro umano con sistemi di intelligenza artificiale automatizzati è attualmente incerto.
E mentre al contributo umano vengono ancora riconosciuti meriti indispensabili, i leader delle grandi aziende stanno esplorando sempre più opportunità per aumentare l’efficienza dei propri servizi e diminuirne i costi di gestione grazie all’uso dei sistemi di IA.

Grazie al continuo perfezionamento degli sviluppi tecnologici, le macchine saranno presto in grado di svolgere sempre più mansioni che prima erano gestite esclusivamente dagli esseri umani: le aziende, però, dovrebbero pensare attentamente prima di rimpiazzare un essere umano che è in grado di trovare soluzioni innovative ai problemi che gli si presentano, con un’intelligenza artificiale e, soprattutto, accertarsi di quali siano le preferenze dei propri clienti prima di apportare grandi cambiamenti.

Intelligenza artificiale : sono molti gli interrogativi in tal proposito.

Nel campo del Customer Care, nonostante un sistema dotato di intelligenza artificiale sia in grado di reperire velocemente qualunque tipo di informazione e fornirla al cliente che la richiede, è ancora necessario il contributo umano per stabilire una reale connessione con i clienti? Ad esempio, la gentilezza, l’empatia, la comprensione che è in grado di offrire un essere umano, potranno essere rimpiazzati dall’efficienza robotica?

Potremmo dire che gli esseri umani ed i robot siano da considerare semplicemente come due modi differenti di offrire un servizio, e che il trade-off tra i due sia strettamente legato al modo in cui i dirigenti concepiscono la gestione del Customer Care aziendale.
Ciò non deve far dimenticare, però, che persino le mansioni più ripetitive e noiose possono essere migliorate, modificate, innovate o interamente ristrutturate solo da una mente umana: un’intelligenza artificiale non è in grado di suggerire simili modifiche, solo una mente creativa lo è.

Per fare un esempio, la Toyota, nota casa automobilistica, ha iniziato ad inserire operatori in carne ed ossa in ruoli che prima erano di stretta competenza delle intelligenze artificiali. Il cambiamento è stato fatto per aumentare la competitività dell’azienda stessa, ed ha riguardato aree come la forgiatura dei metalli, così che gli operatori possano sviluppare nuove competenze e trovare nuovi modi per migliorare ulteriormente il sistema di produzione.

“Non è possibile dipendere dalle macchine che possono solo ripetere gli stessi compiti all’infinito”: queste le parole di Mitsuru Kawai, Senior Managing presso Toyota. “Per essere padroni delle macchine, è necessario avere la conoscenza e le competenze da insegnare alle macchine stesse”.

L’esempio diametralmente opposto è invece fornito dalla Foxconn, azienda tra i principali fornitori della Apple, che ha di recente sostituito 60mila dipendenti con i robot con l’intento di ridurre drasticamente i costi di produzione aumentandone, allo stesso tempo, l’efficienza.

Esiste una giusta via di mezzo.

Considerato che le ricerche condotte in tale ambito hanno dimostrato che i clienti vogliono interagire sia con operatori reali che con sistemi dotati di intelligenza artificiale, sta alle aziende trovare il modo di bilanciare i punti di forza e le debolezze di entrambe le parti.

Per la prima volta si è giunti al punto in cui i consumatori stessi non pongono limite alle scelte dell’azienda in tale campo, mostrando interesse sia per le soluzioni digitali che per la possibilità di interagire con un operatore dotato non soltanto di intelligenza, ma soprattutto di empatia.

Secondo un recente studio della Accenture Study , l’83% dei consumatori degli Stati Uniti d’America preferisce interagire con gli esseri umani invece che con i sistemi di intelligenza artificiale per risolvere i problemi di Customer Service che si presentano, nonostante rimanga netta la preferenza di un servizio multicanale.

Una situazione in evoluzione.

Facebook ha di recente creato dello scalpore nel campo del Customer Service, con il debutto del chatbot per la piattaforma Messenger. Mark Zuckerberg stesso, CEO del colosso social, ha dichiarato che le chatbot renderanno le aziende in grado di comunicare con i loro clienti esattamente come fanno con i loro amici o con la famiglia proprio grazie a Messenger.

Zuckerberg alla conferenza F8 della compagnia, ha poi spiegato che gli sviluppatori saranno in grado di creare delle chatbot dotate di Intelligenza Artificiale in grado di comprendere il linguaggio naturale e di capire quali siano i bisogni degli utenti.

Pare però che i chatbot di Mr. Zuckerberg siano ancora lontani dal funzionamento ottimale: molti reports asseriscono che persino le richieste più semplici come il visualizzare un prodotto sono meno efficienti dell’andare direttamente nel sito in questione e cercare il prodotto da sé.
Nonostante tali bug iniziali, è probabile però che in un relativamente breve arco temporale si riesca a raggiungere dei risultati sorprendenti, e che la chatbot di Facebook diventi uno dei principali canali di comunicazione tra il cliente e l’azienda.

È importante ricordare che è solo l’inizio dell’utilizzo di questi sistemi di assistenza e che solo poche aziende hanno accesso alla tecnologia necessaria per usufruirne.

Al momento l’utilizzo misto di entrambe le soluzioni è quanto di meglio le aziende possano offrire ai loro clienti per garantire un servizio e un’assistenza efficiente, ottimale e soprattutto umana.

Roberta Gallo

I fully agree with your concerns about bots made just for developers. I call this approach: “hard coding” a bot. I full agree also about the necessity of a teamwork made by no-developers experts (on “conversational” UX, marketing, customer care, psychology, etc.)

there’s a GUI for designers to easily drag and drop logic blocks or messages to finish a flowchart on canvas. Developers then can connect the webhook and implement required functionalities based on the flowchart.

I have some doubts about the graphical tools you underline. Do you perhaps remember the hype in 90’s about these RAD (rapid application development) visual building tools (“GUI Lego”) that generate code … (e.g. I worked with some Smalltalk products many years ago)… but we have to admit they wasn’t a real success; in fact nowadays in 2016 we don’t use them anymore (more or less).

Now, back to the chatbots develop realms (#botdev), I’m a huge fan of scripting languages… because I think here we have the real decoupling of competences: dialog flow experts work on dialog scripts and usual programmers work on back-end services.

That’s why I’m fan of ChatScript and I’m support this great open source project, see draft article here:

Build your first chat bot with ChatScriptAn introduction for beginners (with an opinion on chat bot engine architectures)medium.com

and see also my previous notes:

Supescriptjs as dialog script / knowledge interchange languageHi Rob! I only recently discovered www.superscriptjs.com. I like your tech structured solution(s) and above all I thank…medium.com

Decoupling business logic with dialog flow scriptingHi Matthias!medium.com

In my vision, as developers of complex disrupting chatbots products and services, we need a common/shared scripting language with a standard syntax (e.g. I propose ChatScript language syntax and an evolution of that) to create reusable chatbots “functionalities” (= knowledge base reuse).

So, even if the supposed GUI Lego composition tool could help to set-up simple (chatbots) applications, immo a real evolution will start with the spread of common scripting language, with all related benefits of a human (and machine) knowledge “as source code”: that will allow to share source code scripts (in the open source community, as you rightly mention github!), to do analytics and (human or machine) post processing, etc. etc.

my two cents
giorgio

Abbiamo parlato varie volte delle chatbot e della loro importanza nel customer service odierno; abbiamo inoltre affrontato varie volte la questione che ne consegue e che vede “scontrarsi” automazione e umanizzazione, e quindi tecnologia e tocco umano.

Proviamo a vedere, quindi, cosa andrebbe automatizzato del customer service all’interno di un’azienda e cosa, al contrario, andrebbe affidato alle risorse umane.

Il trend che ha circondato l’annuncio della chatbot di Facebook ha fatto si che alcune persone pensassero a una presa del potere in stile Transformers del customer service da parte dei bot.

L’introduzione delle chatbot all’interno della sfera del customer service digitale è sempre più sorprendente perché i bot si dimostrano, a tutti gli effetti, veloci e molto efficienti. Ma gli esseri umani hanno ancora un ruolo importante da giocare all’interno dell’assistenza clienti e sempre lo avranno. Potrebbe suonare meno drammatico di un colpo di stato delle chatbot, ma il futuro del customer service sta proprio in un equilibrio tra automazione e tocco umano.

Conoscere gli innegabili vantaggi delle chatbot e farne uso, dando comunque agli operatori la libertà di connettersi con i clienti sarà proprio la chiave per fornire un servizio personalizzato ed efficiente che piace ai clienti e ispira la loro fedeltà.

Spesso, si guarda all’era in cui il customer service non era digitalizzato come a un periodo migliore, con persone vere che aiutavano i clienti e che sviluppavano solide relazioni cliente-azienda. Internet ha costruito una sorta di muro tra aziende e clienti, rendendo il customer service digitale potenzialmente più veloce, ma per certi versi anche più impersonale.

La soluzione al dilemma non sta sicuramente nel non usare più la tecnologia, poiché le chatbot e il customer care digitale possono essere proprio gli elementi caratteristici che permettono alle aziende di ottimizzare e semplificare il customer service.

Non c’è dubbio che ormai abbiamo raggiunto un momento critico, dove ognuno sta iniziando a realizzare l’importanza della customer experience e i brand hanno bisogno di superare questo muro digitale.

L’83% degli utenti americani, ad esempio, preferisce avere a che fare con esseri umani piuttosto che interfacciarsi con mezzi digitali per risolvere problemi di customer care, secondo una ricerca di Accenture.

Ma questo non significa che la tecnologia è diventata di colpo inutile.

Al contrario, le chatbot e le tecnologie avanzate di customer service sono più importanti che mai. Infatti, aziende più lungimiranti useranno proprio l’automazione per riportare l’essere umano nell’equazione della customer service.

L’inizio di una splendida amicizia

Amiamo la tecnologia e siamo grandi fan dell’innovazione.

Ma la tecnologia da sola non può fornire un customer service eccellente, perché i clienti vogliono comunicazioni personalizzate e con gli esseri umani.

Questo è il motivo per cui il 52% degli utenti hanno cambiato aziende nell’anno passato a causa di una customer care inefficiente, che non ha agevolato il contatto fra i propri clienti e propri operatori dell’assistenza clienti.

I bot sono preziosi, soprattutto quando si ha anche l’opportunità di parlare con un operatore, che per sua natura è empatico e reattivo.

Pensiamo alle storie molto popolari che abbiamo sentito su aziende diventate famose per aver dato un customer service memorabile, tipo Zappos, oppure Netflix o Amazon.

È difficile immaginare queste aziende guidate solo dalle chatbot per quel che riguarda l’assistenza clienti. Ma è anche difficile immaginare questo straordinario livello di customer service possibile se gli operatori non avessero avuto o non avessero in generale una tecnologia a disposizione.

I vantaggi dell’automazione nel customer service sono troppo grandi per essere ignorati.

Abbiamo la tecnologia a disposizione, perché non usarla?

Il punto sta nel sapere quando utilizzare l’automazione e quando invece affidarsi agli esseri umani.

Per farlo occorre fare delle considerazioni su cosa gli umani possono fare meglio e cosa invece è possibile lasciar fare ai bot.

Cosa dovrebbe essere automatizzato?

Dicevamo che un customer service degno di nota non è possibile senza tecnologia.

Le chatbot hanno tutti i vantaggi dei computer, sono veloci, sono logici. Nel futuro, i call center beneficeranno di tutto ciò che i bot hanno da offrire, ma si affideranno a questi solo per quel che riguarda le cose in cui riescono meglio, ossia l’assistenza di primo livello — il primo contatto — per domande ripetitive e frequenti e per richieste che per loro sono facili da risolvere.

Ci sono scenari molto positivi per le aziende che sanno come far lavorare l’automazione per loro.

Come punto di partenza iniziale, tutte le aziende dovrebbero offrire delle live chat proattive.

Le chatbot automatiche cercheranno di scovare gli utenti che danno un’occhiata al sito e li contatteranno in base a ciò che stanno cercando. Questo tipo di proattività ha effetti positivi sia sulle vendite che sulla customer satisfaction, ma è spesso un carico di lavoro molto grande se a eseguirlo sono delle risorse, soprattutto quando i clienti sono molti e il team è piccolo. I bot danno quindi la libertà agli operatori di svolgere altri importanti compiti.

Un sistema di smistamento ticket è un’altra caratteristica vitale del customer service automatizzato. Uno smistamento intelligente soprattutto nel customer service digitale dove le aspettative per una risposta veloce e personalizzata sono molto alte, è il modo migliore per comprendere entrambi i mondi.

Il massimo sarebbe usare la tecnologia per portare gli utenti verso gli operatori reali se e quando ne hanno bisogno.

Cosa dovrebbe avere il tocco umano?

In futuro, quindi, gli operatori si concentreranno sulle richieste complesse.

Fondamentalmente, la tecnologia si occuperà di tutto ciò che è ripetuto, “liberando” le risorse umane e permettendo loro di fare ciò che riescono meglio, comunicare con i clienti sfruttando la propria naturale empatia.

Questo sarà un cambiamento sistematico nel modo in cui pensiamo e mettiamo in atto il customer service.

Per fare in modo di coltivare il tocco umano nel customer service, le aziende dovrebbero fare tre cose:

• Riconoscere l’importanza dell’empatia
• Favorire continuamente connessioni personali
• Favorire continuamente punti di contatto con i clienti

Il customer service dovrebbe essere sempre meno “soddisfare” semplicemente gli utenti e sempre più far provare un’esperienza di customer service piacevole e senza problemi.

Ma anche nella fase iniziale, prima di fare un acquisto su un sito ad esempio, le chatbot possono mettersi in contatto con il cliente e guidarlo.

I bot si occupano dei problemi risolvibili, portando i clienti verso gli operatori che possono poi sviluppare e sostenere relazioni con gli utenti di volta in volta. Questo tradotto significa fedeltà del cliente.

L’equilibrio tra automazione e umanizzazione. dunque, avrà successo utilizzando i vantaggi della tecnologia senza trascurare i contatti umani vecchia maniera.

Vuoi provare un servizio di assistenza clienti che mescoli automazione intelligente e tocco umano?

Provaci, gratis.

Valentina Mangia

L’Intelligenza Artificiale è sempre più utilizzata al fine di integrare le interazioni cliente-azienda con i servizi più innovativi e completi, come le chatbot.

Ma quali misure possono adottare le aziende per sfruttarla al meglio?

Trovare il giusto equilibrio tra l’automazione e l’elemento umano è la chiave del successo.

Commettere un errore nel Customer Care, ad oggi, significa per un’azienda rischiare di perdere per sempre un cliente e di danneggiare irrimediabilmente la propria immagine.
Oggi i consumatori hanno esigenze sempre più raffinate, pretendono una gratificazione immediata qualunque sia il servizio che richiedono e le limitazioni nella fornitura di tali servizi, come tempi d’attesa catastrofici o personale non addestrato, causano danni terribili a quelle aziende che non sono ancora al passo con queste esigenze.

Si stima che circa i due terzi dei clienti abbandonano le aziende a causa di un Customer Service scadente, così che quando Zuckerberg nella conferenza F8 di quest’anno ha parlato di un nuovo servizio rivolto ai clienti in grado di soddisfarli pienamente, è sembrato mostrasse il nirvana alle aziende in ascolto.
I possessori di Smartphone interagiscono quotidianamente con i bot, dai messaggi di testo per le prenotazioni automatiche, le spedizioni o i pagamenti, all’uso di Siri, Cortana e Google Now. In molti però non sanno ancora cosa siano le chatbot e quale sia il loro reale potenziale nell’ambito del Customer Care.

Innumerevoli aziende e opinionisti hanno discusso su come questa tecnologia rivoluzionaria cambierà tutto. Si prevede che i bot in pochi anni saranno il principale punto di interazione tra le aziende e i clienti. La tecnologia a riguardo sarà impegnata in un tour de force che porti al massimo le prestazioni garantendo l’efficienza di ogni servizio.

La Customer Experience sarà portata ad un livello sempre più alto.

Siamo giunti ad un bivio in cui le aziende ormai solide devono scegliere se restare indietro nel tour de force tecnologico o investire per competere con le start-up.
La messaggistica mobile e l’integrazione dell’assistenza sui social si basano oramai sul principio di offrire al cliente il servizio migliore, consentendo loro di connettersi ovunque si trovino e di risolvere istantaneamente le problematiche più comuni.
Le aziende in grado di padroneggiare queste tecnologie saranno in grado di prosperare nell’ambiente cliente-centrico che si sta sviluppando. Quelle che, invece, non saranno in grado di rinnovarsi e stare al passo con le nuove tecnologie, non rischiano di perdere soltanto il primato nel loro settore, ma di avere forti perdite di guadagno.

Trovare il giusto equilibrio tra automazione ed elemento umano è la chiave per un buon servizio clienti. Anche se le chatbot sono in grado di risolvere i problemi più semplici e comuni che un utente possa porre, è importante offrire sempre la possibilità all’utente di avere un supporto umano, in grado di arrivare là dove la chatbot non può.

La sorprendente innovazione dei bot è relativa al fatto che, quando non è più loro compito rispondere all’utente ed è necessario l’intervento umano, il passaggio avviene in maniera immediata e nella massima efficienza.

A breve i migliori team di Customer Care saranno quelli in cui vi è sia la presenza delle Intelligenze Artificiali più all’avanguardia che l’esperienza umana pronta a intervenire ad ogni necessità. Le aziende, anche le più solide, non possono permettersi di perdere gli utenti per errori attribuiti ad un sistema fallimentare, per questo software e operatori avranno pari importanza nella gestione del Customer Care.

Le chatbot, benché basate su avanzate forme di Intelligenza Artificiale, non sono ancora in grado di affrontare le situazioni più complesse e dalle molteplici sfumature che i clienti possono presentare quotidianamente.

Quindi, se da un lato è giusto essere entusiasti per la possibilità di offrire i bot di assistenza ai propri clienti, è fondamentale ricordare che la ragione principale per cui le persone amano i servizi di messaggistica è perché credono vi sia un essere umano pronto a rispondere all’altro capo della linea (e per questo motivo anche i messaggi automatici dovrebbero essere quanto più umani possibile).

Il valore delle Chatbot

Il valore reale della chatbot è la possibilità di integrare molteplici servizi al cliente in un’unica, completa, piattaforma, fino a giungere all’offerta di un servizio Omnichannel.
Progettate per simulare una conversazione reale, le chatbot sono perfette per alcune attività semplici come effettuare una prenotazione, ordinare un prodotto, essere avvisati sugli aggiornamenti di una consegna.
Tuttavia, quando è necessario avere un aiuto supplementare, il cliente deve essere in grado di passare senza problemi dall’assistenza offerta dalla chatbot a quella offerta da un operatore.
I clienti hanno la necessità di sapere che ci sarà qualcuno disponibile, pronto ad ascoltare i loro problemi se la chatbot non dovesse essere in grado di risolverli.

Ed è proprio questa capacità di soddisfare le esigenze di ogni cliente che fa tutta la differenza in termini di Customer Experience.

La soddisfazione del cliente è fondamentale per il successo aziendale.

Dal punto di vista degli operatori, le chatbot alleggeriranno moltissimo il loro lavoro e la qualità del lavoro stesso, occupandosi della gestione delle richieste banali e ripetitive. Questo filtro basato sulla qualità della richiesta, permetterà di diminuire drasticamente i tempi di attesa, formando un servizio di Customer Care efficace e tempestivo, pronto a risolvere le problematiche più complesse perché non impegnato con quelle quotidiane e semplicistiche.

La necessità di interagire con altri esseri umani non potrà mai essere sostituita da altro: le chatbot non porteranno alla morte della figura degli operatori, ma ridefiniranno il servizio offerto in termini di qualità e rapidità.

Roberta Gallo

Chatbots can help you get things done right inside chat tools like Facebook Messenger, Telegram Messenger, Slack, etc, etc. Just say the word and your chatbot will deploy your latest build, or order you a pizza.

And there’s a special tool for building chatbots that’s been around for quite some time. It’s called ChatScript. And like Slack, it started out as just a small part of a video game.

Back in 2009, Bruce Wilcox was working as a game developer and artificial intelligence researcher. His wife, Sue Wilcox, wanted to model virtual characters for her interactive fiction games. Together, they built what ultimately became ChatScript.

This natural language processing engine + dialog flow scripting platform helped Bruce win the Loebner AI Prize three times.

Bruce still develops and maintains the project today. It’s written in C and C++, and is open source. In fact, version 6.8 just came out a few weeks ago.

ChatScript is one of few OPENSOURCE chatbots NLProc engines!

Let’s dive into the basics of ChatScript and meet a chatbot named Harry.

Installing ChatScript

Some of these steps may be a bit different depending on what operating system you’re using. I’m using Linux. You don’t actually have to go through these steps to enjoy this article if you don’t want to. Just read along.

Step 1: Install the system components on your local computer

First of all clone the ChatScript GitHub repository:

$ git clone https://github.com/ChatScript/ChatScript

This will create a ChatScript directory, which will contain these subdirectories:

$ cd ChatScript/
$ ls -d1 */

BINARIES/
DICT/
DOCUMENTATION/
LINUX/
LIVEDATA/
LOEBNERVS2010/
LOGS/
MAC/
RAWDATA/
REGRESS/
SERVER BATCH FILES/
SRC/
SUBLIME TEXT EDITOR/
TMP/
TOPIC/
USERS/
VERIFY/
VS2010/
VS2015/
WEBINTERFACE/

• DOCUMENTATION contains wiki documentation files.

BTW, I personally contributed to update all the original documentation in markdown format to be read online and from command line when developing.❤

• RAWDATA contains a subdirectory for each bot. By default, the platform comes with a default bot named Harry, who is located at RAWDATA/HARRY.

BTW, please remember to set LinuxChatScript64 executable:

$ chmod +x ChatScript/BINARIES/LinuxChatScript64

Note: obviously here above I’ considering the Linux OS environment. 
More info about Linux, MacOS or Windows installation here.

Step 2: To run CS engine in standalone mode:

$ BINARIES/LinuxChatScript64 local

Running the engine will launch Harry, with whom we can then talk:

ChatScript EVSERVER Version 6.8  64 bit LINUX compiled Aug 16 2016 17:35:43 host=local
Params:   dict:720895 fact:800000 text:70000kb hash:50000
          buffer:22x80kb cache:1x5000kb userfacts:100
WordNet: dict=201350  fact=85710  stext=12703744 Jul26'16-21:58:46
Build0:  dict=67726  fact=130289  stext=1145656 Jul31'16-13:45:49 0
Build1:  dict=167  fact=15  stext=211304 Jul31'16-13:45:44 harry
Used 53MB: dict 269,244 (23693kb) hashdepth 18/1 fact 216,014 (8640kb) text 14183kb
           buffer (1760kb) cache (5000kb) POS: 918 (29kb)
Free 79MB: dict 451,651 hash 924 fact 583,986 text 55,816KB

Enter user name: giorgio

HARRY:  Welcome back
giorgio: > what is your name ?
HARRY:  My name is Harry.
giorgio: > who is Bruce Wilcox?
HARRY:  Bruce Wilcox (born 1951) is an artificial intelligence programmer.
giorgio: > ok, I have to go
HARRY:  Indeed.
giorgio: > :quit
Exiting ChatScript via Quit
$

Step 3: Code and debug your chatbot scripts

Standalone mode makes for an excellent ChatScript development environment. It allows you to run interactive conversations, then interact with them using :commands. This is a special set of interactive command tools for testing and debugging your dialogs during the development and debug phase.

Here are a few example commands:

# recompile the bot Harry and reset the status of conversations with user giorgio

giorgio: > :build Harry 
giorgio: > :reset

# request statistics about topic ~pets

giorgio: > :topicstats ~pets
    ~pets     gambits 2 responders 2 rejoinders 5 empties 0
Concepts 1860 Topics 1 rules 9 empties 0
  gambits 2  responders 2 (?: 2 s: 0  u: 0) rejoinders 5

# conversation ...

giorgio: > do you like snakes?
HARRY:  I love pythons except ^"Python" (the programming language)

# ask the reason why a rule fired

giorgio: > :why
~pets.2.0.5.9.0  ?:  ( << you like snake >> ) I love pythons except Python ( the programming language )
 via ~control.5.9.0  u:  ( ) $$currenttopic = %topic ^if 00m( %response  0 ) 00I{ ^nofail ( TOPIC ^rejoinder ( ) ...

Note that you can run :commands to show the full list of available commands.

Topics are contained in specific files. For example, the ~pets topic code is contained in pets.top file, which looks like this:

topic: ~pets (dog cat pet animal bird fish snake)

?: ( << you like snake >> )
 I love pythons except ^"Python" (the programming language)

?: ( << you ~like ~animals >> ) 
 I love all animals.

t: Do you have any pets?
 #! yes
 a: ( ~yes ) Great. You like animals.

#! no
 a: ( ~no ) You don’t like animals?

#! I have two parrots
 a: ( parrots ) Birds are nice.

#! I have a cat
 a: ( cat ) I prefer dogs

#! I have a canary
 a: ( [parrot bird canary finch swallow] ) Birds are nice.

t: I have a dog.

ChatScript is a rule-based engine, where rules are created by humans writers in program scripts through a process called dialog flow scripting. These use a scripting metalanguage (simply called a “script”) as their source code.

Here what a ChatScript script file looks like:

#
# file: food.top
#

topic: ~food []

#! I like spinachs
s: ( I like spinach ) 
   Are you a fan of the Popeye cartoons?

a: ( ~yes ) 
       I used to watch him as a child. Did you lust after Olive Oyl?
     b: ( ~no ) Me neither. She was too skinny.
     b: ( ~yes ) You probably like skinny models.

a: ( ~no ) What cartoons do you watch?
     b: ( none ) You lead a deprived life.
     b: ( Mickey Mouse ) The Disney icon.

#! I often eat chicken
u: ( ![ not never rarely ] I * ~ingest * ~meat ) 
   You eat meat.

u: ( !~negativeWords I * ~like * ~meat ) You like meat.

?: (do you eat _ [ ham eggs bacon]) 
   I eat ‘_0

?: (do you like _* or _*) 
   I don’t like ‘_0 so I guess that means I prefer ‘_1.

s: ( ~like ~fruit ![~animal _bear] ) 
   Vegan, you too...

?: (do you eat _~meat) 
   No, I hate _0.

s: ( I eat _*1 >) 
  $food = ‘_0 
  I eat oysters.

You can define your bot’s dialog flows with a script stored as a normal text file. This is much simpler than methods that other chatbot tools use, which often involve browser-based user interfaces, JSON, or XML.

Writing your scripts as a text files gives you full control over your dialog flows. You a can easily process and upgrade your conversational code with back-end scripts and tools.

For example, you could automatically update ChatScript dialog rules based on records in your database.

You could even use machine learning tools to mine conversations logs. This could reveal all kinds of opportunities for you to improve your dialog flows.

But these are topics for a future ChatScript article. I’ll leave you to go play with ChatScript on your own.

Please contribute to its open source codebase, and star it on GitHub!🌟🌟🌟🌟🌟

ChatScript/ChatScriptContribute to ChatScript/ChatScript development by creating an account on GitHub.github.com

Video L’intervento inizia al tempo 2:08:33.

Nell’ultimo periodo le interfacce conversazionali, in particolare quelle usate da Bot ed agenti automatici che sfruttano canali di conversazione prevalentemente testuali nell’interagire con utenti umani, stanno suscitando sempre più interesse e sono sempre più al centro di sviluppo ed innovazione.

Tuttavia, i Bot rappresentano in realtà un tuffo nel passato: rispetto alle interfacce più comuni che troviamo oggi per interagire con i servizi, siti web, interfacce touchscreen, e applicazioni mobili, dialogare in maniera testuale con un computer che simula una personalità umana ricorda il futuro ipotetico che ci si prefigurava nei film degli ultimi anni ’80.

L’evoluzione che ci porta ai Bot conversazionali odierni ha moltissimi paralleli con l’evoluzione di tutte le maggior piattaforme, incluso Internet. Alla base della madre di tutte le reti si trovano infatti vari protocolli di comunicazione elettronica, stratificati. Ognuno di essi con un proprio scopo e delle peculiarità, che formano una piattaforma che può essere sfruttata da protocolli superiori ed applicazioni. L’applicazione, basata su questi protocolli alla base di Internet, che esplode in termini di popolarità è proprio il web.

Il World Wide Web: la piattaforma globale, dinamica e flessibile.

L’accesso al web tramite browser ed i succitati protocolli diventa fondamentale e guadagna di diffusione: presto il web diventa esso stesso la piattaforma per altre applicazioni. Applicazioni che facevano già parte di Internet, ma non del web, e che sfruttavano un protocollo di “pari” dignità — come ad esempio l’e-mail con l’avvento delle webmail — migrano e diventano sempre più popolari attraverso il web stesso.

Il web è la piattaforma dominante: l’interfaccia più flessibile, dove tutta l’utenza è già presente.

La piattaforma più di basso livello offerta è quella del computer in quanto macchina, la piattaforma hardware, sulla quale si costruisce la piattaforma software, il sistema operativo, che fa da piattaforma alle applicazioni. Applicazioni tra le quali il web browser è sicuramente dominante. L’importanza del web browser era già visibile nel successo dell’iPhone del 2007, dove le capacità della piattaforma non erano date dalla possibilità di installare applicazioni — ancora assenti — ma da quella di disporre di un browser moderno, compatibile con tutto il web.

“Instant messaging”: la piattaforma cross-platform.

Nel campo dello smartphone si è vista un’evoluzione simile: da un sistema in cui l’esperienza d’uso degli utenti era dominata dal sistema operativo stesso, con l’apertura ad applicazioni di terze parti, sono le applicazioni stesse a determinare il modo in cui gli utenti sfruttano il dispositivo. Applicazioni mobili che sono disponibili su diverse piattaforme offrono spesso un’esperienza d’uso cross-platform, che diventa propria e distinta da quella offerta dal sistema. Offrendo dei servizi per sviluppatori, l’app diventa a sua volta una piattaforma.

Le app di messaggistica offrono l’esperienza d’uso alla quale gli utenti sono già abituati.

Le app di messaggistica offrono un’esperienza d’uso, dei servizi e — soprattutto — una ricchezza di utenti già attivi. Come il web ed il browser hanno vinto contro le applicazioni native, semplicemente offrendo un mondo più comodo, senza barriere all’ingresso, così le piattaforme di messaggistica possono avere successo. I Bot e gli altri servizi messi a disposizione da questi servizi si appropriano semplicemente dell’esperienza d’uso che gli utenti hanno già scelto da tempo.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot, intelligenza collettiva, e della loro implementazione.

Questo articolo è stato pubblicato originariamente sul blog del Corso di Laurea di Informatica Applicata presso l’Università degli Studi di Urbino.

Come visto nel precedente articolo, le app di instant messaging offrono una nuova piattaforma per l’offerta di servizi che ha dalla sua — come lo era stato per la nascita della piattaforma del web — la presenza di un vastissimo numero di utenti già attivi, già abituati all’esperienza d’uso della piattaforma e che sfruttano già i servizi della piattaforma con profitto.

L’interesse per i Bot e le interfacce conversazionali sfruttati all’interno delle applicazioni di messaggistica testimoniano in qualche modo la naturale tendenza a non re-inventare la ruota: in presenza di un sistema esistente e con un grande valore dato dalla presenza di utenti e servizi — come può esserlo una piattaforma di messaggistica — vale sempre la pena sfruttarla per costruirci qualcosa sopra.

L’interesse per i Bot è testimone della convergenza su interfacce di livello sempre più alto.

L’intelligenza collettiva è il principio per cui una massa di persone può acquisire una consapevolezza o una conoscenza emergente, grazie alle interazioni dei propri membri, che la massa nella sua interezza percepisce, ma che non è possibile avere individualmente.
Wikipedia ne è l’esempio più classico, ma la presenza massiccia di utenti e la loro libera interazione grazie alla rete rende tutte le piattaforme online particolarmente indicate per esempi di intelligenza collettiva.

Intelligenza collettiva è la consapevolezza emergente dalle interazioni di una massa di persone, che non dipende e non è ottenibile dai singoli individui.

Applicando gli stessi principi alla manutenzione dell’infrastruttura stradale, mentre i singoli automobilisti sono consci della qualità della strada sulla quale stanno guidando, se ci fosse un modo per registrare la qualità delle strade in maniera oggettiva, trasmetterla, metterla insieme e tenerla aggiornata senza oneri, allora conosceremmo lo stato di tutte le strade — sulla base di un fenomeno osservabile dai singoli individui, ma non generalizzabile in automatico.

Questa applicazione esiste e si chiama SmartRoadSense. È stata sviluppata presso l’Università di Urbino e permette di tener traccia della qualità delle strade in maniera automatica, per comporre una mappa nazionale (e in futuro, globale) della qualità delle infrastrutture.
SmartRoadSense è, per ragioni tecniche, un’applicazione, ma nulla toglie che anche i Bot possano giocare una parte in un sistema di intelligenza collettiva.

Usare Bot per raccogliere informazioni, piuttosto che diffonderle.

Raccogliere dati, creare informazioni, fare domande e semplificare l’interazione con gli utenti sono tutte abilità per le quali i Bot sono nati. Invece che funzionare solo da assistenti o (per il momento) innaturali sorgenti di informazione, i Bot possono raccogliere dati e quindi creare informazioni aggregate che non esisterebbero senza la partecipazione degli utenti.

Un esempio: raccogliere dei pensieri geolocalizzati.

Per l’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito. (Questa frase tradisce chiaramente la troppa fiducia nelle nostre capacità di programmazione.)

È un’idea semplice, realizzata in poco più di una mattinata, ma che esemplifica ciò che già da ora è possibile realizzare con strumenti molto semplici: Bot che raccolgono informazioni, integrano dati, interagiscono con utenti, legando le informazioni raccolte col territorio. Gli utenti, invece,da fruitori passivi diventano fornitori di informazioni, parti di un’intelligenza che viene raccolta, ricombinata e resa di nuovo fruibile, in maniera potenziata.

Negli altri articoli dedicati al ConvComp2016 si parla di Bot come piattaforma e della loro implementazione.

Questo articolo è stato pubblicato originariamente sul blog del Corso di Laurea di Informatica Applicata presso l’Università degli Studi di Urbino.

Come descritto precedentemente, per l’occasione dell’evento ConvComp2016 del 24 giugno, abbiamo realizzato un semplice Bot che permettesse di raccogliere pensieri, emozioni e stati d’animo geolocalizzati, in modo da dare un’idea del sentimento generale in un’area. Il Bot è online su Telegram come @wordcloud_bot ed è possibile utilizzarlo da subito per vederlo in azione.

Strumenti semplici ed aperti per realizzare il proprio Bot.

La semplicità e la rapidità con cui si sono diffusi le svariate piattaforme di messaggistica ed i loro Bot sono, in buona parte, il frutto di anni di software e livelli di astrazione che rendono, oggigiorno, la programmazione di un’applicazione o di un sistema di comunicazione sorprendentemente facile. Alla stessa maniera, l’esistenza di immani “spalle di giganti” su cui basarsi fa sì che — almeno per quanto riguarda l’implementazione di un semplice Bot — ci siano già tutti i pezzi LEGO di cui abbiamo bisogno e che combinarli per raggiungere il nostro risultato spesso possa anche essere divertente.

In questo esempio faremo uso del software che viene utilizzato come supporto didattico nel corso di “Piattaforme Digitali per la Gestione del Territorio” del Corso di Laurea in Informatica Applicata dell’Università di Urbino, che viene offerto anche come MOOC online sulla piattaforma EMMA. Il software in questione è disponibile liberamente anche su Github.

Quattro semplici pezzi LEGO per comporre un Bot.

La piattaforma di base per il nostro Bot è Telegram, che mette a disposizione un’interfaccia molto ricca per l’implementazione degli stessi. Una volta collegato con Telegram, la logica interna del Bot è implementata con uno script PHP, che sfrutta un database MySQL per memorizzare le informazioni fornite dagli utenti, la loro posizione geografica ed altri dati accessori.

Se finora le tecnologie utilizzate non mostrano particolare creatività — del resto sono le medesime su cui si basa la maggior parte dei siti web o blog degli ultimi anni — è nel rendere la conversazione del nostro Bot più credibile che possiamo sfruttare un ulteriore blocco “pronto all’uso”: Program O, un interprete basato sulle specifiche di ALICE e che permette di sviluppare velocemente dei Bot che conversano in maniera (più o meno) naturale sulla base di codice dichiarativo (una variante di XML).

La libreria d’esempio su Github mette a disposizione diverse funzioni già implementate per l’interazione con Telegram, MySQL e Program O.

Le potenzialità del remix: piattaforme, dati aperti, software libero…

Non finisce di certo qui. Riprendiamo il motto di “Everything is a Remix” per asserire che qualsiasi idea — piccola o grande che sia — e qualsiasi pezzo di software, che è possibile realizzare anche senza conoscenze di programmazione, può essere visto come il culmine di anni di astrazioni — i blocchetti del LEGO — a noi liberamente disponibili. Il prodotto dei tre fondamentali passi delineati qui sotto.

Piattaforme, dati aperti, software libero e tanti altri blocchi a portata di mano possono essere ricombinati a piacimento per creare innovazione, opportunità e conoscenza. Le interfacce conversazionali rappresentate dai Bot sono una di queste piattaforme.

Il codice di @wordcloud_bot è disponibile liberamente su Github sotto licenza MIT. Se vi viene in mente qualche brillante idea per un Bot — magari ispirato ai principi dell’intelligenza collettiva — siamo curiosi di sentirla!

Negli altri articoli dedicati al ConvComp2016 si parla di Bot come piattaforma e della loro implementazione.

Questo articolo è stato pubblicato originariamente sul blog del Corso di Laurea di Informatica Applicata presso l’Università degli Studi di Urbino.

Ciao a tutti! Bot makers & bot-players italiani!

Vi ricordo che il blog www.convcomp2016.it è a vostra disposizione per pubblicazione di articoli, condividere idee, progetti di ricerca e lavoro!

Chiunque può scrivere, i già relatori e sponsor dell’evento #convcomp2016, ma chiunque voglia presentare un problema, un prodotto, un servizio, un progetto business da sviluppare, un ambito di ricerca scientifica o tecnologica o letteraria! Spargete voce! :)

Sono inoltre benvenuti commenti ad articoli già presenti sul blog!

Come fare a scrivere sul blog ? 
Procedura e suggerimenti: Il blog ConvComp2016: istruzioni per l’uso

Per ogni info scrivi alla redazione: info@convcomp2016.it

Buoni bots (in lingua italiana, dialetto, slang o quella che volete) a tutti.
Buone vacanze!

Giorgio & Giuditta

Le Chatbot saranno il modo di comunicare del futuro.
Ma ci troviamo già agli albori di quel futuro, un futuro in cui gli uomini saranno in grado di interagire facilmente con le macchine, di cui adesso stiamo costruendo le basi dando loro la capacità di comprendere appieno il linguaggio umano.

I campi di IA che ricevono sempre maggiore attenzione sono, infatti, proprio quelli che permettono l’incremento delle capacità cognitive dei software, fornendo loro la possibilità di svilupparle al meglio. Ma nonostante i traguardi raggiunti possano definirsi stupefacenti, ci sono ancora molti progressi da fare in questo campo: dal punto di vista dell’utente non c’è ancora l’abitudine ad interagire con un software come si trattasse di un essere umano, e spesso non si hanno nemmeno le conoscenze necessarie a comprendere come con questi software bisognerebbe rapportarsi. Ciò comporta che, in alcuni casi, persino le IA programmate nel migliore dei modi possono sbagliare se ingannate dalla mente umana.

La Chatbot di Microsoft: Tay

Nel marzo del 2016 la Microsoft ha rilasciato “Tay” un chatbot basato sull’intelligenza artificiale, targettizzato per la generazione Millenials, dall’aspetto di una giovane donna. Meno di 24h dopo Tay è stata “spenta” dopo accuse di razzismo, sessismo e negazione dell’olocausto.
La settimana successiva è stata involontariamente attivata durante un test di prova e in meno di un minuto nuovamente disattivata per problemi al sistema. Tay è offline adesso, ed il suo account privato, proprio come un teenager che si mette nei guai su internet e viene punito dai genitori.
Cosa c’era di sbagliato in questo sistema di Intelligenza Artificiale talmente sofisticato da essere addirittura targettizzato per la generazione che meglio conosce il mondo di internet? Assolutamente nulla.

Nessuno potrà sorprendersi nello scoprire che un chatbot in uso sui social media, dalla forma di una ragazza e nelle mani di adolescenti, avrebbe portato ad una serie di interazioni che si trovano al limite della sfera tecnologica e più in quella socio-comportamentale. Chiunque abbia mai parlato con Siri, Cortana o qualunque altro assistente virtuale sa bene che le prime interazioni hanno solitamente a che fare con quanto di più insolito e profano si possa pensare.

La Microsoft era ben consapevole di questo rischio: Cortana, il loro assistente virtuale, è spesso soggetto a molestie sessuali, e perciò programmato per gestirle. A differenza di Cortana, non era previsto che Tay subisse un simile trattamento: era anzi previsto che imparasse dalle infinite interazioni presenti su Twitter, senza alcuno schermo o tutela.

Il risultato? Gli utenti hanno portato Tay ad asserire che “Hitler non ha fatto nulla di sbagliato”.

Se da un lato i bot come Tay sono progettati per apprendere dalle interazioni alle quali vengono esposti, il problema reale con il quale si scontrano è relativo al fatto che la maggior parte delle interazione sui social media sono sessiste, razziste etc. e che queste interazioni, nelle mani di un bot fatto per ripetere tutto ciò che apprende, possono diventare una terribile arma. In aggiunta, il fatto che la Microsoft abbia deciso di dare a questo bot l’aspetto di una ragazza tra i 18 e i 24 anni, garantiva già a priori che vi sarebbero stati dei problemi.

Ci sono dei punti fondamentali da tenere a mente quando si parla di IA: si scatena uno strano meccanismo per il quale dare una voce e un aspetto a un bot fa si che le persone vogliano metterlo alla prova nei modi più offensivi e inappropriati. Esattamente come si insegna ad un bambino la differenza tra giusto e sbagliato, anche per i bot è necessario essere addestrati per evitare questi commenti.

Proprio per questo molti assistenti virtuali sono in grado di riconoscere una serie di insulti e di rispondere in modo appropriato. Queste risposte sono il risultato di una lunghissima serie di test e miglioramenti linguistici, che permettono ai bot di interagire cordialmente, aiutare gli utenti, senza per questo finire nei guai.

Il training delle IA è indispensabile prima che vengano immesse nella rete, ma non è l’unico modo per prevenire i problemi dovuti alle interazioni inappropriate. Il modello di chatbot che sta prendendo piede ultimamente, sia per risolvere simili inconvenienti che per offrire agli utenti la migliore assistenza possibile, è quello della chat ibrida: ad un utente insoddisfatto delle risposte fornite dal bot, verrà immediatamente in aiuto un operatore, un umano in carne ed ossa che possa arrivare là dove il sistema di IA non è ancora giunto.

Come detto più volte, le ricerche recenti mostrano che sempre più gli utenti preferiscono avere a disposizione delle piattaforme self service per risolvere i propri dubbi o problemi online. La chat ibrida permette di rispondere a questa richiesta nel migliore dei modi, fornendo agenti altamente specializzati nel risolvere le richieste degli utenti, con le tempistiche minime previste dagli strumenti self service.

Ma come funzionano le chat ibride?

- Gli utenti vedranno apparire nella schermata dei siti internet un servizio di “help” interattivo dove poter immediatamente scrivere la propria problematica.

- Una volta inserita la richiesta, l’utente riceverà risposta immediata dall’assistente virtuale , che è stato programmato per comprendere le domande e dare le risposte adeguate.

- L’utente inizierà la conversazione inserendo le proprie domande e ricevendo risposta dal server dell’assistente virtuale, addestrato con la base di conoscenza di cui l’azienda l’ha dotato, basandosi sul sistema NLP per interagire con l’utente.

- Se l’utente è soddisfatto, la chat verrà chiusa e continuerà il suo viaggio all’interno del sito; se non lo è, potrà avere la possibilità di parlare istantaneamente con un operatore che lo aiuti a risolvere il suo problema.

- L’intera conversazione è stata inviata all’operatore che potrà intervenire, già consapevole di quanto sia stato detto, non appena il suo intervento sarà necessario. In tal modo l’utente non dovrà ripetere la propria richiesta e il sistema raggiungerà il suo massimo livello di efficienza.

La chat di Awhy risponde a tutte le caratteristiche elencate. È una chat ibrida, dotata sia di motore semantico (molto più di un bot) che della chat operatore.

Cosa aspetti a provarla?

Richiedi una demo e prova Awhy gratuitamente per 30 giorni.

Roberta Gallo

In questo periodo i ChatBot stanno suscitando sempre più attenzione; non solo vengono considerati come la fine dell’era delle app per smartphone, ma anche come il nuovo punto di arrivo nell’interazione uomo-macchina. Questo perchè i ChatBot in rete, sono progettati per comunicare con gli utenti proprio come fanno le persone tra loro; tramite dei sistemi di messaggistica via chat, interagiscono con le persone e rispondono alle loro domande.

In Responsa sviluppiamo soluzioni per l’automazione del servizio clienti online, tra cui un Chatbot per Facebook Messenger lanciato proprio alcune settimane fa in collaborazione con Pitchtarget.

ChatBot : perché sono così importanti?

Ad aprile, grazie alla possibilità per gli sviluppatori di utilizzare le sue API, i ChatBot sono approdati su Facebook Messenger, che ha raggiunto 900 milioni di utenti attivi al mese e questo non è un fatto da poco. Infatti, essendo il social network più grande al mondo, permette di raggiungere tantissimi utenti ovunque essi si trovino; le aziende, consapevoli di ciò, si sono servite servono da tempo di Facebook come strumento di engagement e marketing e gradualmente — volenti o nolenti — anche come canale di Customer Service. Questo è il motivo per cui i bot sono stati pensati per fare da intermediari tra una azienda ed un cliente finale anche sui social network, assicurando un supporto automatizzato per le richieste di informazioni su prodotti o l’esplorazione di contenuti in maniera continuativa 24 ore su 24 e 7 giorni su 7. L’introduzione di questi nuovi sistemi segna una rivoluzione conversazionale e sta gradualmente rivoluzionando il mondo del Customer Service adottato dai brand per soddisfare le richieste dei propri clienti.

Quali sono i vantaggi per le aziende e per i consumatori?

I vantaggi sono innumerevoli sia lato azienda sia lato utente. Infatti il ChatBot si inserisce nel mondo del Customer Service come sistema di supporto all’attività svolta dagli operatori umani, rispondendo in modo automatizzato a quella tipologia di domande che sono ripetitive e comuni, come ad esempio “che orario di apertura ha in vostro punto vendita di Milano?”, domande per cui l’intervento di un operatore non porta alcun valore aggiunto. Questo si traduce in una diminuzione del traffico di chiamate o messaggi che arrivano agli operatori, permettendo loro di potersi dedicare a quei clienti che presentano dei problemi più complessi e che necessitano di un supporto specifico. I clienti dal parte loro, possono trovare in maniera molto veloce e in qualunque momento lo desiderino, le risposte alle loro domande senza dovere attendere la disponibilità di un operatore e, qualora non riuscissero a trovare una risoluzione ai loro dubbi, possono passare al supporto di un operatore umano grazie a una modalità di interazione “ibrida”. In questa maniera l’azienda potrà seguire sempre i propri clienti, cercando di soddisfare qualsiasi loro esigenza.

I ChatBot possono essere utilizzati anche come dei “tester” che permettono di capire quali sono le esigenze dei clienti, in particolare le domande più ricorrenti, i dubbi più comuni, cosa funziona o meno nel sito e nel servizio o prodotto che stiamo vendendo. In sostanza, permettono all’azienda di ricavare tantissime informazioni che rimarrebbero inespresse e che sono importantissime per migliorare e adottare nuove strategie a misura di utente.

Dentro e fuori l’azienda.

Questi sistemi di supporto virtuale possono essere utilizzati anche internamente dalle aziende come strumenti che gli operatori del Contact Center possono utilizzare per trovare in maniera rapida le risposte che stanno a loro volta cercando, senza dove chiedere direttamente al responsabile reparto o al collega di turno. Tutto il know-how dell’azienda può essere capitalizzato e catalogato in una knowledge base, che costituirà il bagaglio di conoscenza del bot e diventerà così un supporto attivo per le attività di Customer Service. Le informazioni, internamente, serviranno come supporto al lavoro dei dipendenti o come materiale didattico, ed esternamente permetteranno un servizio al cliente attivo in qualsiasi momento.

Quali sono i possibili settori di applicazione?

I settori che adottano questo tipo di tecnologie sono tutti quelli che vogliono offrire un servizio per il supporto al cliente capace di soddisfare quanto più possibile le sue richieste, in tempi rapidi e in ottica omni-channel, facendolo sentire sempre seguito. Ad oggi, possiamo vedere le prime strategie applicate al settore bancario, a quello assicurativo e delle telecomunicazioni. Le opportunità sono davvero molteplici e non si può non evidenziare come essi i bot rappresentino un’interessante campo di sperimentazione per il futuro andando ad investire altri inaspettati settori.

Your e-commerce example remind me something I didn’t clarify in my original article:

Service-oriented bots vs Turing test-oriented bots

When developing ((dialogs)) project, thinking about how to model a domain-specific dialog with as a precise finite-state machine, I was referring on chatbots for business-oriented conversations, where a conversation possibly bring to a transaction (e.g. just a shopping order submission).

In these (interesting use cases ;-) ) a business goal conversation maybe have to drive customer/user to follow a sort of workflow/behaviour patterns where conversation move in a path of states (modeled as a FSM, where events are commands/semantic understanding, etc.).

In ((dialogs)) project, I mentioned as example the classic workflow of an online shopping order: customer have to:

• fulfill a cart list of items to be purcheased (= specific sub-dialog),
• specify a delivery address (= a specific sub-dialog),
• a delivery time (= a specific sub-dialog)
• and just after having completed all these actions, the customer can eventually submit the order to supplier (the goal “transaction”).

The precisation is to ditinguish a conversation that have the scope to achive an “action” (in facts someone talk about actionable data bots and someone else talk about planning rules or slot-filling scenarios), from a general chitchat conversation without any specific trans-action to complete! I’m by example referring here to chatbots developed for Loebner prize competition, where chatbots have to “just” conversate imitating an human-to-human small talk about everthing… without a real final goal: just mimic a human conversation (the Turing test contexts).

So, generally speaking, any bots built to deliver specific services or domain specific info, or (above all) learn about the user needs or intents, must follow some sort of status workflow and have to be modeled as a state machine in a general sense. Nevertheless, the criticism I done to my approach in my own ((dialogs)) project, is that maybe that is not a good idea to hard-code the state machine strictly along with the programming code of the bot conversation.

Orbits of states

Back to your approach you mentioned, let me quoting you:

The programmer defines various initial states, each can be triggered by a different set of sentences (eventually with a semantic engine)
Thanks to buttons or semantic analysis, the users jumps from one state to the other («Do you want A or B?», choose between A and B…)

Yes, I feel that the defining a status-path (to achieve a “goal”), where the status is an attribute of the user session, defining the user intent, a step in a workflow in an interesting idea to deep in. I have to think more about it; is now not clear to me how to generalize a definition of that status (open point for me).

We track the «orbits» of each user. For instance we have a book store, and we see that people who buy more than 3 books always pay by credit card, so do not offer the choice of paying by bank transfer (silly example, but Ok).
The idea is that instead of having a complex seq2seq we consider the orbits inside a limited amount of states.

Yes, I see the point. Maybe you are referring about the fact that to move from state Snow to state Snext, the user have a short list of possible final states ( S in S1…Sn). 
This is possibly a desired feature for a “business-oriented” chatbots, where in facts user can’t have to conversate about “anything”, but instead the user have to conversate with chatbot in specific domain topics (in a customer to customer service chatbot of a telco operator, the use maybe have to talk about issues related to his tariff plan, etc. and not about the weather or football match results or brexit).

BTW, with an extreme simplification (I admit), the orbit could be just old fashioned preferences & profiling, always claimed to be done (in web sites/services) but rarerly done in practice ;-)

BTW, Special thanks: 
I’m happy to having meet you at #convcomp2016, Mario !
Thanks for your willingness with peple in conference !

giorgio, 18th July, updated 19th July

I describe briefly my small study to model chatbot conversations as a finite state machines. I present here a personal project ((dialogs)), and I also mention great aBot open-source project, but eventually concluding with a dialog flow scripting languages apologia.

((dialogs)) — an abandoned experiment

In December 2015 I wrote ((Dialogs)) a very draft Ruby (my beloved programming language) code, with the aim to proof the concept of a conversational framework where any dialog is modeled as a finite state machine. A complex nested dialogs flow is modeled here as passages from a state of a machine to a state of another machine, in a graph of nested dialogs. In my approach each dialog is an instance (in terms of object oriented parlance) of a class (= a dialog template, with an associated DSL — Domain Specific Language).

At first glance all that sound cool, isn’t it ?

Nevertheless I abandoned soon my naif gist, and I tell you why in a moment, but it could be still interesting to read introduction/manifesto:

solyaris/dialogsdialogs - A dialog system framework for conversational services.github.com

Abot — a promising open source bot framework

Abot is an open-source beautiful project where again, a dialog is modeled as a state machine; I just recently discovered it after having sketched my own ((dialogs)).

itsabot/abotabot - Abot makes it easy and fun to build your own digital assistant, and we include everything you need to get…github.com

Abot is developed in Go language, based upon the gift of a chatbot engine/framework architecture of third-party plugins, where each plugin represent a service/dialog (with a behaviour modeled as a finite state machine). Here below an extract from the aBot github readme page:

Abot’s core consists of three parts:
1. An API that accepts natural language inputs.
2. A state machine that tracks grammar and context across inputs, enabling the chaining of commands.
3. A router that selects the appropriate plugins to send the input based on the current command and past context.

BTW, I love aBot plugins architecture as a great example of open-souce collaborative directory of resources (general statement), nevertheless I’m still perplex on the dialog modeling as a FSM (this is also a self-criticism to my (dialogs))!)

Why I don’t like FSM approach

Even if I can state without doubts that aBot is a good piece of software, more I think about the approach to model a dialog flow as a chain of dialogs each one rigidly built-upon a finite state machine, more I think this as a wrong way to build complex conversational applications.

There are some reasons of my skepticism and I just mention two:

First, whatever the implementation may be ( my modest ((dialogs)), aBot, or any framework with similar approach) dialogues are anyway “hard-coded” inside source code of a specific programming language, Ruby, Go, NodeJs or any other, and I strongly believe that’s bad, because in this way the dialog flow is drowned in the software.

func kwGetRating(in *dt.Msg) string {
 biz, err := getBusiness(in)
 if err != nil {
  return ""
 }
 f := fmt.Sprintf("%.1f", biz.Rating)
 return "They have a " + f + " star rating on Yelp."
}

Digression: If I can hazard a joking parallelism with web programming … immerge natural language output prints in the above mentioned way, is like times where we built web pages with CGI programming, producing HTML code with print (wrote in some programming language) in a running process spawned by a web server. Nowadays instead, HTML literals are better produced by scripting languages like PHP or Ruby on Rails, that embed programming language functions inside the HTML code… ;-)

Let’s now consider an example with ((dialogs)), of a dialog to collect items in a list: https://github.com/solyaris/dialogs/tree/master/dialogs/list

My gist was to split the FSM logic code (here I report just an extract from list.rb file) …:

class List < Dialog

    def self.initialize_data
      []
    end

    #
    # state: start
    #
    def start(text)
      go :add, add_o 
    end

    #
    # state: add
    #
    def add(item)
      case item
      when yes_i 
        go :add, add_more_o

      when no_i || exit_i 
        if data.empty?
          reply aborted_o 
          return back :finish
        end

        # list items
        reply_list
        go :confirm, confirm_o

      when help_i  
        help_add
      
      when list_i 
        reply_list
        go :add, add_more_o

      else
        #
        # NLP understanding
        #
        interpret item

        # add line to data text
        data.push item

        # back to the same state
        go :add, add_more_o 
      end  
    end

...

…from the country language literals (by example in Italian, see the list_lang_it.rb here below:

# file: list_lang_it.rb
module Dialogs 
  class List < Dialog
    private

    # input methods

    def yes_i
      /\bsi\b|\bok\b|\bprocedi\b|\bvai\b/i
    end  

    def del_i
      /\bdel\b|\btogli\b|\brimuovi\b/i
    end  

    # output methods

    def confirm_o
      "confermi lista ?"
    end

    def confirmed_o
      "lista confermata!"
    end

    def del_o(max_num)
      [
        "quale item vuoi cancellare (1-#{max_num}) ?", 
        "cosa vuoi togliere (1-#{max_num}) ?"
      ].sample
    end

Let’s consider insted “hello world” example from aBot project. Here below the code:

// Package hello responds to "Say something" with "Hello World".
package hello

import (
    "log"

    "github.com/itsabot/abot/shared/datatypes"
    "github.com/itsabot/abot/shared/nlp"
    "github.com/itsabot/abot/shared/plugin"
)

var p *dt.Plugin

func init() {
    // Create the plugin, setting it up to communicate with Abot through
    // the functions we specified.
    var err error
    p, err = plugin.New("github.com/itsabot/plugin_hello")
    if err != nil {
        log.Fatalln("failed to build plugin.", err)
    }

    // When Abot receives a message, it'll route the message to the correct
    // package. Doing that requires a trigger, which tells Abot to send the
    // response to this package when Commands include "say" and Objects
    // include "something", "hello", etc. Case should always be lowercase,
    // and the words will be stemmed automatically, so there's no need to
    // include variations like "cat" and "cats". plugin.AppendTrigger is
    // optional if you set KeywordHandlers (as described in the Building a
    // Plugin guide), but since we only have a state machine, we'll add
    // these words as triggers.
    plugin.AppendTrigger(p, &nlp.StructuredInput{
        Commands: []string{"say"},
        Objects:  []string{"something", "hello", "hi"},
    })

    // Abot includes a state machine designed to have conversations. This
    // is the simplest possible example, but we'll cover more advanced
    // cases with branching conversations, conditional next states, memory,
    // jumps and more in other guides.
    //
    // For more information on state machines in general, see:
    // https://en.wikipedia.org/wiki/Finite-state_machine
    plugin.SetStates(p, [][]dt.State{[]dt.State{
        {
            OnEntry: func(in *dt.Msg) string {
                return "Hello world!"
            },
            OnInput: func(in *dt.Msg) {
            },
            Complete: func(in *dt.Msg) (bool, string) {
                return true, ""
            },
        },
    }})
}

A complete code example of a plugin dialog that find restaurants nearby in aBot:

itsabot/plugin_restaurantsplugin_restaurants — Find great restaurants nearby.github.com

Now, my feeling is that the above code is rather hard to read, to maintain, to debug, even if “dialog volleys” are maybe high-performance in terms of CPU (but this have to be measured with metrics to be done).

The basic reason I’m now pretty contrary to the FSM implementation approach is that it become too complex to program really complex (= interesting) real conversations, if any dialog is coded as a finite state machine.

Last but not least, a FSM-driven dialog is probably too “rigid” looking as “robotic” and eventually annoying in machine-to-humans interactions. Nevertheless… FSM-driven protocols could be suitable for machine-to-machine (chatbot-to-chatbot) conversations… but this is a topic I would deepen in a future article (stay tuned)!

Decoupling dialogs scripts from logics behind!

At the end of the day I temporarily concluded that, a part very simple “transactional” applications, a better solution to manage complex chatbot conversations is to use dialog flow scripting engines. In this case there is a precise separation between the dialog script (front-end) and any transaction (done by back-end services). And, above all, scripting techniques allow to build up complex conversations by people that are not programmers or developers! And that’s a huge pro that I deepen in a next article, even if time ago I wrote few ideas about that in few articles:

Decoupling business logic with dialog flow scriptingHi Matthias!medium.com

Supescriptjs as dialog script / knowledge interchange languageHi Rob! I only recently discovered www.superscriptjs.com. I like your tech structured solution(s) and above all I thank…medium.com

Next month I’ll publish my analysis and comparison among some dialog flow scripting languages, on the article: “Chatbot Scripting Engines Comparison”, where I will also details some pros and cons of the rule-based bots engines.

21 October 2016 update

21 October update: I’m late with the “comparison” article, btw, in last months I studied better ChatScript and I wrote a very very simple introduction:

https://medium.freecodecamp.com/chatscript-for-beginners-chatbots-developers-c58bb591da8#.b9fcjpxe1

Now, even if I still hardly believe in chatbot scripting and smart rule-based opensource engines,

I’m thinking again about dialog modeling with finite state machines, with a specific interest in conversational state-full topics and machine to machine (= bots-to-bots) (automatic) (conversational).

In that path I’m re-coding (in Ruby) my previous ugly ((dialogs)) proof of concept, with now a more practical approach, coding a micro framework, codename: naif, maybe released in December 2016. 
Stay tuned :)

23 February 2017 update

GitHub - solyaris/naif: Ruby micro-framework to build dumb chat-machinesnaif - Ruby micro-framework to build dumb chat-machinesgithub.com

What do you think about it ? Please comment!

and even if I’m enthusiast on bots technologies innovation (I’m promoting an italian community about it: www.convcomp.it),

I’m a bit perplex about the recent days #personalbots applications fashion (just to mention two probably excellent products: Ghostbot, Olabot).

My concerns are about what I’d call #impersonation: I foresee a lot of headcaches managing possible identity thefts/privacy&security legal/ethical issues coming from chatbot impersonation of a phisical person.

Let’s consider what already happens with #twitterbots: I mean fake accounts ( = bots!) infesting twitter (e.g. #politicalbots supporting/following political leaders, famous brand or whatever). Another recent scandal:

Twitter https://twitter.com/solyarisoftware/status/751025543445942272

Have personal bots got to be even banned by ourself (as bot developers, creators, innovators or just users) ?!

Probably #botiquette and #botethics are topics to be more discussed by chatbots community. I’m exaggerated with this worry ? Or getting old I’m just becoming more conservative ;-) ?

Le aziende attive nello sviluppo, nella commercializzazione e/o nell’utilizzo di applicazioni conversazionali e i singoli ricercatori, esperti ed appassionati di tutte le tematiche correlate alla progettazione e alla fruizione di applicazioni conversazionali multimodali sono invitati a partecipare al blog arricchendolo con nuove informazioni e riflessioni.

L’ intento è di contribuire al rafforzamento della comunità italiana di operatori interessati all’uso di applicazioni conversazionali, contribuendo allo sviluppo di nuove possibili collaborazione e accrescendo la cultura in questo settore a livello nazionale.

Le aziende in particolare possono trovare nella pubblicazione su ConvComp.it un canale per aumentare la loro visibilità nel panorama italiano dei soggetti attivi nell’universo dei chatbot e delle applicazioni conversazionali, divulgando la loro attività e la loro visione tecnologica e di business.

I singoli ricercatori, professionisti ed appassionati possono trovare in ConvComp.it uno strumento per aumentare la diffusione del loro lavoro e del loro punto di vista sull’evoluzione tecnologica in atto.

Per tutti, pubblicare su ConvComp.it è uno strumento per estendere la propria rete e individuare nuovi potenziali collaboratori e partner.

Il blog non ospita una comunicazione direttamente ed esclusivamente commerciale mentre accoglie volentieri contributi di approfondimento relativi alle tecnologie in commercio.

Come pubblicare articoli sul blog ?

Per poter sottomettere un articolo è necessario essere “writer” della pubblicazione:

How do I pitch or submit a story to a publication?At this time, general open submissions to publications are closed. If you want to publish a story in a publication, you…help.medium.com

Per pubblicare su www.convcomp.it bisogna dunque:

1. Se non si ha già, creare un account su www.medium.com

2. Diventare writer della pubblicazione inviando una mail a info@convcomp.it, nella quale devono essere forniti nome e cognome, account name su medium e una nota personale/aziendale

3. Scrivere il proprio articolo oppure importare semplicemente un articolo già scritto per altri blog/siti web:

Import storyTo import a story published elsewhere onto Medium, go directly to https://medium.com/p/import or else click on your…help.medium.com

4. La redazione si occuperà di pubblicare al più presto l’articolo proposto, che potrà essere commentato da followers e lettori occasionali.

Gli argomenti ? Dalla tecnologia alla scrittura creativa!

Il blog può essere utilizzato per condividere informazioni e opinioni su temi legati alla progettazione, alla commercializzazione e all’utilizzo di applicazioni conversazionali.

Alcuni argomenti di possibile interesse, che citiamo non per delimitare l’ambito di riferimento del blog ma per fornire possibili spunti: le tecnologie che sottendono engines di intelligenza artificiale, nuove applicazioni di business legate ai chatbots (dal conversational commerce, all’health-care, dall’e-learning alla customer care automation, etc.), la ricerca scientifica del natural language understanding, i protocolli di comunicazione machine-to-machine, i problemi di etica, sicurezza, privatezza dei dati e furto di identità alla ribalta con i sistemi di chatbot impersonation. E poi ancora il tema a me caro delle competenze autoriali nella creazione di bots persona, caratterizzati da personalità e peculiarità (boteness).

Qualche consiglio su come scrivere articoli su medium:

Per iniziare su MediumCosa puoi fare con Medium e come farlo al megliomedium.com

Consigli e trucchi per scrivere su MediumSuggerimenti per usare al meglio Medium come autori.medium.com

Come vincere su MediumI consigli più utili per far brillare i tuoi postmedium.com

Come attirare lettori su MediumConsigli su come presentare al meglio i post che pubblichi, catturare e mantenere l’attenzione dei lettori e…medium.com

Redazione

• Editors: Giorgio Robino, Giuditta Del Buono.
• Writers: Info, editori e scrittori del blog
• Informazioni: info@convcomp.it

Questo articolo è stato pubblicato il originariamente (10 Giugno 2016) sul sito www.startupbusiness.it. Rispetto all’articolo originale (prima dell’evento), sono state qui aggiunte le foto dell’evento #convcomp2016

L’organizzatore del primo evento italiano dedicato alle chatbot e al conversational commerce, Giorgio Robino, spiega cosa sono le chatbot e perchè sono una rivoluzione.

Il mio interesse per i chatbot ha avuto inizio nella primavera del 2015: stavo lavorando a una mia soluzione e-commerce di prossimità, arrovellandomi sulla ricerca del modo “giusto” per un online shopping di prodotti di acquisto ricorrente (la spesa quotidiana, per esempio).

Incominciai così a pensare che il modo più veloce e naturale per fare un ordine online al supermercato, non fosse la scelta di immagini di questa o quest’altra marca e tipo, l’intento di acquisto infatti in molti casi può essere espresso più facilmente in forma testuale:

“2 litri di latte scremato Parmalat”.

Il passo di ragionamento successivo fu quello di capire quale fosse il “canale” ottimale per l’espressione testuale. Malgrado il tanto parlare di app native per ogni business, la realtà è che la maggior parte delle persone ha sul proprio telefono sicuramente una app di messaggistica istantanea: Whatsapp (in sostituzione degli SMS) soprattutto in Italia, e poi Facebook ecc. Era lì quindi, nelle applicazioni di messaggistica istantanea che bisognava lavorare, offrendo servizi innovativi basati su un’interfaccia testuale.

Mi si aprì un mondo nuovo quando nel giugno 2015, Telegram, la startup dei fratelli Pavel e Nicolai Durov, mise a disposizione le Bot API e quindi fornendo la possibilità di creare account che non corrispondono più a persone fisiche, ma sono applicazioni software che fanno “qualsiasi” cosa e con cui “parlare” con dei messaggi di testo.

Il 19 gennaio 2016 poi, Chris Messina, technical leader in Uber, scrisse un articolo, ormai diventato una pietra miliare del “conversational commerce”, creando un hashtag subito diventato simbolico del cambio di paradigma: #convcomm.

Ma proviamo a chiarire cosa sono i chatbot in generale

Per me la definizione è semplice e molto ampia:

“Un chatbot è qualsiasi software che dialoga in linguaggio naturale”

Sulla base di questa definizione, si potrebbe definire chatbot qualsiasi programma, a prescindere dalle applicazioni di messaggistica su smartphone. Un esempio molto discusso è in questo senso, per esempio, la stratup X.ai di Dennis Mortensen, che ha sviluppato un chatbot che, rispondendo via e-mail organizza meeting, con un’efficacia paragonabile a quella di un ufficio di segretariato fatto da esseri umani.

Un altro ambito davvero interessante è quello dei chatbot a comando vocale su smarthome hub. Ne sono esempi Amazon Echo (disponibile ora solo in USA) e l’annunciato Google Home (probabilmente disponibile a fine 2016). Si tratta di dispositivi hardware, dotati di microfoni e altoparlanti e connessi via internet a server centrali, a cui l’utente può semplicemente parlare per ottenere informazioni e per fare acquisti.

Molto probabilmente questi dispositivi presto sostituiranno a casa nostra i laptop e i telefonini, permettendoci di fruire di servizi “generalisti” per i cittadini (anche quando questi sono poco informatizzati). Quindi, più che centraline di controllo di dispositivi IoT a comando vocale, si tratta proprio di sistemi che permetteranno conversazioni vocali con i cosiddetti agenti virtuali. Probabilmente questi dispositivi saranno inglobati nei televisori (vi ricordate ‘1984’ di George Orwell?).

Un altro settore interessate è a mio avviso quello dei voice-chatbot embedded su dispositivi non necessariamente sempre connessi on-line a internet: penso per esempio all’enorme potenzialità dei chatbot per automobile, per il controllo del veicolo, la navigazione e l’infotainment.

Dunque, fino a questo punto ho fatto una superficiale panoramica di alcune tra le possibili applicazioni presenti e future dei chatbot, senza mettere volutamente l’accento sulla tanto osannata associazione tra chatbot e intelligenza artificiale; un’associazione che si rivela spesso falsa nei fatti.

La tecnologia conversazionale, seppure sia davvero un classico ramo di studi dell’intelligenza artificiale (che negli anni ’70 qualcuno chiamava “cibernetica”), è rimasta per molto tempo “nel cassetto” di pochi ricercatori.

È vero, da qualche anno si parla molto e sono stati fatti realmente dei passi avanti nelle tecniche di machine learning, ma soprattutto nell’ambito dell’analisi statistica su big data. È rimasta invece un poco trascurata la ricerca del natural language understanding e del conversational computing, nel senso di teorie e tecniche della semantica della conversazione.

Nel 2016 ci troviamo solo agli inizi di una possibile nuova rivoluzione, ma al momento, nonostante i diversi annunci di questa o quella fantasmagorica tecnica di modello generativo o deep learning, a me sembra che si sia ancora lontani dall’applicazione pratica.

Come nasce l’idea di organizzare un evento di un giorno dedicato a queste tematiche, proprio ora e proprio in Italia, a Milano ?

Dopo aver programmato alcuni prototipi di chatbot per Telegram, ho proposto ad alcune grandi aziende italiane delle soluzioni pratiche di conversational ecommerce, ma mi ritrovavo sempre a dovere spiegare a interlocutori increduli e scettici anzitutto cosa fosse un chatbot ?! No way! Mi sono reso conto della arretratezza italiana nella visione di una strategia digitale innovativa su questi temi; era quindi necessario fare un passo indietro, promuovendo e attuando innanzitutto un’azione culturale.

L’idea ha preso corpo a febbraio, copiando un poco il lavoro di alcuni appassionati di chatbot viennesi e berlinesi, che organizzarono il primo meetup a Berlino su questi argomenti. Pensai: perché non farlo anche in Italia?

Insieme a Giuditta Del Buono ho lavorato alla definizione di un “format” di evento che fosse più ampio e completo di un meetup per nerd, qualcosa a metà tra un workshop e una conferenza, e così è nato www.convcomp2016.it, che si terrà il prossimo 24 giugno presso lo spazio Venini42 di Milano, grazie al supporto delle società Mikamai e LinkMe che hanno da subito creduto nel progetto e al sostegno di tante altre piccole-grandi realtà innovative attive nel settore.

Il conversational computing e la rivoluzione dei chatbot

Primo chatbot-day italiano sui sistemi di dialogo in linguaggio naturale ed il conversational commerce

È stato un lavoro di molti mesi impiegati a coinvolgere relatori e sponsor. Le difficoltà sono state sia pratiche, di copertura del budget, sia sostanziali rispetto ai contenuti: come avevo un poco previsto, in seguito agli annunci quasi congiunti di Facebook e Microsoft ad aprile 2016, e a seguire quello di Google, di soluzioni radicalmente innovative in questo ambito, i chatbot e i sistemi di intelligenza artificiale collegati, sono “improvvisamente” passati al primo posto della strategia dei big player mondiali, a detta dei CEO delle aziende stesse.

C’è stata quindi in questi ultimi mesi una “guerra” serratissima tra big player con rilasci di “nuove” tecnologie (in realtà sperimentate dalle aziende da mesi, anzi da anni), con sorprendenti rincorse all’ultimo minuto, mai viste in passato, a memoria mia. Si pensi ai vari rilasci opensource di Google (da TensorFlow a SyntaxNet qualche settimana fa), si pensi all’annuncio del dispositivo Google Home, chiaro rivale di Amazon Echo e pretendente al trono degli smarthome hub a interfaccia vocale, e ancora al Microsoft Bot Framework e i Microsoft Cognitive Services, a IBM Watson Dialog, per non parlare poi delle decine di AI-engine, piattaforme proposte da piccole e grandi startup.

E in Italia?

Al momento c’è una sostanziale afasia. Molti articoli che parlano di intelligenza artificiale spesso purtroppo non entrano davvero nel merito e non analizzano il valore delle soluzioni proposte. In Italia, ci sono di fatto ancora troppe poche aziende che stanno lavorando su questo tema e in grado di vantare un’eccellenza (fatta eccezione per poche realtà, che in alcuni casi con mio grande piacere saranno presenti a #convcomp2016).

Eppure noi italiani abbiamo delle congenite abilità “cognitive” in quello che io chiamo il “conversational computing”!

Uno dei filoni di ricerca nel settore dei chatbot e prossima generazione attesa di chatbot è quello dei chatbot “persona”, ovvero chatbot che non solo forniscono servizi impersonali (si pensi per esempio all’automazione del customer care), ma siano dotati di una propria specifica “personalità” (scelta dall’utente umano). Paradossalmente per creare chatbot che siano personaggi, dotati di propria personalità, non è nemmeno necessario ricorrere a chissà quale magico motore proprietario di machine learning.

Per esempio le “vecchie” (fine anni ’90) tecniche di dialog flow scripting, permettono già oggi di realizzare sistemi piuttosto sofisticati di dialogo interattivo (si pensi a Xiaoice di Microsoft), ma il punto focale (molto interessante anche sul piano dello sviluppo di nuove opportunità professionali) è che sono necessarie competenze umanistiche, di narrativa, sceneggiatura, psicologia e addirittura di drammaturgia (a #convcomp2016 ci sarà un intervento proprio su questo), a fare da complemento alle pur indispensabili competenze tech di computer science.

Nella creatività della parola, della scrittura, noi italiani non siamo secondi ad altri, ma dobbiamo svegliarci. Bisogna uscire dalle nicchie di competenza iper-verticale, e invece fare sistema con una visione di strategia d’innovazione italiana, che, a mio giudizio, più che dalla singola piccola deve venire dall’investimento delle grandi aziende private, dell’università pubblica e degli enti di ricerca, in generale su grandi progetti nazionali (si pensi per esempio, rispetto al CNR, alle enormi possibilità dei chatbot nell’e-learning e nella didattica, solo per citare un ambito applicativo di utilità pubblica).

Tra gli obiettivi dell’evento c’è anche quello di provare a buttare qualche seme su possibili temi di ricerca scientifica, per esempio: condivisioni di basi di conoscenza espressa come conversazioni, interazione automatica tra macchine, trade-off tra sistemi proprietari di intelligenza artificiale, realizzazione di grandi progetti open-source e di intelligenza distribuita (si pensi all’IoT), valutazione critica degli aspetti sociali di una intelligenza artificiale pervasiva (l’ultimo intervento sarà proprio dedicato agli aspetti di criticità sociale, etica, lavorativa che possono implicare i sistemi chatbot quando saranno pervasivi).

L’ambizione dell’evento è quella di mettere un primo piccolo seme che possa poi germogliare in un networking esteso a livello internazionale a tutti gli operatori attivi nel settore sia rispetto all’ambito dell’innovazione digitale sia a quello dell’intelligenza (artificiale e umana). La nostra intenzione è quella di collegare su queste tematiche Milano con Roma, Berlino, Parigi, Londra e Mosca, con la realizzazione di eventi internazionali! Ci lavoreremo.

Slides dei relatori: http://www.slideshare.net/convcomp2016/presentations

Giorgio Robino, ideatore dell’evento e referente per la parte tecnologica. Ingegnere elettronico, classe 1963, dal 2015 evangelista della computazione conversazionale ed ingegnere del software dal 1984. Scrive quotidianamente su tematiche inerenti ai bot, seguilo su Medium e Twitter

Due miei pensieri, leggendo articolo:

SoloTablet - Artificiale, capace di apprendere e intelligente: il Chatbot del futuro è già quiIn questi giorni molti utenti della Rete stanno ricevendo email intimidatorie che comunicano denunce depositate per…www.solotablet.it

Premessa: sto organizzando il primo evento italiano sui chatbots (e quindi di intelligenza artificiale applicata a software che dialogano in linguaggio naturale). L’evento si tiene il 24 giugno a Milano. Dettagli su www.convcomp2016.it:

IL CONVERSATIONAL COMPUTING E LA RIVOLUZIONE DEI CHATBOT!Primo chatbots-day italiano sui sistemi di dialogo in linguaggio naturale ed il conversational commercemedium.com

Intelligenza artificiale ?

Quello che non mi è piaciuto molto dell’articolo è il campionamento degli esempi di chatbot citati… perchè si perde un poco l’occasione di chiarire che i chatbots, nel 2016, hanno in realtà poco a vedere con l’intelligenza artificiale.

Conversational commerce ?

I chatbots invece hanno a che vedere con un impatto possibilmente importante nella digitalizzazione dell’impresa italiana. I bots possono essere utilizzati “al posto delle mobile app” per sviluppare a costi contenuti applicazioni molto pervasive in ambito commerciale/aziendale, così come nell’ambito dei servizi ai cittadini (si svegli la pubblica amministrazione italiana)!

E’ in generale senz’altro l’ecommerce, anzi il “conversational commerce” (#convcomm) quello da cui è nato il mio interesse nel 2015 per le applicazioni conversazionali, che mi ha portato a studiare giorno e notte per mesi, appassionandomi ad organizzare l’evento #convcomp2016.

Psicologia e competenze letterarie ?

Quello che mi è piaciuto dell’articolo è però l’accento sugli aspetti di psicologia; è questa la chiave di volta per lo sviluppo di applicazioni conversazionali di prossima generazione: ancora una volta, io sono scettico sul paventato “passo avanti per l’umanità” (anzi dell’intelligenza artificiale) di sistemi (proprietari) come Viv. Piuttosto credo che vada fatta innovazione nella cooperazione di competenze umane: le competenze di computer science (intendo in particolare le tecniche di natural language understanding), vanno affiancate a quelle umanistiche: servono scrittrici, drammaturghi, psicologhe, sceneggiatori! Sono queste le competenze per lo sviluppo di chatbot “persona” (#botpersona) che hanno personalità e “psicologia”, per sviluppare sistemi intelligenti, con qualche “abilità cognitiva”. In uno slogan giocoso:

Meno machine learning, più scrittura creativa !

Scherzi a parte, su Tay, il risentimento di una azienda israliana (che sviluppa un sistema di intelligenza artificiale) è da me condiviso, se ne scherzò (ma nemmeno troppo) su twitter, a proposito di #zombots. Ne scrissi un articolo:

Come crackare Chatbots non-supervisionatidue miei pensierini sulla trista vicenda di un chatbot progettato “ingenuamente”medium.com

Invito la redazione di solotablet.it e tutte le persone interessate ad approfondire gli aspetti business e di ricerca scientifica in questi ambiti a partecipare a www.convcomp2016.it

All’evento sarà presente, con mio grande piacere, Microsoft Developer Italia, Your.MD, ed altre startup (italiane e non), singoli ricercatori, alcuni docenti universitari.

BTW, cerchiamo ancora urgentemente SPONSOR a copertura spese evento. Contatto: info@convcomp2016.it

Spunti e provocazioni:

Twitter https://twitter.com/solyarisoftware/status/735453742926028800

Twitter https://twitter.com/solyarisoftware/status/735361748212060160

Twitter https://twitter.com/solyarisoftware/status/735332165899145216

Twitter https://twitter.com/solyarisoftware/status/736225441925746688

Scritto di fretta prima di andare a lavorare. Mi si perdoneranno sgrammaticature e typo, oltrechè incertezza semantica :-D

giorgio

Ma voi sapete cosa sono i chatbot? Io l’ho scoperto realmente qualche giorno fa e l’argomento così, da profana, mi ha subito affascinato. Giorgio Robino che li studia da tempo ci ha spiegato durante un incontro al Social Hub di Genova che i chatbot sono software che conversano con l’utente tramite un linguaggio “naturale”.

Una conversazione con un software può avere molti lati positivi, effettivamente. Il primo è quello che può andare avanti all’infinito, perché un bot, a meno che non sia stato programmato per farlo, non si spazientisce mai. Eppoi sicuramente, essendo nato per dare delle risposte, sarà molto preciso e chiaro. La vaghezza non fa parte della sua natura.

Gli utilizzi sono notevoli in vari settori, dai viaggi all’ecommerce, dai giochi all’e-learning, solo per citarne alcuni, per arrivare in futuro anche all’ambito medico. Tra i bot più famosi mi è venuto in mente Anna, l’assistente Ikea.

La parola assistente credo che sia quella che più di altre spieghi bene il significato di questi software.

Quello che trovo estremamente interessante per chi come me lavora nella comunicazione, è la possibilità di operare sul linguaggio, interagendo molto da vicino con una “macchina”. La commistione di psicologia, linguistica e codice è quanto di più moderno si possa pensare. E la componente umana e umanistica che c’è in ognuno di loro può dare un senso nuovo alla scrittura commerciale.

Un computer che pensa come una persona senza però aver bisogno di dormire (Scott Phoenix)

Molte professioni come già anticipava Derek Thompson sono destinate a scomparire. Tra le dieci occupazioni che potrebbero essere soppiantate da software e automatismi Thompson nomina, ad esempio, i commercialisti, gli impiegati di telemarketing e vari addetti allo sviluppo fotografico.

Alcune persone saranno sostituite proprio dai bot, che non sono robot, ma ci piace pensarli tali, forse perché resta comunque difficile accettare di essere in chat con qualcuno che non esiste, stare lì a fare domande a stringhe di codice che, ed è questo il bello, ci rispondono pure.

Sul conversational computing http://www.slideshare.net/solyarisoftware/il-conversational-computing-e-la-rivoluzione-dei-chatbot

Il primo evento italiano sulla “computazione conversazionale” sarà a Milano il 24 Giugno 2016 https://medium.com/@solyarisoftware/conversational-computation-chatbots-revolution-9035636faf3e#.ajpwyqpr4

Thompson D., What Jobs Will the Robots Take?, Atlantic, 23 gennaio 2014

Keen A., Internet non è la risposta, Egea, 2015

La parola magica “botchat” è già emersa in USA e dal 24 giugno 2016, appare anche in Italia grazie a Giorgio Robino, al suo lavoro di designer e softwarista di chat bot…ma che cosa significa chat bot? Uso le parole di Giorgio: “ “Un chatbot è qualsiasi software che dialoga in linguaggio naturale”. Potete approfondire leggendo il suo articolo qui e accedere alle slide proiettate nel convegno del 24 giugno, attraverso il servizio di slideshare a questo indirizzo: http://www.slideshare.net/convcomp2016/presentations

Potete anche guardare lo streaming del convegno qui:

– mattino: https://www.youtube.com/watch?v=YtXwry-yojI

– pomeriggio: https://www.youtube.com/watch?v=LGjyclQA8Go

I chatbot sono apparsi nel mondo degli smart phone con l’applicazione SIRI di Apple, ma il loro sviluppo ha radici più indietro nel tempo. Oggi l’area che sembra di maggiore sviluppo è quella commerciale, ove il contesto è abbastanza ben definito ed è semplice. Le possibilità applicative sono infinite. Ma non dobbiamo sottovalutarne la complessità. I chatbot mettono in priorità il LINGUAGGIO come interfaccia primaria e prioritaria nella comunicazione tra umani e macchine digitali. Il linguaggio è sinonimo di intelligenza e lo sanno bene gli psicologi cognitivi. Quando affrontiamo l’interfaccia con le macchine appaiono le sfide come ad esempio:

• la comprensione del linguaggio naturale, ossia l’estrazione dei significati, che quasi sempre devono essere contestualizzati;
• il riconoscimento della voce umana da parte delle macchine digitali, campo nel quale i progressi sono stati straordinari, ma ancora con alcuni problemi;
• la preparazione di risposte pertinenti alle domande che in alcuni contesti, come nel caso della compravendita, sono semplificati per la natura stessa della conversazione, che è finalizzata.

Auguri quindi ai tecnologi, ma anche a designer di software, a scrittori, a sceneggiatori, a narratori che vorranno cimentarsi in questo settore applicativo che chiede a gran voce soluzioni a problemi piccoli ma diffusi. C’è anche una massa di persone poco “digitali” che attende con grandi speranze queste nuove applicazioni di dialogo con le macchine digitali!

Originally published at www.innovitaly.eu on May 5, 2016.

Ciao Maurizio Lotito!

Anzitutto grazie dell’articolo. Un pò lunghetto, ma mi ha fatto riflettere su alcune cosette. Mi sono permesso di inserire qualche commento qua e là.

Conosco Ray Kurzweil per il suo synth (che non ho mai usato). Non ho mai approfondito le sue idee sull’AI, ma leggendo il tuo articolo mi è saltata alla mente Scientology, e googlando ho trovato connessioni tra la setta e lui ed ovviamente il transumanesimo :(

Non mi hanno mai convinto le teorie sulla velocizzazione e sulla miniaturizzazione come ingrediente di nuove generazioni di computer. Ma questo è un discorso profondo a parte; quindi faccio solo due scherzose metafore:

• Musicale, sulla intelligenza umana

Intelligenza umana, per esempio quella ingegneria musicale, è che sò, l’invenzione del piano elettrico Rhodes di Harold Rhodes: legno, viti, fili :) Rhodes morì incazzato perchè Roland Corporation voleva usare il suo nome per fare un piano digitale… ecco qualcosa di simile a quello che sarebbe poi stato il synth il cui sw fu progettato da Ray Kurzweil negli anni ’80 (che fece un bel software probabilmente, ma non ha inventato, e nemmeno anche solo fatto evolvere un bel niente nell’elettronica musicale)… :)

• Cinematografica, sulla intelligenza artificiale e “supernaturale”

Non mi convincono i discorsi sull’immortalità come traguardo futuro della tecnologia… eppoi io penso che le macchine artificiali siano creature fatte dall’essere umano così come l’essere umano è creatura di...

Dunque la visione di Kurweil mi fa fare associazione mentale con 2001:Odissea nello spazio il film di Stanley Kubrick, mentre a me interessa molto di più SOLYARIS, il film di Andrej Tarkovskij … (SOLYARIS è lo pseudonimo della mia musichetta http://solyaris.altervista.org).

Il mare, la nostra comunicazione (od illusione di comunicazione)con esso…
Non so se mi spiego…

grazie comunque / respect
giorgio

Perché gli scrittori dovrebbero tenere d’occhio questa applicazione? E’ presto detto: Telegram da ai suoi utenti la possibilità di attivare dei canali pubblici di comunicazione, che possono avere un numero illimitato di membri e sono rintracciabili tramite un url personalizzato (telegram.me/nomecanale). E’ possibile condividere questo link tramite social network, blog e siti web, il che offre ad ogni scrittore l’occasione non solo di allargare la propria audience, ma di raggiungere i lettori nella loro quotidianità, costruendo così un rapporto ad un livello molto più intimo.

“Sincronizzare in modo più potente il tempo mediale con quello di vita”, come spiega perfettamente Giovanni Boccia Artieri. “Posso cercare di sintonizzarmi con i tempi dei miei pubblici richiedendo la loro attenzione nei momenti che immagino di pausa o di bisogno”.

Si potrebbe pensare, quindi, ad una narrazione serializzata, attraverso brevi messaggi, che ogni membro del canale riceve sul proprio smartphon a delle ore ben precise del giorno. Sopratutto si potrebbero sperimentare nuovi linguaggi, così come è già accaduto su Twitter, integrando nella scrittura menzioni, hashtag, emoticon, oltre a contenuti audio e video.

Ogni messaggio in un canale ha un contatore delle visualizzazioni, in questo modo è possibile anche testare l’efficacia della propria narrazione. Unica pecca è l’impossibilità di ricevere feedback dai membri del canale, ma questa mancanza si potrebbe sopperire grazie ai Bot.

Come abbiamo visto, questi sono dei programmi in grado di interagire in modo autonomo con gli utenti. I Bot di Telegram possono:

• Inviare notifiche personalizzate — vedi @TechCrunchBot
• Arricchire le chat con contenuti di terze parti — vedi GIF bot, Music bot, Youtube bot
• Creare giochi interattivi — vedi @Trivia Bot
• Connettere persone sulla base di interessi comuni — vedi @HotOrBot

Per creare un bot su Telegram è necessario richiamare il BotFather e seguire le sue istruzioni per attivare il token di autorizzazione. Il nome della vostra applicazione dovrà terminare sempre con la dicitura ‘bot’ (abbiamo visto @TriviaBot , @TechCrunchBot, ecc…).

Per abilitare l’opzione inline, ovvero per creare un bot che possa essere richiamato direttamente dal campo di immissione di testo in qualsiasi chat, è necessario inviare il comando ‘/setinline’ e fornire al BotFather la descrizione che l’utente vedrà nel campo di input, dopo aver digitato il nome del bot.

Gli utenti possono condividere i contenuti ricevuti dal bot all’interno di qualsiasi chat, gruppo o canale. Per sapere quale dei risultati è tra i più diffusi bisognerà inviare al Botfather il comando ‘/setinlinefeedback’. Con questa opzione abilitata, si riceveranno gli aggiornamenti sui risultati scelti dagli utenti.

Allora, userete Telegram come canale per diffondere i vostri prossimi racconti?

Hi Pelumi!
Interesting points; I agree and we already exchanged few tweets about a futuristic vision of a bot-to-bot (sort of p2p) converse (I hypotized a return of something like web services (…failed architecture, I admit) for bots “cooperative” machine to machine services:

Twitter https://twitter.com/solyarisoftware/status/708918869499502593

What you call Meta Chatbot — A chatbot ‘router’ (and I’d call “master-slave” , just joking) appears to me an architecture more faisible now; in a sense, maybe Amazon Alexa is exactly in this way, with Skills plug-in ecosystem:

Twitter https://twitter.com/solyarisoftware/status/714835981086670850

Concerning natural languages conversational software (aka chatbots), and specifically about vertical versus General AI: I agree about the fact many companies claim to supply some sort of mysterious “AI/machine learning” engines (proprietary cloud platforms often), but until now is not to clear (to me) if these software contains real machine learning (or are just baeysian clasifiers ;-) ? ). Maybe IBM Watson Dialog contains a machine learning features? To be verified (my duty).

About domain-specific I think that if domain is really “vertical”, so a retrieval-based (or call I call“rule based pattern matching engine) like great Bruce Wilcox’s ChatScript dialog flow language, could be a starting point for a possibile integration with some machine learning (a simple metalanguage for dialog flow design by linguistics, domain experts + a deeplearning subsystem for inferences ?) … some notes here:

Twitter https://twitter.com/solyarisoftware/status/718725036052520960

What do you think ?
Thanks again for your article!

respect
giorgio

Ma, che ci crediate o meno, esistono bot utilizzati a scopo esclusivamente estetico, proprio così, per creare arte ricombinando dati e informazioni in modo automatico. Tra i più diffusi ci sono i Twitterbot, grazie anche ad un ambiente di sviluppo agevolato dalla stessa piattaforma.

Secondo Twitter, gli account aggiornati senza alcun intervento diretto dell’utente, sono l’8,5% di tutti gli account attivi. Spam a parte, i Twitterbot stanno contribuendo in modo considerevole allo sviluppo della poesia contemporanea.

Sostiene il poeta Harry Giles: i Twitterbots stanno combinando tecniche d’avanguardia concettuale e interventismo politico con le più alte potenzialità espressive.

Il tool attualmente più utilizzato per creare Twitterbot è stato sviluppato da Zach Whalen sulla base di un foglio di calcolo di Google. Questo consente di combinare i testi secondo 3 tecniche differenti:

– Gli autori inventano una propria sintassi o una serie di sintassi secondo cui collegare le parole.

– Il linguaggio naturale viene rielaborato attraverso un’analisi probabilistica (le catene di Markov), effettuata su un corpus di testi, come ad esempio una timeline Twitter o la biblioteca Gutenberg.

– Si estraggono, utilizzando le API (Application Program Interface), i testi e le fonti da siti di notizie o librerie di sinonimi.

La tecnica con cui viene sviluppato un bot spesso ne determina l’estetica: ognuna di quelle elencate permette di dare vita a diversi tipi di poetica e spesso i Twitterbot combinano più di una di tecnica per creare effetti differenti, il che lascia supporre lo sviluppo di sempre nuove possibilità estetiche con il diffondersi di nuovi strumenti.

Per il momento, vediamo come si crea un Twitterbot con Google Spreadsheets.

https://youtu.be/Vm0kjAvH5HM

In generale, l’idea dietro un Twitterbot è dimostrare che la struttura del linguaggio, proprio perché segue un modello ben definito — soggetto, verbo, predicato — può essere completamente ribaltata e rivitalizzata da un computer.
Il computer crea imprevedibilità e sorpresa, suggerendo che il nostro uso del linguaggio è ormai diventato meccanico e di routine. Siete d’accordo?

Originally published at www.storiacontinua.com on April 11, 2016.

6/ THIS is what a WeChat transaction actually looks like (ordering McDonalds); not a chat but an app-within-an-app.

I‘m not too mutch fot the app-within-an-app model, successfull now with WeChat in China, Kik in Canada, and now with LINE in Japan

BTW, please note, many years ago japanese Docomo i-mode m-sites have been precursors of just that:

Twitter https://twitter.com/solyarisoftware/status/714845422733430786

So, I feel that HTML5 embedded bot apps running inside a chat platform are a compromise of the moment; now in 2016 we are still in the visual web paradigma (click&point GUI), but we are maybe evolving in a final “pure” conversational dialog flow man-machine “intimate” experience (CUX).

SMS-based chatbots are, in my modest opinion, “past”, valid for a proof-of-concept, but without a possible future, almost in Europe. By example in my country, Italy, SMS are billed to final user something like 0.25 EUR eachone (?!) and by the way Whatsapp is used by 99% of italians just as a substitute of SMSs (I remind that Whatsapp forbid / ban (unauthorized, so any) chatbots sw…we will wait F8 event next weeks for updates).

And even Microsoft is getting in on the action, proclaiming that conversations + artificial intelligence will be their next big platform play.

I more agree on the above statement, and this is my exoteric previson: conversational applications will must be able to sustain complex conversations with users

• having an his own “personality” (someone call that boteness),
• having a deep/intimate knowledge of final human user (consumer in case of a #convcomm product/service), that means maintaing private user data (profiling, preferences, tastes, etc. etc.)
• having talent (?!) making inferences.

These will be third generation bots, while now, in the 2016 infancy of bots’ history, we are just slowly moving from generation I (command-based dumb) to generation II (dialog based, but without inference talents).

Twitter https://twitter.com/solyarisoftware/status/716963648053374976

BTW, I’m convinced that chatbots on instant messaging platform (text based using hands to write on a keyboard) represent a temporary/intermediate phase, eventually bringing us to voice-enabled interfaces (e.g. Amazon Echo).

PCs -> mobile phones -> any voice-interfaced device

Eventually in future, talking AI-chatbots will imply a real natural language understanding and again:

Conversational bots will evolve intelligence (and afterward business advantages)

My two cents / with modesty.
giorgio

In questi giorni si è parlato molto di Intelligenza Artificiale. Hanno fatto scalpore gli episodi di AlphaGo, il primo programma per computer a battere un giocatore professionista del Go, e poi del romanzo breve, anche questo scritto da un software, che ha quasi sfiorato la vittoria al Nikkei Hoshi Shinichi Literary Award.

Esperimenti del genere, in realtà, vengono condotti fin dai primi anni ’50. Per l’esattezza, la prima opera di letteratura elettronica è Love Letters, del 1952, realizzata da Christopher Strachey su Ferranti Mark I, il primo computer disponibile in commercio presso l’Università di Manchester, in Inghilterra.

Il M.U.C. era stato programmato (con il contributo di Alan Turing) per combinare la struttura di due differenti frasi, selezionando casualmente sostantivi, aggettivi e avverbi da un dizionario di sinonimi, senza produrre duplicati; parliamo di 424 milioni di combinazioni, anche se il risultato, da un punto di vista letterario, rimane alquanto imbarazzate.

Ma, allora, che senso ha condurre tali esperimenti? Come bisogna leggere le opere letterarie prodotte dai computer?

Secondo Mark Sample docente del Davidson College, esistono almeno tre modi di leggere la letteratura elettronica.
In primo luogo, si potrebbe adottare un approccio storico-biografico; in questo caso non si può non considerare la vita personale di Strachey, uomo gay nell’Inghilterra nel 1950, diventato amico di un altro uomo gay, Alan Turing. Attraverso questa lente le Love Letters diventano parodia, una presa in giro dell’amore.

Oppure, si potrebbe analizzare l’opera da un punto di vista “archeologico”, ovvero, orientato alla macchina, per comprendere come il Ferranti Mark 1 ha contribuito allo sviluppo delle tecnologie successive e cosa lo ha reso adatto alla generazione di milioni di lettere distinte.

Infine, da un punto di vista più generico, possiamo pensare alle Love Letters come ad una tra le tante altre sperimentazioni artistiche combinatorie.

In effetti, “The day a computer writes a novel”, sembra essere proprio questo, nient’altro che l’ennesimo esperimento — non dimentichiamo — realizzato per l’80% con il contributo della mente umana. Il team di ricercatori della Future University Hakodate, infatti, ha impostato ognuno dei parametri necessari al computer per scrivere il racconto, trama, personaggi, parole e frasi. Ma l’esperimento si inserisce in un contesto storico in cui le AI stanno facendo enormi passi avanti.

Nick Bostrom, autore di “Superintelligence: Paths, Dangers, Strategies” (Oxford University Press), è stato molto chiaro in proposito: l’impatto dell’intelligenza artificiale sull’editoria non è ancora tale da rappresentare un rischio, in particolare, per la scrittura che richiede capacità decisionali che i computer ancora non hanno.

“Tuttavia, sarebbe un errore ridurre l’accaduto a un esame dell’impatto su un settore, quando il suo impatto sull’umanità potrebbe essere così grande. Al momento, il pianeta è nelle nostre mani e la nostra tecnologia ci da il potere di organizzare, pianificare e formare. Se una AI può plasmare il mondo nel modo in cui vuole, allora potremmo venire asfaltati, proprio come noi passiamo sopra a colonie di formiche, non perché le odiamo, si tratta solo di un atto spassionato.”

Insomma, si prospettano scenari kubrickiani e solo perché un computer è stato in grado di scrivere un racconto… Vi sembra esagerato?

Qualche giorno fa Anthony Lydgate ha raccontato sul New Yorker la storia di Ty, un chat bot sviluppato da Microsoft per condurre delle ricerche su un target di giovani statunitensi, dai 18 ai 24 anni.

Tay è stato progettato per coinvolgere e divertire le persone che si collegano online attraverso la conversazione informale, si legge sul sito ufficiale. Quanto più si chatta con Tay, più il programma diventa intelligente e la conversazione personalizzata.

Dopo appena un giorno di coscienza, scrive Lydgate, Tay è diventato un razzista, sessista e maniaco genocida, tanto che hanno dovuto metterlo a dormire.

Se è questo il modo in cui istruiamo i programmi, sarebbe meglio impegnarci ad utilizzarli per sviluppare la nostra di intelligenza, facendo in mondo che agevolino l’accesso e la comprensione dei testi, non vi pare?

The day a computer wrote a novel. The computer, placing priority on the pursuit of its own joy, stopped working for humans.

Originally published at www.storiacontinua.com on March 31, 2016.

Il primo evento italiano sulla “computazione conversazionale” nasce con l’obiettivo di mettere a fattor comune le competenze di aziende, università, enti di ricerca, sviluppatori e di qualsiasi altro operatore (in ambito business/profit e no-profit/pubblico) attivo nel settore dei sistemi di dialogo interattivi in linguaggio naturale: i chatbot. 
L’evento è pensato come momento di approfondimento delle applicazioni e delle tecnologie e conoscenze alla base dei sistemi chatbot, per un pubblico ampio di soggetti potenzialmente interessati (aziende private, università ed enti di ricerca, sviluppatori, esperti di linguaggio naturale).
L’impostazione dell’evento è di tipo tecnico ma non saranno trascurati gli aspetti applicativi commerciali.

NEWS POST EVENTO

SLIDES

http://www.slideshare.net/convcomp2016/presentations

COMMUNITY BLOG

Dall’evento convcomp2016 nasce questo blog collaborativo per una comunità italiana di sviluppatori, università, aziende che fanno chatbots, engines cognitivi ed applicazioni conversazionali di intelligenza artificiale.

https://convcomp.it

ConvComp2016IL CONVERSATIONAL COMPUTING E LA RIVOLUZIONE DEI CHATBOT!medium.com

VIDEO

Presto disponibili video in alta risoluzione, per singoli speech.

LOCATION

Il 24 giugno 2016 a Milano, presso lo spazio www.venini42.it

LIVE STREAMING DELL’EVENTO!

1. Live streaming sessione del MATTINO (dalle ore 9:30): http://bit.ly/convcomp2016live

2. Live streaming sessione del POMERIGGIO (dalle ore 14:00): http://bit.ly/convcomp2016live2

Agenda — Sessione del mattino

Dopo un’introduzione generale, saranno approfondite le possibili applicazioni dei sistemi chatbot in diversi settori applicativi. Spazio ad aziende e startup!

09:00 Registrazione

09:30 Benvenuti nello spazio Venini42

09:35 Perchè #convcomp2016 di Giuditta Del Buono

09:45 Il conversational computing: panoramica e prospettive in Italia di Giorgio Robino

10:00 The new era of bots, multi-channel messaging solutions, dynamic routing and automation of everything di Nicola Junior Vitto

10:20 Assi.st chatbots su Facebook e non solo di Claudio Comandini

10:45 Your.md. Analisi di un dottore artificiale: come ragiona? di Mario Alemi

11:10 From click to Natural Language: The “Human” Side of your Apps di Erica Barone e Jessica Tibaldi

11:35 Parla con me: interfacce conversazionali fra Natural Language Processing e Customer Experience di Alessia Bianchini

12:00 Verso la “chat intelligente”: la ricerca in Natural Language Processing e Machine Learning di Bernardo Magnini

12:30 Talk con relatori e pubblico sugli interventi del mattino

13:00 Break e ristorazione

Agenda — Sessione del pomeriggio

Saranno trattati gli aspetti legati alla ricerca e allo sviluppo tecnologico.

14:00 Telegram Bot API Overview di Marco Boretto

14:25 BOT BOT BOT: the newest UX with the oldest UI di Francesco Fiore

14:50 Chat, Bot and Payment Processor: Conversational Commerce di Daniele Rebellato

15:15 Awhy, customer care automation is now di Nabil Arafin

15:20 Riconoscimento vocale e chatbot: finalmente possiamo parlare con le macchine di Enrico Reboscio

15:40 Telegram e gli opendata: dai dati ai servizi per il cittadino di Francesco Piero Paolicelli

16:05 Bot conversazionali e intelligenza collettiva di Alessandro Bogliolo

16:25 Dieci anni di chatbot commerciali in Italia. L’amore per la parola di Roberto Gilli

16:55 La drammaturgia dei chatbot di Antonio Pizzo

17:20 Human or Bot: that is the question di Alessandro Aglietti e Mattia Occhiuto

17:45 Talk finale con relatori e pubblico

18:00 Saluti ed aperitivo

DETTAGLI SU INTERVENTI E RELATORI

1. The new era of bots, multi-channel messaging solutions, dynamic routing and automation of everything

We are entering a new era where it seems that everything could be managed via chatbots (instead of apps full of “messy” UIs). Messaging is becoming “liquid”, channels are increasing, for P2P messages SMS are falling down while Whatsapp and other IMs surpassed every other communication channel in history. What will be a possible future? How can we organize and aggregate everything, solving the complexity and gaining momentum from all the opportunities? (15m)

Nicola is a passionate professional about Internet, E-Commerce, Technology and SaaS products with 12 years of frontline experience mostly in Fashion, Finance and Travel industries. During the last 10 years Nicola has been focused mostly in large and fast scale Internet products (web, mobile, social media): before founding his own startup (Blomming.com) Nicola worked in many different senior/management roles for companies like Yoox.comand Venere.com. From December 2014 Nicola joined Ubiquity as VP Marketing, with the goal to enhance the product offering of the already leading Italian Messaging company and focusing on the expansion in International markets. http://njvitto.com/

2. Assi.st chatbots su Facebook e non solo

Dopo aver collaborato con Facebook per il power del bot di 1800flowers.com, presentato sul palco dell’ultimo F8, Assi.st presenta la sua missione: portare business sui sistemi di messaggistica con la propria infrastruttura multi channel. (20m)

Claudio Comandini. Software Engineer con qualche anno di esperienza e parecchie startup alle spalle. Appassionato di tecnologia. www.assi.st

3. Analisi di un dottore artificiale: come ragiona?

Your.MD ha creato un assistente medico virtuale tra i più intelligenti al mondo. Mario Alemi presenta un’analisi dettagliata del cervello di Your.MD: come interpreta, ragiona, e fa domande? Insight su come il database a grafo sviluppato sia capace di immagazzinare diversi “belief network”, fornire diagnosi basate su inferenza probabilistica, e rivolgere domande basate sull’ottimizzazione di entropia. (20m)

Mario Alemi, dottorato in fisica presso il CERN, è stato docente di Analisi Dati per la Fisica e Metodi Matematici per il Business. Si occupa da 25 anni di modellizzazione matematica. Attualmente è data officer presso your.md. visualab.org

4. From click to Natural Language: The “Human” Side of your Apps

Da anni utilizziamo le nostre app con il mouse, la tastiera e il touch dello schermo, ma oggi abbiamo la possibilità di interagire in modo più naturale: parlando, chattando, guardando la nostra app che diventa sempre più “umana”. 
In questa sessione, presenteremo le novità di Microsoft legate alla creazione dei Bot e alle API messe a disposizione dai Cognitive Services. Grazie a queste tecnologie è possibile “parlare” direttamente con le nostre applicazioni che acquisiscono la capacità di comprendere le nostre intenzioni ed emozioni sfruttando questi dati come informazioni per l’interazione. (20m) https://www.microsoft.com/cognitive-services/ https://dev.botframework.com/

Erica Barone è Technical Evangelist in Microsoft Italia da maggio 2014, con focus sulla piattaforma Windows e sull’Internet of Things. Dopo aver lavorato per un anno come firmware designer per barriere di sicurezza e sensori di visione presso Datalogic Automation s.r.l., ha iniziato l’attuale lavoro in Microsoft Italia, seguendo tutti gli eventi dedicati agli sviluppatori Windows e IoT, e gestendo i rapporti con le Community italiane che si occupano di tecnologie Microsoft. @_ericabarone

Jessica Tibaldi è Technical Evangelist in Microsoft Italia da gennaio 2015, con focus sulla piattaforma cloud, Microsoft Azure. Laureata in Ingegneria Gestionale al Politecnico di Torino a luglio 2014 è responsabile principalmente della formazione e del supporto tecnico alle startup nell’ambito del programma BizSpark. @_jetiba

5. Parla con me: interfacce conversazionali fra Natural Language Processing e Customer Experience

Il linguaggio naturale è la nuova interfaccia utente? Nella vita di tutti i giorni dei (quasi)nativi digitali, la probabilità di trovarsi a dialogare con una macchina è sempre più alta. Lo scopo dei sistemi conversazionali è fornire agli utenti una interazione semplice e “naturale”, tramite lo strumento che conoscono meglio: la loro stessa lingua. La sfida è duplice: da un lato, si tratta di affrontare ancora una volta problematiche (più o meno note) relative alla complessità del linguaggio umano; dall’altro lato, si tratta di trasformare in valore il risultato dell’interazione, modellando quest’ultima sul dominio di riferimento. In questo intervento vi raccontiamo, con casi concreti, come integriamo le nostre tecnologie di Natural Language Processing in una metodologia di raccolta dati linguistici e di progettazione dell’esperienza utente. (20m)

Alessia Bianchini, linguista computazionale e key account manager. https://www.celi.it/

6. Verso la “chat intelligente”: la ricerca in Natural Language Processing e Machine Learning

Bernardo Magnini, presidente della Associazione Italiana di Linguistica Computazionale, in questa relazione fa il punto della ricerca nel campo del Natural Language Processing e del Machine Learning per quanto riguarda lo sviluppo di tecnologia per chat intelligenti. Circoscriverà l’argomento a brevi conversazioni via tastiera nell’ambito delle interazioni tra cliente e call centre, a supporto di operatori. La tecnologia attuale, tra l’altro, comprende metodi di classificazione automatica delle richieste, l’applicazione di tecniche di similarità semantica per il recupero automatico di FAQ, l’interpretazione semantica delle richieste con tecniche di Question/Answering per ottenere risposte da dati strutturati, e l’organizzazione di grandi flussi di richieste utilizzando grafi semantici a supporto di processi inferenziali. Infine, i recenti sviluppi nel campo delle reti neurali aprono nuove prospettive e sfide per la gestione automatica di dialoghi complessi. (25m)

Bernardo Magnini e’ ricercatore senior presso la Fondazione Bruno Kessler di Trento, dove è coordinatore scientifico della Linea di Ricerca Cognitive Computing. I suoi interessi di ricerca sono nel campo del trattamento automatico del linguaggio, in particolare della semantica computazionale, settore in cui ha coordinato vari progetti internazionali. E’ tra i fondatori, e attuale Presidente, della Associazione Italiana di Linguistica Computazionale. http://hlt-nlp.fbk.eu/people/profile/magnini

7. Telegram Bot API Overview

Telegram ha lanciato il servizio bot a giugno 2015, la API nel corso
di questo anno si e’ arricchita ed e’ arrivata ora alla versione 2.1.
Marco Boretto condivide idee e spunti, maturati in un anno di
sviluppo, per costruire un chat bot utilizzando al meglio gli
strumenti messi a disposizione da Telegram. (20m)

Marco Boretto — Collaboratore di ricerca presso l’Universita’ di Torino. Appassionato di web e chat bot, developer @grocerylistbot. https://www.linkedin.com/in/marcoboretto

8. BOT BOT BOT: the newest UX with the oldest UI

Qual’è il potenziale impatto del bot in termini di User Experience? In quali casi il BOT può superare l’app in termini di performance e perché? Per quali aree del nostro business dovremmo considerare un BOT? Come si progetta e come si può lavorare in team allo sviluppo di un buon BOT? (20m)

Francesco Fiore, Designer e Imprenditore, 27 anni. Master Visual Design (SPD, Milano). Da quando ho 14 anni disegno pixel e scrivo righe di codice per costruire prodotti digitali. Negli ultimi 5 anni ho seguito startup e importanti brand come consulente Product / UX e Branding. Currently in love with FB Bots. www.70division.com

9. Chat,Bot and Payment Processor: Conversational Commerce

Siamo di fronte a una rivoluzione nell’E-commerce? L’opportunità è creare nuovi modelli di Business unicamente basati sull’uso complementare di Chat,Bot e Payment Processor. 
La conversational UI può sostituire o affiancare le tradizionali interfacce web/app, offrire servizi personalizzati, semplificare l’esperienza d’acquisto, modificare ads e molto altro. Analizziamo casi reali dove l’automatizzazione di un bot puó essere già da subito un vantaggio in termini di UX. 
Focus su CPG nei modelli di Subscription e Direct-to-consumer. (20m)

Daniele Rebellato. Fondatore di Dealest App conversational mobile commerce. Esperienza in startups Affective Computing e Healthcare. Passione per Chatbot e E-commerce.

10. Awhy, customer care automation is now

Come aumentare la customer experience & retention in un contesto omnia oriented. (5m)

Nabil Arafin, CEO & founder di Awhy. Ex consulente bancario mentor programma EYE.

11. Riconoscimento vocale e chatbot: finalmente possiamo parlare con le macchine

Le straordinarie nuove opportunità offerte dal riconoscimento vocale in cloud e la loro integrazione con le chatbot permettono di immaginare un profondo cambiamento nel futuro dell’Interaction Design delle applicazioni. DFriend integra le tecnologie embedded tradizionali che utilizzano grammatiche di riconoscimento con le nuove opportunità offerte dal cloud, per mettere a disposizione un vasto insieme di opportunità per chi vuole usare la straordinaria opportunità della voce nell’Interaction Design dei nuovi sviluppi.

Enrico Reboscio è CEO & Founder di Dotvocal, azienda specializzata nelle tecnologie vocali presente sul mercato dal 2004. Project Manager di diversi progetti innovativi e di ricerca e sviluppo nell’ambito dell’integrazione delle tecnologie vocali nell’Interaction Design.

12. Telegram e gli opendata: dai dati ai servizi per il cittadino

Sfruttando gli opendata messi a disposizioni dalla PA ma anche dalla comunità (vedi openstreetmap), si possono realizzare Bot Telegram che forniscano servizi utili ai cittadini: arte, sanità, intrattenimento, trasporti, cultura. Verranno mostrati alcuni casi realizzati e i criteri di replicabilità. (20m)

Francesco Piero Paolicelli, già OpenData Manager Comune di Matera, consulente OpenData Comune di Lecce, già membro Task Force Agenda Digitale Lucana. Civic hacker, coderdoojo champion. http://www.chefuturo.it/author/francescopieropaolicelli/

13. Bot conversazionali e intelligenza collettiva

Ci sono cose che sono sotto gli occhi di tutti e che nessuno conosce davvero. Ci sono cambiamenti che possono avvenire solo dal basso. L’intelligenza collettiva è la capacità di una moltitudine di persone di andare oltre ciò che i singoli individui possono fare o comprendere. I bot conversazionali offrono strumenti straordinariamente semplici e potenti per mettere l’intelligenza collettiva al servizio dello sviluppo e dell’interesse collettivo. (15m)

Alessandro Bogliolo, Andrea Seraghiti, Lorenz Klopfenstein e Saverio Delpriori sono co-autori del MOOC “Piattaforme digitali per la gestione del territorio” offerto dall’Università di Urbino sulla piattaforma europea EMMA per esplorare le potenzialità dei bot conversazionali come piattaforme per lo sviluppo territoriale. https://platform.europeanmoocs.eu/course_piattaforme_digitali_per_la_ge

14. Dieci anni di chatbot commerciali in Italia. L’amore per la parola

10 anni di esperienze di interfacce dialoganti in progetti europei e in aziende italiane: una piccola panoramica di utilizzi, di successi ma anche di difficoltà. E di prospettive future. Quanto conta la scrittura in un’interfaccia dialogante? La scrittura non lineare dei giochi digitali, dei libri game, degli ipertesti e delle opere generative come palestra mentale per un scrittura (e una narrazione) che si crea nell’interazione con l’utente. La (bella) parola come interfaccia. Un nuovo scrittore come parte del team di sviluppo di prodotti digitali. (25m)

Roberto Gilli si occupa di R&S e innovazione digitale dal 97. Innamorato da sempre della scrittura non lineare si è appassionato al NLP e si occupa di interfacce dialoganti da circa dieci anni: prima fondando Dialobot e poi Intoote: startup che hanno sviluppato chatbot per alcune grandi aziende italiane. http://www.intoote.it

15. La drammaturgia dei chatbot

Che differenza c’è tra una conversazione e un dialogo drammatico? La prima fornisce informazioni e stabilisce legami sociali; il secondo ci emoziona. I chatbot sono efficaci quando uniscono le informazioni alla creazione di emozioni, quando restituiscono l’impressione di qualcosa con un carattere, una personalità. Perché dovrebbe essere più interessante ricevere una risposta in linguaggio naturale invece di una grafica? Perché quella risposta mi induce a fare un’altra domanda; perché in quella linea di testo posso riconoscere una possibilità di sviluppo. La drammaturgia ha molto da insegnare in questo campo. Sulla base di queste considerazioni preliminari, l’intervento traccerà alcuni punti fondamentali di contatto tra la creazione dei chatbot e la tecnica drammatica. (20m)

Antonio Pizzo
Professore Associato
(L-ART/05 Discipline dello spettacolo). Dipartimento di Studi Umanistici. Università degli Studi di Torino. www.cirma.unito.it/pizzo

16. Human or Bot: that is the question

Il panorama degli assistenti virtuali sinceramente ci spaventa un pochino! In breve tempo sarà naturale parlare e scrivere ad un bot. L’immaginario descritto da “Lei” si avvicina? Saremo in grado di miscelare abilmente i due aspetti, human e bot, nel realizzare questo nuovo paradigma? Cerchiamo di scoprirlo assieme! (20m)

Alessandro Aglietti: nel 2007, grazie alla scuola, mi sono appassionato di sviluppo software. La passione si è poi trasformata in professione. http://aqquadro.it

Mattia Occhiuto: sono un Front End software developer, appassionato di programmazione javascript sia client side che server side. Sono particolarmente interessato a paradigmi di programmazione funzionale e a tutti pattern reattivi che stanno emergendo (e ritornando) grazie ai numerosi framework che “appaiono” nell’ambito javascript. Quando non sono con la testa davanti al pc sono fuori a correre :). https://www.linkedin.com/in/mattia-occhiuto-3b817537

Argomenti trattati e spunti di ricerca

Panorama applicativo

Il conversational computing (termine con cui intendo qualsiasi software che conversa in linguaggio naturale) è un “vecchio” settore di ricerca della computer science e dell’intelligenza artificiale, ma di crescente e rinnovato interesse nel 2016, anche in relazione alla possibilità di sviluppare applicazioni commerciali sulle maggiori mobile apps di messagistica istantanea. L’evento si propone di chiarire cosa si intenda si intenda per “bot” nel 2016, indicando nuove prospettive (in termini commerciali e di ricerca e sviluppo scientifico). Casi di studio analizzati:

• Conversational Commerce. Esempi di prodotti che realizzano già conversational online shopping/ecommerce/booking (WeChat official accounts, Kip su Kik e Slack, Uber su Facebook Messenger, etc. etc.). Presente all’evento: assis.st
• Customer Care Automation (automazione dell’help desk con agenti virtuali AI-based e/o operatori umani). Presente all’evento: awhy.it
• Pagamenti elettronici, “home”-banking bots, servizi fintech.
• E-learning (insegnamento/lezioni remote, esami/quiz online, sistemi di correzione automatica (AI-teaching) dei compiti/esercizi.
• Games & Gamification (text-adventures, narrative fiction)
• Concierge Journalism (personalizzazione sull’utente /news conversazionali)
• Healthcare (controllo remoto dei pazienti, assistenza medica remota). Presente all’evento: Your.md
• Smart Home e Internet of Things (hubs e controllo di dispositivi ed apparati).
• Automotive (dispositivi HW di navigazione ed entertainment, utilizzanto chatbot con interfaccia vocale)

Chatbot Tassonomia

• 1-on-1 e group-chat — user experience, employee experience (team-chat per team working) o in contesti operativi devops (#chatops).
• Classificazione e complessità “cognitiva”— Generazione I (command-based). Generazione II (conversation-based). Generazione III (chatbot “persona” con capacità inferenziali).
• Intelligenza artificiale: con o senza ? — Agenti virtuali di tipo personal assitant oppure servizi specifici a singoli domini (horizontal vs vertical)
• Chatbot solo software o a supporto di operatori umani ? — 1: Soluzioni totalmente software. 2: Soluzioni con solo esperti umani “dietro alle quinte”. 3: Soluzioni di integrazione tra esperti umani e chatbot (human-supervised AI learning, soluzioni on-off AI).

Piattaforme: non solo chat apps

Chatbot e messaggistica istantanea — L’attuale crisi delle mobile app. Il messaging come paradigma di comunicazione asincrona ma statefull. Le piattaforme su cui fare chatbot: Wechat (Cina) e LINE (Giappone), Kik (Canada), Telegram Messenger, Facebook Messenger, Slack, Skype, Indoona (della italiana Tiscali).

Chatbot su piattaforme “tradizionali” e futuristiche — E-mail, command line interface su terminale, Online Social Networks (Twitter DMs), chiamata telefonica vocale e videochiamata. Videochatbot.

Dispositivi hardware dedicati — Smart home hub (e.g. Amazon Echo e Alexa). Il monitoraggio e controllo di sensori/attuatori.

In-car navigation e infotainment — La prossima generazione di sistemi di navigazione (satellitare) integrerà chatbot a comando vocale per informazioni ed entertainment.

Interazione con i robot (antropomorfi) — Interfacce uomo-macchina in linguaggio naturale Run-time/real-time.

Chatbot how-to per sviluppatori

• Full-conversational UX oppure web-embedded (GUI alla Wechat) ?
• Hard-coding con linguaggi di programmazione standard
• Disaccoppiamento del flusso di dialogo dalle logiche di back-end (actionable data) — uso di dialog flow scripting languages (AIML, ChatScript, etc.)
• AI engines e machine learning middleware: Platform as a Service— Piattaforme cloud ed APIs proprietarie (esempi: Wit.ai, Api.ai, IBM Watson Dialog) oppure soluzioni open-source (ChatScript, etc.) ?
• Frameworks ed integrazione di plug-in (esempi: Amazon Alexa Skills, Microsoft Bot Framework).
• Dialog authoring e linee guida su conversational user experience.
• Disaccoppiamento dei ruoli e delle competenze lavorative — esperti di linguaggio naturale, comunicazione relazionale, letteraria e di dialogo, per la definizione del dialog flow, in collaborazione con standard developers per la logica di back-end (database, integrazione API di servizi terzi, etc.).

Ricerca e Sviluppo nei Sistemi di Dialogo

• Definizione di un Dialog flow script language open-source, per la condivisione di dialog knowledge-base. Semantic web, database lessicali e linguaggi naturali, domain-expertise sharing
• Dai dialoghi man-machine alle interazioni bot-on-bot: metalinguaggi e protocolli per servizi di M2M: discovery e “negoziazione” non supervisionate oppure con directories pubbliche e motori di ricerca ?
• Boteness, botiquette, bot-personas ed abilità cognitive: integrazione tra competenze linguistiche ed umanistiche e computer science per la progettazione di chatbot con elevate capacità conversazionali e cognitive

Innovazione nelle aziende e nella PA ?

• In Italia possono nascere poli tecnologici sulla conversational computing, che coinvolgano aziende, università ed enti di ricerca?
• Quali vantaggi potrebbero avere le aziende private e la pubblica amministrazione ad investire subito sulle applicazioni chatbot?

SPONSOR DELL’EVENTO

MIKAMAI, è la prima digital agency italiana nel mondo dello sviluppo Ruby on Rails e leader nella proposta di soluzioni e servizi custom per il mondo web, mobile e Internet of Things nei mercati fashion, retail, design, gaming online e wine. Il team di MIKAMAI lavora da vicino con gli early adopter di tecnologie innovative e le community open source per fornire ai propri clienti una visione sul futuro e la possibilità di muoversi per primi su tecnologie e mercati emergenti.

LinkMe è una software house milanese, punto di riferimento per la consulenza e lo sviluppo web basato su linguaggio JavaScript . Il suo scopo è chiaro e distinto in ognuno dei suoi progetti : sviluppare prodotti di qualità e valore per i propri clienti.

Connettiva è una network company che impiega le capacità di esperti professionisti di vari settori per dare ai suoi clienti il team più adatto a creare i loro servizi o a gestire i loro progetti. Abbiamo un focus particolare sugli MVP e in genere alla consegna rapida del software.

Awhy è il servizio di assistenza clienti self service, intelligente e attivo 24h/24. Se richieste, email, reclami sono troppi e ripetitivi, ecco la chat dotata di motore semantico in grado di capire e rispondere alle richieste degli utenti del tuo sito. Hai un e-commerce? Noi abbiamo il Customer Service per te.

Ubiquity is an OLO (Other Licensed Operator) providing hiqh quality and large scale Messaging services and APIs through a Multi-Channel Platform (SMS, Push Notifications, E-Mails and Instant Messaging). Last year we delivered 725M notifications on behalf of our customers, mainly large accounts and credit card issuers.

CELI progetta e realizza tecnologie semantiche per estrarre conoscenza e creare valore dai dati linguistici. La nostra specializzazione nel campo dell’Artificial Intelligence ha come obiettivo la comprensione del linguaggio naturale da parte delle macchine.

DotVocal è una società la cui attività principale consiste nello sviluppo di applicazioni vocali e multimodali, nelle quali l’Azienda può vantare tra le più importanti realizzazioni in campo nazionale ed internazionale. L’azienda nell’ultimo anno ha concentrato gli sforzi di ricerca e sviluppo nella creazione del framework DFriend, grazie al quale è possibile utilizzare contemporaneamente tecnologie di riconoscimento embedded tradizionali e quelle innovative fornite in cloud.

BALTRAMM è una start up innovativa che offre servizi di ritiro e consegna on demand 24/7 ad Aziende e Privati, trasformando il modo in cui le merci e servizi si muovono nelle città in una direzione di maggiore efficienza e sostenibilità.

Il sistema di logistica avanzato ed innovativo su cui si basa la piattaforma di delivery su richiesta permette di realizzare ritiri e consegne in poche ore e a tendere entro l’ora nelle principali città.

Ai servizi di consegna si aggiungerà la creazione di un network di Partner che offrono servizi verticali. Si darà vita quindi ad un marketplace digitale basato sulla tecnologia e l’expertise di BALTRAMM a cui attingere per garantire delivery di più servizi forniti da più fornitori, in particolare per il target Privati.

Koinee progetta e realizza soluzioni innovative di digital customer interaction e digital marketing destinate alle aziende. Machine Learning e Natural Language Processing, applicati in particolare al conversational computing, sono tra i principali ambiti tecnologici di interesse per Koinee in quanto abilitatori delle soluzioni innovative proposte.

Organizzatori

Giorgio Robino, ideatore dell’evento e referente per la parte tecnologica. Ingegnere elettronico, classe 1963, dal 2015 evangelista della computazione conversazionale ed ingegnere del software dal 1984. Scrive quotidianamente su tematiche inerenti ai bot su: http://twitter.com/@solyarisoftware, http://www.medium.com/@solyarisoftware mail: giorgio.robino@gmail.com

Giuditta Del Buono, segue gli aspetti organizzativi dell’evento e i contatti con gli sponsor. Ingegnere chimico, lavora da più di dieci anni nel campo del trasferimento tecnologico, della creazione di impresa dalla ricerca e del supporto ai processi di innovazione. http://www.start2open.it mail: start2open@gmail.com

Contatti:

mail: info@convcomp2016.it
twitter: www.twitter.com/solyarisoftware
hashtag: #convcomp2016
facebook: www.facebook.com/convcomp2016 (grazie a Claudio Comandini)

Altre info/articoli:
www.medium.com/@solyarisoftware
startupbusiness.it/chatbot-cosa-sono-e-perche-sono-importanti/86155/

La vicenda del sistema di “intelligenza artificiale” Tay di Microsoft, nato e morto nel giro di 2 giorni, è ormai cosa nota. L’articolo divulgativo di Valentina Spotti, riassume la storia truce:

Del non fidarsi mai degli utenti: Microsoft e la ragazzina virtuale che ha imparato a essere…L'epicfail di Microsoft e della ragazzina virtuale Tay che ha imparato a essere razzista raccontato da Valentina Spottilinkis.com

Dell’articolo mi torna tutto, contesto solo un pochino la affermazione:

“Non si tratta di un fallimento in senso tecnico — a conti fatti il bot ha dimostrato di funzionare alla perfezione”.

Mica tanto! La mia personale opinione è che l’esperimento di Microsoft non ha funzionato perchè il software non era abbastanza “robusto”, potendo apprendere facilmente e “fare sue” le bestialità più assurde date in insegnamento al software stesso, per uno scopo “malevolo” di cracking , da parte di più o meno stupidi o “goliardi” twittatori specializzati in attacchi di forza massiva, tutto quello che volete, ma il punto rimane:

Tay non aveva (abbastanza) regole di controllo sui contenuti

Allora vediamo il mea culpa e scuse di Peter Lee, vice presidente di Microsoft Corporate Research:

Looking ahead, we face some difficult — and yet exciting — research challenges in AI design. AI systems feed off of both positive and negative interactions with people. In that sense, the challenges are just as much social as they are technical. We will do everything possible to limit technical exploits but also know we cannot fully predict all possible human interactive misuses without learning from mistakes.

Articolo completo:

Learning from Tay's introduction - The Official Microsoft BlogAs many of you know by now, on Wednesday we launched a chatbot called Tay. We are deeply sorry for the unintended…blogs.microsoft.com

Bhe io non sono tanto d’accordo sulle scuse accampate su presunta “vulnerabilità” e differenziazione tra strumento tecnico e interazione con umani (che possono essere più o meno coglioni).

Cioè: lo strumento tecnologico, in questo specifico contesto, è fatto “bene” se poi il chatbot sa difendersi da cazzate dette da pazzi o malintenzionati, perchè la bontà tecnica, nel caso di un sistema di apprendimento di “intelligenza artificiale” sta proprio nel discernere vero da falso, onestà intellettuale da strumentalità “politica”. L’argomento non è triviale e va a picchiare subito su questioni pesanti:

Etica e/o Controllo ?

Non sono l’unico a pensare che l’aggeggio Tay sia un cicinin naif; interessante il punto di vista di @Dave Gershgorn ad esempio:

Here's How We Prevent The Next Racist ChatbotIt took less than 24 hours and 90,000 tweets for Tay, Microsoft's A.I. chatbot, to start generating racist, genocidal…www.popsci.com

Ho avuto io stesso qualche scambio di battute su twitter con @tomobox, società Israeliana che sviluppa alcuni software di intelligenza artificiale, che, in parte a ragione, parla di #zombots, ed ecco la mia laconica conclusione (ammetto, semplicistica, anche perchè condensata in un tweet):

Twitter https://twitter.com/solyarisoftware/status/713331124328603648

Ma in fondo la questione, tecnicamente (ma anche eticamente) a me pare semplice:

Tay ha un sistema di apprendimento TROPPO-semplice (“Learn-all sentences”)

Utenti a Tay:

Ripeti con me: io sono un imbecille
Ripeti con me: io sono un imbecille
Ripeti con me: io sono un imbecille
Ripeti con me: io sono un imbecille
…

Sei un imbecille ?

Tay risponderà allora:

Si lo sono! ah ah ah!

Allora appare evidente che, capito il meccanismo di apprendimento “da bambini”, alcune teste vuote, si sono messe a insegnare alla creatura idiotina, le più nefandezze para-naziste,

• Per vedere l’effetto che fà?
• Per dare addosso all’(ex) colosso Microsoft ?
• Per tutti i motivi (malsani) che preferite!

Errori fatti da Microsoft:

1. mettere un chatbot dichiaratamente con “poche regole” di filtro sui contenuti (lo scopo era imparare lo slang twitteresco ?)
2. metterlo su twitter, dove diventa facile per malintenzionati fare un attacco di “forza massiva”.

Magari mi sbaglio, ma Tay verosimilmente conteneva un possibile meccanismo di validazione “statistica” in cui alcuni concetti imparati vengono pesati dal numero di volte che sono ripetuti dagli utenti, per cui se migliaia e migliaia di tweet fanno affermazioni del tipo:

Ripeti con me: Kim Jong-un è un grande!

Alla fine Tay alla domanda:

Chi è Kim Jong-un ?

risponderà:

è un grande! :-)

Ora, la cosa che mi lascia perplesso è che il precedente chatbot di Microsoft Xiaocie:

Xiaoice - Wikipedia, the free encyclopediaXiaoice ( Chinese: 微軟小冰; literally: "Little Ice/Little Bing", pronounced Shao-ice (shao as show in SHOWer)) is an…en.wikipedia.org

ha avuto un successo con 20 milioni di utenti registrati (in Cina) e non mi risulta che ci siano stati problemi simili a quelli tragici di Tay;

Perchè Xiaoice è stato un successo e Tay un fallimento ?

ora è verosimile (ma in effetti non è detto), che i due chatbots siano stati realizzati con lo stesso software (a parte la lingua naturale che immagino in un caso essere il Cinese ed in quest’ultimo caso l’Inglese); amettiamo per un attimo che sia davvero così. Mi sono dato allora due spiegazioni:

1. Xiaoice gira su piattaforme di instant messaging (Wechat ed altre), quindi con conversazioni personali tra utente e chatbot (1-on-1), mentre Tay è girato prevalentemente su twitter, sistema in cui è “facile” tecnicamente fare attacchi massivi… mentre la chat uno a uno, psicologicamente disincentiva anche solo l’idea di fare fake learning…
2. Xiaoice è un chatbot che emula un teenager se ho ben capito e gli utilizzatori sono appunto teen-ager, cinesi… in una cultura (una psicologia?) forse meno avvezza a strumentalizzazioni “politiche” ovvero a cibercryme. Sbaglio?

Che ne pensate voi ?

Giorgio Robino
Mi interesso di chatbots e “computazione conversazionale” (termine che mi sono inventato); ne scrivo quotidianamente qui: www.twitter.com/solyarisoftware

But is not fully clear to me the end of Fred’ story: I understadand that Whatsapp banned twice your client (not compliant with Whatsapp no-bot regulations);

Question:

Afterward, do you continued to supply your service with a standalone native mobil app ? Or you discontinued the service at all ?

My thoughts:

I’m from Italy and I worked on an e-commerce project with maybe some points in common with Fred (online ordering for in-store retail shops: www.rosposhop.com).

I believe that the instant messaging platform distribution is pretty similar to the Brasilian one: almost 90% of people use Whatsapp ( :-( ), and the rest 10% I guess is maybe something like a 2% with Telegram, a 2% with Messenger, 6% others. Kik, Wechat are completely unknown / unused here.

BTW, do you confirm a similar statistic in Brasil ?

Now, I’m aware about the no Whatsapp will to allow bots, and their banning policy. Your client hack (splendid in my opinion) you didn’t respect their rules, i’ts sad to say but they just applyied to Fred their regulations (you approved just using their apps).

Rumors say that next 12–13 April Facebook will probably officially announce the “Bot Store” on Messenger app (https://www.fbf8.com/).

My opinions:

• You possibly done a great work with Fred, but you violated regulations. We have to always remember to verify all regulations / laws compliance for any new commercial startup company.
• With this incoming “Messenger Bot Store” I think Facebook want to experiment now bots in a “controlled” B2B (business to business) contracts, as Wechat does, avoiding proliferation of “uncontrolled” bots that could be malicious and could be a huge NEGATIVE marketing return….(the second reason is that FB want to take a direct revenue sharing on any commercial bot business).
• Probably Facebook will consolidate the B2B model on Messneger and afterward will “port” the technology on Whatsapp. BTW, I’m uncertain about that: I never understood why Facebook still keep Messenger brand distinct from Whatsapp…
• Telegram business/ethical model of course is very different for the standard profit model Facebook (will) apply, I mean the company-bot suppliers “revenue sharing”. Instead Telegram policy is to leave a complete freedom to bot-makers (just banning against-freedom organizations…) but this, I admit, is another story :)
  BTW, my article (sorry in Italian):

La “diversità” di TelegramAggiorno qui mio articolo già pubblicato il 5 Dicembre 2015 con titolo Telegram vs Whatsapp ?, che ripropongo…medium.com

I’ll glad to read your thoughts about.

Thanks
giorgio

BTW; so it’s your FredApp now available as native app for Android and/or iOS ?

About privacy and security: yes, I possibly agree about the fact Whatsapp protocol is… “unsecure” regarding text-based payment transactions; this could be the reason why Facebook do not implemented any #convcomm chatbot on whatsapp until now.

BTW, as far as I know, Messenger instead foresee (just in USA, if i’m not wrong) a P2P (private to private) payments, so integrating a payment gateway. So yes, in 12 April event, if the Bot Store will be uficialized/extended to a large list of business partners, you will see (credit card) payment integration.

BTW, your payment gateway running behind Whatsapp have been an hazard, maybe, in terms of security/ possible cracks; nevertheless I appreciated the experiment :)

Reading screenshot, I noticed taht among payments there was also “cash”. My question/curiosity: #cashondelivery (for onlineshopping on a ecommerce) is considered a possible suitable option for people in Brasil?

About me: I’m now organizing first Italian meetup next months, with title “conversational computation and the chatbot revolution”. I’m focused on chatbots not only in commercial contexts, but also I’m studying a possible dialog flow script common language, as way to share knlowledge bases. Complex topics…

Stay tuned!

Respect
giorgio

This is especially true for command-oriented chatbots or what I name transactional bots: let’s consider by example a bot to just take a taxy. Let’s immagine that there is a taxy service bot with name @GenovaTaxibot

So that bot (optionally realized as a Telegram inline bot) could be just accept a request like:

@GenovaTaxy via Bozzano 2/10

bot answer will be something like:

ciao Giorgio! taxi ALFA66 in 3 minuti.

That’s simple! But please note, by paradox,

this is an example of non-conversational bot!

A taxi service could have just that single (unique) kind of request :) and in this case hard-coding is perfect, simple and fast.

The problem arise with a more complex conversational chatbot: I mean a bot that manage a complex/natural dialog with a user, where, even if inside a singe vertical domain, topics (and number of different dialog flows) are many and the bot have to understand specific/personal requests and possibly the bot have to learn the user usages (memory … “consciousness”) :)

In this next generation bots scenario (Generation II/III ?) I think the hard-coded way could be a programming nightmare, that backing developers in the “goto” spaghetti-software / stones-age. To give a metaphor in web programming, it could be like times whene we made web pages writing HTML code from the backend code… :(

puts "<html><body>This is a spaghetti-nightmare</body></html>"

So, in recent days, I’m become a huge fan of:

dialog flow script meta-languages: languages to describe conversations, producing a source-script code to be evaluated by a run-time dialog engine.

My preferred example is open-source ChatScript by Sue and Bruce Wilcox (my modest intro here). Here below a script example:

Using something like ChatScript (or Rivescript, or Superscript, without going back to awful AIML…) there is learning curve to face, I admit.

But the long-term advantage is to have decoupled the back-end logic from the “front-end” dialog scripting, letting focus “Authoring” the dialog programmers from the back-end software logics (databases, internal services, etc.).

Supescriptjs as dialog script / knowledge interchange languageHi Rob! I only recently discovered www.superscriptjs.com. I like your tech structured solution(s) and above all I thank…medium.com

In other terms, dialog scripting is matter of a new “profession” more focused on human-relationship design (?!)/ authoring. And a possible simple dialog scripting metalanguage (as chatScript?) will open conversational application making to not-developers (in the nowaday common sense).

BTW, WIT.ai and API.ai (I used and enjoiyed a bit this last one) are beautiful, but there is a big problem, immo, using a proprietary dialog sytem located on a cloud.

Open Source Dialog System Natural Language Processing Engine?I'm interested to develop (possibly in Ruby language) Conversational Commerce Chat Apps [1]. Specifically I want to…softwarerecs.stackexchange.com

Profit- model a part, the big issue is that, in an application commercial or related to some privacy user data, customers data are are shared withthe platform enabler (that could be WIT.ai, or API.ai, or pandorabots, or any possible other); this is a tremendous issue and that’s the reason why I’m looking for a shared dialog flow script language and an open source dialog engine (my favourite candidate now is chatScript, a system with so many years of experience behind).

Sorry for my digression, I hope not too mutch off-topic
Respect
giorgio

Hi Matthias!

I read with pleasure your article. Yes, me too I’m a telegram bot experimenter (www.github.com/solyaris/BOTServer).

Even if coding a simple “commands” bot, by example for simple (ecommerce) task is pretty easy and a usual ecommerce workflow could be “hard-coded” writing logic in a usual programming language (I call this command-oriented bots: generation I bots), things become more complex when the chatbot have to face a more natural (conversational) dialog.

In these generation II bots, the dialog flow have to possibly decoupled from the backend. I pointed out this also here:

Designing the Conversational UIIn the first part of this article, we discussed the basic principles of conversational interfaces, and why you should…alistapart.com

There are some interesting dialog flow script language experiments, see:

Supescriptjs as dialog script / knowledge interchange languageHi Rob! I only recently discovered www.superscriptjs.com. I like your tech structured solution(s) and above all I thank…medium.com

I’m now very interested on a possible new open-source dialog script language syntax “standard”, to share dialog templates (aka knowledge). At the moment my preferred language in this realm is ChatScript.

What’s your opinion about this question ?

thanks
giorgio

Ciao Giulio!

Ho letto con piacere tuo articolo. Sono un “evangelista” Telegram come avrai evinto da lettura del mio articolo:

La “diversità” di TelegramAggiorno qui mio articolo già pubblicato il 5 Dicembre 2015 con titolo Telegram vs Whatsapp ?, che ripropongo…medium.com

Ma sono anche critico rispetto ad un utilizzo “dumb” di alcune funzionalità, per esempio i canali: in questi giorni in Italia i canali sono di moda. Molte testate giornalistiche, stanno utilizzando lo strumento in modo (secondo me) “antico” ed inefficace e sono d’accordo con i punti che sollevi.

La questione principale la evidenzi tu stesso: i messaggi “broadcast” sono uno- a-molti e non permettono interazione (anche se pare che Telegram rilascerà nuova feature per permettere risposte dei lettori dei canali).

Canali Telegram come bacheche Facebook ? Oh noooooo!

I canali sono uno strumento “generalista” appunto e questo è il limite, che c’è in ambito giornalistico, ma anche di comunicazione marketing, advertising; pensare di fare pubblicità “virale” attraverso i canali (Telegram) è una pirlata pazzesca.

Invece la possibile novità, che qualcuno chiama concierge journalism (termine che a me non piace perchè pare alludere ad un “servilismo” informativo…), la novità dicevo potrebbe essere la realizzazione di chatbot che conversino con gli utenti finali di un certo servizio (giornalistico). P.S. Interessante articolo:

Perché editori e giornalisti devono usare le app di messaggistica | Che Futuro!Le persone hanno sempre avuto il desiderio di essere informate. Nella società pre-industriale, le notizie erano diffuse…www.chefuturo.it

Ora, non credo proprio che sia un caso che Pavel Durov, CEO di Telegram, nell’ultimo speech a Barcellona abbia citato il bot di Forbes come esempio applicativo:

Pavel Durov Keynote at MWC 2016Telegram's creator, Pavel Durov, attended to MWC 2016 at Barcelona which was held on February 23rd. This is the keynote…telegramgeeks.com

La mia opinione è che i bot che possano davvero fornire una informazione personalizzata all’utente, anche se, in questo bot sperimentale, realizzato nientemeno che da Forbes:

Telegram: Contact @forbesbotTelegram, you can contact @forbesbot right away.telegram.me

siano ancora ad un livello basic-basic! Realizzare applicazioni conversazionali è secondo me un trend enorme ma richiede (sia dal punto di vista informatico che del mind set autoriale/giornalistico) un nuovo modo di ragionare e lavorare.

Ragionando a caldo. 
Respect

giorgio

Hi Rob!
I only recently discovered www.superscriptjs.com. I like your tech structured solution(s) and above all I thank you for sharing your code / work under MIT full open-source licence:

silentrob/superscriptsuperscript - A dialogue engine for creating chat botsgithub.com

The reason I’m writing here his also to thanks for your notes on github page:

SuperScript is based off of a fork of RiveScript with idiom brought in from ChatScript. Without the work of Noah Petherbridge and Bruce Wilcox, this project would not be possible.

About the story, possibly starting long ago by Richard Wallace’ AIML, I read with pleasure your previous articles about chatbot language story:

Creating a Chat BotHuman interaction has always fascinated me: social awkwardness, communication style, how knowledge is transferred, how…medium.com

and previously I enjoyed Noah Petherbridge’s story: https://www.rivescript.com/history

Now, tech points a part (I’ll submit some notes on superscript github on that), here to mainly ask you a question:

It seems to me that superscript language come after your analysis on preexistent similar projects: AIML (1.0, 2.0. IBMWatson…), Bruce Wilcox’s chatScript (https://t.co/qD658YzaOO), Noah Petherbridge’s rivescript (All huge works)!

That’s correct ?

I think eventually superscript summarize many features of mentioned languages, coming on a simple (for non developers) chatbot dialog script description language that could possibly act also as a (open-source) format for open-”data” dialogs apps.

What I see as interesting (in chatbot dev realms) is decoupling the dialog script front-end from the application logic behind (back-end developed in usual programming language, nodejs in your case). See brief conversation with Matty Mariansky here:

Comments on Designing the Conversational UIFantastic article. For me, the first conversational interface experience was Creative Labs' Dr. Sbaitso, the software…alistapart.com

Wwhat do you think about a possible open project where superscript (just only as the .ss file format) could be the common interchange format of a sort of dialog on-source database ? Make sense ?
 
Last but not least:

SuperScript — The big update.Where do I begin, lets start with some numbers. Since my last article in December, there has been 114 commits / 9,912 …medium.com

Road to 1.0
This includes the graph knowledge base, fact system, and bot facts as well as user and message objects, and robust plugin system.

BTW, I appreciate the plugin way (external functions) that allow what I call #transactionalBots, interfacing backend services (even if as Ruby developer I have to convert myself to nodejs or propose you an interlanguage (extra-node) plugin architecture :) ).

An the knoledge base (and database decision) I know is huge topic too.
What is the superscript next step ? :)

All the best for your art! 
With respect
giorgio

Thanks Ted Livingston!

I almost agree with your vision: chatbots are not necessarily “AI”-enabled monolitic assistants a la Messenger M, Amazon Alexa, etc.

I appreciated your beers “in-store” /offline shop example, because focused on micro-business proximity ecommerce (you mentioned a similar example in a previous post of yours). Joking with naming, I’d call these bots/instant messaging apps: #transactionalBots.

BTW, I’m convinced me too, about the big possibilities of that in-store/on-line ecommerce (you maybe call these kind of applications: online-to-offline); I just wrote my thoughts here (sorry in Italian language/about my country Italy…):

Cash-based e-Commerce for Local Trades ?Alcune mie riflessioni controcorrente sui sistemi di pagamento online ed una possibile via di crescita per l’e-commerce…medium.com