Lewati ke konten utama

Pipeline AI Deterministik

Arsitektur pipeline AI andal menggunakan worker idempoten, state store eksplisit, dan eksekusi tahap yang dikendalikan orchestrator.

5 menit baca·Menengah·Konsep·25 Agu 2026
ai systemsdistributed systems

Pipeline AI Deterministik

Apa yang Dibangun​

Artikel ini mensintesis pola pipeline deterministik yang digunakan di tiga repositori publik: shorts-generator (pipeline video 16 tahap dengan checkpoint SQLite), md-ame (autonomous media engine dengan state machine RPC PostgreSQL), dan skeleton-parallel (loop agent berbasis tugas dengan rollback checkpoint Git). Bersama-sama, ketiganya menunjukkan cara membangun sistem AI di mana input sama + config sama = output yang dapat diprediksi dan dipulihkan.

Masalah​

Kebanyakan pipeline AI gagal di produksi karena memperlakukan panggilan LLM sebagai lapisan orkestrasi. Agent memutuskan langkah berikutnya, retry tidak terbatas, dan state tinggal di memori atau tersebar di file log. Ketika run crash atau operator menjalankan ulang job, Anda mendapat output duplikat, state parsial yang rusak, atau hasil yang tidak dapat direproduksi.

Mengapa Masalah Ini Sulit​

  1. Non-determinisme LLM — output model bervariasi meskipun prompt identik.
  2. Tahap berjalan lama — transkripsi, rendering, dan panggilan API memakan waktu menit.
  3. Kegagalan parsial — crash di tahap 12 dari 16 tidak boleh memulai ulang dari tahap 1.
  4. Konkurensi — beberapa worker mengklaim job yang sama menyebabkan pekerjaan duplikat.
  5. Drift konfigurasi — override per-akun atau per-dimensi memperbanyak ruang state.

Model Mental untuk Pemula​

Pipeline AI deterministik adalah resep dengan checklist, bukan percakapan. Orchestrator memegang checklist (state store). Setiap langkah menerima input yang terdefinisi, menghasilkan output yang terdefinisi, dan mencatat penyelesaian sebelum langkah berikutnya dimulai. Jika dapur kebakaran, Anda membaca checklist dan melanjutkan pada item pertama yang belum dicentang — Anda tidak memasak ulang dari awal.

Persyaratan dan Kendala​

Persyaratanshorts-generatormd-ameskeleton-parallel
State storeSQLiteSupabase PostgreSQLGit tags + PLAN.md
Urutan tahap16 tahap tetapFase pipeline tetapDaftar tugas di PLAN.md
Idempotensivideo_id content-addressableidempotency_key SHA-256Rollback checkpoint
Isolasi modulKontrak DTO bekuTransisi DB berbasis RPCScript quality gate
Batas retryResume dari tahap terakhirCron replay + recovery passMaks 5 percobaan per tugas
Otoritas orchestratorSatu proses PythonCron + global lockCLI skeleton run

Gambaran Arsitektur​

Orchestrator adalah satu-satunya komponen yang memajukan state. Panggilan LLM adalah worker di dalam tahap, bukan control plane.

Alur Eksekusi​

  1. Trigger — cron, scheduler, atau perintah CLI memulai run dengan execution ID yang diketahui.
  2. Muat state — orchestrator membaca state store untuk pekerjaan yang sedang berjalan atau terhenti.
  3. Recovery pass — identifikasi dan lanjutkan atau gagalkan job yang macet sebelum menghasilkan pekerjaan baru.
  4. Eksekusi tahap — jalankan setiap tahap secara berurutan; catat penyelesaian di state store.
  5. Tahap LLM — perlakukan output LLM sebagai data untuk divalidasi, bukan keputusan routing.
  6. Quality gate — tahap validasi menolak output buruk sebelum menyebar ke downstream.
  7. State terminal — run berakhir di completed, failed, atau rolled_back — tidak pernah ambigu.

