Prompt Engineering vs Loop Engineering: Yapay Zekada Tek Atışlık Yanıttan Kendi Kendini İyileştiren Döngülere

Bir yapay zeka modeline soru sorduğunuzda aslında iki farklı dünyadan birini seçiyorsunuz: ya modelin tek seferde, tek bir nefeste doğru cevabı üretmesini bekliyorsunuz, ya da modelin kendi ürettiğini tekrar tekrar gözden geçirmesine, sınamasına ve düzeltmesine izin veriyorsunuz. Bu iki yaklaşım son birkaç yıldır “prompt engineering” ve “loop engineering” adları altında ayrı disiplinler haline geldi. Aralarındaki fark, sadece teknik bir tercih değil; maliyet, hız, güvenilirlik ve nihayetinde ürünün kalitesi arasında kurulan bir denge meselesi.

Bu yazıda, bir yazılımcının veya ürün ekibinin karşılaştığı en temel sorulardan birine derinlemesine bakacağız: Yapay zekayı iyi bir prompt yazarak mı kullanmalıyız, yoksa bir yapay zekanın ürettiğini başka bir yapay zekaya (ya da aynı modelin başka bir çağrısına) denetletip döngü halinde iyileştirerek mi? Bu sorunun cevabı sandığınızdan daha nüanslı; çünkü aslında iki yaklaşım birbirinin alternatifi değil, birbirini tamamlayan iki katman.

Konuya girmeden önce şunu netleştirmek gerekir: burada bahsedilen “loop”, klasik programlamadaki for veya while döngüsünden farklıdır. Klasik bir döngüde her adım deterministiktir ve aynı girdi her zaman aynı çıktıyı üretir. Yapay zeka bağlamındaki loop ise, her turunda modelin kendi ürettiği metni yeniden yorumladığı, olasılıksal (probabilistic) bir sistemdir. Bu fark, döngünün tasarımını ve durdurma koşullarını klasik yazılım mühendisliğinden çok farklı bir hale getirir; çünkü burada “hata” kavramı ikili (binary) değil, bir spektrumdur — bir çıktı yüzde yüz doğru ya da yüzde yüz yanlış olmak zorunda değildir, kısmen iyi de olabilir ve döngünün amacı bu kaliteyi kademeli olarak yükseltmektir.

Bu ayrımı anlamak, hem bireysel geliştiricilerin günlük iş akışlarında hem de kurumsal ürün ekiplerinin mimari kararlarında doğrudan etkili olur. Bir e-ticaret şirketinin ürün açıklamalarını otomatik üretmesi ile bir bankanın kredi risk raporunu otomatik hazırlaması aynı yapay zeka teknolojisini kullansa da, ikisinin doğruluk toleransı, dolayısıyla ihtiyaç duyduğu mühendislik yaklaşımı taban tabana zıttır. İlerleyen bölümlerde bu farkı somut örnekler, kod parçaları ve karar kriterleriyle ele alacağız.

1. Prompt Engineering Nedir? Tek Atışlık Zekanın Sınırları

Prompt mühendisliği, bir dil modelinden istenen çıktıyı almak için girdinin (prompt) dikkatlice tasarlanması sanatıdır. Rol tanımlama (“Sen deneyimli bir yazılım mimarisisin”), örnekler verme (few-shot learning), adım adım düşünmeyi teşvik etme (Chain-of-Thought) ve çıktı formatını net biçimde belirtme (JSON şema, XML etiketleri) bu disiplinin temel araçlarıdır.

Prompt mühendisliğinin cazibesi açıktır: tek bir API çağrısı, düşük gecikme (latency), öngörülebilir maliyet. Bir müşteri destek botunun basit bir soruyu yanıtlaması, bir e-postanın özetlenmesi ya da bir metnin belirli bir tona çevrilmesi gibi görevlerde iyi tasarlanmış bir prompt çoğu zaman yeterlidir. Modelin “System Prompt” katmanında verilen talimatlar, kullanıcı mesajıyla birleşerek modelin olasılık dağılımını istenen yöne kaydırır.

Ancak prompt mühendisliğinin temel bir sınırı vardır: model, ürettiği yanıtın doğruluğunu kendi kendine, gerçek dünyadan bağımsız bir şekilde denetleyemez. Bir dil modeli, sonraki tokeni tahmin ederken en olası kelimeyi seçer; bu, mantıksal olarak tutarlı olmasına rağmen faktüel olarak yanlış bir cümle üretmesine engel olmaz. Buna literatürde “halüsinasyon” denir ve tek atışlık (single-shot) bir promptla bu riski sıfıra indirmek mümkün değildir.

Prompt Mühendisliğinin Katmanları

Deneyimli bir mühendis, prompt tasarımını genellikle şu katmanlarda ele alır:

1. Bağlam (Context) Katmanı: Modele hangi bilgiyi, hangi sırayla vereceğinizi belirler. RAG (Retrieval-Augmented Generation) sistemleri burada devreye girer; model, kendi ağırlıklarındaki “donmuş” bilgi yerine, çalışma zamanında getirilen güncel dokümanlara dayanarak cevap üretir.
2. Talimat (Instruction) Katmanı: Görevin ne olduğunu, kısıtları ve beklenen formatı tanımlar.
3. Örnekleme (Few-shot) Katmanı: Modelin taklit edebileceği örnek girdi-çıktı çiftleri sunar.
4. Akıl Yürütme (Reasoning) Katmanı: “Adım adım düşün”, “önce planla sonra yaz” gibi talimatlarla modelin ara adımlarını (Chain-of-Thought) açığa çıkarır.

