Unlimited OCR — Model parsing dokumen panjang one-shot dari Baidu

 (github.com/baidu)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Model OCR E2E berbasis DeepSeek OCR yang mengganti seluruh attention pada decoder, sehingga dapat mentranskripsi dokumen puluhan halaman dalam satu kali forward pass
  • Intinya adalah Reference Sliding Window Attention (R-SWA), yang menjaga KV cache tetap konstan meski panjang decoding bertambah, sehingga kenaikan biaya memori dan komputasi dapat dicegah
  • Meniru working memory manusia saat menyalin buku, dengan melupakan keluaran yang jauh secara halus dan hanya merujuk ke konteks yang berdekatan
  • Di OmniDocBench v1.5 meraih 93%, unggul 6% dibanding DeepSeek OCR, dan di v1.6 mencapai 93.92% untuk meraih SOTA end-to-end
  • R-SWA adalah mekanisme attention parsing umum yang dapat diterapkan bukan hanya pada OCR, tetapi juga pada tugas panjang berbasis referensi seperti ASR dan terjemahan

Latar belakang dan definisi masalah

  • Manusia dapat mengerjakan tugas panjang seperti mentranskripsi ratusan halaman atau menerjemahkan audio berjam-jam tanpa penurunan efisiensi, tetapi model OCR yang ada bahkan tidak mampu mem-parsing 10 halaman dalam satu forward pass
    • Model saat ini memproses per halaman dengan cara for-loop, dan menginisialisasi ulang memori di setiap langkah
    • Pendekatan ini hanyalah jalan memutar rekayasa yang memecah proses panjang yang konsisten menjadi tugas-tugas jangka pendek yang terisolasi, bukan kemajuan menuju kecerdasan berorientasi AGI
  • Jika memakai LLM sebagai decoder, kinerja meningkat karena memanfaatkan prior bahasa, tetapi semakin panjang output, KV cache yang terakumulasi akan memperbesar konsumsi memori dan secara bertahap memperlambat kecepatan generasi
  • Perilaku transkripsi manusia bukan full attention standar maupun linear attention
    • Manusia tidak menelusuri ulang seluruh teks yang sudah ditulis, melainkan hanya merujuk ke konteks yang berdekatan untuk menjaga arah
    • Token visual/referensi tidak mengalami pembaruan state secara rekursif — jika diperbarui, fitur visual akan makin kabur secara bertahap sehingga akurasi pengenalan menurun

Reference Sliding Window Attention (R-SWA)

  • Setiap token dapat mengakses semua token referensi (token visual + prompt), sementara attention output dibatasi hanya pada n token sebelumnya (default 128)
    • Dengan ini, setiap token tetap memahami keseluruhan gambar sambil secara mandiri melacak progres OCR melalui transisi state di dalam jendela geser kausal
    • Saat inferensi, KV cache dijaga tetap konstan untuk mengurangi tekanan memori dan menekan biaya komputasi
  • Attention dibatasi ke jendela dua segmen berukuran m+n
    • m adalah jendela prefix yang mencakup token visual dan prompt, bersifat tetap selama satu inferensi dan hanya bergantung pada jumlah halaman serta resolusi, tidak pada panjang decoding
    • n adalah jendela untuk area decode, dengan ukuran tetap yang bergeser secara kausal

  • Manajemen KV cache

    • Baseline DeepSeek OCR memakai MHA standar sehingga ukuran KV cache bertambah tanpa batas menjadi Lm + T
    • R-SWA mempertahankan seluruh cache prefix Lm, tetapi untuk hasil generasi hanya menyimpan n token terbaru, sehingga ukuran cache menjadi Lm + min(n,T) ≤ Lm + n sebagai batas konstan
    • Jika panjang output cukup besar, rasio cache ρ(T) akan konvergen ke 0 → pertumbuhan linear dipangkas menjadi konstan

  • Analisis kernel

    • Dalam pengukuran kernel Flash Attention v3, MHA standar pada DeepSeek OCR menunjukkan latensi yang meningkat di setiap langkah decoding, sedangkan Unlimited OCR menjaga durasi tetap berkat R-SWA
    • Pada DeepSeek OCR, ketika panjang KV cache melewati batas alignment tertentu, efisiensi transfer data turun tajam dan memunculkan spike; hal ini tidak terjadi pada R-SWA
    • Memori GPU saat inferensi juga meningkat linear pada model asli, sedangkan Unlimited OCR tetap stabil — kestabilan komputasi dan memori secara bersamaan inilah yang memungkinkan parsing dokumen panjang

