Yapay Zekâ ile Soru Aktarımı: sınav PDF'lerinden yapılandırılmış LaTeX maddelerine

Mahdi Molavi 4 Ekim 2026 4 dk okuma

Ocak 2024'ten Aralık 2024'e kadar Avustralya merkezli Noraco için uzaktan, sözleşmeli olarak çalıştım. Yazılı sınavları PDF olarak alıp yapılandırılmış, veritabanına hazır LaTeX maddelerine dönüştüren bir pipeline'ı otomatikleştirdim; toplamda 5.000+ soru. LLM API'leri konu, beceri ve zorluk metadata'sını üretiyor; bir React inceleme konsolu da doğrulama, QA ve yayınlamayı kapsıyor.

Bağlam

Sınav soruları çoğu zaman yalnızca belge olarak bulunur: baskı için hazırlanmış; denklemler, numaralı bölümler, tablolar ve cevap şıklarıyla dolu PDF'ler. Bu format kâğıt sınav için işe yarar, neredeyse geri kalan her şey için ise kötüdür. Konuya göre arayamaz, zorluğa göre filtreleyemez, ondan yeni testler oluşturamaz ya da web'de güvenilir biçimde gösteremezsiniz.

Amaç bu materyali bir soru bankasına dönüştürmekti. Her soru, metadata'sıyla birlikte ayrı ve yapılandırılmış bir madde haline gelir, veritabanında saklanır ve çevrim içi yayınlanmaya hazır olur.

Mühendislik problemi

Sınav PDF'lerini temiz maddelere dönüştürmek kulağa geldiğinden daha zordur; nedenleri bu türden her proje için geçerlidir:

PDF bir sayfa düzeni formatıdır. Gliflerin sayfada nerede durduğunu kaydeder, ne anlama geldiklerini değil. Düz metin çıkarma matematiği düzleştirir, üst simgeleri ve kesirleri kaybeder ve sorular arasındaki sınırları bulanıklaştırır.
Matematiğin gerçek bir temsile ihtiyacı vardır. Formül içeren sınav içeriği için doğal hedef LaTeX'tir. Kesindir, derlenerek ya da render edilerek kontrol edilebilir ve web sayfaları onu gösterebilir.
Metadata belgeyle birlikte gelmez. Bir soru bankasını kullanışlı kılan konu, beceri ve zorluktur. Binlerce maddeyi elle etiketlemek yavaştır ve farklı kişiler aynı soruyu farklı etiketler.
Otomasyon hata yapar. Her otomatik dönüştürme ya da etiketleme adımı zaman zaman yanılır. Binlerce madde söz konusu olduğunda, bir şey bu hataları yakalamazsa küçük bir hata oranı bile çok sayıda hatalı maddeye ulaşır.

Geliştirdiklerim

Aktarım pipeline'ı. Yazılı sınavları yapılandırılmış, veritabanına hazır maddelere dönüştüren PDF'ten LaTeX'e dönüşümü otomatikleştirdim. Pipeline 5.000+ soru üretti.
LLM ile metadata. Sorular için konu, beceri ve zorluk metadata'sı üretmek üzere LLM API'lerini OpenRouter üzerinden entegre ettim.
Backend servisleri. Servisleri FastAPI uygulamaları olarak teslim ettim.
Bir inceleme konsolu. LaTeX doğrulama, QA ve çevrim içi yayınlama için bir React inceleme konsolu teslim ettim.

Tasarım notları

Aşağıdaki notlar bu tür bir pipeline'ın genel gerekçesini veriyor. Noraco'nun iç yapısının bir tarifi değiller.

Madde formatı olarak LaTeX

LaTeX her soruya, matematik için kesin ve yine de insanlar tarafından okunabilen bir metin biçimi verir. Ucuz bir ilk kontrol de sunar: bir maddenin LaTeX'i derlenmiyor ya da render edilmiyorsa bir şeyler ters gitmiştir ve sistem bunu, bir kişi bakmadan önce işaretleyebilir. Bu, "bu dönüşüm doğru mu?" sorusunun bir kısmını mekanik bir teste çevirir.

