Memilih Arsitektur Pemrosesan Dokumen Office untuk AI Agent

Memilih arsitektur pemrosesan dokumen Office untuk AI agent bukan sekadar soal library mana yang paling mudah dipakai. Keputusan ini memengaruhi isolasi proses, keamanan file tak tepercaya, latensi request, throughput batch, biaya operasional, dan kemudahan debugging saat sistem mulai dipakai oleh banyak user atau banyak workflow agent.

Untuk banyak tim, OfficeCLI adalah pintu masuk yang masuk akal karena ia memberi batas proses yang jelas antara aplikasi AI agent dan komponen pemroses file Word, Excel, atau PowerPoint. Namun, itu bukan satu-satunya pilihan. Secara umum ada tiga pendekatan yang perlu dibandingkan: library in-process, CLI/tool eksternal, dan service terpisah. Artikel ini membahas kapan masing-masing cukup, kapan perlu dipisah ke worker, dan kapan service khusus benar-benar layak.

Mengapa arsitektur pemrosesan dokumen Office penting untuk AI agent

AI agent yang bekerja dengan dokumen Office biasanya tidak hanya membaca teks. Ia bisa perlu:

• mengekstrak isi dokumen Word beserta struktur heading dan tabel,
• membaca sheet Excel, formula, dan range tertentu,
• mengambil teks dari slide PowerPoint, catatan presentasi, atau metadata,
• mengonversi dokumen ke format intermediate seperti plain text, HTML, JSON, atau PDF untuk indexing dan retrieval,
• menjalankan pipeline OCR atau enrichment lanjutan jika file tidak bersih.

Masalahnya, file Office bukan input sederhana. Formatnya kompleks, ukuran file bisa besar, isinya bisa rusak atau dibuat secara tidak wajar, dan parsing sering memakan CPU serta memori. Jika file berasal dari user atau pihak luar, anggaplah file tersebut tidak tepercaya. Di titik ini, pilihan arsitektur lebih penting daripada sekadar kenyamanan coding.

Tiga pendekatan utama

1. Library in-process

Pada pendekatan ini, aplikasi AI agent memanggil library parser Office langsung di proses yang sama dengan web app, API server, atau worker utama. Contohnya: request masuk, backend membuka file, library mem-parse dokumen, hasil ekstraksi langsung dipakai oleh agent.

Kelebihan:

• latensi paling rendah karena tidak ada proses tambahan atau hop jaringan,
• implementasi paling sederhana untuk prototipe atau volume kecil,
• deployment lebih mudah karena semua ada dalam satu aplikasi.

Kekurangan:

• risiko crash, memory leak, atau hang langsung berdampak ke proses utama,
• lebih berbahaya untuk file tak tepercaya,
• sulit membatasi konsumsi CPU/memori per dokumen tanpa mekanisme isolasi tambahan,
• observabilitas parsing sering tercampur dengan log aplikasi utama.

Pendekatan ini cocok jika dokumen relatif kecil, sumber file tepercaya, volume tidak tinggi, dan Anda ingin meminimalkan kompleksitas operasional.

2. CLI/tool eksternal

Pada pendekatan ini, aplikasi memanggil tool eksternal melalui subprocess. OfficeCLI masuk di kategori ini. Aplikasi menulis file ke storage sementara atau menerima path file, lalu menjalankan command untuk ekstraksi atau konversi. Hasilnya bisa dibaca dari stdout, file output, atau format JSON yang disepakati.

Kelebihan:

• ada batas proses antara aplikasi utama dan parser,
• lebih aman untuk file tak tepercaya dibanding in-process,
• lebih mudah menerapkan timeout, kill process, pembatasan resource, atau sandbox,
• bahasa aplikasi utama tidak perlu sangat terikat pada library parser tertentu.

Kekurangan:

• ada overhead membuat proses baru,
• manajemen file sementara dan error handling menjadi lebih penting,
• integrasi batch throughput tinggi perlu desain yang rapi agar tidak terlalu banyak spawn process paralel,
• hasil dan error dari tool perlu distandardisasi agar mudah dipakai agent.

Untuk banyak tim, ini adalah titik tengah terbaik: lebih aman dan lebih maintainable daripada in-process, tetapi belum sekompleks service terpisah.

3. Service terpisah

Pada pendekatan ini, pemrosesan dokumen menjadi service sendiri, biasanya diakses lewat HTTP, gRPC, atau queue. Aplikasi AI agent mengirim request ekstraksi atau job asynchronous, lalu service dokumen mengerjakan parsing, konversi, normalisasi, dan mungkin indexing awal.

Kelebihan:

