Bir AWS hesabında bir gecede 200 dolarlık bir fatura belirdiğini gördüm.
Sistem çöktüğü için değil.
Bir ajan, altı saat boyunca hiçbir durma koşulu olmadan döngü halinde çalıştı ve her yinelemede OpenAI API'sini çağırdı.
Tüm izleme panoları sistemin sağlıklı olduğunu söylüyordu.
Sabah fatura gelene kadar kimse fark etmedi.
AI sistemlerini nasıl çalıştıklarını anlamadan inşa ettiğinizde olan budur.
Çoğu insan AI mühendisliğini tersten öğrenir.
Bir kütüphane kur. Bir eğitim izle. Bir API çağrısı yap. Bir şey çalışır hale getir. İlerleme kaydettiğini hisset.
Sonra anlamsız bir şekilde bir şey bozulur.
Düzelene kadar sayıları rastgele değiştirirler.
Bu mühendislik değil. Klavyenin başında umutla beklemek.
İşte bunu düzelten 6 kavram.
Her şeyi açıklayan tek bir cümle
Her AI sistemi, ne kadar karmaşık olursa olsun, şunlardan oluşur:
Bellek (RAG) + Düşünme (LLM + Tokenlar) + Eylemler (Ajanlar) + Ölçüm (Değerlendirmeler)
… Bağlam Mühendisliği aracılığıyla bir araya getirilir.
Bütün alan budur.
Aşağıdaki her şey, her bir parçanın gerçekte ne anlama geldiğini açıklamaktan ibarettir.
1. Tokenlar ve Bağlam Penceresi
LLM'ler kelimeleri okumaz. Token adı verilen parçaları okurlar.
"engineering" → 1 token
"unbelievable" → 2 token Boşluklar ve noktalama işaretleri de sayılır.
Her modelin bir bağlam penceresi vardır — aynı anda tutabileceği tokenlar için sabit bir sınır.
→ Claude: 200.000 token
→ GPT-5: 400.000 token
Bunu bir toplantı odasındaki beyaz tahta gibi düşünün.
Model yalnızca tahtada o anda yazılı olanla çalışır.
Tahta dolduğunda, yer açmak için eski notlar silinir.
Model düşünme yeteneğini kaybetmez.
Daha önceki bilgilere erişimini kaybeder.
Bu neden üretim sistemlerini bozar:
→ Tokenlar paraya mal olur — her API çağrısı, giriş ve çıkış tokenı başına ücretlendirilir
→ Uzun sohbet geçmişleri pencereyi hızla doldurur
→ Bağlam dolduğunda, önceki talimatlar sessizce göz ardı edilir
→ Bağlama neyin girdiği bir varsayılan değil, bir mühendislik kararıdır
Bunu kanıtlayan başarısızlık:
Bir ekip, her talepte tam 12 aylık sohbet geçmişini bağlam olarak kullanan bir müşteri destek asistanı oluşturdu.
5 etkileşimle testte harika çalıştı.
Üretimde, 50 etkileşimden sonra asistan kendi sistem istemini görmezden gelmeye başladı.
Talimatlar hala oradaydı.
80.000 tokenlık konuşma geçmişinin altına gömülmüşlerdi.
Model onlara etkili bir şekilde dikkat etmeyi bırakmıştı.
Çözüm daha iyi bir model değildi.
Pencereyi odaklamak için eski geçmişi özetlemekti.
Rahatsız edici gerçek:
Çoğu "istem mühendisliği başarısızlığı" aslında gizlenmiş token ve bağlam penceresi başarısızlıklarıdır.
Mühendisler, asıl sorun kritik talimatın 500 satırlık bir bağlamın 3. satırında olması ve modelin ona ağırlık vermeyi bırakmasıyken, istemi suçlarlar.
2. Embedding'ler ve Vektör Arama
Embedding'ler anlamı sayılara dönüştürür, böylece "benzerlik" matematiksel olarak hesaplanabilir.
Çözdükleri sorun:
50.000 belgeniz var. Bir kullanıcı bir soru soruyor. Her seferinde 50.000 belgenin tamamını okumadan en alakalı 3 belgeye ihtiyacınız var.
Anahtar kelime araması burada başarısız olur.
Belge "otomobil" diyorsa ve kullanıcı "araba" hakkında soru soruyorsa, anahtar kelime araması bunu kaçırır.
Cevap orada olmadığı için değil. Kelimeler eşleşmediği için.
Embedding'ler bunu farklı şekilde çözer.
Bir embedding modeli, metni bir vektöre — matematiksel uzayda anlamı temsil eden bir sayı listesine — dönüştürür.
Anlamsal olarak benzer metin → sayısal olarak benzer vektörler.
"araba" ve "otomobil" → birbirine yakın
"araba" ve "fotosentez" → birbirinden uzak
Vektör aramanın gerçekte nasıl çalıştığı:
- Her belge bir vektöre dönüştürülür ve saklanır
- Kullanıcının sorusu da bir vektör haline gelir
- Sistem, soru vektörüne en yakın olan saklı vektörleri bulur
- Bunlar en alakalı belgelerinizdir
Bu yaklaşık bir sihir değil. Geometridir.
Benzerlik, hesaplayabileceğiniz gerçek bir matematiksel özelliktir.
Bunun üretimde ortaya çıktığı yerler:
→ Herhangi bir belge sisteminde anlamsal arama
→ Benzer ürünleri, makaleleri, kullanıcı profillerini bulma
→ RAG'daki getirme adımı (sonraki kavram)
→ AI ajanlarında bellek
3. RAG (Getirme ile Zenginleştirilmiş Oluşturma)
Bir modeli verilerinizle eğitmek yerine, sorgu anında alakalı verileri alır ve modeli bağlam olarak beslersiniz.
RAG'ın çözdüğü sorun:
LLM'ler çok şey bilir. Sizin verilerinizi bilmezler.
Şirketinizin iç dokümanları. Ürün veritabanınız. Müşteri destek geçmişiniz.
Bunların hiçbiri eğitim setinde yoktu.
İki seçenek: bir modeli verilerinizle eğitmek (pahalı, yavaş, anında bayatlar) veya modele tam ihtiyacı olduğu anda verilerinizi vermek.
RAG, sistematik olarak yapılan ikinci seçenektir.
3 adımlı işlem hattı:
→ GETİRME:
soru bir vektör haline gelir → vektör veritabanı en benzer saklı belgeleri bulur → ilk 3-5 parça alınır
→ ZENGİNLEŞTİRME:
alınan belgeler modelin bağlamına eklenir → istem "bu bağlamı kullanarak bu soruyu cevapla" haline gelir
→ OLUŞTURMA:
model, halüsinasyon değil, gerçek verilerinize dayalı olarak cevap üretir
RAG'ın bozulduğu yerler:
→ Kötü getirme = kötü cevap. Model yalnızca aldığıyla çalışabilir
→ Zayıf parçalama, cevabı bağlamından ayırır
→ Getirme işe yarar bir şey bulamazsa model yine de halüsinasyon görebilir
Gerçek bir RAG başarısızlığı:
Bir ekip, 500 sayfalık bir teknik kılavuz için dahili bir bilgi asistanı oluşturdu.
Demolarda mükemmel çalıştı. Üretimde cevaplar belirsizdi ve bazen yanlıştı.
Sorun: parça boyutu.
Kılavuzu ham karakter sayısına göre 1.000 tokenlık parçalara bölmüşlerdi.
Tablolar satır ortasında bölünmüştü. Adım adım talimatlar adım ortasında bölünmüştü.
Getirme doğru genel alanı buluyordu — ancak asıl cevabı kaçırıyordu.
Parça boyutunu yarıya indirmek ve bindirme eklemek, sorunların %80'ini bir gecede çözdü.
Sert görüş:
Getirmeniz kötü olduğunda RAG abartılır.
LLM kötü getirmeyi düzeltemez. Sadece etrafında halüsinasyon görebilir.
Yanlış cevaplar görüyorsanız, isteminizi ince ayar yapmayı bırakın.
Getirme hassasiyetinizi ölçmeye başlayın.
Cevap orada.
4. Ajan Döngüsü
Ajanlar, görev tamamlanana kadar tekrar tekrar bir eylem seçerek, onu yürüterek, sonucu gözlemleyerek ve ardından ne yapacağına karar vererek çalışır.
Normal bir LLM çağrısı durumsuzdur. Sorarsınız, cevaplar, biter.
Bir ajan durumludur. Harekete geçer, gözlemler, karar verir, tekrarlar.
Döngünün sade anlatımı:
- Bir hedef al
- Sonraki eyleme karar ver
- Onu yürüt — ara, kod yaz, bir dosya oku
- Sonucu gözlemle
- Öğrenilene göre sonraki eyleme karar ver
- Hedef tamamlanana kadar tekrarla
- Nihai cevabı döndür
Araçlar, ajanlara güçlerini veren şeydir.
Araçlar olmadan, bir LLM yalnızca metinle yanıt verir.
Araçlarla, web'de arama yapabilir, dosyaları okuyabilir, kod yazabilir, API'leri çağırabilir, tanımladığınız herhangi bir eylemi tetikleyebilir.
Yeni başlayanların her zaman yanlış yaptığı üç şey:
→ Durma koşulu olmayan ajanlar sonsuza kadar çalışır. Ne zaman duracağını tanımlamalısınız — adım sınırı, zaman sınırı veya hedef koşulu
→ Daha fazla araç ≠ daha iyi performans. Çok fazla araç, modelin hangisini kullanacağı konusunda kafasını karıştırır
→ Araç hatalarının açıkça ele alınması gerekir. Sessiz bir başarısızlık, ajanın kendinden emin bir şekilde çöp üretmesine neden olur
Bir gecede 200 dolarlık başarısızlık, detaylıca:
Ajanın maksimum adım sayısı yoktu. Hedefi: bir konuyu araştır ve bir özet çıkar.
Web arama araçlarından biri boş bir sonuç döndürdü.
Ajan nasıl duracağını bilmiyordu.
Aramaya, yeniden denemeye, ara özetler oluşturmaya devam etti — her biri başka bir aramayı tetikliyordu.
Altı saat sonra: 847 LLM çağrısı. 2,1 milyon token tüketildi. Mantıklı görünen ama tamamen döngüsel bir özet. 200 dolarlık bir fatura.
Çözüm üç satırdı: bir maksimum adım sayacı, boş sonuçlar için açık bir işleyici, güven düşük olduğunda bir yükseltme yolu.
Aynı ajan şimdi ortalama 12 çağrının altında tamamlanıyor.
Duymanız gereken görüş:
Çoğu ajan, model kötü olduğu için değil, mühendisler döngüyü kendi kendini yönetiyormuş gibi ele aldığı için başarısız olur.
Öyle değildir.
Korkuluklar, durma koşulları, hata işleyicileri — ilk olaydan sonra değil, en başından itibaren yerleşik olmalıdır.
5. Değerlendirmeler (Evals)
Değerlendirmeler, AI sisteminizin gerçekten çalışıp çalışmadığını ve bir değişikliğin onu iyileştirip iyileştirmediğini bilmenizi sağlayan yöntemdir.
Bu, gösterişsiz olduğu için çoğu eğitimin atladığı kavramdır.
Aynı zamanda demo yapan mühendislerle üretim sistemleri yapan mühendisleri ayıran şeydir.
Değerlendirmeler olmadan sorun:
İsteminizi değiştirirsiniz. Getirme mantığınızı güncellersiniz. Daha yeni bir modele geçersiniz.
Daha iyi oldu mu?
Bilmiyorsunuz. Birkaç örneği manuel olarak kontrol edebilirsiniz — ama bu bir kanıt değil, bir histir.
Değerlendirmeler gerçekte neye benzer:
→ Bir altın veri seti: Ana kullanım durumlarını ve bilinen 5 zor uç durumu kapsayan, bilinen doğru çıktılara sahip 25-50 gerçek girdi
→ Mümkün olduğunda ikili metrikler:
— RAG sistemi doğru belgeyi getirdi mi? Evet/Hayır
— Ajan hatasız tamamlandı mı? Evet/Hayır
— Yanıt gerekli bilgiyi içeriyor muydu? Evet/Hayır
→ Zaman içinde takip edilen toplam puanlar:
— Getirme doğruluğu: %89 → değişiklik yapıldı → %84. Gerileme bulundu.
— Görev tamamlama oranı: %76 → yeni ajan sürümü → %81. İyileşme doğrulandı.
Değerlendirme döngüsü:
Dağıt → Değerlendirmelerle ölç → Başarısızlıkları bul → Başarısızlıkları altın veri setine ekle → Düzelt → Değerlendirmeleri tekrar çalıştır → Puanları karşılaştır → Yalnızca sayılar iyileştiyse yayınla
Dürüst gerçek:
"Yardımseverlik: 3,7/5" size uygulanabilir hiçbir şey söylemez.
"Doğru belgeyi getirme: %84 oranında" size sorunun tam olarak nerede olduğunu ve bir düzeltmenin onu ne kadar iyileştirdiğini söyler.
Değerlendirmeleri olmayan bir AI sistemi bir ürün değildir.
Güvenle değiştiremeyeceğiniz bir demodur.
6. Bağlam Mühendisliği
Modelin bağlam penceresine tam olarak hangi bilgilerin girdiğine, nasıl yapılandırıldığına ve neyin dışarıda bırakıldığına karar verme disiplinidir.
İşte insanları rahatsız eden görüş:
Bağlam mühendisliği, istem mühendisliğinden daha önemlidir.
İyi hazırlanmış bir bağlamdaki vasat bir istem, gürültüye gömülmüş dahiyane bir istemi her seferinde geride bırakır.
Çoğu ekip, optimizasyon çabalarının %80'ini isteme harcar ve bağlama neredeyse hiç harcamaz.
Sonuçlar bunu yansıtır.
Saf yaklaşım başarısız olur:
Her şeyi dahil et. Tüm geçmiş. Tüm getirilen belgeler. Her araç açıklaması. Sistem istemi. Kullanıcı mesajı. Hepsini.
Bu, tutarlı bir nedenden dolayı başarısız olur: model en çok neyin önemli olduğu konusunda kafası karışır.
"Ortada kaybolma" adı verilen belgelenmiş bir etki vardır — uzun bir bağlamın derinliklerine gömülü bilgilerin kullanılma olasılığı daha düşüktür.
Bağlam mühendisliği gerçekte neyi içerir:
→ Seçim: Bu belirli karar için hangi belgelere, gerçeklere veya geçmişe ihtiyaç var?
→ Sıkıştırma: Token tasarrufu için konuşmanın eski kısımları özetlenebilir mi?
→ Sıralama: Kritik talimatlar ortada değil, başlangıçta ve sonda olmalıdır
→ Budama: Çıktı kalitesini etkilemeden ne kaldırılabilir?
→ Yapı: Başlıklar, ayırıcılar, etiketli bölümler modelin bilgiyi ne kadar güvenilir kullandığını etkiler
Pratik bir örnek:
Bir ajan 45 dakikadır çalışıyor. 80.000 tokenlık konuşma geçmişi biriktirdi. Penceresi 128.000.
Geçmiş pencereyi doldururken bile orijinal hedefi ve kısıtlamaları kaybetmek istemezsiniz.
Bağlam mühendisliği: eski araç çıktılarını sıkıştır, önceki akıl yürütmeyi özetle, görev tanımını oturum boyunca belirgin tut.
İstem mühendisliği iyi talimatlar yazmaktır.
Bağlam mühendisliği, bu talimatların gerçekten takip edildiği ortamı oluşturmaktır.
Bu 6 kavram tek bir sistemi nasıl oluşturur
BELLEK → RAG + Embedding'ler (sistemin bildikleri)
DÜŞÜNME → LLM + Tokenlar + Bağlam Penceresi (bildikleriyle nasıl akıl yürüttüğü)
EYLEMLER → Ajan Döngüsü + Araçlar (dünyada neler yapabileceği)
ÖLÇÜM → Değerlendirmeler (çalıştığını nasıl bildiğiniz)
TUTKAL → Bağlam Mühendisliği (yukarıdakilerin tümü arasında neyin akacağına karar veren)
Basit bir sohbet robotu yalnızca Düşünme'dir.
Bir müşteri destek asistanı Bellek + Düşünme + Eylemler'dir.
Güvenilir bir üretim sistemi Ölçüm ekler.
Ustalık, parçaların ne kadar iyi bağlandığındadır.
Herhangi bir talep için akış:
Kullanıcı sorusu
→ Bağlam Mühendisliği neyin dahil edileceğine karar verir
→ Embedding'ler alakalı Belleği getirir (RAG)
→ Tokenlar pencereye ne kadar sığacağını belirler
→ LLM birleştirilmiş bağlam üzerinde akıl yürütür
→ Ajan Döngüsü daha fazla bilgi gerekip gerekmediğine karar verir
→ Değerlendirmeler çıktının gerçekten doğru olup olmadığını ölçer
Nereden başlamalı
Altısında da aynı anda uzmanlaşmanız gerekmez.
→ Tokenlar ve bağlam pencereleriyle başlayın — inşa ettiğiniz her şeyi etkilerler → Anlamsal arama veya belleğe ihtiyacınız olduğunda embedding'leri ekleyin
→ Bir modeli kendi verilerinizde temellendirmeniz gerektiğinde RAG'ı öğrenin
→ Otomasyona ihtiyacınız olduğunda ajan döngüsünü öğrenin
→ Bir şeyi üretime göndermeden önce değerlendirmeleri ekleyin
→ Diğer her şey sezgisel hale geldikçe bağlam mühendisliğini uygulayın
Bu sıra keyfi değildir.
Her kavram, bir sonrakini öğrenilebilir kılar.
Dürüst son söz
Üretimde AI ile mücadele eden çoğu ekip, yanlış model veya yanlış kütüphane ile mücadele etmiyor.
Bu altı kavramdan birini atladıkları için mücadele ediyorlar.
Ajan sonsuza kadar döngü yapıyor çünkü kimse durma koşullarını düşünmedi.
RAG cevapları yanlış çünkü kimse getirmeyi ölçmedi.
İstem uzun oturumlarda çalışmayı bırakıyor çünkü kimse bağlam penceresinin nasıl dolduğunu anlamadı.
Bunlar karmaşık sorunlar değil.
Teknik kelimelerle süslenmiş temel sorunlar.
Araçlar her altı ayda bir değişiyor.
Bu altı kavram, araçların nasıl çalıştığıdır.
Kavramları öğrenin ve asla yeni bir araç karşısında kafanız karışmasın.
Daha da önemlisi — bir ajanın gece boyunca döngü yapmasını izleyip neyin yanlış gittiğini merak ederek asla 200 dolar harcamayacaksınız.
Bu faydalıysa:
→ Tanıdığınız her AI mühendisiyle paylaşmak için tekrar paylaşın
→ Daha fazla sistem ve analiz için @sairahul1'i takip edin
→ Bunu yer imlerine ekleyin — üretimde bir şey bozulduğunda bir sonraki sefer başvuracaksınız
AI, ürün oluşturma ve siz uyurken çalışan sistemler hakkında yazıyorum.
