Probabilistic Semantics for Inter-Agent Communication in SingularityNET
Reader beware: This is a set of rough notes and not a formal description of functionality. I may edit this post soon after posting, based on feedback from other SingularityNET developers. But a lot of people have been asking about these aspects of SingularityNET lately, so I wanted to share my current thinking more elaborately than has been done so far. The stuff written here should be taken at the level of “stuff scribbled at the whiteboard during an informal tech meeting.” For example the syntax and particulars used here is not fully consistent with the current SingularityNET prototype — but it’s conceptually consistent…
At the most basic level, SingularityNET is a quite generic framework supporting collaboration between multiple AI Agents carrying out their own intelligent processes. However, the effective practical functioning of such a network, requires some specific tools for inter-Agent communication and cross-Agent knowledge representation.
The simplest form this takes is what we’re called an “ontology” in SingularityNET documentation. So for example a request for the service of labeling pictures in images might conceptually take the form
O = SNet-Foundation-Ontology-1.3
S = interpret-term(O,”stream”)
S.payload-type = interpret-term(O,”images”)
S.payload-rate-limit = interpret-term(O, “4ms”)
F = interpret-term(O,”human face”)
P = interpret-term(O, “identify and label”)
T = eval(P,S,F)
Here, communication between a requestor and a provider is enabled because of use of a common ontology, here labeled SNet-Foundation-Ontology-1.3.
The simplest aspect of an ontology, in this context, is simply the provision of a common set of terms, e.g. “human face”, “image”, “identify and label.” These terms will have hierarchical relationships and sometimes other logical interrelationships, allowing matching between requests and offers to be done using type-theoretic logical inference algorithms.
Another important aspect of SingularityNET ontologies will be the representation of uncertainty. For instance, what if an Agent desires recognition of objects in images, and has an 80% confidence that the percentage of these objects that are human faces will lie between 40% and 70%? What if an Agent has 5 AGI Tokens to pay for a certain data analysis task, and wants to have a 90% chance of getting an accuracy of 70% or higher from the task’s results? What if an Agent is looking for logical propositions that hold true of a certain dataset, or of entities in a certain domain (e.g. people, or American people), and has the requirement that 90% of the propositions it is given should hold true 70% of the time in the dataset/domain in question?
One could say that these particular requirements should be established on an individual Agent-to-Agent basis. However, if a certain language feature is likely to be used sufficiently often for inter-Agent communication, it may make sense to embed this language as a generic feature in the provided inter-Agent communication tools (which in a SingularityNET context, largely means in the ontologies provided).
In the above simple example, this could lead to things like
O = SNet-Foundation-Ontology-1.3
S = interpret-term(O,”stream”)
S.payload-type = interpret-term(O,”images”)
S.payload-rate-limit = interpret-term(O, “4ms”)
Ob = interpret-term(O,”object”)
F = interpret-term(O , “human face”)
assignProbability(F, .7)
P = interpret-term(O, “identify and label”)
A = interpret-term(O, “accuracy”)
assignProbability(A(P), ((.7,1), .9))
T = eval(P,S,Ob &F)
Here the construct
((.7,1), .9)
is an imprecise probability, indicating a .9 chance of a probability lying in the range (.7,1). And the implicit assumption in the rough notation used, is that when an entity created is assigned a probability using assignProbability, this probability is passed along to the entity when it’s used as an argument to “eval.”
The notation I’ve used here is a mess and is not being proposed for actual use, it’s purely intended to get across the idea. In the SingularityNET GitHub you can see first steps toward an elegant python API aimed at enabling this sort of reqeust construction in a pretty and usable way. There will also be APIs in C++, C, Scheme and possibly Haskell.
