In recent years, combining machine learning and knowledge engineering has been gaining significant attention among researchers in industry and academia. While many classical hybrid architectures follow a unified or transformative approach, modular architectures built from independent yet interacting modules are becoming more and more popular in practice. State-of-the-art architectures like the IBM Debater system, for example, are based on distinct modules that implement diverse capabilities, such as speech recognition, natural language processing, reasoning, and speech synthesis. For designing future systems of this kind and complexity, we propose to use the so-called AI=MC2 Taxonomy as a systematic and eficient tool. To this end, we introduce a practical step-by-step procedure for specifying modules of hybrid architectures based on specific artificial intelligence (AI) methods and capabilities. We explain this procedure by example and conclude that this approach will be relevant for future AI designs.
Modular design is a key principle in modern industrialized development processes. In product
design, for example, applying a modularization strategy will yield modular products, or in
other words, products that “are made of modules, building blocks“[
In computer science, too, modularization is an influential and widely applied concept, both
in hardware and software development. A prominent example is object-oriented programming
where organizing all structures and processes in so-called objects represents the central design
paradigm [
Modular hybrid AI has been characterized by various criteria. In classical taxonomies, only
loosely and tightly coupled hybrid modular architectures are distinguished [
Over the last decade, AI-based products and services have become a major technological trend.
The development of such AI applications in large numbers and for a growing number of use
cases has begun to drive a process of standardizing and modularizing AI solutions in industrial
contexts. A prominent exhibit for this the development is the German national roadmap for
standardization of AI [
The AI=MC2 taxonomy reflects and condenses, in particular, available AI methods and
thereby implementable cognitive capabilities into a unified framework. A unique strength is its
level of granuality: It diferentiates not only between top-level capabilities (sense, process, act,
communicate) and top-level methods (traditional AI, symbolic AI, machine learning, hybrid
learning), but rather goes into three levels of details on the basis of existing scientific findings
and taxonomies; examplarily named specific algorithms make up even for a fourth level. For
the capability to process, for example, the subcapability to provide cognitive processing abilities
(one among several) is further diferentiated into 24 specific and distinct subsubcapabilities.
In fact, this taxonomy is today so comprehensive that its most recent version it now covers
more than 30 pages in the accompanying book [
Designing by means of modularization may be described as carrying out one or more of the
following and potentially complementary tasks [
The identification of modules is supported by the taxonomy’s dimension of AI capabilities, which allows to diferentiate overall goals in functionality and specify subfunctionalities to be implemented in individual modules. The actual design of such modules on the other hand is supported by the dimension of AI methods, which allows an intuitive review and selection from a large variety of techniques available for implementation. In the next section, we will outline how to use the the AI=MC2 Taxonomy eficiently along the entire process from identifying modules to designing modules and finally to designing with specified modules.
In order to achieve a structured approach, we propose a three-steps procedure for the development process. Initially, a detailed capabilities analysis is performed. In a second step, a methods analysis is to be carried out. Finally, the interconnections between and/or the ordering of the thereby identified modules is to be determined. This is referred to as the module pathway. Going through these three steps provides a straight-forward and eficient route from analysis to implementation. In the following, we illustrate this procedure along an example, in which we aim to design the modules of an audio chatbot comparable to Apple’s Siri or Amazon’s Alexa. We start under the assumption that no suitable modules have been designed so far.
Similar to requirements analyses in software development, a thorough and structured description of the overall intended functionality is required in order to lay the foundation for an eficient specification of the building blocks of the system. In particular, this implies to translate general requirements for the system into the more specific capabilities defined by the AI=MC 2 taxonomy. The outcome of this step is the identification of the required modules.
For our example of designing an audio chatbot, we would in this step start with the rather general observation that is should be able to sense, process and communicate in order to provide the intended functionality. From these top-level capabilities, second-level capabilities are identified. For sense, for example, the second level would make a distinction between internal and external sensing, where internal comprises self-awareness and balance and external is further divided into the capabilities to see, hear, small, taste, and touch (Fig. 2). The most specific capability – here: hearing – then identifies our first module.
Let us assume that during the capabilities analysis, three distinct modules have been identified. Module A is identified by sense/external/hear. Module B is identified by process/conceptual/ classify. And module C is identified by communicate/without feedback/unidirectional. During methods analysis, suitable AI methods for each module will be identified. As a result of this step, a method is determined for each module that will be used to implememt the related capability. In particular, this completes the task of designing a module from an architectural perspective.
For each identified module, we would in this step switch the point of view to the methods dimension, consisting of the top-level methods traditional AI, symbolic AI, machine learning and hybrid learning. An initial design decision would be whether a data-driven or a knowledgebased approach is to be chosen. For modules A and C, for example, one would typically choose a data-driven approach from the area of machine learning (Fig. 3). In order to actually implement module A (hear) the corrresponding second-level methods (here: reinforcement learning, supervised learning, semi-supervised learning, unsupervised learning, and adversarial learning) will be reviewed. Due to many existing references architectures, we might end up implementing module A by supervised learning and module C by adversarial learning.
Now we have arrived at a point in the design process where all relevant modules have been identified and specified. So far undefined, however, is how these modules will interact with each other in the actual system. Therefore, the ordering, interaction, and related interfaces will be defined for all modules in this third step of the process. This may be seen as the actual design with modules and will be guided by the overall intended functionality.
In our example of designing an audio chatbot, for example, we could end up defining a connection sequence of module A → module B → module C. More specifically, we would further define the corresponding interfaces AB and BC in a way that module A expects an audio input (speech) and delivers written text (derived from audio input) as input for module B, which in turn will provide written text as input for module C, which will then generate speech (audio) from this text. All together, our toy audio chatbot specified by these three modules will then be able to accept audio input, proceed it according to the intended functionality, and finally return an audio message as answer to the user. Based on this architecural specification, development teams can take up the actual implementation process – or reuse existing modules.
We have introduced the AI=MC2 taxonomy with a focus on its use for designing modular hybrid AI systems in a structured, systematic and eficient way. We have demonstrated that the multi-level granularity of this taxonomy regarding both methods and capabilities of AI systems provides an ideal basis for the design of modular AI systems. Moreover, we have defined and exercised a three-step design procedure based on this taxonomy. In conclusion, we have introduced a novel and eficient design strategy for modular hybrid AI.Given that this is only an initial overview of the concept, more practical specifications of the design procedure will, of course, be necessary. In future work, we will therefore further elaborate the described procedure into more detailed guidelines and practices for the design of AI systems.