# Klasik Chain-of-Thought Prompt Örneği
system_prompt = """
Sen kıdemli bir veri mühendisisin. Kullanıcının SQL sorgusunu
optimize etmeden önce sırasıyla:
1. Sorgunun amacını özetle
2. Olası darboğazları listele
3. Optimize edilmiş sorguyu üret
adımlarını izle.
"""

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=800,
    system=system_prompt,
    messages=[{"role": "user", "content": user_query}]
)

Bu yaklaşım güçlüdür ama tavanı bellidir. Model ne kadar iyi bir prompt alırsa alsın, tek geçişte ürettiği çıktı, modelin o anki “en iyi tahmini"nden ibarettir. İşte tam bu noktada loop engineering devreye girer.

Rol Tabanlı Prompting ve Sınırları

Bir diğer yaygın prompt tekniği, modele belirli bir kimlik ya da uzmanlık ataması yapmaktır (“Sen bir güvenlik denetçisisin”, “Sen bir çocuk doktoru gibi açıkla”). Bu teknik, modelin eğitim verisindeki ilgili alt dağılımı (subdistribution) daha güçlü biçimde tetikleyerek, üslup ve terminoloji açısından daha tutarlı çıktılar üretmesini sağlar. Ancak burada dikkat edilmesi gereken önemli bir yanılgı vardır: rol ataması, modele gerçek bir uzmanlık kazandırmaz; sadece modelin zaten sahip olduğu bilgiyi belirli bir çerçeveden sunmasını sağlar. Bir modele “sen bir hukuk profesörüsün” demek, modelin hukuki muhakemesini iyileştirmez; sadece cevabın tonunu ve kelime seçimini bir hukuk profesörünün konuşma tarzına yaklaştırır. Bu ayrımı gözden kaçıran ekipler, rol promptlarının sihirli bir doğruluk artışı sağladığını zannederek yanlış bir güven duygusuna kapılabilir.

Benzer şekilde, few-shot örnekleme de belirli bir formatı ya da akıl yürütme desenini pekiştirmede son derece etkilidir, fakat modelin daha önce hiç görmediği bir problem türünde (out-of-distribution) aynı etkiyi göstermeyebilir. Prompt mühendisliğinin başarısı, büyük ölçüde görevin modelin eğitim dağılımına ne kadar yakın olduğuna bağlıdır; dağılımdan uzaklaştıkça, en iyi prompt bile modelin temel yeteneklerinin ötesine geçemez. İşte tam da bu sınırın aşılması gerektiği noktada — yani görevin doğruluğunun tek bir çıkarımla garanti edilemediği durumlarda — mühendisler loop engineering’e yönelir.

2. Loop Engineering Nedir? Döngüsel Zekanın Anatomisi

Loop engineering (döngü mühendisliği), bir yapay zeka çıktısının tek seferde nihai kabul edilmediği, bunun yerine bir üretim–değerlendirme–düzeltme (generate–evaluate–refine) döngüsüne sokulduğu yaklaşımdır. Burada kilit fikir şudur: Bir modelin bir şeyi üretmesi ile o üretilenin doğruluğunu denetlemesi, bilişsel olarak farklı görevlerdir. Bir model kod yazarken hata yapabilir, ama aynı modele (ya da başka bir modele) “bu kodu test et, hatası var mı bak” dediğinizde, model çoğu zaman kendi hatasını fark edebilir.

Bu, insan biliminde de bilinen bir olgudur: Bir metni yazan kişi kendi yazdığı hataları görmekte zorlanır, ama başka birinin yazdığı metindeki hataları çok daha kolay tespit eder. Yapay zeka modelleri de benzer bir asimetri sergiler; üretim ve eleştiri, farklı “dikkat” (attention) dağılımları gerektirir.

Döngünün Temel Bileşenleri

Bir loop engineering mimarisi genellikle dört bileşenden oluşur:

• Generator (Üretici): İlk çıktıyı üreten model veya prompt zinciri.
• Critic / Evaluator (Eleştirmen): Üretilen çıktıyı bir kriter setine göre puanlayan veya hatalarını işaretleyen ikinci bir model çağrısı, kural tabanlı bir doğrulayıcı ya da harici bir test paketi.
• Refiner (Düzeltici): Eleştirmenin geri bildirimini alarak çıktıyı güncelleyen model çağrısı.
• Durdurma Koşulu (Stopping Criterion): Döngünün ne zaman sonlanacağını belirleyen kural (maksimum iterasyon sayısı, kalite eşiği, maliyet bütçesi).

# Basit bir Generate-Evaluate-Refine döngüsü (kavramsal)
def loop_engineering(task, max_iterations=3, quality_threshold=0.9):
    output = generate(task)
    for i in range(max_iterations):
        score, feedback = evaluate(output, task)
        if score >= quality_threshold:
            break
        output = refine(output, feedback)
    return output, score

Bu basit şablon, günümüzde “agentic AI” (ajan tabanlı yapay zeka) olarak adlandırılan sistemlerin çekirdeğini oluşturur. LangGraph, AutoGen, CrewAI gibi orkestrasyon kütüphaneleri, aslında bu döngüyü daha karmaşık graf yapılarına genişleten araçlardır.

3. Actor-Critic Mimarisi: Bir Yapay Zeka Üretirken Diğeri Denetler

Loop engineering’in en olgun formu, pekiştirmeli öğrenmeden (reinforcement learning) ödünç alınan actor-critic kavramıdır. RLHF ve PPO’da gördüğümüz “policy” (aktör) ve “reward model” (eleştirmen) ayrımı, artık eğitim zamanından çıkıp çıkarım (inference) zamanına da taşınmış durumda.

Pratikte bu, şu şekilde çalışır: Bir “actor” model bir görevi yerine getirir (kod yazar, makale taslağı çıkarır, bir plan üretir). Ayrı bir “critic” model, bu çıktıyı önceden tanımlanmış bir rubrik (değerlendirme kriterleri) üzerinden puanlar ve somut, uygulanabilir geri bildirim verir. Actor bu geri bildirimi alarak yeniden dener. Bu süreç, insan bir editörün yazarın taslağını okuyup kenar notları düşmesine çok benzer.

