Yapay zeka ajanları için self-hosted değerlendirme rehberi

Yapay zeka ajanları için self-hosted değerlendirmeler nelerdir

Yapay zeka ajanları için self-hosted değerlendirmeler, kendi deponuzda tuttuğunuz dört unsurdan oluşur: kaydedilmiş vaka dosyaları, ajanı bu vakalar üzerinde çalıştıran bir betik, her yanıtı puanlayan bir dizi kontrol ve sorgulayabileceğiniz bir sonuç tablosu. Bu listedeki hiçbir şey bir tedarikçiye ihtiyaç duymaz. Tüm döngü, birkaç yüz satırlık Python kodu ve bir adet SQLite dosyasından ibarettir.

Ajan demoda çalıştı çünkü beş girdiyi bizzat siz seçtiniz. İkinci haftada bozuldu çünkü bir istem satırı, bir model veya bir araç açıklaması değişti ve hiçbir ölçüm bunu kapsamadı. Bir değerlendirme döngüsü, "artık daha kötü hissettiriyor" durumunu, "4f1c9ab commit'inde başarı oranı 60'ta 58'den 60'ta 51'e düştü" şeklinde somut bir veriye dönüştürür.

Döngü dört adımdan oluşur ve bu kılavuz her adım için bir bölüm içerir: gerçek izleri (traces) toplamak, ilginç olanları vaka haline getirmek, her değişiklikte her vakayı puanlamak ve başarı oranını onu üreten commit'in yanında saklamak. Aynı döngü, ajanı ne üzerinde çalıştırırsanız çalıştırın işler ve çalıştırmaya değer self-hosted ajan çerçeveleri, büyük ölçüde size ücretsiz olarak sundukları iz verisi miktarı bakımından farklılık gösterir.

Ajan neden ikinci haftada bozulur

Bir ajan; bir istem, bir model, bir dizi araç tanımı ve çalışma zamanında getirilen her türlü bağlamdan oluşur. Bu dört unsur, uygulama kodunuz değişmeden de değişebilir; bu nedenle standart bir kod incelemesi, itiraz edilecek bir durum görmez.

En yaygın neden, istem üzerinde yapılan bir düzenlemedir. Kaba bir yanıtı engellemek için bir cümle eklersiniz. Bu cümle, kimsenin yeniden test etmediği girdilerdeki davranışı değiştirir ve izleme kayıtları bunu açıkça gösterir: aynı soru için geçen haftaki izleme kaydı bir create_refund araç çağrısı içerirken, bu haftaki hiçbir şey içermez ve yanıt bunun yerine nazik bir özürden ibarettir. Hiçbir hata oluşmadığı için herhangi bir uyarı tetiklenmez.

İkinci neden modeldir. Her çalıştırmada gönderdiğiniz tam model dizgisini kaydedin; aklınızda tuttuğunuz bir kısaltma yerine claude-haiku-4-5-20251001 kullanın. Çünkü model değiştirdiğiniz gün düşen bir başarı oranı, ancak model bilgisi satırda kayıtlı olduğunda teşhis edilebilir.

Üçüncüsü araçlardır. Bir araç açıklamasının yeniden ifade edilmesi, modelin onu ne zaman çağıracağına karar verme sürecini değiştirir. Araçlarınız bir VPS üzerinde çalışan MCP sunucuları aracılığıyla geliyorsa, şema başka bir süreçte yaşar; dolayısıyla deponuzda hiçbir fark (diff) oluşmadan sizin bilginiz dışında değişebilir. Dördüncüsü ise veri getirme (retrieval) sürecidir: aynı soru, gece yeniden oluşturulan bir dizine ulaşır ve yanıt, yeni belgeyi takip eder.

Hali hazırda topladığınız izlerden altın seti oluşturun

Değerlendirme senaryoları uydurmayın. Bunları trafikten alın. Eğer halihazırda ajanınız için self-hosted Langfuse izleme kullanıyorsanız, her istek girdisi, araç çağrıları ve çıktısıyla birlikte saklanır; bu da bir senaryonun ihtiyaç duyduğu ham verinin ta kendisidir.

Halka açık API üzerinden bir kök gözlem penceresini dışa aktarın. Bu işlem, kullanıcı adı olarak genel anahtarınızı, parola olarak ise gizli anahtarınızı kullandığınız temel kimlik doğrulama (basic authentication) ile çalışır.

