LLM Pipeline’larında Veri Kirliliği ve RegEx Güvenliği: Yapay Zeka Çıktılarını Temizlerken Nerede Patlıyoruz?
Yazılımda neredeyse elli yıldır değişmeyen gayriresmi bir kural vardır: Çözemediğin bir metin ayrıştırma problemi mi var? Yapıştır bir RegEx (düzenli ifade), arkana yaslan. Oysa modern NLP sistemlerinde ve hayatımızın merkezine oturan LLM’lerde (Büyük Dil Modelleri) işler artık bu kadar basit değil. Yapay zekânın ürettiği ya da işlediği metinleri geleneksel yöntemlerle temizlemeye kalktığınızda işin ucu ciddi bir güvenlik zafiyetine ve çöken sunuculara varabiliyor.
Kendi pipeline’larımda birkaç kez “Neden bu sunucu saatlerdir %100 CPU kullanıyor?” krizi yaşadım. Sonunda meseleyi masaya yatırmaya karar verdim. Gelin, LLM çıktılarının klasik yöntemleri nasıl bozguna uğrattığını testlerle inceleyelim.
Klasik çekiç, kuantum çiviye karşı: RegEx nerede çuvallıyor?
Geleneksel yazılımda veri öngörülebilirdir. Bir formdan gelen e-posta adresi bellidir: Birkaç harf, bir @ işareti, biraz daha harf ve bir nokta. Ancak bir LLM’e “Bana metindeki iletişim bilgilerini çıkar” dediğinizde model size yalnızca e-posta vermez. Bazen Markdown blokları, bazen açıklama cümleleri, bazen de görünmez Unicode karakterleri hediye eder.
Geliştiriciler hemen şu refleksi gösterir: “Araya bir regex atar, temizlerim.” Fakat LLM çıktılarının doğası üç temel problem barındırır:
- Sıfır genişlikli (zero-width) karakterler: LLM’ler internetten beslenir. Kopyalanan metinlerin içinde görünmeyen boşluklar (örneğin
\u200B) veya sağdan sola yazım (RTL) işaretleri bulunabilir. Sizin “temiz” sandığınız regex bu karakterleri atlarsa veri tabanınız sessizce kirlenir. - Halüsinasyon kaynaklı format bozulmaları: Modele “Sadece saf JSON ver” deseniz bile model bazen keyifli bir günündeyse cevabın başına
```jsonekler, sonuna daUmarım bu yardımcı olmuştur!iliştirir. - Tipografik tırnak tuzağı: Model düz tırnak (
") yerine akıllı tırnak (“veya”) ürettiğinde basit bir JSON parser veya regex pattern’i anında iflas eder.
Korkulu rüya: ReDoS (Regular Expression Denial of Service)
İşin en tehlikeli boyutu güvenlik. Bir LLM pipeline’ında kullanıcı girdisi önce modele gidiyor, modelden çıkan yanıt da sizin yazdığınız bir regex filtresinden geçiyorsa kapınızı ReDoS saldırılarına ardına kadar açmış olabilirsiniz.
ReDoS, kötü kurgulanmış bir regex ifadesinin karmaşık veya beklenmedik uzunluktaki bir metinle karşılaştığında “catastrophic backtracking” (yıkıcı geri izleme) yaşamasıdır. Regex motoru eşleşmeyi bulabilmek için milyarlarca kombinasyon dener ve işlemciyi kilitler.
Küçük bir laboratuvar testi yapalım. Masum görünen şu deseni ele alalım:
import re
import time
# Masum görünen ama tehlikeli bir regex
pattern = re.compile(r"^(a+)+$")
# LLM'in beklenmedik şekilde ürettiği uzun ve hatalı bir string
dirty_llm_output = "a" * 30 + "!"
start = time.time()
pattern.match(dirty_llm_output)
print(f"İşlem süresi: {time.time() - start:.2f} saniye")
Yalnızca 30 karakterlik bu metin bilgisayarınızda saniyeler süren bir donmaya sebep olur. Karakter sayısını 35’e çıkardığınızda işlem dakikalar alır, 40 yaptığınızda ise sunucunuz fişi çeker. LLM’in sentetik veri üretirken araya sıkıştırdığı saçma bir tekrar dizisi tüm API servisinizi çökertebilir.
Modern temizleme stratejileri
LLM çıktılarını temizlemek için regex cambazlığı yapmak yerine problemi kaynağında çözen yaklaşımlara geçmek şart. Test ettiğim ve pipeline’larda güvenle çalışan üç ana yöntem var:
1. Şema tabanlı zorlama (Grammar-Guided Generation)
Modelin kafasına göre çıktı üretmesine izin verip sonra arkasını süpürmek yerine, modeli üretirken kısıtlayın. Outlines veya llama.cpp’nin Grammar özellikleri, modelin token üretirken yalnızca geçerli bir JSON veya belirli bir regex formatına uymasını zorunlu kılar. Kural dışı tek bir karakter bile üretilemez.
2. Doğrulama katmanları (Pydantic ve Instructor)
Python ekosistemindeyseniz Instructor kütüphanesi işinizi çok kolaylaştırıyor. OpenAI veya yerel modellerin fonksiyon çağırma (function calling) yeteneğini kullanarak çıktıyı doğrudan bir Pydantic modeline dönüştürüyor. Tip uyuşmazlığı varsa regex ile uğraşmak yerine modeli otomatik olarak uyarıp hatayı düzelttiriyor.
3. Güvenli regex motorları
Regex kullanmaktan başka çareniz yoksa Python’ın yerleşik re modülü yerine Google’ın geliştirdiği re2 kütüphanesini kullanın. re2, backtracking mekanizmasını sınırlandırarak doğrusal zamanda çalışır; yani ReDoS saldırılarına karşı bağışıktır.
Hangi yaklaşım ne kadar mantıklı?
Testlerimde öne çıkan araçların artılarını ve eksilerini şöyle özetleyebiliriz:
| Yöntem / Araç | Güvenlik | Geliştirme Hızı | Artıları | Eksileri |
|---|---|---|---|---|
| Klasik RegEx | Düşük | Hızlı (Başlangıçta) | Ek kütüphane gerektirmez, hafiftir | ReDoS riski, görünmez karakterleri kaçırma |
| Google re2 | Yüksek | Hızlı | ReDoS imkansızdır, güvenlidir | Lookaround gibi bazı gelişmiş özellikleri desteklemez |
| Instructor + Pydantic | Çok Yüksek | Orta | Tipe dayalı tam veri garantisi, otomatik düzeltme | Modelin function calling desteğine bağımlı |
| Guardrails AI | Çok Yüksek | Yavaş (Öğrenme eğrisi var) | Kurumsal doğrulama kuralları, hazır kalıplar | Pipeline’a ek gecikme (latency) ekleyebilir |
Fiyat ve ücretsiz alternatifler
Bu çözümleri projenize entegre ederken cebinizden büyük paralar çıkmak zorunda değil:
- Tamamen ücretsiz ve açık kaynak:
google-re2,OutlinesveInstructorkütüphaneleri 0 TL. Hepsi açık kaynak ve MIT lisanslıdır, yalnızca tükettiğiniz LLM API maliyetiyle çalışırlar. - Guardrails AI: Açık kaynaklı temel kütüphanesi ücretsizdir. Ancak ekipler için sundukları bulut tabanlı hazır hub çözümleri, kullanım hacmine göre ücretlendirilen freemium bir modele sahiptir.
- Yerel çözüm (en ucuzu): Ollama veya vLLM ile kendi sunucunuzda açık kaynaklı bir model (örneğin Llama 3 veya Mistral) koşturup üzerine Outlines eklerseniz hiçbir API faturası ödemeden tamamen güvenli bir temizleme pipeline’ı kurabilirsiniz.
Son söz: çekici yere bırakma zamanı
Yapay zekâ modelleri deterministik (her zaman aynı sonucu veren) makineler değildir; doğaları gereği olasılıksaldır. Olasılıksal bir sistemin çıktısını, 1970’lerden kalma katı kurallarla çalışan geleneksel RegEx desenleriyle evcilleştirmeye çalışmak sunucunuza yapacağınız en büyük haksızlıktır.
Pipeline’ınızda regex kullanmaya devam edebilirsiniz. Ama onu ilk savunma hattı olarak değil, şema kontrollü filtrelerin arkasındaki son güvenlik ağı olarak konumlandırmak en mantıklı strateji olacaktır.