teknofest-2026-kamu-evrak-akilli-ajan

Problem

Kamu kurumlarında bir evrak; okuma, türlendirme, içerik analizi, mevzuat kontrolü, taslak yazımı, birim yönlendirmesi ve arşivleme zincirinden geçiyor. Bu zincirin dört somut arızası var: adımlar tekrarlı ve elle yapılıyor; yasal süreler (4982, 3071, 2577, CİMER) kaçırılırsa hak kaybı doğuyor; aynı evrak farklı personelde farklı yorumlanıyor; kişisel veri içeren evraklar paylaşılırken maskeleme elle yapıldığı için KVKK riski taşıyor. Ek olarak kurum ağları çoğu zaman internetsiz, yani "bulut LLM çağır" çözümü sahada baştan geçersiz.

Yaklaşım

Ekip olarak zinciri 11 uzman ajan ve bir orkestratörle modelledik. Her ajan tek işten sorumlu; orkestratör onları paylaşılan bir durum nesnesi (AgentState, düz bir dataclass) üzerinde koşullu bir akışla çalıştırıyor, her adımın süresini ve güven skorunu ölçüyor. Akış düz bir döngü değil, üç kapısı var: Kapı 1 metin okunabilir mi (30 anlamlı karakter altı ise süreç erken durur), Kapı 2 metin Türkçe mi (değilse taslak atlanır ama analiz sürer), Kapı 3a/3b sınıflandırma ve yönlendirme güveni 0.6'nın üstünde mi (altındaysa karar gerekçesiyle insan onayı kuyruğuna düşer). Çekirdek zekâ LLM değil: kalibre edilmiş ağırlıklı kural skorlaması, saf Python BM25-Okapi ile mevzuat RAG'i ve saf Python Multinomial Naive Bayes; sınıflandırma bu ikisini 0.6 kural + 0.4 ML olarak birleştiriyor. LLM varsa yalnızca düşük güvenli kararlarda devreye giriyor. Üstüne akademik bir ölçüm katmanı var: ECE kalibrasyon, split conformal prediction (α=0.1), Chow reddetme kuralıyla seçici tahmin, metamorfik dayanıklılık ve McNemar anlamlılık testi.

Kararlar ve takaslar

• 01LangChain/LangGraph yerine dataclass + time üzerine kurulu özgün bir orkestratör yazdık, çünkü kamu senaryosunda güvenlik yüzeyini küçük tutmak, her adımı okunur ve test edilebilir kılmak, bağımlılık şişkinliğinden kaçınmak ve çevrimdışı çalışmayı garanti etmek gerekiyordu; alternatif hazır bir ajan framework'üydü — o durumda çekirdeğe ağır bir bağımlılık ve okunmayan bir akış girecekti.
• 02Sistemi çevrimdışı-öncelikli kurduk, LLM'i opsiyonel bıraktık, çünkü kurum ağları çoğu zaman internetsiz ve kişisel veri üçüncü taraf bir API'ye çıkamaz; alternatif LLM'i zorunlu bağımlılık yapmaktı, o zaman model erişimi tek nokta arıza (single point of failure) haline geliyordu. Bu kararın maliyeti, kural katmanını gerçekten iyi yazmak zorunda kalmaktı.
• 03Mevzuat benzerliğini rölatif normalizasyon yerine mutlak ölçekte, min(1, skor / 1.5·Σidf) ile raporladık, çünkü rölatif normalizasyon her sorguda "yüksek benzerlik" gösterip değerlendiriciyi yanıltıyor; mutlak ölçekte zayıf eşleşme (<0.5) açıkça işaretleniyor ve taslak gövdesinde ona atıf yapılmıyor (atıf eşiği 0.6). Alternatif kolay görünen rölatif skordu; onu bilinçli reddettik.
• 04İstatistiksel modeli sklearn/numpy yerine saf Python Multinomial Naive Bayes olarak yazdık, çünkü 52 evraklık küçük veri rejiminde NB güçlü ve şeffaf, ağırlıklar JSON'da okunabiliyor ve kural sınıflandırıcıyla 0.6/0.4 birleştirilebiliyor; öznitelik olarak kelime token'larının yanına karakter 3-gram'ı koyduk çünkü Türkçe sondan eklemeli — "başvuru/başvurunuz/başvurumun" kelime düzeyinde üç ayrı öznitelikken 3-gram'lar kökü paylaşıyor. Ayrıca Rennie ve ark. 2003'e dayanarak uzunluk normalizasyonu ekledik, çünkü NB'nin bağımsızlık varsayımı bağımlı öznitelikleri tekrar sayıp olasılıkları 0/1'e doyuruyordu.
• 05PII regex desenlerini tek doğruluk kaynağı yaptık: desenler info_extraction'da tanımlı, KVKK anonimleştirme ajanı onları import ediyor. Çünkü çıkarım ile maskeleme arasında desen ayrışırsa "çıkarılmış ama maskelenmemiş kişisel veri" sızıntısı doğuyor; alternatif her ajanın kendi desenini tutmasıydı ve o, bu hata sınıfını kaçınılmaz kılıyordu.