LLM-as-a-Judge Yaklaşımı

Bu mimarinin en yaygın uygulama biçimi “LLM-as-a-Judge” (Yargıç Olarak Dil Modeli) yaklaşımıdır. Burada critic rolündeki model, actor’ün çıktısını 1-10 arası puanlar, ya da ikili karşılaştırma (pairwise comparison) yaparak “A mı daha iyi, B mi” diye karar verir. Bu yaklaşımın en büyük avantajı, insan değerlendirmesine göre çok daha ucuz ve hızlı olmasıdır; dezavantajı ise “yargıç” modelin kendi önyargılarını (bias) devralmasıdır — örneğin daha uzun yanıtları sistematik olarak daha kaliteli sanma eğilimi (length bias) literatürde sıkça belgelenmiştir.

def critic_prompt(output, rubric):
    return f"""
    Aşağıdaki çıktıyı şu kritere göre değerlendir: {rubric}
    Çıktı: {output}
    Yanıtını şu formatta ver:
    {{"score": <0-10 arası sayı>, "issues": [...], "suggestion": "..."}}
    """

Bu asimetrik yapı — üretim ve değerlendirmenin farklı “zihniyetlerle” ele alınması — GRPO (Group Relative Policy Optimization) gibi eğitim algoritmalarının çıkarım zamanındaki bir yansıması gibi düşünülebilir. GRPO’da model, aynı girdi için üretilen bir grup çıktıyı birbirine göre değerlendiriyordu:

Loop engineering’de de benzer bir mantık işler: mutlak bir “doğru cevap” yerine, birden fazla aday çıktı üretilir ve bunlar birbirine (ya da bir kritere) göre karşılaştırılarak en iyisi seçilir veya sentezlenir. Bu yaklaşıma “self-consistency” adı verilir ve özellikle matematiksel akıl yürütme görevlerinde tek bir yanıt yerine N farklı akıl yürütme zinciri üretip çoğunluk oyuyla (majority voting) nihai cevaba varmak, doğruluğu ciddi oranda artırır.

4. Self-Refine ve Reflexion: Modelin Kendi Kendini Düzeltmesi

Her zaman ayrı bir critic modele ihtiyaç yoktur. “Self-Refine” adı verilen teknik, aynı modelin kendi çıktısını kendisinin eleştirmesine dayanır. Model önce bir yanıt üretir, ardından “Bu yanıtı bir editör gözüyle incele, eksiklerini bul” talimatıyla kendi çıktısını eleştirir, sonra bu eleştiriyi dikkate alarak yanıtı günceller.

“Reflexion” mimarisi bunu bir adım öteye taşır: model, bir görevi denedikten sonra başarısız olursa (örneğin bir kod parçası testleri geçmezse), başarısızlığın nedenini doğal dilde bir “öz-yansıma” (self-reflection) notuna dönüştürür ve bu notu bir sonraki denemede bağlam olarak kullanır. Bu, kısa süreli bir hafıza mekanizması gibi çalışır; model aynı hatayı tekrar tekrar yapmak yerine, önceki denemelerden “ders çıkarır”.

def reflexion_loop(task, max_attempts=4):
    memory = []
    for attempt in range(max_attempts):
        plan = generate(task, prior_reflections=memory)
        result = execute(plan)
        if result.success:
            return result
        reflection = reflect_on_failure(plan, result.error)
        memory.append(reflection)
    return result

Bu yaklaşımın en somut kullanım alanı yazılım geliştirmedir. Bir kod üretim döngüsünde tipik akış şu şekilde işler: model kod üretir, kod derlenir/çalıştırılır, test paketi (unit test) çalıştırılır, başarısız testlerin çıktısı modele geri verilir, model kodu düzeltir. Bu döngü, “Generate-Test-Refine” olarak adlandırılır ve Claude Code gibi ajan tabanlı kodlama araçlarının temel çalışma prensibidir. Burada dikkat edilmesi gereken kritik nokta, eleştirmenin kural tabanlı ve deterministik olmasıdır (bir test paketinin geçip geçmediği net bir gerçektir); bu, “LLM-as-a-Judge” yaklaşımındaki öznellik problemini ortadan kaldırır ve döngüyü çok daha güvenilir hale getirir.

5. Çoklu Ajan Sistemleri: Orkestrasyon ve Rol Dağılımı

Loop engineering, tek bir generator-critic çiftinin ötesine geçtiğinde “multi-agent” (çoklu ajan) mimarilerine dönüşür. Burada farklı roller üstlenen birden fazla yapay zeka ajanı, bir orkestratör aracılığıyla koordine edilir. AutoGen, CrewAI ve LangGraph gibi kütüphaneler, tam olarak bu ihtiyacı karşılamak için geliştirilmiştir.

Tipik bir çoklu ajan mimarisinde şu roller görülür:

• Planlayıcı (Planner): Görevi alt görevlere böler.
• Araştırmacı (Researcher): Gerekli bilgiyi toplar (web araması, veri tabanı sorgusu, RAG).
• Uygulayıcı (Executor): Alt görevleri yerine getirir (kod yazar, doküman oluşturur).
• Denetçi (Reviewer/QA): Çıktıyı denetler, geri bildirim verir.
• Orkestratör (Orchestrator): Ajanlar arası mesaj akışını yönetir, döngünün ne zaman biteceğine karar verir.

