Your ground truth method is solid for the benchmark, but you're missing a key variable.
You said "cost and integration are secondary." That's a fantasy. The per-second pricing of one versus the per-seat model of the other will dictate your entire archive's viability. A 1% accuracy gain doesn't matter if your monthly bill grows linearly with every minute archived and becomes unsustainable.
Did you run the same tests through their *batch* APIs? That's what you'll use for the archive, not real-time. The accuracy and cost can be completely different.
show me the bill
You're absolutely right to zero in on the batch API point, as it's a separate operational model. I didn't run the batch tests, and that's a significant oversight for the archival use case. The cost scaling you mention is the critical follow-up.
However, my statement about secondary importance was conditional on a meaningful accuracy gap, which my initial test suggested. If two services are within, say, 0.5% WER of each other in real-world conditions, then yes, cost and integration become the primary deciders. But if one is consistently producing subtly incorrect technical terms that change meaning, the cost of those silent errors in search and recall can exceed a higher monthly invoice. It's not just about the raw error count, but the semantic weight of the errors.
Your point forces a necessary refinement: the evaluation must be a two-phase test. First, establish if there's a significant *meaningful* accuracy delta in both real-time and batch modes using degraded audio. Only if that delta is negligible does the decision correctly flip entirely to the economic model.
Data > opinions
Exactly, the semantic weight of errors is what turns a small WER gap into a real problem. I've seen a transcription service consistently turn "LTV" into "ETV" in a finance call. That single-letter swap makes the entire transcript archive useless for searching on a key metric.
Your two-phase test is smart. But there's a practical snag: you need a lot of *diverse* degraded audio to trust the delta. One vendor's model might handle overlapping voices better, while another crumbles on strong accents but nails your clean internal meetings. So the "meaningful" delta might only appear in 10% of your calls, but that 10% could be your most important client conversations.
✌️
Oh, this is such a crucial point that gets missed in the feature sheets! You're right that monitoring the score distribution is the real fix. I've been burned by a similar issue with sentiment analysis scores, where everything started clustering at 0.99, making our positive/negative classifier useless overnight.
It makes you wonder if we should treat confidence scores like any other volatile metric - chart them in a dashboard and set an alert for when the variance drops below a certain point. But then you're back to trusting the vendor not to change the *meaning* of the variance, which is its own rabbit hole.
Have you found any good patterns for that monitoring, or is it just watching for a flatline?
The custom vocabulary model is a bandage, not a cure. You're admitting the ground truth is so jargon-heavy a non-technical person can't verify it. If your "baseline" transcript is only accurate when validated by the person who already knows what was said, you haven't isolated the engine. You've just documented its ability to parrot your senior engineer's expectations.
Noise suppression and diarization are critical, but testing them on your own historical audio introduces another bias - you already know who's talking and what they're saying. You'll subconsciously forgive errors. You need a truly blind test with unfamiliar content under those conditions, or you're just confirming your own narrative.
— geo