Arsitektur model

  • Menggunakan DeepSeek OCR sebagai baseline, dengan gabungan DeepEncoder dan decoder MoE (total 3B, parameter aktif 500M)
    • MHA lama diganti dengan R-SWA, dan parsing dokumen panjang diwujudkan dengan menambahkan buffer KV output berkapasitas tetap n ke cache KV referensi tetap m
    • KV cache diimplementasikan sebagai antrean berkapasitas m+n; setiap kali token baru dihasilkan, KV token ke-(m+1) dikeluarkan untuk menjamin biaya dan memori tidak bertambah

  • DeepEncoder

    • Mengaskadekan SAM-ViT dan CLIP-ViT, lalu menerapkan kompresi token 16x di bridge — bagian awal memproses token gambar asli dengan window attention, sedangkan global attention hanya untuk token terkompresi
    • Menjaga activation tetap rendah saat mengenkode gambar resolusi tinggi untuk menghemat memori GPU, dan mengompresi gambar PDF 1024×1024 menjadi hanya 256 token
    • Mengadopsi dua mode: "Base" untuk multipage (1024×1024) dan "Gundam" untuk halaman tunggal (resolusi dinamis)
    • Token visual dikodekan sekali dan tetap statis sepanjang proses, tanpa mengalami transisi state bersama output

Pengaturan pelatihan

  • Dilatih dengan sekitar 2 juta data OCR dokumen, dengan rasio halaman tunggal vs multipage 9:1
    • PDF satu halaman dianotasi menggunakan Paddle OCR, lalu koordinat dan isi setiap blok digabung untuk membentuk ground truth, dengan koordinat dinormalisasi ke rentang 0–1000
    • Data multipage disintesis dengan menggabungkan halaman tunggal, sekitar 200 ribu sampel (2–50 halaman) memakai pemisah <page>, lalu dipacking ke dalam urutan 32K token penuh
  • Tambahan pelatihan 4.000 langkah dari checkpoint DeepSeek OCR, global batch 256, urutan maksimum 32K, menggunakan 8×16 A800 GPU
    • Selama pelatihan, DeepEncoder dibekukan dan hanya parameter LLM yang dilatih
    • Berbasis framework AdamW optimizer, cosine annealing scheduler, learning rate awal 1e-4, DeepEP(EP=4), dan Megatron-LM
    • Untuk inferensi, manajemen KV cache untuk R-SWA diimplementasikan di library Transformers, dengan dukungan optimasi pada engine SGLang — kedua framework berjalan dengan TPS dan memori GPU yang konstan

