My advice is to read those bugs and give them a good old think. If you can't figure out a potential cause, forget about them for now.
QA should document every issue they find, even if they have no idea how it happened. It's QA's job to try and reproduce issues, but realistically this won't always be possible. Sometimes it doesn't have anything to do with what they did in the last 10 minutes. Something got into an invalid state a day ago, and it just became apparent because of one of the last 10 steps.
With these "1 in 1000" bugs, QA should try to reproduce them for a bit. If they don't have success, they should document the bug, then try a little more.
The reason why they should get the bug entered fairly early on is that the programmer knows the code a lot better than QA, and might immediately know the problem. It could be the code they refactored. It could be that function they half implemented then forgot about. They may have no idea, but there's no sense in the tester wasting a few hours trying to reproduce a problem that's obvious to the person who coded it. The tester can always add more details to the bug later.
The bug should include as much info as possible. Whatever the tester can remember about the lead-up to the issue should be written down in painful detail. Any Crash logs, database snapshots, or relevant screenshots should be attached as well.
If the bug is never reproduced, great! It doesn't hurt having it in the database. If the program is released and a user reports a similar bug later, you can compare their experience to what's in the report and look for any similarities.
In my experience, the juiciest bugs aren't found from following test plans. Sometimes you have to let things stew for a few weeks in order to have the moon and stars align that cause a nasty bug. If QA can do some detective work and find some possible causes, give them a pat on the back. But sometimes, who knows what happened?