- Karmaşık belgelerden bilgi çıkarmak için kullanılan geleneksel OCR ve ayrıştırma yaklaşımları, anlamı çoğu zaman doğru biçimde koruyamıyor
- Morphik, ColPali modeli tabanlı görsel belge gömmeleri yaklaşımıyla tabloları, grafikleri ve sayfa düzeni bağlamını doğrudan anlayan bir yöntem hayata geçiriyor
- Mevcut boru hatlarına kıyasla bu yöntem, doğruluk ve bilgi korunumu açısından açık ara üstün; benchmark testlerinde %95,56'ya kadar doğruluk elde ediyor
- Ayrıca MUVERA ve Turbopuffer kullanımıyla büyük ölçekli belge aramada hız artışı sağlanmış durumda
- Gelecek hedefi ise çok belgeli akıl yürütme, iş akışı entegrasyonu ve uzman düzeyinde yorumlama gibi gerçek belge işi otomasyonu
Karmaşık belge ayrıştırmanın sınırları ve RAG'in zorluğu
- Grafiklerin, diyagramların ve tabloların iç içe geçtiği karmaşık PDF belgelerden bilgi çıkarmaya çalışırken, OCR ve ayrıştırma boru hatları istenen bilgiyi sık sık kaybediyor
- İç içe tablolar, önemli diyagramlar, yoğun açıklamalı teknik belgeler, hatta metinsiz kılavuzlar gibi gerçek senaryolarda mevcut boru hatlarının sınırları açıkça görülüyor
- Geleneksel boru hattının adımları:
- PDF'ye OCR uygulama (sayıları veya harfleri yanlış okuyabilir)
- Yerleşim algılama modeli ile tablo/diyagram ayrımı yapmaya çalışma (başarısızlık olasılığı yüksek)
- Okuma sırasını yeniden kurma (görsel akış kaçabilir)
- Diyagram başlıklarını tanıma (nüanslar sık sık kaybolur)
- Metni parçalara ayırma (ilişkili bilgiler bölünebilir)
- Vektör gömmeleri üretme ve vektör DB'ye kaydetme (konum bilgisi ve bağlam kaybolur)
- Örnek: Basit bir tablo bile
1,000 değerini l,0O0 olarak okuyabiliyor ya da tablo ile üstbilgi ayrıldığı için toplam hesaplaması başarısız olabiliyor
- Grafik lejandını gövde metni sanma, yüzde değerlerinin ilgisiz yerlere dağılması gibi gerçek bilgi kaybı vakaları sık yaşanıyor
Yeni yaklaşım: görsel tabanlı belge anlayışına geçiş
- Morphik ekibi, "Belgeyi insanlar gibi görsel bir nesne olarak anlarsak ne olur?" sorusundan hareketle dönüşüm noktasını bulmuş
- Güncel araştırmalar (ColPali) ve Vision Language Model(VLM) alanındaki gelişmeler sayesinde, görseller doğrudan gömülerek ayrıştırma veya OCR olmadan belgenin tüm bağlamı ve görsel bilgisi korunabiliyor
- Her belge sayfası yüksek çözünürlüklü görsel olarak işleniyor ve yama düzeyinde bölünerek hem görsel hem metinsel bilgiyi yansıtan gömmeler oluşturuluyor
- SigLIP-So400m Vision Transformer görsel yama gömmelerini üretirken, PaliGemma-3B dil modeli belge yapısını anlıyor
- Sorgular için (ör. "Q3 gelir trendi"), metin, grafik, tablo ve renk gibi çeşitli görsel ipuçlarını da içeren late interaction arama yöntemiyle ilgili bilgi doğru biçimde çıkarılıyor
- Belge içindeki konum, yerleşim, renk, grafik değişimleri gibi tüm görsel bilgiler korunuyor — bu, insanın belgeye tek bakışta anlam vermesine benziyor
Geleneksel ayrıştırma ile ColPali yaklaşımının karşılaştırması
- Mevcut ayrıştırma tabanlı boru hatlarında her aşamada bilgi kaybı yaşanıyor; ayrıca metin ve görsel gömmeler ayrı tutulduğu için belge içindeki mekânsal ilişkiler yorumlanamıyor
- Buna karşılık ColPali yaklaşımı, tüm bilgiyi tek bir görsel gömme uzayında birleştirerek belgenin genel anlamını ve bağlamını koruyor
- Gerçek benchmark'larda (özellikle finans belgeleri, açık veri kümeleri) Morphik (ColPali tabanlı) %95,56'ya kadar doğruluk kaydetti (mevcut LangChain+OpenAI text-embedding %72, OpenAI file search ise yalnızca %13,33)
- ViDoRe benchmark'ında görsel tabanlı yaklaşım, mevcut ayrıştırma yöntemlerine göre nDCG@5 ölçütünde 14 puandan fazla daha yüksek performans gösterdi
Performans optimizasyonu ve gerçek kullanım
- İlk yaklaşımın dezavantajı, hesaplama yüküne bağlı hız düşüşüydü; her yama için vektör araması gerektiren yapı saniyede on milyonlarca sorgu için uygun değildi
- MUVERA makalesinden yararlanılarak, çoklu vektör aramasını tek vektör aramasına dönüştüren bir yöntem (sabit boyutlu kodlama) benimsendi
- Turbopuffer odaklı vektör DB ile birleştirilince sorgu hızı 3-4 saniyeden 30ms seviyesine indirildi
- Böylece mevcut metin ayrıştırmaya kıyasla çok daha yüksek hızla milyonlarca belge üzerinde arama yapılabilir hale gelindi
Kullanım alanları ve kolay API sunumu
- Farklı belge türlerinde, görsel yapı ve bilgi kaybı olmadan yüksek doğruluklu arama desteği sunuluyor
- Karmaşık tablo ve grafiklerin kritik olduğu finans belgeleri
- Çizim ağırlıklı teknik kılavuzlar
- Fatura ve fişlerde yerleşim tabanlı bilgi çıkarımı
- Akademik makalelerdeki görsel ve sayısal materyallerin anlaşılması
- Tıbbi kayıtlarda yerleşim temelli ilişki tanıma
- API, belge yüklendikten sonra doğal dille sorgulama yapılabilen çok basit bir yapıya sahip; örneğin "10 bin doların üzerinde ceza maddesi içeren tüm sözleşmeleri göster" gibi istekleri destekliyor
Gelecek yönü: çok belgeli zeka ve daha derin anlayış
- Çok belgeli zeka: Belgeler arasında çapraz referans ve bilgi izleme işlevleri geliştiriliyor
- Tek belge aramanın ötesinde, birden çok belge arasındaki ilişkileri izleme ve akıl yürütme (ör. sözleşme maddesi → düzenleyici belge → uygulama kılavuzu bağlantısı) desteklenecek
- Ajan anlayış sistemi: Belge içinde basit soru-cevabın ötesinde, madde çıkarımı → başka belgede doğrulama → ayrıntı çapraz kontrolü gibi parçalar arası mantıksal akıl yürütmenin otomasyonu hedefleniyor
- İş akışı entegrasyonu: Birden fazla sözleşme arasındaki koşulları karşılaştırma, teknik kararların geçmişini izleme gibi gerçek iş süreçlerine uygun belge otomasyonu zekâsı geliştiriliyor
Sınırlar ve bundan sonraki hedefler
- Mevcut yaklaşım henüz uzman düzeyinde yorumlama ve bağlamsal muhakeme seviyesine ulaşmış değil
- Finans uzmanının derinlemesine yorumuna benzer alanlarda teknoloji hâlâ yetersiz; ayrıca güvenilirlik ve belirsizlik nicemlemesi gibi kurumsal gereksinimler için ek geliştirme gerekiyor
- Görsel anlayış ile alan bilgi grafiklerinin birleştirilmesi, nedensellik akıl yürütmesi ve güvenilirlik göstergeleri sunulması başlıca gelecek görevleri arasında
Sonuç
- Belgeler, görsel bilgi nesneleri olarak ele alınmalı; ayrıştırmanın sınırlarını aşan görsel tabanlı belge anlayışı, RAG ortamında daha üstün bir çözüm sunuyor
- Morphik, belge bilgi çıkarımında yeni bir standart ortaya koymayı ve karmaşık belge iş akışı otomasyonunu gerçek iş kullanımına taşımayı hedefliyor
- Ayrıntılı özellikleri denemek için morphik.ai adresi ziyaret edilebilir
1 yorum
Hacker News yorumu
İnsanların mutlaka bilmesi gereken birkaç temel sorun var
LLM'ler genelde önce 4k metin token'ı üzerinde önceden eğitiliyor, sonra daha uzun bağlam pencerelerine genişletiliyor (4000'den 4001'e gitmek kolay ama görseller farklı tokenlaştırıldığı için bu mümkün değil)
Sonuç olarak dağılım dışına çıkılıyor ve iki üç görselden fazlası işlendiğinde halüsinasyon sorunu ciddi biçimde ortaya çıkıyor
1536×2048 çözünürlüklü bir PDF, metne kıyasla 3 ila 5 kat daha fazla token kullandığı için çıkarım maliyetini artırıyor ve yanıtları yavaşlatıyor
Düşük çözünürlüğe inince görsel bulanıklaşıyor
Görseller ham boyut olarak da ağır olduğu için yalnızca gerekli görselleri indirmek bile her isteğe ek gecikme ekliyor
Küçük benchmark'larda, grafik ve tablo yoğun finans belgelerinde bunun temel metin chunking yaklaşımından doğal olarak daha iyi çalıştığı görülüyor
Ben şahsen Gemini benzeri şekilde OCR ile görsel anotasyonu yapılabilmesini ve sonuçların karşılaştırılmasını görmek isterdim
Uçtan uca görsel yaklaşımı özel durumlarda (patentler, mimari diyagramlar vb.) anlamlı olabilir ama gerçekten son çare
LLM'lerin okuyamadığı kısımlarda kulağa makul gelen metin uydurma sorunu var ve bu da sonucu daha da kötüleştirebilir
Örneğin GPT4.1, 1296×179 boyutundaki bir ekran görüntüsünde kusursuz çalıştı ama %50 küçültülüp 650×84 olarak verildiğinde "Pdf's at 1536 × 2048 use 3 to 5X more tokens" ifadesini "A PNG at 512x 2048 is 3.5k more tokens" diye geri döndürdü
Çoğunu doğru yapıyor ama böyle ince ayrıntıların değişmesi konusunda dikkatli olmak gerek
gemma3 ailesinin ilginç özelliği, giriş görselinin boyutu artsa bile işlem için gereken bellek ihtiyacının artmaması
Çünkü ikinci aşama encoder bunu sabit boyutlu token'lara sıkıştırıyor
Pratikte oldukça faydalı
Ama bunu yaptığınızda işlenen tüm belge kümesi zorunlu olarak büyük bir VLM'den geçmek zorunda kalıyor
Bu da fazla pahalı ve yavaş olabilir
Burada net bir trade-off var
Çoğu durumda mevcut yaklaşım en etkili olanıydı
İnsanlar her şeyi LLM'e koyabiliyor ama bu her durumda uygun olmayabilir
Her şeyi mutlaka LLM ile çözmek gerekmiyor
Bunun RAG pipeline'ını değiştirecek bir fikre genişleyebileceğini düşünüyorum
Her bir RAG sonucu için, model işleme aşamasında görselden kullanıcı sorgusuyla doğrudan ilgili bilgiyi çıkarıp bu (metin) sonuçları toplayarak son üretimin girdisi yapılabilir
Böylece çoklu görsellerdeki token sınırı aşılabilir ve görsel anlama süreci paralelleştirilebilir
Ben ve çalışma arkadaşlarım bunu 6 ay önce Fransız kamu kurumları için uygulamaya çalıştık
Bunu açık kaynak olarak burada paylaştık: https://github.com/jolibrain/colette
Ana işimiz bu değil ve şu an pek ilgilenmiyoruz ama biraz ayarlamayla oldukça verimli çalışıyor
Asıl güzel tarafı, tüm pipeline'ın tamamen diferansiyellenebilir hale getirilip belirli veri kümelerine özel viz rag fine-tune edilebilmesi
Layout modeli de özelleştirilerek hassas belge anlama sağlanabiliyor
Genelde en büyük engel, yüksek kaliteli bir değerlendirme setine ihtiyaç duyulması oluyor (ki bu hep bir engel)
OCR ile görsel + genel amaçlı LLM kıyaslamasına dair birçok benchmark yaptık: https://getomni.ai/blog/ocr-benchmark
Görselden doğrudan çıkarım yapmanın en büyük sorunu çok sayfalı belgeler
Tek sayfada (OCR=>LLM vs Image=LLM) karşılaştırmasında doğrudan görsel yaklaşımı az farkla daha iyiydi ama 5'ten fazla görseli geçince doğruluk, önce OCR kullanan yaklaşıma kıyasla keskin biçimde düşüyor
Aslında metinde uzun bağlam geri çağırma da zor bir problem ama LLM'ler buna göre optimize edilmiş durumda; görsel uzun bağlam geri çağırma ise hâlâ oldukça zayıf
Görselden hemen sonra küçük bir LLM dönüşüm katmanı eklemek de oldukça etkili oluyor (yani doğrudan OCR yapmak yerine, aynı anda 5 görseli küçük bir vision model'e verip belgenin en önemli noktalarını çıkarmak gibi)
Şu anda daha büyük görsel batch'lerinin iyi çalışması için LLM cache'i veya attention map'lerini değiştirmeyi araştırıyoruz
Sliding window ya da sonsuz retrieval gibi yaklaşımlar umut verici görünüyor
Kişisel tahminim, multimodal modellerdeki gelişim hızına bakınca görsel uzun bağlamın yakında büyük bir sorun olmaktan çıkacağı yönünde
Bu blog yazısı retrieval için vision model kullanımı hakkında iyi noktalara değiniyor ama birkaç soruna dikkat çekmek istiyorum
Document parsing, bir belgeyi Markdown/JSON'a (veya çıkarım içinse şemaya uygun bir çıktıya) dönüştürme işi
Bunun bir kullanım alanı RAG ama başka birçok kullanım da var
ColPali retrieval için harika ama (en azından yerleşik olarak) saf document parsing için kullanılamaz
Yazar ağırlıklı olarak görsel retrieval benchmark'larından söz ediyor
Çoğu zaman standart OCR'den daha iyi çalışıyor ama
a. hâlâ uzun kuyruk doğruluk sorunları var
b. confidence score, bounding box gibi metadata eksik kalıyor
c. ekran görüntüsü pipeline'ının kendisi de olgunlaştırılmak istenirse emek gerektiriyor
Görsel token'ları çok daha güçlü ama metin token'larının saklama maliyeti çok daha düşük olduğu için retrieval sırasında tüm belge üzerinde sorgu yapılabiliyor (chunk düzeyinde değil)
(Not: ben llamaindex CEO'suyum ve LlamaCloud ile hem parsing hem retrieval yaptım; bu sadece genel bir bakış açısı)
Geçen yıl patent belgelerini analiz eden bir sistem kurmak için epey zaman harcadım
Patentlerde soyut diyagramlar, kimyasal formüller, matematiksel ifadeler gibi çok çeşitli içerikler bulunduğundan veriyi LLM'e uygun hale getirmek gerçekten zor
Bulduğum en basit yöntem, her sayfayı adeta "fotoğrafını çekmiş" gibi dönüştürüp ardından LLM'den içeriği açıklayan bir JSON ve metadata (sayfa numarası, görsel öğe sayısı vb.) üretmesini istemekti
Karmaşık görselleri de modele tarif ettirebilirsiniz
Böylece ortaya çıkan JSON'u istediğiniz vector store'a kolayca embed edebilirsiniz
Maliyet-etkinliği değerlendirmek zor ama bu yaklaşım, yazarın önerdiğinden daha basit ve daha etkiliydi
Örneğin model bir grafikten x, y çiftlerinin çoğunu doğru çıkarsa bile kullanıcı belirli bir x/y değerini sorarsa bunu atlayabilir
Görseli doğrudan modelin çıkarım aşamasında gösterirseniz, kullanıcı ne sorarsa ona tam karşılık verebilir; bu yüzden bu yaklaşım daha etkili
Buradaki tek gerçek engel retrieval kalitesi ve bu nispeten küçük bir sorun
Yani uygun bağlamı iletmek yeterince iyi yapılırsa gerisini LLM halleder
Aksi halde OCR, parsing, görsel betimleme gibi çözülmesi gereken sorunlar hızla çoğalıyor
Ama aynı zamanda LLM fırsatının mevcut değeri (örneğin patent belgeleri) yeniden sınıflandırma / yeniden işleme alanlarında yoğunlaştığını gösteriyor
90'lar ve 2000'lerde yazılım şirketleri mevcut kâğıt evrakı veritabanına çevirerek başarılı oldu
Sıfırdan yeni ve değerli veri kümeleri oluşturmak ise hâlâ ciddi yatırım ve emek gerektiriyor
Deneyimime göre bu yaklaşım pek iyi değil
Fonta bağlı olarak o harfi ile 0 rakamını ayırt etmek zor
Belgeyi (doc/xls/pdf/html) görsele çevirdiğinizde bu ayrım bilgisi kayboluyor
Seri numarası gibi şeylerde insanlar bile bazen bakıp ayırt edemeyebilir
Bu yüzden PDF için görsel render alıp oradan çıkarmaya çalışmak oldukça makul
Diğer formatlarda ise belgeyi doğrudan parse etmek daha iyi
Yine de pratikte sayfa tasarımı yaparken gerçek görseli modele göstermek, yalnızca kodu vermekten çok daha etkili bir debug yöntemi oluyor
1 ile I, 0 ile O sorunu gerçekten var ama verinin kendisinde diyagram ve grafik yoğunluğu yüksek belgelerde yalnızca görsellerle çok daha kolay ilerlediğim çok oldu
(Burada seçim yanlılığı olabilir)
Gemini'ye bir programı kopyalayıp sorgulatmaya dakikalarca uğraştım ama HTML olsa bile düzgün çalışmadı
Sonunda ekran görüntüsü alıp gereksiz kısımları siyah kutularla kapatıp görsel olarak verince çok iyi çalıştı
Multimodal RAG ile bu sorunun zaten çözülmüş gibi görünmesi nedeniyle merak ediyorum
Flash 2.5, Sonnet 3.7 gibi modellerle görsel analizde oldukça tatmin edici sonuçlar aldım
Hatta metne kıyasla görsel verdiğimde daha iyi yanıtlar aldığımı hissediyorum
https://www.youtube.com/watch?v=p7yRLIj9IyQ
Ancak ilk hâliyle multivektor yaklaşımı (multimodal RAG'in temeli) kullanması çok zor ve benzerlik hesapları çok pahalı olduğu için ölçeklenmesi güç
Quantization, tek vektöre dönüştürme (sabit boyutlu encoding), indexing optimizasyonu gibi şeyler gerekiyor
Morphik'te yaptığımız iş tam da bu
Ben de tüm faturaları topluca taramaya çalıştım; posta kutumdan ekleri çıkarıp tek tek yükleyen bir script çalıştırdım ve her belge için "fatura: evet/hayır" ile birlikte satır kalemlerini, satıcı adını, tarihi, fatura numarasını vb. çıkarmasını istedim
Sonuçta okuma başarısı yüksekti ve LLM çağrıları 3 saatten fazla sürdü ama otomasyon olduğu için önemsemedim
Sonrasında banka ekstreleriyle eşleştirmeyi de LLM'e yaptırdım; yalnızca ek olarak gelmeyen bazı faturalar kaçtı
Ama fatura-ekstre eşleştirmesini LLM oldukça kötü yaptı (birkaç dolarlık fark olsa bile bunu aynı ekstre diye işaretliyordu)
Bu yüzden şimdilik hâlâ bir muhasebeciye ihtiyaç var gibi görünüyor
Maliyeti çok dikkatli hesaplamadım; Claude 3.7 gibi ucuz bir model kullandım
ColPali'nin sezgisel ve güçlü tarafını anlıyorum ama yine de belge işleme yaklaşımının kendi avantajları var