Let's look at the assumptions that this question suggests:
1. Having no documentation makes it risky to refactor
2. Having documentation makes it less risky to refactor
With either assumption, I would say it depends on what you consider as "documentation".
Textual documentation in the form of code comments or, God forbid,
Word documents, is unreliable, IMO. There's a good possibility that these kinds of documentation are either inconsistent or incomplete. At worst, they are obsolete and altogether wrong. I would argue that documentation that does not accurately reflect the current state of the code is worse than having no documentation at all and it poses a greater risk to refactoring. At least when you have no documentation, you are forced to turn to the code to see what's actually happening. Documentation that is not accurate can lead you to doing things you really shouldn't be doing.
On the other hand, if you agree with
Jack Reeves about code being design, then you will consider well-written code and tests as themselves being detailed documentation. This kind of documentation, IMO, is a more superior kind of documentation. Tests should be written so that they document details of the design. Having well-written tests as detailed documentation is a great help in refactoring. If you have no tests, then you have to turn to the code. Code itself should be self-documenting. If code is unclear and isn't self-documenting, then the risks of refactoring are higher.
How to measure the risk is another story. Why do you feel you have to measure that risk? I would say if I had to have one, my scale would be very course-grained, like "a lot", "some", "very little", and "none" based on the kind of documentation you have, as I mentioned.