• isolasi paling kuat dari aplikasi utama,
• skalabilitas paling baik untuk throughput tinggi dan workload batch,
• resource tuning bisa spesifik untuk beban dokumen,
• lebih mudah menerapkan observabilitas, retry policy, dead-letter queue, dan autoscaling worker.

Kekurangan:

• biaya operasional dan kompleksitas deployment paling tinggi,
• butuh kontrak API yang stabil, format hasil yang konsisten, dan versioning,
• latensi request sinkron cenderung lebih tinggi karena hop tambahan,
• tim kecil bisa terlalu cepat masuk ke arsitektur yang belum perlu.

Pendekatan ini layak saat volume mulai besar, sumber file beragam, file tak tepercaya umum terjadi, atau beberapa aplikasi berbeda perlu memakai pipeline dokumen yang sama.

OfficeCLI sebagai pintu masuk praktis

OfficeCLI berguna sebagai boundary yang jelas: aplikasi AI agent tidak perlu menanam seluruh logika parsing Office di prosesnya sendiri. Secara praktis, OfficeCLI dapat diposisikan sebagai:

• adapter lokal di dalam monolit atau worker, atau
• engine pemrosesan di balik service dokumen khusus.

Dengan model CLI, Anda mendapatkan beberapa keuntungan arsitektural:

• kontrak input/output yang eksplisit, misalnya file path masuk dan JSON keluar,
• isolasi kegagalan, jika parser hang atau crash, proses utama tetap hidup,
• kontrol eksekusi, lebih mudah menambahkan timeout, ukuran output maksimum, dan policy cleanup file sementara,
• portabilitas integrasi, aplikasi dari bahasa berbeda bisa memakai tool yang sama.

Yang perlu diingat: CLI bukan jaminan aman dengan sendirinya. Anda tetap harus mengatur direktori kerja, hak akses file, timeout, batas memori jika memungkinkan, dan pembersihan artefak sementara.

Matriks keputusan

Kapan monolit cukup, kapan worker terpisah lebih aman, kapan service khusus layak

Skenario 1: Monolit cukup

Pilih monolit jika semua kondisi berikut relatif benar:

• volume dokumen rendah sampai sedang,
• request sinkron masih penting,
• file berasal dari sumber internal atau lebih tepercaya,
• ukuran dokumen umumnya kecil-menengah,
• tim ingin bergerak cepat tanpa overhead infrastruktur tambahan.

Dalam skenario ini, Anda masih bisa memakai OfficeCLI dari monolit untuk mendapat isolasi proses dasar tanpa harus membangun service sendiri. Ini sering menjadi pilihan paling pragmatis.

Skenario 2: Worker terpisah lebih aman

Pilih worker terpisah jika:

• file berasal dari user eksternal atau integrasi pihak ketiga,
• parsing bisa memakan waktu cukup lama,
• Anda tidak ingin request API utama terblokir,
• dokumen masuk dalam batch,
• kegagalan parsing tidak boleh menjatuhkan web/API process.

Pola yang umum: API menerima upload, menyimpan metadata dan file, lalu mengirim job ke queue. Worker menjalankan OfficeCLI, menulis hasil ekstraksi ke storage atau database, lalu agent melanjutkan indexing atau reasoning setelah job selesai.

Ini sering menjadi titik upgrade paling sehat dari monolit, karena memberi isolasi lebih baik tanpa harus langsung memecah seluruh pipeline menjadi microservice.

Skenario 3: Service khusus layak

Pilih service khusus jika:

• beberapa aplikasi atau tim perlu memakai pipeline dokumen yang sama,
• throughput batch tinggi dan butuh autoscaling,
• pipeline dokumen memiliki banyak tahap: ekstraksi, normalisasi, OCR, chunking, klasifikasi, indexing,
• kebutuhan observabilitas, audit, dan policy keamanan lebih ketat,
• Anda ingin lifecycle rilis pemrosesan dokumen terpisah dari aplikasi agent.

Service khusus masuk akal saat pemrosesan dokumen sudah menjadi domain penting tersendiri, bukan lagi utilitas kecil di belakang aplikasi.

Contoh alur request

Alur A: Monolit + OfficeCLI sinkron

1. User mengunggah file DOCX/XLSX/PPTX.
2. API menyimpan file ke direktori sementara atau object storage.
3. Aplikasi menjalankan OfficeCLI dengan timeout ketat.
4. Hasil ekstraksi dikonversi ke format internal agent.
5. Agent menjalankan chunking, embedding, atau summary.
6. File sementara dibersihkan.

Kapan dipakai: dokumen kecil, traffic rendah, kebutuhan respons cepat.

Alur B: API + Queue + Worker + OfficeCLI

