CSE Blog

How does a Cognitive Systems Engineer see Technology, Toys, and Tools?

Sitting on my desk is a cool little device that started this discussion the other day.   It’s essentially a small, compiled neural net, wrapped in a cool plastic ‘eggshell’ that plays 20 Questions so well that users are ‘freaked out’ like it’s possessed.  The discussion immediately turned to: “if it can do *that*, we can use it to solve <real world user need 1> and <need 2> etc.!”  This is exactly the kind of thinking you’d like a tech savvy developer to experiment with; it’s also good when Cognitive Systems Engineers do it.  The discussion came full circle back to “How do you know what the real technology is, what this little device is, and how it represents a capability to do some ‘heavy lifting’ in a deployed system.”

A little homework on the internet revealed that the little ‘eggshell’ had the advantage of a massive training set for its neural net based big brother, played on the internet by a huge number of people.  Given the rules of 20 questions (Pick an OBJECT…Is it Animal, Vegetable, or Mineral?), this massive ‘honing’ of the taxonomy (folksonomy to the purists) results in a remarkably ‘prescient’ agent for playing (and winning) the game.  This is the underlying technology that makes it tick.  Further exploration gets interesting, and a dichotomy quickly appears:  a) this clearly proves that AI can outperform a human in virtually every task or b) for categorization type tasks, with adequate training, this class of AI technique can do a remarkably good job (with a known empirically determined error rate).  When caught up in the moment, you drift toward a); when considered in the light of day, b) makes you a better system developer.

The siren song comes from the technology being relatively invisible (exhibiting virtually no Observability in a Cognitive Systems Engineering sense), while being packaged in a compelling, emotionally appealing ‘toy’.  During the discussion we came to characterize such toys as “things of small, controlled scale and scope”.  As the discussion continued on and off for a few days, the distinction between toy and tool became a bit clearer.  The scope limitation of the ‘toy’ that was essential to making it practical to implement and to make its performance ‘feel’ fast and accurate was exactly what made it a toy versus a tool.  For example, it is impractical to expect the 20Q Toy to expand into the kind of tool needed to sort all of the “objects” referenced within the network traffic of a large corporation.

Unfortunately, the technology provider will blithely make such claims, point to the toy as evidence (often painted in the colors of the real world ‘tool’) and declare that “our technology will solve your problem.”  A Cognitive Systems Engineer has to understand that underlying technology, understanding the affordances needed by a user in the real world, to do real cognitive work in the wild and look for the toys that really can grow to be tools.

//postscript//  Sometimes, just sometimes, you can see past the Potemkin Village of the technologist’s toys.  During an ARDA technical meeting, participants were presenting their kick-off thoughts…we began keeping score:  12 of the 13 vendors opened their presentations with “our technology solves your problem…Task 1 of our research is to understand your problem…”  Note the oxymoron?  Unfortunately we were to the only ones in the room that did…we were the 1 of 13.