Apache Tika · MarkItDown · PyMuPDF4LLM · Docling · MinerU · Marker
Karşılaştırmalı Analiz ve Marker Seçimi Gerekçelendirmesi
Bu rapor; akademik tezler, bilimsel makaleler ve teknik dokümanlardan oluşan bir PDF korpusunun LLM ve RAG sistemlerinde kullanılabilir, yapısal bütünlüğü korunmuş bir formata dönüştürülmesi amacıyla değerlendirilen altı farklı veri çıkarım aracını karşılaştırmaktadır. Değerlendirilen araçlar; Apache Tika, MarkItDown, PyMuPDF4LLM, Docling, MinerU ve Marker'dır. Karşılaştırma; metin doğruluğu, tablo yapısının korunması, formül/matematiksel ifade işleme, görsel çıkarımı, çok kolonlu sayfa düzeni (layout) çözümleme, OCR kalitesi ve büyük ölçekli işleme performansı kriterleri üzerinden yapılmıştır.
Yapılan tüm denemeler ve performans testleri sonucunda korpusun işlenmesi için Marker aracı tercih edilmiştir. Marker; tablo yapısının korunması, formül ve inline matematik ifadelerinin doğru dönüşümü, başlık-altbaşlık hiyerarşisinin sağlam çıkarılması, görsellerin ayrıştırılarak saklanabilmesi ve RAG için doğal "chunk" yapısı üretebilmesi açısından diğer araçlara göre en dengeli profili sergilemiştir. GPU bağımlılığı ve VRAM tüketimi gibi maliyetler, çıktı kalitesinin önceliklendirildiği bu projede kabul edilebilir bulunmuştur.
PDF, görsel sunum amacıyla tasarlanmış bir formattır; bu nedenle metin, tablo, formül ve görsel öğelerin makineler tarafından doğru biçimde geri kazanılması zorlu bir problemdir. LLM ve RAG iş yüklerinde, çıkarılan içeriğin yalnızca okunabilir değil aynı zamanda yapısal olarak tutarlı olması gerekir; aksi takdirde tablolardaki sayısal veriler, denklem semantiği veya başlık hiyerarşisi kaybolarak alt-akış görevlerin (özellikle retrieval ve cevap üretiminin) kalitesini düşürür. Bu çerçevede araçlar aşağıdaki kriterler üzerinden değerlendirilmiştir:
Apache Tika, Apache Software Foundation çatısı altında geliştirilen, Java tabanlı ve içerik tipinden bağımsız (1000+ format) bir metin çıkarma ve metadata analiz kütüphanesidir. Kurumsal arama altyapılarında ve sunucu tarafı belge boru hatlarında uzun yıllardır yaygın biçimde kullanılmaktadır. PDF işleme tarafında PDFBox motorunu, OCR ihtiyacında ise Tesseract entegrasyonunu kullanmaktadır. Yapay zekâ tabanlı bir layout/tablo modeli içermez; çıkarımı büyük ölçüde metin akışı üzerinden gerçekleştirir.
Varsayılan konfigürasyonla yapılan denemelerde, dijital (text-layer içeren) PDF'lerde düz metin çıkarımı genel olarak başarılı bulunmuştur. Paragraf bazlı metin akışı çoğu tez dokümanında alınabilmekte ve saf metin ihtiyacı için temel düzeyde yeterli bir çıktı üretmektedir. Ancak sistem belgeyi anlamsal yapılar üzerinden değil, büyük ölçüde metin akışı üzerinden ele aldığı için yapısal içeriklerde belirgin kalite kaybı gözlemlenmiştir.
Özellikle tablolar, Tika tarafından tablo nesnesi olarak algılanmamakta; hücre yapısı ve sütun düzeni korunmadan satır satır düz metne dönüştürülmektedir. Bu durum sayısal veri, karşılaştırmalı tablolar ve deney sonuçları içeren bölümlerde veri bütünlüğünü bozmakta, tablonun yeniden yapılandırılmasını neredeyse imkânsız hâle getirmektedir.
Görsel içeriklerde Tika'nın davranışı deterministik değildir. Şekil, grafik veya taranmış sayfa üzerindeki yazılar yalnızca PDF içinde gerçek bir metin katmanı varsa çıkarılabilmektedir. Görüntü tabanlı (bitmap) içerikte ise OCR devreye girmediği sürece bu yazılar tamamen kaybolmaktadır. OCR aktif olsa bile düşük çözünürlük, küçük font, arka plan gürültüsü ve karmaşık yerleşimler doğruluğu ciddi biçimde düşürmektedir.
Matematiksel ifadelerde formül yapısının korunamadığı açıkça gözlemlenmiştir. Kesir yapıları, alt/üst simgeler ve özel semboller çoğunlukla dağılmış karakter dizilerine dönüşmekte, denklem semantiği kaybolmaktadır. Bu durum mühendislik ve fen bilimleri tezlerinde metnin kritik bölümlerinin anlamını yitirmesine yol açmaktadır.
Taranmış tezlerde OCR üzerinden metin çıkarımı mümkün olsa da kalite tutarsızdır. Türkçe karakterlerde bozulma, sembol kaybı, anlamsız karakter dizileri ve dil bütünlüğünün kaybı sık görülmektedir. Çok dilli içeriklerde (özellikle Arapça) varsayılan OCR ayarları çoğu senaryoda yetersiz kalmakta ve bu bölümler büyük ölçüde atlanmaktadır.
Tika, hızlı, olgun ve geniş format desteğiyle saf metin/metadata ihtiyacı için güçlü bir üründür; ancak yapısal bütünlüğün (tablo, formül, layout) önemli olduğu bu projenin gereksinimleri için yetersiz kalmaktadır.
MarkItDown, Microsoft tarafından açık kaynak olarak sunulan, hafif bir Python dönüştürücüsüdür. Temel hedefi belgeleri LLM, RAG ve not işleme araçlarının doğrudan tüketebileceği tek tip ve sade bir Markdown yapısına çevirmektir. PDF'in yanı sıra Word, PowerPoint, Excel, HTML, görüntü ve ses gibi pek çok formatı destekler. PDF tarafında kendisi bir layout modeli içermez; alt katmanda mevcut Python PDF kütüphanelerinden yararlanır.
Kurulumu basittir ve birden çok ofis formatında kullanılabilmesi pratik bir avantaj sağlar. Ancak PDF tarafında daha gelişmiş doküman analiz araçlarıyla karşılaştırıldığında okuma sırası düzeltme, karmaşık layout çözümleme ve tablo yapısını koruma konularında sınırlı kalmaktadır. Metni büyük ölçüde olduğu gibi akışa döker; sayfa düzenini derinlemesine modelleyen sistemler kadar yapısal iyileştirme yapmaz. Bu nedenle temel metin çıkarımı ve hızlı Markdown üretimi için uygun olsa da, akademik makalelerdeki çok sütunlu yapı veya tablo yoğun belgelerde daha gelişmiş araçlara göre basit kalmaktadır.
PyMuPDF4LLM, yüksek performanslı PDF motoru MuPDF'in Python sarmalayıcısı olan PyMuPDF üzerine kurulmuş, LLM/RAG hazırlığına özel bir katmandır. AI tabanlı layout modelleri kullanmaz; mevcut metin katmanını ve sayfa geometrisini doğrudan kullanır. Bu sayede dijital PDF'lerde son derece hızlıdır ve ek model yükü oluşturmaz.
PyMuPDF4LLM, LLM ve RAG veri hazırlama sürecinde verimli çalışan araçlardan biri olarak öne çıkmıştır. PDF'in mevcut metin katmanını doğrudan kullanması ve ağır yapay zekâ tabanlı modellere ihtiyaç duymaması sayesinde, özellikle metin seçilebilir dijital PDF'lerde hızlı ve akıcı bir işlem süreci sağlanmıştır. Çıktıyı yalnızca düz metin olarak değil Markdown formatında sunmaktadır.
Başlık yapısı ve metin akışı çoğu akademik dokümanda korunmuş, iki kolonlu makalelerde okuma sırasını düzenleme konusunda genel olarak başarılı sonuçlar alınmıştır. Bununla birlikte bazı sayfalarda kolon akışında bozulmalarla karşılaşılmıştır; örneğin tek kolondan iki kolonlu metne geçişte cümlelerin birbirine kaynamış halde çıktığı durumlar gözlemlenmiştir. Ayrıca belirli bir makalede (document_11) "ı" harfi çevresindeki kelimelerde harfler arasına bir boşluk eklendiği lokal bir karakter ayrışması tespit edilmiştir.
Karmaşık tablolarda hücre yapısı korunmamış, satır akışı bozulmuş ve özellikle çok sütunlu, çok satırlı tablolarda metin dağılmıştır. Finansal rapor benzeri belgelerde tablo düzeni metne doğru şekilde yansıtılmamıştır. Formüller ve özel semboller bazı sayfalarda parçalanmış karakterler hâlinde çıkmıştır. Bu durumlar büyük ölçüde aracın hatasından çok PDF'in metni grafik öğeleri olarak saklama biçiminden kaynaklanmaktadır. Taranmış (image-only) PDF'lerde OCR devreye girdiğinde işlem süresi belirgin biçimde artmıştır.
PyMuPDF4LLM'in en belirgin özelliği hafif çalışması ve yüksek hız sağlamasıdır. Yapay zekâ tabanlı layout analizi yapan sistemlere göre daha sınırlı yapısal çıkarım yapsa da büyük hacimli, dijital ve tablo/formül yoğunluğu görece düşük korpuslarda hızlı bir baseline aracı olarak değerlendirilebilir.
Docling, IBM Research tarafından geliştirilen ve açık kaynak olarak yayımlanan, AI tabanlı bir doküman işleme aracıdır. Sayfa düzeni analizi için DocLayNet veri seti üzerinde eğitilmiş layout modelleri ve TableFormer benzeri tablo yapı tanıma modelleri kullanır. Çıktıyı; layout segmentleri, span seviyesi bilgi ve nihai Markdown/JSON gibi farklı katmanlarda üretebilir. RAG ve LLM iş yüklerinde son dönemde popülerleşmiştir.
Docling, yalnızca ham metni çıkarmamakta; sayfa yapısını modelleyerek okuma sırasına göre düzenlemektedir. Başlıklar, alt başlıklar, paragraf blokları ve akademik makale akışı büyük ölçüde korunabilmiştir. Özellikle çok kolonlu sayfalarda kolonları karıştırmadan metni doğru sırada birleştirmesi, klasik metin çıkarıcı araçlara kıyasla belirgin biçimde başarılı bulunmuştur. Çıktılar doğrudan LLM ve RAG sistemlerinde kullanılabilir niteliktedir.
Formüller Markdown çıktısında doğrudan matematiksel ifade yerine <!-- formula-not-decoded --> şeklinde bir yer tutucu (placeholder) ile temsil edilmiştir. Bu, Docling'in formülü tamamen kaybetmediğini ancak mevcut model tarafından güvenli biçimde çözümlenmediğini göstermektedir. Cümle içinde formül ve metnin beraber bulunduğu yerlerde formülü decode etme denemeleri yapılmış, ancak düzgün çıktı elde edilememiştir.
Formülün çözümlenemediği durumların açıkça işaretlenmesi, sessiz hatalar yerine kontrol edilebilir eksikler üretmesi açısından pratik bir avantaj sağlamaktadır; ancak formül yoğun bir korpus için bu yer tutucuların alt-akış işlemler için manuel veya alternatif araçlarla tamamlanması gerekecektir. Buna ek olarak bazı metin örneklerinde (özellikle 9., 13. ve 14. metinlerde) Türkçe karakterler arasında gereksiz boşlukların oluştuğu karakter parçalanmaları tespit edilmiştir.
Docling; kolon yapısını doğru okuma, akademik belge düzenini koruma ve sembol tanıma konusunda güçlü bir profil çizerken, formüllerin önemli bir kısmının decode edilememesi ve sporadik karakter ayrışmaları kritik sınırlamalar oluşturmaktadır. Formül yoğun olmayan bilimsel makalelerde dengeli bir alternatiftir.
MinerU, OpenDataLab ekibi (Shanghai AI Laboratory) tarafından geliştirilen ve özellikle bilimsel dokümanlara odaklanan açık kaynaklı bir PDF işleme aracıdır. Dahili olarak layout analizi, formül tanıma (UniMERNet ve benzeri modeller), tablo yapı analizi ve OCR (PaddleOCR vb.) bileşenlerini birleştiren bir pipeline mimarisine sahiptir. GPU'ya yatkın ve görece ağır bir araçtır.
MinerU, belgeyi sadece metin olarak çıkarmak yerine sayfa düzenini de anlamaya çalışmaktadır. Metni okuma sırasına göre düzenlemesi, başlık-paragraf yapısını koruması ve gereksiz üstbilgi/altbilgi kısımlarını ayıklaması, çıktının doğrudan LLM ve RAG sistemlerinde kullanılmasını kolaylaştırmıştır. Formüller ve özel semboller tarafında belirgin bir avantaj gözlenmiş; matematiksel ifadeleri LaTeX formatına dönüştürme konusunda tutarlı sonuçlar vermiş ve alışılmadık karakterlerde bozulma çok az yaşanmıştır.
Yalnızca nihai metni değil layout ve span seviyesinde ara çıktıları da üretebilmesi, modelin sayfayı nasıl parçaladığını görerek kalite kontrol yapmayı mümkün kılmıştır. Buna karşılık çalışma hızı tarafında ağır davrandığı fark edilmiştir; özellikle çok sayfalı belgelerde veya OCR devreye girdiğinde işlem süresi belirgin biçimde uzamaktadır. Yapısal analiz, layout modeli ve formül tanıma gibi ek adımların getirdiği hesaplama yükü hissedilmektedir.
MinerU, yapısal bütünlüğü ve formül doğruluğunu önceleyen senaryolarda en güçlü alternatiflerden biridir. Ancak büyük ölçekli toplu işleme senaryolarında hız ve operasyonel maliyet açısından daha hafif veya daha optimize pipeline'lara göre dezavantajlı kalabilmektedir.
Marker, Datalab ekibi tarafından geliştirilen ve klasik metin çıkarım araçlarından farklı olarak derin öğrenme tabanlı bir pipeline kullanan açık kaynaklı bir araçtır. PDF, görüntü ve Office dosyaları gibi pek çok formatı; Markdown, JSON, HTML ve RAG için uygun "chunk" yapısına dönüştürebilir. Pipeline; layout analizi, OCR (Surya), formül tanıma (Texify benzeri modeller) ve tablo yapı tanıma gibi birden fazla model bileşenini birleştirmektedir. İsteğe bağlı LLM destekli mod ile tablo birleştirme ve form alanı anlama gibi adımlarda ek doğruluk sağlanabilmektedir.
Tabloları, formları, denklemleri, inline matematik ifadelerini ve görselleri yapısal olarak tanıyıp formatlayabilmesi en güçlü taraflarından biridir. Başlık-altbaşlık hiyerarşisini, okuma sırasını ve sayfa düzenini model tabanlı analizle çıkardığı için akademik makale ve teknik dokümanlarda yapısal bütünlüğü metne daha iyi yansıtmaktadır.
Çıktı kalitesi tarafında tabloların yapısal olarak oldukça düzgün çıkarıldığı, hücre düzeninin büyük ölçüde korunduğu görülmüştür. Görseller dosyadan ayrıştırılıp kaydedilebilmiştir. Matematiksel ifadeler ve formüller diğer birçok araca göre belirgin biçimde daha düzgün dönüştürülmüştür. Ayrıca Marker'ın oldukça fazla konfigürasyon seçeneği bulunmaktadır; OCR zorlama, LLM ile düzeltme, sadece tablo çıkarma, sayfa aralığı seçme gibi ayarlarla pipeline davranışı ciddi ölçüde değiştirilebilmektedir.
Performans tarafında CPU üzerinde çalıştırıldığında sistemin belirgin biçimde yavaşladığı görülmüştür; GPU kullanımı zorunluya yakın bir gereksinimdir. Tek dokümanlık işlemlerde GPU tarafında ortalama yaklaşık 3.5 GB, pikte ise 5 GB civarında VRAM tüketimi gözlemlenmiştir. Toplu işleme testleri için ayrı bir performans bölümü hazırlanmıştır (bkz. Bölüm 5).
Marker; hızdan çok yapısal doğruluğa odaklanan, GPU tabanlı, tablo-formül-görsel içeren teknik dokümanlarda güçlü sonuç veren bir sistemdir. Büyük ölçekli toplu işleme senaryolarında vaat edilen en iyi-durum hız değerlerine ulaşmak pratikte zor olsa da, kalite-hız dengesi açısından değerlendirilen araçlar arasında en üst kademede yer almıştır.
Aşağıdaki tablo, gözlemlere dayalı olarak araçların temel kriterlerdeki performansını özetler. Değerlendirme Yüksek, Orta ve Düşük olarak verilmiştir.
| Kriter | Apache Tika | MarkItDown | PyMuPDF4LLM | Docling | MinerU | Marker |
|---|---|---|---|---|---|---|
| Düz metin doğruluğu | Yüksek | Orta | Yüksek | Yüksek | Yüksek | Yüksek |
| Çok kolonlu layout | Düşük | Düşük | Orta | Yüksek | Yüksek | Yüksek |
| Tablo yapısı korunması | Düşük | Düşük | Düşük | Orta | Orta | Yüksek |
| Formül / matematik | Düşük | Düşük | Düşük | Düşük | Yüksek | Yüksek |
| Görsel ayrıştırma | Düşük | Düşük | Orta | Orta | Orta | Yüksek |
| OCR kalitesi | Orta | Düşük | Orta | Orta | Yüksek | Yüksek |
| LLM/RAG uygunluğu (chunk) | Düşük | Orta | Yüksek | Yüksek | Yüksek | Yüksek |
| İşleme hızı (büyük korpus) | Yüksek | Yüksek | Yüksek | Orta | Düşük | Orta |
| Donanım esnekliği (CPU/GPU) | Yüksek | Yüksek | Yüksek | Orta | Düşük | Düşük |
| Konfigürasyon esnekliği | Orta | Düşük | Orta | Orta | Orta | Yüksek |
Açıklama: Marker; tablo yapısı, formül-matematik, görsel ayrıştırma, OCR ve LLM/RAG uygunluğu kriterlerinin tamamında "Yüksek" değerlendirmesini alan tek araçtır. Donanım esnekliği ve büyük korpus hızında orta seviyede kalmaktadır; bu maliyet, projedeki kalite öncelikleri çerçevesinde kabul edilebilir bulunmuştur.
Marker'ın büyük korpuslara ölçeklenip ölçeklenemeyeceğini somut olarak test etmek amacıyla Google Colab ortamında ayrı bir benchmark çalışması yürütülmüştür. Bu testte korpustan seçilen 17 dijital PDF (OCR kapalı), Markdown formatına dönüştürülmüş ve paralel proses sayısı (workers) arttıkça hız ile GPU/VRAM kullanımının nasıl değiştiği incelenmiştir.
TORCH_DEVICE=cudaOCR_ENGINE=None (dijital PDF olduğu için hız kazanmak amacıyla)--disable_image_extraction (gereksiz yükü azaltmak için)nvidia-smi ile düzenli aralıklarla GPU kullanım yüzdesi ve VRAM örneklenerek timeline CSV oluşturulmuştur| Workers | Süre (sn) | Ort. GPU % | Ort. VRAM (GB) | Tepe VRAM (GB) | Başarı (PDF) |
|---|---|---|---|---|---|
| 4 | 398.54 (en yavaş) | 60.13 | ~18.5 | ~34.4 | 17 / 17 |
| 6 | 281.32 | 87.38 | ~37.4 | ~49.1 | 17 / 17 |
| 8 | 279.57 (en iyi) | 88.95 | ~50.0 | ~63.1 | 17 / 17 |
| 10 | 294.78 | 84.13 | ~60.0 | ~78.0 (riskli) | 17 / 17 |
| 12 | 281.33 | — | — | ~81.2 (OOM) | 15 / 17 (eksik) |
Workers sayısı arttıkça başlangıçta belirgin bir hızlanma görülmüştür. 4 worker'da GPU'nun tam beslenemediği (%60 ortalama) ve düşük paralellik nedeniyle bekleme sürelerinin arttığı anlaşılmaktadır. 6 ve 8 worker'da GPU kullanımı %87-89 seviyelerine çıkarak donanımın daha verimli kullanıldığı bir bant oluşmuştur. 6'dan 8 worker'a geçişte süre çok az iyileşirken (281.3 sn → 279.6 sn) VRAM kullanımı ciddi biçimde artmıştır (~37 GB → ~50 GB).
8'den 10 worker'a çıkıldığında VRAM daha da artmasına rağmen toplam süre kötüleşmiştir (279.6 sn → 294.8 sn). Bu durum; GPU'nun doygunluğa ulaşmasının yanında çoklu proses kaynaklı ek yüklerin (proses zamanlaması, model kopyaları, VRAM parçalanması ve CPU tarafı koordinasyon maliyetleri) etkisiyle, paralelliğin sınırsız ölçeklenmediğini göstermektedir. 12 worker senaryosunda ise CUDA out-of-memory hataları oluşmuş; 17 yerine yalnızca 15 Markdown dosyası üretilebilmiştir.
workers = 8 — 17/17 başarı, en düşük süre, ~%89 GPU verimiworkers = 6 — VRAM ~37 GB ile daha rahat aralıkworkers = 10 — VRAM ~78 GB seviyesinde riskli, üstelik süre zaten daha kötüworkers = 12 — OOM hataları ve eksik çıktıKarşılaştırmalı değerlendirme ve performans testleri sonucunda, korpusun veri çıkarım boru hattı için Marker tercih edilmiştir. Bu seçimin gerekçeleri aşağıda alt başlıklar hâlinde özetlenmiştir.
Korpus, akademik tezler ve teknik dokümanlardan oluşmaktadır; bu belgelerde tablolar, denklemler, çok kolonlu sayfalar ve şekiller yoğun biçimde yer almaktadır. Apache Tika ve MarkItDown bu yapısal öğeleri büyük ölçüde kaybetmektedir. PyMuPDF4LLM hızlıdır, ancak tablo ve formül tarafında belirgin sınırlılıklar göstermektedir. Docling tablo ve layout'ta iyi olsa da formülleri büyük oranda formula-not-decoded yer tutucusuna düşürmektedir; bu, formül yoğun bir korpus için ciddi bir bilgi kaybıdır. Marker; tablo, formül, inline matematik ve görselleri tutarlı biçimde yapılandırılmış çıktıya dönüştürebilmektedir.
Marker yalnızca Markdown değil, aynı zamanda JSON ve RAG için doğal "chunk" yapısı üretebilmektedir. Bu özellik, çıktının chunking ve embedding aşamalarına ek bir post-processing katmanı eklenmeden taşınabilmesini sağlamaktadır. Diğer araçlarda bu yapıyı oluşturmak için ek aşamalar gerekmektedir.
Marker; OCR zorlama/devre dışı bırakma, LLM destekli düzeltme modu, sadece tablo çıkarma, sayfa aralığı seçimi ve görsel çıkarımını kapama gibi pek çok parametre sunmaktadır. Bu esneklik, dijital ve taranmış belgeleri aynı pipeline içinde farklı modlarla işlemeye olanak tanımakta ve performans testlerinde gözlemlendiği gibi, kapatılabilir adımlar sayesinde hız kazanımına da imkân vermektedir.
Tika'nın varsayılan OCR'ı Türkçe karakterlerde sıkça bozulma yaşamakta, çok dilli içeriklerde (örn. Arapça) yetersiz kalmaktadır. Marker'ın dahili Surya OCR motoru, modern transformer tabanlı yapısı sayesinde çok dilli senaryolarda klasik Tesseract tabanlı boru hatlarına göre daha tutarlı sonuçlar üretmektedir.
Bölüm 5'teki testler, Marker'ın H100 GPU üzerinde 8 worker konfigürasyonuyla 17 PDF'i yaklaşık 280 saniyede %88-89 GPU verimliliğiyle ve hatasız biçimde işleyebildiğini göstermiştir. Bu süre, projenin korpus büyüklüğü ve operasyonel takvimine uygun bulunmuştur. GPU bağımlılığı bir kısıt olmakla birlikte, korpusun bir kez işlenmesi ve sonuçların saklanacak olması nedeniyle bu kısıt kabul edilebilir bir maliyet olarak değerlendirilmiştir.
Değerlendirilen altı araç içerisinde Marker; yapısal bütünlüğün korunması, formül ve tablo doğruluğu, LLM/RAG çıktı uygunluğu ve konfigürasyon esnekliği boyutlarında en güçlü dengeyi sunmuştur. Performans testleri, aracın H100 GPU üzerinde 8 worker'lık bir konfigürasyonla projenin korpus boyutuna uygun ve stabil biçimde ölçeklendiğini göstermiştir. Bu nedenle veri çıkarım pipeline'ı Marker üzerine inşa edilecek, alternatif araçlar yalnızca Marker'ın özel olarak başarısız olduğu nadir durumlarda yedek/tamamlayıcı olarak değerlendirilecektir.
— Rapor sonu —