Çoğu yapay zekâ asistanı “kullan ve unut” mantığıyla çalışır. Bugün bir alışkanlığını düzeltirsiniz, yarın aynı hatayı tekrarlar; geçen hafta ekibinizin özel iş akışını öğretirsiniz, bu hafta hiç duymamış gibi davranır. Her konuşma sıfırdan başlar; model ne kadar akıllı olursa olsun, hâlâ hafızasını kaybetmiş akıllı bir insan gibidir.
Orkas başka bir hedefin peşinde: ajanın günlük kullanımından öğrenmesi, tekrarlanan deneyimleri özümseyip bir dahaki sefere kendi başına uygulayabilmesi. Açıkça söylemek gerekirse, kullandıkça daha faydalı hâle gelir ve bu “fayda” şu yöne doğru gelişir: sizin, tercihlerinize, alanınıza; model sağlayıcısının herkes için önceden belirlediği bir şeye doğru değil.
Bu makale, bu mekanizmanın nasıl kurulduğunu açıklıyor. İş, “model konuşmayı hatırlasın” demek kadar basit değil. Arkasında eksiksiz bir döngü var: kendini gözlemle → değerlendirme yapıp yapmayacağına karar ver → gerçekten değerlendir → sonuçları yeniden kullanılabilir bir şeye yaz → bir dahaki sefere yeniden kullan. Bunu parça parça ele alacağız.
Önce en önemli nokta: aşağıdaki her şey, tüm “gözlemleme”, “kaydetme” ve “değerlendirme” işlemleri, tamamen kendi cihazınızda gerçekleşir. Çalıştırma verileri, beceriler, ajanın kendisi hakkındaki anlayışı; hepsi yerelde sıradan dosyalar olarak saklanır. Hiçbiri Orkas sunucularına yüklenmez; kullanıcılar arası analiz veya model eğitimi için kullanılmaz. “Kendini geliştirme”, bir programın kendi çalışma kayıtlarını yerel olarak okuyup kendisini yerel olarak geliştirmesi demektir; verilerinizi toplaması değil. Bu deneyim bilgisayardan hiç çıkmaz ve yalnızca bu bilgisayarda, yalnızca size hizmet eder.
Baştan sona döngü
tekrar tekrar gerçek kullanım
│ yerel kayıt: hangi araçlar çağrıldı, hata oldu mu, düzeltildi mi
▼
sinyaller birikir
│ sinyaller konuşmadan yerinde çıkarılır, hepsi cihazda tutulur
▼
değerlendirme yapılıp yapılmayacağına karar verilir
│ sinyaller ağırlıklı puanlanır, yalnızca eşik aşılınca tetiklenir; ağ aksaklıkları sayılmaz
▼
arka planda değerlendirme yapılır
│ her turda değil, düzenli aralıklarla; koşulları karşılayan ajanlar seçilir
▼
iki şeye dönüştürülür
│ ① yeniden kullanılabilir “beceriler” ② kendisine dair bir “anlayış”
▼
sonraki tura otomatik olarak taşınır
└──────────► başa dön, devam etBu döngünün her adımının incelikleri var. Hata yapması en kolay yerler, ilk bakışta en basit görünen iki adım: ne zaman değerlendirme yapılacağı ve yapıldığında neyin kaydedileceği. Baştan başlayalım.
1. adım: neredeyse sıfır maliyetle kendini gözlemlemek
Deneyimden öğrenmek için önce bakabileceğiniz bir “deneyim” gerekir. Her ajan çalışmasının sonunda program, yerel olarak ve o anda, çalışmayla ilgili birkaç basit olguyu sayar: bu turda yaklaşık kaç araç çağrıldığı, herhangi bir hata olup olmadığı, hatanın geçici mi (ağ sorunu gibi) yoksa gerçek bir hata mı olduğu ve kullanıcının o anda düzeltme yapıp yapmadığı. Yalnızca birkaç sayaç ve işaret; hepsi bilgisayarda hesaplanır, hiçbir model çağrılmaz ve hiçbir yere gönderilmez.
Bu önemlidir, çünkü model kullanım maliyeti yaratmaz. Bunlar doğrudan mevcut turun konuşma kaydından sayılır; yalnızca “kendini analiz etmek” için ek bir model çağrısı gerekmez. Her turda iç değerlendirme için bir model çağrısı daha gerekseydi maliyet ve gecikme dayanılmaz olur, mekanizma hiçbir zaman kullanıma sunulamazdı.
“Düzeltildi mi?” kısmı biraz ilginç. Bu, cihazınızdaki mesajda birkaç ifadeyi eşleştirerek yapılan, tamamen sezgisel ve yerel bir tahmindir; Çince “不对” / “应该是” / “重新” gibi, İngilizcede ise şu anlamlara gelen ifadeler: wrong, actually, instead. Kesin olmayı amaçlamaz; yalnızca bir sinyaldir, hüküm değil. Ara sıra yanlış pozitif üretmesi sorun değildir; çünkü daha sonra diğer sinyallerle birlikte ağırlıklandırılır. Tek başına buna dayanarak hiçbir karar verilmez.
2. adım: değerlendirme yapmaya gerçekten ne zaman değer?
Bence tüm mekanizma içinde en fazla ustalık gösteren kısım bu.
En basit yaklaşım, “N olay biriktiğinde değerlendirme yap” demektir. Ama bu kabadır: art arda üç ağ zaman aşımı ile art arda üç kullanıcı düzeltmesi elbette aynı şey değildir ve aynı ele alınmamalıdır. Orkas şunu kullanır: ağırlıklı çoklu sinyal puanlaması: dikkate değer her olgu, bir ağırlık taşıyan sinyaldir. Bu turda tetiklenen sinyallerin ağırlıkları toplanır ve yalnızca toplam eşik değerini (varsayılan olarak 0.7) aşarsa değerlendirme yapılır.
Başlıca sinyaller kabaca şöyle:
| Sinyal | Ağırlık | Tetiklenme koşulu |
|---|---|---|
| Kullanıcı düzeltmesi | 0.9 | Bu turda bir kullanıcı düzeltmesi tespit edildi |
| Beceri etkisiz | 0.85 | Bir beceri yüklendi, ancak tur yine de hatayla sonuçlandı |
| Hatadan toparlanma | 0.8 | Hata oluştu, ancak sonunda toparlandı |
| Bilinen bir zayıflığa rastlama | 0.7 | Görev, öz değerlendirmede belirtilen zayıf bir noktaya denk geldi |
| Görev karmaşıklığı | 0.5 | Araç çağrısı sayısı belirli bir sayıyı aştı |
Örneğin hem kullanıcı düzeltmesi (0.9) hem de belirli bir karmaşıklık (0.5) içeren turun toplamı 1.4 olur; bu, 0.7'nin hayli üzerindedir ve değerlendirme yapılır. Yalnızca biraz karmaşık olan tur (0.5) ise eşiğin altında kalır ve geçilir. Ağırlıklandırma ayrıca bir tercih yansıtır: doğrudan kullanıcı düzeltmesi en yüksek ağırlığı, 0.9'u alır; çünkü sinyal-gürültü oranı en yüksek geri bildirim budur. Kullanıcı açıkça yanıldığınızı söylemiştir; dolayısıyla bunun kaydedilmeye değer olma ihtimali çok yüksektir.
O kritik istisna
Tüm puanlama mantığında, bu mekanizmanın “doğru şeyleri öğrenip öğrenmeyeceğini” belirleyen dönüm noktası olarak gördüğüm bir kural var: geçici hatalar asla sayılmaz.
Ağ zaman aşımları, kopan bağlantılar, istek hızı sınırları; bunlar ajanın yeteneğindeki eksiklikler değil, ortam kaynaklı sorunlardır. Bunları dışarıda bırakmazsanız kötü bir şey olur: rastlantısal bir ağ aksaklığı yüzünden bir araç hata verir ve değerlendirme mekanizması bunu “bu araç güvenilir değil, daha az kullan” diye kaydeder; hatta gayet iyi bir beceriyi bozabilir veya silebilir. O andan itibaren ajan yanlış bir dersöğrenmiş olur ve bu hata peşini bırakmaz.
Bu yüzden “hatadan toparlanma”, “beceri etkisiz” ve “bilinen bir zayıflığa rastlama” sinyallerinin tümü, yalnızca geçici nitelikteki hataları açıkça dışarıda tutar. Değerlendirme istemi de bunu tekrar hatırlatır: ağ türü hatalar ortam kaynaklıdır; bunları zayıflık olarak kaydetme, ilgili becerilere dokunma. Kendini geliştiren bir sistemin en çok korkması gereken şey yavaş öğrenmek değil, yanlış yönde öğrenmektir. Bu istisna tam da buna karşı koruma sağlar.
3. adım: değerlendirme gözünüzün önünde değil, arka planda yürür
Kolayca düşülen bir tuzak: “değerlendirme zamanı” olduğunu fark ettiğiniz anda durup orada değerlendirme yapmak. Bu, ajanın ara sıra tekliyormuş ve “hayatı düşünmek” için konudan uzaklaşıyormuş gibi hissettirmesine yol açar; kötü bir deneyimdir.
Orkas, değerlendirmeyi sabit bir ritimle arka plana taşır. Zamanlama kuralları kabaca şöyle:
- Belirli aralıklarla bir değerlendirme döngüsü başlat (örneğin on iki saati biraz aşan aralıklarla).
- Çok sık çalışmaması için aynı ajanın iki değerlendirmesi arasında asgari bir bekleme süresi (birkaç saat) uygula.
- Ancak çok uzun süredir değerlendirme yapmadıysa (örneğin bir haftadan fazla), süresiz ertelenmesin diye bir değerlendirmeyi zorunlu kıl.
- Aynı anda fazla dağılmaması için her döngüde seçilen ajan sayısını sınırla.
Sevdiğim küçük bir tasarım var; adı değişiklik kontrolü: bir döngü başladığında önce bu ajanda son değerlendirmeden bu yana yeni bir şey olup olmadığını kontrol et; yeni sinyaller, güncellenmiş konuşma kayıtları gibi. Hiç hareket yoksa bu sefer atla ve model maliyeti yaratan bir değerlendirmeyi boşa harcama. Basit, ama pratikte çok tasarruf sağlıyor.
4. adım: değerlendirme gerçekte nasıl çalışır?
Gerçekten değerlendirme zamanı geldiğinde akış şöyledir: önce son etkinlikleri bir “paket” hâlinde düzenle, ardından özenle yazılmış bir istemle eşleştirip okuması ve özetlemesi için modele ver.
Paketin bir bütçesi vardır: en fazla birkaç yakın tarihli konuşmayı al, birkaç tür sistem olayı ekle, bunları zaman sırasına göre iç içe yerleştir ve toplamı bir token sınırının altında tut (örneğin on bini biraz aşan bir sınır). Tüm geçmiş olduğu gibi içeri dökülmez; hem sığmaz hem de sinyal-gürültü oranı düşük olur.
Asıl özen gerektiren şey istemdir. Modelden “betimlemeler” değil, şunu üretmesini ister: uygulanabilir talimatlar. Fark küçük görünür ama çok önemlidir. Karşılaştırın:
✗ “Ajanın çıktısı bazen fazla uzun; dikkatli ol.”
✓ “Aile ofisi sorularını yanıtlarken asla 5 maddeyi aşma.”
✗ “Kullanıcı kısa çıktıları tercih ediyor gibi görünüyor.”
✓ “Aile ofisi bağlamında yanıt verirken her zaman önce sonucu, ardından gerekçeyi ver.”
İstem, modeli somut tetiklenme koşulları içeren “asla / her zaman / şu olduğunda bunu yap” yapılarına açıkça yönlendirir. Nedeni pratiktir: “kısa olmaya dikkat et” diyen bir not, ajan bir dahaki sefere okuduğunda uygulanabilir bir şey söylemez; oysa “asla 5 maddeyi aşma” doğrudan izlenebilir. Kendini geliştirmenin faydalı olması için özümsenen şeyin, doğru ama basmakalıp bir söz değil, işe yarayan bir talimat olması gerekir.
Değerlendirmeden sonra model birkaç şey yapabilir: beceri oluşturmak veya değiştirmek, kendisi hakkındaki anlayışını güncellemek ya da bu zaman diliminde gerçekten kaydetmeye değer bir şey yoksa yalnızca “kaydedilecek bir şey yok” demek. Hiçbir şey yapmamasına izin vermek de başlı başına önemli bir tasarım tercihidir: işe yaramaz bir gürültü yığını biriktirmemek için öğrenme sonucunu zorlamayın.
İki şeye dönüştürülür
Değerlendirme çıktısı iki yere gider.
Biri becerilerdir. Her beceri, meta veriler içeren bir Markdown belgesidir: adı, açıklamayı, oluşturulma ve güncellenme zamanlarını, kaç kez yama yapıldığını ve en son ne zaman kullanıldığını kaydeden bir ön bilgi bloğu; ardından asıl adımlar veya önemli noktalar gelir:
---
name: "Weekly Report Export"
description: "Compile this week's data into the standard weekly-report format"
createdAt: "2025-01-01T00:00:00Z"
updatedAt: "2025-01-08T00:00:00Z"
patchCount: 2
lastUsedAt: "2025-01-09T10:00:00Z"
---
## Steps
1. ...
2. ...Becerileri dosya olarak saklamak pratik bir tercihtir: insan bunları doğrudan okuyup düzenleyebilir; şeffaf olmayan bir veritabanına kilitlenmiş değillerdir.
Diğeri, kendisi hakkındaki anlayışıdır. Bu kısım, ajanın kendisine yazdığı iki parçalı bir nota daha çok benzer: biri “nelerde iyiyim ve nerelerde tökezleme eğilimindeyim”, diğeri “bu kullanıcı ve bu alan için geliştirdiğim yöntemler neler” der. İkisinin de uzunluk sınırı vardır; bu onları kısa tutmaya zorlar. Daha uzun olan değil, daha doğru olan daha iyidir. Sonraki konuşmanın başında bu içerik sistem istemine eklenir; böylece ajan “kendisi hakkında bir anlayışla” işe başlar.
Beceriler yalnızca yazılıp bırakılmaz
Yalnızca beceri oluşturursanız zamanla bir hurdalık biriktirirsiniz. Bu yüzden becerilerin tam bir yaşam döngüsü vardır.
Oluşturmanın ötesinde, daha yaygın işlem aslında yama yapmaktır: mevcut bir beceriyi tamamen kaldırıp yeniden yazmak yerine küçük bir bölümünü değiştirmek. Her yama bir sayacı artırır ve güncellenme zamanını yeniler. Böylece beceri, her turda baştan yazılmak yerine deneyimle yavaş yavaş gelişir.
Sayı için de bir üst sınır vardır. Toplam beceri sayısı sınırlıdır (örneğin 200); kapasite dolduğunda yeni bir beceri eklemek, eski bir becerinin şu yöntemle çıkarılmasını sağlar: LRU (en uzun süredir kullanılmayan) . Böylece yer açılır. Çıkarma işleminin bir önceliği vardır: önce oluşturulduğundan beri hiç kullanılmayanları çıkar. Hiç okunmamış bir beceri muhtemelen en başta doğru biçimde özümlenmemiştir ve yerini başkasına bırakması daha iyidir.
Ajan bir beceriyi her okuduğunda “son kullanım zamanı” yenilenir. Bu zaman damgası hem LRU'nun çıkarma kararını besler hem de yerel mekanizmanın hangi becerilerin gerçekten kullanıldığını, hangilerinin yalnızca yer kapladığını anlamasını sağlar.
Bir becerinin gerçekten faydalı olduğunu nasıl anlarsınız?
Pek çok “otomatik öğrenme” sisteminin üşenip atladığı adım budur: bir şey öğrendi, ama işe yarıyor mu? Orkas bunu yerel olarak birkaç ölçüte dönüştürür. Bu ölçütler, bilgisayardaki geliştirme mekanizmasının kendi kullanımı için, hangi becerinin değiştirileceğine veya silineceğine karar vermek amacıyla hesaplanır ve yine bu bilgisayardan hiç çıkmaz.
Mekanizma şöyle: her turun başında kullanılabilir beceriler sistem isteminin dizininde görünür; bu bir “gösterim”dir. Ajan o turda bir beceriyi gerçekten okursa bu bir “çağrı”dır. İkisini karşılaştırınca ilk ölçütü elde edersiniz —
- Çağrılma oranı = çağrılar / gösterimler. Günlerce kimsenin kullanmadığı bir becerinin çağrılma oranı düşüktür; bu da ya işe yaramadığı ya da ne zaman kullanılacağının anlaşılamayacağı biçimde tanımlandığı anlamına gelir.
- Kullanım sonrası düzenleme oranı = becerinin çağrıldığı, ancak kullanıcının ardından sonucu elle düzenlediği durumların payı. Yüksek olması, becerinin ürettiğinin kullanıcının tercihine tam uymadığını gösterir.
- Etkisizlik oranı = becerinin çağrıldığı, ancak turun geçici olmayan bir hatayla bittiği durumların payı. Yüksek olması, becerinin kendisinde bir sorun olabileceğine işaret eder.
Burada o istisnanın izini yeniden görürsünüz: etkisizlik oranı hesaplanırken geçici hatalar sayılmaz; kullanıcının yarıda elle durdurduğu turlar da sayılmaz. Tek bir ağ aksaklığı yüzünden gayet iyi bir beceriye eksi puan veremezsiniz.
Bu birkaç sayıyla beceriler, “kara kutuda biriken şeyler” olmaktan çıkıp “değerlendirilebilir ve iyileştirilebilir şeyler” hâline gelir. Hangi becerinin değiştirileceği veya silineceği artık sezgiye dayalı bir karar değildir.
Döngüyü tamamlamak
Yukarıdakileri birleştirdiğimizde tam bir döngü şöyle işler:
Ajan gerçek görevleri yürütürken çalışma verilerini yerel olarak kaydeder ve sinyalleri yerinde işaretler. Arka plandaki değerlendirme döngüsünün zamanı geldiğinde, yeni etkinliği olan ve bekleme süresini doldurmuş ajanları seçer; her birinin son etkinliklerini bir pakette düzenler ve modelden bunları kendisi hakkındaki mevcut anlayışıyla karşılaştırarak incelemesini ister. Birleştirilmesi gerekenler birleştirilir, kaldırılması gerekenler kaldırılır, özümsenmesi gerekenler yeni becerilere dönüştürülür. İncelemenin çıktısı beceriler ve öz anlayış olur. Sonraki konuşmada bu beceriler istem dizinine, öz anlayış da sistem istemine girer; ajan, önceki turda öğrendiklerini yanında taşıyarak geri döner. Ardından bu tur yeni ölçütler ve sinyaller üretir ve bunlar başlangıca geri beslenir.
Döngü, turdan tura sürer. Her tur büyük bir sıçrama getirmez, ama yön tektir: sizi daha iyi anlamak ve aynı hataları daha az tekrarlamak.
Adını koymaya değer birkaç ödünleşim
Geriye dönüp baktığımızda, bu mekanizmadaki birkaç kararın belirleyici olduğunu görüyoruz.
Öz değerlendirme ucuz olmalı. Sistemin kendini gözlemlemesi, model maliyeti sıfır olan metrikler kullanır; gerçekten pahalı olan değerlendirme ise arka plana taşınır, seyrek çalıştırılır ve önce değişiklik kontrolünden geçirilir. "Pahalı" kısmı sıkı biçimde sınırlandırırsanız mekanizmanın bütünü gerçekten çalışabilir.
Yanlış öğrenmektense hiç öğrenmemek daha iyi. Geçici hataları kapsam dışında tutmak, değerlendirmenin "hiçbir şey kaydetmemesine" izin vermek, belirsiz açıklamalar yerine uygulanabilir talimatlar yazmak — hepsi aynı yargıya dayanır: kendini geliştiren bir sistem için yanlış yönde öğrenmek, yavaş öğrenmekten çok daha tehlikelidir.
Öğrenilenler görünür, düzenlenebilir ve sizin kontrolünüzde olmalı. Beceriler düz metin dosyalarıdır, sistemin kendine ilişkin anlayışı düz metin bir nottur, becerilerin etkinliği metriklerle kontrol edilebilir — üstelik tüm bu dosyalar bulutta değil, kendi makinenizde bulunur. Hiçbir yerde kara kutu yoktur; bir insan bunları istediği zaman açıp değiştirebilir.
Öğrenmeye fren koyun. Sayı sınırları, LRU ile çıkarma, uzunluk kısıtları — bunlar olmadan "sürekli öğrenme" er ya da geç "sürekli şişmeye" dönüşür. Unutmak, elemek ve budamak, hatırlamak kadar önemlidir.
Sonuç
Orkas'ın kendi kendine evrilmesi, özünde ajana yavaş bir döngü eklemektir: hızlı döngü, her konuşmadaki anlık yanıttır; yavaş döngü ise düzenli aralıklarla geriye bakıp deneyimi bir sonraki sefer kullanılabilecek bir şeye dönüştürmektir. Zor olan "modelin hatırlamasını sağlamak" değildir — kolayca gözden kaçan mühendislik kararlarıdır: hangi deneyimlerin kayda değer olduğunu ayırt etmek, rastlantısal bir başarısızlıkla yönünü şaşırmamak, öğrenilenleri gerçekten uygulanabilir hâle getirmek ve şişmeden önce budamak.
Bu kararlar bir araya geldiğinde "kullandıkça daha yararlı olur" sözü, bir pazarlama ifadesinden gerçekten çalışan bir mekanizmaya dönüşür. Sizden öğrenen — ve yanlış şeyleri öğrenmeyen — bir asistan, yalnızca daha zeki olan bir asistana kıyasla çoğu insanın gerçekte istediğine daha yakın olabilir.