How to Architect a complex problem in ML/AI
Oct 13, 2022 | Jagannath Rajagopal | 6 min read
First you need to understand it well. In a Hero problem — a complex problem in AI solved by Hero Methods — there exists the notion of a dichotomy between the inside and the outside. In Reinforcement Learning, you have an agent and it’s world. You’ll need to analyze both — the inside and the outside, in detail.
- - -
Nature of the problem
What are the different aspects of your problem? Is it primarily data-driven, i.e., does data take foremost precedence in arriving at a solution? Or is it principle-driven, i.e., algorithms, methods and techniques are primary. Or, is it knowledge-driven, where the central aspect is formal or expert knowledge.
Aspects you need to consider include Customization, Scaling, Specialization, etc. To define the Inside, there are 10 different aspects -
- Data vs. Principle vs. Knowledge
- Structure, Ownership and Capture
- Design vs. Training vs. Inference
- Customization & Scaling
- Specialization vs. Generality
- Hardware and Performance
- Virtual vs Physical
- Person or Machine
- Complexity to Structure
Trustability/Provenance. To elaborate on one of the above, this is a common point of pain — dealing with having to build a black box. Many complex problems in Machine Learning and Optimization are hard to debug because it’s not always easy to look under the hood. If so, can you avoid it? If not, what do you do?
- - -
Nature of the world
World definition advises problem definition. AI Architects and ML Engineers sometimes tend to ignore World Definition even though it influences design in a non-trivial way.
Aspects you need to consider include Visibility, Multitude, Uncertainty etc. To define the Outside, there are 6 in total -
- The Need for Memory
- Is the World Fully known
Visibility. To elaborate on one of the above, if the world is partially visible, the model may have to maintain memory of some sort — to remember the parts of the world it has encountered, as seen as system state in Planning and RL.
I’ve created a LOT of resources on Hero Methods. Here’s my course on Design Thinking for Hero Methods. Here’s my YouTube channel with previews of course videos. Here’s my website; navigate through the courses to find free previews & pdfs.
- - -
Once you’ve understood the problem and the world, it’s time to break it down into sub-problems. In order to get complex top-level systems like Smart Buildings, Autonomous Vehicles etc working, you’ll need to solve multiple smaller problems.
A common way to do so is by hierarchy inherent in the problem. In NLP, are you modelling letters, words, sentences, paragraphs, sections, or documents? If you sell potato and other types of chips, it may be by family — potato vs tortilla, flavor — plain vs barbecue, pack size etc. Problems solved at different levels in a hierarchy almost never relate to each other in a linear way.
Problems may also be decomposed based on Inter-relationships — between levels and individuals. If correlations are a part of your problem, this may be relevant.
- - -
OK, I’ve decomposed my problem. Now what?
First, you hypothesize a solution for every sub-problem. In order to do so, you need to understand your method/technique choices.
Which methods can stand-in or replace what others? You need to ponder Interchangeability. If you are modelling something as a learning problem, it may be OK instead to solve it as an optimization problem, as long as there is no need to learn anything, as would be the case in one-off datasets.
How do methods extend others? How can two or more be combined together to solve a problem? It helps to think of pairs or triplets first. Perhaps the input of your problem needs to be enriched by an Ontology. Or the output post-processed by a learner. Stacking methods is a useful skill set to develop.
Also, if there exist patterns where methods are combined together, you would need to know that. If you have the model of an individual, how would you scale that up to study a crowd?
Armed with knowledge of interchangeability, integration and patterns, you can now architect your solution. These form the basis for stringing methods into an architecture which you can experiment with and iterate.
In the process of doing so, avoid pitfalls. As a principle, avoid solving top-level complex problems with a single large deep net.
Instead, perform these steps collaboratively -
- Draw a flowchart with the different functional parts of the solution. If you are modelling a crowd for example, you potentially have 3 steps: a) Model an individual, b) model a crowd, & c) model behavior.
- In the flowchart, apply a method to each function. In the above, you could have: a) Supervised Learning, b) Discrete Event Simulation and c) Agent Based Simulation.
- Now, select a technique for each method: a) Linear Regression (ML), b) SimPy/AnyLogic (DES), and c) WASABI/GAMA (ABS). Sometimes, there may be more than one. [a) is a method, while b) and c) are apps]
This is how you hypothesize an architecture. Include metrics and measures to validate performance both during training and operation.
With that, not only do you now have your initial solution concept, you also have a structure that will let you swap methods and techniques based on how well they work for a problem.
In order to solve a complex problem…..
…..decompose it into sub-problems…..
…..select your methods & techniques…..
…..and assemble them in an architecture along with the appropriate metrics.
- - -
At Kado, we showcase how to put together solutions for complex problems in the AI domain. Our goal is to get you started on this. Think of our courses like music school. Just like a young, fresh graduate of music school is not yet as well honed as a long-time musician, completing this course will not immediately place you on the same level as someone who has done this for years. The key to mastery for yourself, and our music student, is experience and hands on application.