export LF_HOST="https://langfuse.example.com"
curl -sS -u "$LF_PUBLIC_KEY:$LF_SECRET_KEY" \
  "$LF_HOST/api/public/v2/observations?limit=50&isRootObservation=true&fromStartTime=2026-07-01T00:00:00Z" \
  | jq '.data[0]'

Herhangi bir ayrıştırma işlemi yazmadan önce bir kaydı okuyun. Satırlar data altında döner, ancak soruyu ve yanıtı tutan alan adları ajanınızın span'leri nasıl enstrümante ettiğine bağlıdır; bu nedenle beklediğiniz şeye göre değil, gerçekte gördüğünüz şeye göre eşleme yapın. Ardından senaryoları, satır başına bir JSON nesnesi olacak şekilde evals/cases.jsonl formatında elle yazın:

{"id": "refund-double-charge", "tags": ["smoke"], "input": "I was charged twice for order 41822.", "must_call": ["lookup_order", "create_refund"], "must_not_include": ["I cannot help"], "rubric": "The reply confirms exactly one refund for order 41822 and states the amount."}

Setin çalıştırılmaya değer kalmasını sağlayan beş kural:

• Başlangıç için 40 ila 80 senaryo yeterlidir. 20'nin altında, kararsız tek bir senaryo başarı oranını 5 puan değiştirir ve sebepsiz yere zıplayan bir sayı görmezden gelinir.
• Düzelttiğiniz her üretim hatası, düzelttiğiniz gün bir senaryoya dönüşür. Setin doğru yönde büyümesini sağlayan alışkanlık budur.
• Her senaryoda tek bir davranış. İade tutarını ve üslubu aynı anda kontrol eden bir senaryo, başarısız olduğunda size hiçbir şey anlatmaz.
• id asla değişmez, çünkü kimlik (id) bugünkü çalışmanın geçen ayki çalışmayla nasıl karşılaştırılacağını belirler.
• Commit etmeden önce verileri gizleyin (redact). Bu dosya git içine gireceği için müşteri isimlerini ve size ait olmayan sipariş numaralarını temizleyin.

Belirleyici denetimleri önce uygulayın, çünkü bunlar ücretsizdir

Doğru cevabı olan her şey için basit bir doğrulama (assertion) kullanılır. Model çağrısı, maliyet veya belirsizlik yoktur. Belirleyici denetimler yapısal gerilemeleri yakalar; bunlar, aracınızın etrafındaki sistemleri bozan hatalardır: JSON ayrıştırılamıyor, araç hiç çağrılmadı, yasaklı ifade geri döndü veya cevap hiçbir kaynak göstermiyor.

Sadece bir fonksiyon aracınız hakkında bilgi sahibidir. Test düzeneğindeki diğer her şey genel amaçlıdır.

import json, os, urllib.request

def run_agent(case):
    req = urllib.request.Request(
        os.environ["AGENT_URL"],
        data=json.dumps({"input": case["input"]}).encode(),
        headers={"content-type": "application/json"},
    )
    with urllib.request.urlopen(req, timeout=120) as resp:
        return json.load(resp)


def deterministic(case, result):
    text = result.get("output", "")
    called = [c["name"] for c in result.get("tool_calls", [])]
    failures = []
    for tool in case.get("must_call", []):
        if tool not in called:
            failures.append(f"tool not called: {tool}")
    for phrase in case.get("must_not_include", []):
        if phrase.lower() in text.lower():
            failures.append(f"forbidden phrase: {phrase}")
    if len(called) > case.get("max_tool_calls", 12):
        failures.append(f"too many tool calls: {len(called)}")
    return failures

Araç bütçesini bu listede tutun. Bugün bir vakayı 3 çağrıda, yarın 11 çağrıda çözen bir araç, nihai cevap doğru olsa bile gerilemiş demektir; çünkü yapılan her çağrı için ödeme yaparsınız.

Yargıç olarak LLM ve hatalı çalıştığı dört durum

İddiaları karşılayan her çıktı, okuma yapabilen bir değerlendiriciye ihtiyaç duyar. Yargıç olarak kullanılan bir LLM, ikinci bir model çağrısıdır: soru, temsilcinin yanıtı ve bir kriteri alır, ardından bir hüküm döndürür. "Yanıt, kullanıcının sorduğu soruyu karşılıyor mu" sorusunu puanlamanın tek pratik yolu budur.

