Processing pipelines

Compose speech recognition, speaker processing, audio intelligence, and language models into one observable request instead of stitching vendors.

A pipeline is the ordered set of stages applied to an audio workload.

audio
  → speech model
  → diarization
  → transcript formatting
  → entities and sentiment
  → language-model task
  → structured output

Every stage is optional except the stage that produces the base representation your application needs.

Design principles

Keep stages explicit

Know which model and processor produced each field. Hidden bundles make accuracy, latency, and cost difficult to debug.

Separate immediate and eventual output

Streaming text can arrive immediately while diarization, entities, or LLM-derived output finalize later. Do not make a responsive interface wait for the slowest stage unless it must.

Make jobs idempotent

Attach your own stable request identifier where the API surface supports it. If a network failure makes completion uncertain, reconcile job state before submitting the same audio again.

Version evaluation data

When changing a model or processor, run the same representative set and compare the whole pipeline, not just one isolated metric.

On this page