Uzun Doküman ve Context ile Çalışmak: Yerleşim, Alıntı İstemek, Bölmek ve Prompt Caching'e Uygun Sıralama

Sürüm notu: Bu yazıdaki kodlar .NET 10 ile derlenip denenmiştir; Microsoft.Extensions.AI 11.0.0, OllamaSharp 5.5.2 ve xUnit v3 4.0.3 kullanılmıştır. Model çıktıları ve süre ölçümleri yerelde Ollama 0.34.4 üzerinde çalışan küçük bir açık model olan gemma3:4b'den (4,3 milyar parametre, Q4_K_M) alınmıştır; bulut sağlayıcıyla koşulmamıştır. OpenAI ve Anthropic'in prompt caching kuralları 15 Kasım 2026'da resmi dokümanlarından okunmuştur.

Önce Tahmin Et

Sitedeki serilerin ortak örnek uygulaması Bookstore'un (bir online kitapçı) satın alma ekibi, kitap tedarikçisiyle imzalanan sözleşme hakkında sürekli aynı türden sorular soruyor: hasarlı kitabı kaç gün içinde bildirmeliyiz, satılamayan stokun ne kadarını iade edebiliriz, kargoyu kim öder? Sözleşme 31 madde ve üç ekten oluşuyor; yaklaşık 14.500 kelime, basılı hâliyle kırk sayfa civarı. Cevapların bir kısmı Madde 17'de, bir kısmı ise sondaki değişiklik protokolünde, Ek-3'te; Ek-3, Madde 17'nin iki hükmünü değiştiriyor.

Model 128 bin token'lık bir context window'a sahip; sözleşmenin tamamını prompt'a koyup soruyu sormak en kolay yol. Üç şeyi tahmin et: sözleşme kaç token? Dokümanı soru ile talimatın önüne mi, arkasına mı koymalısın? Modelden cevabını sözleşmeden alıntılarla desteklemesini istersen doğruluk artar mı?

Context Bütçesi: Önce Token'ı Say

Sözleşme Türkçe ve gemma3'ün tokenizer'ı Türkçe metni İngilizceye göre daha fazla parçaya bölüyor: 14.500 kelime 33.496 token ediyor. Bu sayıyı tahminle değil, ölçerek bulmak gerekiyor; çünkü context window'un ne kadarının kullanılabileceği modelin iddia ettiği sayıdan değil, çalıştırdığın ortamdan geliyor. Ollama'da context uzunluğu istek başına num_ctx ile veriliyor; varsayılan değer bu sözleşmeye yetmeyecek kadar küçük. Lab'de bunu ChatOptions.AdditionalProperties üzerinden geçiyoruz:

// Ollama'nın context window'u istek başına ayarlanır; varsayılan bu sözleşmeye yetmez
public static ChatOptions Options(int contextTokens)
{
    ChatOptions options = LabClient.Options();
    options.AdditionalProperties = new() { ["num_ctx"] = contextTokens };
    return options;
}

Aynı soruları num_ctx 32.768 ile sorduğumda hiçbir hata almadım; cevaplar geldi, JSON geçerliydi. Yalnız Ollama'nın log'unda şu satır vardı ve her cevabın Usage.InputTokenCount değeri 33.600 yerine 16.387'ydi:

level=WARN source=llama_server.go:320 msg="truncating input prompt" limit=16387 prompt=33654 keep=5 new=16387

Ollama prompt'u sessizce kırpmış ve model sözleşmenin yarısını hiç görmemiş. Bu koşuda altı sorudan yalnız biri geçti; ikisinin cevabı Ek-3 yerine Madde 17'nin eski hükümlerine dayanıyor. Uzun doküman gönderen her kodun, yanıttaki input token sayısını beklenen sayıyla karşılaştırması gerekiyor: fark varsa cevap kullanılmamalı. Bulut sağlayıcılar context'i aşan isteği genellikle hata ile reddediyor; yerel sunucular ve bazı gateway'ler ise kırpabiliyor. Context bütçesinin RAG (cevaptan önce ilgili doküman parçalarını bulup modele veren yaklaşım) tarafı, yani kaç parçanın sığacağı ve düşük skorda "bilmiyorum", RAG serisinin "Prompt'a Context Koymak" yazısında.

Doküman Nereye: Başa mı, Sona mı?

