- PDF dosyalarından metin çıkarma beklenenden çok daha zordur ve PDF özünde grafik tabanlı bir dosya biçimidir
- PDF içinde yalnızca glif konum bilgileri bulunur ve anlamsal sinyal neredeyse yoktur; bu da metni tanımlama ve yeniden kurmayı zorlaştırır
- Arama motorları HTML biçiminde temiz girdi ister, ancak mevcut açık kaynak araçlar başlık veya paragraf gibi yapısal bilgileri çıkarmakta sınırlıdır
- Makine öğrenmesi tabanlı görsel yaklaşımlar en doğru sonucu verir, ancak kaynak ve performans sorunları nedeniyle geniş ölçekte uygulamak zordur
- Başlıca iyileştirme yöntemi olarak, yazı tipi boyutu ve istatistik tabanlı başlık/paragraf tanımlama algoritmaları kullanılarak çıkarım doğruluğu artırılır
PDF’den metin çıkarmanın zorlukları
- Modern arama motorları PDF dosya biçimini indeksleyebilir hale gelmiştir
- PDF’den bilgi çıkarmak kolay değildir; bunun nedeni PDF’nin aslında metin biçimi değil, grafik biçimi olmasıdır
- Gerçek metin yerine koordinatlara yerleştirilmiş glifler bulunduğundan, döndürme, üst üste binme, sıra karışması ve anlam bilgisinin eksikliği gibi sorunlar ortaya çıkar
- Genelde metin olarak düşündüğümüz bilgi, dosyanın içinde doğrudan mevcut değildir
- PDF görüntüleyicide
ctrl+f ile metin araması yapılabilmesi aslında hayret vericidir
Arama motorlarının gereksinimleri ve temel yaklaşımın sınırları
- Arama motorlarının en çok tercih ettiği girdi temiz HTML biçimidir
- En iyi performansı modern makine öğrenmesi tabanlı bilgisayarlı görü modelleri gösterir, ancak
- büyük hacimli (yüzlerce GB) PDF dosyalarını GPU olmadan tek bir sunucuda işlemek verimsizdir
- Neyse ki bu alan tamamen bilinmeyen bir alan değildir;
- başlangıç noktası olarak PDFBox'ın PDFTextStripper sınıfı kullanılabilir
- ancak başlık gibi anlamsal yapıları neredeyse hiç anlayamaz — yalnızca dizgeleri çıkarır
Başlık tanımlama algoritması
Başlık tanımlamanın temel ilkesi
- Genelde başlıkların semi-bold ya da daha kalın yazıyla ve izole şekilde yer almasından yararlanılabilir
- kalın olmayan başlıklar da yaygın olduğundan, yalnızca bu yöntem yeterli değildir
- Çoğu durumda, yazı tipi boyutu başlıkları ayırmak için temel ölçüttür
- ancak yazı tipi boyutu her belgede tamamen farklıdır ve küresel eşik değeri kullanmak mümkün değildir
Yazı tipi boyutu istatistiklerinden yararlanma
- Her sayfada genelde baskın bir yazı tipi boyutu (gövde metni) bulunur
-
- sayfa (kapak), açıklayıcı içerik ve yazar bilgileri içerdiği için yazı tipi boyutu dağılımı farklıdır
- Sayfa bazında yazı tipi boyutu dağılımı farklı olduğundan, belgenin tamamı yerine sayfa düzeyinde istatistik kullanmak etkilidir
- Her sayfanın medyan yazı tipi boyutuna yaklaşık %20 artış uygulayarak başlıklar oldukça doğru biçimde saptanabilir
Çok satırlı başlıkları birleştirme sorunu
- Biçemsel nedenlerle başlıklar birden çok satıra bölünebilir
- başlıkların ne zaman birleştirileceğine karar vermek kolay değildir; iki ya da daha fazla satırlı başlıklar, yazar adları ve ayrı vurgulu metinler iç içe bulunabilir
- Birleştirme kuralları:
- aynı yazı tipi boyutu ve kalınlığa sahip ardışık satırları birleştirmek oldukça iyi çalışır
- ancak çok sayıda istisna vardır — kontrolsüz birleştirme alakasız sonuçlara yol açabilir
Paragraf tanımlamayı iyileştirme
- PDFTextStripper paragrafları satır aralığı ve girintiye göre tanımlar
- satır bazlı ayırma eşiği sabit değer olarak kullanıldığı için, belgeye göre değişen satır aralıklarını uygulamakta sınırlıdır
- özellikle makale taslaklarında/ön baskılarda 1.5~2 kat satır aralığı da yaygındır
- Eşik değer çok büyük olursa, başlıkların gövde metnine dahil edilmesi hatası ortaya çıkar
İstatistik tabanlı paragraf ayrımı
- Yazı tipi boyutunda olduğu gibi, satır aralığı için de istatistiksel işlem uygulanır
- satırlar arasındaki mesafenin ortanca değeri (medyan) kullanılarak, her türlü satır aralığında sağlam paragraf ayrımı yapmak mümkündür
Sonuç
- PDF’den metin çıkarmak, doğası gereği kusursuz olamayacak bir iştir
- çünkü PDF biçiminin kendisi bu amaç için tasarlanmamıştır
- Gerçek uygulamada ödün vermek kaçınılmazdır ve “yeterince iyi” sonuç elde etmeye yönelik strateji önemlidir
- Arama motorları için başlıklar, özetler ve temel yapısal ipuçları gibi anlamlı sinyalleri çıkarmaya odaklanmak daha verimlidir
Örnek referans metin
- Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
: Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
- The theory of ideas and Plato’s philosophy of mathematics (2019)
: Dembiński, B.
- The role of phronesis in Knowledge-Based Economy (2024)
: Anna Ceglarska, Cymbranowicz Katarzyna
1 yorum
Hacker News yorumu
İnsan hayatta bir şeyin yeni ve ilginç olduğunu düşünüp sonra geçmişte aylarca ya da yıllarca uzmanlaştığı bir şeyi belli belirsiz hatırladığı bir deneyim yaşayabiliyor. Hatta gerçekten harika şeyler yaptığı anların bile zihninden silinmiş gibi olup yeniden en baştan başlıyormuş hissi veriyor. Yaklaşık 6-7 yıl önce PDF ve OCR ile oldukça etkileyici bir şeyler yaptığım yönünde muğlak bir anım var. Google'da arayınca “tesseract” adı tanıdık geldi
2006 civarında, erken dönem hacklenebilir e-reader iRex'te çok sütunlu bilimsel makalelerden metin kopyalayamamak sinir bozucuydu. O zaman kullanılan PDF görüntüleyici poppler olduğu için, çok sütunlu belgelerde okuma sırasını tahmin edecek şekilde poppler'ı değiştirdim. Bunun için tesseract'ın yazarı Thomas Breuel'in OCR algoritmasını referans aldım. Bu bir tür sezgisel hack'ti ve erişilebilirlik API'leriyle pek uyumlu değildi. Çok sütunlu seçim özelliği eklendi ama bakımcıları ikna etmekte zorlandım. Her neyse, sonuçta kpdf'e çok sütunlu seçim özelliği geldi. Bugün olsa bu tür kullanım için doğrudan tesseract kullanmanın çok daha mantıklı olduğunu düşünürdüm
PDF adlı format yüzünden insanlığın boşa harcadığı onlarca yılı geri getiremeyiz. Bu çılgınlığın ne zaman biteceğini merak ediyorum
Tesseract bir dönem en iyi açık kaynak OCR'dı. Ama bugün doğruluk ve GPU hızlandırma açısından docTR'ın daha iyi olduğunu düşünüyorum. docTR, çeşitli metin algılama ve tanıma modellerini bir araya getirebilen bir pipeline yapısına sahip. PyTorch veya TensorFlow üzerinde eğitilip ince ayar yapılabildiği için belirli alanlara çok daha iyi uyacak performans elde edilebiliyor
Hayat böyle bir şey. Her projeyi bitirdiğimde “Artık bu alanın uzmanıyım. Ama muhtemelen bunu bir daha asla yapmayacağım” diye düşünüyorum. Çünkü bir sonrakinde tamamen yeni bir konuyu yeniden sıfırdan öğrenmek gerekiyor
Kısa süre önce biri C++ hakkında soru sorduğunda “bununla ciddi çalışmışlığım yok” demiştim. Sonra yaklaşık 20 yıl önce Borland C++ ile yazdığım özel bir anlık mesajlaşma istemcisinin kodunu yazdığımı ve bunu binlerce kişinin kullandığını sonradan hatırladım. Bu tür şeyler sık oluyor
Aklındakilerin hepsini bilemem ama muhtemelen gerçekten tesseract'tı. Ben de benzer bir şey yaşadım, benimki yaklaşık 12 yıl önceydi
HQ popülerken tesseract ile otomatik bir HQ quiz çözücüsü yapmıştım. Uygulamadaki soru ekranının ekran görüntüsünü alıp küçük bir API'ye gönderiyor, sonra soru metnini Google'da aratıp her cevabın kaç kez geçtiğini sayarak olasılığa göre sıralıyordu. Çok doğru değildi ve basit bir yöntemdi ama yapması çok eğlenceliydi
Rüzgâr bir yaprağı uçurunca gidip başka yaprak bulan ateş karıncalarından pek farkı olmayan bir durum
7-8 yıl önce, 20'li yaşlarımdayken olmuştu; o yüzden hâlâ çok net hatırlıyorum. Acaba biraz yaş farkı mı var diye merak ettim. Ya da bir sağlık kontrolünden geçmek de iyi olabilir
Tarayıcı geliştirici araçlarındaki (“öğeyi incele”) gibi, PDF'in içerik akışını — metni saran BT…ET, font ve koordinatları belirleyen çeşitli operatörler vb. — kaynak düzeyinde “görebileceğim” ve bunu render edilmiş sonuçla yan yana karşılaştırıp analiz edebileceğim bir araç olmasını isterdim. Bu, görsel modellerin PDF'i “görerek” işleyip metni okuması akışından farklı; gerçekten PDF'in içinde hangi bilgilerin bulunduğunu derinlemesine anlamak istiyorum. Bazı araçlar var ama sadece nesne düzeyini gösteriyorlar, içerik akışının içine kadar inmiyorlar. Örnek bir PDF'in gerçek akış kaynağını ve render sonucunu HTML gibi yan yana karşılaştırıp hangi bölümün nasıl ifade edildiğini görebileceğim bir ortam istiyorum
Mozilla'nın PDF.js'i ile PDF'i DOM olarak render ederseniz buna çok benzer bir deneyim elde edebilirsiniz diye düşünüyorum. Örneğin Tj ya da TJ gibi işleçler sırasıyla <span> ya da onların kümelerine dönüştürülüyor. Muhtemelen kaynak belgeye sadık kalma ihtiyacından dolayı böyle
cpdf aracını denemenizi öneririm (kendim yaptım). cpdf'in -output-json ve -output-json-parse-content-streams seçenekleriyle PDF'i JSON'a çevirip çeşitli deneyler yapabilirsiniz. Tersine, JSON'dan tekrar PDF üretmek de mümkün. Ancak canlı etkileşim sunmuyor
Ücretsiz ya da açık kaynak bir araç arıyor gibisiniz ama eskiden Acrobat Pro kullanırken buna çok yakın bir özellik sunuyordu. Yalnız sayfayı incelemekten çok içerik ağacında dolaşma biçimindeydi ve nesne/akış düzeyine kadar gösteriyor, tek tek komutlara inmiyordu
“PDF'i bir görsel model gibi ‘insan gibi görmek’ ile ‘gerçekte PDF'in içinde hangi veri olduğunu bilmek’ birleşimini biz Tensorlake'de yapıyoruz (ben de orada çalışıyorum). Sadece metni okumakla kalmayıp tablo, görsel, denklem, el yazısı gibi şeyleri de gerçekten anlayıp Markdown/JSON olarak veri çıkarabiliyoruz; böylece AI, LLM vb. uygulamalarda kullanılabiliyor” https://tensorlake.ai
Tam olarak istenen düzeyde değil ama PDF içindeki çeşitli çizim işlemlerini ‘canlı’ gösteren bir inceleyici sunan bir not defteri var; bakmanızı öneririm https://observablehq.com/@player1537/pdf-utilities
Bu soruna Apple'da yıllarca odaklandım. Özünde mesele “her şey geometri” gerçeğini kabul etmek ve kelime aralığı ile harf aralığını kümeleme yoluyla ayıran bir algoritma geliştirmekti. Çoğu PDF'te işe yarıyor ama yakından bakınca çeşitlilik o kadar fazla ki bazı durumlar hayal kırıklığı yaratıyor. Bugün yeniden yapacak olsam, OCR'ı tamamen çıkarır, geometri tabanlı yaklaşımı makine öğrenmesiyle birleştirirdim. Önceden bilinen metinlerle PDF üretip bunu makine öğrenmesinde kullanırsanız eğitim verisini oluşturmak da otomatikleşebilir. (WWDC 2009'da Bertrand Serlet'in bir sunum videosu var)
Bunun tek bir ‘PDF to Text’ problemi olmadığını, aslında 3 kategoriye ayrıldığını düşünüyorum: (1) güvenilir OCR (arama, vektör veritabanı girdisi vb. için), (2) yapılandırılmış veri çıkarma (sadece belirli değerleri çekmek), (3) uçtan uca belge pipeline otomasyonu (ör. mortgage otomasyonu). Marginalia'nın amacı (1) ve bugün Gemini Flash gibi araçlar sayesinde OCR ucuzlayıp genelleşti. Ancak (2) ve (3) daha zor; tam otomasyon için hâlâ veri seti kurma, pipeline tasarımı, belirsizlik tespiti ve manuel müdahale, fine-tuning gibi çok fazla insan emeği gerekiyor. Gelecek bu yönde. (Bir LLM belge işleme şirketi işletiyorum) https://extend.ai
(4) olarak, farklı belge biçimlerinde güvenilir OCR ve anlamsal çıkarım, yani erişilebilirlik için çözümler de gerektiğini düşünüyorum. Bunun zor olmasının nedeni, tipik iş akışlarının aksine kullanıcı belgelerinin türünün öngörülememesi; tablo, üstbilgi/altbilgi/not/denklem gibi metin dışı unsurların da çıkarılması gerekmesi; hata minimizasyonu gerektiği için gereksiz OCR kullanımından kaçınılması; gömülü metin ile render edilen içeriğin uyuşmayabilmesi (gizli metin ya da düzensiz birleşimler gibi); çoğunlukla yerel uygulamalarda çalıştığı için sunucu kullanımının zor olması; ve kabartma baskı amaçlı belgeler için Form desteği ihtiyacı gibi pek çok karmaşık sorunun aynı anda bulunması. Şu an tüm bunları eksiksiz çözen bir çözüm yok
VLM kullanarak OCR pipeline'ını basitleştirdiklerini söylüyorlar ama pratikte karmaşık belgelerde iş çok zor. Basit görsel etiketlemede mükemmeller ve çok basit belgelerde işe yarayabiliyorlar, ancak tablo, üstbilgi ve düzenlenmiş özetler içeren belgelerde ciddi halüsinasyonlar üretiyorlar. Bu yüzden gerçekte neredeyse kullanılamaz durumdalar
Markdown'a dönüştürürken üstbilgi tespiti gibi çeşitli sorunlar yaşıyorum. Günümüz OCR'ı harika ama belgenin genel yapısını korumak çok daha zor. Yapıyı çıkarmak için LLM'den birkaç kez geçirip sayfa bazında bağlam ekleyerek ancak fena olmayan sonuçlar alabiliyorum
Daha iyi çözüm, düzenlenebilir kaynak belgeyi PDF'in içine eklemek. LibreOffice ile bunu kolayca yapmak mümkün. Genelde çok fazla yer kaplamaz ve metnin anlamını açık biçimde korur. Mevcut PDF okuyucularla da sorunsuz çalışır
Sorun mevcut PDF'lerden metin çıkarmakken, PDF üretim şekline dair tavsiyelerin gerçekten ne kadar yardımcı olacağı konusunda şüpheliyim. Bu tür çözümün ne zaman ciddi bir etkisi olacağını merak ediyorum
Doğru ama kaynak belge ile render edilen PDF'in içerik olarak tamamen farklı olabilmesi gibi bir risk doğuruyor
Katılıyorum ama bu ancak PDF'i üretenle PDF'i tüketenin çıkarları örtüşüyorsa geçerli. Elektronik delil keşfi (e-Discovery) alanında, karşı tarafın avukatının materyali kullanmayı zorlaştırmak için bilerek PDF'e dönüştürüp teslim etmesi sık görülen bir uygulama. Sonuç olarak kaynağı kısıtlı kamu savunucuları bu materyali işlemek için daha fazla zaman harcamak zorunda kalıyor ve fiilen dezavantaj yaşıyor. Bunu önlemek için çeşitli verilerin standart makinece okunabilir formatlarda zorunlu teslim edilmesini yasayla düzenlemek gerektiğini düşünüyorum
Kaynak belgeye erişiminiz varsa, bunu PDF içine eklemek gerçekten çok iyi olur. Ama çoğu durumda böyle bir kontrolünüz yok
Asıl sorunların çoğu legacy PDF'ler. Bizim şirkette de binlercesi birikmiş durumda ve bazıları berbat taramalar. Bazılarında Adobe OCR gömülü ama çoğunda hiç yok
Aşağıdaki PDF aslında bir .txt dosyası. Uzantısını .pdf yapıp bir PDF görüntüleyicide açabilirsiniz; ayrıca bir metin düzenleyicide doğrudan düzenleyerek ekranda neyin görüneceğini, fontu, font boyutunu, satır aralığını, sayfa başına karakter sayısını, satır sayısını, kâğıt boyutunu ve daha birçok şeyi kontrol edebilirsiniz. (Doğrudan PDF metin örneği içeriyor)
PDF içine ikili (binary) akışlar da gömülebilir. PDF bir metin formatı değil, yerleşim ve grafik için tasarlanmış bir format. Örnekte olduğu gibi her satır bir kerede görünebilir ama gerçekte harf harf, kelime kelime hatta tamamen sırasız şekilde bile ifade edilebilir
PDF, “Portable Document Format” ifadesinin kısaltmasıdır. 7-bit ASCII dosyası olarak kodlandığı için çeşitli cihaz ve OS ortamlarında yüksek taşınabilirlik sunar. (Not: Adobe resmî doküman bağlantısı)
Bu örnek PDF'in ‘Hello World’ü gibi. Güncel PDF'lerin çoğu nesneleri (obj) deflate ile sıkıştırıyor ve bunları akışların içinde gruplayarak yapıyı daha karmaşık hâle getiriyor. Bu yüzden düz metin içinde "6 0 Obj" arayarak analiz yapmak çok zorlaşıyor
PDF'den metin, özellikle de yapılandırılmış metin çıkarmak kesinlikle kolay değil. HTML tabloları çoğu zaman nispeten kolay çıkarılabiliyor ama PDF'te bir tablo sadece render edilmiş koordinatlarla tablo gibi görünür; gerçekte metin ve grafik dağınık biçimde yer alır. Ben de Poppler PDF utils ile PDF'i HTML'e dönüştürüp, tablo başlıklarını bulup, her değerin x koordinatına göre sütunları belirleyerek satır bazında veri çıkarmak için kullanıyorum. Görüntü olarak kaba duruyor ama hizalanmış txt ile çalışmaktan daha güvenilir sonuç veriyor
Web sayfalarında BeautifulSoup benzeri rahatlıkta PDF'den veri çıkaramıyor olmaktan rahatsız olup böyle bir arayüze sahip bir kütüphane yazdım. (
page.findbiçimi örneği) PDF'ye göre durumlar cehennem gibi değiştiği için, çıkarma bilgisini ve berbat PDF örneklerini toplayıp kütüphaneye dönüştürüyorum https://jsoma.github.io/natural-pdf/ , https://badpdfs.com/Bir gün PDF'ten tablo verilerini kendi veri işleme yazılımıma aktarmak istiyorum. C++ uygulamasına entegre edilebilen, ücretsiz ya da çok ucuz bir kütüphane bilen varsa haber versin
(Devlet kurumlarında olduğu gibi) görüntülenen metinle gerçekte çıkarılan metnin tamamen farklı olduğu belgeler var. Böyle vakalar ara sıra çıkıyor
PDF özünde bir markup/XML formatı. Aynı PDF bile gerçekten sayısız şekilde üretilebiliyor. Grafik araçlarından dışa aktarıldığında grafik ve metnin karıştığı PDF'ler, kelime işlemcilerden dışa aktarıldığında metin ağırlıklı PDF'ler gibi çok boyutlu sonuçlar oluşuyor. PDF'i üreten uygulamanın bilgiyi nasıl işlediği, çıktıdaki PDF'in biçimini ciddi şekilde etkiliyor. Hazır araçlar arasında cisdem gibi çeşitli ürünler bir ölçüde yapılandırılmış veri çıkarmada iş görebiliyor. Ama her iş için uygun araç ayrı
En sevdiğim örneklerden biri şu makalenin PDF'i (bağlantı verilmiş). İlk sayfada tipik iki sütunlu metin, ortada başlık, iki sütun arasına giren metinler ve satır uzunluğu ile girintiyi değiştiren öğeler bir arada bulunuyor. Sayfa üstbilgileri de tek/çift sayfalara göre farklı, bölüm başlığı kuralları da tutarsız. Paragraflar da her zaman girintili değil ve satır aralıkları değişebiliyor. Çeşitli sorunların toplu gösterimi gibi
Basit bir PDF ayrıştırıcısı yazmayı denediğimde formatın çalışma şekli beni şaşırtmıştı. Bu yüzden bu formatın neden metin merkezli işler için bu kadar yaygın kullanıldığına hep şaşmışımdır. Örneğin faturalarda, dijital sistemin veriyi kolayca çıkarabilmesi gerekirken insanlar için de biçimlendirilmiş görünüm uygun olmalı. Bu yüzden teknoloji dünyasının daha iyi formatlara kademeli geçiş yapmasını umuyorum
PDF'den ‘yararlı bilgi’ çıkarmak tam olarak Tensorlake'in yaptığı iş (https://tensorlake.ai). PDF'ler yalnızca metin değil; tablo, görsel, denklem, el yazısı, üstü çizili metin gibi birçok bilgi barındırıyor. Bu yüzden geliştiriciler olarak yalnızca metni “okumamız” değil, onu “anlamamız” gerekiyor. (Orada çalıştığını belirtiyor)