I am still learning the AIML ropes and was wondering if and/or how GAC-360K has been incorporated into existing AIML?

Thanks
Matt Hamm

Hey there, Matt!

Take a look at this thread for information about what Dr Wallace has done to the Alice AIML set with MindPixel, and why only 80k of the 360 has been translated. I should also point out that 360,000 AIML categories is usually larger than what most AIML chatbots contain by a factor of 8 or more.

Hope this helps.

Bear in minds that there is LOADS of rubbish in GAC-360K. One example that comes to mind is something like:

Human - How old is the Queen?
Bot - Probably.

Ah OK   So the core 80k was what was deemed “usable” and incorporated into most bots already  

Dave, why is 5000ish categories the norm, and why can’t there be millions  

Thanks Again
Matt

The default ALICE AIML set (minus the GAC-80k) is around 46k categories in size (depending on where you get it), and few botmasters expand upon that by any great amount. Further, depending the platform and AIML interpreter, huge numbers of categories to search through can cause performance problems. Older versions of Program O, for example, choked with chatbots that contained as few as 70k categories. I was able to improve performance recently, but it still slows down with higher category counts.

Good info thanks Dave, what is the most efficient platform out there in your opinion?  Also, what did you do to get the performance boosts?

Matt

A bot called The Professor has over 500K categories and Program AB is quite happy at handling that. It takes about 30 seconds to initially load (converting the AIML to csv files) but after that, it loads in a few seconds and is quick to respond.

Program O handles AIML storage very differently from other interpreters, using a MySQL database to hold them all. The original search query for finding potential AIML matches was extremely inefficient, as was the table structure within the DB itself, so I redesigned the DB table, added some much needed indexes, and worked out a streamlined version of the query that did the actual searching. The Program O dev team is currently working on a new storage/search solution that is closer in design to the algorithms that Program AB uses, but that requires at least one of the team to understand Java, and none of us do, so I’m taking the time to learn the language. Needless to say, it’s a slow process.

As to the “most efficient”, I really don’t know, though if I had to guess I’d say either Program AB or Program Z (Pandorabots). Program O runs a distant third right now (tnough I hope to narrow the gap), and the rest are far behind that.