Sonuç

Depoda üretilmiş, elle düzenlenmeyen ölçüm dosyaları var; hepsinin çerçevesini olduğu gibi veriyorum. Sınıflandırma ve görev metrikleri (README değerlendirme tablosu, kaynak eval_report*.json): geliştirme seti (52 evrak) sınıflandırma 1.000 / birim yönlendirme 0.962 / eksik bilgi micro-F1 1.000 / mevzuat isabet@3 0.962; tutulmuş set (16) 1.000 / 1.000 / 1.000 / 0.875; tutulmuş v2 (16) 1.000 / 0.938 / 1.000 / 0.750; temiz adversarial v4 (16) 0.938 / 0.938 / 1.000 / 0.938. v4 raporu (data/processed/eval_report_heldout_v4.json) accuracy 0.9375 ve macro-F1 0.9333 diyor, koşum mührü git commit 869fe34, Python 3.12.10, Windows 11, LLM backend "offline" ve kullanılamaz — yani bu skorlar LLM'siz, tamamen kural tabanlı modda alınmış. Performans (data/processed/benchmark_raporu.json, 2026-07-12, Darwin arm64, 8 çekirdek, Python 3.9.6, 84 evrak × 5 tekrar = 420 ölçüm): verim 88.1 evrak/saniye, medyan gecikme 11.28 ms, p95 14.19 ms, p99 15.73 ms, tepe bellek 0.21 MB (tracemalloc) ve 1x/5x/10x ölçeklemede evrak başına süre 11.25/11.24/11.26 ms — yani ölçekleme doğrusal. Dayanıklılık (data/processed/dayaniklilik_raporu.json, tohum 1234, 52 evrak, 260 varyant): tür invaryansı 0.9923, birim invaryansı 0.9692; en kırılgan bozulma diyakritik kaybı (tür 0.9615, birim 0.8462), iki dosyada cevap_yazisi kararı ust_yazi'ya kayıyor. Teknik rapor 632 birim/entegrasyon testinin 16.07.2026 itibarıyla yeşil olduğunu söylüyor. En anlatmaya değer sonuç ise bir düşüş: geliştirme seti 12.07.2026'da 35'ten 52 evraka çıkarıldığında yönlendirme doğruluğu 1.000'den 0.962'ye indi ve iki hata, etiket hatası değil gerçek işlevsel belirsizlik olduğu için dosyaya özgü kural yazılarak DÜZELTİLMEDİ, olduğu gibi raporlandı. Aynı gelenek adversarial v3'te de sürüyor: kalan iki sınırlılık (rapor gövdesinin 5018'i ilk üçten itmesi, "yazınız" ikinci-şahıs sinyalinin cevap/üst yazı ayrımını zorlaması) v4'te de gözlendi ve dürüstçe açık bırakıldı. Yarışma değerlendirmesi henüz yapılmadı; bu sayfadaki hiçbir sayı yarışma sonucu değil.

Teknolojiler