1. User mengunggah file.
2. API hanya menyimpan file dan membuat job.
3. Worker mengambil job dari queue.
4. Worker menjalankan OfficeCLI di proses terpisah.
5. Hasil ekstraksi disimpan ke database atau object storage.
6. Status job diperbarui.
7. Agent atau pipeline indexing memproses hasil lanjutan secara asynchronous.

Kapan dipakai: file tak tepercaya, ukuran file bervariasi, throughput mulai naik.

Alur C: API Agent -> Document Service

1. API agent menerima file atau referensi file.
2. Request dikirim ke document service.
3. Service membuat job internal dan mendistribusikan ke worker.
4. Worker menjalankan OfficeCLI atau engine parser lain.
5. Service mengembalikan hasil sinkron atau callback status.
6. Agent mengonsumsi hasil yang sudah dinormalisasi.

Kapan dipakai: banyak consumer, kebutuhan isolasi tinggi, pipeline dokumen sudah kompleks.

Contoh integrasi praktis dengan pola CLI

Inti integrasi yang sehat bukan pada command spesifiknya, tetapi pada cara Anda mengeksekusi tool eksternal dengan aman: validasi input, timeout, pembacaan output terukur, dan cleanup file. Contoh pseudocode berikut menggambarkan pola umum:

function extractOfficeDocument(filePath) {
  assertFileExists(filePath)
  assertAllowedExtension(filePath)

  const cmd = [
    "officecli",
    "extract",
    "--input", filePath,
    "--format", "json"
  ]

  const result = runProcess(cmd, {
    timeoutMs: 30000,
    maxStdoutBytes: 10 * 1024 * 1024,
    cwd: "/srv/office-sandbox",
    env: { LANG: "C" }
  })

  if (result.exitCode !== 0) {
    logError("office_extract_failed", {
      filePath,
      exitCode: result.exitCode,
      stderr: truncate(result.stderr, 4000)
    })
    throw new Error("Document extraction failed")
  }

  return parseJson(result.stdout)
}

Hal yang penting dari contoh di atas:

• timeout mencegah proses menggantung terlalu lama,
• batas ukuran stdout mencegah ledakan memori akibat output tak terduga,
• cwd terkontrol membantu sandboxing dan cleanup,
• error distandardisasi agar mudah dipantau dari sistem utama.

Trade-off teknis yang paling sering menentukan

1. Isolasi proses

Jika parser berjalan in-process, bug parser bisa merusak seluruh worker atau web process. Dengan CLI, setidaknya crash parser berhenti di subprocess. Dengan service terpisah, radius dampak lebih kecil lagi karena kegagalan terbatas pada domain dokumen.

Jika file berasal dari luar organisasi, anggap isolasi proses sebagai kebutuhan, bukan fitur tambahan.

2. Keamanan file tak tepercaya

Dokumen Office dapat berisi struktur yang tidak lazim, file sangat besar, atau konten yang sengaja dibuat untuk membebani parser. Risiko praktis yang perlu dihadapi:

• CPU spike karena parsing kompleks,
• penggunaan memori berlebih,
• hang pada parser tertentu,
• zip bomb atau arsip dengan ekspansi ekstrem,
• eksposur path/file system jika direktori kerja tidak dibatasi.

CLI dan service memudahkan mitigasi ini karena Anda bisa menambahkan sandbox, user non-privileged, filesystem terisolasi, dan batas resource. Untuk in-process, mitigasi semacam ini jauh lebih sulit diterapkan dengan bersih.

3. Latensi

Untuk request sinkron yang harus cepat, in-process terlihat menarik. Namun, jika file tidak konsisten atau parser kadang lambat, latensi tail bisa memburuk. CLI menambah sedikit overhead startup proses, tetapi sering sepadan dengan peningkatan kestabilan. Service terpisah menambah hop jaringan dan serialisasi, sehingga lebih cocok untuk workflow asynchronous atau semi-asynchronous.

4. Throughput batch

Batch besar jarang cocok dijalankan langsung di web process. Worker dengan queue biasanya jauh lebih baik karena concurrency bisa dikendalikan. CLI dalam worker cukup efektif selama Anda membatasi jumlah subprocess paralel sesuai CPU dan memori. Service khusus unggul ketika Anda butuh skala horizontal dan pengaturan kapasitas independen dari aplikasi utama.

5. Biaya operasional dan deployment

Monolit in-process paling murah di awal. CLI sedikit menambah kompleksitas packaging binary/tool dan runtime environment. Service terpisah menambah image/container, monitoring, deployment pipeline, queue, retry logic, dan kadang penyimpanan hasil terpisah. Jangan memilih service khusus hanya karena terlihat lebih rapi secara arsitektur jika belum ada tekanan skala yang nyata.

