LangChain, OpenAI AgentKit konusunda iyimser değil

Birkaç gün önce geliştirici konferansında OpenAI, geliştiriciler ve kuruluşlar için eksiksiz bir araç seti olan AgentKit’i piyasaya sürdü. Bunlar arasında, çok aracılı iş akışlarını oluşturmak, yönetmek ve sürümlendirmek için görsel tuval Agent Builder kullanılır ve iş akışı, düğümler sürüklenerek düzenlenebilir.

LangChain’in kurucusu Harrison Chase, yakın zamanda AgentKit hakkındaki görüşlerinden bahsetmek için başka bir blog yazısı yazdı. Harrison, piyasada AgentKit gibi bir “görsel iş akışı oluşturucuya” ihtiyaç olmadığını sert bir şekilde yorumladı.

İş Akışı ile Aracı arasındaki temel fark öngörülebilirlik ve özerkliktir. İş Akışı süreci, görsel arayüz üzerinde çeşitli düğümler ve bağlantı hatları olan birçok dal ve paralel karmaşık mantık ile sabittir; Aracının mantığı basitleştirilir ve doğal dile soyutlanır ve ardından Yüksek Lisans, hedefi tamamlamak için bir döngüde hangi araçların çağrılacağına karar verir.

AgentKit ve piyasadaki benzer araçların çoğu esas olarak iş akışları oluşturuyor ancak bunlar gerçek aracılar değil.

Harrison, “görsel iş akışı oluşturucunun” hem yüksek hem de alçak yönlerden sıkıştırıldığı için garip bir konumda olduğuna inanıyor: basit görevler için kodsuz aracıları kullanmak daha uygundur, ancak istikrar ve güvenilirliği sağlamak için karmaşık görevlerde kodun kullanılması gerekir.

Kurucu Park tarafından derlenen ve ince ayar yapılan makalenin orijinal içeriği aşağıdadır.

Orijinal bağlantı: https://blog.langchain.com/not-another-workflow-builder/

luşturucu” en sık alınan taleplerden biri oldu. Ancak bu gelişmeyi hiçbir zaman ilerletmedik, bunun yerine diğer ekiplerin (LangFlow, Flowise, n8n gibi) teknolojimizi geliştirmesine izin vermeyi tercih ettik.

Dün OpenAI, Geliştirici Konferansında (Geliştirme Günü) bir iş akışı oluşturucuyu başlattı. Bu fırsatı şu ana kadar neden böyle bir araç geliştirmediğimizden, nelerle daha çok ilgilendiğimizden ama farklı gelişim yönlerinden bahsetmek istiyorum.

İlk olarak, bu tür kodsuz iş akışı oluşturucunun çözmesi gereken temel sorunu tanımlamak gerekir. Ana hedefleri, teknik bilgisi olmayan kullanıcıların Aracılar oluşturmasına olanak sağlamaktır. Bunun arkasında iki temel neden var:

• Pek çok şirketin mühendislik yeteneği açısından sınırlı kaynakları var ve bu da tüm ekibin teknik ihtiyaçlarını desteklemeyi zorlaştırıyor;

• Ne tür Agent’ların oluşturulması gerektiğini ve bu Agent’ların hangi işlevleri uygulaması gerektiğini teknik olmayan kullanıcılar en iyi bilir.

Teknik kullanıcıların bunu hızlı bir şekilde Agent prototipleri oluşturmak ve ardından koda dönüştürmek için kullanması gibi diğer talep senaryolarını zaman zaman görüyoruz. Ancak bu makalede temel gereksinimlerin şöyle olduğunu varsayıyoruz:Kuruluştaki herkesin, mühendislik ekibi desteğine ihtiyaç duymadan uygulamaları ve bileşenleri bağımsız olarak oluşturmasına izin verin.

Daha önce “iş akışı” ve “Ajan” terimlerini bilinçli olarak kullandım. İkisi arasındaki ilişkiyi önceki bir blog gönderisinde tartışmıştık (ilginç bir şekilde, bu gönderi “iş akışı”na karşı çıkan bir OpenAI gönderisine yanıt olarak “iş akışını” desteklemek için yazılmıştır).

Kurucu Park’ın önceki makaleleri:

LangChain’in kurucusu ve “Acenteler ve İş Akışları arasında ne daha iyi, ne daha kötü?” OpenAI Bar açık》

Geliştirici topluluğu temel olarak “Ajan” tanımı konusunda fikir birliğine varmıştır:

LLM Agent, araçları döngüsel olarak çağırarak hedeflerine ulaşır.

İş akışı, daha yüksek “öngörülebilirlik” karşılığında “özerkliği” feda eder; Ajan ise daha yüksek “özerklik” karşılığında “öngörülebilirliği” feda eder. şunu belirtmekte yarar varBir Aracı sistemi oluşturmanın temel amacı,「İstikrarlı ve güvenilir iyi sonuçlar“ancak ne “öngörülebilirlik” ne de “özerklik” tek başına bunu garanti edemez.

İş akışları genellikle dallanma mantığı, paralel düğümler ve birden çok farklı yol içeren karmaşıktır. Bu karmaşıklık, iş akışının “grafiğine” yansıtılacak ve alana özgü bir dil (DSL) aracılığıyla sunulacaktır.

