HTM anomaly detection model too large for streaming analysis

Engineering NuPIC
,
7

Hi @rvsandeep,

Here is what I would try to reduce the size of the model:

  • Use the code in $NAB/nab/detectors/numenta/numenta_detector.py as a starting point for your anomaly detector. Use NAB to test the impact of any parameter changes.
  • Try changing columnCount from 2048 down to 1536 or 1024. Note that you have to change this in both the SP and TM (they should always be the same).
  • Try changing the number of active columns from 40 down to 30 or 20. As you change this, you will want to also reduce activationThreshold, minThreshold, and newSynapseCount.
  • Try changing cellsPerColumn from 32 down to 16, 12, or 8.

In addition, you will find that the model size grows slowly over time. This is because the HTM always adds new synapses. To counteract this, I’ve speculated for a while that you might be able to randomly downsample the number of synapses once you have trained on a few thousand records. Here’s what I would try first: on each iteration keep track of the number of synapses you add (max is newSynapseCount * number of active columns on any given iteration). After the compute step, randomly choose that many synapses throughout the network, and delete them. If a segment becomes empty, delete the whole segment. You might need to add some methods in the class to support this operation.

With all of the above, test with the full NAB benchmark to ensure the changes are not too disruptive to performance. This is slow, but the best quantitative way we know of to ensure decent anomaly detection accuracy. You’ll want to make sure you understand our anomaly detection paper, NAB codebase, and the datasets used in NAB. I think NAB is a valuable tool in debugging.

I have not tried the above, so these are my best guesses. I would be very curious to see what you find out!! Of course, doing the above will speed up the serialization process as well.

There are also many code optimization strategies that have not been implemented and can work (e.g. using smaller bitsize floating point instead of 64 bit, or going down to 8 bit integer math), but that would be more work. (A quick version of this might be to just change the Proto bit sizes. This will lead to a situation where you won’t get identical results after deserialization, but it might be “good enough”. I don’t know enough about Proto to know whether this will really work.)

5 Likes