trAIn

• 

  trAIn input data & post run logging

• 

  trAIn thumbnail

Inspiration

For months, I have been conducting research regarding the development of artificial intelligence from reasoning-based and expert system into large language models, deep neural networks, etc.

Among this research, included breaking down the inner workings of training, understanding how information passes through a neural network to produce an output, how algorithms are chosen and stacked to sufficiently codify data, and the emerging directions of AI in the form of both algorithmic development and sector.

From this research, I pulled out two main points: historically, the race to AI -- and much computing technology in general -- has been badly handicapped by infrastructure needs (just because the algorithm works doesn't mean the infrastructure can run it) and as AI develops, the black box that emerges is becoming more of a standard expectation rather than a byproduct that's being worked towards resolving.

My response is to demystify the internal workings of AI by building on the previous AI development methods while simultaneously lowering the bar of entry down out of understanding of syntax into presentation of declarative sentences.

What it does

trAIn, at its base, is a model trainer. It is built through a series of "architectures" and "suites" (smaller programs that perform manipulation on the knowledge base according to performance during testing) that are called in sequence both implicitly and conditionally.

1. A trained data set (plain-English sentences with truth values) are passed into the pre-processor.
2. The pre-processor completes the task of transforming the sentences into proper syntax and the calls the testing suite.
3. The testing suite takes in the processed labelled data and the knowledge base and begins testing the knowledge base against the labelled data until an anomaly is flagged. The testing architecture calls on the training architecture, passing the location of the anomaly for it to be analyzed and corrected.
4. Upon being called, the training architecture spins up an ephemeral knowledge base to work in. Any necessary changed that need to be made across the knowledge base are made in order to align to the labelled data.
5. Once corrected, the validation architecture is called. This step performs the same action as the testing suite but sits between the knowledge base and the ephemeral knowledge base. If all is corrected, the ephemeral knowledge base is then treated as the final source of truth and overwrites the knowledge base. If another anomaly is flagged, the training architecture is called again.

The training and validation architecture work in a looping state until no failures are found, then the model is treated as properly trained and complete.

How we built it

trAIn is built using Java and Python and related bidirectional communicators between those and the Prolog-based knowledge base.

The Preprocessor, NLP Suite, and Trainer were built in Java, with the Trainer also utilizing the Java-Prolog API (JPL API). The Testing Architecture and Validation Architecture were built using Python.

Challenges we ran into

• Setting up in general. The JPL API needed to be imported through a more complex system than expected, but was resolved.
• Querying the knowledge base. For trAIn to work, we must assume that there will be cases in which certain words are undefined and will throw an error. Handling those errors properly so that the system did not crash but instead pushed through the update the knowledge base was a significant blocker.
• Multi-language codebase. Since the codebase was not written in a universal language, to create a pipe that flowed all the way through, subprocess calling was used to point to the next location in the piping.

Accomplishments that we're proud of

I have theorized about how a system like this could work and could have worked for a while, so bringing even a portion of it into reality is something for me to be proud of.

What we learned

We learned how to architect out complex systems with little to no foundation to start with.

What's next for trAIn

• Ideally, setting up containerization. The necessary dependencies make it so that trAIn is difficult to set up to run. Although it is resource-light and the act of using it is very simple, set-up is complex and could be frustrating
• In-suite data-labelling. As of now, any labelled data placed under the data folder as a csv named data can train the model. In another iteration, we would add a front-end that allows for labelling the data and writing out the csv directly in the product without needing to export from a table-making software then placing in the project file structure

Built With

• java
• jpl
• prolog
• python