When the base path is too restrictive, the virtual service will not accept the incoming request at all. This usually results in a connection exception type message (as if no endpoint is found).
The SI Not Found Response you describe above occurs when there is no match in the VSI for the given incoming request. This means the base path test passed and the VSM is in the VS Image Selection Step.
Generally speaking, SI Not Found responses relate to:
a) an issue where the incoming operation name does not match an operation in the VSI or
b) when the arguments on the incoming request do not match the argument signature of one of the transactions in the VSI
c) Match Script errors / issues
Assuming the request went to the correct VSI, analyze a) & b), above, first. Review the lisatmp_x_x_x directory and locate your Virtual Service name. (e.g., VS_<yourService>.log). Analyze the log file content. Compare the incoming arguments to the signature(s) in the VSI -- look for a missing argument, misspelled argument name, cAsE Sensitivity in the argument names, etc.:
yyyy-MM-dd HH:mm:ss ... [service [VS_<yourService>_Run]/1] INFO - Inbound Request {"id":0,"operation":"POST /some/basePath","arguments":{"Arg1":"Val1","Arg2":"Val2","Arg3":"Val3"...}}
Look a the vse_matches.log at about the same timestamp and you should see the Responding From information for the transaction. I believe the incoming request also prints here when an SI Not Found is used.