PDF’yi yüksek doğrulukla hızlıca Markdown’a dönüştürme teknolojisi

(github.com/VikParuchuri)

2 puan yazan GN⁺ 2023-12-02 | 1 yorum | WhatsApp'ta paylaş

Marker, yalnızca PDF değil; görüntü, PPTX, DOCX, XLSX, HTML ve EPUB belgelerini de Markdown, JSON, chunks ve HTML’e hızlı ve doğru biçimde dönüştüren bir belge zekâsı aracıdır
Tabloları, formları, denklemleri, satır içi matematiği, bağlantıları, referansları ve kod bloklarını biçimlendirir; görsel çıkarma/kaydetme ile üstbilgi/altbilgi gibi artifaktların kaldırılmasını destekler
Doğruluğu artırmak için --use_llm ile bir LLM birlikte kullanılabilir; varsayılan değer gemini-2.0-flash olup Gemini, Ollama, Claude, OpenAI, Azure OpenAI gibi seçenekler kullanılabilir
Benchmark’ta Marker, tek bir PDF sayfası bazında ortalama 2.83837 saniye, sezgisel skor 95.6709 ve LLM skoru 4.23916 elde etti; H100 batch modunda ise 25 pages/second iş hacmi bekleniyor
Python 3.10+ ve PyTorch gerekir; kod GPL lisanslıdır, model ağırlıkları ise değiştirilmiş AI Pubs OpenRAIL-M lisansıyla sunulur ve araştırma, kişisel kullanım ile $2M altı girişimler için ücretsiz koşulu uygulanır

Marker’ın dönüştürdüğü belgeler ve çıktılar

Marker, belgeleri Markdown, JSON, chunks ve HTML’e dönüştürür
Girdi biçimleri arasında PDF, görüntü, PPTX, DOCX, XLSX, HTML ve EPUB bulunur; tüm dillerdeki belgeleri işler
Belge öğesi işleme kapsamı:
- tablolar, formlar, denklemler, satır içi matematik
- bağlantılar, referanslar, kod blokları
- görsel çıkarma ve kaydetme
- üstbilgi, altbilgi ve diğer artifaktların kaldırılması
Kendi biçimlendirme ve mantığınızla genişletilebilir
JSON şeması verilirse yapılandırılmış çıkarım yapabilir; bu özellik beta durumundadır
GPU, CPU ve MPS üzerinde çalışır

Datalab yönetilen platformu

Datalab yönetilen platformu, en yeni açık kaynak model Chandra’yı çalıştırır
Chandra’nın Marker’dan daha yüksek doğruluk sunduğu belirtilir; varsayılan olarak veri saklama yoktur ve SOC 2 Type 2 ile özel BAA sunulur
Yüksek hacimli iş yükleri için batch işleme servisi haftada 200M+ sayfa işlemiştir
Kayıt olanlara $5 ücretsiz kredi verilir; ayrıca herkese açık playground da sunulur
Ticari self-hosting için lisans gerekir; on-premise lisans için ayrıca iletişime geçilmelidir

Performans ve LLM hibrit modu

Marker, Llamaparse, Mathpix gibi bulut servisleri ve diğer açık kaynak araçlara kıyasla olumlu benchmark sonuçları sunar
README’deki tam performans sonuçları, tek bir PDF sayfasının seri çalıştırılması temel alınarak ölçülmüştür
Batch modunda daha hızlıdır; H100 üzerinde 25 pages/second iş hacmi beklenir
En yüksek doğruluk için --use_llm bayrağıyla LLM birlikte kullanılabilir
- sayfa taşan tabloların birleştirilmesi
- satır içi matematik işleme
- tablo biçimlendirmesinin iyileştirilmesi
- formlardan değer çıkarılması
LLM hibrit modu, tablo benchmark doğruluğunda yalnızca Marker veya yalnızca Gemini Flash’tan daha yüksek sonuç verir