# Basitleştirilmiş çoklu ajan orkestrasyonu
class Orchestrator:
    def __init__(self, planner, executor, reviewer, max_rounds=5):
        self.planner = planner
        self.executor = executor
        self.reviewer = reviewer
        self.max_rounds = max_rounds

    def run(self, goal):
        plan = self.planner.create_plan(goal)
        for round_idx in range(self.max_rounds):
            draft = self.executor.execute(plan)
            verdict = self.reviewer.review(draft, goal)
            if verdict.approved:
                return draft
            plan = self.planner.revise_plan(plan, verdict.feedback)
        return draft

Bu mimarilerin en büyük avantajı, her ajanın kendi uzmanlaşmış promptuyla çalışmasıdır — bir “jack of all trades” (her işe yarayan ama hiçbirinde uzman olmayan) tek bir dev prompt yerine, her biri dar bir sorumluluğa sahip birden fazla küçük prompt. Bu, hem çıktı kalitesini artırır hem de hata ayıklamayı (debugging) kolaylaştırır: bir sorun olduğunda hangi ajanın hatalı çalıştığını izole etmek, tek bir monolitik promptun içindeki hatayı bulmaktan çok daha kolaydır.

Ancak bu yaklaşımın bedeli açıktır: her round, birden fazla model çağrısı anlamına gelir; bu da maliyeti ve gecikmeyi doğrusal olmayan biçimde artırır. Beş ajanlı, üç turluk bir döngü, tek bir prompt çağrısına kıyasla on beşe kadar API çağrısı gerektirebilir.

Rol Ayrıştırmasının Kalite Üzerindeki Etkisi

Neden tek bir devasa prompt yerine birden fazla dar kapsamlı ajan tercih edilir? Bunun altında yatan neden, dil modellerinin “dikkat bütçesi"nin sınırlı olmasıdır. Bir modele aynı anda hem planlama yapmasını, hem araştırma yürütmesini, hem kod yazmasını hem de kendi kodunu denetlemesini isterseniz, model bu görevlerin her birine daha az “bilişsel öncelik” ayırır ve sonuç olarak her biri vasat kalabilir. Görevleri ayrı ajanlara böldüğünüzde, her ajan kendi dar bağlamında çok daha odaklı çalışır — tıpkı bir yazılım şirketinde bir kişinin hem mimar, hem geliştirici, hem test mühendisi, hem de proje yöneticisi olmasının verimsiz olması gibi.

Örneğin bir içerik üretim hattında şu rol dağılımı sıkça görülür: bir “Araştırmacı” ajan konuyla ilgili güncel kaynakları tarar ve özetler; bir “Yazar” ajan bu özetten taslak metni üretir; bir “SEO Denetçisi” ajan başlık, anahtar kelime yoğunluğu ve meta açıklama uyumunu kontrol eder; bir “Editör” ajan üslup tutarlılığını ve dilbilgisini denetler. Her ajan kendi dar kapsamında çalıştığı için, nihai çıktı tek bir promptla üretilen versiyona kıyasla çok daha tutarlı ve hatasız olur. Bu yaklaşımın bir bedeli vardır elbette: ajanlar arasında bilgi kaybı (information loss) riski oluşur — bir ajanın ürettiği bağlamın bir kısmı, bir sonraki ajana aktarılırken kaybolabilir. Bu yüzden orkestratörün, ajanlar arası mesajlaşma protokolünü net ve yapılandırılmış (örneğin JSON şemaları üzerinden) tutması kritik önem taşır.

6. Test-Time Compute: Düşünme Süresini Satın Almak

2024-2026 arası dönemde yapay zeka araştırmasındaki en önemli paradigma kaymalarından biri, “test-time compute” (çıkarım zamanı hesaplama) kavramının olgunlaşmasıdır. OpenAI’nin o1/o3 serisi ve benzer “reasoning” (akıl yürütme) modelleri, bir soruya cevap vermeden önce dahili olarak uzun bir düşünme zinciri (extended thinking) üretir; bu düşünme zinciri kullanıcıya gösterilmese bile, modelin nihai cevabının kalitesini ciddi biçimde artırır.

Bu yaklaşım, aslında loop engineering’in modelin içine gömülmüş halidir. Model, harici bir critic’e ihtiyaç duymadan, kendi iç sürecinde bir tür üretim-değerlendirme döngüsü çalıştırır: bir hipotez kurar, onu sınar, çelişki bulursa geri döner, alternatif bir yol dener. Bu, “inference-time scaling” olarak da adlandırılır ve temel önermesi şudur: modelin parametre sayısını artırmak yerine, aynı modele bir soruyu yanıtlarken daha fazla “düşünme bütçesi” (compute budget) tanımak da benzer kalite kazanımları sağlayabilir.

Monte Carlo Tree Search ve Tree of Thoughts

Bazı gelişmiş sistemlerde bu iç döngü, açıkça bir arama ağacı (search tree) biçiminde modellenir. “Tree of Thoughts” (ToT) yaklaşımında model, bir problem için birden fazla olası “düşünce adımı” üretir, bu adımları bir değerlendirme fonksiyonuyla puanlar, en umut verici dalları genişletir ve zayıf dalları budar (pruning). Bu, klasik oyun ağaçlarında kullanılan Monte Carlo Tree Search (MCTS) algoritmasının dil modellerine uyarlanmış halidir.

def tree_of_thoughts(problem, breadth=3, depth=3):
    frontier = [Thought(state=problem, path=[])]
    for level in range(depth):
        candidates = []
        for thought in frontier:
            candidates += generate_next_steps(thought, n=breadth)
        scored = [(evaluate(c), c) for c in candidates]
        scored.sort(key=lambda x: x[0], reverse=True)
        frontier = [c for _, c in scored[:breadth]]
    return frontier[0]

Bu yaklaşımın maliyeti son derece yüksektir — tek bir soruya cevap vermek için onlarca, hatta yüzlerce iç model çağrısı gerekebilir — ama matematik olimpiyatı seviyesindeki problemler veya karmaşık kod mimarisi kararları gibi “yüksek getirili” (high-stakes) görevlerde bu maliyet fazlasıyla haklı çıkabilir.