Anthropic'in prompting rehberi uzun dokümanları prompt'un başına, sorunun, talimatların ve örneklerin üstüne koymayı öneriyor; kendi testlerinde sorunun sona konmasının, özellikle çok dokümanlı girdilerde, cevap kalitesini yüzde 30'a kadar artırabildiğini belirtiyor. Ayrıca dokümanı kaynak bilgisiyle birlikte etiketlemeyi öneriyor. Prompt builder iki yerleşimi de üretebiliyor:

// Sabit kısım (doküman) başta, değişen soru sonda; ya da tersi
BuildUser: question => placement == Placement.DocumentFirst
    ? $"{document}\n\n<question>{question}</question>"
    : $"<question>{question}</question>\n\n{document}",

document değişkeni sözleşmeyi <document source="supplier-contract-tr.md"> etiketiyle sarıyor. Test seti altı soru: Ek-3'ün değiştirdiği iki hüküm, Madde 17'den üç hüküm ve sözleşmenin hiç düzenlemediği bir konu (e-kitap iadesi), ki doğru cevabı NOT_FOUND.

Cevabı Alıntıya Dayandırmak

v1'de model yalnız cevap yazıyor. v2'de önce sözleşmeden ilgili maddeleri kelimesi kelimesine madde numarasıyla kopyalıyor, sonra cevabı yalnız bu alıntılara dayanarak yazıyor. Şemada Quotes alanı Answer'dan önce geliyor; model JSON'u yukarıdan aşağı ürettiği için alıntıları cevaptan önce yazmış oluyor:

// Şemada alıntılar cevaptan önce gelir, model de önce onları yazar
public sealed record GroundedAnswer(List<ContractQuote> Quotes, string Answer);

Grader iki şeyi ayrı kontrol ediyor: cevapta beklenen bilginin geçmesi (Türkçe büyük-küçük harf kurallarıyla; "TEDARİKÇİ" ile "tedarikçi" eşleşsin diye tr-TR CompareInfo kullanılıyor) ve her alıntının sözleşmede gerçekten geçmesi. Beklenen bilgi "10 iş gün" gibi bir kök olarak yazılı; ilk denemede "10 iş günü" yazmıştım ve model "on (10) iş güne düşmüştür" dediği için doğru cevap başarısız sayıldı. Türkçe metinde anahtar kelime kontrolü ek almış hâlleri de kapsamalı. Doküman başta, iki sürüm (v2'nin cq-02 ve cq-06 satırlarını ve uzun alıntı listelerini kısalttım; v1'in ilk sorusu 2,2 saniye sürdü, çünkü aynı önek bir önceki koşudan bellekteydi, nedeni aşağıda):

dotnet run --project src/Bookstore.Prompts.Lab -- contract ask v1 doc-first
PASS cq-01   2.2s in=33628 Madde 17'ye göre hasarlı bir kitabı tedarikçiye on beş (1...
PASS cq-02   3.4s in=33621 Madde 17.2'de belirtilen on beş (15) günlük bildirim süre...
PASS cq-03   1.5s in=33616 Madde 17.1'e göre, kusurlu kitapların iadesinde kargo ücr...
PASS cq-04   3.8s in=33612 Teslimatın Madde 9'da belirtilen süreyi aşması halinde TE...
FAIL cq-05   2.0s in=33614 answer "Madde 17.2'de belirtilen on beş (15) günlük bildirim süre..." lacks 6 ay|altı (6) ay|altı ay
FAIL cq-06   1.1s in=33614 expected NOT_FOUND, got "Hayır, sözleşmede e-kitapların iadesiyle ilgili bir hüküm..."
4/6 passed

dotnet run --project src/Bookstore.Prompts.Lab -- contract ask v2 doc-first
FAIL cq-01  44.9s in=33661 no quote from Ek-3 (cited: 17.1, 3.1)
FAIL cq-03   4.4s in=33649 answer "BOOKSTORE, kusurlu kitapların iadesiyle ilgili kargo ücre..." lacks tedarikçi; no quote from 17.6 (...)
FAIL cq-04   3.4s in=33645 answer "TEDARİKÇİ, iade edilen kitapları teslim tarihinden itibar..." lacks 30 gün|otuz (30) gün|otuz gün; 1/1 quotes not in the contract; no quote from 17.7 (cited: 27.2)
FAIL cq-05   4.6s in=33647 1/1 quotes not in the contract
0/6 passed