6. Observabilitas

Pemrosesan dokumen sering gagal karena file tertentu, bukan karena bug sistem secara umum. Karena itu, observabilitas penting:

• log per file dan per job,
• durasi ekstraksi,
• ukuran file input dan output,
• kode keluar proses,
• stderr terpotong dengan aman,
• jumlah retry, timeout, dan kategori kegagalan.

Pada pendekatan CLI, Anda bisa menjadikan stdout sebagai hasil terstruktur dan stderr sebagai log diagnostik. Pada service terpisah, Anda bisa menambahkan tracing lintas komponen dengan lebih rapi.

7. Maintainability

In-process mudah di awal, tetapi coupling cepat meningkat jika logika parser, normalisasi konten, fallback, dan policy keamanan terus bertambah di codebase utama. CLI memberi batas antarmuka yang lebih jelas. Service memberi pemisahan domain paling kuat, tetapi hanya benar-benar menguntungkan jika ada cukup kompleksitas untuk dibenarkan.

Risiko utama dan cara menguranginya

File sementara tidak dibersihkan

Masalah ini umum pada pendekatan CLI dan worker. Solusi: gunakan direktori kerja per job, beri TTL cleanup, dan pastikan cleanup tetap berjalan walau job gagal.

Subprocess tak pernah selesai

Tanpa timeout, satu file rusak dapat menahan worker terlalu lama. Terapkan timeout keras, lalu tandai job sebagai gagal-terkontrol, bukan gagal diam-diam.

Terlalu banyak proses paralel

Menjalankan banyak instance CLI sekaligus bisa membuat host kehabisan CPU atau memori. Gunakan concurrency limit berbasis kapasitas host, bukan hanya jumlah job di queue.

Format hasil tidak stabil

Jika hasil ekstraksi dipakai banyak bagian sistem, buat kontrak hasil yang konsisten: metadata file, isi teks, struktur dokumen, daftar sheet/slide, warning, dan error code. Jangan biarkan tiap caller menafsirkan output parser sendiri.

Parsing dilakukan di jalur request kritis tanpa fallback

Jika ekstraksi Office ada di request yang sensitif terhadap latensi, siapkan fallback: respons 202 asynchronous, cache hasil, atau pemisahan mode cepat vs mode lengkap.

Catatan praktis: Banyak masalah bukan berasal dari parser Office itu sendiri, tetapi dari keputusan arsitektur yang menempatkan parsing berat di proses yang salah, tanpa timeout, tanpa cleanup, dan tanpa observabilitas.

Rekomendasi praktis

Untuk tim kecil

Mulailah dengan monolit atau worker sederhana yang memanggil OfficeCLI. Ini biasanya memberi rasio terbaik antara keamanan, kecepatan implementasi, dan maintainability.

• Jika kebutuhan sinkron dan traffic kecil: monolit + OfficeCLI + timeout + cleanup yang disiplin.
• Jika file berasal dari luar atau ukuran file sulit diprediksi: API + queue + worker + OfficeCLI.

Hindari membangun document service khusus terlalu awal kecuali sejak awal sudah jelas ada banyak consumer atau regulasi keamanan yang ketat.

Untuk sistem yang mulai diskalakan

Saat volume naik, file makin beragam, atau pipeline agent bertambah kompleks, naikkan isolasi bertahap:

1. pisahkan parsing dari web process ke worker,
2. standarkan output ekstraksi,
3. tambahkan metrik dan kategori error,
4. batasi concurrency per host,
5. baru pertimbangkan service khusus jika pemrosesan dokumen sudah menjadi domain independen.

Dengan pendekatan bertahap ini, Anda tidak membayar kompleksitas terlalu cepat, tetapi tetap punya jalur evolusi yang jelas.

Kesimpulan

Dalam konteks memilih arsitektur pemrosesan dokumen Office untuk AI agent, tidak ada satu jawaban mutlak untuk semua tim. Library in-process cocok untuk kebutuhan sangat sederhana dan tepercaya. CLI/tool eksternal seperti OfficeCLI adalah pilihan praktis yang sering paling seimbang karena memberi isolasi proses tanpa biaya operasional setinggi service khusus. Service terpisah layak ketika skala, keamanan, dan kompleksitas pipeline sudah cukup besar untuk membenarkannya.

Jika Anda ragu, gunakan aturan sederhana ini: mulai dari CLI yang dijalankan secara disiplin, pindah ke worker saat risiko dan volume naik, lalu bangun service khusus hanya ketika pemrosesan dokumen benar-benar telah menjadi subsistem tersendiri.