Kurulum ve temel kullanım

Python 3.10+ ve PyTorch gerekir
PDF odaklı kurulum:
```
pip install marker-pdf
```
PDF dışındaki belge biçimlerini işlemek için ek bağımlılıkları kurun
```
pip install marker-pdf[full]
```
Tek dosya dönüştürme:
```
marker_single /path/to/file.pdf
```
Klasör bazında çoklu dosya dönüştürme:
```
marker /path/to/input/folder
```
Birden fazla GPU ile dönüştürme:
```
NUM_DEVICES=4 NUM_WORKERS=15 marker_chunk_convert ../pdf_in ../md_out
```
- NUM_DEVICES, kullanılacak GPU sayısıdır ve 2 veya daha büyük olmalıdır
- NUM_WORKERS, GPU başına paralel süreç sayısıdır

Başlıca CLI seçenekleri

--page_range TEXT: işlenecek sayfa numaralarını ve aralıkları belirtir
--output_format [markdown|json|html|chunks]: çıktı biçimini belirtir
--output_dir PATH: çıktı dosyalarının kaydedileceği dizini belirtir
--paginate_output: sayfa numaraları ve ayırıcılar ekleyerek çıktı verir
--use_llm: doğruluğu LLM ile artırır
--force_ocr: tüm belgeye OCR’ı zorla uygular ve satır içi matematiği de uygun şekilde biçimlendirir
--block_correction_prompt: LLM modunda Marker çıktısını düzeltmek için kullanılacak prompt’u belirtir
--strip_existing_ocr: mevcut OCR metnini kaldırır ve surya ile yeniden OCR yapar
--redo_inline_math: --use_llm ile birlikte satır içi matematik dönüşüm kalitesini artırır
--disable_image_extraction: PDF içinden görselleri çıkarmaz
--converter_cls: varsayılan marker.converters.pdf.PdfConverter veya yalnızca tablolar için marker.converters.table.TableConverter seçilir
--llm_service: --use_llm kullanıldığında LLM servisini belirtir; varsayılan marker.services.gemini.GoogleGeminiService’tir
--workers: eşzamanlı dönüştürme worker sayısını belirtir
- worker başına en fazla 5GB VRAM, ortalama 3.5GB VRAM kullanır

Python API ve dahili blok işlemleri

PdfConverter ile Python içinden doğrudan dönüştürme yapılabilir

from marker.converters.pdf import PdfConverter
from marker.models import create_model_dict
from marker.output import text_from_rendered

converter = PdfConverter(
    artifact_dict=create_model_dict(),
)
rendered = converter("FILEPATH")
text, _, images = text_from_rendered(rendered)

Markdown çıktısındaki rendered, markdown, metadata, images özelliklerine sahiptir
JSON çıktısındaki rendered, children, block_type, metadata özelliklerine sahiptir
ConfigParser ile çıktı biçimi, processor’lar, renderer’lar, LLM servisi vb. yapılandırılabilir
Belgeler sayfa ve bloklardan oluşan bir ağaç yapısıdır; sayfalar da kendi içinde bloklar barındırabilir
contained_blocks kullanılarak formlar gibi belirli bloklar programatik olarak çıkarılabilir

Dönüştürücü türleri

PdfConverter: tüm PDF’yi dönüştüren varsayılan dönüştürücüdür
TableConverter: yalnızca tabloları çıkarır ve dönüştürür
- force_layout_block=Table belirtilirse yerleşim algılamadan kaçınılır ve tüm sayfalar tablo varsayılır
- output_format=json kullanılırsa hücre bounding box bilgileri de alınabilir
OCRConverter: yalnızca OCR çalıştırır
- --keep_chars ayarlanırsa tek tek karakterler ve bounding box’lar korunur
ExtractionConverter: beta durumundaki yapılandırılmış çıkarım dönüştürücüsüdür
- önce LLM servisi yapılandırılmalıdır
- çıkarılan değerleri JSON çıktısı olarak döndürür
- önceki çalıştırmadan alınan original_markdown, existing_markdown olarak verilirse belge yeniden parse edilmeden geçilebilir

