Bu sayfada
Pazartesi değişen bir ürün kataloğu hayal edin. Asistanın istemi hâlâ cuma günkü listeyi içeriyor. Ekip istemi güncelliyor. Eski listenin ikinci kopyası ise modeli eğitmek için kullanılan örneklerde duruyor. Asistan aynı oturumda bir güncel, bir de eskimiş yanıt veriyor.
Bu örnek bir hatadır, ancak mekanizması yaygındır: aynı bilgi birden fazla yere yerleşmiştir.
İstemler, bilgi getirme ve model ağırlıkları üzerine bir konuşma yararlı bir sınır çizer. İstem asistana nasıl davranacağını söyler. Bilgi getirme, belirli görev için güncel ve kaynak gösterilebilir bilgiyi sağlar. Model uyarlaması istikrarlı bir örüntü öğretebilir. Bunları “önce istem, sonra bilgi getirme, yanıt hâlâ yanlışsa ince ayar” sıralaması olarak görmek, olgusal hatayı yanlış teşhis eder.
İstem iyi bir katalog değildir
İstemler kolay düzenlendiği için çekicidir. Paragraf eklersiniz; sonraki istek onu taşır. Bu kolaylık iki maliyeti gizler. Bilgi ilgisizken bile her çağrıda gönderilir. Büyük istem, modelin kuralın hangi kopyasını kullandığını anlamayı zorlaştırır.
“Kampanya göndermeden önce sor” gibi kalıcı yönerge ajanın yakınında olmalıdır. Bu mağazanın güncel özel alanlarının listesi olmamalıdır. Hesap yöneticisi özellik eklediğinde değişebilir. Kiracılar arasında farklı olabilir. Bir çalışma alanına görünürken diğerine yasak olabilir.
Brevo bağlayıcı kılavuzu alan tanımlarının kişi senkronizasyonu için neden önemli olduğunu gösterir. Özellik hedef hesapta tanımlı değilse adından mantıklı görünen eşleme amaçlanan alanı üretmeyebilir. Ajan, eğitimden genel alan listesini hatırlamak yerine hesabın güncel sözleşmesini incelemelidir.
Yararlı getirme sonucu sorgulanabilecek kadar küçüktür. Hangi hesaba veya kiracıya uygulandığını, ne zaman okunduğunu, hangi işlemi veya alanı anlattığını belirtmelidir. Getirilen iki bölüm çelişirse sistem daha akıcı olanı sessizce seçmek yerine çelişkiyi göstermelidir. Doğru sonraki adım, istemi daha güçlü sözlerle yazmak değil yeni sorgu veya inceleme olabilir.
Bilgiyi kapsamıyla birlikte getirin
Yararlı bilgi kaydı metinden fazlasını taşır. Kaynağa, sürüme veya getirme zamanına, hesap kapsamına ve kaldırılıp değiştirilmesi için açık bir yola ihtiyaç duyar. Bir satıcı hesabında bulunan alan tanımı başka bir hesap için evrensel kurala dönüşmemelidir.
Kişi özelliğine ilişkin soru, onu yanıtlayan en küçük bölümü getirebilir: alan adı, türü ve bulunduğu hesap. Yanıt bu kaynağa dönebilir. Eşleme başarısız olursa ekip bilginin eski olup olmadığını, yanlış hesabın sonucunun dönüp dönmediğini veya modelin doğru bölümü yanlış anlayıp anlamadığını sorabilir.
Bunlar farklı onarımlardır. İstem düzeltmesi, kiracı sınırını aşan getirme filtresini onaramaz. Daha büyük model, hiç getirilmemiş özellik tanımını sağlayamaz.
MCP açıklaması, ajanın araçları nasıl sorgulayabildiğini anlatır. Araç ilgili sözleşmeyi döndürmeli; uygulama da onu kimin görebileceğini belirleyen erişim kurallarını uygulamalıdır. “Başka kiracının verisini açıklama” diyen metin yönergesi, kapsamı sınırlandırılmış sorgunun yerini tutmaz.
Bu ayrım onarımı hızlandırır. Hedef alanın adı değişirse şema kaynağını güncelleyin ve etkilenen eşlemeyi geçersiz kılın. Ajan istikrarlı yönergeyi sürekli yanlış anlıyorsa yönergeyi değiştirin veya hedefli eğitim yaklaşımını test edin. Yanıt, getirme sistemi yanlış hesabı seçtiği için yanlışsa model ağırlıklarını düzeltmek nedeni ıskalar. Her hata sınıfının farklı sahibi ve düzeltme yolu vardır.
- Kalıcı yönerge
Asistan nasıl davranmalı
- Sınırlandırılmış bilgi getirme hesap · sürüm · zaman
Şu anda doğru olan
- Eşleme kararı
Bu görevde güncel bilgiyi kullanın
- Denetlenen yazma
Kod izin ve kapsamı kontrol eder
Örüntüleri ancak yerleştikten sonra öğretin
Makul bir itiraz şudur: “Bir bilgi sürekli kullanılıyorsa neden onu daha küçük modele öğretmeyelim?” Yalnızca tekrar yeterli değildir. Bilgi, model güncellemeleri arasında doğru kalmalı; model de bağlamları ayırabilmelidir.
İstikrarlı sınıflandırma biçimi sonunda ince ayara değer olabilir. Sağlayıcının güncel alan listesi iyi aday değildir. Nadiren değişse bile tek eski yanıtın bedeli çok sayıda kayda uygulanan yanlış eşleme olabilir. Bilgiyi kişinin inceleyip güncelleyebileceği yerde tutun.
Kaynak konuşma, her akıl yürütme hatasını bilgi getirmeyle çözmemeyi de söyler. Model ilgili iki belgeyi doğru karşılaştıramıyorsa elli belge daha eklemek ona muhakeme öğretmez. Önce doğru bölümün gelip gelmediğini, ardından o bölüm üzerindeki değerlendirmenin sağlamlığını sorun.
Entegrasyon kurucusu için onarım sırası şöyledir: yanlış iddiayı belirleyin; getirilen alan veya API bölümünü inceleyin; hesap ve sürümü doğrulayın; gerekirse kaynağı veya getirmeyi düzeltin; kararı yeniden test edin. Model değişikliğini ancak bundan sonra düşünün.
Bunun maliyeti gerçek bir bilgi katmanı sürdürmektir: kaynak güncellemeleri, erişim kontrolleri ve kaynak gösterimi. Kazancı, tek yerde düzeltilebilen bilgidir.
Değişen bir sözleşme, modelin onu unutmasını beklemek zorunda kalmamalıdır.
Sık Sorulan Sorular
Ajan isteminde ne bulunmalı?
Davranış ve sınırlarla ilgili kısa, kalıcı yönergeler orada bulunmalı. Değişen katalog, kiracıya özgü alan listesi veya güncel sağlayıcı kuralı gerektiğinde yetkili kaynaktan getirilmeli.
Modele güncel belgelerle neden ince ayar yapmayalım?
İnce ayar, değişen bilgiyi incelenmesi ve güncellenmesi zor ağırlıklara gömebilir. Önce karar anında doğru belgenin getirilip kaynak gösterildiğinden emin olun.
Yanlış olgusal yanıt nasıl düzeltilmeli?
Kaynak belgeyi, sürümünü, getirme filtresini ve dönen bölümü inceleyin. Modeli değiştirmeden önce bilgiyi veya getirme yolunu düzeltin.