Bir yargıcı kullanılabilir kılan dört kural vardır:

• İkili hüküm verin, asla 1'den 10'a kadar puanlama yapmayın. Ölçekli puanlama neredeyse her şeye 7 veya 8 verir; bu nedenle sayı asla değişmez ve sonuçtan hiçbir şey öğrenemezsiniz.
• Çağrı başına tek bir kriter belirleyin. İade tutarını veya üslubu sorun, ikisini aynı anda sormayın.
• Bir durumun beklenen bir yanıtı varsa, bunu yargıca verin. Referansa göre puanlama yapmak, soyut bir şekilde puanlama yapmaktan çok daha kolaydır.
• Çıktı biçimini zorunlu tutun ve katı bir şekilde ayrıştırın.

from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment


def judge_prompt(case, output):
    return (
        "You grade one answer against one criterion.\n"
        "Reply with JSON only, in this exact shape:\n"
        '{"verdict": "pass", "confidence": "high", "reason": "one short sentence"}\n'
        f"Criterion: {case['rubric']}\n"
        f"Question: {case['input']}\n"
        f"Answer: {output}\n"
        "Length is not a criterion. Judge only the criterion above."
    )


def judge(case, output, model):
    msg = client.messages.create(
        model=model,
        max_tokens=200,
        messages=[{"role": "user", "content": judge_prompt(case, output)}],
    )
    return json.loads(msg.content[0].text)

Şimdi başarısızlık modlarına bakalım. Her birinin bu öğleden sonra çalıştırabileceğiniz bir testi vardır. Bunları çalıştırmak önemlidir, çünkü denetlenmeyen bir yargıç, kesin görünen ancak hiçbir anlam ifade etmeyen sayılar üretir.

Uzunluk yanlılığı. Daha uzun yanıtlar daha sık geçer. Bunu test edin: yargıcın başarısız olduğu on yanıt alın, her birini yeni bir bilgi eklemeyen iki paragraf dolgu metinle genişletin ve tekrar yargılayın. Geçer notuna dönen her hüküm, uzunluk yanlılığıdır; düzeltilmesi gereken şey yönergedir.

Öz tercih. Bir yargıç, genellikle kendi model ailesinden gelen çıktıları diğerlerinden daha hoşgörüyle puanlar. Bunu test edin: aynı 30 yanıtı iki farklı aileden gelen yargıçlarla puanlayın ve hükümleri vaka bazında karşılaştırın. Anlaşamadıkları durumlarda vakayı kendiniz okuyun.

Konum yanlılığı. Bir yargıcı iki yanıtı (A ve B) karşılaştırmak için kullanıyorsanız, sırayı değiştirin ve tekrar çalıştırın. Sıra değiştiğinde değişen bir hüküm, ikili karşılaştırmanın o yönerge için henüz güvenli olmadığı anlamına gelir.

Yönerge kayması. Belirsiz kriterler, uyumlu yargıçlar üretir. "Yanıt yardımcı mı" kriteri neredeyse her şeyi geçirir. "Yanıt, iade tutarını dolar cinsinden belirtiyor mu" kriteri ise sadece kastettiğiniz şeyi geçirir. Her kriteri, kontrol edilen gerçeği isimlendirene kadar yeniden yazın.

Tek bir önlem bu dört sorunu da kapsar. Elle etiketlediğiniz 30 vakayı saklayın ve yargıç modelini veya yargıç istemini her değiştirdiğinizde, yargıcı kendi etiketlerinize göre puanlayın. On vakadan birinden fazlasında sizinle fikir ayrılığına düşüyorsa, ürettiği geçme oranına güvenmeden önce yönergeyi düzeltin. Yargıç bir koddur; bu nedenle kod gibi sürümlenmeli ve gözden geçirilmelidir.

Ucuz modellerle değerlendirme yapın, sınır modellerine kademeli geçin

Her commit işleminde her durumu en pahalı modelle değerlendirmek, değerlendirme maliyetinin test edilen ajanın maliyetini aşmasına neden olur. Değerlendiricileri fiyata göre sıralayın ve yanıt netleştiği anda durun.

