E Elecay
8.1.2.5 Tip: pratik Seri: Sıfırdan Ajan Kurmak

Prompt Zincirleme: Tek İstekte Yapılamayan İşi Bölmek

Beş şey isteyip üçünü iyi almak neden kaçınılmaz? İşi bölmenin doğru yerleri, adımlar arasında bilgi taşıma, zincirin nerede kırıldığı ve maliyeti.

Seviye
Orta
Ön koşul
Belirsizlik: Promptunuzda Söylemediğiniz Her Şey Bir Karardır (isteğe bağlı)
Okuma süresi
~9 dakika

Beş şey istediniz. Üçü iyi geldi, ikisi baştan savma.

Bu tesadüf değil ve promptu daha iyi yazarak çözülmüyor. Model üretirken dikkatini bölüyor ve listenin sonundaki maddeler sistematik olarak zayıf kalıyor. Talimatı numaralandırmak, büyük harfle vurgulamak veya “hepsini eksiksiz yap” eklemek bu kalıbı değiştirmiyor.

Çözüm promptta değil yapıda: işi bölmek.

Ne zaman bölmeli?

Dört belirti bölme zamanının geldiğini gösterir.

Listenin sonu zayıf geliyor. İlk iki istek iyi, son ikisi yüzeysel. Klasik dikkat bölünmesi.

Bir adımın çıktısı diğerinin girdisi. “Özetle ve özetten sunum çıkar” aslında iki iş. Tek istekte birleştirmek, ilk adımı görmeden ikinciye geçmek demektir.

Ara sonucu görmek istiyorsunuz. Model yanlış şikâyetleri çıkardıysa, bunu son çıktıda değil ilk adımda yakalamak istersiniz.

Farklı adımlar farklı şey gerektiriyor. Bir adım yaratıcılık, diğeri kesinlik istiyor olabilir. Tek promptta ikisi birbirini bozar.

Bunların hiçbiri yoksa bölmeyin. Zincir maliyet ve karmaşıklık ekler; karşılığı olmayan bölme zarar.

Nereden bölmeli?

Kötü bölme, iyi bölmeden daha kötü sonuç verir. Üç kural:

Her adım tek bir iş yapsın. “Şikâyetleri çıkar ve grupla” iki iştir. Ayırın.

Ara çıktı denetlenebilir olsun. Bir adımın çıktısına bakıp doğru olup olmadığını anlayabilmelisiniz. Anlayamıyorsanız yanlış yerden bölmüşsünüzdür.

Ara çıktının formatı sabitlensin. Bir sonraki adım onu girdi alacak. Serbest metin yerine yapılandırılmış çıktı isteyin. → Çıktı Formatını Zorlamak: Talimat Yeter mi, Şema mı Gerekir?

Doğru ve yanlış bölme

Yanlış:

Adım 1: Dökümü oku ve anla
Adım 2: Analiz et
Adım 3: Rapor yaz

“Anlamak” denetlenebilir bir çıktı üretmiyor. “Analiz etmek” ne demek olduğu belirsiz. Bu bölme, işi bölmüyor sadece parçalıyor.

Doğru:

Adım 1: Dökümden geçen tüm şikâyet cümlelerini olduğu gibi çıkar.
        Çıktı: numaralı liste, her satır bir alıntı.

Adım 2: Bu şikâyetleri konuya göre grupla.
        Çıktı: Grup adı | Kaç şikâyet | Şikâyet numaraları

Adım 3: En sık üç grup için birer çözüm önerisi yaz.
        Çıktı: Grup | Öneri | Tahmini etki

Her adımın çıktısı görülebilir, kontrol edilebilir ve bir sonrakinin girdisi olabilir.

Adımlar arasında bilgi taşımak

Zincirin en kırılgan yeri burası.

Yalnızca gerekeni taşıyın. Her adıma tüm önceki çıktıları vermek bağlamı şişirir ve maliyeti artırır. Üçüncü adım ham dökümü görmek zorunda değil.

Ara çıktıyı yapılandırın. Serbest metin yerine tablo veya alan listesi. Bir sonraki adım neyi nerede bulacağını bilir.

Kaynağa geri bağlantı bırakın. İkinci adımda şikâyet numaralarını taşımak, üçüncü adımda “bu öneri hangi şikâyetten çıktı” sorusunu cevaplanabilir kılar. Bu, zincirin en çok işe yarayan ayrıntısıdır.

Blueprint: Çok adımlı üretim hattı

Kim kurar: İçerik ekipleri, analistler, operasyon ekipleri Yapı taşları: Adım tanımları → Ara çıktı formatı → Kontrol noktaları → Hata durumunda geri dönüş Tipik ölçek: 3–5 adım Zorluk: Orta Nerede kırılır: İlk adımın hatası sonuna kadar taşınır ve son adımda kaynağı görünmez olur.

