- Untuk mengekstrak informasi dari dokumen kompleks, pendekatan OCR dan parsing tradisional tidak mampu mempertahankan makna dengan baik
- Morphik menerapkan metode embedding dokumen visual berbasis model ColPali yang dapat langsung memahami tabel, bagan, hingga konteks tata letak
- Dibanding pipeline lama, metode ini jauh lebih unggul dalam hal akurasi dan pelestarian informasi, dengan capaian akurasi hingga 95,56% pada uji benchmark
- Selain itu, dengan penerapan MUVERA dan Turbopuffer, mereka berhasil meningkatkan kecepatan dalam pencarian dokumen skala besar
- Ke depannya, targetnya adalah otomasi pekerjaan dokumen yang nyata seperti penalaran multi-dokumen, integrasi workflow, dan interpretasi setingkat pakar
Batas parsing dokumen kompleks dan tantangan RAG
- Saat mencoba mengekstrak informasi dari dokumen PDF kompleks yang mencampurkan grafik, diagram, dan tabel, pipeline OCR dan parsing sering kehilangan informasi yang dibutuhkan
- Keterbatasan pipeline lama sangat terasa dalam situasi nyata seperti tabel bertingkat, diagram penting, dokumen teknis dengan banyak anotasi, bahkan manual tanpa teks
- Tahapan pipeline lama:
- Menerapkan OCR ke PDF (angka atau huruf bisa salah dibaca)
- Mencoba membedakan tabel/diagram dengan model deteksi layout (peluang gagal tinggi)
- Memulihkan urutan baca (aliran visual bisa terlewat)
- Mengenali caption diagram (nuansa sering hilang)
- Text chunking (informasi yang saling terkait bisa terpisah)
- Membuat embedding vektor dan menyimpannya di vector DB (informasi posisi dan konteks hilang)
- Contoh: bahkan tabel sederhana pun sering dibaca sebagai "1,000" menjadi "l,0O0", atau tabel dan header terpisah sehingga perhitungan total gagal
- Kasus kehilangan informasi di dunia nyata juga sering terjadi, seperti legenda grafik dianggap sebagai teks isi, atau nilai persentase tersebar ke posisi yang salah
Pendekatan baru: beralih ke pemahaman dokumen berbasis visual
- Tim Morphik menemukan titik balik dari pertanyaan: "Bagaimana jika dokumen dipahami sebagai objek visual seperti manusia melihatnya?"
- Berkat riset terbaru (ColPali) dan perkembangan Vision Language Model (VLM), kini dimungkinkan untuk melakukan embedding langsung pada gambar sehingga seluruh konteks dokumen dan informasi visual tetap terjaga tanpa parsing atau OCR
- Setiap halaman dokumen diproses sebagai gambar beresolusi tinggi, lalu dipecah per patch untuk menghasilkan embedding yang mencerminkan informasi visual sekaligus tekstual
- SigLIP-So400m Vision Transformer membuat embedding patch visual, sementara model bahasa PaliGemma-3B memahami struktur dokumen
- Untuk kueri (seperti "tren pendapatan Q3"), informasi terkait diekstrak secara akurat dengan metode pencarian late interaction yang mencakup petunjuk visual seperti teks, grafik, tabel, dan warna
- Posisi dalam dokumen, layout, warna, perubahan grafik, dan semua informasi visual tetap dipertahankan—mirip cara manusia melihat dokumen secara sekilas
Perbandingan parsing tradisional dan pendekatan ColPali
- Pipeline berbasis parsing lama kehilangan informasi di setiap tahap, dan karena embedding teks serta gambar terpisah, hubungan spasial di dalam dokumen tidak bisa diinterpretasikan
- Sebaliknya, pendekatan ColPali mengintegrasikan semua informasi dalam satu ruang embedding visual, sehingga makna dan konteks keseluruhan dokumen tetap terjaga
- Dalam benchmark nyata (berfokus pada dokumen keuangan, dataset publik), Morphik (berbasis ColPali) mencatat akurasi hingga 95,56% (sementara LangChain+OpenAI text-embedding hanya 72%, dan OpenAI file search hanya 13,33%)
- Pada benchmark ViDoRe, pendekatan berbasis visual mencatat performa lebih tinggi lebih dari 14 poin persentase pada nDCG@5 dibanding pendekatan parsing tradisional
Optimasi performa dan penerapan nyata
- Kelemahan pendekatan awal adalah penurunan kecepatan akibat beban komputasi, karena arsitekturnya memerlukan pencarian vektor untuk setiap patch sehingga tidak cocok untuk puluhan juta kueri per detik
- Dengan merujuk pada paper MUVERA, diperkenalkan metode yang menggantikan pencarian multi-vektor menjadi pencarian vektor tunggal (encoding berdimensi tetap)
- Dikombinasikan dengan vector DB khusus Turbopuffer, kecepatan kueri meningkat dari 3–4 detik menjadi sekitar 30ms
- Hasilnya, pencarian jutaan dokumen kini dimungkinkan dengan kecepatan yang jauh lebih tinggi dibanding parsing teks tradisional
Bidang pemanfaatan dan API yang mudah digunakan
- Mendukung pencarian berakurasi tinggi di berbagai jenis dokumen tanpa kehilangan struktur visual dan informasi
- Dokumen keuangan dengan tabel dan grafik kompleks yang sangat penting
- Manual teknis yang berpusat pada gambar/diagram
- Ekstraksi informasi berbasis layout dari invoice dan kuitansi
- Pemahaman materi visual/data numerik dalam paper riset
- Pengenalan relasi berbasis layout dalam rekam medis
- API dibuat sangat sederhana: cukup unggah dokumen lalu ajukan pertanyaan dalam bahasa alami, misalnya permintaan seperti "tampilkan semua kontrak dengan klausul denda di atas 10 ribu dolar" dapat ditangani
Arah masa depan: kecerdasan multi-dokumen dan pemahaman yang lebih mendalam
- Kecerdasan multi-dokumen: sedang mengembangkan kemampuan referensi silang dan pelacakan informasi antar banyak dokumen
- Melampaui pencarian dokumen tunggal, sistem ini mendukung pelacakan relasi dan penalaran antar dokumen (misalnya klausul kontrak → dokumen regulasi → manual eksekusi yang saling terhubung)
- Kerangka pemahaman agen: melampaui tanya jawab sederhana dalam dokumen, menuju otomasi penalaran logis antar-chunk seperti ekstraksi klausul → verifikasi ke dokumen lain → cross-check detail
- Integrasi workflow: meningkatkan kecerdasan otomasi dokumen agar sesuai dengan proses kerja nyata, seperti membandingkan syarat antar kontrak atau melacak riwayat keputusan teknis
Keterbatasan dan target berikutnya
- Pendekatan saat ini belum mencapai kemampuan interpretasi dan penilaian kontekstual setingkat pakar
- Bagian seperti analisis mendalam oleh pakar keuangan masih belum memadai secara teknis, dan kebutuhan enterprise seperti keandalan serta kuantifikasi ketidakpastian masih memerlukan pengembangan tambahan
- Penggabungan pemahaman visual dengan knowledge graph domain, penalaran kausal, dan penyediaan metrik keandalan menjadi tantangan utama ke depan
Kesimpulan
- Dokumen perlu diperlakukan sebagai objek pengetahuan visual, dan melampaui keterbatasan parsing, pemahaman dokumen berbasis gambar adalah solusi yang lebih unggul dalam lingkungan RAG
- Morphik ingin menghadirkan standar baru dalam ekstraksi informasi dokumen, dengan sasaran otomasi workflow dokumen kompleks dan penerapan di pekerjaan nyata
- Pengalaman fitur lebih lanjut tersedia di morphik.ai
1 komentar
Komentar Hacker News
Ada beberapa masalah mendasar yang wajib dipahami orang
LLM umumnya dilatih lebih dulu pada 4k token teks, lalu diperluas ke context window yang panjang (melangkah dari 4000 ke 4001 itu mudah, tetapi ini tidak bisa dilakukan untuk gambar karena cara tokenisasinya berbeda)
Akibatnya model keluar dari distribusi, sehingga saat menangani lebih dari dua atau tiga gambar masalah halusinasi menjadi sangat parah
PDF beresolusi 1536×2048 memakai token 3~5 kali lebih banyak daripada teks, sehingga biaya inferensi naik dan jawaban menjadi lebih lambat
Jika resolusinya diturunkan, gambar menjadi buram
Ukuran asli gambar sendiri berat, jadi hanya untuk mengunduh gambar yang dibutuhkan saja sudah menambah latensi pada setiap permintaan
Pada benchmark kecil, pendekatan ini memang secara alami bekerja lebih baik daripada chunking teks dasar untuk dokumen finansial yang penuh grafik dan tabel
Secara pribadi saya ingin membandingkannya dengan pendekatan seperti Gemini yang memungkinkan anotasi gambar lewat OCR
Pendekatan gambar end-to-end masuk akal untuk kasus khusus seperti paten, diagram arsitektur, dan sejenisnya, tetapi benar-benar merupakan pilihan terakhir
LLM punya masalah membuat teks yang terdengar masuk akal pada bagian yang tidak bisa dibacanya, sehingga hasilnya bisa jadi makin kacau
Misalnya, GPT4.1 bekerja sempurna pada screenshot berukuran 1296×179, tetapi saat diperkecil 50% menjadi 650×84, model mengembalikan "Pdf's at 1536 × 2048 use 3 to 5X more tokens" sebagai "A PNG at 512x 2048 is 3.5k more tokens"
Sebagian besar memang benar, tetapi perubahan detail halus seperti ini perlu diwaspadai
Karakteristik menarik dari keluarga gemma3 adalah kebutuhan memori pemrosesannya tidak bertambah meskipun ukuran gambar input diperbesar
Karena encoder tahap kedua mengompresinya menjadi token berukuran tetap
Dalam praktiknya ini cukup berguna
Tetapi dengan begitu seluruh kumpulan dokumen yang diproses harus melewati VLM besar
Itu bisa menjadi terlalu mahal dan lambat
Jelas ada trade-off di sini
Dalam kebanyakan kasus, pendekatan saat ini adalah yang paling efektif
Ada kalanya orang memasukkan apa pun ke LLM, padahal tergantung situasinya itu bisa jadi tidak cocok
Tidak semua hal harus diproses dengan LLM
Rasanya ini bisa diperluas menjadi ide untuk mengubah pipeline RAG
Untuk setiap hasil RAG, pada tahap pemrosesan model kita bisa mengekstrak dari gambar hanya informasi yang langsung relevan dengan kueri pengguna, lalu mengumpulkan hasil (teks) itu sebagai input untuk generasi akhir
Dengan begitu kita bisa menghindari batas token banyak gambar sekaligus memparalelkan proses pemahaman gambar
Saya dan rekan-rekan pernah mencoba implementasi seperti ini 6 bulan lalu untuk sebuah lembaga pemerintah Prancis
Kami menyediakannya sebagai open source di sini: https://github.com/jolibrain/colette
Ini bukan bisnis utama kami dan sekarang hanya dibiarkan begitu saja, tetapi dengan sedikit tuning sistem ini bekerja cukup efisien
Daya tarik utamanya adalah seluruh pipeline bisa dibuat sepenuhnya dapat didiferensiasikan, sehingga viz rag dapat di-fine-tune untuk dataset tertentu
Model layout juga bisa dikustomisasi sehingga pemahaman dokumen yang presisi menjadi mungkin
Dalam banyak kasus, hambatan terbesarnya adalah perlunya evaluation set berkualitas tinggi (dan ini memang selalu menjadi hambatan)
Saya sudah melakukan banyak studi benchmarking OCR versus gambar + LLM umum: https://getomni.ai/blog/ocr-benchmark
Masalah terbesar dari pendekatan ekstraksi langsung dari gambar adalah dokumen multi-halaman
Pada satu halaman, dalam perbandingan (OCR=>LLM vs Image=LLM) pendekatan gambar langsung sedikit lebih baik, tetapi setelah melewati 5 gambar atau lebih, akurasinya turun tajam dibandingkan pendekatan OCR-first
Sebenarnya long-context recall pada teks saja sudah merupakan tantangan yang sulit, dan meskipun LLM dioptimalkan untuk itu, long-context recall pada gambar masih jauh tertinggal
Menambahkan layer transformasi kecil dari gambar langsung ke LLM juga cukup efektif (artinya alih-alih melakukan OCR langsung, kirim 5 gambar sekaligus ke model vision kecil untuk mengekstrak hanya poin-poin terpenting dokumen)
Saat ini kami sedang meneliti cara memodifikasi cache atau attention map LLM agar batch gambar yang lebih besar bisa bekerja dengan baik
Pendekatan seperti sliding window atau infinite retrieval tampak menjanjikan
Ini hanya dugaan pribadi, tetapi melihat percepatan perkembangan model multimodal, saya rasa long-context gambar sebentar lagi tidak akan lagi menjadi masalah besar
Postingan blog ini memberi poin yang bagus soal penggunaan model vision untuk retrieval, tetapi saya ingin menyoroti beberapa masalah
Document parsing adalah pekerjaan mengubah dokumen menjadi teks terstruktur seperti Markdown/JSON (atau output yang disesuaikan dengan skema saat melakukan ekstraksi)
Salah satu gunanya adalah RAG, tetapi ada banyak kegunaan lain juga
ColPali sangat bagus untuk retrieval, tetapi (setidaknya secara native) tidak bisa dipakai untuk document parsing murni
Penulis terutama hanya membahas benchmark visual retrieval
Sering kali memang bekerja lebih baik daripada OCR standar, tetapi
a. masih ada masalah akurasi long tail
b. metadata seperti confidence score, bounding box, dan sebagainya hilang
c. pipeline screenshot itu sendiri juga butuh upaya jika ingin dibuat canggih
Token gambar memang jauh lebih kuat, tetapi token teks jauh lebih murah biaya penyimpanannya, sehingga saat retrieval kita bisa melakukan kueri terhadap seluruh dokumen (bukan hanya per chunk)
(Catatan: saya adalah CEO llamaindex dan telah melakukan parsing/retrieval dengan LlamaCloud, jadi ini hanya pandangan umum saya)
Tahun lalu saya menghabiskan cukup banyak waktu membangun sistem analisis dokumen paten
Paten memuat berbagai jenis konten seperti diagram abstrak, rumus kimia, persamaan, dan lain-lain, sehingga menyiapkan data agar cocok untuk LLM benar-benar rumit
Cara paling sederhana yang saya temukan adalah mengonversi tiap halaman seperti sedang “memotret”, lalu meminta LLM menghasilkan JSON dan metadata yang menjelaskan isinya (nomor halaman, jumlah elemen visual, dan sebagainya)
Untuk gambar yang kompleks, cukup minta model mendeskripsikannya
Dengan begitu JSON tersebut bisa dengan mudah di-embed ke vector store yang diinginkan
Sulit menilai efisiensi biaya dibanding hasilnya, tetapi pendekatan ini lebih sederhana dan lebih efektif daripada yang diusulkan penulis
Misalnya, walau model sebagian besar mampu mengekstrak pasangan x, y dari grafik dengan benar, jika pengguna menunjuk x/y tertentu, model bisa saja melewatkannya
Jika pada tahap inferensi gambar ditunjukkan langsung ke model, pendekatan ini lebih efektif karena model bisa menjawab tepat apa yang ditanyakan pengguna
Satu-satunya hambatan nyata di sini adalah kualitas retrieval, dan itu masalah yang relatif kecil
Artinya, selama konteks yang tepat bisa diberikan dengan baik, sisanya dapat ditangani sendiri oleh LLM
Kalau tidak, jumlah masalah yang harus diurus seperti OCR, parsing, deskripsi gambar, dan sebagainya meningkat tajam
Namun ini juga menunjukkan bahwa peluang LLM terkonsentrasi pada pengklasifikasian ulang/pemrosesan ulang nilai yang sudah ada sebelumnya (seperti dokumen paten)
Pada era 90-00-an, perusahaan software berhasil berbisnis dengan mengubah dokumen kertas lama menjadi DB
Membuat dataset baru yang bernilai dari nol masih membutuhkan investasi dan usaha yang besar
Dari pengalaman saya, pendekatan ini kurang bagus
Bergantung pada font-nya, sulit membedakan o (huruf o) dan 0 (angka nol)
Jika dokumen (doc/xls/pdf/html) diubah menjadi gambar, informasi pembeda seperti itu hilang
Untuk nomor seri dan sejenisnya, kadang manusia pun tidak bisa membedakannya hanya dengan melihat
Karena itu, mengekstraknya dengan merender PDF sebagai gambar cukup masuk akal
Untuk format lainnya, parsing dokumen secara langsung lebih baik
Tetapi secara praktik, saat mengerjakan desain halaman, menunjukkan gambar aktual ke model jauh lebih efektif untuk debugging daripada hanya memberikan kodenya
Masalah 1 vs I dan 0 vs O memang nyata, tetapi untuk dokumen yang datanya sendiri penuh diagram/grafik, saya sering mendapati gambar saja jauh lebih mudah diproses
(Mungkin ada selection bias)
Saya sempat beberapa menit mencoba menyalin jadwal ke Gemini lalu menanyakannya, tetapi meskipun berbentuk HTML tetap tidak berhasil dengan baik
Akhirnya saya ambil screenshot, menutupi bagian yang tidak perlu dengan kotak hitam, lalu memasukkan gambar itu, dan hasilnya bekerja sangat baik
Saya penasaran karena rasanya masalah ini sudah diselesaikan oleh multimodal RAG
Saya mendapatkan hasil analisis gambar yang cukup memuaskan dengan Flash 2.5, Sonnet 3.7, dan sebagainya
Malah saya merasa ketika diberi gambar, responsnya lebih baik dibanding saat diberi teks
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Hanya saja, multivector mentah (fondasi dari multimodal RAG) sangat sulit ditangani di awal dan perhitungan kemiripannya sangat mahal, sehingga sulit di-scale up
Diperlukan quantization, konversi ke vektor tunggal (encoding dimensi tetap), optimasi indexing, dan sebagainya
Itulah tepatnya yang kami kerjakan di Morphik
Saya juga pernah mencoba memindai semua tagihan sekaligus dengan mengekstrak hanya lampiran dari kotak masuk, lalu menjalankan skrip yang mengunggahnya satu per satu agar mengekstrak “invoice: ya/tidak” serta tiap item, nama vendor, tanggal, nomor invoice, dan sebagainya
Hasilnya tingkat keterbacaannya tinggi dan panggilan LLM berjalan lebih dari 3 jam, tetapi karena otomatis saya tidak terlalu peduli
Setelah itu saya bahkan meminta LLM mencocokkannya dengan mutasi bank, dan hanya sebagian invoice yang tidak datang sebagai lampiran yang terlewat
Namun, pencocokan invoice-mutasi ini dilakukan LLM dengan cukup buruk (bahkan jika selisihnya hanya beberapa dolar, model tetap menjawab inilah mutasinya)
Jadi untuk sementara sepertinya akuntan masih dibutuhkan
Saya tidak benar-benar memperkirakan biayanya, dan saya memakai model murah seperti Claude 3.7
Saya paham ColPali itu intuitif dan kuat, tetapi tetap saja pendekatan pemrosesan dokumen punya sejumlah keunggulan