[Uygulamada Ajan Platformu (8)] ADK Go Graph İş Akışı Google Research Harness ile Buluştuğunda (Bölüm 2): 4. Aşama Değerlendirme Verilerinin Entegrasyonu

Giriş: Prompt'ları Ayrıştırmak Neden Yeterli Değil?#

Serinin önceki yazısında, Google Research tarafından geliştirilen google-research/harness2 (arXiv:2610.14224) çerçevesini incelemiş ve LINE AI Kartvizit Asistanı'nın (kkdai/line-card-assistant) prompt'larını, güvenlik sınırlarını (guardrails), uzun süreli belleğini ve isteğe bağlı yeteneklerini LINE_CARD_HARNESS_DIR üzerinden dinamik olarak bağlanabilen, düzenlenebilir bir c1..c8 Harness dosya ağacına ayrıştırmıştık.

Ancak yalnızca çalışırken yeniden yüklenebilir (hot-reloadable) bir c1..c8 dosya ağacına sahip olmak yeterli değildir; Harness²'nin çift katmanlı özyinelemeli optimizasyon motoru (harness2/core/recursion.py), Go tabanlı ajanımızı doğrudan optimize edemez. Bunun nedeni, Harness²'nin üç temel soruyu yanıtlayacak standart bir köprüye — yani BenchmarkAdapter bileşenine — ihtiyaç duymasıdır:

• list_tasks() (Test soruları nelerdir?): Ajan hangi test senaryolarıyla sınanmalıdır? Her senaryo için açık girdiler (Prompt / Görsel) ve gizli puanlama kriterleri (Rubrics) nelerdir?
• run() (Ajan nasıl düşünür ve yürütür?): Aday bir Harness ($H'$) belirli bir görevi yürütmek üzere bağlandığında, ajanın nihai çıktısı (deliverable) nedir? Daha da önemlisi, ajan Graph İş Akışı'nın 13 düğümü boyunca hangi karar yörüngesini (trajectory.md) izlemiştir?
• score() (Performans nasıldı?): Nihai çıktı ve yürütme yörüngesi hangi bağımsız puanlama maddelerinden (per_rubric) geçti ve nerelerde puan kaybetti?

4. Aşamada (PR #13) oluşturduğumuz eval/datasets/ otomatik değerlendirme kıyaslaması ve 5. Aşamada (PR #14) tüm 13 Graph düğümüne eklediğimiz workflow.node.* OpenTelemetry Span'leri sayesinde elimizde güçlü bir temel bulunuyor. Bu bölümde (Issue #17 ve PR #19), bu iki varlığı Harness² LineCardAdapter içinde birleştiriyor ve tasarımın neden bu şekilde yapılması gerektiğini inceliyoruz.

Pratik Çıkarım: Üretim seviyesinde ajan geliştirirken yalnızca prompt'ları koddan ayırmak yetmez; Golden Dataset Oluşturma, AI Test Stratejileri ve Agent Monitoring ve Debugging süreçlerini standart bir adaptör arayüzüyle birleştirerek ölçülebilir bir geri bildirim döngüsü kurmak gerekir.

I. Neden Bu Değişiklik? İki Temel Tasarım Felsefesi#

Koda geçmeden önce mühendisler genellikle şu iki soruyu sorar:

• "Neden tüm eval/datasets/*.json dosyasını doğrudan optimize edici LLM'e verip prompt'u kendisinin değiştirmesine izin vermiyoruz?"
• "Neden 5. Aşamadaki OpenTelemetry Span'lerini trajectory.md dosyasına dönüştürmemiz gerekiyor? Nihai LINE yanıt metni ve toplam puan yeterli değil mi?"

Bu iki soru, Harness² makalesindeki en temel mühendislik tasarımlarına işaret eder: Sıfır Sızıntı Bariyeri (Zero-Leakage Barrier) ve Davranışsal Yörünge Karşılaştırması (Behavioral Trajectory Contrast).

1. Neden "Sıfır Sızıntı Bariyeri"? Optimize Edicinin "Cevapları Ezberleyerek Hile Yapmasını" Önlemek#

eval/datasets/harness2-challenge-dataset.json içindeki altın yanıtları (örneğin expected_contains: ["+81-3-1234-5678", "Kenta Sato"]) doğrudan ajana veya Harness² Harvester LLM'e açtığımızı düşünün. Optimize edicinin tam puan almak için seçeceği en kolay ve tembel yol, systemprompt.md dosyasına tek bir satır eklemek olacaktır: "Girdi Sato içeriyorsa, doğrudan +81-3-1234-5678 ve Kenta Sato çıktısını ver."

Makine öğrenmesinde bu durum Test Seti Sızıntısı (Test Set Leakage) veya Rubriklere Aşırı Uyum (Overfitting to Rubrics) olarak bilinir. Ajan kıyaslama testinde 100 tam puan almış gibi görünür, ancak gerçek dünyada yeni bir Japonca kartvizitle karşılaştığında anında çöker.

Yazılım Geliştirme Açısından Yorum: Programatik prompt optimizasyonu yaparken değerlendirme verilerini (expected_contains, expected_route) bir bariyer arkasında tutmak, modelin ezber yapmak yerine genelleyebilir akıl yürütme kuralları geliştirmesini garanti altına alır.