stephensonsco

I didn't answer "Do you have a cheap way of generating high quality data?". We have good ways to do it. They're not that cheap though. It's expensive (organizationally and real $$$) to label large amounts of data no matter what.

But we do utilize our capabilities to better tackle the wild data gathering and labeling. For instance, "is every labeled minute just as valuable as any other?". Definitely not. So if you can find and select only the data you want to label, rather than indiscriminately labeling a bunch, then you can increase your overall efficacy.

Yep, all good points. One thing to consider is that generalization is a big problem. It's easy to get good on a specific dataset nowadays (like 5-10% word error rate level on academic datasets), but that same model might do 40% WER on data in the wild.

You can pay to get training at a lower usage amount too.

You find out very interesting things even randomly sampling your life in audio.

We still come back to this for fun. The original device was an intel edison but recent variants have been based on the raspberry pi zero w.

If you're training from scratch around 10k hours is needed to get a good model, but when you are transfer learning you don't need nearly that much (100 hours gets you a lot).

We excel in phone call and meetings settings. I.e. the typical sales/office/support environment.

There's no additional charge for training a custom model when your usage is a minimum of 10k hrs/mo.

Best to say "yes! but only some of the time". It's something we're working on right now. You can be 80% accurate, by some metric, but it's still not good enough usually to pass a human's sniff test. Good speaker labeled audio in various settings is hard to find.

There are several ways to look at this problem too.

L1: exact speaker is known (voiceprint) and can be picked from all humans with accuracy, even when others are talking L2: exact speaker is known from a subset of people, even while talking in a conversation with others L3: speaker1,2,3,... are identified accurately L4: speaker changes are identified accurately

L1 is a really hard problem. L2 is fine if you don't care about the time domain (knowing exactly when they spoke), but is harder if you have to accurately detect changes. L3 is about as hard as L2 but the big goal isn't who anymore, it's when. And L4 is easier, kinda like putting line breaks in when human transcribing a file. Not too bad. All of them need better data sources.

We do custom models (train the full DNN, not just tack on a new text language model) using transfer learning and it works for small numbers of examples too.

Glad to hear you asking about fuzzy search. That's something we do (it's actually what Deepgram started on!). It's not in the docs at the moment (tends to confuse people who are looking for transcription, we're working on how to present it in a better way). You can submit with queries and get back confidences and timestamps.

Many times the model doesn't need any training but it does increase accuracy if you do training and can get really good if it's focused (it's a lot like wake word detection -- we don't offer WWD as a real product yet either, just saying the challenges are similar). Best thing to do is search for phrases if you can, that really helps signal/noise.

It's a metric that's hard to nail down because there is so much parameter space that you are flattening into one number. Also it doesn't address the "I care about these five high value words (that are made up), can you recognize them?" like product names and company names.

There's ~4 types of audio:

Phone call - close microphone - conversational - low bandwidth audio - two way conversation - more industry specific terminology

Meetings - 2-5 people - conversational - far away mic - better bandwidth audio - more industry specific terminology

Broadcast - usually good diction - close mic - good bandwidth audio - more general terminology

Command&Control (saying to your phone: "go to <this address>") - close mic or array or mics far away - short audio chunks, 2-10 seconds - spoken in a way that makes it easier to recognize (learned behavior) - usually a lot of widely known named entities are said

In that full aggregated line up I bet we'd be in the 22-24% WER pack. That'd mostly be because we focus only on phone calls and meetings. We don't try to improve command&control/broadcast/podcast type yet. Broadcast because it's perceived as lower value (so customers tend not to pay for good recognition for it [we do train models to make them better for specific customers/verticals(usually a reduction of errors by 20-40%), but the buyer has to have a budget for it for now, but there are ways to make it cheaper in the long term]), command and control because you have to have a fleet of devices out in the field collecting data and driving use cases and we don't have customers there yet.

Price starts at $1/hr billed in 1 second increments. Frequently we charge less than that, since the price is dropped with volume, and that's typically businesses have a steady amount running through them (a few thousands hours). Medium usage scale would be $0.25-0.75/hr (e.g. 10,000 hours to 100,000 hours a month scale). Large usage is around 10,000 hrs+ per day and the price can be much lower per transcribed hour (like $0.15/hr).

That's the ballpark for cloud + batch mode. If it's cloud + realtime it's a little more. If you need it on premise it's a little more (we work with integration partners to do parts of it).

Pricing for speech is interesting since there's more than just how many $/hr in the equation. Usually businesses care about turnaround time, throughput, failover/availability, and a collection of features. So we usually want to talk about those goals and price accordingly to support 'em. I definitely wish I had a better way to frame it than "it's complicated"!

Pretrained models are very nice to spin up a system and start using it. You need that because training the model is so hard. But, the pretrained models are by no means a good general model. They are trained with narrow params (like #/size of datasets), so the ability to generalize is very low. It's not uncommon to train a system like that to be 5% WER on Switchboard (think MS/IBM), then have that same system perform at 40% WER on other audio.