'How to think', 'What to think'
Separating 'How to Think', from 'What to Think' is one of the core foundations of a Dabnis AI solution. It facilitates many features: a generic core; dynamic flexible operation; reinforced learning; distributed deployment options. All stem from separating the 'how to think' from the 'what to think' components of the AI solution.
How To Think
Rather than being an abstract term, 'how to think' is a determined method of cognitive process. While not a precise, or exact explanation, the following serves as a good description: Regardless of complexity all complex cognitive processes (conscious thought) are sequential by nature. By deconstructing these sequential processes, cognitive primitives can be identified. There are a finite number of primitives that can be assembled as a library. This library of cognitive primitives can be used to assemble other complex cognitive processes.
Why this is important for a Dabnis AI solution? By fine-tuning small LLMs to be experts in the processing of related library cognitive processes and getting those small LLMs to work collectively (orchestrated) we can process more complex cognitive tasks more efficiently via such as increased context attention, reduced context drift etc.
This collection of small LLMs is referred to as 'The Hive'. It is the hive that is controlled and manipulated by what we call the Universal Cognitive Engine (U.C.E.). In reality the U.C.E. is a single compiled binary (excluding model weights) that can be deployed on a single device, or multiple networked devices, realising a distributed system/solution.
The 'how to think', hive, U.C.E. is the fixed constant within the solution.
What to Think
If the U.C.E., 'How to Think' is the fixed component of a solution, then the 'What to Think' is the dynamic variable, custom component within a solution. The 'What to Think' is the variable that is dictated by the AI needs of the business that is the target of the solution.
The 'What to Think' is a structure of one, or many domains and subdomains that represent a clone of the business, or industrial domains that it intends to mimic. This domain structure in limited only by the imagination of the client business.
Domain Structure
- Domain Configuration: Mission statement; Tool use authority, etc.
- Knowledge: Knowledge that is specific to the domain. Optionally this knowledge is ingested into a RAG system at solution start-up and can be composed of many common types of data format: Markdown, csv, PDF, Word docs, JSON, JSONL, pre-defined DB queries etc to name but a few. This content can be muted in real time during solution operation.
- Standard Operating Procedures (SOPs): The 'How to Think' for most business departments are there standard operating procedures. SOPs for a Dabnis solution domain are a custom format of such.
- Standard Transfer Procedures (STPs): Much like SOPs, STPs are rules relating to when to transfer a cognitive process to another domain.
- Semantic Instinct/Reflexes: Binary weights, the output of nural networks that facilitate reinforced learning.
Process Orchestration
There is no central orchestration process. Each domain has full autonomy over how a cognitive task is processed, what tools it should use, if it should consult another domain, or transfer the complete cognitive task to another domain.
Solution Ingress
There are many types of ingres interface to a solution, email monitoring, API monitoring (industrial solutions), monitored DB mutation and drop folders.
Presently in development is voice (STT/TTS), although initial tests suggest that a dedicated device (PC) would be required.
The key technologies behind Dabnis AI are in many ways standard. It's how they are configured as processes, architectures and solutions that makes Dabnis AI what it is.
The reader should understand that some aspects of Dabnis AI operation and function have been restricted for reasons of commercial sensitivity.