Bir çoklu-ajan sistemini nasıl notlandırıyoruz.

Çoklu-ajan AI kuran çoğu ekibe en zor problemlerinin ne olduğunu sorarsan, orkestrasyon, ya da erişim, ya da maliyet derler. Bunlar zor. Ama gerçekten en zor problem — şirketin hayatta kalıp kalmayacağına karar veren — değerlendirme: bir değişikliğin sistemi daha iyi mi yoksa daha kötü mü yaptığını bilmek.

Sıradan yazılımda bilirsin. Test paketi ya yeşildir ya kırmızı. Diff incelenebilir. Bir çoklu-ajan sisteminde çıktı determinist değildir — aynı ajana aynı soruyu iki kez sor, iki farklı geçerli cevap al. Determinist olmayan çıktıyı diff'leyemezsin. Dolayısıyla 'bu değişiklik yardımcı oldu mu?' gerçek bir ölçüm problemine dönüşür ve çoğu ekip onu sezgiyle cevaplar — yayına alır, birkaç çalıştırmaya göz gezdirir, umarlar. Bu, yaklaşık on müşteriden öteye ölçeklenmez. GOGOGO LLC'de onun yerine çalıştırdığımız değerlendirme harness'ı bu.

Çekirdek kural: her ajan adımı notlandırılır

Harness, yayından önce çalıştırdığın ayrı bir test dosyası değil. Runtime'ın bir parçası. Her tek ajan çağrısı — geliştirmede, CI'da ve üretimde örneklenmiş bir kesirde — bir değerlendiriciler paneli tarafından otomatik notlandırılır. Not, çalıştırmanın trace_id'sine iliştirilir ve çıktının yanında olay günlüğüne yazılır.

Bu önemli çünkü bir değerlendirmenin ne olduğunu değiştirir. Bir değerlendirme, yayından önce bir kez geçtiğin bir kapı değildir. Sistemin şimdiye kadar yaptığı her çalıştırmanın sürekli bir özelliğidir. Bir müşteri kötü bir sonuç bildirdiğinde, yeniden-üret-ve-tahmin-et yapmayız — trace_id'yi çekeriz, tam o çalıştırmanın her adımındaki notları okuruz ve hangi ajanın hangi değerlendiriciyi başarısız ettiğini görürüz. Değerlendirme harness'ı aynı zamanda hata ayıklayıcıdır.

Dört değerlendirici sınıfı

Dört tür değerlendirici çalıştırıyoruz. Her ajan çıktısı, türüne uygulanan dördünden hangileri varsa onların içinden geçer.

1 · Şema geçerliliği

En ucuz, en katı ve en çok atlanan değerlendirici. Runtime'daki her ajan tipli bir çıktı sözleşmesi bildirir — bir pydantic şeması. Şema-geçerliliği değerlendiricisi düz çıktıyı ona karşı denetler: doğru alanlar, doğru tipler, null'a izin verilmeyen yerde null yok, aralıktaki enum'lar. Bu bir boolean. %100 çağrıda çalışır çünkü neredeyse bedava. 'AI yanlış' olaylarının şaşırtıcı bir kesri aslında 'AI ayrıştırılamayan, geçerli görünen metin döndürdü' — şema geçerliliği bunları daha hiç müşteri problemi olmadan yakalar.

2 · Dayanaklılık

Erişim yapan herhangi bir ajan için — erişim ve yeniden-sıralayıcı ajanları — dayanaklılık değerlendiricisi şunu sorar: çıktıdaki her olgusal iddia gerçekten erişilen bir belge tarafından destekleniyor mu? Tek işi gerekçelendirme denetimi olan ayrı, daha küçük bir model tarafından çalıştırılır: iddia X, kaynak Y, Y X'i destekliyor mu — evet mi hayır mı. Dayanaklılık başarısızlıkları erişim kaymasının erken-uyarı sinyalidir. Külliyat değiştiğinde ve dayanaklılık puanları düştüğünde, müşteriden önce biliriz.

3 · Halüsinasyon denetimi

Dayanaklılıktan ayrı. Dayanaklılık 'iddia destekleniyor mu?' diye sorar; halüsinasyon değerlendiricisi 'ajan hiçbir yerde var olmayan bir varlık, bir sayı, bir yetenek ya da bir kaynak gösterimi mi uydurdu?' diye sorar. Bu, üreteç ajanlarda — serbest metin üretenlerde — çalıştırılır. Müşteri güveni için tek en önemli değerlendirici, ve ekiplerin en sık atladığı olan, çünkü sistemi daha sık başarısız oluyormuş gibi gösterir. Daha sık başarısız olmuyor. Başarısızlıklar hep oradaydı; değerlendirici onları görünür kılıyor.