Sorunun tamamını yanıtlamaz. Render edilen LaTeX yine de yanlış bir şey söylüyor olabilir; bu yüzden kontrolden geçmek bir filtredir, incelemenin yerini tutmaz.

Metadata için LLM'ler, taslak olarak

Bir soruyu konu, beceri ve zorluğa göre etiketlemek bir dil görevidir ve LLM'ler bunu elle etiketlemenin yetişemeyeceği bir hacimde yapabilir. Ancak bir modelin etiketleri birer öneridir. Özellikle zorluk, gerçek öğrenciler soruyu cevaplayana kadar bir tahminden ibarettir. Bu tür bir pipeline'da üretilen metadata en iyi, bir madde yayına girmeden önce inceleyicinin düzeltebileceği bir taslak olarak ele alınır.

Neden OpenRouter

OpenRouter, farklı sağlayıcılardan pek çok modeli tek bir API'nin arkasında toplar. Binlerce madde üzerinde çalışan bir pipeline için bu, model seçimi açık kalırken entegrasyon kodunu sabit tutar; model değiştirmenin nedeni belirli bir konudaki kalite, maliyet ya da erişilebilirlik olabilir.

İnceleme konsolu neden önemli

Hacmi otomasyon karşılar; muhakemeyi insanlar yapar. İnceleme konsolu önemlidir, çünkü dönüştürme ve etiketleme zaman zaman yanlış olacaktır ve bunu yakalamanın en ucuz yeri, bu iş için yapılmış bir araçtır; orada inceleyici bir maddeyi dosyalara geri dönmeden kontrol edip düzeltebilir. Yayınlamayı aynı konsola koymak "dönüştürüldü" ile "yayında" arasında net bir kapı bırakır: bir script bitti diye hiçbir şey yayına girmez.

Backend'de FastAPI

Belge işleme ve LLM istemci kütüphaneleri Python'da iyi desteklenir. FastAPI, Python kodunu HTTP servisleri olarak sunmanın hafif bir yoludur; tipli istek ve yanıt modelleri ile otomatik üretilen API dokümantasyonu sağlar. Bunlar bir inceleme frontend'i ve onun backend'i yan yana geliştirildiğinde işe yarar, çünkü aralarındaki sözleşme tek bir yerde yazılı olur.

Teknoloji yığını

Python ve FastAPI
OpenRouter üzerinden LLM API'leri
LaTeX
İnceleme konsolu için React

Sonuç

Yalnızca PDF olarak var olan yazılı sınavlar, LLM ile üretilmiş konu, beceri ve zorluk metadata'sına sahip, yapılandırılmış ve veritabanına hazır 5.000+ soruya dönüştü. React konsolu, projeye LaTeX doğrulama, QA ve çevrim içi yayınlama için tek bir yer sağlıyor.

İlgili

Yapılandırılmış metadata'ya sahip madde bankaları genel olarak uyarlamalı testin hammaddesidir; değerlendirme işinin bu tarafı için uyarlamalı test platformu vaka çalışmasına bakın. Aklınızda benzer bir proje varsa Benimle çalışın sayfasına bakın.

Sık sorulan sorular

Noraco soru aktarım pipeline'ı ne yapıyordu?

PDF formatındaki yazılı sınavları yapılandırılmış, veritabanına hazır LaTeX maddelerine dönüştürdü: toplamda 5.000+ soru.

Pipeline'da LLM'ler nasıl kullanıldı?

Mahdi Molavi, sorular için konu, beceri ve zorluk metadata'sı üretmek üzere LLM API'lerini OpenRouter üzerinden entegre etti.

İnceleme konsolu ne işe yarıyordu?

Soruların LaTeX doğrulaması, kalite güvencesi ve çevrim içi yayınlanması için geliştirilmiş, FastAPI servislerine dayanan bir React uygulamasıdır.

Bu bölümdeki diğer sayfalar

Projeler