Çıktı biçimleri

Markdown çıktısı:
- görsel bağlantıları
- biçimlendirilmiş tablolar
- $$ ile çevrili LaTeX denklemleri
- triple backticks kod blokları
- dipnotlar için superscript
HTML çıktısı:
- img etiketi görselleri
- <math> etiketi denklemleri
- pre etiketi kodları
JSON çıktısı:
- sayfaları liste olarak ifade eder ve her sayfa dahili Marker şemasındaki bir bloktur
- id, block_type, html, polygon, children anahtarlarını içerir
- alt bloklar ayrıca section_hierarchy, images içerir
- blok yapısı ağaç biçimindedir
Chunks çıktısı:
- JSON’a benzer ama her şeyi tek bir listeye düzleştirir
- her blok için tam HTML içerdiğinden RAG için chunk’lamada esnek kullanılabilir
Tüm çıktı biçimleri metadata döndürür
- hesaplanan PDF içindekiler tablosu olan table_of_contents
- sayfa bazında metin çıkarım yöntemi ve blok sayısını içeren page_stats

Desteklenen LLM servisleri

--use_llm kullanıldığında seçilebilecek servisler:
- Gemini: varsayılan olarak Gemini developer API kullanır ve --gemini_api_key gerekir
- Google Vertex: --vertex_project_id gerekir ve marker.services.vertex.GoogleVertexService belirtilir
- Ollama: yerel model kullanır; --ollama_base_url, --ollama_model ayarlanır
- Claude: --claude_api_key, --claude_model_name ayarlanır
- OpenAI: OpenAI uyumlu endpoint’leri destekler; --openai_api_key, --openai_model, --openai_base_url ayarlanır
- Azure OpenAI: --azure_endpoint, --azure_api_key, --deployment_name ayarlanır

İç mimari ve genişletme noktaları

Marker, derin öğrenme modeli pipeline’ı olarak çalışır
- metin çıkarma, gerekirse OCR uygulama
- sayfa yerleşimi algılama ve okuma sırası tespiti
- her bloğun temizlenmesi ve biçimlendirilmesi
- gerekirse LLM ile kalite iyileştirme
- blokların birleştirilmesi ve tüm metnin sonradan işlenmesi
OCR ve yerleşimle ilgili adımlarda surya kullanılır
Denklemle ilgili biçimlendirmede texify kullanılır
Temel bileşenler:
- Providers: PDF gibi kaynak dosyalardan bilgi sağlar
- Builders: ilk belge bloklarını oluşturur ve metni doldurur
- Processors: tablo biçimlendirici gibi belirli blokları işler
- Renderers: blokları çıktı biçimlerine render eder
- Schema: tüm blok türlerinin sınıfları
- Converters: tam end-to-end pipeline’ı çalıştırır
İşleme davranışını değiştirmek için processors yeniden tanımlanabilir
Yeni çıktı biçimleri, yeni bir renderer yazılarak eklenebilir
Yeni girdi biçimleri, yeni bir provider yazılarak eklenebilir

API sunucusu ve dağıtım

Basit bir FastAPI sunucusu çalıştırılabilir

pip install -U uvicorn fastapi python-multipart
marker_server --port 8001

Sunucuya localhost:8001 üzerinden erişilebilir; endpoint seçenekleri localhost:8001/docs adresinde görülebilir
Bu API sunucusu dayanıklı bir API değildir ve yalnızca küçük ölçekli kullanım için tasarlanmıştır
Daha sağlam dönüştürme seçenekleri gerekiyorsa barındırılan Datalab API kullanılabilir
Dağıtım örnekleri arasında Modal üzerinden web endpoint dağıtımı da bulunur

Sorun giderme

