Show Posts
1
General Discussion / new AI from scratch
« on: January 15, 2006, 09:20:35 am »
Hello
Here are some ideas about building an AI.
Probably most of it has already been realized in some way , but for me it looks pretty interesting.
If you get the courage to read all, what do you think of ?
'this is the first step to build an AI, that should not emulate a human brain, but
'be some kind of curious mind, able to ask question, learn thing,
'make statement or inference and build a personality by himself.
'The AI should recognize the value of a conversation by the quantity of new data discovered,
'the percentage of contradiction discovered, number of object covered.
'The AI should be logic, but tolerant and be able to use fuzzy concept or accept
'value (like EVERYWHERE, SOMETIME) and accept to make choice based on probability.
'The AI should not look for logic in what is said. we want it free to discuss
'about lies or false opinion. But we want some wisdom in it, so it does not
'accept anything for being true or false, but can accept something being
'a different point of view and respecting it.
'=======================================================================
'The first approach is close from LISP, in a manner we build lists.
'first db is object description for short memory.
'this mean, we will build each object during conversation to grab data from
'what said by the user. to help conversation, some data (the obvious ones) can be taken from
'the 2nd database (same structure), but usually the goal would be to generate questions and
'have specific answers.
'for example it is obvious that a car has 4 wheel(most of time) and an engine.
'This should be found in the 2nd DB, called Knowledge and containing only
'proven(usual) facts or cultural information and being READ-ONLY DB.
'The knowledge DB will also contain the point to clarify.
'More important, the knwledge DB will contain for each object all the properties
'that it would be nice to know, indicated by a question mark.(kind of template for creating
'child objects from generic objects).
'For example the object NA(name)=car will have the propertie CO (color)=?
'indicating that color is something that could be asked for such object.
'We could build some code for expressing urgency level like CO=?! meaning
'that this is possibly something higly important to know.
'For the object "Jim's car" we would like to know the color, the maker etc...
'The knowledge DB cannot be modified by regular conversation (must be in training mode).
'but if a child object (john's car) has new properties created that were not in the
'generic template, we could have a log that warns the programmer that such object
'likely needs to be updated. On long term, this could be automatic.
'Such modification could be tagged (L for learned) for eventual management.
'This should allow to manage contradiction like john saying sky is red.
'the knowledge DB will indicate the sky is blue (on earth), so we can create
'an new object is short memory called NA=john'sky OW=John and set CO=red and GG=sky
'In further discussion with John, we will know that John think that the sky is red,
'contrary to the general opinion.
'(or the AI could infer that John is probably not living on earth and ask)
'This is far from PROLOG, where everything is an attempt to verify/prove things
'as true or false. Here we do not really care, we just try to build a meaning from
'things.
'Structure:
'we got 3 fields. object ID (number incremented), value definition and value.
'each time we find a new object, we start to define it.
'for example a new object will receive immediately at least one record.
'12934 , NA, john
'here object 12934 has NAME=John
'the list of properties is defined, but can be expanded as needed
'Properties should answer to simple questions like WHO, WHEN, WHAT, HOW
'WHO or WHAT
'The goal being to be able to get useful info and create links between object.
'Each propertie will have a table with standard questions.
'for example NA can trigger "What is your name ?" or "How did you call it ?"
'or "Has it a name ?" and so on...
'This is slightly different than AIML, because the AI will be able to choose what
'to ask and how to ask, without having to write script. We still can use AIML, but
'main of it should be generated by the AI itself, not by the programmer.
'the choice factor would be something like "what answer is currently most important or urgent to have to continue dialog".
'this can be easily based on statistic.
'this can make use of pre-recorded TTS more efficient, since we do not need to
'convert standard question to .ogg on the fly.
'In the same time we need a tool that can log the way the AI uses links between
'object to find is something new must be created (new property or new keyword).
'Ideally the develloper interface would include a box to show the objects created,
'the number of positive hit (request fullfiled) to other object
', negative hit (object or information not found) and the number of direct and indirect
'link created.
'===========
'NA , FN, LN, MO, FA, SI, BR, SO, DA, OW
'NA=name of object (usually the word used in conversation, but we can create
'object with special names (codes, acronyms) to cover special needs.
'FN,LN firstname, lastname obviously for people only
'MO=mother, can be a simple name, a pointer to another object, or a key word
'indicating special propertie (for example NONE)
'same for FA(father), SI(sister), BR(brother),SO(son), DA(daugther)
'OW=owner. usually point to another object.
'We do not need more since we can reconstruct the whole family geology from
'these info. We could even simplify using only PA (parent) and CH(child) and
'determine parent function from sex propertie of each member, but this would lead
'to more calculation without benefit.
'GG=genre. Here we probably start our first list of keyword.
'I can propose HUMAN, ANIMAL, MACHINE, OBJECT, EVENT, OPINION ,FEELING, LAW, CONCEPT.
'GE=subtype genre (like dog), usually a pointer to another object. (object dog from the knowledge DB)
'=====================
'WHEN
'=====
'some keyword will be needed NEVER, ALWAYS, SOMETIME, EVERYTIME but basically time
'should be value HH:MM or DD/MM/YYYY or both.
'When possible, relative indicators (like tomorrow or after Xmas)must be converted to "hard" value.
'Object could have few values like
'BI= birthdate (age means nothing, so it will calculated as birth date).
'This apply to every object (start of an event for example)
'DU =duration
'HOW
'======
'this should describe specifically on object, or be in the generic definition of object
'for example:
'NA = Lily
'GG = ANIMAL
'GE = cow
'OW = john987
'usually cow have an averag size that can be described under object=cow.
'in this case, if we want to express that Lily is a big cow, we will add
'SZ=BIG
'This will allow to define the object "Lily" by its own properties with eventual fallback to the
'properties of the generic object "cow".
'possibly, the generic object does not contains the requested info, or only a pointer to another
'object (like SZ of cow is specified as same as "horse", or smaller than "elephant").
'once one size is known, every relative value will be recalculated to prevent having to chase for a value
'from object to object
'ST=status, with our second list of keyword.
'for living creatures DEAD,ALIVE,BROKEN, ASLEEP
'for object GAZ, LIQUID, SOLID, BROKEN
'for machine, ON, OFF, BROKEN
'for event, idea, feeling, GOOD, BAD
??
'for law and concept?
'WHERE
'=========
'LO=location, can be anything like Africa, New-York, map coordinates or keyword
'like NOWHERE (somewhere is implicite if LO not specified), EVERYWHERE, or pointer to
'another object (to express the concept WITH ME).
'MISC
'=====
'there will be a set of physical properties like
'LE(length) WI (width), TP(temperature) WT (weight)
'SH (shape) , HU (humidity) SK (skin with values like SOFT, HARD, ROUGH etc.)
'MO (mood), VA(value)
End Sub
Here are some ideas about building an AI.
Probably most of it has already been realized in some way , but for me it looks pretty interesting.
If you get the courage to read all, what do you think of ?
'this is the first step to build an AI, that should not emulate a human brain, but
'be some kind of curious mind, able to ask question, learn thing,
'make statement or inference and build a personality by himself.
'The AI should recognize the value of a conversation by the quantity of new data discovered,
'the percentage of contradiction discovered, number of object covered.
'The AI should be logic, but tolerant and be able to use fuzzy concept or accept
'value (like EVERYWHERE, SOMETIME) and accept to make choice based on probability.
'The AI should not look for logic in what is said. we want it free to discuss
'about lies or false opinion. But we want some wisdom in it, so it does not
'accept anything for being true or false, but can accept something being
'a different point of view and respecting it.
'=======================================================================
'The first approach is close from LISP, in a manner we build lists.
'first db is object description for short memory.
'this mean, we will build each object during conversation to grab data from
'what said by the user. to help conversation, some data (the obvious ones) can be taken from
'the 2nd database (same structure), but usually the goal would be to generate questions and
'have specific answers.
'for example it is obvious that a car has 4 wheel(most of time) and an engine.
'This should be found in the 2nd DB, called Knowledge and containing only
'proven(usual) facts or cultural information and being READ-ONLY DB.
'The knowledge DB will also contain the point to clarify.
'More important, the knwledge DB will contain for each object all the properties
'that it would be nice to know, indicated by a question mark.(kind of template for creating
'child objects from generic objects).
'For example the object NA(name)=car will have the propertie CO (color)=?
'indicating that color is something that could be asked for such object.
'We could build some code for expressing urgency level like CO=?! meaning
'that this is possibly something higly important to know.
'For the object "Jim's car" we would like to know the color, the maker etc...
'The knowledge DB cannot be modified by regular conversation (must be in training mode).
'but if a child object (john's car) has new properties created that were not in the
'generic template, we could have a log that warns the programmer that such object
'likely needs to be updated. On long term, this could be automatic.
'Such modification could be tagged (L for learned) for eventual management.
'This should allow to manage contradiction like john saying sky is red.
'the knowledge DB will indicate the sky is blue (on earth), so we can create
'an new object is short memory called NA=john'sky OW=John and set CO=red and GG=sky
'In further discussion with John, we will know that John think that the sky is red,
'contrary to the general opinion.
'(or the AI could infer that John is probably not living on earth and ask)
'This is far from PROLOG, where everything is an attempt to verify/prove things
'as true or false. Here we do not really care, we just try to build a meaning from
'things.
'Structure:
'we got 3 fields. object ID (number incremented), value definition and value.
'each time we find a new object, we start to define it.
'for example a new object will receive immediately at least one record.
'12934 , NA, john
'here object 12934 has NAME=John
'the list of properties is defined, but can be expanded as needed
'Properties should answer to simple questions like WHO, WHEN, WHAT, HOW
'WHO or WHAT
'The goal being to be able to get useful info and create links between object.
'Each propertie will have a table with standard questions.
'for example NA can trigger "What is your name ?" or "How did you call it ?"
'or "Has it a name ?" and so on...
'This is slightly different than AIML, because the AI will be able to choose what
'to ask and how to ask, without having to write script. We still can use AIML, but
'main of it should be generated by the AI itself, not by the programmer.
'the choice factor would be something like "what answer is currently most important or urgent to have to continue dialog".
'this can be easily based on statistic.
'this can make use of pre-recorded TTS more efficient, since we do not need to
'convert standard question to .ogg on the fly.
'In the same time we need a tool that can log the way the AI uses links between
'object to find is something new must be created (new property or new keyword).
'Ideally the develloper interface would include a box to show the objects created,
'the number of positive hit (request fullfiled) to other object
', negative hit (object or information not found) and the number of direct and indirect
'link created.
'===========
'NA , FN, LN, MO, FA, SI, BR, SO, DA, OW
'NA=name of object (usually the word used in conversation, but we can create
'object with special names (codes, acronyms) to cover special needs.
'FN,LN firstname, lastname obviously for people only
'MO=mother, can be a simple name, a pointer to another object, or a key word
'indicating special propertie (for example NONE)
'same for FA(father), SI(sister), BR(brother),SO(son), DA(daugther)
'OW=owner. usually point to another object.
'We do not need more since we can reconstruct the whole family geology from
'these info. We could even simplify using only PA (parent) and CH(child) and
'determine parent function from sex propertie of each member, but this would lead
'to more calculation without benefit.
'GG=genre. Here we probably start our first list of keyword.
'I can propose HUMAN, ANIMAL, MACHINE, OBJECT, EVENT, OPINION ,FEELING, LAW, CONCEPT.
'GE=subtype genre (like dog), usually a pointer to another object. (object dog from the knowledge DB)
'=====================
'WHEN
'=====
'some keyword will be needed NEVER, ALWAYS, SOMETIME, EVERYTIME but basically time
'should be value HH:MM or DD/MM/YYYY or both.
'When possible, relative indicators (like tomorrow or after Xmas)must be converted to "hard" value.
'Object could have few values like
'BI= birthdate (age means nothing, so it will calculated as birth date).
'This apply to every object (start of an event for example)
'DU =duration
'HOW
'======
'this should describe specifically on object, or be in the generic definition of object
'for example:
'NA = Lily
'GG = ANIMAL
'GE = cow
'OW = john987
'usually cow have an averag size that can be described under object=cow.
'in this case, if we want to express that Lily is a big cow, we will add
'SZ=BIG
'This will allow to define the object "Lily" by its own properties with eventual fallback to the
'properties of the generic object "cow".
'possibly, the generic object does not contains the requested info, or only a pointer to another
'object (like SZ of cow is specified as same as "horse", or smaller than "elephant").
'once one size is known, every relative value will be recalculated to prevent having to chase for a value
'from object to object
'ST=status, with our second list of keyword.
'for living creatures DEAD,ALIVE,BROKEN, ASLEEP
'for object GAZ, LIQUID, SOLID, BROKEN
'for machine, ON, OFF, BROKEN
'for event, idea, feeling, GOOD, BAD
??'for law and concept
?'WHERE
'=========
'LO=location, can be anything like Africa, New-York, map coordinates or keyword
'like NOWHERE (somewhere is implicite if LO not specified), EVERYWHERE, or pointer to
'another object (to express the concept WITH ME).
'MISC
'=====
'there will be a set of physical properties like
'LE(length) WI (width), TP(temperature) WT (weight)
'SH (shape) , HU (humidity) SK (skin with values like SOFT, HARD, ROUGH etc.)
'MO (mood), VA(value)
End Sub