Bu noktada şu benzetmeyi yapmak faydalı olabilir: klasik bir tek-atışlık prompt, bir satranç oyuncusunun ilk aklına gelen hamleyi hiç düşünmeden oynaması gibidir. Test-time compute ise, aynı oyuncunun hamleyi oynamadan önce birkaç olası senaryoyu zihninde canlandırıp, rakibin olası karşı hamlelerini tartıp, en güvenli yolu seçmesine benzer. İkinci yaklaşım her zaman daha yavaştır, ama karmaşık pozisyonlarda kazanma ihtimalini belirgin biçimde artırır. Yapay zeka modellerinde de bu “zihinde canlandırma” süreci, kullanıcıya gösterilmeyen ama modelin nihai yanıtının kalitesini doğrudan etkileyen bir iç hesaplama katmanı olarak işler.

Bu yaklaşımın pratik sonucu, ürün ekipleri için önemli bir mimari karardır: bazı görevler için daha “ucuz” ama hızlı bir model tercih edip harici bir loop kurmak mı, yoksa dahili olarak zaten uzun düşünen bir “reasoning” modelini tek bir çağrıyla kullanmak mı daha uygun? Genel kural şudur — eğer görev nesnel bir doğrulama kriterine sahipse (kod, matematik, mantık bulmacaları) ve doğrulama ucuzsa, harici bir loop genellikle daha kontrol edilebilir ve daha şeffaftır; eğer görev daha çok “derin, çok adımlı ama tek seferlik bir akıl yürütme” gerektiriyorsa (bir mimari kararı analiz etmek, bir hipotezi çürütmek), modelin kendi dahili test-time compute mekanizmasına güvenmek daha pratik olabilir.

7. Prompt mi, Loop mu? Karar Matrisi

Şimdiye kadar anlattıklarımızdan, “loop engineering her zaman daha iyidir” gibi yanlış bir sonuç çıkarılmamalı. Aksine, doğru mühendislik kararı, görevin doğasına bağlıdır. Aşağıdaki karar matrisi, hangi durumda hangi yaklaşımın tercih edilmesi gerektiğini özetler:

Bu tabloyu bir kural olarak değil, bir sezgi aracı olarak kullanmak gerekir. Örneğin bir müşteri hizmetleri chatbotunun sıradan bir sorusuna cevap verirken loop engineering’e başvurmak, kullanıcıyı gereksiz yere bekletir ve maliyeti katlar. Ama aynı sistemin bir hukuki sözleşme taslağı hazırladığı senaryoda, çıktının bir “hukuki kontrol” ajanı tarafından denetlenmesi, olası bir hatanın bedeli düşünüldüğünde kesinlikle değerlidir.

Hibrit Yaklaşım: Uyarlanabilir Döngü Derinliği

En olgun sistemler aslında ikisi arasında sabit bir seçim yapmaz; görevin risk seviyesine göre döngü derinliğini dinamik olarak ayarlar. Buna “adaptive compute allocation” denir. Basit bir soru tek atışlık bir promptla yanıtlanırken, sistem görevin karmaşıklığını (ya da kullanıcının belirttiği önem derecesini) algıladığında otomatik olarak bir doğrulama katmanı ekler, gerekirse ikinci bir critic çağrısı devreye sokar.

def adaptive_pipeline(task, risk_level="low"):
    output = generate(task)
    if risk_level == "low":
        return output
    score, feedback = evaluate(output, task)
    if risk_level == "medium" and score < 0.8:
        output = refine(output, feedback)
    elif risk_level == "high":
        while score < 0.95:
            output = refine(output, feedback)
            score, feedback = evaluate(output, task)
    return output

8. Loop Engineering’in Gizli Maliyetleri

Döngü mühendisliğinin cazibesine kapılmadan önce, göz ardı edilmemesi gereken üç önemli maliyet kalemi vardır.

Maliyet katlanması: Her ek iterasyon, ek bir API çağrısı, dolayısıyla ek token maliyeti demektir. Üç turluk bir generate-evaluate-refine döngüsü, tek atışlık bir prompta göre kabaca üç ila altı kat daha fazla token tüketebilir (hem generator hem critic çağrıları sayıldığında).

Gecikme birikimi: Ardışık (sequential) API çağrıları, gecikmeleri toplar. Beş saniyelik bir model çağrısını üç kez art arda çalıştırmak, kullanıcıyı on beş saniye bekletmek anlamına gelir. Bu, gerçek zamanlı etkileşimli uygulamalarda kabul edilemez olabilir; bu yüzden loop engineering çoğunlukla arka plan işlerinde (batch processing) veya kullanıcının bekleyebileceği “derin araştırma” (deep research) senaryolarında tercih edilir.

Yakınsamama riski (non-convergence): Bazı durumlarda critic ve generator arasında bir tür “salınım” (oscillation) oluşabilir; model bir yönde düzeltme yapar, critic tam tersini önerir, döngü hiçbir zaman kararlı bir noktaya (convergence) ulaşmaz. Bu yüzden pratikte her döngüye mutlaka bir maksimum iterasyon sınırı ve bir “en iyi sonucu sakla” (best-so-far) mekanizması eklenir; döngü hedefe ulaşamasa bile, şimdiye kadar üretilen en yüksek puanlı aday döndürülür. Deneyimli ekipler ayrıca döngüye bir “erken çıkış” (early stopping) mantığı da ekler: eğer art arda iki iterasyon arasında kalite puanı anlamlı biçimde artmıyorsa (örneğin yüzde birden az bir iyileşme), döngü daha fazla kaynak harcamadan sonlandırılır. Bu, azalan getiriler eğrisinin erken tespit edilip gereksiz maliyetin önüne geçilmesini sağlar.