İlk bakışta v1 iyi, v2 felaket. Ama v1'in 4/6'sına yakından bakınca tablo değişiyor. cq-03'ün cevabı doğru (kargoyu tedarikçi öder), ama dayanağı olarak "Madde 17.1" deniyor; hüküm 17.6'da. cq-02'nin cevabı soruyla ilgisi olmayan bildirim süresiyle başlıyor ve doğru oran (%30) ancak ikinci cümlede geliyor. cq-04'ün cevabının yarısı Madde 22'deki gecikme cezasından bahsediyor. v1'in geçen cevapları, kontrol ettiğimiz kelime cevapta bir yerde geçtiği için geçti; modelin sözleşmeyi gerçekten doğru yerden okuduğunu gösteren hiçbir şey yok.

v2 aynı zayıflığı görünür kılıyor. Alıntıların çoğu sözleşmede yok: model maddeleri kendi cümleleriyle yeniden yazmış, madde numaralarını karıştırmış (17.4'ün metnine "17.1" demiş) ve cq-04'te var olmayan bir "Madde 27.2" uydurmuş; o maddeye göre kredi notu 30 değil 15 gün içinde düzenleniyor. cq-05'te cevap doğru, ama alıntı kelimesi kelimesine değil. 4 milyar parametrelik bir model, 33 bin token'lık bir metinden birebir alıntı yapmakta zorlanıyor; alıntı istemek onu daha doğru yapmadı, ama yanlışlarını kodla yakalanabilir hâle getirdi. Production'da v1'in "doğru görünen" cevaplarından birine güvenip iade sürecini kaçırmak, v2'nin "kaynağını gösteremedim" demesinden çok daha pahalı.

Soru Başta Olunca Ne Oluyor?

Aynı v2 prompt'unu soru başta, doküman sonda olacak şekilde koştum. Sonuç yine 0/6, ama hata türü değişti: cq-01'de model 37 alıntı döktü ve bunların 13'ü sözleşmede yok; cq-03'te 258 saniye boyunca üretmeye devam etti ve sonunda geçerli bir JSON bile çıkmadı. v1'i soru başta koşunca skor yine 4/6, ama cevaplar daha dağınık: cq-01 "Madde 1'de belirtildiği üzere" diye başlıyor, cq-05 "bu süre 10 aylı geçtikten sonra" gibi anlamsız bir cümleyle bitiyor. Bu tek model ve altı soruluk sette yerleşimin doğruluk farkını sayıyla iddia etmek için veri yetersiz; ama bir farkı kesin gösteriyor: süre. Doküman başta olduğunda ilk sorudan sonraki her soru birkaç saniyede cevaplandı, soru başta olduğunda her soru sıfırdan 35–40 saniye işlendi. Sebebi bir sonraki bölümün konusu.

Sabit Kısım Başa: Prompt Caching

Model bir prompt'u işlerken her token için bir ara durum (KV cache) hesaplıyor. Sonraki istek aynı önekle başlıyorsa bu hesap yeniden yapılmak zorunda değil. Ollama'nın altında çalışan llama.cpp sunucusu, bir önceki isteğin önekini bellekte tutup aynı başlangıçlı yeni istekte yeniden kullanıyor. Aynı üç soruyu iki yerleşimle sırayla sorup modelin prompt'u işlemesinin ne kadar sürdüğünü ölçüyoruz; süre OllamaSharp'ın ham yanıtındaki PromptEvalDuration alanından geliyor:

ChatDoneResponseStream? done = response.RawRepresentation as ChatDoneResponseStream;
double promptSeconds = (done?.PromptEvalDuration ?? 0) / 1e9;

dotnet run --project src/Bookstore.Prompts.Lab -- contract cache
DocumentFirst  cq-01 total  42.7s prompt eval  35.9s tokens 33661
DocumentFirst  cq-02 total   7.8s prompt eval   0.2s tokens 33654
DocumentFirst  cq-03 total   4.1s prompt eval   0.2s tokens 33649
QuestionFirst  cq-01 total 116.8s prompt eval  35.9s tokens 33661
QuestionFirst  cq-02 total  41.3s prompt eval  36.1s tokens 33654
QuestionFirst  cq-03 total 252.4s prompt eval  36.2s tokens 33649

Doküman başta olduğunda ilk soru sözleşmenin tamamını 35,9 saniyede işliyor; sonraki iki soruda prompt işleme 0,2 saniyeye iniyor, çünkü system prompt'tan sözleşmenin sonuna kadar her şey aynı ve yalnız sondaki soru yeni. Soru başta olduğunda ilk birkaç token her istekte farklı ve önekten sonraki hiçbir şey yeniden kullanılamıyor: her soru yine 36 saniye. Token sayısı iki durumda da aynı, maliyetin nereye gittiği farklı. (cq-03'ün 252 saniyelik toplam süresinin büyük kısmı prompt işleme değil, modelin durmadan alıntı üretmesi.)

