Geçtiğimiz 6 ay boyunca, farklı iş yükleri için tasarladığım AI agent’larını otonom bir şekilde çalıştırdım. Bu deneyim, beklentilerimi büyük ölçüde şekillendirdi ve AI agent’larının mevcut yetenekleri ile gelecekteki potansiyelleri hakkında bana çok net bir tablo sundu. İlk başta büyük bir heyecanla başladığım bu yolculuk, beni hem şaşırttı hem de bazı gerçeklerle yüzleştirdi.
Bu yazıda, kendi deneyimimden yola çıkarak AI agent’larının kurulumundan optimizasyonuna, karşılaştığım teknik zorluklardan maliyet analizine kadar her şeyi olabildiğince şeffaf bir şekilde anlatacağım. Amacım, bu alana ilgi duyan veya kendi agent’larını geliştirmeyi düşünen herkese, sahadan gelen dürüst bir rapor sunmak.
AI Agent Kavramına İlk Yaklaşımım Ne Oldu?
AI agent’lar, temel olarak belirli bir amacı gerçekleştirmek üzere tasarlanmış, otonom karar verme ve eylem yapma yeteneğine sahip yazılım varlıkları olarak tanımlanabilir. Benim ilk ilgim, bu agent’ların tekrar eden, kural tabanlı ama aynı zamanda esneklik gerektiren iş süreçlerinde ne kadar verimli olabileceği üzerineydi. Özellikle bir üretim ERP’sinde veya kendi yan ürünümün back-end süreçlerinde, insan müdahalesi olmadan otomatikleşebilecek alanları hep merak etmişimdir.
Genel kanı, AI agent’ların sadece basit script’lerden ibaret olmadığı, aksine dinamik planlama, araç kullanımı ve geri bildirim döngüleri ile karmaşık görevleri yerine getirebildiği yönündeydi. Teorik olarak bu kulağa harika gelse de, gerçek dünyadaki uygulama alanlarını ve limitasyonlarını görmek istedim. Bu yüzden, sadece bir prompt’a dayalı tek seferlik bir cevap üretmek yerine, kendi başına bir dizi adımı izleyebilecek ve gerektiğinde kendini düzeltebilecek yapılar kurmayı hedefledim.
Hangi İş Yükleri İçin AI Agent’ları Denemeye Karar Verdim?
Deneme sürecimde birkaç farklı iş yükü belirledim. Bunların başında, kendi bilingual teknik blog’um için içerik fikirleri üretme ve taslak metinler hazırlama geliyordu. Bu, nispeten düşük riskli ama yüksek tekrar potansiyeli olan bir alandı. İkinci olarak, bir üretim ERP’sinde karşılaştığımız, tedarik zinciri verilerini analiz edip potansiyel aksaklıkları erken tespit etme ve raporlama işini otomatize etmeye çalıştım. Bu daha kritik ve karmaşık bir görevdi.
Üçüncü bir deneme alanı ise, Android spam blocker uygulamam için yeni spam paternleri analiz edip kural önerileri oluşturmaktı. Bu görev, sürekli değişen veri setleriyle çalışmayı gerektiriyor ve hızlı adaptasyon yeteneği bekliyordu. Son olarak, kendi VPS’imde koşan bir dizi sistem izleme ve log analizi görevi vardı; anormallikleri tespit edip bana özet geçmesi bekleniyordu. Her bir görev, agent’ın farklı yeteneklerini test etmek üzere seçilmişti.
Agent Mimarisi Nasıl Kuruldu ve Neler Kullandım?
Agent mimarimi olabildiğince esnek tutmaya çalıştım. Temelde bir Controller agent’ı, görevleri parçalayan bir Planner agent’ı ve her bir alt görevi yerine getiren Executor agent’larından oluşan bir yapı kurdum. Aralarındaki iletişimi RabbitMQ benzeri bir mesaj kuyruğu üzerinden sağladım. LLM olarak başlangıçta Gemini Flash ve Groq API’lerini kullandım, daha sonra OpenRouter ile Cerebras gibi farklı sağlayıcıları da devreye alarak fallback mekanizmaları oluşturdum. Özellikle Groq, düşük gecikmesi sayesinde Executor agent’ları için biçilmiş kaftandı.
Prompt Engineering tarafında ise, her agent için ayrı bir “system prompt” ve araç tanımlamaları kullandım. RAG (Retrieval-Augmented Generation) desenini, özellikle ERP verileri ve kendi teknik blog’umun geçmiş içerikleri için uyguladım. PostgreSQL’de pg_vector uzantısını kullanarak vektör aramaları yaptım. Aşağıda basitleştirilmiş bir akış diyagramını görebilirsiniz:
graph TD;
A["Kullanıcı/Tetleyici"] --> B["Controller Agent"];
B --> C{"Görevi Parçala"};
C --> D["Planner Agent"];
D --> E["Görev Kuyruğu (RabbitMQ)"];
E --> F["Executor Agent (LLM: Groq)"];
E --> G["Executor Agent (LLM: Gemini Flash)"];
F --> H["Araçlar (API, DB, Web Scraper)"];
G --> H;
H --> I["Sonuç / Geri Bildirim"];
I --> B;
style A fill:#f9f,stroke:#333,stroke-width:2px;
style B fill:#bbf,stroke:#333,stroke-width:2px;
style D fill:#bbf,stroke:#333,stroke-width:2px;
style F fill:#bbf,stroke:#333,stroke-width:2px;
style G fill:#bbf,stroke:#333,stroke-width:2px;
style H fill:#ccf,stroke:#333,stroke-width:2px;
style I fill:#f9f,stroke:#333,stroke-width:2px;
Bu yapı, bir agent’ın başarısız olması durumunda diğerine geçiş yapma esnekliği sunuyordu. Örneğin, Groq’un token limitine takıldığımda otomatik olarak Gemini Flash’e yöneliyordum. Bu çoklu sağlayıcı fallback stratejisi, özellikle ilk aylarda agent’ların kesintisiz çalışmasında kritik rol oynadı. Kendi yan ürünüm için kurduğum bu sistemin Python kod yapısı aşağıdaki gibiydi:
# executor_agent.py
import os
from openai import OpenAI # OpenRouter uyumlu
from google.generativeai import GenerativeModel # Gemini
class ExecutorAgent:
def __init__(self, llm_provider="groq"):
self.llm_provider = llm_provider
self.client = self._init_client()
def _init_client(self):
if self.llm_provider == "groq":
return OpenAI(api_key=os.getenv("GROQ_API_KEY"), base_url="https://api.groq.com/openai/v1")
elif self.llm_provider == "gemini":
return GenerativeModel(os.getenv("GEMINI_API_KEY"))
elif self.llm_provider == "openrouter":
return OpenAI(api_key=os.getenv("OPENROUTER_API_KEY"), base_url="https://openrouter.ai/api/v1")
else:
raise ValueError("Unsupported LLM provider")
def execute_task(self, prompt, tools=None):
messages = [{"role": "user", "content": prompt}]
try:
if self.llm_provider == "gemini":
# Gemini API'si farklı çalıştığı için özel handling
response = self.client.generate_content(prompt)
return response.text
else:
response = self.client.chat.completions.create(
model="llama3-8b-8192" if self.llm_provider == "groq" else "mistralai/mistral-7b-instruct:free",
messages=messages,
tools=[t.schema for t in tools] if tools else None,
tool_choice="auto" if tools else "none"
)
if response.choices[0].message.tool_calls:
# Tool call logic
return {"tool_calls": response.choices[0].message.tool_calls}
return response.choices[0].message.content
except Exception as e:
print(f"Error executing task with {self.llm_provider}: {e}")
raise
# Controller agent'ı bu ExecutorAgent'ı kullanarak farklı sağlayıcılar arasında geçiş yapıyordu.İlk 3 Ay: Başarılar ve Hayal Kırıklıkları Nelerdi?
İlk üç ay, özellikle blog içeriği üretme ve spam patern analizi gibi nispeten daha esnek görevlerde gözle görülür başarılar elde ettim. Blog için haftalık 3-4 taslak metin üretimi %70 oranında kabul edilebilir kalitedeydi, yani sadece küçük düzeltmelerle yayına hazır hale gelebiliyordu. Bu, içerik üretim sürecimi ciddi şekilde hızlandırdı ve insan yazarın üzerindeki yükü azalttı. Benzer şekilde, Android spam blocker için önerilen kuralların %85’i doğru tespitler içeriyordu ve manuel analiz süresini ortalama 2 saatten 30 dakikaya indirdi.
Ancak, üretim ERP’sindeki tedarik zinciri analizi görevinde beklediğim performansı yakalayamadım. Agent, karmaşık iş kurallarını ve istisnaları anlamakta zorlandı. Örneğin, “eğer bir hammadde X’in stoğu kritik seviyenin altına düşerse ve tedarikçi Y’nin teslimat süresi Z günden fazlaysa, alternatif tedarikçileri araştır” gibi çok katmanlı bir kuralı sürekli olarak yanlış yorumladı. Başlangıçta %60 doğrulukla raporlama yaparken, bu oran manuel kontrolle %35’e kadar düşüyordu. Özellikle “fuzzy logic” içeren durumlarda agent’ın deterministic olmayan yapısı, güvenilirliği ciddi şekilde etkiledi.
Ayrıca, agent’ların “halüsinasyon” eğilimi, özellikle kritik veri analizi görevlerinde başıma bela oldu. Bir keresinde, ERP sisteminden gelmeyen, tamamen uydurma bir tedarikçi adı ve teslimat tarihiyle ilgili bir “risk raporu” üretti. Bu, manuel kontrol mekanizmalarımın ne kadar önemli olduğunu bir kez daha gösterdi. Güvenilir bir çıktı elde etmek için, agent’ın her adımda kullandığı verileri ve vardığı sonuçları doğrulamak gerekti. Bu da otonomi hedeflerime ciddi bir darbe vurdu.
Sonraki 3 Ay: Optimizasyonlar ve Derinlemesine Öğrenilen Dersler Nelerdi?
İlk üç aydaki tecrübelerimden sonra, özellikle ERP ve sistem izleme agent’larım için ciddi optimizasyonlara gittim. En büyük ders, agent’lara daha fazla “grounding” sağlamaktı. RAG sistemini güçlendirerek, agent’ın sadece genel LLM bilgisini değil, aynı zamanda güncel ve doğrulanmış şirket içi belgeleri, iş akış şemalarını ve kural setlerini de kullanmasını sağladım. PostgreSQL’deki pg_vector index’lerini optimize ederek (örneğin IVFFlat yerine HNSW kullanarak), vektör arama performansını %30 artırdım ve agent’ın daha alakalı bağlam çekmesini sağladım.
Prompt Engineering tarafında ise, her adım için daha spesifik talimatlar ve “thought process” yönergeleri ekledim. Agent’tan sadece cevabı değil, aynı zamanda cevaba nasıl ulaştığını, hangi araçları kullandığını ve hangi bilgileri referans aldığını da açıklamasını istedim. Bu, debugging sürecini çok kolaylaştırdı. Örneğin, ERP agent’ının bir görevi yerine getirmeden önce izlemesi gereken adımlar şöyle tanımlandı:
# ERP Tedarik Zinciri Analiz Agent'ı - Görev Adımları
1. Gelen talebi analiz et ve gerekli parametreleri çıkar (ürün kodu, tarih aralığı, kritik stok seviyesi).
2. Veritabanından (PostgreSQL) ilgili ürünlerin stok, sipariş ve sevkiyat verilerini çek. SQL sorgusunu açıkça belirt.
3. Çekilen verilerde kritik stok seviyesinin altına düşen ürünleri tespit et.
4. Bu ürünler için mevcut tedarikçilerin geçmiş teslimat sürelerini ve ortalama gecikme oranlarını sorgula.
5. Eğer bir tedarikçi için gecikme riski yüksekse (örneğin, son 3 teslimatın 2'sinde 5 günden fazla gecikme varsa), alternatif tedarikçilerin listesini ve onların ortalama teslimat sürelerini bul.
6. Tüm bu bilgileri özetle ve "Risk Raporu" formatında sun. Raporda, riskli ürün, mevcut tedarikçi, risk nedeni, önerilen alternatifler ve tahmini etki (örneğin, üretim kaybı) yer almalı.
7. Raporu oluşturduktan sonra, tüm adımları ve nedenlerini adım adım açıkla.Bu detaylı prompt’lar sayesinde ERP agent’ının doğruluk oranı %35’ten %70’e çıktı. Hala mükemmel değildi, ama en azından uydurma bilgi üretme sıklığı önemli ölçüde azaldı. Ayrıca, “Human-in-the-loop” mekanizmalarını daha entegre hale getirdim. Kritik kararlar öncesinde veya belirli bir güven eşiğinin altında kalan raporlarda, bir Slack bildirimi göndererek manuel onayı zorunlu kıldım. Bu, özellikle finansal hesaplayıcılar ve müşteri projeleri gibi hassas alanlarda agent’ların güvenle kullanılabilmesini sağladı.
AI Agent’ların Gerçek Maliyeti ve ROI Hesaplamam Ne Oldu?
AI agent’larını 6 ay boyunca çalıştırmanın maliyeti, düşündüğümden daha karmaşık ve sadece API ücretlerinden ibaret değildi. En büyük kalemler:
- LLM API Ücretleri: Ortalama olarak aylık 150-250 USD civarında bir maliyet oluştu. Groq, yüksek performansına rağmen token başına maliyeti düşük olduğu için burada avantajlıydı. Ancak, daha karmaşık görevler için Gemini veya GPT-4 gibi modelleri kullandığımda bu maliyet hızla artabiliyordu. Özellikle RAG için yapılan embeddings ve vektör aramaları da küçük ama sürekli bir maliyet oluşturdu.
- Altyapı Maliyetleri: Kendi VPS’imde (DigitalOcean) koşan agent’lar, RabbitMQ, PostgreSQL ve RAG vektör veritabanı için aylık ortalama 80 USD ek maliyet getirdi. Özellikle yoğun işlem gerektiren RAG sorguları ve paralel agent çalıştırmaları, CPU ve RAM kullanımını artırdı.
- Geliştirme ve Bakım Süresi: En önemli ama gözden kaçan maliyet kalemi buydu. İlk kurulum ve prompt engineering için yaklaşık 1.5 ay tam zamanlı mesai harcadım. Sonraki 5 ay boyunca da haftalık ortalama 10-15 saatimi agent’ları optimize etmeye, hataları gidermeye ve yeni araçlar entegre etmeye ayırdım. Bu, bir geliştiricinin aylık maaşının önemli bir kısmına denk geliyor. Örneğin, bir üretim ERP’sinde N+1 sorgu problemi yaşadığımda, önce agent’ın loglarını inceleyip sonra veritabanı tarafında
EXPLAIN ANALYZEile sorgu planını incelemek, agent’ın yaptığı hatayı anlamak için ciddi zamanımı aldı.
ROI (Return on Investment) hesaplamama gelince: blog içerik üretimi ve spam patern analizi gibi nispeten basit görevlerde, agent’lar gerçekten de insan iş gücünden tasarruf sağladı. Blog için haftalık 3-4 taslak metin üretimi, bir içerik yazarının haftalık 5-6 saatlik işini karşıladı. Bu da aylık yaklaşık 20-24 saatlik bir tasarruf demekti. Spam analizi tarafında ise aylık 50 saatlik manuel analizi 10 saate düşürdü. Bu iki alandaki toplam tasarruf, LLM ve altyapı maliyetini fazlasıyla karşılıyordu.
Ancak, ERP’deki tedarik zinciri analizi gibi karmaşık görevlerde ROI negatif çıktı. Agent’ın ürettiği raporların düşük güvenilirliği nedeniyle, her raporun manuel olarak kontrol edilmesi ve düzeltilmesi gerekiyordu. Bu da agent’ın “otomasyon” vaadini boşa çıkardı ve hatta bazen manuel sürece kıyasla daha fazla zaman harcamama neden oldu. Burada, agent’ın hata maliyeti (yanlış rapor nedeniyle alınacak yanlış bir karar) de göz önünde bulundurulmalıydı.
Gelecekte AI Agent’lara Yaklaşımım Nasıl Olacak?
6 aylık bu yoğun deneyimden sonra AI agent’lara bakış açım çok daha gerçekçi bir hal aldı. Artık agent’ları bir “görev avcısı” olarak değil, daha çok “akıllı asistanlar” veya “veri toplayıcılar” olarak görüyorum. Tam otonomi, özellikle karmaşık ve yüksek riskli işlerde, henüz hayalden öteye geçemiyor. Agent’ların en büyük gücü, insan müdahalesiyle birlikte çalıştığında ortaya çıkıyor.
Gelecekte agent’ları daha çok şu alanlarda kullanmayı hedefliyorum:
- Veri Ön İşleme ve Özetleme: Büyük veri setlerini (örn. loglar, finansal kayıtlar) hızlıca tarayıp anlamlı özetler çıkarmak. Özellikle
journaldloglarındaki anormallikleri tespit edip bana konsolide bir rapor sunması, sistem yönetimi tarafında büyük kolaylık sağlayabilir. - Bilgi Arama ve Sentezleme: RAG mimarisini daha da geliştirerek, şirket içi bilgi tabanından (Wiki, dökümanlar, geçmiş e-postalar) alakalı bilgileri çekip belirli bir soruya yanıt vermek üzere sentezlemek. Bu, yeni bir çalışanın oryantasyon sürecini hızlandırabilir veya teknik destek ekibinin sorun çözme süresini kısaltabilir.
- Otomatik Test Senaryosu Üretimi: Yazılım geliştirme süreçlerinde, belirli bir özellik için test senaryoları ve hatta basit unit test kodları üretmek. Bu, CI/CD pipeline’ımın reliability’sini artırabilir. Bir müşteri projesinde, yeni bir API endpoint’i eklendiğinde agent’ın otomatik olarak test case’leri oluşturduğunu görmek isterim.
- Basit Form Doldurma veya Veri Girişi: Özellikle web arayüzleri üzerinden yapılan tekrar eden, kural tabanlı veri giriş görevleri.
Sonuç olarak, AI agent’lar hala emekleme aşamasında. Çok hızlı ilerliyorlar, evet, ancak benim 20 yıllık tecrübem, bir teknolojinin potansiyelini değerlendirirken her zaman gerçek dünya uygulamalarına odaklanmam gerektiğini öğretti. Abartılı vaatler yerine, neyi gerçekten iyi yaptıklarını ve nerede insan müdahalesinin vazgeçilmez olduğunu anlamak, bu teknolojiden en iyi şekilde faydalanmanın anahtarı. Eğer bir gün bana “Bu agent’lar üretimde %99.99 güvenle çalışır mı?” diye sorarsanız, cevabım muhtemelen “Hayır, henüz değil,” olacaktır. Ama “İşimi %30 daha verimli hale getirir mi?” sorusuna kesinlikle “Evet!” diyebilirim.