def bounded_loop(task, max_iterations=5):
    best_output, best_score = None, -1
    output = generate(task)
    for _ in range(max_iterations):
        score, feedback = evaluate(output, task)
        if score > best_score:
            best_output, best_score = output, score
        if score >= 0.95:
            break
        output = refine(output, feedback)
    return best_output

9. Pratik Örnek: Kod Üretiminde Uçtan Uca Loop Engineering

Somut bir örnek üzerinden ilerleyelim: bir yazılımcının, bir API endpoint’i için birim testleriyle birlikte kod üretmesini istediğini düşünelim. Saf prompt engineering yaklaşımında, mühendis tek bir talimat verir (“şu endpoint’i yaz, testlerini de ekle”) ve modelin çıktısını olduğu gibi kabul eder. Bu yaklaşımda, kodun gerçekten çalışıp çalışmadığı, edge-case’leri kapsayıp kapsamadığı belirsizdir.

Loop engineering yaklaşımında ise süreç şöyle işler:

1. Generate: Model, endpoint kodunu ve testleri üretir.
2. Execute: Üretilen kod gerçek bir sandbox ortamında çalıştırılır, testler koşturulur.
3. Evaluate: Test sonuçları (geçen/kalan testler, hata mesajları, linter uyarıları) toplanır — bu evaluate adımı deterministik olduğu için, bir önceki bölümde bahsettiğimiz LLM-yargıç öznelliği burada devre dışı kalır.
4. Refine: Başarısız testlerin hata mesajları modele geri verilir, model kodu düzeltir.
5. Repeat: Tüm testler geçene ya da maksimum iterasyon sayısına ulaşılana kadar 2-4 adımları tekrarlanır.

Bu döngü, tam olarak Claude Code gibi ajan tabanlı kodlama araçlarının veya CI/CD hatlarına entegre edilmiş “self-healing” test sistemlerinin çalışma prensibidir. Buradaki kritik ders şudur: loop engineering’in en güvenilir olduğu senaryolar, geri bildirim mekanizmasının nesnel ve otomatikleştirilebilir olduğu senaryolardır. Kod derlenir ya da derlenmez; test geçer ya da geçmez. Buna karşılık, “bu makale ne kadar ilgi çekici” gibi öznel bir kriterde loop engineering’in getirisi daha sınırlı ve daha az güvenilirdir, çünkü critic’in kendisi de hataya açık bir dil modelidir.

Aynı mantığı, bir yazılım ekibinin kod inceleme (code review) sürecine benzetebiliriz. Bir geliştirici tek başına yazdığı kodu doğrudan ana koda (main branch) birleştirseydi, hata oranı çok daha yüksek olurdu; bu yüzden ekipler bir “pull request” sürecinde başka bir geliştiricinin gözden geçirmesini zorunlu kılar. Loop engineering, bu insan iş akışının yapay zeka versiyonudur — sadece burada gözden geçiren kişi de bir model, hatta bazen otomatik bir test paketidir. Aradaki fark, insan kod incelemesinin saatler, günler sürebilmesine karşın, bir yapay zeka döngüsünün aynı işi saniyeler içinde, sürekli ve yorulmadan tekrarlayabilmesidir — bu da onu özellikle yüksek hacimli, tekrarlayan görevlerde ölçeklenebilir kılar.

10. Yapay Zekaların Kullandığı Araçlar: Fonksiyon Çağırma ve Loop’un Kesişimi

Loop engineering’i güçlü kılan bir diğer unsur, modellerin artık salt metin üretmekle kalmayıp gerçek dünyayla etkileşime girebilmesidir. “Function calling” (fonksiyon çağırma) veya “tool use” (araç kullanımı) olarak adlandırılan bu yetenek, modelin bir hesap makinesi, bir web arama motoru, bir kod yürütücü ya da bir veri tabanı sorgu aracı çağırmasına imkân tanır. ReAct (Reasoning + Acting) çerçevesi, bu iki yeteneği birleştirir: model önce akıl yürütür (“bu bilgiye ihtiyacım var”), sonra bir eylemde bulunur (araç çağırır), ardından aracın sonucunu gözlemler ve akıl yürütmesine geri döner.

Thought: Kullanıcının sorduğu güncel döviz kuru bilgim yok, bir araç çağırmalıyım.
Action: get_exchange_rate(from="USD", to="TRY")
Observation: 1 USD = 34.12 TRY
Thought: Artık kullanıcıya doğru cevabı verebilirim.

Bu ReAct döngüsü de aslında bir loop engineering biçimidir; her “Thought-Action-Observation” turu, modelin dünyadan yeni bilgi alıp kendi planını güncellediği bir mikro-döngüdür. Modern ajan çerçeveleri (LangGraph, AutoGen), bu döngüyü graf düğümleri (node) ve kenarları (edge) olarak modelleyip, döngünün ne zaman sonlanacağına, hangi düğümden hangi düğüme geçileceğine dair koşullu mantık ekler.

11. Güvenlik ve Kalite Kapıları: Guardrails’in Loop İçindeki Rolü

Loop engineering sadece kaliteyi artırmakla kalmaz, aynı zamanda güvenlik ve uyum (compliance) katmanlarının da doğal bir yerleşim noktasıdır. Bir “guardrail” (koruma bariyeri), üretilen çıktının belirli kurallara uyup uymadığını kontrol eden bir denetim katmanıdır — örneğin bir finansal danışmanlık asistanının kesin yatırım tavsiyesi vermediğinden, ya da bir sağlık asistanının teşhis koymadığından emin olmak.