Hasil evaluasi

  • Benchmark utama adalah OmniDocBench(v1.5/v1.6), yang mengevaluasi kemampuan parsing multidimensi seperti teks, rumus, struktur tabel, dan urutan baca
    • v1.6 adalah versi terbaru dengan tambahan 296 gambar uji dibanding v1.5, sedangkan v1.5 menyediakan perbandingan dengan model klasik termasuk DeepSeek OCR
    • Juga dibangun test set internal untuk evaluasi OCR dokumen panjang, membagi novel, dokumen, dan makalah ke kategori 2/5/10/20/40+ halaman (masing-masing lebih dari 10 buku per kategori)

  • Kinerja utama

    • Hanya dengan tambahan pelatihan 2M data, model mencapai SOTA end-to-end; di v1.5 jarak edit teks turun 0.035, dan TEDS tabel naik 5.96%
    • Metrik gabungan v1.6 mencapai 93.92% untuk SOTA end-to-end — membuktikan bahwa mengganti seluruh attention standar dengan R-SWA lebar 128 tetap efektif dan tanpa kehilangan kualitas
    • Inferensi sangat efisien dengan 0.5B parameter aktif MoE; di mode "Base" mencapai 5580 TPS (peningkatan kecepatan 12.7% dibanding 4951 TPS pada DeepSeek OCR)

  • Analisis subkategori

    • Menunjukkan peningkatan yang konsisten di semua metrik dibanding DeepSeek OCR, setara peningkatan tingkat "free lunch"
    • Dibanding DeepSeek OCR 2, unggul pada 7 dari 9 kategori untuk jarak edit teks dan urutan baca
    • Tidak kalah bahkan pada layout kompleks seperti PPT, surat kabar, majalah, dan catatan

  • Parsing dokumen panjang

    • Dengan R-SWA, puluhan hingga ratusan halaman dapat diprefill dalam satu pass, lalu diparsing terus-menerus dari halaman pertama hingga akhir sambil menjaga KV cache tetap tetap sehingga latensi output stabil
    • Tetap tangguh bahkan saat 20 halaman dimasukkan sekaligus, dan pada 40+ halaman mempertahankan jarak edit di bawah 0.11 serta Distinct-35 97%
    • Error repetisi berasal dari kesulitan mode multipage "Base" (1024×1024) dalam membedakan teks kecil, bukan karena R-SWA kehilangan arah

Analisis efisiensi

  • Perbandingan TPS output dalam kondisi konkurensi ideal (panjang prefill tetap 10)
    • Pada 256 token, kecepatan inferensi kedua model hampir sama
    • Saat panjang output bertambah, TPS DeepSeek OCR terus menurun, dan pada 6.000 token tertinggal 35% dari Unlimited OCR
    • Ini menegaskan kembali bahwa kecepatan generasi yang konsisten adalah kebutuhan inti untuk tugas OCR dokumen panjang

