Yapılandırılmış LLM Çıktıları: Output Parser

n8n'deki Output Parser node'u, serbest metne güvenmek yerine LLM yanıtlarından yapılandırılmış JSON çıktısı elde edilmesini zorunlu kılar: dil modelinin uyması gereken bir şema tanımlar ve Basic LLM Chain veya yapay zeka (YZ) ajanı sonucu daha sonra tam olarak bu formatta döndürür. LLM yanıtlarını otomatik olarak CRM, ERP veya veritabanlarına aktarmak isteyen şirketler için bu, güvenilir şekilde işlenebilen alanlar ile metin yanıtlarının yorucu manuel olarak yeniden düzenlenmesi arasındaki farktır. Tarih: Temmuz 2026.

Salt serbest metin otomasyonlarda neden başarısız olur

Başka bir kısıtlama olmadan bir dil modeli, yanıtları doğal dilde döndürür. Bir sohbet arayüzü için bu istenen bir durumdur, ancak yanıtı bir sonraki sisteme aktarması gereken bir workflow adımı için bu bir sorundur. Sabit bir yapı olmadan, tek tek değerleri ayıklamak için metin parçaları, regex veya ek ara adımlarla çalışmak gerekir ve modelin ifadesindeki küçük bir değişiklik bile bu çıkarımı bozabilir. Output Parser node'u tam olarak burada devreye girer: modele bir şema verir ve yanıtın, takip eden node'larda doğrudan işlenebilecek şekilde açıkça adlandırılmış alanlara sahip geçerli bir JSON olarak dönmesini sağlar.

Structured Output Parser: JSON şemasını zorunlu kılmak

n8n dokümantasyonuna göre (Structured Output Parser dokümantasyonu), node JSON şemasına dayalı alanlar döndürür ve LLM çıktısını buna göre yapılandırır. Şema tanımı için iki yol mevcuttur:

• Generate from JSON Example: Örnek bir JSON girersiniz ve node şemayı bundan otomatik olarak türetir. Bu sırada yalnızca nesne özellik türleri ve adları kullanılır, örnekteki gerçek değerlerin bir önemi yoktur. Bu modda tüm alanlar zorunlu kabul edilir.
• Define using JSON Schema: Şemayı manuel olarak oluşturursunuz. Dokümantasyon, bu şemada $ref ile yapılan referansların desteklenmediğini açıkça belirtir.

Pratik kullanım için önemli: bu Output Parser gibi sub-node'lar, ifadeleri normal node'lardan farklı işler. Dokümantasyona göre, birden fazla giriş item'ı olduğunda bir ifade her zaman yalnızca ilk item için çözümlenir, her item için ayrı ayrı değil. Bu, birden fazla kaydın toplu işlenmesinde beklenmedik sonuçlara yol açabilir ve önceden test edilmelidir.

Basic LLM Chain veya YZ ajanına bağlanma

Bir Output Parser'ın etkili olabilmesi için, Basic LLM Chain gibi ilgili kök node'da "Require Specific Output Format" seçeneğinin etkinleştirilmesi gerekir. Ancak bundan sonra, Structured Output Parser'ı, Item List Output Parser'ı veya Auto-fixing Output Parser'ı bağlayabileceğiniz bağlantı noktası görünür. YZ ajanları için dokümantasyon açık bir uyarı içerir: yapılandırılmış çıktı ayrıştırması ajanlarda genellikle güvenilir değildir. Alternatif olarak, ajandan gelen ham verileri alan ve ancak ardından hedef formata dönüştüren ayrı bir LLM Chain kullanılması önerilir. Bir ajan workflow'u içindeki ara adımlar için dokümantasyon zaten parser kullanılmasını önermez, bunun yerine istenen biçimlendirmenin doğrudan System Message içinde tanımlanmasını önerir. Bu tür ajan workflow'ları planlayanlar konuyla ilgili daha fazla bilgiyi YZ Ajanları.

Hata yönetimi: LLM geçerli JSON döndürmediğinde

Hiçbir dil modeli verilen bir şemaya yüzde yüz uyacağını garanti etmez; özellikle daha karmaşık yapılarda veya uzun yanıtlarda bir alanın eksik olması, bir tırnak işaretinin yanlış konması veya JSON'un etrafında ek metin bulunması mümkündür. Tam olarak bu durum için Auto-fixing Output Parser ile ilgili n8n dokümantasyonuna göre ayrı bir çözüm vardır: node, mevcut bir Output Parser'ın etrafında bir wrapper görevi görür. İlk ayrıştırma denemesi başarısız olursa, n8n otomatik olarak ek bir LLM çağırır, bu da hatalı çıktıyı düzeltir ve tekrar istenen formata getirir. Bu, güvenilirliği belirgin şekilde artırır, ancak workflow'un kendisindeki hata yönetiminin yerini tutmaz. Güvende olmak isteyenler, yine de parser'dan sonra bir kontrol eklemelidir, örneğin bir error-trigger yolu veya düzeltme denemesi de başarısız olduğunda devreye giren bir koşul. Boş veya yanlış alanlarla sessizce devam eden bir otomasyon, düzgün şekilde kaydedilmiş bir hata durumundan daha fazla zarar verir.

n8n'de yapılandırılmış LLM çıktıları hakkında sık sorulan sorular

Structured Output Parser ile Auto-fixing Output Parser arasındaki fark nedir?

Structured Output Parser hedef şemayı tanımlar ve yanıtı buna göre kontrol eder. Auto-fixing Output Parser bunun üzerine ek bir güvenlik katmanı olarak eklenir: başka bir parser, örneğin Structured Output Parser'ı kullanır ve bir ayrıştırma denemesi başarısız olduğunda çıktıyı düzeltmek için ek bir LLM çağırır.

Birden fazla item'ı aynı anda yapılandırılmış şekilde ayrıştırabilir miyim?

Teknik olarak evet, pratikte bir sınırlama ile. Output Parser gibi sub-node'lar ifadeleri yalnızca ilk giriş item'ı için çözdüğünden, birden fazla kayıtla, sonucun toplu işlemeye körü körüne güvenmek yerine her item için beklendiği gibi görünüp görünmediğini dikkatlice test etmelisiniz.

Output Parser yüzde yüz geçerli JSON garanti eder mi?

Hayır. Yapılandırılmış, geçerli bir yanıt olasılığını önemli ölçüde artırır ve Auto-fixing Parser ayrıca birçok hatayı da yakalar, ancak hiçbir dil modeli yüzde yüz garanti vermez. Bu nedenle workflow içinde temiz bir hata yolu anlamlı olmaya devam eder.

Output Parser, YZ ajanlarında da güvenilir şekilde çalışır mı?

n8n dokümantasyonuna göre, basit bir LLM Chain'e kıyasla daha az güvenilirdir. Ajan workflow'ları için, biçimlendirmenin ya System Message üzerinden kontrol edilmesi ya da ham yanıtın Output Parser'a sahip ayrı, sonraki bir LLM Chain'e aktarılması önerilir.