Bu guardrail’ler, loop’un evaluate adımına doğal olarak entegre edilebilir: generator bir yanıt üretir, guardrail katmanı bu yanıtı politika kurallarına göre tarar, bir ihlal tespit ederse yanıtı reddeder ve generator’a “şu kısmı şu şekilde değiştir” talimatıyla geri gönderir. Bu, saf bir kalite döngüsünden ziyade bir “uyum döngüsü” (compliance loop) olarak düşünülebilir ve kurumsal yapay zeka uygulamalarında (özellikle finans, sağlık, hukuk sektörlerinde) neredeyse zorunlu hale gelmiştir.

12. Ölçeklenebilirlik: Loop’u Üretime Taşımak

Bir loop engineering prototipini bir Jupyter defterinde çalıştırmakla, onu binlerce eşzamanlı kullanıcıya hizmet veren bir üretim sistemine dönüştürmek çok farklı mühendislik zorlukları içerir. Burada dikkat edilmesi gereken birkaç kritik konu vardır:

Paralelleştirme: Bağımsız değerlendirilebilecek adaylar (örneğin self-consistency yaklaşımındaki N farklı akıl yürütme zinciri), sıralı değil paralel olarak üretilmelidir; bu, toplam gecikmeyi ciddi ölçüde azaltır.

Önbellekleme (caching): Aynı görev tekrar tekrar karşımıza çıkıyorsa, önceki döngülerin sonuçlarını önbelleğe almak, gereksiz tekrar hesaplamaları önler. Prompt önbellekleme (prompt caching) özellikle sabit sistem promptları ve bağlam bloklarında token maliyetini büyük ölçüde düşürür.

İzlenebilirlik (observability): Bir döngü üretimde beklenmedik biçimde çok fazla iterasyona girip maliyeti patlatabilir. Bu yüzden her döngüye; iterasyon sayısı, toplam token tüketimi ve toplam gecikme için üst sınırlar ve izleme (monitoring/tracing) altyapısı eklenmelidir.

Kademeli devreye alma (progressive rollout): Loop engineering’i doğrudan tüm trafiğe açmak yerine, önce düşük riskli bir kullanıcı segmentinde test etmek, döngünün gerçekten kalite artışı sağlayıp sağlamadığını A/B testleriyle doğrulamak gerekir. Zira bazı görevlerde ek iterasyonların getirisi azalan getiriler (diminishing returns) eğrisine hızla girer; üçüncü iterasyondan sonra kalite artışı ölçülemez hale gelirken maliyet artmaya devam edebilir.

13. RAG ile Loop Engineering’in Kesişimi

Retrieval-Augmented Generation (RAG), modelin kendi ağırlıklarında saklı olmayan, güncel veya özel bir bilgi kaynağına dayanarak yanıt üretmesini sağlayan bir mimaridir. Yüzeyde RAG, prompt engineering’in bir uzantısı gibi görünür — sonuçta yapılan şey, modele daha iyi bir bağlam (context) sağlamaktır. Ama RAG’in gelişmiş formları, aslında birer loop engineering örneğidir.

“Corrective RAG” (CRAG) ve “Self-RAG” gibi yaklaşımlarda, model önce getirilen (retrieved) dokümanların soruyla gerçekten alakalı olup olmadığını değerlendirir. Eğer getirilen belgeler yetersiz veya alakasız bulunursa, sistem yeni bir arama sorgusu (query) üretir ve tekrar arama yapar. Bu, klasik “tek seferlik getir ve yanıtla” (retrieve-then-generate) yaklaşımından çok daha dayanıklı bir mimaridir, çünkü ilk aramanın başarısız olma ihtimalini hesaba katar.

def self_rag(query, max_retries=2):
    for attempt in range(max_retries):
        docs = retrieve(query)
        relevance = evaluate_relevance(docs, query)
        if relevance >= 0.7:
            return generate_answer(query, docs)
        query = rewrite_query(query, docs)
    return generate_answer(query, docs, low_confidence=True)

Bu döngü, arama motoru optimizasyonu (SEO) açısından da ilginç bir paralellik taşır: tıpkı bir arama motorunun kullanıcı sorgusunu farklı biçimlerde yeniden yorumlayıp en alakalı sonucu bulmaya çalışması gibi, Self-RAG mimarisi de modelin kendi sorgusunu yeniden yazarak (query rewriting) daha iyi kaynaklara ulaşmasını sağlar. Kurumsal bilgi tabanlarında (internal wiki, doküman arşivleri) çalışan yapay zeka asistanlarının güvenilirliğini artırmak isteyen ekipler için bu yaklaşım, saf RAG’e kıyasla belirgin bir kalite sıçraması sunar.

14. Sık Sorulan Sorular

Prompt engineering öğrenmek loop engineering için gerekli mi? Evet. Loop engineering, prompt engineering’in yerine geçen bir disiplin değil, onun üzerine inşa edilen bir katmandır. Bir döngüdeki her generator ve critic çağrısı, yine iyi tasarlanmış bir prompta ihtiyaç duyar. Zayıf bir promptu döngüye sokmak, yalnızca aynı hatanın daha yüksek maliyetle birkaç kez tekrarlanmasına yol açar. Bu yüzden döngü kurmadan önce her bir adımın promptunu tek başına optimize etmek, döngünün toplam iterasyon sayısını ciddi ölçüde azaltır.

Loop engineering her zaman daha pahalı mıdır? Kısa vadede evet, çünkü ek model çağrıları ek token maliyeti demektir. Ancak uzun vadede, bir hatanın üretim ortamında yol açacağı maliyet (yanlış bir kod satırının canlı sisteme yayılması, yanlış bir hukuki ifadenin sözleşmeye girmesi) düşünüldüğünde, döngü maliyeti genellikle çok daha küçük kalır. Doğru soru “daha pahalı mı” değil, “bu görevde hata maliyeti döngü maliyetini haklı çıkarıyor mu” olmalıdır.