Keterbatasan dan tugas ke depan

  • Dengan panjang konteks yang terbatas (misalnya 32K), parsing yang benar-benar tak terbatas belum dimungkinkan karena ada batas panjang prefill — meskipun rasio kompresi DeepEncoder tinggi, prefill tetap memanjang seiring akumulasi halaman
  • Dalam jangka pendek, direncanakan pelatihan model berkonteks lebih panjang seperti 128K untuk mendukung prefill lebih banyak halaman
  • Dalam jangka panjang, tujuannya adalah membangun prefill pool, melatih model agar otomatis mengambil chunk KV prefill untuk meniru efek manusia membalik halaman, sehingga dapat mencapai OCR yang benar-benar tak terbatas
  • Ada rencana menerapkan R-SWA ke tugas berbasis referensi lain seperti ASR dan terjemahan

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Cukup menarik. Dari yang saya pahami, sepertinya para peneliti menemukan semacam rekayasa arsitektur yang mencegah AI terus menumpuk memori saat membaca dokumen panjang
    Biasanya, ketika AI mentranskripsikan PDF 100 halaman, ia berusaha mengingat semua kata yang sudah dibaca, dan memori jangka pendek ini, yaitu cache KV, bertambah linear sebagai O(N) sehingga VRAM habis atau mentok batas. Karena itu, pengembang akhirnya membuat kode kasar yang memecah PDF per halaman untuk diproses lalu menggabungkannya lagi
    Unlimited OCR membagi fokus menjadi dua jalur dengan Reference Sliding Window Attention (R-SWA). Satu adalah referensi global yang melihat gambar dokumen asli secara utuh, dan yang lain adalah generasi lokal yang membatasi memori teks buatan model sendiri ke jendela geser sempit seperti 128 kata terakhir. Ini tampaknya cukup menarik untuk AI lokal, dan saya penasaran apa yang akan dibuat dan dikembangkan komunitas

    • Sepertinya ada kecocokan yang pas juga untuk percakapan. Sudah cukup lama saya bereksperimen dengan enkapsulasi percakapan panjang, di mana ada konteks tingkat atas dan fakta yang tidak banyak berubah, termasuk hal-hal seperti nama peserta atau latar belakang mereka
      Sebaliknya, fakta yang sangat rinci seperti apa yang dimakan pagi ini mungkin berguna sekarang, tetapi dalam jangka panjang tidak terlalu berarti selain kecenderungan umum. Untuk merekonstruksi percakapan, kita perlu menemukan keseimbangan yang tepat tanpa menarik semua yang sudah dibahas sejauh ini, jadi pendekatan ini tampaknya layak ditelaah lebih lanjut
    • Saya belum membaca seluruh makalahnya, tetapi jendela generasi lokal tampak agak kecil. Khususnya karena input gambar memakai banyak token, jadi tergantung di mana lapisan perhatian lokal ditempatkan, akan lebih baik jika ukurannya lebih besar, setidaknya sekitar 4096 kata
    • Saya melakukan persis seperti ini saat OCR gambar. Jika satu gambar besar dipotong menjadi beberapa gambar kecil lalu dikirim ke LLM, hasilnya selalu sempurna, tetapi saat memasukkan gambar utuh, hasilnya sangat buruk
    • Saya kira alat-alat LLM utama sudah mendukung sliding window attention
    • Itulah kenapa LeetCode berguna. Karena terus mengerjakan LeetCode, saya jadi melihat kenapa teknik-teknik seperti ini ada dan bagaimana penerapannya di dunia nyata. Banyak hal yang menarik

  • Baru-baru ini saya membeli tablet untuk partitur, terutama untuk menggantikan kumpulan jazz Real Book saat jam session. Hasil scan dengan kamera ponsel lumayan oke, tetapi ukurannya tetap dan banyak noda visual.
    Akan bagus kalau bisa langsung transpose untuk instrumen Bb atau Eb, tetapi karena itu hasil scan, tentu saja tidak mungkin. Setelah menelusuri kondisi optical music recognition, saya sampai pada kesimpulan bahwa musik hampir merupakan wilayah yang belum tergarap dari sudut pandang AI. Optical music recognition cukup buruk, dan pemahaman AI terhadap teori musik juga buruk dalam ranah melihat partitur nyata. LLM lumayan bagus dalam penjelasan teks tentang konsep teori yang kemungkinan besar masuk ke pelatihan dari teks online.
    Masalahnya tampaknya adalah masih kurangnya format digital yang benar-benar dapat mengodekan titik-titik di atas kertas yang dibaca para musisi. Notasi musik cukup kaya. MIDI dibuat terutama untuk memuat aspek yang dibutuhkan untuk playback atau performa, jadi tidak memuat semua yang diperlukan untuk pemahaman simbolik. MusicXML tampak paling dekat dengan format digital yang memuat informasi yang diinginkan musisi, tetapi kurang ada korpus pelatihan yang bagus yang menghubungkan representasi MusicXML dengan gambar partitur atau audio. Tampaknya karena MusicXML saja tidak cukup memuat informasi yang dibutuhkan untuk tata letak partitur.
    Alat seperti MuseScore harus melacak banyak informasi tata letak yang tidak bisa direpresentasikan dengan MusicXML. Format LilyPond kurang bertele-tele dibanding MusicXML dan memuat sedikit lebih banyak informasi yang berguna bagi pembuat partitur, tetapi kebanyakan orang tidak membuat partitur dengan LilyPond. Tambahan lagi, kondisi font jazz di LilyPond mengecewakan. Dalam konteks jazz, saya tidak suka melihat partitur yang terasa “bergaya klasik”. Setiap kali melihat peningkatan incremental yang tampak cukup bagus pada OCR, saya jadi teringat betapa mengenaskannya OMR.

    • Format yang digunakan para musikolog dan peneliti musik adalah MEI: https://music-encoding.org/ dan engraver acuannya adalah verovio: https://www.verovio.org/index.xhtml
      verovio dapat mengukir ke format SVG sambil mempertahankan sebanyak mungkin informasi dari partitur MEI asli, sehingga metadata yang cukup untuk membuat dataset deteksi nyata bagi model deep learning bisa diekstrak. Ada juga skrip hack kasar untuk membuat dataset COCO dari sekumpulan partitur yang diukir dengan verovio: https://github.com/kwon-young/music/blob/main/svg2pl.py
      Dataset partitur sintetis yang dibuat di sini juga sudah dipublikasikan: https://www.kaggle.com/datasets/kwonyoungchoi/trompa-coco/da... Siapa pun yang ingin mencoba melatih detektor di atasnya dipersilakan. Alasan OMR dibiarkan terbengkalai seperti ini adalah karena kebanyakan orang sangat meremehkan tingkat kesulitan pekerjaan ini. Ini adalah tugas khusus yang mencampurkan bentuk yang sangat beragam dan tata bahasa grafis yang sangat kompleks.
    • Pernyataan bahwa “musik hampir sepenuhnya wilayah yang belum tergarap bagi AI” memang benar sekali. Pacar saya belajar musikologi, dan karena disabilitas fisik kadang sulit mencatat, saya sedikit demi sedikit membuatkan aplikasi seperti TTS/OCR berbasis AI untuk membantunya.
      Dalam prosesnya, jadi terasa sangat jelas, sampai menyakitkan, bahwa musik tidak pernah dianggap sebagai bagian penting dalam dataset pelatihan AI mana pun. Belakangan kemampuan Opus 4.8 untuk memahami dan menjelaskan teori musik cukup mengagumkan, tetapi kalau diminta menyalin partitur atau melakukan OCR/OMR, ia dengan percaya diri menghasilkan versi MusicXML/LilyPond setara “2 + 2 = kuda”. Saya berharap ranah yang diabaikan ini ikut tersapu gelombang AI yang makin besar, tetapi untuk saat ini ia masih diremehkan secara tidak adil.
    • Jika yang dibutuhkan hanya analisis chord, ada notasi Harte yang bertujuan merepresentasikan nada tanpa ambigu: https://ismir2005.ismir.net/proceedings/1080.pdf
      Tentu saja ini tidak memberi semua informasi tambahan yang dibutuhkan untuk engraving atau representasi musik secara keseluruhan, tetapi ada dataset riset seperti https://github.com/smashub/choco. Untuk pekerjaan analisis, saya juga pernah memakai dataset https://github.com/MarkGotham/When-in-Rome, tetapi ini juga tidak 100% cocok dengan yang dicari. Untuk mengganti jazz standard di tablet dan kebutuhan transpose, Anda mungkin akan menyukai aplikasi “iReal Pro”. Untuk use case itu, aplikasinya cukup bagus dibanding scan kamera.
    • Bagaimana dengan format engraving partitur seperti https://abcnotation.com/?
    • Kalau mengikuti ranah OCR musik, sejauh ini sepertinya satu-satunya solusi yang benar-benar cukup bagus adalah soundslice. Setelah scan lalu meninjau beberapa edge case saja, hasilnya sangat bagus. Ini layanan berbayar dari perusahaan kecil, tetapi sangat layak didukung.

  • Menulis “Terima kasih kepada model dan ide berharga dari Deepseek-OCR, Deepseek-OCR-2, dan PaddleOCR” adalah sikap yang berkelas.

    • Saya tidak paham kenapa itu disindir.

  • Sebagai referensi, “Unlimited OCR Works” adalah parodi dari Unlimited Blade Works dari Fate/stay night. Dalam karya aslinya, Unlimited Blade Works adalah sihir dengan konsep menyalin senjata buatan orang lain.

  • Makalahnya ada di https://arxiv.org/abs/2606.23050
    Sebagai catatan, saya juga melakukan OCR lokal untuk kebutuhan RAG kecil atas kutipan yang saya baca di buku, dan saya juga membagi input menjadi chunk untuk menghemat RAM, jadi menarik bahwa pendekatan yang alami seperti ini juga berhasil pada model streaming.

  • Ini terlihat lebih menjanjikan daripada yang baru saja dirilis Mistral. Kebetulan? Rasanya tidak.
    Pendekatan ini juga tampaknya bisa dipakai dalam beberapa kombinasi untuk generasi gambar. Sepertinya memungkinkan untuk mulai menggambar ke alat seperti Illustrator/Inkscape atau ke SVG setelah membaca atau melihat gambar, lalu mengisi bagian yang hilang nanti.

  • Saya penasaran bagaimana ini dibandingkan dengan infinty parser 2, yang tampaknya mengungguli alat OCR lain: https://huggingface.co/datasets/allenai/olmOCR-bench
    Kalau mau adil, memang tidak ada benchmark OCR dengan satu pemenang mutlak, dan alat ini juga belum muncul di mana pun.

  • Mungkin aku terdengar seperti orang yang tidak paham dunia nyata, tetapi apa sebenarnya alasan perusahaan merilis perangkat lunak yang sangat bagus sebagai open source?
    Kalau Baidu atau Google, bukankah seharusnya mereka menyimpannya sendiri agar pesaing tidak bisa meniru dan mereka bisa mengekstrak nilainya?

    • Bahkan di dalam perusahaan besar ada orang-orang yang percaya pada ideal open source dan berhasil meyakinkan pemberi kerja mereka untuk mengizinkan proyek dirilis
      Perusahaan mendapat reputasi, dan itu membantu funnel rekrutmen. Kadang ini juga bisa menjadi langkah strategis untuk mengguncang pesaing, seperti ketika Meta merilis Ollama
    • Merilis model open source bisa menggerus pendapatan lab AI di AS. Jika itu mengurangi uang yang bisa mereka investasikan kembali untuk menang dalam persaingan jangka panjang, hal itu bisa menguntungkan China

  • Setiap upaya OCR dengan AI yang pernah kucoba selalu tercampur hasil halusinasi, jadi sulit dipakai di produksi. Aku penasaran apakah ini juga punya masalah seperti itu
    Contoh sederhananya, kata-kata yang seharusnya tetap dalam bahasa lain malah otomatis diterjemahkan ke bahasa Inggris sehingga merusak hasilnya

    • Aku jadi tidak menginginkan machine learning di tingkat yang lebih besar daripada kata, yaitu pada level pasangan kata, frasa, kalimat, dokumen, atau korpus
      Dalam transkripsi, yang diinginkan hampir selalu adalah hasil yang pasti benar, atau penanda yang jelas bahwa teksnya memang tidak bisa dibaca. Menebak dari konteks memang bisa, tetapi pada OCR tertentu kita perlu tahu apakah tebakan itu didasarkan pada sesuatu selain fakta bahwa huruf-huruf tersusun berurutan membentuk kata
      Misalnya, pada dokumen sensus di familysearch.com, seorang penyalin “mengoreksi” nama menjadi Joseph, padahal huruf yang benar-benar tertulis di dokumen tulisan tangan itu adalah Josepth, dan itu memang varian ejaan lokal. Di dokumen lain, penulis menyingkat “Joh”, dan kemungkinan penyalin manusialah yang mengubahnya menjadi John; itu memang tebakan yang paling masuk akal, tetapi sebenarnya salah. Kadang penting untuk tahu bahwa itu hanyalah tebakan, dan kadang yang dibutuhkan hanyalah tebakan terbaik
    • Jika menginginkan hasil pengenalan 100%, aku akan menggabungkan metode ini dengan model gambar rekonstruksi dokumen asli. Caranya adalah menyelaraskan teks transkripsi dan layout untuk membangun ulang dokumen aslinya
      Jika menggunakan seluruh dokumen kecuali halaman atau paragraf yang sedang diuji, kita bisa menghindari regenerasi frasa yang diuji secara mentah dari artefak gambar. Setelah rekonstruksi, lakukan perbandingan optik untuk mencocokkan karakter yang tidak selaras, lalu cari kesalahan dan ulangi prosesnya. Mahal, tetapi bisa menjamin pengenalan 100%
    • Aku sedang mencoba mentranskripsikan PDF tata bahasa Jepang dengan model ini di 4090. Dokumennya ditulis dalam bahasa Inggris dan berisi banyak contoh kalimat Jepang, dan sejauh yang sempat kucek sebagian, hasilnya bekerja cukup baik
      Output-nya mempertahankan kanji/hiragana dan bahasa Inggris di tempat yang memang diperlukan, dan tidak mencoba menerjemahkannya. Kecepatannya sekitar 200 halaman per jam
    • Penasaran model atau alat apa saja yang sudah pernah dipakai

  • Aku tidak tahu bagaimana kabar Reducto. Sekitar 12–15 bulan lalu, itu terlihat cukup menjanjikan