Bulut sağlayıcılarda aynı mantık bir fiyat kalemine dönüşüyor. OpenAI'ın dokümanına göre prompt caching desteklenen modellerde varsayılan olarak açık; cache, prompt'un başının birebir aynı olmasını istiyor; GPT (OpenAI'ın güncel model ailesi) 5.6 ve sonrasındaki modellerde cache'lenebilir önek en az 1.024 token olmalı ve cache'ten okunan token sayısı yanıttaki usage.input_tokens_details.cached_tokens alanında görünüyor. Rehber, sabit içeriği (talimatlar, tool tanımları, referans metin) başa, değişen içeriği sona koymayı ve eski mesajları yeniden yazmak yerine yenilerini eklemeyi öneriyor. Anthropic'te önek sırası tools, system ve messages; cache'in nerede biteceği cache_control ile işaretleniyor (en fazla dört nokta) ya da istek düzeyinde otomatik caching açılıyor. Varsayılan ömür beş dakika ve her isabette yenileniyor; cache'e yazmak taban input fiyatının 1,25 katı, okumak çoğu modelde 0,1 katı. Önek, model ailesine göre 512 ile 4.096 token arasında bir alt sınırın altındaysa sessizce cache'lenmiyor. Ayrıntılar ve güncel fiyatlar sağlayıcı serilerinde (Claude API ile Uygulama Geliştirme) ve resmi dokümanlarda; bu rakamlar 15 Kasım 2026 tarihli.

Bunun prompt tasarımına etkisi basit bir kural: prompt'u en az değişenden en çok değişene doğru sırala. System prompt ve tool tanımları en başta, referans doküman onlardan sonra, kullanıcıya veya isteğe özgü her şey (soru, tarih, kullanıcı adı) en sonda. System prompt'a "bugünün tarihi" gibi her istekte değişen bir değer koymak, arkasındaki bütün öneki her istekte geçersiz kılar. Bir önceki yazıdaki terim sözlüğü gibi sabit parçaları da prompt'un başında, her istekte aynı sırayla tutmak gerekiyor; C#'ta bir Dictionary'yi dolaşırken sıranın sabit olduğundan emin olmak bu yüzden önemli.

Bölmek: Map-Reduce

Küçük model 33 bin token'dan birebir alıntı yapamıyorsa, ona daha küçük parçalar vermek akla gelen çözüm. Map-reduce iki adımdan oluşuyor. Map adımında sözleşme dört maddelik parçalara bölünüyor ve her parçadan iadeyle ilgili maddeler kelimesi kelimesine toplanıyor. Kod, toplanan her alıntıyı sözleşmede arıyor ve bulamadıklarını atıyor. Reduce adımında sorular, yalnız bu doğrulanmış alıntılardan oluşan kısa bir dokümana soruluyor. Map prompt'u:

System: """
    You read one part of Bookstore's supplier contract. Copy, word for word, the clauses
    in this part that are about BOOKSTORE returning books to the supplier: notice
    deadlines, limits on unsold stock, who pays return shipping, credit notes, and any
    clause that explicitly changes one of those return clauses.
    General clauses about notices, documents, cooperation, payments or penalties do not
    count. Clause is only the number, such as "17.2" or "Ek-3.1".
    Return at most 8 clauses, and an empty list if this part has none.
    """,

Bu prompt ikinci sürüm. İlk sürümde "en fazla" sınırı yoktu ve parçalar altı maddelikti; üçüncü parçada model 80'den fazla alıntı yazarken çıktı yarıda kesildi ve JsonException ile bütün koşu düştü. Şimdi çıktı 2.048 token'la sınırlı ve geçersiz JSON dönen parça atlanıyor:

ChatOptions mapOptions = Options(16384);
mapOptions.ResponseFormat = ContractPrompts.Map.Format;
// Küçük bir model madde saymayı bırakmayabilir; çıktıyı sınırla, yarım kalan cevabı başarısız parça say
mapOptions.MaxOutputTokens = 2048;

dotnet run --project src/Bookstore.Prompts.Lab -- contract map
map chunk 1: 8 quotes, 8 found in the contract: 1.1. Sözl..., 1.11. Söz..., 2.1. Bu m..., 2.9. Tanı..., 2.18. Tar..., 3.14. BOO..., 3.17. Tar..., 4.1. Ürün...
map chunk 5: 6 quotes, 6 found in the contract: 17.2. Has..., 17.3. Sür..., 17.4. BOO..., 17.5. İad..., 17.6. Kus..., 17.7. TED...
map chunk 9: 2 quotes, 2 found in the contract: Ek-3.1. M..., Ek-3.2. M...
FAIL cq-01 answer "Ocak 2027'de teslim alacağımız kitaplar için hasarlı bir ..." lacks 10 iş gün|on (10) iş gün|on iş gün; no quote from Ek-3 (...)
PASS cq-02 Okul siparişleri için aldığınız kitaplarda satılamayan st...
PASS cq-03 Kusurlu kitapların iadesinde kargo bedeli TEDARİKÇİ'ye ai...
PASS cq-04 TEDARİKÇİ, iade edilen kitapları teslim aldığı tarihten i...
PASS cq-05 BOOKSTORE, satılamayan kitapları yayın tarihinden itibare...
FAIL cq-06 expected NOT_FOUND, got "BOOKSTORE, satılamayan kitapları yayın tarihinden itibare..."
4/6 passed, 65 quotes collected, 68182 input tokens in total

Çıktıdan dokuz parçanın üçünü bıraktım. Map adımı kusursuz değil: model neredeyse her parçadan tam sekiz alıntı döndürdü; "en fazla 8" talimatını "8 tane bul" diye okumuş gibi. Toplanan 65 alıntının çoğu iadeyle ilgisiz. Ama iki önemli şey doğru: Madde 17'nin altı fıkrası ve Ek-3'ün iki fıkrası eksiksiz ve birebir toplandı, çünkü dört maddelik bir parçada birebir kopyalamak 33 bin token'lık bir metinden kopyalamaktan çok daha kolay.

Reduce sonucu 4/6 ve bu kez geçen her cevap doğru maddeden, sözleşmede birebir geçen bir alıntıyla geliyor: cq-02'de 17.4 ve Ek-3.2 birlikte alıntılanıp %30 sonucuna varılmış. cq-01'de model Ek-3.1'i görmesine rağmen 17.2'nin eski 15 günlük süresini kullandı; değişiklik ilişkisini kuramadı. cq-06'da yine NOT_FOUND yerine konuyla ilgisiz bir madde döndü. Toplam maliyet 68.182 input token: dokuz map çağrısı ve altı kısa reduce çağrısı. Tam dokümanla altı soru, cache olmadan 200 bin token'ın üstünde; cache ile ise pratikte bir kez 33.600 token işlenip sonra yalnız sorular işleniyor. Map-reduce tek soruluk bir iş için pahalı; aynı dokümana çok soru sorulacaksa map sonucu bir kez üretilip saklanabilir. Map adımının yaptığı iş, bir anlamda ilgili parçaları bulmak; aynı işi embedding ile yapan yaklaşım RAG serisinin konusu.

Üretimde Dikkat

Input token sayısını her istekte kontrol et. Ollama'daki sessiz kırpma, uzun doküman gönderen her sistemde olabilecek bir hatanın en temiz örneği. Gönderdiğin token sayısını tokenizer'la ya da bir önceki ölçümle tahmin et, yanıttaki Usage.InputTokenCount ile karşılaştır ve tutmuyorsa cevabı kullanma.

Alıntıyı kodla doğrula ve doğrulanamayan cevabı insana gönder. Satın alma ekibi için "bu cevabın dayanağı bulunamadı, Madde 17 ve Ek-3'e bakın" mesajı, yanlış bir iade süresinden çok daha ucuz. Doğrulanmış alıntılar ekranda madde numarasıyla gösterilirse, kullanıcı cevabı sözleşmeyi açmadan kontrol edebilir.

Değişiklik protokollerini ayrı ele al. Ek-3 gibi bir ek, önceki maddeleri değiştiriyor; ne tam doküman ne de map-reduce bu ilişkiyi bu küçük modelde güvenilir şekilde kurdu. Doküman ekleri yapılandırılmış olarak (hangi ek hangi maddeyi, hangi tarihten itibaren değiştiriyor) tutuluyorsa, bu ilişkiyi koda vermek modelden çıkarmaktan daha güvenilir.

Prompt'un sırasını bir sözleşme gibi koru. Cache isabeti prompt'un baştan sona birebir aynı olmasına bağlı. Bir geliştiricinin system prompt'un başına bir satır eklemesi, bütün isteklerin cache'ten düşmesine ve maliyetin bir anda katlanmasına yol açabilir. Sağlayıcıların yanıtında cache'ten okunan token sayısını izleyip düşüşte alarm üretmek bu yüzden işe yarıyor.

Model ve doküman boyutuna göre yaklaşım seç. Bu yazıdaki sonuçlar 4 milyar parametrelik yerel bir modelden. Büyük bir bulut modeli 33 bin token'dan birebir alıntıyı çok daha iyi yapabilir; ama "yapıyor mu?" sorusunun cevabı yine aynı test setiyle ve aynı alıntı kontrolüyle verilir.

Sık Düşülen Tuzaklar

"Context window büyük, hepsini koyarım." Modelin desteklediği uzunluk, çalıştırdığın sunucunun ayarıyla aynı değil; bu kurulumda 128 bin token'lık model sözleşmeyi 16 bin token'a kırpılmış hâlde gördü. Sığdığında bile maliyet ve süre doküman uzunluğuyla büyüyor.

Anahtar kelime eşleşmesini doğru cevap sanmak. v1'in soru-başta koşusunda cq-02 geçti; cevap Madde 22'deki gecikme cezasını anlatıp sonuna "okul siparişlerinde yüzde otuz" ekliyordu. Kelime cevapta vardı, gerekçe yanlıştı.

Alıntı isteyip kontrol etmemek. Model alıntı yerine yeniden yazılmış cümleler ve uydurma madde numaraları üretebiliyor; bunları ayırmanın tek yolu alıntıyı kaynakta aramak.

Değişen bilgiyi prompt'un başına koymak. Soruyu, tarihi ya da kullanıcı bilgisini başa koymak, arkasındaki uzun dokümanın her istekte yeniden işlenmesi demek.

Türkçe metinde kesin kelime aramak. "10 iş günü" ile "10 iş güne", "yüzde otuz" ile "yüzde 30" aynı bilgiyi taşıyor. Kontrolü kök ve alternatiflerle yaz, büyük-küçük harfi tr-TR kurallarıyla karşılaştır.

Küçük Bir Deneme

★☆☆ contract ask v2 doc-first 16384 ile koş ve yanıtlardaki in= değerine bak. Kırpılan bir isteği yakalayıp hata fırlatan küçük bir kontrol ekle: gönderilen metnin token sayısını önceki ölçümden tahmin et ve InputTokenCount bunun yüzde 90'ının altındaysa cevabı reddet.

★★☆ Map adımına sözleşmedeki madde başlıklarını kullanan basit bir ön filtre ekle: yalnız başlığında ya da metninde "iade" geçen bölümleri ve "Ek-" ile başlayan bölümleri map'e gönder. Toplanan alıntı sayısı, toplam input token ve reduce skoru nasıl değişiyor?

★★★ Ek-3'ün değiştirdiği maddeleri koda ver: ContractDocument'a "Ek-3.1, 17.2'yi 2027-01-01'den itibaren değiştirir" bilgisini tutan bir liste ekle ve reduce'a giden alıntıları, değişen maddenin hemen arkasına değiştiren ek gelecek şekilde sırala. cq-01 ve cq-02'nin sonucu değişiyor mu?

Sıradaki yazıda kod üreten prompt'lara geçiyoruz: raporlama ekranı için doğal dilden yalnız okuma yapan SQL üretmek, test ve code review prompt'ları. Orada da aynı ilke geçerli olacak: modelin çıktısına güvenmek yerine onu derleyici, parser ve veritabanı ile doğrulamak.