Major Components Overview
Nothing to see here! Scroll along!
Bonsai’s AI Engine has several major components.
- The architect: generates learning models using the Inkling program and characteristics of the provided training lesson(s).
- The instructor: trains those topologies according to the information set out in the Inkling program. Specifically, it is responsible for taking the curriculum and lesson plan and directing training between the learner and the data source(s).
- The learner: does the learning for the lesson(s).
- The predictor: predicts new outcomes generated by the AI when presented with new data. It is used during training and execution of an AI and is the intended production deliverable of the Bonsai Platform.
There are many other parts of our system that are more common—systems for storing and querying data, systems for streaming and manipulating data, and plumbing to expose models in the AI engine as API’s
The Bonsai AI Engine keeps versions of BRAINs. Each BRAIN can contain multiple versions. A BRAIN version is a snapshot of the brain at a particular time. Each training session generates a new version of the BRAIN, with a new snapshot of the user files pushed to the BRAIN. This way you can compare the training or prediction of your latest version of a BRAIN with previous versions. When training a BRAIN, you are actually training a specific version.
The architect component is responsible for creating and optimizing learning topologies (e.g. neural networks) based on mental models. In essence, it takes the codified mental model and pedagogy, and it proposes a set of candidate low level learning algorithms, topologies, and their configurations that it believes will best be able to learn the concepts in the model. This is akin to the work that the data scientist does in the toolkit approach, or that the search system automates in the statistical data analysis tools approach. Here, the system, is guided by the provided pedagogical program instead of being a broad search.
In this section, we outline techniques used by the architect to determine reasonable architectures.
Currently Supported Models
At the moment, the Architect chooses from only a small number of solutions. As time goes on, this library of solutions will grow. At the moment we currently support Q-Tables, DQN (Deep Q-Networks) and DDPG (Deep Deterministic Policy Gradients) as our primary reinforcement-learning solutions. In a multi-concept inkling file, the Architect may mix-and-match solutions depending on the complexity of subconcepts.
First, many heuristics regarding the mental model can be used to inform what types of artificial intelligence and machine learning algorithms to use. For example, the data types used have a large influence. For this reason, Inkling contains rich native data types in addition to the basic data types. If the architect sees, for example, that an image is being used (or higher-dimensional representations), a convolutional deep learning neural network architecture may be appropriate. If the architect sees data that is temporal in nature (for example audio data, or sequence data), then a recursive deep learning neural network architecture like an LSTM network may be more appropriate (this is not currently implemented). The collection of heuristics is generated by data science and machine learning / AI experts who work on the architect codebase, and who attempt to capture the heuristics that they themselves use in practice.
Model Description Language
The system internally as part of the compilation process produces an intermediary representation of a learning model using our Model Description Language. The MDL provides a coarse-level description of a model that is lated used to instantiate in a particular framework (currently Tensorflow). When generating a new model to solve a given inkling program, the architect generates proposed MDL descriptors, which are then instantiated as needed.
Meta learning is an advanced technique used by the architect, and at this time it is not fully implemented yet. It is, as the name implies, learning about learning. This means, as the architect generates candidate algorithm choices and topologies for training, it records this data along with the signature of the model and the resultant system performance. This data set is then used in its own learning system (a portion of the architect is itself written in Inkling). Thus the architect, by virtue of proposing, exploring, and optimizing learning models, can observe what works and what doesn’t, and use that to learn what models it should try in the future when it sees similar signatures.
The instructor component is responsible for carrying out the training plan codified in the pedagogy. It reads the curriculum and lesson plan specified in the Inkling program, and directs the training by coordinating the associated reconfigurations of the Learner and data source(s) to accommodate. While some operations can take place in a traditional, batch oriented fashion, the system is designed to work in an interactive streaming fashion wherein the system being trained is presented with data or an environment, asked to compute its output or action, has its performance assessed, and is then asked to learn accordingly.
In this section, we outline techniques used by the instructor.
The Execution Plan
When starting a training operation, the instructor first generates an execution plan. It uses this ordering when teaching the concepts, and for each concept which lessons it intends to teach in what order.
Statistical Distribution Inference
In addition to looking at the mental model, the Instructor also considers the pedagogy provided in the Inkling code. It will, for example, look at the statistical distribution of any data sets being used; in the case of simulators, it can ask the simulator to generate substantial amounts of data so as to determine the statistics of data that will be used during training. These distribution properties can further inform the heuristics used.
The learner component is responsible for carrying out the actual execution of the low level, underlying artificial intelligence algorithms. In training mode, it instantiates a system conforming to what was proposed by the architect, interfaces with the instructor to set the parameters of the learning algorithm, and assess performance. The learner is then responsible for the actual execution of the learning algorithm. In deployed mode, it will instantiate an instance of the already trained system, and execute its computation when called for.
After an algorithm is trained, it is hosted in a ‘prediction mode’. This mode holds a neural network for use as an HTTP API endpoint. The programmer can then send input data to the predictor and get back a prediction. This module is intended to be lightweight and used as the final endpoint for general use.