The reasons for and methods of developing chatbots: an overview

In linguistics, a portmanteau is a word that combines two words into one. The term chatbot refers to chatting, an activity that has become commonplace in private communication as a result of digitalization. On the other hand, robots are even better known, and their introduction into many areas of life has already been accompanied by a wide range of emotions and will continue to cause a stir in the future. One of the key questions here is what role a bot can, should, or must play in order to deliver real added value.

It is precisely this understanding of the role that must be examined closely when using chatbots in intralogistics before the first steps are taken toward implementation.
Many internet users have already encountered an automated question-and-answer game on a website, especially in the B2C sector. Such a “conversation” was satisfactory for simple content, but often failed when it came to a more in-depth discussion of the user’s problem. Large companies in the B2C sector in particular are therefore working to continuously expand the repertoire of preset solutions for their chatbots and to incorporate artificial intelligence (AI) so that answers can be generated in the software itself without the preparatory work of programmers.

In an industrial environment such as intralogistics, the focus of every consideration is on the ability of certain roles to act within the company and on the management of complexity.

The five chatbot assistance models for employees in (intralogistics) corporate environments:

• Office Assistant: Performing administrative tasks (meeting organization, email drafting)
• Performance Assistant: Answering factual questions (inventory figures, picking orders)
• Process Assistant: Supporting employees/warehouse staff (guidance/advice on work processes)
• Discover Assistant: Taking over activity documentation (presentation of filtered information)
• Operator Assistant: Clarifying problems (actively implementing alternative solutions)

Looking a little further into the future, particularly in terms of the further development of artificial intelligence, two additional assistance systems are conceivable in which chatbots could be used:

• Teaching Assistant: Conducting training courses (explaining tasks, including alternatives)
• Support Assistant: Handling support work (ad hoc consultations as needed)

This brief overview of the possibilities alone makes it clear how wide-ranging the potential field of application for smart chatbots can be.

Chatbots can be divided into different categories. Criteria frequently cited in the specialist literature include use, knowledge domain, and design. In terms of use, a distinction can be made between task-oriented and non-task-oriented applications. The command to a digital assistant such as Alexa to turn on the living room light or play your favorite song is clearly task-oriented.

For this, knowledge within a closed domain is sufficient. To execute the example task “turn on the light,” a specific function is called up via an interface to the smart home or to the Wi-Fi-enabled light bulb. For this type of data and service provision, a query-based design approach can be chosen, which has a pool of predefined functions and responses.

Generative design approaches overcome this dependence on predefined responses and functions by generating new responses independently. They operate in an open knowledge domain and have no predefined tasks or functions. The resulting conversation flows are not task-oriented and do not usually pursue a direct goal. This type of chat bot has been used primarily in research and, until recently, has found little application among end users.

ChatGPT marks a turning point. This is because the tasks that a chatbot is supposed to perform are being rethought. While in recent years the tasks were defined in a closed solution space – e.g., “Send a message I have formulated” – ChatGPT fulfills the other side of the task, namely the independent formulation of the text, while users send it themselves.

On the one hand, there are call-based instances that enable completely (pre)scripted responses, and on the other hand, there are variants that process freely formulated language. Two other aspects are important for use in an industrial environment: user experience (UX) and ease of use. Looking to the future, hybrid forms between the two categories are of course also possible.

In English-dominated technical jargon, the term natural language processing (NLP) is widely used. A chatbot encounters natural language in a wide variety of forms, which it must recognize and process. These are decoded using lexical analysis. In the more complex tasks mentioned above, which go beyond simple commands, it encounters the respective chatbot in varying vocabulary, dialect, intonation, etc. This human form of expression, understood here as code, must be converted into tokens that are assigned a meaning and are thus identifiable by the bot.

During tokenization, sentences are split into words and categorized as so-called lexemes. This can be done, for example, using the whitespace separator. The resulting part-of-speech tokens (POS) are then converted into meaningful phrases (nominal, verbal, etc.) during the next step, chunking. The next step is named entity recognition (NER). This enables comparisons to be made, such as recognizing that shoes are clothing. Using machine learning, this knowledge must first be created using a basic set of manual training sentences. This entity determination allows conclusions to be drawn about the speaker’s intention. In the example shown, the user wants to order shoes in size 8.

The message is now initially recorded. The key content, intentions, and entities are stored in variables in the dialogue state tracker. This allows the chatbot to retrieve this information at a later point in time. If something is missing, the bot must fill in these information slots.

Slots:

Taking the above options into account, the chatbot can either output predefined responses or practice natural language generation (NLG), i.e., the independent creation of artificial “natural” language. Once all slots are filled, it is ready for operation.

Once a company has decided to implement a chatbot, there are many options for doing so. The various stakeholders involved must be taken into account and a frame of reference created between them. Factors that are not restrictions per se but are intended to prevent an “anything goes” approach must be considered. These include:

• The company itself: What are the internal goals and structures?
• The technical constraints: Is the existing framework suitable, and are the skills and resources available for an in-house solution?
• The legal framework: Is there a framework that is fully GDPR-compliant? After all, depending on the type of chatbot, statements are stored that can be assigned to individuals.

Based on the RASA framework, the first prototype for a TUP chatbot was developed under the direction of Yannick Schellert. The Operator Assistant was selected for demonstration purposes, as its use in intralogistics appears particularly promising: For example, stocks or articles could be blocked and released, and messages could be attached to individual orders. Real warehouse data from the TUP dialog system served as the data basis for the prototype simulation.

