Optik okuyucu cihazı olmadan sınav değerlendirme, doldurulmuş formun tarayıcıdan alınan görüntüsünü okuyan bir yazılımla yapılır. Kararın verildiği yer aracın hangi girdiyi kabul edeceğidir; yalnız fiziksel formu kabul eden bir kurulumda okuma merkeze bağlı kalır ve kâğıt yine yola çıkar. Vipkurum’un optik okuma aracında form yine elle dolduruluyor ve bir tarayıcıdan geçiyor; ortadan kalkan yalnızca cihazın kendisi.
Optik okuyucu cihazı değerlendirmeyi neden tek noktaya kilitler
Optik okuyucu bir cihazdır ve cihazlar bir yerde durur. Kurumun birden çok şubesi varsa okuma yeteneği o şubelerden yalnız birinde bulunur. Geri kalanı sınavını yapar, formları toplar ve okutmak için cihazın durduğu merkeze taşır. İlk kilit budur ve lojistiktir: değerlendirme takvimi kâğıdın yol süresine bağlanır.
İkinci kilit süreklilikte. Okuma yeteneği tek bir makinede toplandığında o makine arızalandığı gün bütün kurumun sınav değerlendirmesi olduğu yerde durur. Yedeği yoktur, çünkü yedeği ikinci bir cihaz satın almak demektir. Arıza tek bir şubeyi değil, cihaza bağlı bütün şubeleri bekletir. Kurum büyüdükçe bu tek noktanın taşıdığı yük de büyür; ama yükü taşıyan şey aynı tek makine olarak kalır.
Üçüncü kilit daha sessiz işler ve faturada hiç görünmez. Cihaz her formu okumaz; kabul ettiği bir form vardır. Bu, sınav formunun tasarımını kurumun değil cihazın belirlediği anlamına gelir. Kurum değerlendirme biçimini değiştirmek istediğinde önce cihazın kabul kriterlerine bakmak zorunda kalır. Soru sayısı, sütun düzeni, kitapçık türü alanı, öğrenci numarasının kaç haneli olduğu — hepsi cihazın izin verdiği çerçevenin içinde kalır. Kurumun kendi değerlendirme tanımı, bir donanımın kabul kriterlerinin altına yerleşir.
Üç kilit her kurumda aynı ağırlıkta hissedilmiyor. Tek binada çalışan, formu yıllardır değişmeyen ve formları zaten cihazın durduğu odada dolduran bir kurum için optik okuyucu ucuz ve doğru cevaptır. Taşıma yoktur, tasarım baskısı yoktur, arıza tek bir binanın işini durdurur. Kilitlerin bedeli şube sayısı ve form düzeni değişikliğinin sıklığı arttıkça büyür. Vipkurum’da iki koşul da tersineydi: şubeler kendi sınavlarını yapıyordu ve form düzeni kurumun kendi değerlendirme tanımına göre değişiyordu.
İşaretlemeyi cihazın optiği değil formun görüntüsü verir
Vipkurum’un optik form okuma aracında işaretlemeler formun görüntüsü üzerinde OpenCV ile çıkarılıyor. Değişen şey okumanın yapılıp yapılmadığı değil, nerede yapıldığı. Cihazlı düzende okuma donanım katmanında olur: sensör kâğıdın üzerinden geçer, işaretin karşılığını doğrudan üretir ve dışarıya bir sonuç verir. Görüntüden okuyan düzende okuma yazılım katmanında olur; görüntü analizi kodu aynı karşılığı formun piksellerinden üretir.
Yerin değişmesi tek başına bir kazanç değildir. Kazancı yaratan şey girdinin değişmesi. Cihaz fiziksel formu ister — kâğıdın kendisinin makinenin içinden geçmesi gerekir. Görüntü analizi katmanı formun görüntüsünü ister. Görüntü kopyalanabilir, ağ üzerinden taşınabilir ve aynı anda birden fazla yerde bulunabilir; kâğıt bunların hiçbirini yapamaz. Bu yüzden okuma yeteneği tek merkezde toplanmak zorunda kalmaz. Görüntü üretebilen her şube kendi sınavını kendi okutur, formlar merkeze taşınmaz.
Girdi kâğıt olduğu sürece coğrafya cihaza bağlı kalır. Okuma işini yazılıma taşımak tek başına şubeyi bağımsızlaştırmaz; şubeyi bağımsızlaştıran şey, okumanın girdisinin taşınabilir bir nesne olması. Aynı araç yalnız fiziksel formu kabul edecek biçimde kurulsaydı, merkezdeki cihazın yerini merkezdeki sunucu alırdı ve kâğıt yine yola çıkardı.
Görüntü analizi katmanı Python üzerinde çalışıyor. Platformun geri kalanı Laravel, MySQL ve Redis üzerinde duruyor; görüntü işleme buraya ayrı bir çalışma zamanı olarak, yalnız bu işi yapmak için girdi. Okunan formun sonucu yine platformun kendi kayıt düzenine düşüyor.
Zincirin ilk halkası özel bir cihaz değil, sıradan bir tarayıcı
Aracın gündelik kullanımı şu sırayla işliyor. Sınav biter, doldurulmuş formlar toplanır ve sıradan bir belge tarayıcısından geçirilir. Taranan görüntüler web arayüzünden yüklenir. Yükleme tamamlandığında Python tarafındaki okuma servisi Node.js üzerinden çağrılır. Servis her formun görüntüsünü okur, işaretlemeleri çıkarır ve sonucu geri döndürür. Sonuç Laravel tarafında MySQL kaydına yazılır.
Zinciri başlatan şey özel bir cihaz değil, ofiste zaten bulunan genel amaçlı bir tarayıcı. Tarayıcı bozulursa yerine başka bir tarayıcı konur. Bir tarayıcının tedarik süresi, fiyatı ve ikame edilebilirliği optik okuyucuyla aynı sınıfta değil. Süreklilik kilidi tam olarak burada gevşiyor: değerlendirme, yerine kolayca benzeri konabilen bir cihaza dayanıyor.
Zincirin öteki ucunda çıktının biçimi değişiyor. Cihazlı düzende değerlendirmenin çıktısı bir cihaz raporudur; basılır, dosyalanır ve gerekirse elle başka bir yere aktarılır. Burada çıktı bir veritabanı kaydı. Sınav sonucu platformun içinde duruyor: sorgulanabiliyor, öğrencinin kendi kaydına bağlanıyor, raporlara giriyor. Değerlendirme sonucu ile öğrencinin geri kalan kaydı arasında elle taşınan bir adım kalmıyor. Elle taşınan her adım, aynı bilginin ikinci kez yazıldığı yerdir ve hata oraya girer.
Tarama adımı ortadan kalkmıyor. Form yine kâğıt, yine elle dolduruluyor ve yine bir tarayıcıdan geçmek zorunda. Kaldırılan donanım özel optik okuyucudur, kâğıdın kendisi değil. Kazanç kâğıdın seyahat mesafesinde: eskiden merkeze gidiyordu, şimdi koridorun sonundaki tarayıcıya.
Form düzeni değiştiğinde iş tedarikten yazılıma geçer
Bir eğitim kurumu için form düzeni sabit bir şey değil. Değerlendirme biçimi değişir, soru sayısı değişir, kitapçık türü eklenir, forma yeni bir alan gerekir. Sorunun kendisi her iki düzende de aynı kalıyor: yeni düzen okunabilir olmalı. Farklı olan, cevabın adresi.
Cihazlı düzende cevabın adresi tedarik. Kurum ya cihazın kabul ettiği yeni formu bastırır ya da yeni düzeni okuyabilen bir cihaz alır. İkisi de bir satın alma süreci: teklif, sipariş, teslim, kurulum. Bu sürede sınav takvimi bekler; daha doğrusu takvim bir baskı işine ya da bir teslimat tarihine bağlanır. Kurumun kendi kararı, kurumun dışındaki bir zamana bağlanmış olur.
Görüntüden okuyan düzende cevabın adresi Python tarafındaki görüntü işleme kodu. Yeni form düzeni geldiğinde uyarlama orada yapılıyor; cihaz değişikliği ya da cihaza özel form tedariki gündeme gelmiyor. Sınav takvimi bu kez bir geliştirme işini bekliyor.
Uyarlama bedava değil. Her yeni form düzeni Python tarafında gerçek bir geliştirme işi: yeni düzenin geometrisi tanımlanır, okuma o geometriye göre uyarlanır, sonuç doğrulanır. Değişen şey maliyetin varlığı değil, türü ve adresi. Tedarik maliyeti dışarıya, tedarikçinin takvimine bağlıdır ve kurum onu yalnız bekleyebilir. Yazılım maliyeti içeride, bakımı sürdüren ekibin takvimine bağlıdır ve planlanabilir.
Servis sınırı bu uyarlamanın önkoşulu. Okuma servisi web katmanından ayrı bir süreç olarak duruyor: Node.js köprüsünün bir tarafında Laravel’in kayıt katmanı, öteki tarafında Python’un görüntü analizi var. Yeni bir form düzeni geldiğinde dokunulan yer görüntü analizi tarafı; web arayüzü, yükleme akışı ve kayıt yapısı yerinde kalıyor. İki katman tek süreçte iç içe geçseydi, her form düzeni değişikliği yükleme akışını ve kayıt yapısını da riske sokardı. Bu ayrımı sistem mimarisi çalışmasında baştan çiziyoruz, çünkü sonradan çekilen bir sınır aynı işi görmez.
Cihazla okuma ile görüntüden okuma yan yana
Tablo yeni bir olgu eklemiyor; yukarıdaki dört sorunun cevabını iki düzen için yan yana koyuyor.
| Soru | Optik okuyucu cihazıyla | Form görüntüsünden okumayla |
|---|---|---|
| Form nereye taşınır? | Cihazın durduğu tek merkeze; şube doldurulmuş formları fiziken taşır | Hiçbir yere; form bulunduğu yerde taranır, görüntü web arayüzünden yüklenir |
| Arıza neyi durdurur? | Cihaz arızası bütün kurumun sınav değerlendirmesini durdurur | Okuma bir yazılım servisidir; değerlendirme tek bir cihazın çalışır durumda olmasına bağlı değildir |
| Form düzeni değişince ne gerekir? | Cihaza özel form tedariki ya da cihaz değişikliği; çözüm tedarik meselesidir | Python tarafında yazılım uyarlaması; tedarik beklenmez |
| Şube ne kadar bağımsız? | Okuma için merkeze bağımlıdır | Şube kendi sınavını kendi okutur |
Sağ sütun her satırda soldakinden daha iyi değil; sağ sütun maliyeti başka bir yere taşıyor. İlk satırda kazanılan şey taşıma, üçüncü satırda ödenen şey geliştirme. Bir kurum için doğru seçim, hangi sütunun daha parlak göründüğüne değil, kaç şubesi olduğuna ve form düzenini ne sıklıkla değiştirdiğine bağlı.
Cevap anahtarı nereden gelir: kitapçıktan soruya, sorudan anahtara
Optik okuma sınavın bir ucunu okuyor: öğrencinin işaretlediği cevabı. Öteki uçta doğru cevabın kendisi var ve o da bir yerden gelmek zorunda. Vipkurum çatısı altında bu ikinci ucu ayrı bir araç taşıyor.
Soru kırpma aracında başlangıç noktası kurumun elindeki basılı soru kitapçığı. Kitapçık sayfası OpenCV ile tek tek soruya bölünüyor. Bu iş daha önce öğretmenin elindeydi: yeni bir test kuracak öğretmen soruları bir görüntü düzenleyicide kırpıyor, cevap anahtarını elle yazıyordu. Kırpma işi görüntü işleme katmanına geçti; sayfadan soruyu ayırmanın sınırlarını artık kod belirliyor.
Asıl değişiklik cevap anahtarının nerede durduğunda. Gemini ve OpenAI modelleri anahtardaki cevabı ilgili soruya bağlıyor ve doğru cevap ayrı bir belgede değil, kırpılan soru kaydının içinde duruyor. Bu bir düzen tercihi değil, bir hata sınıfının zeminini kaldırma kararı. Elle tutulan bir anahtarda tek satır kaydığında hata tek soruda kalmaz; kaymanın altındaki bütün soruların değerlendirmesi yanlışa döner. Üstelik bu hata sessizdir — sonuçlar tutarlı görünür, yalnız yanlıştır. Anahtar sorunun kendi kaydının parçası olduğunda kayacak bir satır kalmaz.
Araç üçüncü bir işi daha yapıyor. Elde olan sorular örnek alınıyor ve dil modeli aynı biçimde yeni soru yazıyor; her yeni sorunun cevap anahtarı soruyla birlikte üretiliyor. Kurumun elinde olmayan soru, elindekilerin biçimini taşıyarak havuza giriyor ve anahtarı, soru üretildiği anda yanında oluyor.
Kayıt tarafı da ayrı duruyor. Kırpılan görseller ve soru kayıtları MongoDB’de tutuluyor; Python görüntü işleme servisi Node.js üzerinden Laravel tarafındaki içerik yönetimine bağlanıyor. Optik okuma aracındakiyle aynı kalıp: görüntü işleme kendi sürecinde, kayıt ve arayüz platformun kendi katmanında.
Görüntü işleme ile dil modelinin sınırı nerede çizilir
Bu iki araçta hem görüntü işleme hem dil modeli var. Hangi işin hangi tarafa verildiği kurucu bir karar.
Soru sınırlarını görüntü işleme belirliyor. Bir sorunun sayfada nerede başlayıp nerede bittiği, kırpılan görselin neyi içerip neyi dışarıda bıraktığı OpenCV’nin işi. Bu karar dil modelinin yorumuna bırakılmadı. Bırakılsaydı soru sınırları güvenilmez olurdu: aynı sayfa iki kez işlendiğinde farklı sınırlar çıkabilir, bir sorunun şıkkı komşu sorunun görseline taşabilirdi. Sınır çizmek kesinlik isteyen bir iş ve kesinlik isteyen işler deterministik tarafta kalıyor.
Aynı ayrım optik okuma tarafında da geçerli. Doldurulmuş formdaki işaretlemeyi OpenCV çıkarıyor; dil modeli bu adıma hiç girmiyor. İşaretin okunması, yoruma açık olmaması gereken bir ölçüm.
Dil modeline kalan iki iş var. Birincisi anahtardaki cevabı ilgili soruya bağlamak; bu bir eşleştirme işi ve metnin anlamını gerektiriyor. İkincisi eldeki soruları örnek alıp aynı biçimde yeni soru yazmak; bu da bir üretim işi. İkisi de yorum gerektiriyor ve ikisi de görüntü işlemenin yapamayacağı işler. Kırpma görüntü işlemede, yorum dil modelinde kalıyor ve iki iş karışmıyor.
Modelin her işi yapabiliyor olması, her işi ona vermek için yeterli sebep değil: dil modeli, deterministik bir cevabı olan sorunun yerine geçmiyor. Model her işe girseydi araç daha az kod içerirdi, ama sınav değerlendirmesinin dayandığı iki ölçüm — işaretin yeri ve sorunun sınırı — yorumdan geçmiş olurdu.
Sınırın nereden geçeceği her problemde aynı değil. Deterministik sınır çizme, geometrisi belirli bir sayfada işler. Taranırken eğrilmiş, üzerine elle yazılmış ya da düzeni sayfadan sayfaya değişen belgelerde aynı yaklaşım zorlanır ve sınır başka bir yere kayar. Bu yüzden iş bölümünü hazır bir formül olarak taşımıyoruz; her problemde sınırın nereye düşeceği problemin kendi geometrisine bakılarak belirleniyor.
Sınavın iki ucu tek kayıtta buluşur
İki araç ayrı problemleri çözüyor ama aynı yerde buluşuyor. Soru kırpma aracı cevap anahtarını üretiyor, optik okuma aracı öğrencinin işaretlediği cevabı çıkarıyor. Değerlendirme, bu iki bilginin aynı sınav kaydında karşılaşmasıyla oluşuyor.
Bu buluşma kendiliğinden olmuyor. Her iki aracın da aynı platformun çatısı altında geliştirilmiş olmasından geliyor. Soru kırpma içerik yönetim katmanının yanında, optik okuma değerlendirme tarafında duruyor; ikisi de Laravel tarafındaki kayıt katmanına bağlanıyor. Ayrı ayrı satın alınmış iki ürün olsalardı aralarındaki bağ bir dışa aktarma dosyası ya da elle yapılan bir eşleştirme olurdu — ve o eşleştirme, kaldırılmak istenen hata sınıfını arka kapıdan geri getirirdi.
Vipkurum platformunun çatısı altında 7 kurum kendi alan adı ve markasıyla aynı çekirdek üstünde çalışıyor. İki görüntü işleme aracı da bu çekirdeğe bağlı. Bir kurumun sınav kaydı kendi sınırının içinde duruyor; araçların ürettiği anahtar ve işaretleme de aynı sınırın içinde kalıyor.
Bu tür işleri yapay zekâ danışmanlığı tarafında kurarken ilk sorduğumuz soru model seçimi olmuyor. Önce şu soruluyor: süreçte hangi adım bir cihazın, bir kâğıdın ya da elle yazılan bir belgenin üzerinde duruyor. Optik okumada cevap cihazdı, soru kırpmada elle tutulan anahtardı. Adımın nerede durduğu bilinmeden hangi aracın nereye gireceği de bilinmez; model seçimi o sorudan sonra gelen, çok daha küçük bir karar.
