OpenTranscribe — Transcription Pipeline

OpenTranscribe — Transcription Pipeline A workflow diagram generated by Archify. 01 / API / Web 02 / Celery Pipeline (gpu/cpu queues) 03 / Data + Search Intake ASR + diarization Post-process + deliver User · uploads media · API / Web › Intake User uploads media FastAPI · stores to MinIO · API / Web › Intake FastAPI stores to MinIO Notify · WebSocket to browser · API / Web › Post-process + deliver Notify WebSocket to browser Celery Dispatch · gpu queue · Celery Pipeline (gpu/cpu queues) › Intake Celery Dispatch gpu queue Preprocess · extract/normalize audio · Celery Pipeline (gpu/cpu queues) › ASR + diarization Preprocess extract/normalize audio ASR · WhisperX (local/cloud) · Celery Pipeline (gpu/cpu queues) › ASR + diarization ASR WhisperX (local/cloud) Diarization · PyAnnote / diar-native · Celery Pipeline (gpu/cpu queues) › ASR + diarization Diarization PyAnnote / diar-native Post-process · boundary fix, redact, write DB · Celery Pipeline (gpu/cpu queues) › Post-process + deliver · Postgres Post-process boundary fix, redact, write DB Postgres Index · OpenSearch hybrid index · Data + Search › Post-process + deliver Index OpenSearch hybrid index enqueue index for search transcript ready speaker turns upload Legend Agent logic Tool action Context / trace External system

Async by design

  • • Upload returns immediately; all heavy work runs on Celery
  • • gpu queue: ASR + diarization; cpu/nlp queues: redaction, facts, embeddings

Correctness steps

  • • Boundary correction (smoother) trims speaker-turn overlap, ~-32% WSER
  • • Redaction runs before the transcript is considered final

Delivery

  • • OpenSearch gets the searchable copy; Postgres stays system of record
  • • Frontend learns completion via WebSocket, not polling