The case study provides a more concrete idea of the range of possible applications in intralogistics. Even in the internal test scenario, which only showed a small selection of potential applications, the added value of the Intralogistics Operator Assistant concept became apparent. Here are a few examples:

• Fast mobile data retrieval on the MDE device that is carried anyway
• Easy operation with individual language patterns
• No special vocational training required for use
• Combination of the two previous points of simplicity:
  • Technical terms are not absolutely necessary, as alternative terms also lead to successful information retrieval. Example: The test database uses the technical term “actuator,” but the message of the query is also recognized by alternative, more intuitive terms such as ‘user’ or “operator.”

The economic added value of a chatbot application results from the combination of various functions. The more extensive these are, the more helpful the digital assistant becomes. For standardized queries, individual calls via a button are faster and more effective for passing on information. For complex problems, chat-based queries are also an intuitive way for new employees to access information about processes or inventories as needed without having to search through digital or paper-based documentation.

The more functions are integrated into the chatbot’s configuration – even beyond the operational role mentioned above – the more powerful the technology becomes. This creates more application possibilities and allows overview information to be included.

If a company wants to use the digital tool chatbot for itself or its project partners, clear objectives should first be defined and the necessary framework conditions created. The following are key variables that prepare the ground for installing a chatbot and avoid dead ends:

The most important question at the outset is: What should the chatbot support? Without a well-thought-out answer to this question, its development is likely to be a waste of time. In addition to the primary area of application, it is important to consider at an early stage what other tasks a digital assistant could potentially cover. The more the bot can do, the more support its use will have among the workforce. It is advisable to involve external perspectives, such as those of project partners, at an early stage in order to identify possible additional areas of application. Depending on the project, this may involve larger topics, specific functionalities, or even individual commands. If necessary, user-specific versions can also be implemented – these can then be anchored in the chatbot using a feature. This further increases universality in terms of functionality, in line with our guiding principle of “software follows function.”

In science fiction literature, bots and the AI behind them are self-learning; in today’s technical jargon, this is referred to as strong AI. This is not (yet) the case in reality. New functionalities continue to emerge through human intervention. Nevertheless, sufficient training data should be made available to the AI, which in turn can expand the perception data of the respective bot. For example, general usability can be expanded by using the largest possible vocabulary that takes into account customer-specific terminology.

With regard to data protection guidelines, it is imperative to clarify the hosting and access rights of the software architecture used in a legally compliant manner. Information storage must be clarified with the project partner who has data sovereignty so that access to sensitive data can be guaranteed on both sides and, above all, securely. In general, GDPR compliance is a very big issue in the context of AI. With applications becoming increasingly complex, further challenges will arise in the future.

Implementation on the provider side is complex. It must therefore be ensured that sufficient resources are available. A chatbot project requires a large number of employees in various roles. These include, among others, the following:

• a content manager
• the chatbot developer themselves
• backend support
• the interface developer, and
• the frontend developer

Depending on the project, additional areas of activity may be required to achieve the final goal – an excellent UX.

The technical requirements of data protection are also a top priority here. In addition, the digital assistant itself requires professional organization to ensure that software releases are implemented adequately. Since data is generated in parallel on both the developer and user sides, a functioning pipeline for continuous development (CD) and continuous integration (CI) is essential. The bot should be designed as closely as possible to the user experience. From the backend, the developer can quickly see where problems arise in everyday use and where there is potential for optimization. These are the areas that need to be tweaked, and in some cases, this also opens up scope for further improvements.

While task-oriented chatbots have previously operated in a closed solution space, various large language models such as ChatGPT, Llama, and Gemini are now demonstrating what is possible in an open solution space. Multimodal input and output in the form of text, images, and code are now also possible. It will be exciting to see how well the two use cases can be combined—for example, in the request: “Formulate individual Christmas wishes and send them directly to all employees.” However, such a step also carries a certain risk. If Easter greetings are suddenly sent instead of Christmas wishes, it will certainly cause a laugh. But what if an Operator Assistant in intralogistics independently deletes all inventory data? Here, it is important to weigh up the opportunities and risks and coordinate access rights.

LLMs already excel with their wide-ranging knowledge and ability to adapt results in multiple iterations. So what is possible when you feed the technology with insider knowledge in a specific field by providing it with all internal and publicly available information relating to intralogistics? It could then be possible to support employees with more complex tasks such as warehouse planning. Only time will tell whether a machine will ultimately plan, optimize, and adapt more efficiently, and how much freedom we want to give it in doing so.

Chatbots in intralogistics promise to automate processes and thus increase efficiency in the handling of a wide variety of tasks. However, development is still in its infancy and requires a precise examination of the challenges to be solved – otherwise, unclear requirements will quickly lead to frustration among those involved. This must be avoided in advance through intelligent, targeted action.

Introduction to classification

• A Survey on Conversational Agents/Chatbots Classification and Design Techniques by Shafquat Hussain, Omid Ameri Sianaki, and Nedal Ababneh
• A Survey on Dialogue Systems: Recent Advances and New Frontiers by Hongshen Chen, Xiaorui Liu, Dawei Yin, and Jiliang Tang

Understanding NLP

• Natural Language Processing (Almost) from Scratch by Ronan Collobert, Jason Weston, Léon Bottou, Michael Karlen, Koray Kavukcuoglu & Pavel Kuksa

This article appeared in an abridged version in issue 7 2023 of the trade magazine DHF Intralogistik.

Back to the home page
To our other blog posts
To our references