Doğruluk sorunu varsa --use_llm ile LLM kullanın
- bu durumda Gemini API anahtarı GOOGLE_API_KEY olarak ayarlanmalıdır
Bozuk metin görünüyorsa force_ocr ile belgeye yeniden OCR uygulayın
TORCH_DEVICE ile kullanılacak torch cihazı zorla belirtilebilir
Bellek yetersizliği hatası alınırsa worker sayısı azaltılabilir veya uzun PDF’ler birkaç dosyaya bölünebilir
debug seçeneği, algılanan yerleşimi ve metni içeren sayfa görselleri ile bounding box bilgilerini içeren JSON dosyalarını kaydeder

Benchmark sonuçları

Tam PDF dönüştürme benchmark’ı, common crawl’dan tekil PDF sayfaları çıkarılarak oluşturulan benchmark set kullanılarak yapılmıştır
Skorlar, ground truth metin segmentleriyle hizalayan sezgisel yöntem ve LLM-as-judge yaklaşımıyla hesaplanır
Tam PDF dönüştürme sonuçları:
- marker: ortalama süre 2.83837, sezgisel 95.6709, LLM 4.23916
- llamaparse: ortalama süre 23.348, sezgisel 84.2442, LLM 3.97619
- mathpix: ortalama süre 6.36223, sezgisel 86.4281, LLM 4.15626
- docling: ortalama süre 3.69949, sezgisel 86.7073, LLM 3.70429
marker ve docling H100 üzerinde çalıştırılmıştır; llamaparse ve mathpix ise bulut servisleri kullanır
Uzun PDF iş hacmi benchmark’ı için Think Python kullanılmıştır
- marker: sayfa başına 0.18 saniye
- belge başına 43.42 saniye
- VRAM 3.17GB
- H100 üzerinde 22 ayrı süreç çalıştırılabildiğinden 122 pages/second iş hacmi beklenir
Tablo dönüştürme benchmark’ı, FinTabNet test split’inin HTML temsilleri karşılaştırılarak yapılmıştır
- marker: ortalama skor 0.816, toplam 99 tablo
- marker w/use_llm: ortalama skor 0.907, toplam 99 tablo
- gemini: ortalama skor 0.829, toplam 99 tablo
FinTabNet ile yerleşim modelinin algılama yöntemlerindeki fark nedeniyle ground truth ile hizalanamayan tablolar filtrelenmiştir

Sınırlamalar ve lisans

PDF, işlenmesi zor bir biçim olduğundan Marker her zaman kusursuz çalışmayabilir
Bilinen sınırlamalar:
- iç içe tablolar ve formlar içeren çok karmaşık yerleşimler çalışmayabilir
- form render etme iyi sonuç vermeyebilir
--use_llm ve --force_ocr bayrakları çoğu durumda bu sorunların büyük bölümünü çözebilir
Model ağırlıkları değiştirilmiş AI Pubs OpenRAIL-M lisansını kullanır
- araştırma, kişisel kullanım ve funding/revenue’su $2M altında olan girişimler için ücretsizdir
Kod GPL lisanslıdır
Daha geniş ticari lisans veya GPL gereksinimlerinin kaldırılması için pricing page geçerlidir

1 yorum

GN⁺ 2023-12-02

Hacker News görüşleri