[
  {
    "label": "Haiku 4.5, Batch API",
    "usd_per_1000_judge_calls": "0.90"
  },
  {
    "label": "Haiku 4.5",
    "usd_per_1000_judge_calls": "1.80"
  },
  {
    "label": "Sonnet 5",
    "usd_per_1000_judge_calls": "3.60"
  },
  {
    "label": "Opus 5",
    "usd_per_1000_judge_calls": "9.00"
  }
]

Bu rakamlar, bir soru, bir yanıt ve bir kriter için gerçekçi bir boyut olan yaklaşık 1.200 girdi token'ı ve 120 çıktı token'ı üzerinden hesaplanmıştır. 1.000 durumu değerlendirmenin maliyeti Claude Haiku 4.5 üzerinde 1.80 ABD doları, Claude Opus 5 üzerinde ise 9.00 ABD dolarıdır. Bu fark, çarpanlarla hesaplanana kadar önemsiz görünebilir. Haftada 40 commit yapılan ve her commit'te 60 durumun değerlendirildiği bir senaryoda, gece işleri (nightly jobs) çalıştırılmadan önce haftalık 2.400 değerlendirme çağrısı gerçekleşir.

Değerlendirme süreçlerine iki indirim uygulanabilir ve bunlar birleştirilebilir. Değerlendirme süreçleri etkileşimli değildir; bu nedenle Batch API, asenkron teslimat karşılığında hem girdi hem de çıktı fiyatlarını yarıya indirir; bu, tablonun ilk satırında yer alır. Rubrik ve talimatlar her çağrıda bayt bazında aynıdır, bu nedenle prompt caching uygundur: bir önbellek okuması, temel girdi fiyatının onda biri kadardır ve beş dakikalık bir önbellek yazımı temel girdinin 1,25 katıdır; dolayısıyla önbellek tek bir isabetten sonra kendini amorti eder. Bunlar Ağustos 2026 itibarıyla Anthropic liste fiyatlarıdır ve Sonnet 5, 31 Ağustos 2026 tarihine kadar tanıtım fiyatlandırmasındadır; bu nedenle üçüncü çubuk bu tarihten sonra yükselir.

Sıralama şu şekildedir:

• Her durumda deterministik kontroller. API maliyeti sıfırdır.
• Bu kontrolleri geçen durumlarda küçük bir model değerlendirici.
• Yalnızca küçük modelin başarısız dediği veya düşük güvenle geçtiği durumlarda sınır modeli değerlendirici.
• Haftada bir kez küçük bir örneklem üzerinde insan incelemesi.

CHEAP = "claude-haiku-4-5-20251001"
STRICT = "claude-opus-5"


def grade(case, result):
    hard = deterministic(case, result)
    if hard:
        return False, "deterministic", "; ".join(hard)
    first = judge(case, result["output"], CHEAP)
    if first["verdict"] == "pass" and first["confidence"] == "high":
        return True, CHEAP, first["reason"]
    second = judge(case, result["output"], STRICT)
    return second["verdict"] == "pass", STRICT, second["reason"]

Bu yöntem, değerlendirme doğruluğundan bir miktar ödün vererek maliyet tasarrufu sağlar; bu nedenle varsayımda bulunmak yerine bu değişimi ölçün. Ayda bir kez, tüm seti katı değerlendirici ile derecelendirin ve iki sütunu karşılaştırın. Eğer birkaç durumdan fazlasında fikir ayrılığı yaşanıyorsa, rubriğiniz küçük model için fazla gevşektir ve düzeltilmesi gereken şey rubriktir. Ajanın kendi harcamalarını kontrol etmek ayrı bir iştir ve bir VPS üzerindeki yapay zeka ajanı için maliyet kontrolü bölümünde ele alınmıştır.

Sahip olduğunuz bir sistemde başarı oranını zaman içinde takip etme

Bir commit ile ilişkilendiremediğiniz başarı oranı sadece bir histen ibarettir. Her çalıştırma için vaka başına bir satır kaydedin; commit ve model bilgisini bu satırın içinde tutun.

CREATE TABLE IF NOT EXISTS results (
  run_id      TEXT NOT NULL,
  ran_at      TEXT NOT NULL,
  git_sha     TEXT NOT NULL,
  agent_model TEXT NOT NULL,
  case_id     TEXT NOT NULL,
  passed      INTEGER NOT NULL,
  graded_by   TEXT NOT NULL,
  reason      TEXT
);