Aracı aynı zamanda karmaşık mantık da içerebilir, ancak fark, bu mantıkların doğal dile soyutlanması ve Prompt’a gömülmesidir. Bu nedenle, Aracının genel yapısı çok basittir (yalnızca “İstem+araç”tan oluşur), ancak “İstem”in kendisi bazen oldukça karmaşık olabilir.

OpenAI’nin AgentKit’inin yanı sıra n8n, Flowise, LangFlow vb. araçlar da mevcuttur.Esasen hepsi「Görsel iş akışı oluşturucu“yerine「 Temsilci oluşturucu“.

Yukarıdaki arka planla birleştiğinde görsel iş akışı oluşturucunun aşağıdaki temel sorunları vardır:

• Ve HAYIR”Düşük“eşik: Hedef kullanıcılar genel halk olmasına rağmen, teknik bilgisi olmayan sıradan kullanıcıların kullanımı hala kolay değildir;

• Karmaşık görevlerin yönetilmesi zordur: Görev karmaşıklığı belirli bir eşiği aştığında ve bu eşiğe kolayca ulaşıldığında, arayüz düğümler ve bağlantılarla dolacak, bu da onu karmaşık hale getirecek ve yönetilmesini zorlaştıracaktır.

Temel hedefimiz “istikrarlı ve güvenilir bir LLM sürücü sistemi” (ister iş akışı ister Temsilci olsun) oluşturmaktır. İnsanların bu tür sistemlerle çözdüğü sorunların karmaşıklığı düşükten yükseğe doğru değişir, bu nedenle en iyi çözümlerin karmaşıklığa göre farklılaştırılması gerekir.

Son derece karmaşık senaryolar: kodlanmış iş akışı

Yüksek karmaşıklıktaki problemler için, yeterince yüksek güvenilirliğe ulaşmak için sistemin saf bir aracı olamayacağını, ancak iş akışının bazı özelliklerini entegre etmesi gerektiğini bulduk. Bu tür sorunlar genellikle karmaşık iş akışı desteği gerektirir. Şu anda çok sayıda dallanma, paralel işleme ve modüler tasarım gerekiyorsa “kod” en iyi seçimdir (LangGraph’ımız bunun için tasarlanmıştır).

Geleneksel olarak bu tür sorunlar teknik bilgisi olmayan kişilerin ulaşamayacağı düzeyde olmuştur. Ancak kod oluşturmanın maliyeti giderek azaldıkça, daha fazla geliştiricinin bu çözümleri geliştirebilecek durumda olmasını bekliyoruz.

Düşük karmaşıklık senaryosu: kodsuz aracı

Düşük karmaşıklık senaryoları için “basit Aracı”nın (İstem + araç) güvenilirliğinin sorunu çözmek için yeterli olduğunu düşünüyorum. Üstelik bu tür bir Aracıyı kodsuz bir şekilde oluşturmak, kodsuz bir şekilde iş akışı oluşturmaktan daha basit olacaktır.

LLM kendini yenilemeye devam ettikçe, bu tür Aracıların çözebileceği sorunların karmaşıklığının üst sınırı artmaya devam edecektir.

Kodsuz iş akışı oluşturucularının karşılaştığı temel sorunlar şunlardır:gelen「düşük karmaşıklık“Ve「yüksek karmaşıklık“İki yönde ekstrüzyon.

Kodsuz bir şekilde bir Aracı (İstem + araç) oluşturmak, bir iş akışı oluşturmaktan kesinlikle daha basittir. Modelin, Aracı çerçevesinin ve “Aracı oluşturma, değiştirme ve eğitim arayüzünün” sürekli optimizasyonu ile bu Aracılar giderek daha fazla görevi istikrarlı bir şekilde çözebilecektir.

Öte yandan karmaşıklık belli bir seviyeye ulaştığında görsel iş akışı oluşturucu kontrolden çıkacak ve şu anda tek alternatif “kod” olacaktır. Kod yazmak tarihsel olarak az sayıda kişiyle sınırlıydı ve giriş engeli oldukça yüksekti. Bununla birlikte, kod oluşturma modelleri optimize edildikçe ve maliyetler düştükçe, kodla ilgili sorunların çözülmesine yönelik giriş engeli giderek azalacaktır.

Açık olmak gerekirse: n8n, Flowise, LangFlow, Gumloop vb. gibi “LLM odaklı iş akışı oluşturucu” konusunda mükemmel bir iş çıkaran birçok şirket zaten var. Bu ekiplerin çoğu, günümüzün gerçek dünya sorunlarını çözen ve teknik olmayan kullanıcıların harika sonuçlar yaratmasına olanak tanıyan PMF’ler buldu.

Ama sanırımDünyadaBir taneye daha gerek yok「İş akışı oluşturucu“.Tam tersine, çözülmeye değer bir sonraki temel sorular şunlardır:

• Kullanıcıların kodsuz bir şekilde “istikrarlı ve güvenilir bir Aracı” oluşturması nasıl kolaylaştırılır. Bunun “düşük kodlu iş akışı” değil, “Aracı” olduğunu unutmayın;

• “LLM odaklı iş akışı/Ajan” ile ilgili kodun yazılmasını daha iyi hale getirmek için kod oluşturma modeli nasıl optimize edilir.