Mainly just writing out thoughts on what I’m doing and some thoughts on how it relates to AI and some ideas I have in that area.
Current Work
So, it started as a NodeJS-based Rainmeter skin, really. I went down a rabbit-hole of making menus in Rainmeter, hit some walls with making it more dynamic, and then turned to NWJS for transparent windows and the flexibility of all that. Now, I have a menu system with dialogs to add/edit/remove icons, choose colors for the text/borders/background of the menus, and…
That work metastasized into a platform for various AI experiments and coding exercises, as it does. Being able to pop open a window that I can fill with an HTML5 app I create and modify on the fly is a great way to develop when I don’t have a full time schedule to devote to these projects.
Some of the projects that are being tinkered with inside this platform include:
- A type/talk chatbot: I’m intending on bringing in some of the code from Interrogative 3.0 that I’ve talked about a while back into this, leveraging an extensible knowledge graph that allows me to have a privately-siloed chatbot with some of the functionality of the more popular ones out there. Right now, the most annoying issue is that for voice commands, I need to pop up a Chrome window to get speech to text functionality unless I want to send data out to the cloud (I don’t). It’s not “there” yet, so no screenshots to show for it.
- Data visualizations: One way to get data into the above chatbot is to create a tool, much like the one I’d created for the NPC AI– so I’m porting a subset of the code to a Knowledge Editor window. It does some visualizations for the dictionaries I’ve been working on, as well as graph visualizations using Cytoscape.js. I’m working on adding in a more traditional data entry-like tab to the window for adding information.
- More Graph Stuff: Well, of course! But I’ll get into that in another section…
Graphs and AI Thoughts and Direction
I naturally gravitated towards graphs while evolving the “Interrogative 3.0” NPC AI system I was working on a few years back, and then I fell down that rabbit hole. I’m still digging, and have no real intention of climbing out. But as I learned about Deep Learning as well, seeing that it’s all just computational graphs, I realized that, as with regular graphs, you can really just mash these things up.
Look at it like this: A system with a knowledge graph fed by a variety of algorithms. Deep Learning or HTM classifiers among them, feeding into labels that are themselves part of a higher level graph, which are iterated over by direct queries or tree traversals either looking to return data, or to connect it.
Example: What kind of cat is that? Well, run the picture through a classifier, get the label, and that will take you immediately to a built-out concept for the cat breed, and then to the generic for the cat. Traversing the ontology to assemble and return the information to an algorithm that will generate human readable text as an answer.
This example requires a number of steps, with a classifier being only one of them. But all of them occur on a graph:
- A classifier algorithm, which hooks right into a set of labels connected to concepts updated from other sources (NLP, etc).
- A knowledge graph, which acts as a store of facts and “memories”.
- Computational graphs as sub-graphs for various functionalities. Some of these would hook into external code, like pointers to functions for iterating over the graph in various ways. Having the graph be able to iterate over itself via the graph seems useful in a game-loop sort of way.
Some of this is hokey right now, I admit. But mostly, it’s not, and it’s really just trying to tie together lighter-weight graph operations like queries with heavier-weight operations like classifiers, but reviving some GOFAI techniques in the process. And why do it like that?
Here’s a thing I noticed while going through Numenta’s YouTube channel’s HTM School playlist: The Sparse Distributed Representations (SDRs) are one-dimensional bit arrays that you can do binary arithmetic against for comparisons, unions, etc- all the Boolean logic your heart desires! It’s nifty, really. It’s also what Cortical.io base their Semantic Folding on- but they’re using HTMs a bit differently.
What they’re doing is building an SDR out of data corpora and indexing the words in bits. Then, if I read the paper right, they group the words spatially in the SDR in a way that if, in a word vector, they’re close, then they’re close in a 2D mapping of the data. In this way, you can do measurements on the distances between words like you do in word vectors, but the SDR representation allows you to compare documents’ using binary arithmetic, and the bits represent semantic information like words and concepts/entities.
You can almost do the same thing with graphs, if you index the nodes so that you can embed them in an SDR like the words and concepts are embedded in the SDRs Cortial.io uses. There’s an added level of complexity if you take relations into account, of course, which means you probably have two SDRs- one for the nodes, and one for the relations and/or relation types (depending on how you want to represent relations). It almost becomes more of a visualization issue at this point. Almost…
A lot remains to mull over with these techniques:
- Data formats for the graph. I’m representing a ton of different things, and because I’m not using a single representation format, like SDRs, then it’s down to doing a database/json like format. Binary is faster, but harder to tweak on the fly, so is not up for consideration yet.
- Visualizations of the graph present problems pretty fast as complexity grows. And it grows very fast, even when you’re just showing a vanilla knowledge graph. Editing and working with such a thing requires various levels of interaction: A text/voice query and answer interface. Editors at both the data-entry (for high-level injection of data), graph (for medium-level creation of function sub-graphs), and procedural (for low-level creation and joining of classifiers, decision trees, and other large structures) levels. The data-entry portion is easy to implement, and the graph portion can borrow heavily from dataflow techniques. Procedural techniques will rely on some Jedi-hand-waving algorithms to glue things together in any sort of automated way.
- Lots of other stuff. Coffee isn’t working right now…