Repo genelinde Nougat ile karşılaştırma biçimi biraz kafa karıştırıcı
Nougat, akademik belgeler için özel olarak eğitilmiş bir model; Nougat’ın en iyi OCR modeli olduğunun iddia edildiğini sanmıyorum. Benchmark’larda da arXiv belgelerinde Nougat doğruluğunun daha yüksek olduğu belirtiliyor. Ayrıca marker’ın Nougat’a göre formülleri daha az dönüştürdüğünü söyleyip hız karşılaştırmasını Nougat ile yapmak da, bunun akademik belgeler için bir model olması nedeniyle biraz hayal kırıklığı yaratıyor
Matematik içeren PDF’lerde OCR yapmak istiyorsanız Nougat kesinlikle denenmeye değer. Python paketi olarak kurulumu kolay; tek bir komutla formülleri, metinleri, tabloları vb. .mmd dosyasına çıkarıyor. Kişisel kullanım için hızı da fena değil; 4 yıllık i5 dizüstümde yalnızca CPU ile 6 sayfalık bir belgeyi dönüştürmek yaklaşık 30 saniye sürdü
- İki şeyi karşılaştırmak, mevcut olanın en iyisi diye pazarlandığı anlamına gelmez
  Yeni bir aracı aşina olunan bir şeyin yanına koyup değerlendirme yöntemi sadece. Dediğiniz gibi Nougat’ın kurulumu ve çalıştırması kolay, bu yüzden karşılaştırma hedefi olarak seçilmesi doğal. Karşılaştırmaya daha fazla kütüphane eklenirse elbette daha iyi ve faydalı olur
- RPG kural kitabı PDF’lerini Nougat’ın ne kadar iyi işleyeceğini merak ediyorum
  RPG kitaplarının bazı bölümlerini Markdown’a aktarmama yardımcı olacak bir OCR modeli arıyorum. Mümkünse kalın veya italik gibi vurguların da aynen aktarılması iyi olur
  Metin, sayı ve matematik sembolü kombinasyonu teknik/akademik belgelere benziyor gibi duruyor; ama tuhaf biçimlendirmeler, kenar boşluklarındaki metin kutuları ve çok sayıda tablo sıkça karışıyor
- Yazarıyım. Benim kullanım senaryom bilimsel PDF’leri toplu dönüştürmek olduğu için Nougat en iyi çözümdü; bu yüzden varsayılan karşılaştırma hedefi olarak onu aldım
  Aşağıda basit metin çıkarma ile de karşılaştırdım. Nougat harika bir model ve birçok PDF’yi iyi dönüştürüyor, ama ben daha hızlı ve daha genellenebilir bir şey istedim
- PDF içindeki tablo biçimindeki finansal tabloları çıkarmak istiyorum; Nougat böyle bir kullanım için de uygun olur mu?
Böyle araçların etkisi küçümsenmemeli. Çünkü “okumak için iyi ama dağıtmak için kötü” bir formata hapsolmuş muazzam bilgiyi açığa çıkarıyorlar
Gerçekten heyecan verici. Bir pipeline olsa iyi olurdu: tüm PDF’ler → hepsi Markdown’a dönüştürülsün → hepsi archive.org’da saklansın
- Arşivleme amacı için bu pipeline uygun görünmüyor. Daha iyi sıra tüm PDF’ler → orijinali sakla → Markdown’a dönüştür olurdu
  Böylece hatalar düzeltildiğinde ve iyileştirmeler geldiğinde dönüştürmeyi yeniden çalıştırabilirsiniz. Kayıtların korunmasında genellikle özgün malzemeye mümkün olduğunca yakın biçimde saklama tercih edilir. Çünkü sonradan yapılan tüm dönüşümler yalnızca veri kaybı yaratabilir
- PDF aslında dağıtım formatı olarak harikadır
  Son kullanıcının gördüğü belgeyi üretmek için kullanılan ham veriyi istediğiniz biçimde görünmez şekilde içine koyabilirsiniz. Örneğin PrinceXML ile HTML’i render edip PDF oluşturuyorsanız, tüm metinleri, grafikleri, çizelgeleri vb. üretmek için kullanılan orijinal JSON’u PDF’in içine yerleştirebilirsiniz. Elbette çoğu kişi bunu gerçekten yapmıyor, ama bu spesifikasyonun suçu değil
- Yazarıyım. Bu aracı yapmamın nedenlerinden biri de tam olarak bu
  https://github.com/VikParuchuri/libgen_to_txt de incelenebilir. Henüz marker ile entegre etmedim; şu anda basit metin çıkarma kullanıyor
