Attention allocation within OpenCog weights pieces of knowledge relative to one another, based on what has been important to the system in the past and what is currently important. Attention allocation has several purposes:
- To guide the process of working out what knowledge should be stored in memory, what should be stored locally on disk, and what can be stored distributed on other machines.
- To guide the forgetting process. Deleting knowledge that is deemed to not be use any more (or that has been integrated into system in other ways, e.g. raw perceptual data).
- To guide reasoning carried out by PLN. During the inference process, the combinatorial explosion of potential inference paths become a bane to effective and efficient reasoning. By providing an ordering of which paths should be used first, and potentially also providing a cutoff (knowledge with too low an importance is ignored) inference should become more tractable.
Currently Attention allocation is implemented for keeping track of the importance of atoms. The overall design of OpenCog calls for keeping track of MindAgent importance as well. MindAgents confer attention to the atoms they use, and are then rewarded in importance funds when they achieve system goals. MindAgents can currently store attention, but the mechanism for rewarding them for fulfilling system goals is not yet implemented (in part because the goal system is not yet implemented).
- HebbianLinks - indicate which atoms are important at the same time.
- ImportanceUpdatingAgent - pays "wages" and collects "rent" from atoms in the form of Short term importance (STI) and Long term importance (LTI).
- ImportanceDiffusionAgent - spreads STI along HebbianLinks.
- ImportanceSpreadingAgent - alternative way to spread STI along HebbianLinks.
- ForgettingAgent - "forgets" atoms with low LTI.
- HebbianLinkUpdatingAgent - updates the weights of HebbianLinks based on what is in the Attentional focus of the OpenCog instance at the time it's run.
- AttentionValues - Each atom has an AttentionValue to record it's STI and LTI.
This sections presents how the flow of attention allocation works.
- Rewarding "useful" atoms:
- Atoms are given stimulus by a MindAgent if they've been useful in achieving the MindAgent's goals.
- This stimulus is then converted into Short and Long Term Importance, by the ImportanceUpdatingAgent.
- STI is spread between atoms along HebbianLinks, either by the ImportanceDiffusionAgent or the ImportanceSpreadingAgent.
- The HebbianLinkUpdatingAgent updates the HebbianLink truth values, based on whether linked atoms are in the Attentional Focus or not.
- The ForgettingAgent removes either atoms that are below a threshold LTI, or above it.
Specification for future work
ECAN Parameter Tuning Workbench
To facilitate independent ECAN parameter tuning, we should set up an ECAN Parameter Tuning workbench. This workbench should consist of a ECAN Parameter Tuning agent whose only goal is to provide known time-varying stimuli to sets of Atoms. For example, we could begin with two sets of Atoms, A and B. Set A Atoms could be initialized with mean importance mu_A and standard deviation sigma_A and set B Atoms similarly initialized with mean importance mu_B and standard deviation sigma_B. As time progresses, the ECAN parameter tuning agent should begin to change the stimuli provided to these two sets of Atoms.
For example, suppose initially mu_A >> mu_B but as time progresses these mean values change so that eventually mu_B >> mu_A. We would expect that initially many set A Atoms and few set B Atoms would appear in the attentional focus, but that as time moves forward, some set A atoms begin to get replaced by atoms from set B. To make things simple we should begin with two distinct "bands" of atoms by setting, for example, mu_A-2*sigma_A > mu_b+2*sigma_B, so that initially there is little overlap between the two sets of Atoms. We also need to set the focus boundary and the time-varying stimuli in such a manner that we should know the desired behavior of the Atoms and can then vary the parameters until the desired behavior is achieved.
By creating an ECAN Parameter Tuning workbench we will obviously still need to tune the parameters again once ECAN begins interacting with other agents. The hope is that the experiments carried out within the workbench will provide a baseline from which to better explore the parameter space.
ECAN Simplification Redesign Spring 2015
As part of the ECAN simplification process we should update the updating equations using these New ECAN Equations
MindAgent specific stimulus
The conversion from stimulus (the quantity that MindAgents reward useful atoms with) should be converted to short term importance (STI) after each MindAgent runs.
This change of when conversion occurs is because the amount of STI to reward per unit of stimulus is dependent on the amount of STI the MindAgent has to distribute. This prevents a MindAgent that isn't particular effective (in achieving system goals) from upping the importance of the atoms it uses - since they are not important in the overall OpenCog instance.
At the moment, stimulus -> STI/LTI is just done by the ImportanceUpdatingAgent (along with collecting rent and taxation when necessary). For the above stim->STI/LTI scheme, it'd probably be better to include it as a separate process.
- Add an AttentionValue and a stimulus map to the MindAgent class.
- Split the ImportanceUpdatingAgent into a RentCollectionAgent and a WageAgent: The WageAgent needs to be called after every other MindAgent has completed it's cycle (assuming the MindAgent has distributed any stimulus or has STI to pay its atoms with.
- move the atom stimulus map from the AtomSpace to a separate map per MindAgent.
- In the MindAgent base class, provide a method rewardAtoms() which calls the WageAgent. This method would also signal to the WageAgent who the caller was so that the correct stimulus map and amount of STI for reward could be worked out.
- It's up to the MindAgent to figure out the appropriate time to reward the atoms it uses. Usually at the end of a run cycle.
- This scheme would prevent us from batching/preprocessing the importance updates -- which would be left as one of the tasks of the WageAgent. Alternatively, we could let the server itself collect the stimulus/importance data from each agent and pass it to the Wage agent.
- Implement HebbianLinkMining - Mines the SystemActivityTable to discover what atoms are synchronously important and create representative HebbianLinks.
- Make it possible for importance to spread beyond a single Hebbian link in a single diffusion of importance. E.g. try implementing a Lévy flight for importance spread (use a Lévy distribution to work out the proportion of importance that gets spread beyong a single link. Note: depending on the density of HebbianLinks, this could be computationally impractical. Also, PLN may be used to do inference on HebbianLinks, which would make this redundant.
- Gradually update rent when AtomSpace funds go out of homeostatic bounds. Use time since last rent change to work out the weighting combining the new value with the old.