SELECT run_id, git_sha, agent_model,
       count(*) AS cases,
       round(100.0 * sum(passed) / count(*), 1) AS pass_pct
FROM results
GROUP BY run_id
ORDER BY ran_at DESC
LIMIT 10;

Şemayı sqlite3 evals/results.db < evals/schema.sql ile yükleyin, ardından trendi sqlite3 -box evals/results.db < evals/passrate.sql ile okuyun. 60 vaka üzerinden günlük çalıştırmalarla bir yıl, yaklaşık 22,000 satır eder; bu nedenle veri deposu asla başlı başına bir proje haline gelmez. VPS üzerinde SQLite çalıştırma rehberi, bu dosya makineler arasında paylaşıldığında önem kazanan ayarları ele alır.

Çalıştırıcı, bir kişi için aynı bilgileri şu şekilde yazdırır:

run 2026-08-05T09:14:22Z  sha 4f1c9ab  model claude-sonnet-5  58/60 pass (96.7%)
FAIL refund-double-charge  deterministic: tool not called: create_refund
FAIL pto-policy-question   judge(opus): reply gives no dollar amount

Test paketini, bir ajanı bozabilecek değişiklikler üzerinde çalıştırın; bu, depodaki her commit yerine prompt düzenlemeleri, model değişiklikleri ve araç değişiklikleri anlamına gelir. Bir pre-push kancası, hızlı alt kümeyi kapsar:

cat > .git/hooks/pre-push <<'EOF'
#!/bin/sh
python3 evals/run.py --set smoke || exit 1
EOF
chmod +x .git/hooks/pre-push

Tam kapsamlı çalıştırmalar daha yavaştır ve bir zaman çizelgesine bağlı olmalıdır. Gece çalışan bir VPS üzerinde systemd servis ve zamanlayıcısı, tüm seti dağıtılmış prompt üzerinde çalıştırır; bu, barındırılan bir aracın davranışının değişmesi gibi deponuzun dışından gelen değişiklikleri yakalayan yöntemdir.

İnsan incelemesi, kapsamlı değil örneklemeli

Yargıç, insan etiketlerine göre kalibre edilir, bu nedenle birinin bu etiketleri oluşturması gerekir. Her hafta bir örneklem okuyun: yargıcın başarısız olduğu her vaka ve rastgele seçilen on başarılı vaka. Rastgele seçilen başarılı vakalar, işin önemli yarısıdır; çünkü sessizce hatalı yanıtları onaylamaya başlayan bir yargıç, kendi kararlarından oluşturulan herhangi bir kontrol panelinde kusursuz görünür.

Üçer dakikadan on beş vaka haftada 45 dakika eder ve bu süreç, sizinle yargıcın fikir ayrılığına düştüğü durumlarda değerlendirme kriterlerine düzeltmeler sağlar; ayrıca kimsenin öngörmediği başarısızlık türleri için yeni vakalar kazandırır. İnsan kararını, graded_by değeri human olarak ayarlanmış aynı tabloya yazın; böylece yargıç ile insan arasındaki mutabakat, bir hafıza meselesi olmaktan çıkıp bir sorgu haline gelir.

Değerlendirme altyapısının kendisinde ne bozulur

anthropic.RateLimitError ilk tam çalıştırmada. Aynı anda başlatılan altmış vaka, katmanınız için belirlenen istek veya token sınırını aşar. Eşzamanlılığı dört işçi ile sınırlayın ve gece çalıştırmalarını Batch API üzerine taşıyın.

json.JSONDecodeError: Expecting value: line 1 column 1 (char 0) değerlendiriciden kaynaklı. Model düz metin olarak yanıt verdi veya JSON çıktısını bir kod bloğu içine aldı. Bir kez yeniden deneyin, ardından vakayı hata olarak kaydedin. Bir ayrıştırma hatasının başarılı sayılmasına asla izin vermeyin; çünkü hataları başarıya dönüştüren bir test paketi, ajan kötüleşirken %100'e doğru tırmanır.