4 · Yeniden-oynatılabilirlik

Meta-değerlendirici. Şunu sorar: bu çalıştırmanın trace_id'si verildiğinde, tüm çalıştırma günlüklenen girdilerden determinist olarak yeniden yürütülüp aynı yörüngeyi (illa aynı metni değil — aynı ajan çağrıları ve araç çağrıları dizisini) üretebilir mi? Yeniden oynatılamayan bir çalıştırma hata ayıklanamaz, denetlenemez ve bir regresyon sabiti olarak kullanılamaz. Yeniden-oynatılabilirlik başarısızlıkları altyapı hatalarıdır ve çıktı iyi görünse bile bunları yayını engelleyen sayarız.

Bir değişiklik nasıl yargılanır

Bir mühendis bir değişiklik önerdiğinde — yeni bir prompt, takas edilmiş bir model, yeniden ayarlanmış bir yeniden-sıralayıcı — daha iyi göründüğü için yayına girmez. Dondurulmuş bir değerlendirme setine karşı çalıştığı için yayına girer: bilinen-iyi notlara sahip birkaç yüz kaydedilmiş gerçek çalıştırma. Değişiklik uygulanır, değerlendirme seti yeniden çalıştırılır ve dört değerlendirici puanı önce ve sonra karşılaştırılır.

1. Dört değerlendirici puanı da sabit kalır ya da iyileşir → yayına al.
2. Bir puan iyileşir, bir başkası geriler → değişiklik bir takastır ve tam sayılar masadayken bir insan kararına gider — asla bir göz kararıyla değil.
3. Herhangi bir puan, hiçbir şey iyileşmeden gerilerse → değişiklik otomatik reddedilir. Demonun ne kadar iyi göründüğü önemli değil.

Küçük bir ekibin kaliteyi sessizce aşındırmadan tek runtime üzerinde dört ürün yayına almasını sağlayan disiplin bu. Her değişikliğin ona iliştirilmiş bir sayısı var. Sayılar Goddo, GoPeople, GoVista ve GoTrack genelinde karşılaştırılabilir çünkü hepsi aynı harness'ı çalıştırır.

Başarısız bir değerlendirme neden bir özellik

Ekiplerin gerçek bir değerlendirme harness'ı kurmamasının en yaygın nedeni teknik değil, duygusal. İyi bir harness sistemini daha kötü gösterir — pano başarısızlıklarla yanar. Mühendisler ve kurucular o panoyu istemez, çünkü sistem bozukmuş gibi hissettirir.

Ama başarısızlıklar hep oradaydı. Harness onları yaratmadı; yüzeye çıkardı. Değerlendirme harness'ı olmayan bir çoklu-ajan sistemi, daha az başarısız olan bir sistem değildir — görünmez başarısız olan bir sistemdir, ki bu da müşteride başarısız olduğu anlamına gelir. Başarısız bir değerlendirme, bir başarısızlığın olabileceği tek en ucuz yerdir. Bu bir özellik. CI'da panonun kırmızıya dönmesi, sistemin tam tasarlandığı gibi çalışmasıdır.

“Ölçemediğini iyileştiremezsin, ve determinist olmayan çıktıyı ona bakarak ölçemezsin. Değerlendirme harness'ı bir çoklu-ajan sistemine cıvatalanmış test altyapısı değildir. Sistemin geri kalanının bir yönü olmasını sağlayan parçasıdır.”

Elinde hiçbir şey yoksa nereden başlamalı

Çoklu-ajan AI kuruyorsan ve değerlendirme harness'ın yoksa, dört değerlendiriciyi bir anda kurmaya çalışma. Şema geçerliliğiyle başla — neredeyse bedava, boolean, ve şu an müşterilere yayınladığın bir hata sınıfını anında yakalayacak. Sonra yeniden-oynatılabilirliği ekle, çünkü o olmadan bir regresyon seti kuramazsın. Dayanaklılık ve halüsinasyon, onlar için bir model bütçen olduğunda üçüncü ve dördüncü gelir. %100 çağrıda çalışan tek bir değerlendirici, hâlâ tasarlamakta olduğun dört değerlendiriciyi yener.

Değerlendirme harness'ı notlarını karşılaştırmak istersen — değerlendirici tasarımı, örnekleme oranları, dondurulmuş değerlendirme setini nasıl kurduğun — bana ulaşmak kolay. atakanozalan.com ya da [email protected].