Bozulmayan agentic iş akışları: araç çağırma, döngüdeki insan, ve sistemler arasındaki dikişler

İş süreci otomasyonu ve bir AI ajanı aynı şeymiş gibi satılıyor, ama değiller. Otomasyon sabit bir hattır: ikinci adım her zaman aynı şekilde birinci adımı takip eder. Ajan ise, bir araç çağrısının az önce ne döndürdüğüne dayanarak modelin bir sonraki adımın ne olacağına karar verdiği bir döngüdür. İkisinin de yeri var - bir işletmenin gerçekten ihtiyaç duyduğu şeylerin çoğu, her kararı veren bir ajan değil, bir veya iki agentic karar noktası olan otomasyondur.

Her ikisinin de altındaki mimari, gerçek verilerle temas ettiğinde hayatta kalıp kalmayacağını belirleyen şeydir: modele bağlamı nasıl beslediğiniz, kodunuzun güvenebileceği bir biçimde cevabı nasıl geri aldığınız, modelin diğer sistemlere nasıl uzandığı, ve bir insanın hâlâ evet demesi gereken yer. Bir projenin çoğunu model seçimine değil, işte bu tesisata harcarım.

1. Bağlam mühendisliği: modele her şeyi değil, doğru dilimi vermek

Bağlam mühendisliği, belirli bir çağrıda modelin neyi gördüğüne - hangi kayıtları, hangi önceki turları, hangi talimatları - ve en az onun kadar önemlisi, neyi görmediğine karar vermenin gösterişsiz işidir. Her seferinde tüm müşteri geçmişini veya tam bir belgeyi prompt’a boşaltmak titizlik değildir; gerçek soruyu modelin dikkatinden daha da uzaklaştıran ve her çağrının maliyetini sessizce şişiren bir gürültüdür.

İşe yarayan model bir bellek sorunundan çok bir arama sorununa benzer: bu belirli adımla ilgili iki üç kaydı çekmek, öncekini kelimesi kelimesine tekrarlamak yerine özetlemek, ve ajanın yalnızca ihtiyaç duyduğunda daha fazlasını istemesine izin vermek. On binden doğru beş satırı güvenilir şekilde çeken bir iş akışı, on binin hepsini tıkıştırıp umut eden bir iş akışını yener.

2. Yapılandırılmış çıktılar ve araç/fonksiyon çağırma gerçek arayüzdür

Serbest metinle cevap veren ve regex ile ayrıştırılan bir model, bu yapıların üretimde sessizce başarısız olduğu yerdir. Yapılandırılmış çıktılar - modelin içinde cevap vermeye zorlandığı bir JSON Schema - ve araç/fonksiyon çağırma - modelin bir eylemi düz yazıyla tarif etmek yerine tipli argümanlarla belirli bir fonksiyon istemesi - kodunuzun her çıktıyı yeniden okuyan bir insan olmadan harekete geçecek kadar bir yanıta güvenmesini sağlayan şeylerdir.

Şemayı modelden çıkarken ve gerçek bir sisteme ulaşmadan önce tekrar doğrularım, çünkü bir model sözdizimsel olarak geçerli ama elindeki iş kuralı için yine de yanlış olan bir JSON üretebilir - negatif bir miktar, geçmişte bir tarih, hesabın desteklemediği bir para birimi. Şema, şekil hatalarını yakalar; ikinci, sıkıcı bir doğrulama katmanı ise geçerli JSON olup yine de yanlış olanları yakalar.

3. Embedding’ler ve vektör veritabanı - yalnızca arama gerçekten iş olduğunda

Embedding’ler ve bir vektör veritabanı, görev gerçekten geri getirme (retrieval) olduğunda yerini hak eder: bu yeniye en yakın üç destek biletini bulmak, bu soruya en yakın sözleşme maddesini bulmak. Normal bir veritabanı sorgusunun zaten karşıladığı sabit, küçük bir kayıt kümesi için yanlış araçtır - on bir olası kategorisi olan bir iş akışına vidalanmış bir vektör veritabanı gördüm, oysa bir arama tablosu daha hızlı, daha ucuz ve hata ayıklaması daha kolay olurdu.

Doğru araç olduğunda, gerçekten özen isteyen şey embedding modeli değildir - neyin nasıl parçalara ayrıldığı ve kaynak belge değiştikten sonra indeksin ne kadar taze kaldığıdır. Bayat parçalar üzerinde bir vektör araması, kendinden emin ama yanlış bir cevap verir, ve ajanın çıktısında bunun olduğunu size söyleyen hiçbir şey yoktur.

4. Döngüdeki insan ve API orkestrasyonu: gerçekte nerede bozulur

En çok gördüğüm arıza, modelin kötü akıl yürütmesi değil - iki sistem arasındaki dikiştir: zaman aşımına uğrayan ve ajanın iki kez yeniden denediği bir API çağrısı, kopya bir sipariş göndererek; önceki adım yazmayı bitirmeden ateşlenen bir webhook; tedarikçi tarafında başarılı olan ama ajanın aldığı yanıtın başarısız dediği bir araç çağrısı. CRM, faturalama ve e-posta arasında çağrıları orkestre etmek, bir zaman aşımında veya kısmi başarısızlıkta ne olacağına üretimde gerçekleşmeden önce karar vermek demektir, sonra değil.

Para gönderen, bir kaydı silen veya bir müşteriye e-posta gönderen her şey, ateşlenmeden önce bir insan onay adımından geçer - model genel olarak güvenilmez olduğu için değil, yanlış bir otomatik eylemin maliyeti bir fazladan tıklamanın maliyetine göre asimetrik olduğu için. Ajanın otomatik olarak yanlış bir fatura göndermesindense, bir kişinin günde yirmi doğru eylemi onaylamasını tercih ederim.

Sonuç: ajan kolay olan %10’dur

Bir model seçmek ve ilk prompt’u yazmak, agentic bir iş akışının gerçekten kolay kısmıdır. Beslenen bağlam, doğrulanan şema, yalnızca gerektiğinde çalışan vektör araması, üç API arasındaki yeniden deneme mantığı, ve bir insanın hâlâ onayladığı o tek adım - işte diğer %90 budur, ve altı ay sonra bir Salı günü kimsenin test etmediği verilerle otomasyonun hâlâ çalışıp çalışmayacağına karar veren de budur. Otomatikleştirmek istediğiniz süreci formdan yazın, %10’unun ajan, gerçekten inşa edilmesi gereken %90’ın ne olduğunu size söyleyeyim.