It is recommended that you keep these rule classes in separate rule sets:
Keep the data rule classes for your custom entities and evidence types in a separate rule set to maximize their re-use across different products.
Keep the rule classes for your eligibility/entitlement calculations in a separate rule set so that display-only changes to rules do not require re-testing of core eligibility/entitlement implementations.
Keep the rule classes for your key decision factors in a separate rule set so that they can be maintained independently of your eligibility/entitlement rule classes.
Keep the rule classes for your decision details in a separate rule set so that they can be maintained independently of your eligibility/entitlement rule classes.
As you identify calculator rule classes which are common between your eligibility/entitlement, key decision factor and/or decision detail rule classes, you can consider placing such rule classes in "common" rule sets.
While it is important to adhere to the recommended structure above by the time your product's implementation is complete, you do not have to strictly adhere to it in the early days of your product's development cycle.
You can refactor your rule sets later to match this structure, although such a refactoring task will become more complex the longer it is put off. In any case, to refactor freely you will need to have built up a good bank of unit tests for the behavior of your rule classes.