Elle çalıştırıyorsanız her adımdan sonra durup bakın. Otomatikleştiriyorsanız her adıma bir kontrol koyun: çıktı beklenen formatta mı, boş mu, satır sayısı makul mü. Bozuk çıktıyı bir sonraki adıma geçirmek, hatayı büyütmenin en hızlı yolu.

Adımlar arasında durum taşımak

Zincir uzadıkça bir soru büyüyor: her adıma ne kadar geçmiş bilgi verilecek?

Üç strateji var ve seçimi işin yapısı belirliyor.

Yalnızca bir önceki çıktı. En yaygın ve en ucuz. Her adım, bir öncekinin çıktısını alır, öncesini görmez. Adımlar birbirinden bağımsız dönüşümlerse doğru seçim.

Biriktirerek taşımak. Her adım, tüm önceki çıktıları görür. Sonraki adım geçmişe referans vermesi gerekiyorsa gerekir — ama bağlam hızla şişer ve maliyet artar.

Seçerek taşımak. Her adıma yalnızca ihtiyaç duyduğu alanları geçirmek. En verimli ama en çok tasarım isteyen yol.

Pratikte işleyen bir orta yol var: ham veriyi değil, kimliği taşıyın. Üçüncü adıma tüm şikâyet metinlerini vermek yerine numaralarını verin; gerekirse o numaralarla kaynağa dönülür.

Adım 2 çıktısı:
Grup: Kargo gecikmesi | Şikâyet no: 1,4,7,9,11

Adım 3 girdisi:
Grup: Kargo gecikmesi (12 şikâyet)
→ ham metinler taşınmadı, numara yeterli

Bu, bağlamı küçük tutarken izlenebilirliği koruyor — zincirin en çok işe yarayan tasarım ayrıntısı.

Zincir nerede kırılır?

Hata birikir. Birinci adımda %90 doğrulukla çalışan bir zincir, üç adım sonra belirgin biçimde daha düşük doğrulukta olur. Her adım bir öncekinin hatasının üstüne kendi hatasını ekler.

Hatanın kaynağı görünmez olur. Son çıktı yanlışsa hangi adımda bozulduğunu bilmek zordur. Ara çıktıları kaydetmezseniz teşhis imkânsızlaşır.

Adım sayısı arttıkça kontrol zorlaşır. Üç adımlı bir zincir yönetilebilir, on adımlı bir zincir bir sisteme dönüşür ve sistem araçları gerektirir. → 5.5.3.3yakında

Maliyet toplanır. Her adım ayrı bir istek. Beş adımlı zincir, tek istekten belirgin biçimde pahalıdır ve daha yavaştır.

Bu son madde bölme kararını dengeliyor: zincir kaliteyi artırır ama hız ve maliyeti kötüleştirir. Tek istekle kabul edilebilir sonuç alıyorsanız bölmeyin.

Somut örnek: nerede araya girilir?

Üç adımlı zincirin ikinci adımında şunu gördüğünüzü düşünün:

Grup adı              | Kaç | Numaralar
Kargo gecikmesi       | 12  | 1,4,7,9,11,15,18,22,25,29,31,34
Ürün hasarı           | 8   | 2,5,13,17,20,26,30,33
Diğer                 | 21  | ...

“Diğer” grubu 21 şikâyetle en büyük grup. Bu, gruplandırmanın işe yaramadığını gösteriyor — model tanımlayamadığı her şeyi bir kutuya atmış.

Tek istekli bir promptta bunu göremezdiniz. Üçüncü adımdan gelen öneriler makul görünürdü ve şikâyetlerin yarısının hiç ele alınmadığını fark etmezdiniz.

Zincirin asıl değeri burada: hatayı erken görmek.

Zincir mi, tek prompt mu? Karar hesabı

Bölme kararı bir ödünleşim ve iki tarafı da tartmak gerekiyor.

Zincirin kazandırdıkları: Her adımda daha az iş olduğu için savsaklama azalır. Ara çıktıyı gördüğünüz için hata erken yakalanır. Adımlar ayrı olduğu için her birini bağımsız iyileştirebilirsiniz — birinci adımın promptunu değiştirmek diğerlerini etkilemez.

Zincirin götürdükleri: Her adım ayrı bir istek olduğu için maliyet adım sayısıyla çarpılır. Toplam süre uzar. Sistem karmaşıklaşır: ara çıktıları saklamak, hataları yakalamak ve bir adım bozulduğunda ne yapılacağına karar vermek gerekir.

Karar için pratik bir eşik: tek promptla aldığınız sonuç kabul edilebilir seviyedeyse bölmeyin. Zincir bir çözümdür, bir iyileştirme yöntemi değil. Çalışan bir şeyi “daha iyi olur” diye bölmek genellikle karmaşıklığı kazançtan fazla artırır.

Bölmeyi gerektiren asıl durum şu: tek promptta kabul edilebilir sonuç alamıyorsunuz ve sebebi işin büyüklüğü. Sebep bilgi eksikliği ya da yetenek sınırıysa bölmek yardımcı olmaz. → Promptla Çözülemeyen Problemler: Yedi Belirti ve Doğru Çözümleri

