Model seçimi değil, ingestion: PDF ayrıştırma neden RAG erişim kalitesini belirliyor

Bir dev.to yazısı, modellere mal edilen RAG başarısızlıklarının çoğunun aslında ingestion başarısızlıkları olduğunu savunuyor. Ayrıştırıcı bir PDF'i karakter akışına düzleştirir ve bir bölücü bu akışı sabit aralıklarla keserse, en iyi embedding modeli ve en iyi LLM bile anlam yerine parçalar üzerinde çalışmak zorunda kalır.

Düz metin çıkarımı, erişimin ihtiyaç duyduğu her şeyi kaybediyor

Standart bir PDF çıkarıcısı bir karakter akışı döndürür ve yazışta üç kayıp sayılıyor: çok sütunlu sayfaların okuma düzeni, bir başlık ile altındaki paragraflar arasındaki bağ ve tabloların içindeki satır-sütun ilişkileri. LangChain'in genel metin için önerdiği varsayılan ayırıcı olan RecursiveCharacterTextSplitter, paragrafları mümkün olduğunca bir arada tutar, gerekirse cümlelere, sonra kelimelere geri döner. Bu, temiz düz yazı için sağlam bir başlangıç noktası; ama yazarın da belirttiği gibi, ayırıcı yalnızca separator'ları görür — bir tabloyu göremez.

Bunu göstermek için yazar, sahte bir 10-K dosyasını bilerek küçük tutulmuş 200 karakterlik bir bütçeyle böldü. Çıktı üç bozuk chunk'tı: başlığından ve rakamları açıklayan cümleden kopmuş bir gelir tablosu, tablo chunk'ının sonunda yapayalnız kalmış bir Risk Factors başlığı ve hiçbir bölüme bağlı olmayan tek bir risk cümlesi. LangChain eğitimlerinde kullanılan 1.000 karakter boyutu ve 200 overlap gibi daha büyük bütçeler yalnızca başarısızlığı geciktirir; herhangi bir sabit bütçe er ya da geç bir tablonun içine ya da bir başlık ile gövdesinin arasına denk gelir. Yazıya göre erişim kalitesi, tek bir embedding hesaplanmadan önce, tam olarak bu adımda belirleniyor.

Chunking'den önce belge zekası gelir

Önerilen çözüm, sayfayı kesmeden önce okumak. Belge zekası dört iş yapar: başlıklar, bölüm başlıkları, gövde metni, tablolar ve şekiller gibi bölgeleri algılayıp sınıflandıran düzen (layout) analizi; okuma düzeni; tablo yapısı tanıma; ve taranmış sayfalar için OCR. Yazıda alıntılanan Docling teknik raporu, sınırlayıcı kutular ve öğe sınıfları tahmin eden bir object-detection layout modeli ile tablo yapısını — kısmi veya eksik kenarlıklar, boş hücreler ve birleşik hücreler dahil — kurtaran ve TableFormer adlı ikinci bir modeli, ardından her şeyi Markdown veya JSON olarak dışa aktarılabilen tek bir belge nesnesinde birleştirdiğini anlatıyor.

Eğitim verisi de burada önemli. Yazıya göre DocLayNet, önceki açık veri kümelerinin yalnızca bilimsel makale depolarından gelmesi ve bunlarla eğitilen modellerin diğer sayfa tasarımlarında kötüleşmesi nedeniyle oluşturuldu. Finans, bilim, patentler, ihaleler, hukuk metinleri ve kılavuzlardan derlenen, 11 sınıfta sınırlayıcı kutular içeren 80.863 elle etiketlenmiş sayfadan oluşuyor ve Docling'in layout modeli diğer veri kümeleriyle birlikte bununla eğitildi.

Farklı ödünleşimleri olan bir araç kutusu

Yazı dört seçeneği karşılaştırıyor:

• Docling: IBM Research'ün MIT lisanslı dönüştürme araç seti. TableFormer üzerinden layout'u, okuma düzenini, şekilleri ve tabloları kurtarır, sıradan donanımda yerel olarak çalışır ve bir LangChain loader'ına sahip.
• PP-DocLayoutV2: PaddleOCR'nin layout aşaması; 25 öğe kategorisini ve okuma düzenini kapsayan, RT-DETR tabanlı bir dedektör ile bir pointer network eşleşmesi. PaddleOCR dokümantasyonu zaten daha yeni bir V3'ü listeliyor.
• Mistral OCR 3: yazının 17 Aralık 2025 olarak tarihlediği barındırılan bir API; birleşik hücreleri koruyan HTML tablolarıyla Markdown üretiyor. Önceki sürüme karşı iddia edilen %74 kazanma oranı satıcı tarafından bildiriliyor.
• Infinity-Parser: LayoutRL ile eğitilmiş, sayfa görüntülerinden doğrudan yapılandırılmış çıktı üreten, araştırma amaçlı bir vision-language parser; ödül fonksiyonu edit distance, paragraf sayısı ve okuma düzenini birleştiriyor.

Seçim tavsiyesi net: önce tabloları test edin, çünkü Markdown birleşik hücreleri ifade edemezken HTML edebilir; ve karar vermeden önce elinizdeki en kötü sayfaları her adaydan geçirin.

LangChain'de yapı farkındalıklı chunk'lar

Entegrasyon, LangChain'in standart loader arayüzünü paylaşan DoclingLoader üzerinden geliyor. ExportType.MARKDOWN dosya başına bir belge döndürürken, varsayılan olan ExportType.DOC_CHUNKS Docling'in kendi chunking aracından — varsayılan olarak HybridChunker — chunk başına bir belge döndürüyor. Anlatım, Python 3.13 üzerinde langchain 1.4.7, langchain-docling 3.0.0, docling-slim 2.145.0 ve langchain-text-splitters 1.1.3 sürümleriyle yapıldı.

Yazının kapanış kuralları şöyle: önce yapı için ayrıştırın, çünkü layout, okuma düzeni ve tablo kurtarma chunk'ların içerebileceğini belirler; o yapıya göre bölümlerin, tabloların ve ebeveyn-çocuk bağlarının öncülük ettiği, token limitlerinin ise yedek güvenlik olduğu şekilde chunk'layın; erişimin filtreleyebilmesi ve agent'ların atıfta bulunabilmesi için başlıkları ve sayfa numaralarını metadata olarak saklayın; ve görsel olarak yoğun sayfalar için metin çıkarımını atlayıp sayfa görüntüleri üzerinden erişim sağlayın.

Neden önemli

Yazı, alışılmış hata ayıklama sırasını tersine çeviriyor: erişim kalitesini model seçimi değil, ingestion belirliyor. Görsel bir erişim modeli olan ColPali'nin yazarlarından alıntı yapıyor; onlar deneylerinde, görsel olarak zengin belgeler için geliştirilmiş bir ingestion hattının, metin embedding modelini değiştirmekten çok daha fazla yardım ettiğini bulmuş. Pratik sonuç şu: kendi en kötü belgelerinizi test seti olarak kullanarak parser'ınızın ve splitter'ınızın gerçekte ne ürettiğine bakmak, telafi etmek için embedding'leri ya da LLM'leri yükseltmekten daha ucuz. Ve erişimi bir araç olarak çağıran agent'lar için yapısal metadata iki kez ödüllendirir: filtrelenmiş aramaları mümkün kılar ve modele atıfta bulunabileceği bir şey verir.