- Bu tür araçlara muazzam talep var. Özellikle çok çeşitli PDF belgeleri bulunan büyük kuruluşların ilgisinin yüksek olması kaçınılmaz
  İhtiyaçların veya kullanım senaryolarının yalnızca bir kısmını karşılasa bile, düzgün çalışırsa çok faydalı olur
- Erişilebilirlik açısından da çok işe yarar
  PDF erişilebilirliğini gerçekten doğru yapmak devasa bir iş; yapsanız bile kullanıcının kullandığı PDF görüntüleyicinin gerekli standartları desteklememe ihtimali yüksek
Hafta sonu kendim denemeliyim
Seçilebilir metin olmayacak şekilde OCR yapılmamış ya da yapılmış olsa bile kalitesi düşük, kaynağı belirsiz RPG PDF taramalarını sık sık elle aktarıyorum
Kopyala-yapıştır hatalarını düzeltmekten veya OCR ile metne dönüştürdükten sonra hataları düzeltmektense doğrudan kendim yazmamın kelimenin tam anlamıyla daha hızlı olduğu zamanlar oluyor
Resmî PDF’lerde bile biçimlendirme sık sık bozuluyor ve kelimeler arasında çift/üçlü boşluklar ya da sekmeler girebiliyor. Düzgün kullanılabilirse gerçekten çok zaman kazandıracak gibi
- Ben de bu kullanım senaryosunu düşünüyordum. Bir kitap üzerinde denedim ama sonuç pek iyi değildi
  Tablolar ve metin kutuları çok bozuldu. Tabloların ekran görüntüsünü alıp ChatGPT’ye yapıştırarak Markdown tablo dönüşümü yaptırınca oldukça iyi sonuç aldım. “Satır satır oku. Sütun başlıkları X, Y, Z. X metin, Y sayı, Z kelime” gibi biraz prompt verirseniz düzensiz tabloları da işleyebildi
- RPG ile ilgili materyaller arasında hiç fiziksel medyada yayımlanmamış ve fikrî mülkiyet açısından sahipsiz kalmış materyal gerçekten çok olduğu için hemen aklıma bu geldi
Bugünlerde Tesseract OCR ne kadar iyi? Eskiden denediğimde AWS, Azure ve GCP’nin çevrimiçi OCR’larının epey gerisindeydi
- Yakın zamanda epey güncelleme oldu ve git’te Tesseract 5 bağımlılık olarak belirtilmiş. Son kullandığımdan bu yana oldukça iyileşmiş olma ihtimali yüksek
  https://github.com/tesseract-ocr/tesseract/releases
  Sonuçta kullanım senaryosuna bağlı gibi. Bu tür kişisel işler için yeterli olma ihtimali yüksek; kullanıcı bilgisi veya kredi kartı gibi şeyler de gerekmiyor
- Beklediğimden harikaydı ve tarayıcı içi performansı da etkileyiciydi
  Ancak çözünürlüğe çok duyarlı. Görsel belirli bir boyutun altına indiğinde insan gözüyle yeterince okunabilir olsa bile Tesseract çıktısı berbat hale geldi
- Epey ön işleme gerekiyor. Yalnızca GCP çözümünü denedim; benim deneyimime göre o daha iyiydi
- Oldukça yakın zamanda denedim ve çok temel görsellerde bile başarısız oldu
  iOS Vision API’yi de denedim ama o da başarısız oldu. Test vakası, bir kitap sayfasının net çekilmiş fotoğrafıydı