Zincir yerine geçebilecek üç şey

Bölmeye karar vermeden önce daha ucuz üç seçeneği deneyin.

İşi küçültmek. Kırk yorumu tek seferde işletmek yerine onarlı gruplar hâlinde işletmek, zincir kurmadan aynı sorunu çözebilir. Yapı aynı kalır, yalnızca girdi bölünür.

Formatı sıkılaştırmak. Savsaklanan maddeler genellikle formatta karşılığı olmayan maddelerdir. Çıktı yapısına her istek için ayrı bir alan açtığınızda, model o alanı boş bırakmakta zorlanır. → Çıktı Formatını Zorlamak: Talimat Yeter mi, Şema mı Gerekir?

Kısıt sayısını azaltmak. Bazen sorun işin çokluğu değil kuralların çokluğudur. Ayıklama, bölmeden ucuzdur. → Prompt Ne Kadar Uzun Olmalı? Ayrıntının Ters Tepmeye Başladığı Nokta

Üçü de işe yaramıyorsa bölme gerçekten gereklidir. Bu sıra, gereksiz karmaşıklığı önlüyor — ve bir sistemde en pahalı şey, sonradan sökülemeyen gereksiz karmaşıklıktır.

Sınırlar

Her iş bölünmez. Kısa ve tek adımlı işlerde zincir gereksiz yavaşlatır.

Bölme, kötü tanımlanmış işi kurtarmaz. Ne istediğiniz belli değilse üç adıma bölmek üç kat belirsizlik üretir. → Promptla Çözülemeyen Problemler: Yedi Belirti ve Doğru Çözümleri

Ara çıktılar da yanlış olabilir. Kontrol etmediğiniz bir ara adım, hatayı sessizce taşır.

Uzun zincirler ayrı bir disiplin. Beş adımı geçtiğinizde konu prompt yazımından çıkıp sistem tasarımına geçer.

Zincir mi, ajan mı?

Bir zincir büyüdükçe farklı bir şeye dönüşüyor ve bu geçişi bilmek gerekiyor.

Zincir deterministiktir. Adımlar önceden belirlidir, sıra sabittir, her adımın ne yapacağı yazılıdır. Kontrol sizdedir; model yalnızca her adımın içini doldurur.

Ajan ise kendi sırasını belirler. Hangi adımın atılacağına, kaç adım gerekeceğine ve ne zaman duracağına model karar verir.

Ajanın esnekliği bir bedelle geliyor: öngörülebilirlik. Zincirde ne olacağını bilirsiniz, ajanda bilmezsiniz. Bu yüzden pratik kural şu: adımları önceden biliyorsanız zincir kurun. Ajanı yalnızca adımların girdi bazında gerçekten değiştiği işlerde tercih edin.

Çoğu iş, sanıldığından daha fazla oranda zincir işidir. Ajana geçmenin cazibesi yüksek ama getirisi genellikle karmaşıklığından az. → 5.5.3.3yakında

Özet

Tek istekte beş şey istemek, listenin sonundaki maddelerin zayıf kalmasıyla sonuçlanır. Bu promptla çözülmez, işi bölerek çözülür.

Bölme kararı dört belirtiyle verilir: listenin sonu zayıf geliyor, bir adımın çıktısı diğerinin girdisi, ara sonucu görmek istiyorsunuz, adımlar farklı şey gerektiriyor.

Doğru bölmenin üç kuralı var: her adım tek iş yapsın, ara çıktı denetlenebilir olsun, formatı sabitlensin.

Zincirin asıl değeri kalitede değil görünürlükte: hatayı son çıktıda değil kaynağında yakalarsınız. Bedeli ise maliyet ve hız.

Sık sorulanlar

Prompt zincirleme nedir?

Tek istekte yapılamayacak bir işi, her biri tek bir görevi yapan ardışık adımlara bölmek ve her adımın çıktısını bir sonrakine girdi olarak vermektir.

İşi ne zaman bölmeliyim?

Listenin sonundaki istekler zayıf geliyorsa, bir adımın çıktısı diğerinin girdisiyse, ara sonucu görmek istiyorsanız veya adımlar farklı nitelikler gerektiriyorsa.

Kaç adıma bölmeliyim?

Üç ile beş adım çoğu iş için yeterli. Daha fazlası prompt yazımından çıkıp sistem tasarımına geçer ve ayrı araçlar gerektirir.

Zincirleme maliyeti artırır mı?

Evet. Her adım ayrı bir istek olduğu için hem maliyet hem gecikme artar. Tek istekle kabul edilebilir sonuç alıyorsanız bölmeyin.

Zincirde hata olduğunu nasıl anlarım?

Ara çıktıları kaydedip her adımdan sonra kontrol ederek. Yalnızca son çıktıya bakarsanız hatanın hangi adımda oluştuğunu göremezsiniz.

İlgili yazılar