Komponen Penting​

PolaTanggung jawab
OrchestratorUrutan tahap, checkpointing, penanganan error
State storeSingle source of truth untuk progress dan output
Kontrak bekuDTO atau skema RPC antar tahap/modul
Idempotency keysMencegah output duplikat saat retry
Quality gateMemvalidasi output LLM sebelum melanjutkan
Recovery passMenangani pekerjaan terhenti sebelum generasi baru

Contoh Implementasi yang Disederhanakan​

Pola checkpoint orchestrator (disederhanakan):

# simplified — resume from last completed stage
last_stage = db.get_last_completed_stage(run_id)
for stage in STAGES[index_of(last_stage) + 1:]:
    output = stage.run(input_dto)
    db.record_stage_complete(run_id, stage.name, output)

Insert idempoten (disederhanakan):

-- simplified — safe rerun
INSERT INTO work_units (idempotency_key, status, payload)
VALUES ($1, 'queued', $2)
ON CONFLICT (idempotency_key) DO NOTHING;

Keandalan dan Idempotensi​

  • Di mana state tinggal: Selalu di store yang tahan lama (SQLite, PostgreSQL, atau Git), tidak pernah hanya di memori proses.
  • Apa yang terjadi saat retry: Tahap yang selesai dilewati; tahap yang sedang berjalan dilanjutkan atau gagal secara eksplisit.
  • Panggilan LLM: Di-cache berdasarkan hash konten jika memungkinkan (TTS di shorts-generator, scene cache di md-ame).
  • Konkurensi: FOR UPDATE SKIP LOCKED (md-ame, polymarket) atau orchestrator single-process (shorts-generator) mencegah klaim duplikat.

Mode Kegagalan​

KegagalanPerilaku
Crash di tengah pipelineResume dari tahap terakhir yang tercatat
LLM mengembalikan output tidak validQuality gate menolak; retry terbatas
Trigger cron duplikatIdempotency keys mencegah output duplikat
Job in-progress yang macetRecovery pass mengidentifikasi dan melanjutkan atau gagalkan
Perubahan config di tengah runRun baru mendapat idempotency key baru; run lama selesai atau gagal

Trade-off dan Alternatif yang Ditolak​

PilihanAlasanAlternatif yang ditolak
Tahap dikendalikan orchestratorAlur dapat diprediksi dan diujiAgent memutuskan langkah berikutnya secara dinamis
State store tahan lamaPemulihan crashState in-memory + harapan
Retry terbatasTerminasi yang diketahuiLoop agent tak terbatas
Quality gate pada output LLMMenangkap error sebelum menyebarMempercayai output LLM secara membabi buta
Idempotency keysRerun amanHapus-dan-buat ulang saat retry

Pengujian​

Ketiga repositori sumber menyertakan unit dan integration test. Tahap deterministik diuji dengan fixture; tahap LLM memakai mock atau respons yang direkam. Quality gate memiliki test case eksplisit untuk jalur pass/fail/revert.

Operasi dan Observabilitas​

  • shorts-generator: pipeline.log per video; state SQLite dapat di-query; cron scheduler
  • md-ame: Stdout terstruktur dengan execution_id; laporan mingguan Telegram
  • skeleton-parallel: Git tags sebagai titik rollback; output script quality gate

Pelajaran yang Dipetik​

  1. Pisahkan control plane dari LLM — orchestrator memutuskan kapan; LLM memutuskan teks/kode apa dalam tahap yang terbatas.
  2. Checkpoint di batas tahap — resume kasar mengalahkan recovery sub-langkah halus untuk sebagian besar pipeline.
  3. Idempotensi bukan opsional — sistem apa pun yang dapat di-retry harus menghasilkan outcome yang sama dengan input state yang sama.
  4. Kekacauan agent adalah design smell — jika pipeline Anda tidak dapat digambar sebagai flowchart, pipeline tersebut belum cukup deterministik untuk produksi.

Terkait​

Sumber​