| … | … | @@ -1,6 +1,58 @@ |
| 1 | Text processing agent |
| 2 | --------------------- |
| 3 | ***Design goal***: Agent that reads text and responds, by generating text. |
| 4 | |
| 5 | ***Prototype***: Read text files, count word pairs, and generate |
| 6 | high-ranked word-pair streams. The pair-counting agent is in |
| 7 | `pair-agent.scm` and the generator is in `generator.scm`. |
| 8 | |
| 9 | ***Motivation***: Word-pairs stand in for generic complex networks of |
| 10 | occurances in the sensory environment that correlate with agent internal |
| 11 | state. The agent sees and responds to the environment. The generation |
| 12 | stream is a stand-in for generic agent motor control: after seeing and |
| 13 | "thinking", the agent "responds" with "actions" out into the external |
| 14 | environment. |
| 1 | 15 | |
| 2 | 16 | ## Pair counting agent |
| 3 | | Prototyping for a more agential approach. |
| 17 | Prototype proof of concept. Implemented in `pair-agent.scm`. |
| 18 | Counts word-pairs, observed by looking at a text file. The Sensory API |
| 19 | (implemented in `(use-modules (opencog sensory))`) is general enough to |
| 20 | allow arbitrary text sources, including chat. |
| 21 | |
| 22 | The dataflow pipeline is hand-crafted. The sensory API is supposed to |
| 23 | eventually auto-build these pipelines, but that code is not working yet. |
| 24 | |
| 25 | ### Design Notes |
| 26 | Here's the design we want for the pair-counting agent: |
| 27 | |
| 28 | 1) Some source of text strings. This source blocks if there's |
| 29 | nothing to be read; else it returns the next string. The SRFI's |
| 30 | call this a generator. The `OpenLink` provided by `sensory.scm` |
| 31 | provides exactly this, so we're good. |
| 32 | 2) (Optional) Some way to split one source into multiple sources. |
| 33 | Maybe this: |
| 34 | https://wiki.opencog.org/w/PromiseLink#Multiplex_Example |
| 35 | but what happens if the readers don't both read ??? |
| 36 | 3) A Filter that takes above and increments pair counts. |
| 37 | Done. Its non-atomic, but so what. Perhaps we can live with |
| 38 | that, given that sampling is statistical, anyway. |
| 39 | 4) Execution control. There are two choices: |
| 40 | |
| 41 | ***Pull***: infinite loop polls on promise. Source blocks if |
| 42 | no input. |
| 43 | ***Push***: Nothing happens until source triggers; then a cascade |
| 44 | of effects downstream. |
| 45 | - Right now, the general infrastructure supports Pull naturally. |
| 46 | - There aren't any push demos. |
| 47 | - Attention control is easier with Pull. |
| 4 | 48 | |
| 5 | | Some prototype sketches and notes. |
| 6 | | Nothing works here yet. |
| 49 | ### TODO/Open issues |
| 50 | Some unresolved issues. |
| 51 | * Parser wants strings as `Node`s; it would be nice to be able to work |
| 52 | with `StringValue`. |
| 53 | * Need to call `cog-execute!` in a loop, to loop over whole file. Would |
| 54 | be nicer to not have to do this. This is a bug; the `OutputStream` |
| 55 | class does run an inf loop on streams, but that loop fails on things |
| 56 | that have a `Filter` in the middle. |
| 57 | * End-of-file results in a throw from parser. This is a side effect. |
| 58 | The throw should happen from the file-reader, directly. |