I don't think that's a big problem.
There are two obvious things that could be causing that. One is that you're experiencing some mild point deflation. The other is that your team is actually getting faster. (I hope it's the latter!)
Either way, it shouldn't be a big deal. The two main uses of velocity are figuring out how much work to take on in the next iteration, and making rough estimates of delivery dates for larger chunks of work. Neither of those is harmed by a gradually changing velocity. Indeed, if the improved velocity comes from getting better, then your new numbers present a truer picture of the team's capacity.
If the velocity is changing too quickly for comfort, then one response is canonical stories. Go through the last couple months, picking out 3 stories each to represent the point levels you use. Put 'em up on the wall where you do estimations. Then as you estimate, use them as comparison with the story you're dealing with. That should reduce both drift and volatility in your estimates.
You are correct, there is not a formula to convert story points to hours. You can get a pretty lossless conversion of meters to feet, and vice versa, but you can't say a 3 point story will take X hours, so a 5 point story will take Y hours (solve for Y).
HorusKol touched on this next part. Your sprint velocity as a team can help out with the longer term deliverables. Say your team is at 50 points per sprint, and each sprint is 2 weeks. So 50 points per sprint multiplied by 50 weeks in a year (assuming people take 2 weeks off for vacations) then your current team can do a maximum of 2,500 points in 12 months.
So the business comes up to you with 170 points worth of stories and epics. Divide that by the team's historical velocity of 50 points (an average of every sprint so far) and you get 3.4 sprints. Since we are doing an estimate, round that up to 4 sprints: 8 weeks. Two months, basically. I also like to take the last 3-4 sprints and take another estimate. Let's say your team in the last 3 sprints has done 53, 67, and 55 points respectively. That works out to 58-ish points, which at that rate is 2.9 sprints — so basically 3 sprints. Looks like your timeline for those 170 points is looking like 6 to 8 weeks.
Tell the business 2 months. Don't tell them 6-8 weeks, because they will just hear "6 weeks." Don't even tell them 8 weeks, because most months have about 4.5 weeks in them, and when people hear "4 weeks" they instantly think "1 month." Once an estimate hits about 4 weeks, it becomes 1 month. Then just work in months. If you hit a year or more then honestly just don't estimate that work. It's pointless. Too much can change in a year.
I've found this to be a fairly accurate way to convert story points to hours... well time, anyhow.
You'll get a variance in the amount of time it takes individual stories to be completed. Some developers work faster than others. Putting all the story points into a bowl and turning the blender on to work with averages helps alleviate those inconsistencies.
Oh, and don't forget the most important part:
Round up. Always.
Best Answer
Story points are subjective; always. What a '5' means to you may mean something else to another team member. As your team grows and gains more experience after each sprint, you get an understanding of how the rest of your team members view a '5'. Every sprint, you'll get a better understanding, and therefore a better estimate.
There is no need to make sure your scale remains consistent, it will happen naturally.
You could compare it to average tasks from the last sprint. You don't need to utilize that "base-line" story every single time, especially as your team evolves.