Yazara soru: Neden Markdown? Bu aracın zor kısmı PDF’yi yüksek doğrulukla ayrıştırmak gibi görünüyor; sonrasında hangi biçimde dışa aktardığı değil.
Bu yüzden kullanıcının çıktı biçimini seçebilmesi iyi olurdu. Yüksek doğrulukta bir PDF ayrıştırıcım olsaydı bunu EPUB oluşturmak için kullanmak isterdim
- Yapısal işaretlemeyi olabildiğince koruyan bir tür işaretleme gerekli
  Bir üniversite yayınevinde e-kitapları yönetiyorum; dönüştürülmeyi bekleyen çok sayıda eski katalog var ve bunların önemli bir kısmında eski basılı nüshaların yalnızca sayfa taramaları kalmış durumda. EPUB olarak sunmak için bölüm ayrımlarının, başlıkların, tabloların, grafiklerin, formüllerin, alıntıların vb. nerede olduğunu bilmem gerekiyor. Dış kaynak bir firma bunu yapabilir, ama bazı kitaplarda dönüştürme maliyeti satış gelirinden daha yüksek. Bir kısmını bile kendi başımıza yapabilsek iyi olurdu
- Ara biçimin, isteğe bağlı olarak başka biçimlere dönüştürülebilecek düz metne yakın olması gerektiğine katılıyorum
  Ancak burada Markdown ara biçim olarak kullanılıyor gibi. Düz metne yakın, ama basit yerleşim bilgilerini koruyabiliyor. Pratikte Markdown çıktısını alıp istediğim nihai çıktı biçimine dönüştüren bir araca bağlayarak kullanacağımı düşünüyorum
- Markdown’ın seçilme nedeni formülleri, tabloları, kalın/italik bilgisini ve başlıkları korumak istemeleriydi
  Formüller $/$$ ile sarılabilir. EPUB çıktısına henüz bakmadım, ama bu gereksinimler nedeniyle düz metin elenmiş
Henüz iyi bir çözüm bulamadığım sıra dışı bir kullanım alanı var: inşaat belgelerini okumak
Çizimler her zaman PDF olarak geliyor; DXF (AutoCAD) dosyalarını ayrıştırırken çok daha iyi sonuç almıştım. Ama sahadaki genel yüklenici ben olsam bile mimardan DXF göndermesini istemek ve almak her zaman kolay olmuyor
Uzun yazıları çoğunlukla e-kitap okuyucuda okuyorum
PDF’ler, özellikle çok sütunlu düzenler, Amazon Kindle veya Pocketbook’un yerleşik özellikleriyle neredeyse kâbus gibi. Bu araç okuma deneyimini epey iyileştirecek gibi görünüyor
Güzel çalışma
Nougat çıktısında görülen halüsinasyonların nereden geldiğini merak etmiştim. Think Python örneğinin Nougat çıktısına göz atarsanız ne demek istediğimi anlarsınız
Tekrar bakınca LLM’den geçirildiği yazıyor; dolayısıyla halüsinasyon beklenebilir bir şeymiş
- Bu tür araçların, metin veya biçimlendirme halüsinasyon oranı titiz bir okuyucunun belgeyi tekrar tekrar okurken yapacağı hata oranının altına düşene kadar riskli olduğunu düşünüyorum
  Bu seviye neredeyse 0’a yakındır ve kullanım alanına bağlı olarak fiilen 0 olması bile gerekebilir. Belgenin doğru içeriğinin önemli olmadığı durumlarda genel olarak sorun olmayabilir; ancak kimse için şimdi ya da gelecekte önemli olmayan, buna rağmen PDF’den daha erişilebilir olması gereken çok sayıda belge bulunması pek yaygın bir durum gibi gelmiyor
OneNote’taki notlarımı taşımama yardımcı olabilecek bir araç gibi görünüyor
- Şunu denesene?
  https://help.obsidian.md/import/onenote
- OneNote konusunda nasıl yardımcı olacağını merak ediyorum
Oldukça ilginç. Repo’ya dönüştürme öncesi/sonrası örnekleri birkaç tane eklemek iyi olurdu
Hangi tür PDF’lere göre ayarlandığını merak ediyorum. El yazısı notları nasıl işliyor?