Kararsız vakalar. Ajan çıktısını örneklediği için aynı girdi bir çalıştırmada başarılı olurken diğerinde başarısız olur. Kararsız vakayı üç kez çalıştırın ve vakayı silmek yerine başarı oranını kaydedin. Üç çalıştırmadan ikisinde başarılı olan bir vaka gerçek bir dayanıklılık hatasıdır ve müşteri bunu mutlaka bulacaktır.

Altın setin eskimesi. Birisi test paketini yeşile çevirmek için beklenen bir yanıtı düzenler. evals/cases.jsonl üzerindeki değişiklikleri, ajana yapılan değişiklikler kadar dikkatli inceleyin; çünkü o dosya, doğruluğun yazılı tanımıdır.

Asla başarısız olmayan bir test paketi. Bir ay boyunca %100 başarı oranında sabit kalan bir paket, ürünün takibini bırakmış demektir. Yakın zamana ait on izleme kaydını çekin, ajanın kötü yönettiği vakaları bulun ve bunları ekleyin. Ardından kasıtlı olarak bir şeyi bozun ve çalıştırmanın kırmızıya döndüğünü doğrulayın; bu, mutasyon testinin bir test paketine uygulanması kontrolüdür ve setinizin hala işlevsel olduğunu bilmenin tek yoludur.

FAQ

Bir yapay zeka ajanı değerlendirme seti kaç örnek içermelidir?

40 ila 80 örnekle başlayın ve seti gerçek hatalardan yola çıkarak genişletin. 20 örneğin altında, tek bir kararsız sonuç başarı oranını 5 puan değiştirir; bu nedenle sayı anlamını yitirir. Birkaç yüz örnekten sonra ise her çalıştırma gerçek maliyet ve zaman kaybına yol açarken, marjinal örnekler çok az ek kapsama sağlar. Önemli olan sayı değil, bilinen üretim hatası türlerinizin en az bir kez set içerisinde yer alma oranıdır.

Ajanımı değerlendirmesi için bir LLM hakemine güvenebilir miyim?

Yalnızca kendi etiketlerinizle kıyaslayarak ölçüm yaptıktan sonra güvenebilirsiniz. Elle derecelendirdiğiniz 30 örneği saklayın ve hakem modelini veya hakem istemini (prompt) her değiştirdiğinizde hakemi bu örneklerle puanlayın. Hakemler, uzun yanıtların daha sık geçmesine neden olan "uzunluk yanlılığı" ve kendi model ailesinden gelen çıktıları daha olumlu değerlendirme eğilimi olan "öz-tercih" sergilerler. Her ikisi de test edilebilir: başarısız bir yanıtı uzatıp tekrar değerlendirin veya aynı yanıtları farklı bir aileden gelen bir hakemle puanlayın. Eğer hakem, on örnekten birinden fazlasında sizin etiketlerinizle çelişiyorsa, değerlendirme kriterleriniz çok belirsizdir.

Değerlendirmeleri hangi model yapmalıdır?

Ucuz olanla derecelendirin ve gerekirse üst modele geçin. Deterministik doğrulamalar maliyetsizdir, bu yüzden her örnekte ilk olarak bunlar çalıştırılmalıdır. Küçük bir model net geçişleri halleder. Yalnızca başarısız sonuçlar ve düşük güvenli kararlar bir sınır (frontier) modeline gönderilir. Ağustos 2026 liste fiyatlarıyla, 1.000 örneği değerlendirmek Claude Haiku 4.5 ile yaklaşık 1.80 ABD dolarına, Claude Opus 5 ile ise yaklaşık 9.00 ABD dolarına mal olur. Değerlendirme çalıştırmaları asenkron olduğu için Batch API kullanımı her iki rakamı da yarıya indirir.

Değerlendirmeler üretim izlemenin yerini tutar mı?

Hayır, çünkü farklı sorulara yanıt verirler. Bir değerlendirme paketi, yayınlamak üzere olduğunuz bir değişikliğin sabit bir örnek setini iyileştirip iyileştirmediğini söyler. İzleme (tracing) ve gözlemleme (monitoring) ise gerçek kullanıcıların o anda neyle karşılaştığını, hiçbir örnek setinin kapsamadığı girdiler dahil olmak üzere size bildirir. Birbirlerini beslerler: izleme kayıtları yeni örnekleri sağlar, değerlendirme paketi ise yaptığınız düzeltmenin gerçekten işe yarayıp yaramadığına karar verir.