Tek bir model kendi kendini gerçekten eleştirebilir mi, yoksa ayrı bir model mi gerekir? Her ikisi de mümkündür. Aynı modelin kendi çıktısını eleştirmesi (self-refine) daha ucuzdur ama modelin kör noktalarını (blind spot) tekrar üretme riski taşır — çünkü aynı model, aynı hatayı yapma eğilimindeyse, kendi hatasını fark etmesi daha zordur. Farklı bir model veya farklı bir “persona” ile çalışan ayrı bir critic çağrısı, bu kör nokta riskini azaltır ama maliyeti artırır. Kritik görevlerde ayrı bir critic; düşük riskli görevlerde self-refine tercih edilebilir.

Loop engineering yalnızca büyük şirketler için mi anlamlıdır? Hayır. Bireysel bir geliştirici de kendi otomasyon betiğinde basit bir “generate-test-refine” döngüsü kurarak ciddi kalite kazanımı elde edebilir. Örneğin bir kişisel proje için kod üreten bir betikte, üretilen kodu otomatik olarak çalıştırıp hata mesajlarını modele geri vermek, tek satırlık bir ek mantıkla uygulanabilir ve çıktı kalitesini gözle görülür biçimde artırır.

Hangi araçlar loop engineering’i kolaylaştırır? LangGraph, graf tabanlı, koşullu dallanmalara izin veren döngüler kurmak için tercih edilir. AutoGen ve CrewAI, çoklu ajan rol dağılımı ve sohbet tabanlı orkestrasyon için uygundur. Daha basit senaryolarda, harici bir kütüphaneye ihtiyaç duymadan, birkaç fonksiyonla kendi döngünüzü de yazabilirsiniz — nitekim bu yazıdaki örnek kod parçaları da bunu göstermektedir.

15. Sonuç: İki Paradigma, Tek Amaç

Prompt engineering ve loop engineering, birbirine rakip iki felsefe değil, aynı mühendislik problemine farklı ölçeklerde verilen iki cevaptır. Prompt engineering, “modelden ilk seferde en iyi çıktıyı nasıl alırım” sorusuna odaklanırken; loop engineering, “modelin ilk çıktısı yeterli değilse, bunu sistematik olarak nasıl iyileştiririm” sorusuna cevap arar. Olgun bir yapay zeka ürünü, aslında ikisini bir arada kullanır: iyi tasarlanmış bir prompt, döngünün her turunda daha az iterasyona ihtiyaç duyulmasını sağlarken; iyi tasarlanmış bir döngü, kusurlu bir promptun neden olabileceği hataları yakalayıp telafi eder.

Geleceğin yapay zeka sistemleri muhtemelen bu ayrımı giderek daha görünmez hale getirecek; test-time compute’un olgunlaşmasıyla birlikte, “döngü” artık geliştiricinin elle kurduğu harici bir mekanizma olmaktan çıkıp, modelin kendi iç mimarisinin doğal bir parçası haline gelecek. Ama bugün için, bir yazılımcının ya da ürün ekibinin sorması gereken soru hâlâ nettir: Bu görev, tek bir iyi cümleyle mi çözülür, yoksa modelin kendi kendini sınamasına izin vermek mi gerekir? Bu sorunun dürüst cevabı, çoğu zaman ikisinin bir karışımıdır — ve iyi mühendislik, o karışımın oranını doğru bulmaktan ibarettir.

Bu yazıda ele aldığımız kavramların ortak paydası, aslında yapay zekayı bir “kara kutu” olarak değil, üzerinde tasarım kararları verebileceğimiz bir sistem olarak ele almaktır. Prompt engineering, bu sistemin girdisini şekillendirir; loop engineering, sistemin kendi çıktısıyla nasıl bir ilişki kuracağını şekillendirir. İkisini birlikte, bilinçli biçimde kullanan ekipler, sadece daha kaliteli çıktılar elde etmekle kalmaz, aynı zamanda hangi görevin ne kadar hesaplama ve maliyet gerektirdiğini önceden öngörebilen, dolayısıyla bütçesini ve zaman çizelgesini çok daha isabetli planlayabilen bir mühendislik kültürü inşa eder. Yapay zekayı yalnızca “daha iyi bir prompt yazarak” ya da yalnızca “daha çok döngü ekleyerek” iyileştirmeye çalışmak, madalyonun sadece bir yüzüne bakmaktır; asıl ustalık, ikisi arasındaki dengeyi görevin doğasına göre her seferinde yeniden kurabilmektir.

Teknik Not: Prompt engineering hız ve maliyet ekseninde optimize ederken, loop engineering doğruluk ve güvenilirlik ekseninde optimize eder. İkisi arasındaki doğru dengeyi bulmak, görevin risk profiline, doğrulanabilirliğine ve kullanıcının bekleme toleransına bağlıdır. Geleceğin akıllı sistemleri, muhtemelen bu dengeyi statik bir mimari kararı olarak değil, her görev için dinamik olarak hesaplanan bir “hesaplama bütçesi” (compute budget) olarak ele alacak.

Son olarak şunu eklemek gerekir: bu iki paradigmayı öğrenmenin en iyi yolu, teoriyi okumak değil, küçük bir projede ikisini de deneyip karşılaştırmaktır. Basit bir metin sınıflandırma görevini önce tek bir promptla, sonra üç turluk bir generate-evaluate-refine döngüsüyle çalıştırıp sonuçları, maliyeti ve gecikmeyi karşılaştırmak, herhangi bir teorik anlatımdan çok daha kalıcı bir sezgi kazandırır. Yapay zeka mühendisliğinde, tıpkı diğer mühendislik disiplinlerinde olduğu gibi, en sağlam öğrenme biçimi ölçüp gözlemlemekten geçer.